cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
1,521 Views
Registered: ‎06-28-2017

how can I compare placement and routing on ZYNQ part from 2 different design runs in vivado 2016.3?

Does anyone know how can I compare placement and routing from 2 different design runs ? It appears that adding chipscope (ILA) to 3rd party design causes it to work more reliably, i suspect the placement was an issue so i want to figure out how to best collect the placement data from a particular run and incorporate that into the XDC for future rums - however i really don't want to have to maintain a separate guide file. im using vivado 2016.3 on zync 7010 and 7020 and cant migrate to the latest version of vivado either. Im just trying to capture the main placement and routing differences as one design works reliably and the other version of the identical design w/o ILA does not. I do not own the original IP im using either.  Any Ideas?

 

Tags: [vivado 2016.3, ZYNQ,  ILA, Placement, Routing, XDC, Guide] 

0 Kudos
4 Replies
Highlighted
Scholar
Scholar
1,512 Views
Registered: ‎02-27-2008

Look at your constraints,

 

If adding ILA made it 'better' your design is improperly (incompletely) constrained.  The solution is not placement, it is making the tools aware of what timings must be met, at what points.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Highlighted
Scholar
Scholar
1,503 Views
Registered: ‎09-16-2009

What Austin said times 10.

 

We've occasionally run into these types of problems.  Each and every time - 100% - the root cause was some sort of timing trouble based on missing / incorrect timing constraints or improper synchronizer design.

 

A good place to start is looking at the report generated with "report_clock_interaction".  Focus on your cross-clock paths and synchronizer designs.  Use the general area of the bench failure to help guide your search.

 

It's often not easy to find, but I strongly suggest not trying to mess around with blind placement guidelines.  You're just rolling the dice.

 

Regards,

 

Mark

0 Kudos
Highlighted
Visitor
Visitor
1,493 Views
Registered: ‎06-28-2017

Austin,

I also considered that but the interface that has been troublesome is a very slow (10-20Mhz) SPI interface, all my timing flop to flop is met with the Zynq  AXI interface global clock at 125Mhz, with other IP cores > 200MHz and those work fine. But this slow SPI interface issue is confusing perhaps this is new to vivado but on ISE one didnt need to define constraints for a slow UART or SPI interface if your primary clock was much faster. If i can meet timing at 125Mhz meeting 20Mhz is trivial. But are you saying in vivado the tool really requires that all I/O has constraints even if they are order of magnitude slower than global clock? The funny thing Is is that the ILA is not even being technically used.... my platform consists of several ipcores and an SPI core. I have a parameter tied to a generate block inside the spi core so that in the BD i can add or remove the ILA as needed. I have the parameter tied to 0 so that it does not insert the core. 

 

case in point:

so if i have this with DEBUG_EN = 0  or  DEBUG_EN = 1 the design works and seems to read data from external SPI component

 


//---------------------------
generate
begin
if (DEBUG_EN == 1) begin
//---------------------------
viv163_vivado_ila64 cs_test_vivado_ila64_1 // RX1 - SerialClk
(
.clk(Clock),
.trig_out(), // o
.trig_out_ack(1'b1), // i
.trig_in(1'b0), // i
.trig_in_ack(), // o
.probe0(cs_test_vector_0) // i 64
);


assign cs_test_vector_0[63] = InBoundValid;
assign cs_test_vector_0[62:60] = AdcNumber[2:0];
assign cs_test_vector_0[59:56] = Channel[3:0];
assign cs_test_vector_0[55:52] = ChannelAddress[3:0];
assign cs_test_vector_0[51:40] = InternalData[11:0];
assign cs_test_vector_0[39:28] = InBoundData[2][11:0];
assign cs_test_vector_0[27:16] = InBoundData[1][11:0];
assign cs_test_vector_0[15:0] = InBoundData[0][15:0];
//---------------------------
end
end
endgenerate
//---------------------------

 

 

but..if i try to comment out all the code (as shown) and build the design the IPcore does not properly read from the external SPI component.


// //---------------------------
// generate
// begin
// if (DEBUG_EN == 1) begin
// //---------------------------
// viv163_vivado_ila64 cs_test_vivado_ila64_1 // RX1 - SerialClk
// (
// .clk(Clock),
// .trig_out(), // o
// .trig_out_ack(1'b1), // i
// .trig_in(1'b0), // i
// .trig_in_ack(), // o
// .probe0(cs_test_vector_0) // i 64
// );
//
// assign cs_test_vector_0[63] = InBoundValid;
// assign cs_test_vector_0[62:60] = AdcNumber[2:0];
// assign cs_test_vector_0[59:56] = Channel[3:0];
// assign cs_test_vector_0[55:52] = ChannelAddress[3:0];
// assign cs_test_vector_0[51:40] = InternalData[11:0];
// assign cs_test_vector_0[39:28] = InBoundData[2][11:0];
// assign cs_test_vector_0[27:16] = InBoundData[1][11:0];
// assign cs_test_vector_0[15:0] = InBoundData[0][15:0];
// //---------------------------
// end
// end
// endgenerate
// //---------------------------

 

0 Kudos
Visitor
Visitor
1,480 Views
Registered: ‎06-28-2017

there is nothing really there that pertains to this logic core....

 

 

report_clock_interaction
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -1, Delay Type: max.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 4 CPUs
WARNING: [Timing 38-164] This design has multiple clocks. Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path.
Copyright 1986-2016 Xilinx, Inc. All Rights Reserved.
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2016.3 (lin64) Build 1682563 Mon Oct 10 19:07:26 MDT 2016
| Date : Tue Nov 21 13:45:18 2017
| Host : xilinx-VirtualBox running 64-bit Ubuntu 14.04.5 LTS
| Command : report_clock_interaction
| Design : design_1_wrapper
| Device : 7z010-clg400
| Speed File : -1 PRODUCTION 1.11 2014-09-11
------------------------------------------------------------------------------------

Clock Interaction Report

Clock Interaction Table
-----------------------

WNS TNS Failing TNS Total WNS Path Clock-Pair Inter-Clock
From Clock To Clock Clock Edges WNS(ns) TNS(ns) Endpoints Endpoints Requirement(ns) Classification Constraints
----------------------------- ----------------------------- ----------- ------- ------- ----------- ----------- --------------- ------------------- -----------------------
clk0_design_1_clk_wiz_0_0 clk0_design_1_clk_wiz_0_0 rise - rise 0.44 0.00 0 544 5.00 Clean Timed
clk0_design_1_clk_wiz_0_0 clk_fpga_0 rise - rise 1.53 0.00 0 36 5.00 Clean Timed
clk_fpga_0 clk0_design_1_clk_wiz_0_0 rise - rise 0.59 0.00 0 115 5.00 Clean Timed
clk_fpga_0 clk_fpga_0 rise - rise 0.41 0.00 0 19158 10.00 Clean Partial False Path
clk_fpga_0 clk_fpga_1 rise - rise 8.12 0.00 0 348 10.00 Ignored Max Delay Datapath Only
clk_fpga_1 clk_fpga_0 rise - rise 6.47 0.00 0 364 8.00 Ignored Max Delay Datapath Only
clk_fpga_1 clk_fpga_1 rise - rise 1.98 0.00 0 10255 8.00 Clean Partial False Path

 

 

with clk_fpga_0 (100Mhz) and clk_fpga_1 (125Mhz)  begin  "design_1_processing_system7_0_0_FCLK_CLK0' and "design_1_processing_system7_0_0_FCLK_CLK1"  respectively. the core in question only uses the 125 Mhz clk

0 Kudos