UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer drmerxius
Observer
472 Views
Registered: ‎12-20-2018

Forcing vivado to use LAGUNA regs

Hello everyone,

I've read many post about that and tried many things but no one solved my problem:
I have to cross SLRs at high speed (500+ MHZ), on vu9p, vivado 2019.1, I've tried:

- single pblock grouping cells of both SRLs

- two pblocks at the edge of each SLR, tried many shapes of the pblock, also tried with pblock with only laguna cells

- four pblocks, two for every SLR, one with just the cell and one bigger with the "core" the cell is referring to

- pblocks with the interested cells and the ones connected to them

- specific cell assignment

and also many other tries that I can't remember here, I'm a bit confused at the moment.

last try was:

set_property USER_SLL_REG TRUE [get_cells $CoreCellPath/cores\[*\].reg1]
set_property USER_SLL_REG TRUE [get_cells $CoreCellPath/cores\[*\].reg2]
set_property BEL TX_REG0 [get_cells $CoreCellPath/cores\[1\].reg1/bus_out_reg\[complete\]]
set_property LOC LAGUNA_X19Y478 [get_cells $CoreCellPath/cores\[1\].reg1/bus_out_reg\[complete\]]
set_property BEL RX_REG0 [get_cells $CoreCellPath/cores\[1\].reg2/bus_out_reg\[complete\]]
set_property LOC LAGUNA_X18Y480 [get_cells $CoreCellPath/cores\[1\].reg2/bus_out_reg\[complete\]]

producing this error:
ERROR: [Place 30-784] Connectivity Legality - Laguna RX register [top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg2/bus_out_reg[complete]] needs to have its driver [top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg1/bus_out_reg[complete]] on a SLR across the inter-SLR channel connected to that BEL and not placed on any TX Laguna Register. If a register is constrained to a Laguna RX site, it is also necessary to constrain its driver to the adjacent SLR

can you help me?

0 Kudos
9 Replies
Xilinx Employee
Xilinx Employee
391 Views
Registered: ‎04-11-2008

Re: Forcing vivado to use LAGUNA regs

Easiest thing to try is to run:

phys_opt_design -tns_cleanup -slr_crossing_opt

You will probably need to run phys_opt_design 2x in order to clean up any paths that degrade. So:

phys_opt_design -tns_cleanup -slr_crossing_opt

phys_opt_design -directive AggressiveExplore

 

USER_SLL_REG is a soft constraint so not required to force locations. To work, you must have the input / output in different SLRs and the load of the source register must be just one. Setting this property does not force the tools to recognise a net as an SLR crossing path which means your floorplan will have to do that.

Let us know how you got on with the phys_opt_suggstion.

John

0 Kudos
Scholar drjohnsmith
Scholar
378 Views
Registered: ‎07-09-2009

Re: Forcing vivado to use LAGUNA regs

take step back and use brute force method.

Use double the number of routes, at half the data rate !

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Observer drmerxius
Observer
348 Views
Registered: ‎12-20-2018

Re: Forcing vivado to use LAGUNA regs

  drjohnsmithI cannot change the design, sorry

I've tried many things, including the phys_opt you suggested me, but made some errors on tcl scripts and the correct one should complete overnight.

I've managed to force the use of laguna regs, I also found in documentation that laguna regs directly connect are 120 columns far, so like X19Y400 connects to X19Y520.

anyway I get this timings

 

Max Delay Paths
--------------------------------------------------------------------------------------
Slack (VIOLATED) :        -0.411ns  (required time - arrival time)
  Source:                 top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg1/bus_out_reg[complete]/C
                            (rising edge-triggered cell FDRE clocked by clkgen0_out  {rise@0.000ns fall@1.000ns period=2.000ns})
  Destination:            top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg2/bus_out_reg[complete]/D
                            (rising edge-triggered cell FDRE clocked by clkgen0_out  {rise@0.000ns fall@1.000ns period=2.000ns})
  Path Group:             clkgen0_out
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            2.000ns  (clkgen0_out rise@2.000ns - clkgen0_out rise@0.000ns)
  Data Path Delay:        0.966ns  (logic 0.165ns (17.081%)  route 0.801ns (82.919%))
  Logic Levels:           0  
  Clock Path Skew:        -0.738ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    4.975ns = ( 6.975 - 2.000 ) 
    Source Clock Delay      (SCD):    5.886ns
    Clock Pessimism Removal (CPR):    0.173ns
  Clock Uncertainty:      0.118ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.226ns
    Phase Error              (PE):    0.000ns
  Inter-SLR Compensation: 0.437ns  ((DCD - CCD) * PF)
    Destination Clock Delay (DCD):    4.975ns
    Common Clock Delay      (CCD):    2.060ns
    Prorating Factor         (PF):    0.150
  Clock Net Delay (Source):      5.886ns (routing 1.854ns, distribution 4.032ns)
  Clock Net Delay (Destination): 4.975ns (routing 1.701ns, distribution 3.274ns)

    Location             Delay type                Incr(ns)  Path(ns)    Partition      Netlist Resource(s)
  -------------------------------------------------------------------    ----------------------------------
                         (clock clkgen0_out rise edge)
                                                      0.000     0.000 r                 
    BUFGCTRL_X1Y74       BUFGCTRL                     0.000     0.000 r  reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/clkgen0/mmcm_mux/O
    X2Y7 (CLOCK_ROOT)    net (fo=1556882, routed)     5.886     5.886    reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg1/hashing_clk
    LAGUNA_X19Y475       FDRE                                         r  reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg1/bus_out_reg[complete]/C
  -------------------------------------------------------------------    ----------------------------------
    LAGUNA_X19Y475       FDRE (Prop_TX_REG0_LAGUNA_C_Q)
                                                      0.165     6.051 r  reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg1/bus_out_reg[complete]/Q
                         net (fo=1, routed)           0.801     6.852    reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg2/bus_out_reg[complete]_0
    SLR Crossing[1->2]   
    LAGUNA_X19Y595       FDRE                                         r  reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg2/bus_out_reg[complete]/D
  -------------------------------------------------------------------    ----------------------------------

                         (clock clkgen0_out rise edge)
                                                      2.000     2.000 r                 
    BUFGCTRL_X1Y74       BUFGCTRL                     0.000     2.000 r  reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/clkgen0/mmcm_mux/O
    X2Y7 (CLOCK_ROOT)    net (fo=1556882, routed)     4.975     6.975    reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg2/hashing_clk
    SLR Crossing[1->2]   
    LAGUNA_X19Y595       FDRE                                         r  reconfigurable top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg2/bus_out_reg[complete]/C
                         clock pessimism              0.173     7.148                     
                         inter-SLR compensation      -0.437     6.711                     
                         clock uncertainty           -0.118     6.592                     
    LAGUNA_X19Y595       FDRE (Setup_RX_REG0_LAGUNA_C_D)
                                                     -0.151     6.441    reconfigurable   top_i/stage2_wrapper_i/stage2_i/hub_0/inst/logic_i/cores[1].reg2/bus_out_reg[complete]
  -------------------------------------------------------------------
                         required time                          6.441                     
                         arrival time                          -6.852                     
  -------------------------------------------------------------------
                         slack                                 -0.411                     

I've launched many sequential runs to test a lot of different cells combination (Xeon server 128gb ram), some is better (-0.275ns) but I use this as reference.

main problem in my opinion is 

  Clock Net Delay (Source):      5.886ns (routing 1.854ns, distribution 4.032ns)
  Clock Net Delay (Destination): 4.975ns (routing 1.701ns, distribution 3.274ns)

so looking in the forum I found the command CLOCK_DELAY_GROUP

that from what I understand should be launched this way:

set_property CLOCK_DELAY_GROUP BUFGCE [get_nets -of_objects [get_cells $CoreCellPath/cores\[1\].reg1/bus_out_reg\[complete\]]]

I was thinking that this way it should have grouped all nets connected to this cell, build completed but nothing has changed.

so maybe I have to specify at least two objects, and a build with this:

set_property CLOCK_DELAY_GROUP core1group [get_nets -of_objects [get_cells $CoreCellPath/cores\[1\].reg1/bus_out_reg\[complete\]] [get_cells $CoreCellPath/cores\[1\].reg2/bus_out_reg\[complete\]]]

should complete overnight

 

what do you think? have any suggestion?

0 Kudos
Scholar drjohnsmith
Scholar
316 Views
Registered: ‎07-09-2009

Re: Forcing vivado to use LAGUNA regs

Id suggest your trying to tune up a mini instead of making a Ferrari
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Observer drmerxius
Observer
309 Views
Registered: ‎12-20-2018

Re: Forcing vivado to use LAGUNA regs

Don't get the sense of your comment. I'm working on this as hobby and got core that could go higher than 900mhz. This part of the code is not my job but need to tune it

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
297 Views
Registered: ‎04-11-2008

Re: Forcing vivado to use LAGUNA regs

CLOCK_DELAY_GROUP is for matching the delay of two clocks that have synchronous CDCs going between the clocks.

It tells the tools they are related and will match programmable delays and the clock roots. In your timing report there is just one clock between the two laguna sites. This is not going to give you a solution to this problem. It might change the picture a little but i do not think this will help.

What you need to do is the following:

i) Lower the uncertainties on the clocking paths. 

a) You have 0.288 ns DJ. There might be something you can do to lower this such as improve your MMMC settings by increasing Fvco.

b) The timing equation is based on the length/delay of the clock tree. You can reduce the length of the clock tree by lowering the programmable delays that are inserted. Try using USER_MAX_PROG_DELAY (2019.2) for earlier version use:

create_property MAX_PROG_DELAY net
set_property MAX_PROG_DELAY <0-7> [get_nets -of [get_pins BUFG/O]]
 
You need to set this to a value of 3 or 4.
 
Lesser difference is by having the crossings close to the CLOCK_ROOT vertical spine (X coordinate of the clock root)
 

ii) You may need to run route_design with directive Explore or NoTimingRelaxation. This will enable some advanced skew balancing techniques in the clock tree.

 

Even with these techniques, you are going too fast for a -2LV speedgrade. 

John

Scholar drjohnsmith
Scholar
275 Views
Registered: ‎07-09-2009

Re: Forcing vivado to use LAGUNA regs

You will need the top speed grades of the Ferrarie to get these sort of speeds, the mini is never going to ger that fast, less it falls off a cliff.
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Observer drmerxius
Observer
257 Views
Registered: ‎12-20-2018

Re: Forcing vivado to use LAGUNA regs

blaine: really thanks for the hint, I'm on 2019.1.3 so the command USER_MAX_PROG_DELAY should work, at least tcl script seems to notice it, but I'm getting errors about the objest, tryied:

 
create_property MAX_PROG_DELAY net
set_property MAX_PROG_DELAY 4 [get_nets -of [get_pins BUFG/O]]
set_property USER_MAX_PROG_DELAY 4 [get_nets -of [get_pins BUFG/O]]
set_property USER_MAX_PROG_DELAY 4 [get_nets -of_objects [get_cells $CoreCellPath/cores\[1\].reg1/bus_out_reg\[complete\]]]

all getting errors

0 Kudos
Xilinx Employee
Xilinx Employee
216 Views
Registered: ‎04-11-2008

Re: Forcing vivado to use LAGUNA regs

You will need to replace the BUFG with the cell name.

What is the error you get?

0 Kudos