Re: [casper] SNAP ADC at 1GSps
Hi,
Just wanted to say that I managed to run all 3 ADC chips of the SNAP board
in parallel at 960 MSps. The setup worked reliably for approximately an
hour. I managed to make some sort of 3-channel spectrum analyzer.
The board takes input at SMATP1, SMATP5 and SMATP9. PFB consists of the
pfb_generic block working at (12 taps, 4096 points) with a Blackmann window
and FFT is done using the fft_wideband_real taking 4 samples simultaneously
from every input channel. FFT size is 4096 points. The python script plots
3 spectra of 480 MHz in real time, updating at every integration. I managed
to read the 3 spectra, each with 2048 complex 64-bit frequency channels,
through the Raspberry Pi itself. The connection did choke once, but ran
correctly after I changed the cable.
Having fun experimenting. ;)
Cheers,
Nitish
On Fri, Oct 11, 2019 at 10:18 PM Nitish Ragoomundun <
nitish.ragoomun...@gmail.com> wrote:
> Hi,
>
> Thank you very much for your replies. The temperature being a possible
> cause is quite interesting.
>
> Actually for our project we need 250 MSps on 12 channels. I am still in
> the learning process so I set myself a mini project and I thought I'll
> program the SNAP just to output a spectrum. I have already tried
> frequencies lower than 1 GHz and only one ADC working at 1 GSps would have
> been great, but I guess 950 MSps will do. I'll have a wide enough band to
> play with.
>
> Cheers,
> Nitish
>
>
>
>
> On Fri, Oct 11, 2019 at 7:58 PM Ross Martin wrote:
>
>> Hi Nitish,
>>
>> The reason that the ADC worked the first time *might* be temperature.
>> When parts are cooler, they often can run at higher speeds. It might be
>> that the first time you ran it was before the board got warm, and that's
>> why it worked. Then later the board had warmed up, which changes board
>> timing, so it failed. I'm by no means certain of this, but it explains the
>> things you've said and seems like a reasonable possibility.
>>
>> You could test it out by turning down the temperature in the room,
>> letting everything cool overnight, and then running it again early in the
>> morning.
>>
>> If the test works, it might lead to a more permanent solution. Better
>> board cooling might be enough, with fans, heat sinks, or liquid cooling
>> systems.
>>
>> PC gamers often have extensive cooling systems to keep their CPUs cool so
>> they can reach the highest clock speeds when they overclock them. You can
>> find lots of information on cooling-to-increase-speed on the web from the
>> overclocking community -- assuming it's that important to get this working.
>>
>> Also keep in mind that when you're really trying to push speed to it's
>> limits, part variability from one board to another may matter. So try
>> multiple different boards, if you have them, since one board may work when
>> others fail.
>>
>> Ross
>>
>>
>> On Fri, Oct 11, 2019, 7:22 AM Dan Werthimer
>> wrote:
>>
>>>
>>> hi nitish,
>>>
>>> i don't think there's an easy way to make all three adc's work at 1
>>> Gsps.
>>> i think one of the adc's works reliably at 1 Gsps.
>>> the other two work reliably around 950 Msps. (i'm not sure about this
>>> number).
>>>
>>> if 950 Msps isn't enough for your application,
>>> you could play around with the adc's clock termination resistors and
>>> clock distribution chip parameters,
>>> or use an external dual 1gps zdoc adc.
>>>
>>> best wishes,
>>>
>>> dan
>>>
>>>
>>>
>>>
>>> Dan Werthimer
>>> Marilyn and Watson Alberts Chair
>>> Astronomy Dept and Space Sciences Lab
>>> University of California, Berkeley
>>>
>>>
>>> On Fri, Oct 11, 2019 at 12:56 AM Nitish Ragoomundun <
>>> nitish.ragoomun...@gmail.com> wrote:
>>>
Hi,
I read from the SNAP wiki page that we can operate the SNAP board ADCs
at 1GSps with 3 channels of input. So, I modified the CASPER SNAP tutorial
3 to make the ADC work at 1GSps to obtain a 1 channel spectrometer with a
spectrum of 500 MHz. First I modified the SNAP User IP Clock Rate to 250
MHz, then changed the snap_adc Sample Rate to 1000 MHz.
Then I modified the script to obtain a 500 MHz spectrum and the ADC
initialization is done with
adc.init(samplingRate=1000, numChannel=1, resolution=8)
No compilation problem with the toolflow. The script worked the first
time when I ran it. ADC initialization was fine and I got my 500 MHz
spectrum. However, when I ran the script a second time, the ADC
initialization failed with the following messages:
ERROR:root:Frame clock NOT aligned.
{0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 128, 1:
128, 2: 128, 3: 128, 4: 128, 5: 128, 6: 128, 7: 128}, 2: {0: 0, 1: 0, 2: 0,
3: 0, 4: 0, 5: 0, 6: 0, 7: 0}}
ERROR:root:Line clock NOT aligned.
{0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 39, 1: 39,
2: 39, 3: 39, 4: 39, 5: 39, 6: 40, 7: 39}, 2: {0: 0, 1: 0, 2: 0, 3: 0, 4:
0, 5: 0, 6: 0, 7: 0}}
ERROR:root:ADC1
Re: [casper] SNAP ADC at 1GSps
Hi,
Thank you very much for your replies. The temperature being a possible
cause is quite interesting.
Actually for our project we need 250 MSps on 12 channels. I am still in the
learning process so I set myself a mini project and I thought I'll program
the SNAP just to output a spectrum. I have already tried frequencies lower
than 1 GHz and only one ADC working at 1 GSps would have been great, but I
guess 950 MSps will do. I'll have a wide enough band to play with.
Cheers,
Nitish
On Fri, Oct 11, 2019 at 7:58 PM Ross Martin wrote:
> Hi Nitish,
>
> The reason that the ADC worked the first time *might* be temperature. When
> parts are cooler, they often can run at higher speeds. It might be that
> the first time you ran it was before the board got warm, and that's why it
> worked. Then later the board had warmed up, which changes board timing, so
> it failed. I'm by no means certain of this, but it explains the things
> you've said and seems like a reasonable possibility.
>
> You could test it out by turning down the temperature in the room, letting
> everything cool overnight, and then running it again early in the morning.
>
> If the test works, it might lead to a more permanent solution. Better
> board cooling might be enough, with fans, heat sinks, or liquid cooling
> systems.
>
> PC gamers often have extensive cooling systems to keep their CPUs cool so
> they can reach the highest clock speeds when they overclock them. You can
> find lots of information on cooling-to-increase-speed on the web from the
> overclocking community -- assuming it's that important to get this working.
>
> Also keep in mind that when you're really trying to push speed to it's
> limits, part variability from one board to another may matter. So try
> multiple different boards, if you have them, since one board may work when
> others fail.
>
> Ross
>
>
> On Fri, Oct 11, 2019, 7:22 AM Dan Werthimer wrote:
>
>>
>> hi nitish,
>>
>> i don't think there's an easy way to make all three adc's work at 1 Gsps.
>> i think one of the adc's works reliably at 1 Gsps.
>> the other two work reliably around 950 Msps. (i'm not sure about this
>> number).
>>
>> if 950 Msps isn't enough for your application,
>> you could play around with the adc's clock termination resistors and
>> clock distribution chip parameters,
>> or use an external dual 1gps zdoc adc.
>>
>> best wishes,
>>
>> dan
>>
>>
>>
>>
>> Dan Werthimer
>> Marilyn and Watson Alberts Chair
>> Astronomy Dept and Space Sciences Lab
>> University of California, Berkeley
>>
>>
>> On Fri, Oct 11, 2019 at 12:56 AM Nitish Ragoomundun <
>> nitish.ragoomun...@gmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> I read from the SNAP wiki page that we can operate the SNAP board ADCs
>>> at 1GSps with 3 channels of input. So, I modified the CASPER SNAP tutorial
>>> 3 to make the ADC work at 1GSps to obtain a 1 channel spectrometer with a
>>> spectrum of 500 MHz. First I modified the SNAP User IP Clock Rate to 250
>>> MHz, then changed the snap_adc Sample Rate to 1000 MHz.
>>>
>>> Then I modified the script to obtain a 500 MHz spectrum and the ADC
>>> initialization is done with
>>>
>>> adc.init(samplingRate=1000, numChannel=1, resolution=8)
>>>
>>> No compilation problem with the toolflow. The script worked the first
>>> time when I ran it. ADC initialization was fine and I got my 500 MHz
>>> spectrum. However, when I ran the script a second time, the ADC
>>> initialization failed with the following messages:
>>>
>>> ERROR:root:Frame clock NOT aligned.
>>> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 128, 1:
>>> 128, 2: 128, 3: 128, 4: 128, 5: 128, 6: 128, 7: 128}, 2: {0: 0, 1: 0, 2: 0,
>>> 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}}
>>> ERROR:root:Line clock NOT aligned.
>>> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 39, 1: 39,
>>> 2: 39, 3: 39, 4: 39, 5: 39, 6: 40, 7: 39}, 2: {0: 0, 1: 0, 2: 0, 3: 0, 4:
>>> 0, 5: 0, 6: 0, 7: 0}}
>>> ERROR:root:ADC1 lane0 delay decision failed
>>> ERROR:root:ADC1 lane1 delay decision failed
>>> ERROR:root:ADC1 lane2 delay decision failed
>>> ERROR:root:ADC1 lane3 delay decision failed
>>> ERROR:root:ADC1 lane4 delay decision failed
>>> ERROR:root:ADC1 lane5 delay decision failed
>>> ERROR:root:ADC1 lane6 delay decision failed
>>> ERROR:root:ADC1 lane7 delay decision failed
>>> ERROR:root:Line clock NOT aligned.
>>> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 78, 1: 78,
>>> 2: 78, 3: 78, 4: 79, 5: 78, 6: 79, 7: 78}, 2: {0: 0, 1: 0, 2: 0, 3: 0, 4:
>>> 0, 5: 0, 6: 0, 7: 0}}
>>> ERROR:root:ADC1 lane0 delay decision failed
>>> ERROR:root:ADC1 lane1 delay decision failed
>>> ERROR:root:ADC1 lane2 delay decision failed
>>> ERROR:root:ADC1 lane3 delay decision failed
>>> ERROR:root:ADC1 lane4 delay decision failed
>>> ERROR:root:ADC1 lane5 delay decision failed
>>> ERROR:root:ADC1 lane6 delay decision failed
>>> ...
>>>
>>> I have seen these before with the 800 MSps, but ADC initialization would
>>> eventually work at the second
Re: [casper] SNAP ADC at 1GSps
Hi Nitish,
The reason that the ADC worked the first time *might* be temperature. When
parts are cooler, they often can run at higher speeds. It might be that
the first time you ran it was before the board got warm, and that's why it
worked. Then later the board had warmed up, which changes board timing, so
it failed. I'm by no means certain of this, but it explains the things
you've said and seems like a reasonable possibility.
You could test it out by turning down the temperature in the room, letting
everything cool overnight, and then running it again early in the morning.
If the test works, it might lead to a more permanent solution. Better
board cooling might be enough, with fans, heat sinks, or liquid cooling
systems.
PC gamers often have extensive cooling systems to keep their CPUs cool so
they can reach the highest clock speeds when they overclock them. You can
find lots of information on cooling-to-increase-speed on the web from the
overclocking community -- assuming it's that important to get this working.
Also keep in mind that when you're really trying to push speed to it's
limits, part variability from one board to another may matter. So try
multiple different boards, if you have them, since one board may work when
others fail.
Ross
On Fri, Oct 11, 2019, 7:22 AM Dan Werthimer wrote:
>
> hi nitish,
>
> i don't think there's an easy way to make all three adc's work at 1 Gsps.
> i think one of the adc's works reliably at 1 Gsps.
> the other two work reliably around 950 Msps. (i'm not sure about this
> number).
>
> if 950 Msps isn't enough for your application,
> you could play around with the adc's clock termination resistors and clock
> distribution chip parameters,
> or use an external dual 1gps zdoc adc.
>
> best wishes,
>
> dan
>
>
>
>
> Dan Werthimer
> Marilyn and Watson Alberts Chair
> Astronomy Dept and Space Sciences Lab
> University of California, Berkeley
>
>
> On Fri, Oct 11, 2019 at 12:56 AM Nitish Ragoomundun <
> nitish.ragoomun...@gmail.com> wrote:
>
>>
>> Hi,
>>
>> I read from the SNAP wiki page that we can operate the SNAP board ADCs at
>> 1GSps with 3 channels of input. So, I modified the CASPER SNAP tutorial 3
>> to make the ADC work at 1GSps to obtain a 1 channel spectrometer with a
>> spectrum of 500 MHz. First I modified the SNAP User IP Clock Rate to 250
>> MHz, then changed the snap_adc Sample Rate to 1000 MHz.
>>
>> Then I modified the script to obtain a 500 MHz spectrum and the ADC
>> initialization is done with
>>
>> adc.init(samplingRate=1000, numChannel=1, resolution=8)
>>
>> No compilation problem with the toolflow. The script worked the first
>> time when I ran it. ADC initialization was fine and I got my 500 MHz
>> spectrum. However, when I ran the script a second time, the ADC
>> initialization failed with the following messages:
>>
>> ERROR:root:Frame clock NOT aligned.
>> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 128, 1: 128,
>> 2: 128, 3: 128, 4: 128, 5: 128, 6: 128, 7: 128}, 2: {0: 0, 1: 0, 2: 0, 3:
>> 0, 4: 0, 5: 0, 6: 0, 7: 0}}
>> ERROR:root:Line clock NOT aligned.
>> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 39, 1: 39,
>> 2: 39, 3: 39, 4: 39, 5: 39, 6: 40, 7: 39}, 2: {0: 0, 1: 0, 2: 0, 3: 0, 4:
>> 0, 5: 0, 6: 0, 7: 0}}
>> ERROR:root:ADC1 lane0 delay decision failed
>> ERROR:root:ADC1 lane1 delay decision failed
>> ERROR:root:ADC1 lane2 delay decision failed
>> ERROR:root:ADC1 lane3 delay decision failed
>> ERROR:root:ADC1 lane4 delay decision failed
>> ERROR:root:ADC1 lane5 delay decision failed
>> ERROR:root:ADC1 lane6 delay decision failed
>> ERROR:root:ADC1 lane7 delay decision failed
>> ERROR:root:Line clock NOT aligned.
>> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 78, 1: 78,
>> 2: 78, 3: 78, 4: 79, 5: 78, 6: 79, 7: 78}, 2: {0: 0, 1: 0, 2: 0, 3: 0, 4:
>> 0, 5: 0, 6: 0, 7: 0}}
>> ERROR:root:ADC1 lane0 delay decision failed
>> ERROR:root:ADC1 lane1 delay decision failed
>> ERROR:root:ADC1 lane2 delay decision failed
>> ERROR:root:ADC1 lane3 delay decision failed
>> ERROR:root:ADC1 lane4 delay decision failed
>> ERROR:root:ADC1 lane5 delay decision failed
>> ERROR:root:ADC1 lane6 delay decision failed
>> ...
>>
>> I have seen these before with the 800 MSps, but ADC initialization would
>> eventually work at the second attempt, whereas 1 GSps, it fails. I have
>> increased the number of attempts in calling adc.init( ), but it fails time
>> and time again. I also power cycled the board and tried again, but it still
>> fails. The strange thing is that it worked the very first time I ran the
>> script, but failed every single time after this.
>>
>> Is there a way to make 1 GSps work reliably over several re-programming
>> stages and across reboots.
>>
>> Regards,
>> Nitish
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to
Re: [casper] SNAP ADC at 1GSps
hi nitish,
i don't think there's an easy way to make all three adc's work at 1 Gsps.
i think one of the adc's works reliably at 1 Gsps.
the other two work reliably around 950 Msps. (i'm not sure about this
number).
if 950 Msps isn't enough for your application,
you could play around with the adc's clock termination resistors and clock
distribution chip parameters,
or use an external dual 1gps zdoc adc.
best wishes,
dan
Dan Werthimer
Marilyn and Watson Alberts Chair
Astronomy Dept and Space Sciences Lab
University of California, Berkeley
On Fri, Oct 11, 2019 at 12:56 AM Nitish Ragoomundun <
nitish.ragoomun...@gmail.com> wrote:
>
> Hi,
>
> I read from the SNAP wiki page that we can operate the SNAP board ADCs at
> 1GSps with 3 channels of input. So, I modified the CASPER SNAP tutorial 3
> to make the ADC work at 1GSps to obtain a 1 channel spectrometer with a
> spectrum of 500 MHz. First I modified the SNAP User IP Clock Rate to 250
> MHz, then changed the snap_adc Sample Rate to 1000 MHz.
>
> Then I modified the script to obtain a 500 MHz spectrum and the ADC
> initialization is done with
>
> adc.init(samplingRate=1000, numChannel=1, resolution=8)
>
> No compilation problem with the toolflow. The script worked the first time
> when I ran it. ADC initialization was fine and I got my 500 MHz spectrum.
> However, when I ran the script a second time, the ADC initialization failed
> with the following messages:
>
> ERROR:root:Frame clock NOT aligned.
> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 128, 1: 128,
> 2: 128, 3: 128, 4: 128, 5: 128, 6: 128, 7: 128}, 2: {0: 0, 1: 0, 2: 0, 3:
> 0, 4: 0, 5: 0, 6: 0, 7: 0}}
> ERROR:root:Line clock NOT aligned.
> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 39, 1: 39, 2:
> 39, 3: 39, 4: 39, 5: 39, 6: 40, 7: 39}, 2: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0,
> 5: 0, 6: 0, 7: 0}}
> ERROR:root:ADC1 lane0 delay decision failed
> ERROR:root:ADC1 lane1 delay decision failed
> ERROR:root:ADC1 lane2 delay decision failed
> ERROR:root:ADC1 lane3 delay decision failed
> ERROR:root:ADC1 lane4 delay decision failed
> ERROR:root:ADC1 lane5 delay decision failed
> ERROR:root:ADC1 lane6 delay decision failed
> ERROR:root:ADC1 lane7 delay decision failed
> ERROR:root:Line clock NOT aligned.
> {0: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0}, 1: {0: 78, 1: 78, 2:
> 78, 3: 78, 4: 79, 5: 78, 6: 79, 7: 78}, 2: {0: 0, 1: 0, 2: 0, 3: 0, 4: 0,
> 5: 0, 6: 0, 7: 0}}
> ERROR:root:ADC1 lane0 delay decision failed
> ERROR:root:ADC1 lane1 delay decision failed
> ERROR:root:ADC1 lane2 delay decision failed
> ERROR:root:ADC1 lane3 delay decision failed
> ERROR:root:ADC1 lane4 delay decision failed
> ERROR:root:ADC1 lane5 delay decision failed
> ERROR:root:ADC1 lane6 delay decision failed
> ...
>
> I have seen these before with the 800 MSps, but ADC initialization would
> eventually work at the second attempt, whereas 1 GSps, it fails. I have
> increased the number of attempts in calling adc.init( ), but it fails time
> and time again. I also power cycled the board and tried again, but it still
> fails. The strange thing is that it worked the very first time I ran the
> script, but failed every single time after this.
>
> Is there a way to make 1 GSps work reliably over several re-programming
> stages and across reboots.
>
> Regards,
> Nitish
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAC6X4cMmhx0LnqytPGVTuHvS8N8LfZP7pOyLKsxuYJ51u1um2Q%40mail.gmail.com
>
> .
>
--
You received this message because you are subscribed to the Google Groups
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGHS_vH9jdRFU9htPizCYLMWbm8RPDY-vhgLqnBVBCbP%2Bq6MdA%40mail.gmail.com.
