You are not logged in.
Someone else wrote:
I'm trying to come to terms with getting a system hooked up with the following key parameters:
Processor Clock: 200MHz
OPB Clock: 100MHz
Radio ADCs: 50MHz
Sample Rate: 25MHz
To do this, I've got a DCM spitting out sys_clk_s at 100MHz, driving some custom pcores. Inside one of those pcores. I've got a 1:4 counter spitting at 100/4 = 25MHz to the RSSI ADC clocks on the bridge. My question is this: what is the converter clock input on the bridge? I've tried it at both the default (sys_clk_s = 100MHz) and manually hooked up to a new net from the CLKDV output running at 50MHz. Neither seems to give me a reasonable RSSI signal. Any help getting my head around these different clocks would be greatly appreciated
Offline
The converter clock input is the signal the bridge drives out to the Tx DAC and Rx ADC. The same clock is used to capture data arriving from the ADC in registers inside the bridge. This clock must be synchronous with whatever block uses the user_ADC and user_DAC signals (i.e. there's no buffering in the bridge; the user has to handle a new sample every cycle of converter_clock_in). The converters must run between 32-65MHz.
The RSSI clock signal must be driven separately via the user_RSSI_clk port on the bridge. It also needs to be synchronous with converter_clock_in (the RSSI data and clock both get registered by converter_clock_in in the IOBs). The maximum RSSI ADC clock rate is 20MHz. I suspect you're seeing screwy RSSI values because the RSSI ADC is being over-clocked.
Offline
Can you briefly describe the interplay between the FPGA-generated clocks (like the bus clock, various ADC/DACs, etc.) and the physical reference for the radio (clock-board)?
My current understanding is that the reference from the clock board feeds some internal PLL in the radio, allowing the MAX2829 to produce and accept the proper analog signals (RSSI, I, Q, etc.). These signals feed external ADCs and DACs that are clocked by the FPGA. As such, the clock board's frequency is independent of the particular project's clock selection. Is this correct? Thanks!
Offline
It's fair to treat these two clocks (radio reference clock and analog converter clock) as independent. The radio reference clock is used soley by the MAX2829 to generate the RF carrier. The FPGA does not get a copy of this clock. The clock board uses a high-quality TCXO to provide a clean reference clock to each radio board.
The MAX2829 does not get a copy of the converter clock; its digital inputs are asynchronous (except for its serial control interface, which has its own clock, produced by the radio controller pcore).
In all of our projects, the analog converter clock is synchrnous with one of the FPGA's bus clocks. This is an articaft of our projects' reliance on cores generated by System Generator. Sysgen cores generally have a single clock input; everything in the core is driven by the same clock, and synchronous clock enables are used to achieve various sampling rates. Since our Sysgen cores are attached to both the OPB and the radio's converters, we must use a bus clock (or some deritative) to drive the analog converters.
It would be possible to build a core with two (potentially asynchronous) clock domains- one for the analog interface, one for the bus interface. In such a setup, the analog converter clock could be driven by an independent clock.
Offline
In the post http://warp.rice.edu/forums/viewtopic.php?id=18,
murphpo wrote:
Future distributions of the FPGA board will include a centralized clock circuit. This circuit will provide five copies of a very clean 40MHz clock. One is driven into a global clock pin on the FPGA. The other four are used to drive the ADC/DACs on radio boards via board-to-board cables (not via traces on the FPGA board). All other clocks in the FPGA can be derived from this 40 MHz input, allowing a PHY (in logic) and the PowerPC processor to operate synchronously with the ADC/DACs. It will still be possible to use the 100 MHz oscillator in other parts of the FPGA.
When is this future distribution? Is this the version with a clock distribution board and going to send out to WARP users?
The question here is why you need to make this modification? Isn't it easier to let radio_bridge drive the ADC/DAC as what has been implemented? As you point out in the above
murphpo wrote:
The converter clock input is the signal the bridge drives out to the Tx DAC and Rx ADC. The same clock is used to capture data arriving from the ADC in registers inside the bridge. This clock must be synchronous with whatever block uses the user_ADC and user_DAC signals (i.e. there's no buffering in the bridge; the user has to handle a new sample every cycle of converter_clock_in). The converters must run between 32-65MHz.
My feeling is that, if ADC/DAC is driven by a clock signal not coming from the FPGA, it is hard to guarantee the FPGA pcore is in sync with ADC/DAC. Even all clocks are orignated from the same oscillator, some pass through FPGA's digital circuitry, while others stay outside FPGA.
Offline
We're wokring on the build of clock boards with two oscillators (radio reference and converter clock) now. These will be provided for users with existing kits and included in new kits.
The motivation for this design is to drive the analog converters with a very low jitter clock signal. Using the FPGA to drive the clock introduces significant jitter, reducing the realized SNR at the DACs and ADCs. The AD9248 datasheet has a good discussion of the SNR consequences of clock jitter (see pg 18).
zrcao wrote:
My feeling is that, if ADC/DAC is driven by a clock signal not coming from the FPGA, it is hard to guarantee the FPGA pcore is in sync with ADC/DAC. Even all clocks are orignated from the same oscillator, some pass through FPGA's digital circuitry, while others stay outside FPGA.
As long as the phase relationship between the clock at the ADC/DAC and at the FPGA IOBs is deterministic (and it is, since it's just a funciton of the propogation delays through the various buffers), we can easily constrain the timing of the synchronous I/O. If the delays line up such that a setup/hold problem would occur, a DCM can provide a clock for the FPGA with whatever phase shift is needed to avoid problems. We'll post a reference design which uses the clock board's sampling clock which will demonstrate all of this.
Offline