cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jprovidenza
Voyager
Voyager
9,046 Views
Registered: ‎08-30-2007

PAR 12.2 vs Trace 12.2 report disagreements

I'm using ISE 12.2 on a Spartan 6 design and have been seeing numerous  bogus

outputs from the Trace program.  The latest is PAR vs Trace.

 

Here's info from the PAR report:

Timing Score: 0 (Setup: 0, Hold: 0, Component Switching Limit: 0)
Routing: Completed - No errors found.
Timing: Completed - No errors found.

From the TRACE report:

Timing errors: 16  Score: 37543  (Setup/Max: 0, Hold: 37543)

 

Is anyone else seeing this type of discrepancy?  I'm also seeing problems that Trace treats

some signals as unconstrained that are clearly constrained.  The signals tend to involve either

BRAMS or Distributed RAMs.

 

John Providenza

 

 

 

 

 

 

0 Kudos
9 Replies
htsvn
Xilinx Employee
Xilinx Employee
9,031 Views
Registered: ‎08-02-2007

Hi,

 

It looks as not to be working as intended, please file a webcase with Xilinx Technical Support.

 

Thnx

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
ywu
Xilinx Employee
Xilinx Employee
8,981 Views
Registered: ‎11-28-2007

If you run trce with -u (report unconstrained paths), it will report hold violations on unconstrained paths. Take a look at the .twx from trace to see if that's the case.

 

Regarding distRAM showing up in unconstrained path report, check http://www.xilinx.com/support/answers/35881.htm to see if it's applicable.

 


@jprovidenza wrote:

I'm using ISE 12.2 on a Spartan 6 design and have been seeing numerous  bogus

outputs from the Trace program.  The latest is PAR vs Trace.

 

Here's info from the PAR report:

Timing Score: 0 (Setup: 0, Hold: 0, Component Switching Limit: 0)
Routing: Completed - No errors found.
Timing: Completed - No errors found.

From the TRACE report:

Timing errors: 16  Score: 37543  (Setup/Max: 0, Hold: 37543)

 

Is anyone else seeing this type of discrepancy?  I'm also seeing problems that Trace treats

some signals as unconstrained that are clearly constrained.  The signals tend to involve either

BRAMS or Distributed RAMs.

 

John Providenza

 

 

 

 

 

 


 

Cheers,
Jim
0 Kudos
jprovidenza
Voyager
Voyager
8,971 Views
Registered: ‎08-30-2007

Jim -

 

I always run with the -u option so I can resolve unconstrained paths.  I have constraints i my

UCF file that *should* tig some ot the distRAM paths, but TRACE only applies it to some of

the paths.

 

Right now I see 3 problems with PAR vs TRACE in the 12.2

1) they disagree on the timing results

2) trace does not porperl y apply UCF constraints to distRAM paths

3) trace reports some paths as unconstrained that actually look to be

properly constrained.

 

I've opened a Webcase to see what resolution is suggested.

 

This is very disappointing.  How can you do a correct design when the tools lie to you?

 

John Providenza

 

0 Kudos
endab
Xilinx Employee
Xilinx Employee
8,950 Views
Registered: ‎11-06-2007

There is a known issue with DRAMs not been picked up correctly by TNM constraints. Please see the following:

http://www.xilinx.com/support/answers/35881.htm

 

The other issue with the Timing Score not been 0 when the -u option is used. I filed a CR aginst the tools and will provided feedback to this tread once I have more information.

0 Kudos
jprovidenza
Voyager
Voyager
8,945 Views
Registered: ‎08-30-2007

Yes, I'm adding the kludges suggested by the AR358881 to see if they help.  That problem was

planned to be fixed in 12.2 according to the AR. 

 

I suspect XIlinx should update the AR to report that the distRAM timing bug is not yet fixed.

 

John P

0 Kudos
jprovidenza
Voyager
Voyager
8,941 Views
Registered: ‎08-30-2007

The TPSYNC kludge suggested by AR358881 only partially works. I added lines like:

INST "*/u_phy_rx_fifo/Mram_pause_fifo_mem*"   TPSYNC = "pause_ram";

TIMESPEC "TS_pause_ram_2"        = from FFS to   "pause_ram" 7.7 ns datapathonly;

But I still get unconstrained paths like:

Timing constraint: Unconstrained path analysis

 1462 paths analyzed, 1462 endpoints analyzed, 0 failing endpoints
 0 timing errors detected. (0 setup errors, 0 hold errors)
 Minimum period is   7.805ns.
--------------------------------------------------------------------------------

Paths for end point u0_channel/u_phy_rx_fifo/Mram_pause_fifo_mem2_RAMB (SLICE_X18Y38.BX), 1 path
--------------------------------------------------------------------------------
Delay (setup path):     7.805ns (data path - clock path skew + uncertainty)
  Source:               u0_channel/rx_d_1 (FF)
  Destination:          u0_channel/u_phy_rx_fifo/Mram_pause_fifo_mem2_RAMB (RAM)
  Data Path Delay:      7.547ns (Levels of Logic = 0)
  Clock Path Skew:      -0.039ns (0.696 - 0.735)
  Source Clock:         u0_channel/rx_clk rising at -0.771ns
  Destination Clock:    u0_channel/rx_clk rising at 7.129ns
  Clock Uncertainty:    0.219ns

 

In addition, TRACE reports

================================================================================
Timing constraint: TS_pause_ram_2 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP
"pause_ram" 7.7 ns         DATAPATHONLY;

 0 paths analyzed, 0 endpoints analyzed, 0 failing endpoints
 0 timing errors detected.
--------------------------------------------------------------------------------

 

Sigh.

 

John Providenza

 

 

0 Kudos
endab
Xilinx Employee
Xilinx Employee
8,916 Views
Registered: ‎11-06-2007

The issue with the Timing Score difference in PAR and TRCE is expected. I created AR 37292 for this with the following contents:

 

“When you run a timing analysis and report unconstrained paths with the -u switch I see a timing score due to hold violations. Is this correct?

 

Yes this is correct and expected. The unconstrained timing report may include hold errors that are not explicitly covered by user timing constraints and this is designed to alert the end user that these unconstrained paths have hold violations. Please see the following:

http://www.xilinx.com/support/answers/31881.htm

 

Par implements the design to the end-user's timing constraints, and does not perform analysis on unconstrained paths, hence the zero timing score in par. Under these circumstances trce without the unconstrained option will also get a zero timing score, reflecting only the timing constraints explicitly specified for implementation. But when the unconstrained analysis is run then any failures will contribute to the timing score.”

 

I hope this explains the situation.

 

The issue with the DRAMs not been grouped should be worked on seperately and I have a case on this.

0 Kudos
xingzhe
Xilinx Employee
Xilinx Employee
8,523 Views
Registered: ‎11-21-2008

 

this i think is caused by misuse of clock in your design, for example, maybe you have data path between two unrelated clock, or else your clock is using regular routing resource which leads to too much skew on clock.

0 Kudos
jprovidenza
Voyager
Voyager
8,499 Views
Registered: ‎08-30-2007

No, the problem was not a design problem,  it was caused by a bug in the Xilinx s/w. 

 

They reproduced the problem and sent me a patch file that updated some of their files. After

installing the patch, the timing tools started analyzing all the paths and gave sensible results.

 

John Providenza

0 Kudos