cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
drapczynski
Visitor
Visitor
10,838 Views
Registered: ‎05-16-2011

Prioritize routing to meet timing

Jump to solution

I am using Xilinx 12.4 tools with a Virtex 5 FX200T part.  The design uses 85% SRL's and 75% FD's, so it's pretty full.  I have been using the -lc auto MAP option on all of my attempts to build the design -- this significantly reduces MAP time.  I have tried many other differenct MAP options but have not been able to meet timing.  The best I can do is less than 100 errors.  Here is an example of a failing constraint:

 

================================================================================
Timing constraint: PERIOD analysis for net
"$pclk2x.CLK2X$7.142857142857142ns$pclk$/u_PLL_BASE.CLKOUT1" derived from  NET  
      
"$pclk2x.CLK2X$7.142857142857142ns$pclk$/
u_WILDSTAR5_VME_iope_clock_pclk2x.clkIn"        PERIOD = 3.572 ns HIGH 50%;
multiplied by 2.00 to 7.144 nS   

 753169 paths analyzed, 274630 endpoints analyzed, 62 failing endpoints
 62 timing errors detected. (62 setup errors, 0 hold errors, 0 component switching limit errors)
 Minimum period is  10.823ns.
--------------------------------------------------------------------------------
Slack:                  -3.679ns (requirement - (data path - clock path skew + uncertainty))
  Source:               ibPort2/te/ngci/ninp/nx2m/nxh2/nnv (FF)
  Destination:          ibPort2/te/ngci/ninp/nx2m/nxhb/nir_ (FF)
  Requirement:          7.144ns
  Data Path Delay:      10.604ns (Levels of Logic = 5)
  Clock Path Skew:      -0.148ns (1.615 - 1.763)
  Source Clock:         $pclk2x.CLK2X$7.142857142857142ns$pclk$.clkOut1 rising at 0.000ns
  Destination Clock:    $pclk2x.CLK2X$7.142857142857142ns$pclk$.clkOut1 rising at 7.144ns
  Clock Uncertainty:    0.071ns

  Clock Uncertainty:          0.071ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter (TSJ):  0.070ns
    Discrete Jitter (DJ):       0.123ns
    Phase Error (PE):           0.000ns

  Maximum Data Path: ibPort2/te/ngci/ninp/nx2m/nxh2/nnv to ibPort2/te/ngci/ninp/nx2m/nxhb/nir_
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    SLICE_X86Y59.DQ      Tcko                  0.471   ibPort2/te/ngci/ninp/nx2m/nxh9
                                                       ibPort2/te/ngci/ninp/nx2m/nxh2/nnv
    SLICE_X121Y107.C6    net (fanout=4)        2.697   ibPort2/te/ngci/ninp/nx2m/nxh9
    SLICE_X121Y107.C     Tilo                  0.094   ibPort2/te/nge0/n5d(14)
                                                       ibPort2/te/nge0/nta7/nt66/naq/nae
    SLICE_X86Y59.D6      net (fanout=4)        2.751   ibPort2/te/nge0/nta7/nt6r
    SLICE_X86Y59.D       Tilo                  0.094   ibPort2/te/ngci/ninp/nx2m/nxh9
                                                       ibPort2/te/nge0/nta7/nt66/nau/nav
    SLICE_X116Y97.D5     net (fanout=3)        2.441   ibPort2/te/ng0_
    SLICE_X116Y97.DMUX   Tilo                  0.242   ibPort1/port/nc08/n7uo/nyco/nycc/nyc3/n4u(8)
                                                       ibPort2/te/ngci/ninp/nx2m/nau/nav
    SLICE_X117Y97.C5     net (fanout=6)        0.411   ibPort2/te/ngci/ninp/nx2m/nam
    SLICE_X117Y97.COUT   Topcyc                0.423   ibPort2/te/ngci/ninp/nx2m/nxhb/njb(3)
                                                       ibPort2/te/ngci/ninp/nx2m/nxhb/nxhv/nwy
                                                       ibPort2/te/ngci/ninp/nx2m/nxhb/nxhv/n1j
    SLICE_X117Y98.CIN    net (fanout=1)        0.000   ibPort2/te/ngci/ninp/nx2m/nxhb/nxhv/n1j.O
    SLICE_X117Y98.BMUX   Tcinb                 0.335   ibPort2/te/ngci/ninp/nx2m/nxhb/njb(4)
                                                       ibPort2/te/ngci/ninp/nx2m/nxhb/nxhv/n18
    SLICE_X118Y92.BX     net (fanout=1)        0.656   ibPort2/te/ngci/ninp/nx2m/nxhb/nxhg5
    SLICE_X118Y92.CLK    Tdick                -0.011   ibPort2/te/ngci/n4np
                                                       ibPort2/te/ngci/ninp/nx2m/nxhb/nir_
    -------------------------------------------------  ---------------------------
    Total                                     10.604ns (1.648ns logic, 8.956ns route)
                                                       (15.5% logic, 84.5% route)

--------------------------------------------------------------------------------

 

The problem is always ibPort1 or ibPort2.  Is there a way to tell the tools to route these paths first?  84.5% route does indicate that the route is the problem even though the resources that have the longest delays don't seem to be that far away.  Would using an AREA constraint provide a better chance of meeting timing?  How would I specify an area constraint in this case?

 

Thanks,

Dan

 

 

0 Kudos
1 Solution

Accepted Solutions
evgenis1
Advisor
Advisor
11,782 Views
Registered: ‎12-03-2007

Dan,

 

I don't have a good explanation why adding AREA_GROUP constraint would cause this error. Can you roll back to the last good implementation (that passes MAP/PAR), add the AREA_GROUP, and rebuild the design with the same tool options.

 

One "trick" I use to floorplan the desing with PlanAhead is not to open the entire design, which can be very slow. Instead, you can create a new project using "Create and IO planning project", and add your UCF files. Than you can quickly and easily draw and change rectangles (area groups), and export their coordinates in the UCF format .

 

 

Thanks,

Evgeni

 

View solution in original post

0 Kudos
16 Replies
drjohnsmith
Teacher
Teacher
10,836 Views
Registered: ‎07-09-2009

Hi

 

can I ask, why do you think routing this first will make any differance ?

 

I'd have thought the router will try different ways of finding a route,

 

In my experiance, timming fit is rather like aballoon full of water being squeezed.

    if you get one bit popping out, if you push that back in, something else where will pop out.

 

can you re arange the code so that route depends upon less logic levels ? 

   a bit of pipe lining ?

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
drapczynski
Visitor
Visitor
10,833 Views
Registered: ‎05-16-2011

Yes, I understand what you are saying.  The only reason I thought routing this path first might help was that it always seems to be the one that is failing timing. 

 

I am using a graphical design tool (similar to Simulink) to generate the code which I do not have access to.  The design tool does not provide the level of detail necessary to implement pipelining.

 

Do you think an area constraint would help?

0 Kudos
drjohnsmith
Teacher
Teacher
10,826 Views
Registered: ‎07-09-2009

area constraint in this case unlikely to help,

 

you seem to have a function with lots of terms, ( I can't remeber how many, but it was 5 LUT deep )

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
evgenis1
Advisor
Advisor
10,820 Views
Registered: ‎12-03-2007

Hi,

 

You're using 140MHz clock, and the critical path breaks down into 15.5% logic, 84.5% route.

You can see long "jumps" from SLICE_X86Y59 to SLICE_X121Y107, SLICE_X116Y97 and back (X and Y coordinate difference in CLB units).

The fanout is low, meaning that the placer has a good reason to place "ibPort2/te/ngci/ninp/nx2m/nxh9"  LUT far away from "ibPort2/te/ngci/ninp/nx2m/nxh9" register.

 

Floorplanning "ibPort2/te" instance might help reduce routing delays.

 

Have you tried logic replication ?

 

Thanks,

Evgeni

Tags (1)
0 Kudos
drapczynski
Visitor
Visitor
10,809 Views
Registered: ‎05-16-2011

Evgeni,

 

I was able to get this particular design to meet timing by rerunning PAR a few times with the -xe c option.  This has worked for me in the past but not always.  I have also tried running MAP with different placer cost table values with some success.  I guess I was looking for another approach that would produce more predictable results.

 

I have not tried floorplanning yet but I will look into it.

 

What do you mean by logic replication?  I am using a high level graphical design tool so I can't manipulate low level logic.  Is there a tool option to implement logic replication generically?

 

Thanks,

Dan

0 Kudos
evgenis1
Advisor
Advisor
10,804 Views
Registered: ‎12-03-2007

Dan,

 

That's exactly what floorplanning is good for: achieve more predictable build results, among other things.

You've mentioned that you used -lc MAP option. -register_duplication (Duplicate Registers) is a MAP option that helps meet timing. This is also the same XST option (I don't know what synthesis tool are you using). 

 

Thanks,

Evgeni

0 Kudos
drapczynski
Visitor
Visitor
10,802 Views
Registered: ‎05-16-2011

According to the Command Line Tools Users Guide, since I'm targeting a Virtex 5, timing driven packing and placement is on by default (-timing MAP option).  Also, it says that these options are enable when using -timing: -logic_opt, -ntd, -ol, -register_duplication, -x, -xe.  So I believe -register_duplication is enabled already.

 

So in looking into floorplanning, I tried to open my EDF file in PlanAhead and I get a bunch of these errors:

 

ERROR: [HD-EDIFIN 16] Can't connect net 'nmq1' to pin 'num/ntg[1]' in cell 'nu4'. This pin is already connected to net 'nmq[1]'. The new connection will be ignored (line '14932')

 

Then it looks like the open fails with this error:

 

ERROR: [HD-EDIFIN 9] Identifier 'n8fn' used multiple times in the same scope (cell 'n85z', library 'work')

 

Any ideas on these errors?  Is there another tool I can use to floorplan?

 

Thanks,

Dan

0 Kudos
evgenis1
Advisor
Advisor
10,797 Views
Registered: ‎12-03-2007

Dan,

 

You can check whether -register_duplication option is used or not by looking into the MAP report (*.mrp file). It's on the very top of the report in "design information" section.

 

Do those PlanAhead errors prevent opening the design ? From what I've seen so far, they don't. I've seen errors, although different that yours, and opened a few WebCases with Xilinx.

 

As far as I know, PlanAhead is the only tool that can automate floorplanning (not counting Synplify Premier). At the lowest level all it does is writing AREA_GROUP constraints to the UCF (design constraints file). AREA_GROUP locks instances of the design to certain area on the FPGA die.

 

Thanks,

Evgeni

Tags (1)
0 Kudos
danhoud
Xilinx Employee
Xilinx Employee
10,784 Views
Registered: ‎09-24-2007

You can try making timing groups of the registers on each end of these problem paths and then defining a FROM-TO which is equal to or less than the normal PERIOD constraint.  This will elevate the importance of these nets and they will get implemented before the rest of the PERIOD group. 

 

This is good for a few problem situations, but gets very diminishing returns if you use it a lot.  If this approach just continues to cause new nets to fail, then it is better to attack this at the design level with more pipelining.

Regahds
drjohnsmith
Teacher
Teacher
8,410 Views
Registered: ‎07-09-2009

HI

 

I'd also be very worried about  a high level tool that does not let you specify thigns like pipelining, or algorithum changes to allow your design to optimise.

 

after all, if I put A <= B+C, 

    I''d hope to be able to infulance as to if that gets interpreted as a serial or ripple carry or what sort of adder,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
rcingham
Teacher
Teacher
8,406 Views
Registered: ‎09-09-2010

 


@drjohnsmith wrote:

 

after all, if I put A <= B+C, 

    I''d hope to be able to infulance as to if that gets interpreted as a serial or ripple carry or what sort of adder,

 


Why? If the tool fits it in the device and it meets timing, the low-level aspects of the implementation are irrelevant. "Good enough" is good enough!

 

 


------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
drjohnsmith
Teacher
Teacher
8,401 Views
Registered: ‎07-09-2009

totaly agree

 

and thats what I was trying to say, sorry long day,

 

if the top level tools does not allow one to specify enough that the architecture can not be changed to meet requirments, 

   then it;s the wrong tools.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
drapczynski
Visitor
Visitor
8,399 Views
Registered: ‎05-16-2011

Evgeni,

 

I have not been able to open my design in PlanAhead.  I've tried to manually enter AREA_GROUP constraints in a UCF file.  At first I was getting MAP errors basically saying my range needed to be bigger.  So I kept making the range bigger until I got errors like these:

 

Phase 2.7  Design Feasibility Check
ERROR:Place:899 - The following IOBs use the Digitally Controlled Impedance
   feature (DCI) and have been locked (LOC constraint) to the I/O bank 11.
   This feature requires the VRN and VRP pins within the same I/O bank to be
   connected to reference resistors.
   The following VR pins are currently locked and can't be used to supply the
   necessary reference.
   IO Standard: Name = LVDCI_DV2_18, VREF = NR, VCCO = 1.80, TERM = DRIVER, DIR
   = BIDIR, DRIVE_STR = NR
   List of locked IOB's:
       x_cf_LadMux.pads(787)
       x_cf_LadMux.pads(802)
       x_cf_LadMux.pads(804)
       x_cf_LadMux.pads(799)
       x_cf_LadMux.pads(810)
       x_cf_LadMux.pads(801)
       x_cf_LadMux.pads(789)
       x_cf_LadMux.pads(782)
       x_cf_LadMux.pads(808)
       x_cf_LadMux.pads(792)
       x_cf_LadMux.pads(809)
       x_cf_LadMux.pads(784)
       x_cf_LadMux.pads(812)
       x_cf_LadMux.pads(806)
       x_cf_LadMux.pads(807)
       x_cf_LadMux.pads(793)
       x_cf_LadMux.pads(795)
       x_cf_LadMux.pads(797)
       x_cf_LadMux.pads(791)
       x_cf_LadMux.pads(790)
       x_cf_LadMux.pads(794)
       x_cf_LadMux.pads(811)
       x_cf_LadMux.pads(796)
       x_cf_LadMux.pads(813)
       x_cf_LadMux.pads(798)
       x_cf_LadMux.pads(788)
       x_cf_LadMux.pads(805)
       x_cf_LadMux.pads(783)
       x_cf_LadMux.pads(800)
       x_cf_LadMux.pads(786)
       x_cf_LadMux.pads(858)
       x_cf_LadMux.pads(862)
       x_cf_LadMux.pads(803)
       x_cf_LadMux.pads(785)

   List of occupied VR Sites:
   VR site R42 is occupied by comp x_cf_LadMux.pads(790)
   VR site P42 is occupied by comp x_cf_LadMux.pads(797)

 

Here is the constraint I am using:

 

INST "ibPort1/te*" AREA_GROUP = "ibPort1";
AREA_GROUP "ibPort1" RANGE=SLICE_X40Y30:SLICE_X110Y100;

 

I also get this warning:

WARNING:Map:83 - The range defined by columns 40, 110 and rows 30, 100 in area
   group "ibPort1" does not fall on CLB boundary.  The constraint value equals
   SLICE_X40Y30:SLICE_X110Y100.  This practice is dangerous and will likely lead
   to overlapping area group warnings in PAR as well as possibly undesirable RPM
   placements.

 

 

I'm not sure what to try next.  I could make the range bigger but I have a feeling that won't help.  I'm not even sure I am implementing the constraint correctly.

 

The procedure I am using to meet timing is this:  run MAP with -lc auto, -cm speed options and placer cost table value specified using the -t option.  I run PAR with the -xe c option on each MAP output and see if I meet timing.  If I don't, I rerun PAR.  If the number of timing errors decreases, I keep rerunning PAR until I meet timing or the number of timing errors stops decreasing, in which case I run MAP again with the next placer cost table value.  This process can be time consuming (on the order of 5 hrs. total) but at least it seems to work.  Hopefully this may help someone else with similar issues meeting timing.

 

I would still like to try an alternate method of meeting timing.  Any suggestions you have would be appreciated.  I will experiment more with AREA_GROUP constraints.

 

Thanks,

Dan

 

 

 

 

0 Kudos
evgenis1
Advisor
Advisor
11,783 Views
Registered: ‎12-03-2007

Dan,

 

I don't have a good explanation why adding AREA_GROUP constraint would cause this error. Can you roll back to the last good implementation (that passes MAP/PAR), add the AREA_GROUP, and rebuild the design with the same tool options.

 

One "trick" I use to floorplan the desing with PlanAhead is not to open the entire design, which can be very slow. Instead, you can create a new project using "Create and IO planning project", and add your UCF files. Than you can quickly and easily draw and change rectangles (area groups), and export their coordinates in the UCF format .

 

 

Thanks,

Evgeni

 

View solution in original post

0 Kudos
8,387 Views
Registered: ‎05-26-2011

For "WARNING:Map:83", the values of the RANGE should include full CLB (SLICE pair), i.e. :

 

   SLICE_X*Y*:SLICE_Xodd_valueY*

 

For instance, instead of SLICE_X40Y30:SLICE_X110Y100, try SLICE_X40Y30:SLICE_X111Y100.

0 Kudos
drapczynski
Visitor
Visitor
8,346 Views
Registered: ‎05-16-2011

Evgeni,

 

I figured out why I was getting the errors during the design feasability check.  I was not including constraints that were generated by the vendor design tool I am using. 

 

Thanks for your "trick".  I was able to create a new project in PlanAhead to create the area groups.  I was able to eliminate timing errors due to a few nets but still have errors in others. 

 

The project that this design was for has been put on hold so I may not get back to it for a while.  Thanks for all your help!

 

Dan

0 Kudos