I think you mean "derive_pll_clocks" ?The Altera's SDC constraints have some sort of set_propagated_clocks
Yeah, that command, I don't use Altera much so I forgot what the command was.I think you mean "derive_pll_clocks" ?
Either a virtual clock (useful for source synchronous designs, my mistake I thought that was what you were describing in the first post), but if your design isn't source synchronous then just use the clock_x in the input constraint.What the "derive_pll_clocks" macro do is create the base clocks and the generated clocks.
But after all clocks are created, what clock do you think the data pin should be relative for set_input_delay?
Kind of surprised you've never looked at that before...it's typically the easiest way to determine if there is a common problem with a design that has a large number of paths failing timing.
Well,
the report I posted is usually my first (and last) port of call. If the launch clock isn't the same as the latch clock - it indicates a violation inside the same domain, something that mustn't be ignored.
What's the report name you refer to in Vivado?
Not sure what you are trying to tell me here.
Of course it is. And I'm not implying anything.I consider knowing exactly what it's adding up to be very important.
It's the normal report but with detailed timing enabled. At least that is what it used to be, in the older versions of QuartusI didn't find a report in Timequest like the one you mentioned in #8.
Startpoint: FF1 (rising edge-triggered flip-flop clocked by Clk)
Endpoint: FF2 (rising edge-triggered flip-flop clocked by Clk)
Path Group: Clk
Path Type: max
Point Incr Path
-----------------------------------------------------------
clock Clk (rise edge) 0.00 0.00
clock network delay (propagated) 1.10 * 1.10
FF1/CLK (fdef1a15) 0.00 1.10 r
FF1/Q (fdef1a15) 0.50 * 1.60 r
U2/Y (buf1a27) 0.11 * 1.71 r
U3/Y (buf1a27) 0.11 * 1.82 r
FF2/D (fdef1a15) 0.05 * 1.87 r
data arrival time 1.87
clock Clk (rise edge) 4.00 4.00
clock network delay (propagated) 1.00 * 5.00
FF2/CLK (fdef1a15) 5.00 r
library setup time -0.21 * 4.79
data required time 4.79
------------------------------------------------------------
data required time 4.79
data arrival time -1.87
------------------------------------------------------------
slack (MET) 2.92
It's the normal report but with detailed timing enabled. At least that is what it used to be, in the older versions of Quartus
And I'm referring to path reports like this that were output from tools like synopsys...
though this particular example doesn't have any of the routing delays as I think they are merged with the cell delays. At least for Xilinx they separate the routing and cell delays, so you can see the routing vs. logic delay ratio.Code:Startpoint: FF1 (rising edge-triggered flip-flop clocked by Clk) Endpoint: FF2 (rising edge-triggered flip-flop clocked by Clk) Path Group: Clk Path Type: max Point Incr Path ----------------------------------------------------------- clock Clk (rise edge) 0.00 0.00 clock network delay (propagated) 1.10 * 1.10 FF1/CLK (fdef1a15) 0.00 1.10 r FF1/Q (fdef1a15) 0.50 * 1.60 r U2/Y (buf1a27) 0.11 * 1.71 r U3/Y (buf1a27) 0.11 * 1.82 r FF2/D (fdef1a15) 0.05 * 1.87 r data arrival time 1.87 clock Clk (rise edge) 4.00 4.00 clock network delay (propagated) 1.00 * 5.00 FF2/CLK (fdef1a15) 5.00 r library setup time -0.21 * 4.79 data required time 4.79 ------------------------------------------------------------ data required time 4.79 data arrival time -1.87 ------------------------------------------------------------ slack (MET) 2.92
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?