Clock for serializer with a Spartan3

Which is the preferred way to generate the output clock for a deserializer made with a shift register? For example, let's say I feed a 4-bit shift register with a 500 MHz signal, so that I have to store four bits at 125 MHz into a BRAM (or just latch them). How do I generate this 125 MHz clock? I can't use a DCM because the input frequency is out of range, but if I generate the clock with common logic (e.g. a binary counter or a shift register), how can I be sure that it won't violate the hold/setup times in respect to the four output bits?

Thank you!

--
asd
Reply to
dalai lamah
Loading thread data ...

Howdy,

Two ways to solve this:

  1. If the 125 MHz "clock" isn't needed for a considerable amount of logic, strongly consider generating and using a clock enable that is actually in the 500 MHz domain.

  1. If you have a bunch of logic that needs to run at 125 MHz, the DCM has a CLKIN_DIVIDE_BY_2 mode to handle higher frequencies:

formatting link

Have fun,

Marc

Reply to
Marc Randolph

"Marc Randolph" schrieb im Newsbeitrag news: snipped-for-privacy@z14g2000cwz.googlegroups.com...

deserializer

clock?

in

formatting link

Marc,

I guess you did pay attention to the part selection of OP, Spartan-3

there is no way Spartan-3 DCM handles 500MHz, well there is one undocumented config bit of the DCM (aka ultra high freq mode) but I really dont know what it does... in all normal modes S3 DCM will not handle 500MHz in our actual measurements with S3 -4 speedgrade the DCM actually worked OK til 275MHz above that it failed.

now to the 500MHz clock in S3, I think this may just barely be useable, but to be hones I am little bit interested by what means this clock is entering the S3 logic fabric.

The highest clock I have measured in S3 fabric is around 420MHz (speed grade -4), the 420MHz is useable, but only in very limited routing area, basically all the 420MHz needs to be locked down into primitives or be implemented as hard macro.

I think that a VERY careful design may just work at 500MHz, but it really needs to be optimized and 'hard locked'. Xilinx max toggle speed for S3 is some 750MHz, 500 is very close to it.

Well if the 500MHz was not the clock freq but bitrate and dual data rate (2 clock edges) is being used then we get down to 250MHz what is more useable in Spartan-3

to the OP

if 500MHz deserializer is used then the design should run out of 250MHz the clock doubling should happen at OBUF DDR primitives.

The DCM can accept input freq as low as 1MHz is your input clock lower than that? if the input clock is highere than DCM range try using the clkindiv2 attribute

antti

Reply to
Antti Lukats

Un bel giorno Antti Lukats digitò:

But the CLKIN_DIVIDE_BY_2 attribute seems to be supported also by Spartan3!

I need to use the 500 MHz clock just for the shift registers that deserialize the data, i.e. four flip-flops for each bit (and sixteen bit in total). I've tried to add this clock constraint to my design and it compiled correctly, even without manual floorplanning. In theory, if we give credit to the S3 datasheet, they should go at least 100 MHz faster than that!

I'm very interested on this topic, I was believing that the datasheet specifications (and ISE map/par results) were realistic. If they aren't, I'd like to know it before I make the prototypes. :)

No, it's SDR. Actually it's the output of a MAX104, high-speed ADC (another problem will be interface its LVPECL 3V interface with S3 LVPECL_25, but one problem at a time :-)).

Uhm, I'm not sure what's your point; this is exactly the same advice that Marc gave me, but apparently in the first part of your message you didn't agree with that. :)

--
asd
Reply to
dalai lamah

Un bel giorno Marc Randolph digitò:

Thank you, I didn't notice this feature!

--
asd
Reply to
dalai lamah

Un bel giorno dalai lamah digitò:

This problem seems to be already solved: :-)

formatting link

I am always amazed on the quality of Xilinx answers database.

--
asd
Reply to
dalai lamah

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.