Setup Hold times for Cyclone IV Flops

[Altera_Forum]

Hi All, 

 I have looked in Cyclone IV Handbook and did not find T'su or T'hold for the flops. Is this info available somewhere? Can I safely assume t'hold to be zero?   I am also trying to co-relate the above missing info to the Clock Tree specs (mentioned in the Manual, under Core Performance specifications heading Table 1-24 in Manual). For my speed grade it lists the Performance as ~400MHz. (1/F'max = 2.5ns). Does this mean that the Flops in the device have a minimum T'su of 2.5 ns?  Thanks

[Altera_Forum]

I'm not sure if they're in the handbook or not. It probably is somewhat dependent on what input to the flop is used, i.e. data, clock enable, sync load, etc. In reality, these values are pretty useless by themselves, as the external delay differences between clock and data will be exponentially larger.(Are you asynchronously sampling data, and just trying to get an idea of how often it will go metastable? That's the only thing I can think of where these might be important). 

In TimeQuest, when you do setup and hold analysis, you will see a uTsu and uTh parameter. And the Tsu is not 2.5ns. It will probably be closer to 1/100th of that. That 2.5ns is how fast the clock tree can toggle and is independent of the FFs.

[Altera_Forum]

Hello Rysc, thanks for the reply. 

  Ref: (are you asynchronously sampling data, and just trying to get an idea of how often it will go metastable? that's the only thing i can think of where these might be important)      No, actually I am trying to Mux two data streams at 1x clock rate to a single stream at 2x clock rate. Both 1x and 2x clocks are phase (pos edge) aligned. Data is launched and latched by flops on respective domains.   I have an internally generated enable signal, which basically toggles on every pos edge of 2x clock. I use it to capture/mux the 1st and 2nd stream.   My concern is that the instance I am capturing the 2nd stream, at the same time (plus the Tco + Tpropagation delay from Source flop) the output of 2nd stream would be changing too. So my hold time at the latching flop would be Tco + T propagation delay – any positive clock skew on clk2x.     Higher this positive skew, lower available hold time.     Is this something which the tool can handle itself, or using a particular constraint would be recommended for a case like this?

[Altera_Forum]

Ref: that 2.5ns is how fast the clock tree can toggle and is independent of the ffs. 

 So clock tree is much slower than Tsu, cos it has the added burden of ensuring low skew between the farthest corners of the chip?  

[Altera_Forum]

TimeQuest handles all of this. You need to constrain your clocks coming in, the PLL if you have one, and might have some multicycles on paths that take multiple clock cycles(but the default analysis will be more restrictive, so if it passes that, it will pass with multicycles). Go to www.alterawiki.com, click on Popular Pages, and there is a TimeQuest User Guide I put together, which might be a good place to get started.

[Altera_Forum]

Since your clocks are in phase then you can do this: 

 process begin wait until clk_2x = '1'; if clk_1x = '1' then data_out <= data1; else data_out <= data2; end of; end process;

[Altera_Forum]

Hi kaz, 

 This won't synthesize... As a further precaution, I am re-timing both incoming data streams to 2x clk, when the 'enable' is high. This allows me to avoid sampling data on clk1x, while it is about to change.

[Altera_Forum]

To add some more fun to my design.. I have to take care of a case, where the 2x clock could be same as 1x clock :-)  

Then I use only one of the links...