Question on Virtex2p DCMs usability

Greetings,

First off, let me share with you that I'm a complete newb when it comes to FPGA/ISE/VHDL. I'm using the "free" version of ISE and my end device is a V2P-7 672 pin FPGA with the pins already locked and unchangable on a custom board. I'm using VHDL.

The issue I'm trying to deal with is deserializing an 8 bit serial line from a clock rate of 1MHz upto 40MHz (bit rate of 8MHz to 320MHz) with the ability to switch which incoming clocks to use as the master deserializer clock. The deserializer I'm using is a portion of XAPP265 from XILINX, mainly just the flipflop section (not the block ram or DCM section).

The first problem is the wide range of clock rates I need to program for. The 2nd issue deals with the fact that the "SYNC" clock may be unstable depending on the DUT and I will want to switch to a secondary SYNC clock if that's the case. The 2nd problem is how to implement the DCMs using as few of them as possible.

The following is a description of the FPGA inputs: These 2 signals come directly from the DUT SYNC - The 1MHz to 40MHz clock from the device under test (DUT) which can sometimes be unstable INPUT - The 8MHz to 320MHz data word which I want to deserialize These 2 signals come from a clock generator which can be used in place of the SYNC if the SYNC clock is too unstable for deserializing PCLK - Optional 1MHz to 40MHz clock from external clock generator to be used instead of SYNC if necessary (on different pins from SYNC). CLK4x - Optional 4x of PCLK clock which is used as a DDR clock to deserialize data from INPUT if SYNC is too unstable

Here is my current approach: If the DUT is operating at slow speeds (SYNC < 24MHz), I use the CLK4x input as my DDR clock because the DCM can't generate the 4x clock from the SYNC clock. I may optionally switch out the SYNC clock for the PCLK if the SYNC clock is too unstable. This is currently one build of the FPGA code and it appears to work fine. No DCMs are used in this build.

My next approach is to figure out how to combine the slow and high speed options but am not sure the best way to approach this. I want to have a command protocol between my computer and the FPGA to be able to tell the FPGA if the DUT will be operating in SLOW or HIGHSPEED mode and command which clock, SYNC or PCLK to use.. HIGHSPEED mode will first try to use the SYNC clock and generate a 4xSYNC clock to use as the DDR clock, but if that fails due to SYNC instability, use the PCLK in place of the SYNC.

I'm thinking I need at least 2 DCMs to do this. One to phase shift the SYNC/PCLK signal since I can't get the PCLK to have 0 phase relation with the SYNC clock externally and another DCM to generate a phase shiftable 4x clock from the SYNC/PCLK clock. I'm thinking of using a mux to switch between PCLK and the SYNC clock to the input of the both DCMs and a mux to switch in either the external CLK4x or the DCM generated CLK4x to operate as the DDR clock.

Will this approach work? Is there a better way to do this? How can I tell the DCM which frequency it'll be operating at (the DCM pixel period generic) and is that generic really necessary?

Thanks, Jason

Reply to
Jason Whitwam
Loading thread data ...

With such a wide range of clock rates, a DCM-based solution does sound a little awkward. If possible, you might want to consider using a single high-frequency clock on the FPGA (say around

400 MHz) to sample both data and incoming clock. A state machine (effectively a PLL) could then watch for edges on the incoming clock to know which samples of the data signal to pay attention to. Probably you'll want two or four phases of the FPGA clock to get enough timing resolution for good sampling of the incoming signals; a DCM would be convenient to generate those phases.

An MGT would also make a good sampler/deserializer at some fixed high rate, but since you say your pinout is fixed, it's probably not an option for you.

Cheers, Peter Monta

Reply to
Peter Monta

If your sync becomes unstable, what do you expect for the behavior of your circuit to be before and into the switchover to a stable clock?

Is the determination of sync stability an issue only when communication is first established?

If the sync is occasionally unstable and you must design for the unstable case, is there a reason to include the sync in the circuit design?

Only question at this point so that answers may come more readily.

Reply to
John_H

Hi Peter,

Thanks for the advice. One question I have about this approach is how do I determine which sampled data is bit1, bit2, etc?

Thanks, Jason

Reply to
Jason Whitwam

Hi John,

If a DUTs SYNC clock is unstable then the tester will send a command to the FPGA to switch to the stable clock and this clock will be used always for this particular DUT. I'm not planning any logic to automatically switch between the two. The test engineer will determine if the SYNC clock is unstable, not the FPGA.

The reason why I want to try to use the SYNC clock rather than always use the "always" stable clock is:

- I want to find DUTs which are working fine, meaning a stable SYNC clock because that's the clock which will be used in the final system.

- If the SYNC clock is unstable, I still wish to be able to test the DUTs other functions to find any other issues and to gather reliability data to help improve the design of future ASICs.

I hope that helps.

Thanks, Jason

Reply to
Jason Whitwam

Bit order and link protocol are design decisions. The data packets must be delineated somehow. HDLC requires bit stuffing to eliminate flag patterns in the data. Start-bit / stop-bit is simpler, but requires a fixed packet width.

See the reference design here

formatting link
for a start-bit protocol example.

-- Mike Treseler

Reply to
Mike Treseler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.