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 <ross.mar...@ieee.org> 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 <d...@ssl.berkeley.edu> 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 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
>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAC6X4cMmhx0LnqytPGVTuHvS8N8LfZP7pOyLKsxuYJ51u1um2Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGHS_vH9jdRFU9htPizCYLMWbm8RPDY-vhgLqnBVBCbP%2Bq6MdA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/CAG4nf73D0R1R1KPmd-hLvKn-D-Dc-NbJiknu_zHGMtvqtmTm8Q%40mail.gmail.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG4nf73D0R1R1KPmd-hLvKn-D-Dc-NbJiknu_zHGMtvqtmTm8Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAC6X4cMWK4Op8Hp%2BZzFGia371fcGo4gNqnbEq1tiYyNKgGgrRQ%40mail.gmail.com.
