+ Post New Thread
Results 1 to 17 of 17
  1. #1
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    What clock should the Sdc constraint be relative to?

    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 ?

  2. #2
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

    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.



  3. #3
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    Re: What clock should the Sdc constraint be relative to?

    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.



  4. #4
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

    Quote Originally Posted by shaiko View Post
    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.


    1 members found this post helpful.

    •   Alt16th March 2017, 17:08

      advertising

        
       

  5. #5
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    Re: What clock should the Sdc constraint be relative to?

    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.



  6. #6
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

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



    •   Alt16th March 2017, 21:00

      advertising

        
       

  7. #7
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    Re: What clock should the Sdc constraint be relative to?

    Click image for larger version. 

Name:	tq.png 
Views:	8 
Size:	142.4 KB 
ID:	137069

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



  8. #8
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

    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.



    •   Alt17th March 2017, 22:52

      advertising

        
       

  9. #9
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    Re: What clock should the Sdc constraint be relative to?

    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.



  10. #10
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

    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.



  11. #11
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    Re: What clock should the Sdc constraint be relative to?

    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?



  12. #12
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

    Quote Originally Posted by shaiko View Post
    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.



  13. #13
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    Re: What clock should the Sdc constraint be relative to?

    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.



  14. #14
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

    Quote Originally Posted by shaiko View Post
    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.


    1 members found this post helpful.

    •   Alt20th March 2017, 16:45

      advertising

        
       

  15. #15
    Advanced Member level 5
    Points: 11,627, Level: 25

    Join Date
    Aug 2011
    Posts
    2,382
    Helped
    278 / 278
    Points
    11,627
    Level
    25

    Re: What clock should the Sdc constraint be relative to?

    Thanks,

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



  16. #16
    Super Moderator
    Points: 25,734, Level: 39
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    5,834
    Helped
    1434 / 1434
    Points
    25,734
    Level
    39

    Re: What clock should the Sdc constraint be relative to?

    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.

    ...I'm sure glad I'm using Xilinx...



  17. #17
    Advanced Member level 5
    Points: 33,284, Level: 44
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,094
    Helped
    1785 / 1785
    Points
    33,284
    Level
    44

    Re: What clock should the Sdc constraint be relative to?

    Quote Originally Posted by ads-ee View Post
    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.


    1 members found this post helpful.

--[[ ]]--