q2418130103p
Newbie level 6
Hello everyone,
I apologize for the vague title, but I had a few questions and I figured I would roll them into one thread.
I am working on a 'high-speed' cpld design. I put 'high-speed' in quotes since I seem to be in this nebulous region between regular speed and true high-speed.
The design will be interfacing, configuring, controlling and serializing data from a multichannel ADC. There will be a bunch of channels, sampled at a few different rates, there is a large disparity between the required sample rates of the fastest and slowest signals. I am estimating that there will be 10-20 Mbits worth of data being sent serially over a fiber, including an embedded clock (probably Manchester encoding or something similar). There will be a cpld on the receiving end as well. It will perform the separation of the clock and the data. So with 10x over sampling the clock would need to be between 80MHz and 160MHz on the receiving end. The resulting data and clock will go into another device for processing.
So my questions:
1) It seems that clocks up around the 150MHz range are mostly available in differential signaling forms. That would make sense, but what do people usually do in the case of a coolrunner-ii, which doesnt support differential signaling. I have found the occasional device like this one: Vectron Products - Standard Crystal Oscillators (XO) - VCC1 , which supports TTLCMOS. I just dont want to get myself into trouble by using something that doesnt appear to be typical This appears to also be the case with most optical transceivers.
2) Do I forget about a 160MHz clock and just say that if I need a clock that fast then I should just use an 80MHz clock and a frequency doubler? (A dual edge flip-flop available on the coolrunner-ii)
3) Can anyone suggest a better method for what I am doing?
4) Is getting an adjustable clock dangerous for any reason? It would be nice to have a clock which would could be adjusted via SPI or I2C, just in case the design changes, or needs to be re-implemented for something else.
Thanks,
Jay
I apologize for the vague title, but I had a few questions and I figured I would roll them into one thread.
I am working on a 'high-speed' cpld design. I put 'high-speed' in quotes since I seem to be in this nebulous region between regular speed and true high-speed.
The design will be interfacing, configuring, controlling and serializing data from a multichannel ADC. There will be a bunch of channels, sampled at a few different rates, there is a large disparity between the required sample rates of the fastest and slowest signals. I am estimating that there will be 10-20 Mbits worth of data being sent serially over a fiber, including an embedded clock (probably Manchester encoding or something similar). There will be a cpld on the receiving end as well. It will perform the separation of the clock and the data. So with 10x over sampling the clock would need to be between 80MHz and 160MHz on the receiving end. The resulting data and clock will go into another device for processing.
So my questions:
1) It seems that clocks up around the 150MHz range are mostly available in differential signaling forms. That would make sense, but what do people usually do in the case of a coolrunner-ii, which doesnt support differential signaling. I have found the occasional device like this one: Vectron Products - Standard Crystal Oscillators (XO) - VCC1 , which supports TTLCMOS. I just dont want to get myself into trouble by using something that doesnt appear to be typical This appears to also be the case with most optical transceivers.
2) Do I forget about a 160MHz clock and just say that if I need a clock that fast then I should just use an 80MHz clock and a frequency doubler? (A dual edge flip-flop available on the coolrunner-ii)
3) Can anyone suggest a better method for what I am doing?
4) Is getting an adjustable clock dangerous for any reason? It would be nice to have a clock which would could be adjusted via SPI or I2C, just in case the design changes, or needs to be re-implemented for something else.
Thanks,
Jay
