Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

What clock should the Sdc constraint be relative to?

Status
Not open for further replies.

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
Hello,

Signal_X in an input pin to my FPGA.
Signal_X is synchronous to clock_x which is also an input pin.

clock_x drives a pll input and becomes pll_clock_x.
pll_clock_x is phase aligned to clock_x and is used to latch signal_x.

Question:
When constraining signal_x for input_delay - what clock should be used? Clock_x or pll_clock_x ?
 

The Altera's SDC constraints have some sort of set_propagated_clocks that will generate the pll_clock_x constraint. The tools will go through the PLL and calculate the delays of the entire clock path (including the PLL). So you can use a virtual clock that matches the clock_x clock.

Maybe this will help though it is for a center aligned case.
 

The Altera's SDC constraints have some sort of set_propagated_clocks
I think you mean "derive_pll_clocks" ?

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?

Should it be clock_x ? or should it be pll_clock_x ?

In my opinion, as the tool is fully aware of the internal connectivity - set_input_delay should be relative to "clock_x" (the input clock pin). Not pll_clock_x...
Do you agree ?
Don't see why a virtual clock is necessary.
 

I think you mean "derive_pll_clocks" ?
Yeah, that command, I don't use Altera much so I forgot what the command was.

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?
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.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Well, that's what I did before posting...
I.E: set_input_delay relative to the clock pin (not the Pll output).

But then I started getting setup timing violations on the nets latched by pll_clock_x.

The input delay I set wasn't strict, the design isn't congested and the frequency of clock_x is 40Mhz.

Seems strange to me.
 

Perhaps you can post the timing report for a sample pin that is failing.
 

tq.png

"IN_PCLOCK_RX_12B" under the Launch Clock tab is my "clock_x" pin.
The very long name under the Latch Clock tab is my "clock_x_pll"
Any of the names under From Node is my "signal_x".
Any of the names under To Node represent the "clock_x_pll" registered version of "signal_x".
 

I didn't mean a timing summary, I meant the timing report (preferably a verbose one). The timing path with all the delay elements listed out, including the routing, if I recall correctly it's what shows when you double click on one of those entries you have in that picture.

Cut and paste that path into a code block, so the path can be analyzed and determine why your set_input_delay is not working.

- - - Updated - - -

BTW it might be a good idea to post both the setup and hold paths for one of those failing pins.
 

I'll most gladly post it if you tell me the exact report name...
Perhaps the Pll is too far away from the input pin it clocks.
 

Don't know what the name of it in Altera, I just know you usually get it by looking at one of the paths listed in the summary timing report and expanding it to show the path incremental delays.

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.
 

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?
 

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. Are you implying that i don't look at the right file? Or that i dont consider timing problems between the same launch and destination clock needs to be fixed.

I don't know why you never used the detailed path report before to check your timing. I consider knowing exactly what it's adding up to be very important.
 

Not sure what you are trying to tell me here.
I consider knowing exactly what it's adding up to be very important.
Of course it is. And I'm not implying anything.
Just explaining how I go about solving timing issues in the design. And that the above usually gives me everything I need to know to solve the problem.
If my approach is flawed and there're other "more interesting"reports I'd like to know about them.

I didn't find a report in Timequest like the one you mentioned in #8.
 

I didn't find a report in Timequest like the one you mentioned in #8.
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...
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
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.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Thanks,

I'll have a look and see if I find anything that resembles it.
 

If they removed this then this is going backwards from what was available in timequest, that tool really looked like something that hardware engineers told the software engineers how to display the information in the tool (they even had a graphic of the timing relationship shown).

Maybe Altera/Intel has decided to let the software engineers decide what tools a hardware engineer needs to do their job. :???::shock::roll:

...I'm sure glad I'm using Xilinx...;-)
 

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...
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
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.

Thats what you get from timequest when you click on a particular route, with a nice little timing graph, and right clicking allows you to visualise the net on the chip planner or map viewer (not the rtl view, as this makes little sense). You also get it on a per net basis (as you said) in the detailed timing report.
Im still stuck with Q15.1, but I doubt it changed much for Q16.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top