Re: [casper] adc5g block run at 2500MHz
Hi everyone, from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 bit without a great effort in the design phase. I'd like to understand how portable would it be a design using roach1+iADC with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, just by encreasing the processed bandwidth and tweaking the necessary bits in the model file like the number of parallel streams ecc... Also, can anyone provide informations about pricing and availability of these high freq samplers? thanks for the info cheers Marco 2014/1/15 Weiwei Sun su...@uw.edu Oh, that's clear! I followed it and got the design compiled successfully in Simulink. Thanks Jack! Best, Weiwei On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish jackhick...@gmail.comwrote: Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the meantime, the changes (along with LOTS of other modifications to other parts of the library) are in my repo at https://github.com/jack-h/mlib_devel Alternatively, if you've got the latest mlib_devel from sma-wideband, you can apply the patch I emailed using the command (run within the repository) git apply /path/to/adc5g-mmcm.patch Cheers, Jack On 15 January 2014 20:24, Weiwei Sun su...@uw.edu wrote: Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project. Thanks! Best, Weiwei On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish jackhick...@gmail.com wrote: On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from the ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a per-bit calibration anyway. With IODELAY calibration only (without bothering with the MMCM phase) so far I haven't had any glitches in 2 hours of running. Strangely, when I ran the MMCM phasing calibration after IODELAY cal, things got worse, but I've been wildly hacking software, so there's a very reasonable chance I've broken something. I'll look into this after I've let my current glitch counting test run for a bit longer. I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Our git repos seem to have diverged quite a lot, but I've attached a patch to peruse/edit/merge at your leisure. Obviously, YMMV :) Cheers, Jack Thanks! Rurik On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are
Re: [casper] adc5g block run at 2500MHz
i suggest you contact mo ohady at digicom electronics for pricing and availability of adc's and roach boards. m...@digicom.org casper collaborators might already have a design similar to what you need. are you building a correlator? or a spectrometer? how many frequency channels? how many adc inputs? readout rate? full stokes? it might be hard to get the roach1 to sample all the way up to 5 Gsps. it's been accomplished by several people on roach2, but i don't know anyone that has a roach1 and adc08-5000 working at 5 Gsps. best wishes, dan On Fri, Jan 24, 2014 at 2:16 AM, Marco Bartolini mbartol...@med.ira.inaf.it wrote: Hi everyone, from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 bit without a great effort in the design phase. I'd like to understand how portable would it be a design using roach1+iADC with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, just by encreasing the processed bandwidth and tweaking the necessary bits in the model file like the number of parallel streams ecc... Also, can anyone provide informations about pricing and availability of these high freq samplers? thanks for the info cheers Marco 2014/1/15 Weiwei Sun su...@uw.edu Oh, that's clear! I followed it and got the design compiled successfully in Simulink. Thanks Jack! Best, Weiwei On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish jackhick...@gmail.comwrote: Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the meantime, the changes (along with LOTS of other modifications to other parts of the library) are in my repo at https://github.com/jack-h/mlib_devel Alternatively, if you've got the latest mlib_devel from sma-wideband, you can apply the patch I emailed using the command (run within the repository) git apply /path/to/adc5g-mmcm.patch Cheers, Jack On 15 January 2014 20:24, Weiwei Sun su...@uw.edu wrote: Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project. Thanks! Best, Weiwei On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish jackhick...@gmail.com wrote: On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from the ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a per-bit calibration anyway. With IODELAY calibration only (without bothering with the MMCM phase) so far I haven't had any glitches in 2 hours of running. Strangely, when I ran the MMCM phasing calibration after IODELAY cal, things got worse, but I've been wildly hacking software, so there's a very reasonable chance I've broken something. I'll look into this after I've let my current glitch counting test run for a bit longer. I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Our git repos seem to have diverged quite a lot, but I've attached a patch to peruse/edit/merge at your leisure. Obviously, YMMV :) Cheers, Jack Thanks! Rurik On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be
Re: [casper] adc5g block run at 2500MHz
The roach 1 will only work at the speeds you are interested at with the dmux 2:1 option at 4 bits. I think the max speed at 8 bits is about 3.2GSPS and that is due to the ZDOK interface. I'm sure with significant effort in planahead you could achieve 5GSPS on a low resolution correlator in a ROACH-1 (I have it working at 4GSPS). My advice would be to just go the ROACH-2 route and eat the cost - I believe there are correlator designs already working out there at 5GSPS using an adc5g on a ROACH2 On Fri, Jan 24, 2014 at 8:19 AM, John Ford jf...@nrao.edu wrote: i suggest you contact mo ohady at digicom electronics for pricing and availability of adc's and roach boards. m...@digicom.org casper collaborators might already have a design similar to what you need. are you building a correlator? or a spectrometer? how many frequency channels? how many adc inputs? readout rate? full stokes? it might be hard to get the roach1 to sample all the way up to 5 Gsps. it's been accomplished by several people on roach2, but i don't know anyone that has a roach1 and adc08-5000 working at 5 Gsps. Agreed, although I think it would be easy to port a working spectrometer with an iADC to use the 5gs sampler sampling at only 800 MS/s. Using it in the demux x8 it should work fine. the demux x16 is more of a problem for roach1 due to routing resource usage, I think. John best wishes, dan On Fri, Jan 24, 2014 at 2:16 AM, Marco Bartolini mbartol...@med.ira.inaf.it wrote: Hi everyone, from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 bit without a great effort in the design phase. I'd like to understand how portable would it be a design using roach1+iADC with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, just by encreasing the processed bandwidth and tweaking the necessary bits in the model file like the number of parallel streams ecc... Also, can anyone provide informations about pricing and availability of these high freq samplers? thanks for the info cheers Marco 2014/1/15 Weiwei Sun su...@uw.edu Oh, that's clear! I followed it and got the design compiled successfully in Simulink. Thanks Jack! Best, Weiwei On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish jackhick...@gmail.comwrote: Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the meantime, the changes (along with LOTS of other modifications to other parts of the library) are in my repo at https://github.com/jack-h/mlib_devel Alternatively, if you've got the latest mlib_devel from sma-wideband, you can apply the patch I emailed using the command (run within the repository) git apply /path/to/adc5g-mmcm.patch Cheers, Jack On 15 January 2014 20:24, Weiwei Sun su...@uw.edu wrote: Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project. Thanks! Best, Weiwei On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish jackhick...@gmail.com wrote: On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from the ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a per-bit calibration anyway. With IODELAY calibration only (without bothering with the MMCM phase) so far I haven't had any glitches in 2 hours of running. Strangely, when I ran the MMCM phasing calibration after IODELAY cal, things got worse, but I've been wildly hacking software, so there's a very reasonable chance I've broken something. I'll look into this after I've let my current glitch counting test run for a bit longer. I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Our git repos seem to have diverged quite a lot, but I've attached a patch to peruse/edit/merge at your leisure. Obviously, YMMV :) Cheers, Jack Thanks! Rurik On
Re: [casper] adc5g block run at 2500MHz
you can probably to sample faster than 3.2Gsps 8 bit on a roach1 if you use the -2 speed grade fpga. you can look at the fpga data sheets to find their max lvds bit rate for the -1 and -2 speed grades. note that if you want to use the 5Gsps 4 bit ADC, that that's a different adc board - you can not make an 8 bit board into a 4 bit board or vice versa. order the one you need. i agree that if you want to sample 5Gsps 8 bits, the easiest thing to do is get a roach2 board. several people have developed instruments using a pair of 5 Gsps ADC's feeding a roach2. best wishes, dan On Fri, Jan 24, 2014 at 3:43 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: The roach 1 will only work at the speeds you are interested at with the dmux 2:1 option at 4 bits. I think the max speed at 8 bits is about 3.2GSPS and that is due to the ZDOK interface. I'm sure with significant effort in planahead you could achieve 5GSPS on a low resolution correlator in a ROACH-1 (I have it working at 4GSPS). My advice would be to just go the ROACH-2 route and eat the cost - I believe there are correlator designs already working out there at 5GSPS using an adc5g on a ROACH2 On Fri, Jan 24, 2014 at 8:19 AM, John Ford jf...@nrao.edu wrote: i suggest you contact mo ohady at digicom electronics for pricing and availability of adc's and roach boards. m...@digicom.org casper collaborators might already have a design similar to what you need. are you building a correlator? or a spectrometer? how many frequency channels? how many adc inputs? readout rate? full stokes? it might be hard to get the roach1 to sample all the way up to 5 Gsps. it's been accomplished by several people on roach2, but i don't know anyone that has a roach1 and adc08-5000 working at 5 Gsps. Agreed, although I think it would be easy to port a working spectrometer with an iADC to use the 5gs sampler sampling at only 800 MS/s. Using it in the demux x8 it should work fine. the demux x16 is more of a problem for roach1 due to routing resource usage, I think. John best wishes, dan On Fri, Jan 24, 2014 at 2:16 AM, Marco Bartolini mbartol...@med.ira.inaf.it wrote: Hi everyone, from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 bit without a great effort in the design phase. I'd like to understand how portable would it be a design using roach1+iADC with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, just by encreasing the processed bandwidth and tweaking the necessary bits in the model file like the number of parallel streams ecc... Also, can anyone provide informations about pricing and availability of these high freq samplers? thanks for the info cheers Marco 2014/1/15 Weiwei Sun su...@uw.edu Oh, that's clear! I followed it and got the design compiled successfully in Simulink. Thanks Jack! Best, Weiwei On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish jackhick...@gmail.comwrote: Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the meantime, the changes (along with LOTS of other modifications to other parts of the library) are in my repo at https://github.com/jack-h/mlib_devel Alternatively, if you've got the latest mlib_devel from sma-wideband, you can apply the patch I emailed using the command (run within the repository) git apply /path/to/adc5g-mmcm.patch Cheers, Jack On 15 January 2014 20:24, Weiwei Sun su...@uw.edu wrote: Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project. Thanks! Best, Weiwei On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish jackhick...@gmail.com wrote: On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from
Re: [casper] adc5g block run at 2500MHz
Hi All, Could someone summarize this discussion for me re: the case I am interested in, which is as follows? I have a need for a dual-pol spectrometer covering an RF of at least 1-18 GHz (0.5-18 GHz is better). From the discussion, it sounds like one option is to use the 1x5GSPs board at 1:1 (8-bit) on ROACH-2, using two such ADCs per ROACH, giving 2.5 GHz dual-polarization per ROACH. Using 7 such ROACH systems would cover 17.5 GHz, with suitable downconversion upstream. However, it is likely that I can only afford 4 ROACH-2s for the project, which would mean I would have to time-multiplex to cover the band, but could then relax the clock speed to 2.2 GHz and cover 2.2 GHz x 4 ROACH x 2 times = 17.6 GHz. Is this a viable solution? What is the FPGA clock speed resulting from this? Is it 8 times less than the ADC clock speed? Thanks, Dale On Fri, Jan 24, 2014 at 7:04 PM, Dan Werthimer d...@ssl.berkeley.eduwrote: you can probably to sample faster than 3.2Gsps 8 bit on a roach1 if you use the -2 speed grade fpga. you can look at the fpga data sheets to find their max lvds bit rate for the -1 and -2 speed grades. note that if you want to use the 5Gsps 4 bit ADC, that that's a different adc board - you can not make an 8 bit board into a 4 bit board or vice versa. order the one you need. i agree that if you want to sample 5Gsps 8 bits, the easiest thing to do is get a roach2 board. several people have developed instruments using a pair of 5 Gsps ADC's feeding a roach2. best wishes, dan On Fri, Jan 24, 2014 at 3:43 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: The roach 1 will only work at the speeds you are interested at with the dmux 2:1 option at 4 bits. I think the max speed at 8 bits is about 3.2GSPS and that is due to the ZDOK interface. I'm sure with significant effort in planahead you could achieve 5GSPS on a low resolution correlator in a ROACH-1 (I have it working at 4GSPS). My advice would be to just go the ROACH-2 route and eat the cost - I believe there are correlator designs already working out there at 5GSPS using an adc5g on a ROACH2 On Fri, Jan 24, 2014 at 8:19 AM, John Ford jf...@nrao.edu wrote: i suggest you contact mo ohady at digicom electronics for pricing and availability of adc's and roach boards. m...@digicom.org casper collaborators might already have a design similar to what you need. are you building a correlator? or a spectrometer? how many frequency channels? how many adc inputs? readout rate? full stokes? it might be hard to get the roach1 to sample all the way up to 5 Gsps. it's been accomplished by several people on roach2, but i don't know anyone that has a roach1 and adc08-5000 working at 5 Gsps. Agreed, although I think it would be easy to port a working spectrometer with an iADC to use the 5gs sampler sampling at only 800 MS/s. Using it in the demux x8 it should work fine. the demux x16 is more of a problem for roach1 due to routing resource usage, I think. John best wishes, dan On Fri, Jan 24, 2014 at 2:16 AM, Marco Bartolini mbartol...@med.ira.inaf.it wrote: Hi everyone, from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 bit without a great effort in the design phase. I'd like to understand how portable would it be a design using roach1+iADC with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, just by encreasing the processed bandwidth and tweaking the necessary bits in the model file like the number of parallel streams ecc... Also, can anyone provide informations about pricing and availability of these high freq samplers? thanks for the info cheers Marco 2014/1/15 Weiwei Sun su...@uw.edu Oh, that's clear! I followed it and got the design compiled successfully in Simulink. Thanks Jack! Best, Weiwei On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish jackhick...@gmail.comwrote: Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the meantime, the changes (along with LOTS of other modifications to other parts of the library) are in my repo at https://github.com/jack-h/mlib_devel Alternatively, if you've got the latest mlib_devel from sma-wideband, you can apply the patch I emailed using the command (run within the repository) git apply /path/to/adc5g-mmcm.patch Cheers, Jack On 15 January 2014 20:24, Weiwei Sun su...@uw.edu wrote: Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project.
Re: [casper] adc5g block run at 2500MHz
hi dale, your plan sounds good to me. the adc08-5000 yellow block for roach2 demuxes by 16, so a 5Gsps sample rates means a 312.5 MHz FPGA rate. 312 MHz fpga rate is not easy to acheive - you need to learn how to use the plan ahead software, and you can't pack the fpga full. how many spectral channels do you want? their may be some roach2/adc08-5000 spectrometer designs you can use or adapt. if you are lucky, you can use a design as is, and not have to learn floor planning to get to 312 MHz clock rates. i think NRAO's DiBAS design (led by John Ford) uses a Roach2 board to sample a pair of ADC's at 5 Gsps, and one of the DiBAS modes does stokes spectroscopy. and Jack Hickish's AMI correlator also samples a pair of 5 Gsps ADC's using Roach2. best wishes, dan On Fri, Jan 24, 2014 at 4:30 PM, Gary, Dale E. dale.e.g...@njit.edu wrote: Hi All, Could someone summarize this discussion for me re: the case I am interested in, which is as follows? I have a need for a dual-pol spectrometer covering an RF of at least 1-18 GHz (0.5-18 GHz is better). From the discussion, it sounds like one option is to use the 1x5GSPs board at 1:1 (8-bit) on ROACH-2, using two such ADCs per ROACH, giving 2.5 GHz dual-polarization per ROACH. Using 7 such ROACH systems would cover 17.5 GHz, with suitable downconversion upstream. However, it is likely that I can only afford 4 ROACH-2s for the project, which would mean I would have to time-multiplex to cover the band, but could then relax the clock speed to 2.2 GHz and cover 2.2 GHz x 4 ROACH x 2 times = 17.6 GHz. Is this a viable solution? What is the FPGA clock speed resulting from this? Is it 8 times less than the ADC clock speed? Thanks, Dale On Fri, Jan 24, 2014 at 7:04 PM, Dan Werthimer d...@ssl.berkeley.eduwrote: you can probably to sample faster than 3.2Gsps 8 bit on a roach1 if you use the -2 speed grade fpga. you can look at the fpga data sheets to find their max lvds bit rate for the -1 and -2 speed grades. note that if you want to use the 5Gsps 4 bit ADC, that that's a different adc board - you can not make an 8 bit board into a 4 bit board or vice versa. order the one you need. i agree that if you want to sample 5Gsps 8 bits, the easiest thing to do is get a roach2 board. several people have developed instruments using a pair of 5 Gsps ADC's feeding a roach2. best wishes, dan On Fri, Jan 24, 2014 at 3:43 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: The roach 1 will only work at the speeds you are interested at with the dmux 2:1 option at 4 bits. I think the max speed at 8 bits is about 3.2GSPS and that is due to the ZDOK interface. I'm sure with significant effort in planahead you could achieve 5GSPS on a low resolution correlator in a ROACH-1 (I have it working at 4GSPS). My advice would be to just go the ROACH-2 route and eat the cost - I believe there are correlator designs already working out there at 5GSPS using an adc5g on a ROACH2 On Fri, Jan 24, 2014 at 8:19 AM, John Ford jf...@nrao.edu wrote: i suggest you contact mo ohady at digicom electronics for pricing and availability of adc's and roach boards. m...@digicom.org casper collaborators might already have a design similar to what you need. are you building a correlator? or a spectrometer? how many frequency channels? how many adc inputs? readout rate? full stokes? it might be hard to get the roach1 to sample all the way up to 5 Gsps. it's been accomplished by several people on roach2, but i don't know anyone that has a roach1 and adc08-5000 working at 5 Gsps. Agreed, although I think it would be easy to port a working spectrometer with an iADC to use the 5gs sampler sampling at only 800 MS/s. Using it in the demux x8 it should work fine. the demux x16 is more of a problem for roach1 due to routing resource usage, I think. John best wishes, dan On Fri, Jan 24, 2014 at 2:16 AM, Marco Bartolini mbartol...@med.ira.inaf.it wrote: Hi everyone, from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 bit without a great effort in the design phase. I'd like to understand how portable would it be a design using roach1+iADC with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, just by encreasing the processed bandwidth and tweaking the necessary bits in the model file like the number of parallel streams ecc... Also, can anyone provide informations about pricing and availability of these high freq samplers? thanks for the info cheers Marco 2014/1/15 Weiwei Sun su...@uw.edu Oh, that's clear! I followed it and got the design compiled successfully in Simulink. Thanks Jack! Best, Weiwei On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish jackhick...@gmail.comwrote: Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the
Re: [casper] adc5g block run at 2500MHz
Thanks Dan. I think I should get a couple of these ADCs and maybe John's design and give it a try! John, how many channels does your design use over 2.5 GHz? We would want of order 20,000, if that is possible. Regards, Dale On Fri, Jan 24, 2014 at 7:48 PM, Dan Werthimer d...@ssl.berkeley.eduwrote: hi dale, your plan sounds good to me. the adc08-5000 yellow block for roach2 demuxes by 16, so a 5Gsps sample rates means a 312.5 MHz FPGA rate. 312 MHz fpga rate is not easy to acheive - you need to learn how to use the plan ahead software, and you can't pack the fpga full. how many spectral channels do you want? their may be some roach2/adc08-5000 spectrometer designs you can use or adapt. if you are lucky, you can use a design as is, and not have to learn floor planning to get to 312 MHz clock rates. i think NRAO's DiBAS design (led by John Ford) uses a Roach2 board to sample a pair of ADC's at 5 Gsps, and one of the DiBAS modes does stokes spectroscopy. and Jack Hickish's AMI correlator also samples a pair of 5 Gsps ADC's using Roach2. best wishes, dan On Fri, Jan 24, 2014 at 4:30 PM, Gary, Dale E. dale.e.g...@njit.eduwrote: Hi All, Could someone summarize this discussion for me re: the case I am interested in, which is as follows? I have a need for a dual-pol spectrometer covering an RF of at least 1-18 GHz (0.5-18 GHz is better). From the discussion, it sounds like one option is to use the 1x5GSPs board at 1:1 (8-bit) on ROACH-2, using two such ADCs per ROACH, giving 2.5 GHz dual-polarization per ROACH. Using 7 such ROACH systems would cover 17.5 GHz, with suitable downconversion upstream. However, it is likely that I can only afford 4 ROACH-2s for the project, which would mean I would have to time-multiplex to cover the band, but could then relax the clock speed to 2.2 GHz and cover 2.2 GHz x 4 ROACH x 2 times = 17.6 GHz. Is this a viable solution? What is the FPGA clock speed resulting from this? Is it 8 times less than the ADC clock speed? Thanks, Dale On Fri, Jan 24, 2014 at 7:04 PM, Dan Werthimer d...@ssl.berkeley.eduwrote: you can probably to sample faster than 3.2Gsps 8 bit on a roach1 if you use the -2 speed grade fpga. you can look at the fpga data sheets to find their max lvds bit rate for the -1 and -2 speed grades. note that if you want to use the 5Gsps 4 bit ADC, that that's a different adc board - you can not make an 8 bit board into a 4 bit board or vice versa. order the one you need. i agree that if you want to sample 5Gsps 8 bits, the easiest thing to do is get a roach2 board. several people have developed instruments using a pair of 5 Gsps ADC's feeding a roach2. best wishes, dan On Fri, Jan 24, 2014 at 3:43 PM, Ross Williamson rwilliam...@astro.caltech.edu wrote: The roach 1 will only work at the speeds you are interested at with the dmux 2:1 option at 4 bits. I think the max speed at 8 bits is about 3.2GSPS and that is due to the ZDOK interface. I'm sure with significant effort in planahead you could achieve 5GSPS on a low resolution correlator in a ROACH-1 (I have it working at 4GSPS). My advice would be to just go the ROACH-2 route and eat the cost - I believe there are correlator designs already working out there at 5GSPS using an adc5g on a ROACH2 On Fri, Jan 24, 2014 at 8:19 AM, John Ford jf...@nrao.edu wrote: i suggest you contact mo ohady at digicom electronics for pricing and availability of adc's and roach boards. m...@digicom.org casper collaborators might already have a design similar to what you need. are you building a correlator? or a spectrometer? how many frequency channels? how many adc inputs? readout rate? full stokes? it might be hard to get the roach1 to sample all the way up to 5 Gsps. it's been accomplished by several people on roach2, but i don't know anyone that has a roach1 and adc08-5000 working at 5 Gsps. Agreed, although I think it would be easy to port a working spectrometer with an iADC to use the 5gs sampler sampling at only 800 MS/s. Using it in the demux x8 it should work fine. the demux x16 is more of a problem for roach1 due to routing resource usage, I think. John best wishes, dan On Fri, Jan 24, 2014 at 2:16 AM, Marco Bartolini mbartol...@med.ira.inaf.it wrote: Hi everyone, from what I understand the adc5g can easily sample 2.2GHz bandwidth at 8 bit without a great effort in the design phase. I'd like to understand how portable would it be a design using roach1+iADC with 400MHz bandwidth to a roach1+adc5g setup sampling 2.2GHz bandwidth, just by encreasing the processed bandwidth and tweaking the necessary bits in the model file like the number of parallel streams ecc... Also, can anyone provide informations about pricing and availability of these high freq samplers? thanks for the info cheers Marco 2014/1/15 Weiwei Sun
Re: [casper] adc5g block run at 2500MHz
Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are just dumping data to a snapshot. I believe a ROACH-2 is harder to reach timing. Ross On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish jackhick...@gmail.com wrote: Hi all, Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a simple ADC to snap model, and (as Rurik warned) getting reliable data capturing is difficult at this speed. I've tried per-bit calibration of input data streams via IODELAYs in conjunction with phase-shifting of the sampling clock, but can't seem to achieve glitchless data capture for any reasonable length of time. In the email I'm replying to, Rurik suggests a number of ways around this problem, but before I opt for forcing an unsupported MMCM mode by compiling and running at different speeds, I thought a final desperate plea for any advice on the maillist might be worthwhile. If anyone has any words of wisdom, I'd be excessively grateful to hear from them. Cheers, Jack On 6 November 2013 16:31, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Weiwei, Generally the sma-wideband/mlib_devel has the most recent changes to the ADC5g yellow block, please use the latest commit of that repo (at this moment it is 2c80cb2). The problem your are seeing is related to a change that was introduced in the Xilinx tools (I believe from version 11 to 12) that increased the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125 MHz in HIGH bandwidth mode. This made it no longer possible to clock the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH bandwidth mode. There are a few options for moving forward (ordered by ease of implementation): 1. Clock the ADC below (and not including) 2400 MHz 2. Change MMCM from HIGH to LOW bandwidth mode 3. Compile your design with the ADC clocked above (and not including) 5400 MHz, but actually run it at 5 GHz 4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH bandwidth mode 5. Compile your design using the Xilinx 11 tools If you don't need to sample at exactly 5 Gsps then option 1 is the optimal solution. If 5 Gsps is critical then you can go with options 2 or 3. Option 2 has non-ideal clock-to-out timing and may cause problems when trying to calibrate out jitter due to the data capturing. Option 3 may cause timing problems since your fabric clock will run at 337.5 MHz. I have not found a way to implement option 4 but I can't see why this shouldn't be possible. Finally option 5 may or may not be useful to you. The SMA wideband correlator runs its ADCs below 4800 Msps. However we have bitcodes that we use to characterize the ADC that run at 5 Gsps and which have low resource utilization. For what it's worth we used option 3 to get around this issue and this appears to work for us. Whatever reason Xilinx had for changing the minimum PFD frequency to 135 MHz does not seem to cause problems for us. Hope this helps, Rurik On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun su...@uw.edu wrote: I tried the casper-astro, ska-sa, sma-wideband. None of them seemly works. Weiwei On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi, Which version of mlib_devel are you using? Rurik On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun su...@uw.edu wrote: Hi, I have trouble to compile the adc clock rate of asiaa_adc5g block at 2500MHz. Block parameter: two-channel, ZDOK0, demux 1:1 . System: roach2, clock source:adc0_clk, clock rate: 312.5MHz) The error is as follows: Creating block object: xps_adc5g Problem with block: lab_test_adv5/asiaa_adc5g1 :
Re: [casper] adc5g block run at 2500MHz
Hi Jack, Great work! The oversample mode is not something I realized existed! Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Thanks! Rurik On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are just dumping data to a snapshot. I believe a ROACH-2 is harder to reach timing. Ross On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish jackhick...@gmail.com wrote: Hi all, Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a simple ADC to snap model, and (as Rurik warned) getting reliable data capturing is difficult at this speed. I've tried per-bit calibration of input data streams via IODELAYs in conjunction with phase-shifting of the sampling clock, but can't seem to achieve glitchless data capture for any reasonable length of time. In the email I'm replying to, Rurik suggests a number of ways around this problem, but before I opt for forcing an unsupported MMCM mode by compiling and running at different speeds, I thought a final desperate plea for any advice on the maillist might be worthwhile. If anyone has any words of wisdom, I'd be excessively grateful to hear from them. Cheers, Jack On 6 November 2013 16:31, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Weiwei, Generally the sma-wideband/mlib_devel has the most recent changes to the ADC5g yellow block, please use the latest commit of that repo (at this moment it is 2c80cb2). The problem your are seeing is related to a change that was introduced in the Xilinx tools (I believe from version 11 to 12) that increased the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125 MHz in HIGH bandwidth mode. This made it no longer possible to clock the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH bandwidth mode. There are a few options for moving forward (ordered by ease of implementation): 1. Clock the ADC below (and not including) 2400 MHz 2. Change MMCM from HIGH to LOW bandwidth mode 3. Compile your design with the ADC clocked above (and not including) 5400 MHz, but actually run it at 5 GHz 4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH bandwidth mode 5. Compile your design using the Xilinx 11 tools If you don't need to sample at exactly 5 Gsps then option 1 is the optimal solution. If 5 Gsps is critical then you can go with options 2 or 3. Option 2 has non-ideal clock-to-out timing and may cause problems when trying to calibrate out jitter due to the data capturing. Option 3 may cause timing problems since your fabric clock will run at 337.5 MHz. I have not found a way to implement option 4 but I can't see why this shouldn't be possible. Finally option 5 may or may not be useful to you. The SMA wideband correlator runs its ADCs below 4800 Msps. However we have bitcodes that we use to characterize the ADC that run at 5 Gsps and which have low resource utilization. For what it's worth we used option 3 to get around this issue and this appears to work for us. Whatever reason Xilinx had for changing the minimum PFD frequency to 135 MHz does not seem to cause problems for us. Hope this helps, Rurik On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun su...@uw.edu wrote: I tried the casper-astro, ska-sa, sma-wideband. None of them seemly works. Weiwei On Tue, Nov
Re: [casper] adc5g block run at 2500MHz
On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from the ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a per-bit calibration anyway. With IODELAY calibration only (without bothering with the MMCM phase) so far I haven't had any glitches in 2 hours of running. Strangely, when I ran the MMCM phasing calibration after IODELAY cal, things got worse, but I've been wildly hacking software, so there's a very reasonable chance I've broken something. I'll look into this after I've let my current glitch counting test run for a bit longer. I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Our git repos seem to have diverged quite a lot, but I've attached a patch to peruse/edit/merge at your leisure. Obviously, YMMV :) Cheers, Jack Thanks! Rurik On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are just dumping data to a snapshot. I believe a ROACH-2 is harder to reach timing. Ross On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish jackhick...@gmail.com wrote: Hi all, Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a simple ADC to snap model, and (as Rurik warned) getting reliable data capturing is difficult at this speed. I've tried per-bit calibration of input data streams via IODELAYs in conjunction with phase-shifting of the sampling clock, but can't seem to achieve glitchless data capture for any reasonable length of time. In the email I'm replying to, Rurik suggests a number of ways around this problem, but before I opt for forcing an unsupported MMCM mode by compiling and running at different speeds, I thought a final desperate plea for any advice on the maillist might be worthwhile. If anyone has any words of wisdom, I'd be excessively grateful to hear from them. Cheers, Jack On 6 November 2013 16:31, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Weiwei, Generally the sma-wideband/mlib_devel has the most recent changes to the ADC5g yellow block, please use the latest commit of that repo (at this moment it is 2c80cb2). The problem your are seeing is related to a change that was introduced in the Xilinx tools (I believe from version 11 to 12) that increased the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125 MHz in HIGH bandwidth mode. This made it no longer possible to clock the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH bandwidth mode. There are a few options for moving forward (ordered by ease of implementation): 1. Clock the ADC below (and not including) 2400 MHz 2. Change MMCM from HIGH to LOW bandwidth mode 3. Compile your design with the ADC clocked above (and not including) 5400 MHz, but actually run it at 5 GHz 4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH bandwidth mode 5. Compile your design using the
Re: [casper] adc5g block run at 2500MHz
Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project. Thanks! Best, Weiwei On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish jackhick...@gmail.com wrote: On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from the ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a per-bit calibration anyway. With IODELAY calibration only (without bothering with the MMCM phase) so far I haven't had any glitches in 2 hours of running. Strangely, when I ran the MMCM phasing calibration after IODELAY cal, things got worse, but I've been wildly hacking software, so there's a very reasonable chance I've broken something. I'll look into this after I've let my current glitch counting test run for a bit longer. I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Our git repos seem to have diverged quite a lot, but I've attached a patch to peruse/edit/merge at your leisure. Obviously, YMMV :) Cheers, Jack Thanks! Rurik On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are just dumping data to a snapshot. I believe a ROACH-2 is harder to reach timing. Ross On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish jackhick...@gmail.com wrote: Hi all, Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a simple ADC to snap model, and (as Rurik warned) getting reliable data capturing is difficult at this speed. I've tried per-bit calibration of input data streams via IODELAYs in conjunction with phase-shifting of the sampling clock, but can't seem to achieve glitchless data capture for any reasonable length of time. In the email I'm replying to, Rurik suggests a number of ways around this problem, but before I opt for forcing an unsupported MMCM mode by compiling and running at different speeds, I thought a final desperate plea for any advice on the maillist might be worthwhile. If anyone has any words of wisdom, I'd be excessively grateful to hear from them. Cheers, Jack On 6 November 2013 16:31, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Weiwei, Generally the sma-wideband/mlib_devel has the most recent changes to the ADC5g yellow block, please use the latest commit of that repo (at this moment it is 2c80cb2). The problem your are seeing is related to a change that was introduced in the Xilinx tools (I believe from version 11 to 12) that increased the minimum frequency of the
Re: [casper] adc5g block run at 2500MHz
Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the meantime, the changes (along with LOTS of other modifications to other parts of the library) are in my repo at https://github.com/jack-h/mlib_devel Alternatively, if you've got the latest mlib_devel from sma-wideband, you can apply the patch I emailed using the command (run within the repository) git apply /path/to/adc5g-mmcm.patch Cheers, Jack On 15 January 2014 20:24, Weiwei Sun su...@uw.edu wrote: Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project. Thanks! Best, Weiwei On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish jackhick...@gmail.com wrote: On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from the ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a per-bit calibration anyway. With IODELAY calibration only (without bothering with the MMCM phase) so far I haven't had any glitches in 2 hours of running. Strangely, when I ran the MMCM phasing calibration after IODELAY cal, things got worse, but I've been wildly hacking software, so there's a very reasonable chance I've broken something. I'll look into this after I've let my current glitch counting test run for a bit longer. I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Our git repos seem to have diverged quite a lot, but I've attached a patch to peruse/edit/merge at your leisure. Obviously, YMMV :) Cheers, Jack Thanks! Rurik On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are just dumping data to a snapshot. I believe a ROACH-2 is harder to reach timing. Ross On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish jackhick...@gmail.com wrote: Hi all, Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a simple ADC to snap model, and (as Rurik warned) getting reliable data capturing is difficult at this speed. I've tried per-bit calibration of input data streams via IODELAYs in conjunction with phase-shifting of the sampling clock, but can't seem to achieve glitchless data capture for any reasonable length of time. In the email I'm replying to, Rurik suggests a number of ways around this problem, but before I opt for forcing an unsupported MMCM mode by compiling and running at different speeds, I thought a final desperate plea for any advice on the maillist might be worthwhile. If anyone has any words of
Re: [casper] adc5g block run at 2500MHz
Oh, that's clear! I followed it and got the design compiled successfully in Simulink. Thanks Jack! Best, Weiwei On Wed, Jan 15, 2014 at 12:35 PM, Jack Hickish jackhick...@gmail.comwrote: Hi Weiwei, I'll leave it up to Rurik to merge or not the changes into sma-wideband, but in the meantime, the changes (along with LOTS of other modifications to other parts of the library) are in my repo at https://github.com/jack-h/mlib_devel Alternatively, if you've got the latest mlib_devel from sma-wideband, you can apply the patch I emailed using the command (run within the repository) git apply /path/to/adc5g-mmcm.patch Cheers, Jack On 15 January 2014 20:24, Weiwei Sun su...@uw.edu wrote: Hi Jack and Rurik, I'm very excited to hear that the adc could run at exact 5GSPS mode (2 channels, demux 1:1) . I'd like to follow the modification, but the vhdl is something that I'm not familiar. I wonder if it is possible that the module could be merged into the sma-wideband github, or help with some more details to instruct me to make the modification. That would be a BIG help for my project. Thanks! Best, Weiwei On Wed, Jan 15, 2014 at 9:53 AM, Jack Hickish jackhick...@gmail.com wrote: On 15 January 2014 16:28, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Jack, Great work! The oversample mode is not something I realized existed! Me neither -- I eventually stumbled across it in the SelectIO Resources guide. (Where the order of the SERDES module outputs are documented wrongly, just for extra fun) Previously when we've been able to get the tools to use HIGH bandwidth mode we could get away with just shifting the MMCM clock phase to remove glitches on the interface (i.e. no IODELAY adjustments). Have you tried just doing that? I've run your calibration routine to look at the glitches vs. phase values and it seems to find reasonably wide glitchless regions. But I find the differences between the slowest and fastest bits from the ADC to be around 4 IODELAY taps (312ps), so it seemed worth doing a per-bit calibration anyway. With IODELAY calibration only (without bothering with the MMCM phase) so far I haven't had any glitches in 2 hours of running. Strangely, when I ran the MMCM phasing calibration after IODELAY cal, things got worse, but I've been wildly hacking software, so there's a very reasonable chance I've broken something. I'll look into this after I've let my current glitch counting test run for a bit longer. I'd like to merge your change into sma-wideband, could you perhaps send me a Github pull request? Our git repos seem to have diverged quite a lot, but I've attached a patch to peruse/edit/merge at your leisure. Obviously, YMMV :) Cheers, Jack Thanks! Rurik On Wed, Jan 15, 2014 at 7:51 AM, Jack Hickish jackhick...@gmail.com wrote: Hi Ross, Thanks for the info -- I've actually got a 5 Gsps ROACH2 (demux 1:1) pocket correlator compiled, and the final piece of the puzzle was getting the ADCs running properly (I only got hold of the hardware relatively recently). But it's always reassuring to know someone else is using a similar system with success! For anyone that's interested, I think I may have solved my problem. I changed the adc interface to use SERDES blocks in oversampling mode, which allowed me to dispense with the high frequency MMCM output. Without this troublesome output, the MMCM can be set into high bandwidth mode and the data capture seems to perform much more happily. After this mod, and setting the IODELAY blocks appropriately, the ADC appears to be capturing data happily without any problems Cheers, Jack On 14 January 2014 18:18, Ross Williamson rwilliam...@astro.caltech.edu wrote: Hi Jack, Not sure this helps as I'm using two DMUX 2:1 at 4GSPS as a correlator on a ROACH-1. The only think I would say is that I've put a fair amount of effort in planahead to try and get 5GSPS. I'm sure it could be done and I've thought I've got close a number of times but in the end I've just eaten that 500MHz of BW as too much effort for the little gain it gives in receiver noise. I would say that on a Roach-1, two boards at 5GSPS (4-bit) works fine if you are just dumping data to a snapshot. I believe a ROACH-2 is harder to reach timing. Ross On Tue, Jan 14, 2014 at 8:11 AM, Jack Hickish jackhick...@gmail.com wrote: Hi all, Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a simple ADC to snap model, and (as Rurik warned) getting reliable data capturing is difficult at this speed. I've tried per-bit calibration of input data streams via IODELAYs in conjunction with phase-shifting of the sampling clock, but can't seem to achieve glitchless data capture for any reasonable
Re: [casper] adc5g block run at 2500MHz
Hi all,
Like Weiwei, I'm trying to use the ADC5g at 5 Gsps. I've played with a
simple ADC to snap model, and (as Rurik warned) getting reliable data
capturing is difficult at this speed. I've tried per-bit calibration
of input data streams via IODELAYs in conjunction with phase-shifting
of the sampling clock, but can't seem to achieve glitchless data
capture for any reasonable length of time.
In the email I'm replying to, Rurik suggests a number of ways around
this problem, but before I opt for forcing an unsupported MMCM mode by
compiling and running at different speeds, I thought a final desperate
plea for any advice on the maillist might be worthwhile. If anyone has
any words of wisdom, I'd be excessively grateful to hear from them.
Cheers,
Jack
On 6 November 2013 16:31, Primiani, Rurik rprimi...@cfa.harvard.edu wrote:
Hi Weiwei,
Generally the sma-wideband/mlib_devel has the most recent changes to
the ADC5g yellow block, please use the latest commit of that repo (at
this moment it is 2c80cb2).
The problem your are seeing is related to a change that was introduced
in the Xilinx tools (I believe from version 11 to 12) that increased
the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125
MHz in HIGH bandwidth mode. This made it no longer possible to clock
the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH
bandwidth mode.
There are a few options for moving forward (ordered by ease of
implementation):
1. Clock the ADC below (and not including) 2400 MHz
2. Change MMCM from HIGH to LOW bandwidth mode
3. Compile your design with the ADC clocked above (and not including)
5400 MHz, but actually run it at 5 GHz
4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH
bandwidth mode
5. Compile your design using the Xilinx 11 tools
If you don't need to sample at exactly 5 Gsps then option 1 is the
optimal solution. If 5 Gsps is critical then you can go with options 2
or 3. Option 2 has non-ideal clock-to-out timing and may cause
problems when trying to calibrate out jitter due to the data
capturing. Option 3 may cause timing problems since your fabric clock
will run at 337.5 MHz. I have not found a way to implement option 4
but I can't see why this shouldn't be possible. Finally option 5 may
or may not be useful to you.
The SMA wideband correlator runs its ADCs below 4800 Msps. However we
have bitcodes that we use to characterize the ADC that run at 5 Gsps
and which have low resource utilization. For what it's worth we used
option 3 to get around this issue and this appears to work for us.
Whatever reason Xilinx had for changing the minimum PFD frequency to
135 MHz does not seem to cause problems for us.
Hope this helps,
Rurik
On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun su...@uw.edu wrote:
I tried the casper-astro, ska-sa, sma-wideband. None of them seemly works.
Weiwei
On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik rprimi...@cfa.harvard.edu
wrote:
Hi,
Which version of mlib_devel are you using?
Rurik
On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun su...@uw.edu wrote:
Hi,
I have trouble to compile the adc clock rate of asiaa_adc5g block at
2500MHz.
Block parameter: two-channel, ZDOK0, demux 1:1 .
System: roach2, clock source:adc0_clk, clock rate: 312.5MHz)
The error is as follows:
Creating block object: xps_adc5g
Problem with block: lab_test_adv5/asiaa_adc5g1
: An optimum PLL solution is not available!
Backtrace 1: xps_adc5g:175
Backtrace 2: gen_xps_files:229
Backtrace 3: run_Callback:149
Backtrace 4: casper_xps:82
Backtrace 5:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Error using gen_xps_files (line 242)
Error found during Object creation.
There are a bunch of frequency justification in the xps_adc5g.m that I
just
can't understand. Could some one give me some suggestions on the error
or
the codes? Does it mean that the 5G adc can't run at 2.5GHz?
Any help or suggestions are very appreciated!
Weiwei
Re: [casper] adc5g block run at 2500MHz
Hi Rurik,
I have a question of the adc5g yellow block. I can meet the time
requirement by relocating the adc pblock (ZDOK_0_1_1) in planahead (e.t.
modify the .ucf constrain file), but I'm not sure if I'm allowed to do so.
Maybe I should not move the pblocks, and come out other way to meet the
timing.
Weiwei
On Wed, Nov 6, 2013 at 10:11 AM, Primiani, Rurik
rprimi...@cfa.harvard.eduwrote:
Hi Weiwei,
In most cases, as long as you run your design below the
successfully-compiled-for clock rate, i.e. the clock rate at which the
Xilinx tools have guaranteed timing for you, you should be okay. This
is complicated by the fact that the clock goes through an MMCM which
has various parameters that may not work at a lower rate. However for
the two clock-rates I mentioned before I have verified the ADC5g to
work correctly. Note: you may need to compile for slightly above 5400
Msps because the Xilinx tools have issues with rounding clock periods.
In our test designs we use 5408 MHz which corresponds to an input
frequency of 2704 MHz (the value you put into the yellow block).
I'll just reiterate that running the MMCM's PFD at an unapproved
frequency may present other problems in the future! Thankfully we
haven't run into any problems so far in our testing.
Additionally if your design starts to use a significant amount of
resources you will start having trouble meeting timing.. just a
warning!
Best,
Rurik
On Wed, Nov 6, 2013 at 12:51 PM, Weiwei Sun su...@uw.edu wrote:
We are hoping to run it at 5GHz for the our need, so I'll try the option
2
3 first. I have a question about the option 3: How does the fpga/adc
actually work if the design and running are at different clock rate?
Thanks very much Rurik! Your suggestions are really helpful to me to dig
into the problem.
Weiwei
On Wed, Nov 6, 2013 at 8:31 AM, Primiani, Rurik
rprimi...@cfa.harvard.edu
wrote:
Hi Weiwei,
Generally the sma-wideband/mlib_devel has the most recent changes to
the ADC5g yellow block, please use the latest commit of that repo (at
this moment it is 2c80cb2).
The problem your are seeing is related to a change that was introduced
in the Xilinx tools (I believe from version 11 to 12) that increased
the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125
MHz in HIGH bandwidth mode. This made it no longer possible to clock
the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH
bandwidth mode.
There are a few options for moving forward (ordered by ease of
implementation):
1. Clock the ADC below (and not including) 2400 MHz
2. Change MMCM from HIGH to LOW bandwidth mode
3. Compile your design with the ADC clocked above (and not including)
5400 MHz, but actually run it at 5 GHz
4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH
bandwidth mode
5. Compile your design using the Xilinx 11 tools
If you don't need to sample at exactly 5 Gsps then option 1 is the
optimal solution. If 5 Gsps is critical then you can go with options 2
or 3. Option 2 has non-ideal clock-to-out timing and may cause
problems when trying to calibrate out jitter due to the data
capturing. Option 3 may cause timing problems since your fabric clock
will run at 337.5 MHz. I have not found a way to implement option 4
but I can't see why this shouldn't be possible. Finally option 5 may
or may not be useful to you.
The SMA wideband correlator runs its ADCs below 4800 Msps. However we
have bitcodes that we use to characterize the ADC that run at 5 Gsps
and which have low resource utilization. For what it's worth we used
option 3 to get around this issue and this appears to work for us.
Whatever reason Xilinx had for changing the minimum PFD frequency to
135 MHz does not seem to cause problems for us.
Hope this helps,
Rurik
On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun su...@uw.edu wrote:
I tried the casper-astro, ska-sa, sma-wideband. None of them seemly
works.
Weiwei
On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik
rprimi...@cfa.harvard.edu
wrote:
Hi,
Which version of mlib_devel are you using?
Rurik
On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun su...@uw.edu wrote:
Hi,
I have trouble to compile the adc clock rate of asiaa_adc5g block
at
2500MHz.
Block parameter: two-channel, ZDOK0, demux 1:1 .
System: roach2, clock source:adc0_clk, clock rate: 312.5MHz)
The error is as follows:
Creating block object: xps_adc5g
Problem with block: lab_test_adv5/asiaa_adc5g1
: An optimum PLL solution is not available!
Backtrace 1: xps_adc5g:175
Backtrace 2: gen_xps_files:229
Backtrace 3: run_Callback:149
Backtrace 4: casper_xps:82
Backtrace 5:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Error using gen_xps_files (line 242)
Error found during
Re: [casper] adc5g block run at 2500MHz
Hi Weiwei, Removing that pblock is fine if you are using Rev. 2 of the ROACH2 (which is the default). That pblock is unfortunately left over from the Rev. 1 days and should probably be removed... or at least only conditionally added depending on what revision is being targeted. Best, Rurik On Fri, Nov 8, 2013 at 7:34 PM, Weiwei Sun su...@uw.edu wrote: Hi Rurik, I have a question of the adc5g yellow block. I can meet the time requirement by relocating the adc pblock (ZDOK_0_1_1) in planahead (e.t. modify the .ucf constrain file), but I'm not sure if I'm allowed to do so. Maybe I should not move the pblocks, and come out other way to meet the timing. Weiwei On Wed, Nov 6, 2013 at 10:11 AM, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Weiwei, In most cases, as long as you run your design below the successfully-compiled-for clock rate, i.e. the clock rate at which the Xilinx tools have guaranteed timing for you, you should be okay. This is complicated by the fact that the clock goes through an MMCM which has various parameters that may not work at a lower rate. However for the two clock-rates I mentioned before I have verified the ADC5g to work correctly. Note: you may need to compile for slightly above 5400 Msps because the Xilinx tools have issues with rounding clock periods. In our test designs we use 5408 MHz which corresponds to an input frequency of 2704 MHz (the value you put into the yellow block). I'll just reiterate that running the MMCM's PFD at an unapproved frequency may present other problems in the future! Thankfully we haven't run into any problems so far in our testing. Additionally if your design starts to use a significant amount of resources you will start having trouble meeting timing.. just a warning! Best, Rurik On Wed, Nov 6, 2013 at 12:51 PM, Weiwei Sun su...@uw.edu wrote: We are hoping to run it at 5GHz for the our need, so I'll try the option 2 3 first. I have a question about the option 3: How does the fpga/adc actually work if the design and running are at different clock rate? Thanks very much Rurik! Your suggestions are really helpful to me to dig into the problem. Weiwei On Wed, Nov 6, 2013 at 8:31 AM, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi Weiwei, Generally the sma-wideband/mlib_devel has the most recent changes to the ADC5g yellow block, please use the latest commit of that repo (at this moment it is 2c80cb2). The problem your are seeing is related to a change that was introduced in the Xilinx tools (I believe from version 11 to 12) that increased the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125 MHz in HIGH bandwidth mode. This made it no longer possible to clock the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH bandwidth mode. There are a few options for moving forward (ordered by ease of implementation): 1. Clock the ADC below (and not including) 2400 MHz 2. Change MMCM from HIGH to LOW bandwidth mode 3. Compile your design with the ADC clocked above (and not including) 5400 MHz, but actually run it at 5 GHz 4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH bandwidth mode 5. Compile your design using the Xilinx 11 tools If you don't need to sample at exactly 5 Gsps then option 1 is the optimal solution. If 5 Gsps is critical then you can go with options 2 or 3. Option 2 has non-ideal clock-to-out timing and may cause problems when trying to calibrate out jitter due to the data capturing. Option 3 may cause timing problems since your fabric clock will run at 337.5 MHz. I have not found a way to implement option 4 but I can't see why this shouldn't be possible. Finally option 5 may or may not be useful to you. The SMA wideband correlator runs its ADCs below 4800 Msps. However we have bitcodes that we use to characterize the ADC that run at 5 Gsps and which have low resource utilization. For what it's worth we used option 3 to get around this issue and this appears to work for us. Whatever reason Xilinx had for changing the minimum PFD frequency to 135 MHz does not seem to cause problems for us. Hope this helps, Rurik On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun su...@uw.edu wrote: I tried the casper-astro, ska-sa, sma-wideband. None of them seemly works. Weiwei On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik rprimi...@cfa.harvard.edu wrote: Hi, Which version of mlib_devel are you using? Rurik On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun su...@uw.edu wrote: Hi, I have trouble to compile the adc clock rate of asiaa_adc5g block at 2500MHz. Block parameter: two-channel, ZDOK0, demux 1:1 . System: roach2, clock source:adc0_clk, clock rate: 312.5MHz) The error is as follows: Creating block object: xps_adc5g Problem with block:
Re: [casper] adc5g block run at 2500MHz
Hi Weiwei,
In most cases, as long as you run your design below the
successfully-compiled-for clock rate, i.e. the clock rate at which the
Xilinx tools have guaranteed timing for you, you should be okay. This
is complicated by the fact that the clock goes through an MMCM which
has various parameters that may not work at a lower rate. However for
the two clock-rates I mentioned before I have verified the ADC5g to
work correctly. Note: you may need to compile for slightly above 5400
Msps because the Xilinx tools have issues with rounding clock periods.
In our test designs we use 5408 MHz which corresponds to an input
frequency of 2704 MHz (the value you put into the yellow block).
I'll just reiterate that running the MMCM's PFD at an unapproved
frequency may present other problems in the future! Thankfully we
haven't run into any problems so far in our testing.
Additionally if your design starts to use a significant amount of
resources you will start having trouble meeting timing.. just a
warning!
Best,
Rurik
On Wed, Nov 6, 2013 at 12:51 PM, Weiwei Sun su...@uw.edu wrote:
We are hoping to run it at 5GHz for the our need, so I'll try the option 2
3 first. I have a question about the option 3: How does the fpga/adc
actually work if the design and running are at different clock rate?
Thanks very much Rurik! Your suggestions are really helpful to me to dig
into the problem.
Weiwei
On Wed, Nov 6, 2013 at 8:31 AM, Primiani, Rurik rprimi...@cfa.harvard.edu
wrote:
Hi Weiwei,
Generally the sma-wideband/mlib_devel has the most recent changes to
the ADC5g yellow block, please use the latest commit of that repo (at
this moment it is 2c80cb2).
The problem your are seeing is related to a change that was introduced
in the Xilinx tools (I believe from version 11 to 12) that increased
the minimum frequency of the Virtex-6 MMCM's PFD to 135 MHz from 125
MHz in HIGH bandwidth mode. This made it no longer possible to clock
the fabric from an ADC5g running at 4800 Msps using an MMCM in HIGH
bandwidth mode.
There are a few options for moving forward (ordered by ease of
implementation):
1. Clock the ADC below (and not including) 2400 MHz
2. Change MMCM from HIGH to LOW bandwidth mode
3. Compile your design with the ADC clocked above (and not including)
5400 MHz, but actually run it at 5 GHz
4. Force the Xilinx tools to allow the PFD to run at 125 MHz in HIGH
bandwidth mode
5. Compile your design using the Xilinx 11 tools
If you don't need to sample at exactly 5 Gsps then option 1 is the
optimal solution. If 5 Gsps is critical then you can go with options 2
or 3. Option 2 has non-ideal clock-to-out timing and may cause
problems when trying to calibrate out jitter due to the data
capturing. Option 3 may cause timing problems since your fabric clock
will run at 337.5 MHz. I have not found a way to implement option 4
but I can't see why this shouldn't be possible. Finally option 5 may
or may not be useful to you.
The SMA wideband correlator runs its ADCs below 4800 Msps. However we
have bitcodes that we use to characterize the ADC that run at 5 Gsps
and which have low resource utilization. For what it's worth we used
option 3 to get around this issue and this appears to work for us.
Whatever reason Xilinx had for changing the minimum PFD frequency to
135 MHz does not seem to cause problems for us.
Hope this helps,
Rurik
On Wed, Nov 6, 2013 at 2:29 AM, Weiwei Sun su...@uw.edu wrote:
I tried the casper-astro, ska-sa, sma-wideband. None of them seemly
works.
Weiwei
On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik
rprimi...@cfa.harvard.edu
wrote:
Hi,
Which version of mlib_devel are you using?
Rurik
On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun su...@uw.edu wrote:
Hi,
I have trouble to compile the adc clock rate of asiaa_adc5g block at
2500MHz.
Block parameter: two-channel, ZDOK0, demux 1:1 .
System: roach2, clock source:adc0_clk, clock rate: 312.5MHz)
The error is as follows:
Creating block object: xps_adc5g
Problem with block: lab_test_adv5/asiaa_adc5g1
: An optimum PLL solution is not available!
Backtrace 1: xps_adc5g:175
Backtrace 2: gen_xps_files:229
Backtrace 3: run_Callback:149
Backtrace 4: casper_xps:82
Backtrace 5:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Error using gen_xps_files (line 242)
Error found during Object creation.
There are a bunch of frequency justification in the xps_adc5g.m that
I
just
can't understand. Could some one give me some suggestions on the
error
or
the codes? Does it mean that the 5G adc can't run at 2.5GHz?
Any help or suggestions are very appreciated!
Weiwei
Re: [casper] adc5g block run at 2500MHz
Hi,
Which version of mlib_devel are you using?
Rurik
On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun su...@uw.edu wrote:
Hi,
I have trouble to compile the adc clock rate of asiaa_adc5g block at
2500MHz.
Block parameter: two-channel, ZDOK0, demux 1:1 .
System: roach2, clock source:adc0_clk, clock rate: 312.5MHz)
The error is as follows:
Creating block object: xps_adc5g
Problem with block: lab_test_adv5/asiaa_adc5g1
: An optimum PLL solution is not available!
Backtrace 1: xps_adc5g:175
Backtrace 2: gen_xps_files:229
Backtrace 3: run_Callback:149
Backtrace 4: casper_xps:82
Backtrace 5:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Error using gen_xps_files (line 242)
Error found during Object creation.
There are a bunch of frequency justification in the xps_adc5g.m that I just
can't understand. Could some one give me some suggestions on the error or
the codes? Does it mean that the 5G adc can't run at 2.5GHz?
Any help or suggestions are very appreciated!
Weiwei
Re: [casper] adc5g block run at 2500MHz
I tried the casper-astro, ska-sa, sma-wideband. None of them seemly works.
Weiwei
On Tue, Nov 5, 2013 at 10:20 PM, Primiani, Rurik
rprimi...@cfa.harvard.eduwrote:
Hi,
Which version of mlib_devel are you using?
Rurik
On Tue, Nov 5, 2013 at 11:16 PM, Weiwei Sun su...@uw.edu wrote:
Hi,
I have trouble to compile the adc clock rate of asiaa_adc5g block at
2500MHz.
Block parameter: two-channel, ZDOK0, demux 1:1 .
System: roach2, clock source:adc0_clk, clock rate: 312.5MHz)
The error is as follows:
Creating block object: xps_adc5g
Problem with block: lab_test_adv5/asiaa_adc5g1
: An optimum PLL solution is not available!
Backtrace 1: xps_adc5g:175
Backtrace 2: gen_xps_files:229
Backtrace 3: run_Callback:149
Backtrace 4: casper_xps:82
Backtrace 5:
@(hObject,eventdata)casper_xps('run_Callback',hObject,eventdata,guidata(hObject)):0
Error using gen_xps_files (line 242)
Error found during Object creation.
There are a bunch of frequency justification in the xps_adc5g.m that I
just
can't understand. Could some one give me some suggestions on the error
or
the codes? Does it mean that the 5G adc can't run at 2.5GHz?
Any help or suggestions are very appreciated!
Weiwei
