What is micro Setup time?

[Altera_Forum]

Can anyone please explain what "micro setup time [uTsu]" means. 

 Thanks, AA

[Altera_Forum]

That's the setup and hold you learned in college, i.e. the amount of time before and after the .clk hits a register that the .data must be stable, or else the register could go metastable. They're small numbers dwarfed by the variance in data and clock delays getting to the register. For example, the uTsu of a register might be 150ps. After place and route, the data path to the register might be 1ns longer than the clock path. TimeQuest uses both of these to say your data needs to be available 1.15ns before the clock(at the I/O).

[HTork]

Continuing on this really old thread.

The is the information I get on setup slack in TimeQuest.

As you can see, micro setup time [uTsu], is added to the data required path, making the setup slack larger, not smaller.

Isn't this in contradiction to what is mentioned above.

Hope for some help to clearify this.

[sstrell]

uTsu is the silicon-based setup timing requirement. It is the latest time before the clock edge that the data must arrive. Look in the Waveform tab to see how it is used to designate the data required time. The timing report you've posted shows the latest data must arrive, taking uTsu into account, and based on the clock edge arriving at the destination register. Normally, I see this value as negative since it should be subtracted from when the clock arrives to calculate the required time. I'm not sure why it's positive in the screenshot. Can you post the waveform tab?

#iwork4intel

[HTork]

Here is the included Waveform. In the waveform it is written -0.018ns. But as you can see from the small arrow it is added to data required time.

Below follows verilog code, RTL view and Summary of Paths.

The design is compiled for the Cyclone10LP 10CL025YU256I7G.

It is path#1 (d1->d2) that is given in the waveform above and the Setup Slack details.

module Test01 (input clk, output ClockOut, output reg q);

reg d1; /* synthesis preserve */

reg d2; /* synthesis preserve */

assign ClockOut = clk;

always @ ( posedge (clk)) 

begin

if((q==1'b1)&(d2==1'b1)&(d1==1'b1))

begin

d1<=1'b0;

d2<=1'b0;

q<=1'b0;

end

else

begin

d1  <= 1'b1;

d2  <= d1;

q  <= d2 & 1'b1;

end

end

endmodule

[Altera_Forum]

What do mean by " So when we do a setup check on this path, the Data Arrival Path must get to the FPGA before the data required path's micro setup time(utsu)" 

 Thanks, AA

[Altera_Forum]

Where's that from? That's the technical answer, i.e. your data has to be at the register before the clock by the amount of the uTsu. That's just looking at the register. If you step back and look at data path and clock path, then you're looking at the whole picture, and that is what the Data Arrival Path and Data Required Path cover. (Those terms should be in the handbook or TQ documentation, but running "report_timing -setup ..." on any path in your design and looking at the Data Path tab should help understand Data Arrival and Data Required.)

[Altera_Forum]

Hello RySc, 

 That was from the "TimeQuest User Guide" that you had written. I read it more closely and it increased my understanding. I do have some confusion. I will post it here as and when I get the doubts.  When people say clock Domain[clock a] are they talking about all registers that have that particular clock [clock a] as input   Thanks, AA

[Altera_Forum]

Yes. (At least that's what I mean when I talk about a clock domain...)

[Altera_Forum]

And clock crossing means one particular data passing through register [fed by clock a] and another register [fed by clock b]

[Altera_Forum]

It important to track the data path clock propagation as well as the clock to out times of the part. The propagation time of the clock to part input helps the setup, whereas propagation time of data path hurts the setup time. This of course assumes that you aren't dealing with a bidirectional data bus. In that case skew on clock will help setup on one end and hurt it on the other end.:D 

 Not bad for a female ehh? I can even tell you how to measure setup and hold, though you should already know this from college if they still teach such basics anymore.

[Altera_Forum]

Basically from a practical aspect the best way to measure discrete setup of a board to understand the aspect inside the FPGA routes. Is to take a scope on a digital PCB and measure with to probes the clock (trigger) at the destination part with respect to the data (other probe). You want the data to arrive prior to the clock edge (setup time). Hence you see if you move your trigger (clock) probe closer to the source part and keep the probe of data at the destination end you will make your setup much worse because the data will arrive later to the clock edge. You therefore can improve setup on a one direction transfer by increasing propagation delay of the clock.

[Altera_Forum]

FPGA is similar to clock distribution as a PCB therefore you have the same issues. Most people will try to keep the clock skew down by using a global clock. Fast routes and local/global clocks are used on data that needs low skew as well across a broad spectrum of the part. One can use enables and pipelining to improve timing.