chipscope使用tips

1、实现的时候有错误：

LUT5 symbol"DelayCntMax_mux0000<0>1" (output

  signal=DelayCntMax_mux0000<0>) has input signal"DelayCntMax_i<31>" which

  will be trimmed. See Section 5 of the Map Report File for details aboutwhy

  the input signal will become undriven.

解决方法：

1、http://www.xilinx.com/support/answers/30477.htm

This is a problem in XST. Xilinx iscurrently working on a fix.

You can work around this issue in one oftwo ways:

- Turn off the "read cores"option under Synthesis properties.

- Move both cores into the same module inthe HDL.

实践证明不管用

2、11.1 MAP - Master Answer Record for MAP Trimming IssuesAR# 23990

This Answer Record is intended to cover allaspects of trimming and optimization during MAP. 

What is logic trimming?

Logic trimming is the removal of logic thatis unused because it has no driver, no load, or no effect on any chip outputs.For example, a state machine whose outputs are used only as feedback to itsinputs can be removed without affecting the operation of the design.

What is constant optimization?

Constant optimization occurs when logic isremoved or modified due to a constant input signal. For example, if a flip-flopis driving a LUT input, where the flip-flop data input is GND, INIT=0, andthere is no Reset, the flip-flop can be removed and replaced with a constantGND. The LUT input can in turn be removed and the LUT equation simplified.

Section 4 of the MAP report (.mrp) is asummary of removed logic. Section 5 is a detailed list of removed logic.

What are the known problem areas for trimming andoptimization?

Validtrimming of unused logic - The most common reasonfor valid trimming is that a net has no driver or load and so it is unused, ora logical block is undriven or unloaded and so it is unused. This results in acascade of trimming as the next element in the path becomes undriven orunloaded. The Removed Logic section (the trim report), "Section 5" ofthe MAP report (.mrp), attempts to track the sequence of trimming events byindenting a line if it is dependent on a previous line. An unindented line canbe considered a starting point of trimming. This cause-and-effect sequencing isnot always accurate. The order is sometimes reversed.

The signal"xyz/trn_rbar_hit_n<6>" is loadless and has been removed.

Loadless block "xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit_i[6]"(BUF) removed.

The signal"xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit<6>" is loadless andhas been removed.

Loadless block"xyz/com/tlm/u_tlm_rx/vc0/fifo/bar_d[6]" (FF) removed.

The signal "xyz/trn_rbar_hit_n<5>"is loadless and has been removed.

Loadless block"xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit_i[5]" (BUF) removed.

The signal"xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit<5>" is loadless andhas been removed.

 

Validcycle trimming - MAP will correctly trim any logicthat feeds back on itself without ever driving anything off-chip, even if everysignal has a driver and load. This logic is referred to as a "cycle",and this term may appear in the trimming section of the MAP report (.mrp).

Invalidtrimming of memory feedback paths - Problems haveoccurred when one Dual Port RAM output feeds back to the data input while theother drives used logic. MAP incorrectly identifies this as a cycle (seeabove), and trims the RAM and logic driven by the RAM. For more information,including an environment variable work-around, see (Xilinx Answer 23284).

Validtrimming to LUT inputs - If a path is trimmed to aLUT input, MAP fails with the following errors:

"ERROR:MapLib:820 - LUT2 symbol"b2.rp_3_i_m2[0]" (output signal=rp_3_i_m2(0)) has an equation thatuses input pin I0, which no longer has a connected signal. Please ensure thatall the pins used in the equation for this LUT have signals that are nottrimmed (see trim report for details on which signals were trimmed)."

or

"ERROR:MapLib:661 - LUT3 symbol"i_vio/vio/i_vio/gen_sync_in/32/sync_in_cell/async_f_mux" (outputsignal=i_vio/i_vio/gen_sync_in/32/sync_in_cell/async_mux_f_out) has inputsignal "i_vio/i_vio/gen_sync_in/32/sync_in_cell/falling_out" whichwill be trimmed. See the trim report for details about why the input signalwill become undriven."

or

"ERROR:MapLib:979 - LUT2 symbol<instance name> has an equation that uses input pin I1 which no longerhas a connected signal. Please ensure that all the pins used in the equationfor this LUT have signals that are not trimmed (see Section 5 of the Map Reportfile for details on which signals were trimmed)."

or

ERROR:MapLib:978 - LUT4 symbol <instancename> has an equation that uses input pin I3, which no longer has aconnected signal. Please ensure that all the pins used in the equation for thisLUT have signals that are not trimmed (see Section 5 of the Map Report File fordetails on which signals were trimmed).

These errors occur because simulation isused to perform trimming calculations and it is not valid to simulate anequation with non-existent terms.

l  The KEEP attribute does not block trimming - A common misconceptionis that KEEP properties can be used to block signal trimming. The KEEP propertycan be used to prevent a signal from being absorbed into a component, but ithas no effect on trimming behavior. The correct attribute to block trimming is"S" (AKA Save, SAVESIG, NOCLIP).

l  Beginning with ISE version 10.1, the S attribute not only blockstrimming, but also constant optimization. The S property can be applieddirectly to a logical block, or to a net attached to a logical block to preventboth constant optimization or trimming.

l  Pin preassignment blocks trimming - The existence of LOC constraintson unused I/O logic triggers a new feature referred to as "PinPreassignment". The unused I/O is no longer removed so that designers canwork on board layout with only the I/O logic defined. If trimming is desired,LOC constraints should be removed.

l  KEEP HIERARCHY - Several trimming issues have been experiencedrelated to KEEP HIERARCHY constraints. Simulation is used to drive trimmingbehavior, and KH constraints have been known to cause problems withsimulations, and therefore, trimming behavior. Try disabling KH(-ignore_keep_hierarchy) during MAP to see if a trimming problem depends onthis feature.

Newtrimming behavior in 10.1 might cause signals that should be trimmed to not betrimmed; this can lead to a variety of DRC warnings and errors including:

"ERROR:PhysDesignRules:1577 - Illegalrouting. The DCM_ADV block<i_srl_top/i_srl_pcix_clk_wrap/i_pci_clk_fpga/DCM_BASE_pci_clk/DCM_ADV>has CLK output pin <CLK90> with incomplete or incorrect connectivity.Routing from the <CLK90> pin to a BUFG, BUFGCTRL or PLL_ADV block typewas not found. The DCM_ADV CLK output pins can only route to BUFG, BUFGCTRL orPLL_ADV block types."

If a design has no output pad connections,the entire design is "unused" and will be trimmed, leading to one ofthe following MAP Pack errors:

"ERROR:Pack:198 - NCD was notproduced. All logic was removed from design. This is usually due to having noinput or output PAD connections in the design and no nets or symbols marked as'SAVE'. You can either add PADs or 'SAVE' attributes to the design, or run 'map-u' to disable logic trimming in the mapper."

"ERROR:Map:116 - The design isempty."

Debugging valid trimming behavior

If a certain trimming behavior isunexpected and the Removed Logic section of the MAP report file does notprovide sufficient information, it is possible to use an iterative debuggingtechnique to track down the source of trimming:

A. Choose a logical instance involved inthe unexpected trimming and apply an "S" property to all signalsattached to the instance. In the case of the LUT error mentioned in (4) above,it might be necessary to repeat for every failing LUT in the design for thefirst pass. For example, the following UCF constraints would work for a LUT2instance: 

NET "net_name_1" S ; # I0 inputof LUT xyz

NET "net_name_2" S ; # I1 inputof LUT xyz

NET "net_name_3" S ; # O outputof LUT xyz

Run MAP and PAR on the design (disablerouting to save time) and load the placed NCD file in FPGA Editor.

Examine the component containing theinstance chosen in step A and examine the signal connectivity. One or more ofthe signals involved will have either no driver or load and is an indication ofthe source of trimming for this instance. This may contradict the trim reportin the ".mrp" file.

After identifying the signal trimmingsource, trace through that signal in the logical design to the next instance inthe path and repeat step A.

Continue with this iterative process untilthe ultimate source of the trimming is reached.

NOTE: If you suspect that a flip-flop isbeing trimmed because it will never change state, this can be confirmed bychanging the INIT value of the flip-flop and noting any change in the trimbehavior; this is a diagnostic test, not a work-around. Similarly, the trimmingbehavior related to a LUT can be tested by changing the LUT INIT state:

INST "ff_name" INIT=1 ;

Solution

Links to Answer Records for specific knowntrimming and optimization problems:

(Xilinx Answer 20350) - Removed LogicSummary is misleading about the source of logic trimming

(Xilinx Answer 17765) - A change in thefunctionality of the MAP "-u" switch that disables logic trimming

(Xilinx Answer30112) - New SAVE behavior in 10.1

(Xilinx Answer 31574) - Lack of trimming onDCM_ADV output signals leads to "ERROR:PhysDesignRules:1577 - Illegalrouting"

(Xilinx Answer 33743) - Change in trimmingbehavior for IBUFDS_GTXE1 components in 11.3

(Xilinx Answer 34352) - Optimization ofLUT6_2 inputs mishandled leading to trimming errors

 

 

 

1、在综合时去掉KH果然消除了很多错误，但是还是有错误。

2、使用map中的ingore KH和Global optimization之后，发现了一个错误。

Xst:2887 -Input pin I1 of

  i_icon/U0/U_ICON/U_TDO_MUX/U_CS_MUX/I4.U_MUX16/Mmux_O3_SW5 isunconnected.

  The function of the LUT depends on this pin. Leaving this pinunconnected

  will result in unpredictable behaviour. The pin has been tied off tologic

  zero to remove this unpredictability.

可能i_icon不用ucf。因为jtag脚特殊，不用指定。

 

这个trim导致的问题，必须通过untrim来实现。

在map报告的section5找到被误trim掉的信号，和错误信息中报告的信号，加上S属性（Save net）来保存之。

在源文件中的信号通过VHDL的attribute或Verilog的(* *)来加约束，但是在ngc文件中的就只能通过.ucf来加约束了。

 

S属性语法：

verilog：

(* S = "YES" *)wire control_vio2;

UCF：

Net “Signal_name” S;

 

 

最终原因是：verilog语法错误：信号声明缺位数，导致赋值时两侧信号位数不匹配。导致一些不该删减的逻辑因为没有用到而被删减。

使用Chipscope核，如不注意，经常出现这种输入信号被trim的error。

2、VIO核

VIO的输出，在ChipScope软件里面显示的数据是不可靠的。

因为换掉usb后，它显示的值并不会变化，不反映当前信号的值。所以，VIO的输出不能用于显示输出的信号的值！！！

3、在调试的时候

调试的时候，特别是刚开始调试的时候，要把所有相关信号都加进去，别怕麻烦。

否则如果你少加一个信号，那么还得重新编译，更加浪费时间。

4、Chipscope 的GUI中Bus的显示

它是按照从下到上来显示为16进制的。其实是按照signal位号来显示的。

它是这样的：

定义的时候的trig与GUI里面的port是如下对应的：

每一个trig对应一组port，根据trig的位宽。比如：trig0：8bit，trig1：2bit，那么trig0->port0~7,trig1-> port8~9。

每一个trig内部，按照高低位来对应。比如：trig0:8bit,trig1:2bit；trig0连接了一个4bit的信号A，那么A[3:0]~port[3:0]。

5、一个新的使用ChipScope的方法

将ChipScope例化到每一个模块里面去，并将关键信号连接。

使用`define来控制这例化是否生效。

仅将36bit的inout的CONTROL信号连接到最外面，这个端口的连接也用`ifdefine来控制是否生效。

最后在顶层将需要观察的模块的ChipScope连接到ICON上就可以了。