FPGA internal logic analyzer

[promach]

1. I am using ISE Chipscope ILA as shown in the picture below. May I know how I actually use CONTROL0 and TRIG0 signals to capture the FPGA signal that I want ? Note: I am trying to debug on this DDR memory controller project at https://github.com/promach/DDR

2. I have written my own ILA module at https://github.com/promach/internal_logic_analyzer . However, I am not sure how to code the verilog module that transmits the data to host cpu as well as the cpu software that actually processes the internally captured FPGA signals/data and display them accordingly ?

[hamster_nz]

One thing to watch out for is when you attach an ILA close to the edges of your FPGA design it can make quite dramatic changes to design timing.

It pays to compare the implementation reports and timing summary to check that weird things are not going on.

This is especially important if a design is o ly lightly constrained (e.g only the clocks are specified).

[promach]

Why is the bitstream generated successfully without error even without icon module ?

[hamster_nz]

Short answer is because the design is still valid.

The ILA connects "read-only" to the signals being probed and (silently) to the FPGA's internal JTAG chain. With out it you just get your un-instrumented design.

[promach]

Why am I having "no driver" error as shown below ?

In other words, how should I drive the CONTROL0 signal ?

[hamster_nz]

Why am I having "no driver" error as shown below ?

In other words, how should I drive the CONTROL0 signal ?

It's been a while but to properly answer you answer I would need to know the details of your design, and the process you used to add the ILA to your design.

IIRC there is two ways to add it to your design.

- You can create an IP block and add that to your RTL

- You can define your ILA probes after implementation and 'insert' the ILA into your design

I think you are trying the first way. If this is the case then you want to make sure you are can drive the signal somewhere in your design.

I never got the latter to work reliably, as nets get optimized away and names for inferred objects and signal nets keep changing or even getting optimized out of the design as the design is tweaked...
   

[promach]

You are correct, I am using the first method.

However, how should I drive the CONTROL0 signal ?

By the way, have a look at https://forums.xilinx.com/t5/Vivado-Debug-and-Power/Chipscope-ILA-Please-ensure-that-all-the-pins-used-in-the/td-p/1237426 as well*

[Someone]

UG029 explains all this very clearly
https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/chipscope_pro_sw_cores_ug029.pdf

[promach]

Adding wire [35:0] CONTROL0 seems to have solved the error 

[promach]

ALL the ILA modules that I am having now do not work.

I mean they failed to even capture the user-assigned 'clk' and 'resetn' signals. Why ?

Note: the PCB schematics could be found here

[Bassman59]

I'm just gonna say that the old ISE ChipScope and its Inserter and Analyzer were the best software tools Xilinx ever released. They were worth the money when we had to pay for them, too.

The Vivado ILA is like Vivado itself: overly complicated and uses a poorly-thought-out user interface. Same applies to the Vivado simulator.

[promach]

Chipscope is available for the free webpack license, why need to pay ?

by the way, I still could not get the ILA to be triggered even after I changed the trigger value for both 'clk' and 'resetn' signals.

Someone told me to connect BUFG in between SYS_CLK and ILA. So, I modified the ILA coding to the following.  However, I have some other error related to BUFG though.

50MHz clock crystal --> SYS_CLK --> FPGA IO pin A10 --> BUFG --> ILA

Code: [Select]

`ifdef USE_ILA
`ifdef XILINX

wire [DQ_BITWIDTH-1:0] dq_r;  // port O of IOBUF primitive
wire [DQ_BITWIDTH-1:0] dq_w;  // port I of IOBUF primitive

// Added to solve https://forums.xilinx.com/t5/Vivado-Debug-and-Power/Chipscope-ILA-unable-to-capture-signals-correctly/td-p/1237830
// ILA cannot connect directly to clk signal which originates from external FPGA IO pin
wire clk_buf;

BUFG ila_clk_buf (
.O(clk_buf),
.I(clk)
);

// Added to solve https://forums.xilinx.com/t5/Vivado-Debug-and-Power/Chipscope-ILA-Please-ensure-that-all-the-pins-used-in-the/m-p/1237451
wire [35:0] CONTROL0;
wire [35:0] CONTROL1;
wire [35:0] CONTROL2;

icon icon_inst (
.CONTROL0(CONTROL0), // INOUT BUS [35:0]
.CONTROL1(CONTROL1), // INOUT BUS [35:0]
.CONTROL2(CONTROL2)  // INOUT BUS [35:0]
);

ila ila_dq_w (
.CONTROL(CONTROL0), // INOUT BUS [35:0]
.CLK(clk_buf), // IN
.TRIG0(dq_w) // IN BUS [15:0]
);

ila_1 ila_clk (
.CONTROL(CONTROL1), // INOUT BUS [35:0]
.CLK(clk_buf), // IN
.TRIG0(clk) // IN BUS [15:0]
);

ila_1 ila_reset (
.CONTROL(CONTROL2), // INOUT BUS [35:0]
.CLK(clk_buf), // IN
.TRIG0(resetn) // IN BUS [15:0]
);

`else

// https://github.com/promach/internal_logic_analyzer

`endif
`endif

Code: [Select]

ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found
   that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock
   IOB component <clk> is placed at site <A10>. The corresponding BUFG component
   <ila_clk_buf> is placed at site <BUFGMUX_X2Y4>. There is only a select set of
   IOBs that can use the fast path to the Clocker buffer, and they are not being
   used. You may want to analyze why this problem exists and correct it. If this
   sub optimal condition is acceptable for this design, you may use the
   CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a
   WARNING and allow your design to continue. However, the use of this override
   is highly discouraged as it may lead to very poor timing results. It is
   recommended that this error condition be corrected in the design. A list of
   all the COMP.PINs used in this clock placement rule is listed below. These
   examples can be used directly in the .ucf file to override this clock rule.
   < NET "clk" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Pack:1654 - The timing-driven placement phase encountered an error.
This placement error from ISE tool is a bit strange because clk which is connected to A10 pin is not even close to any other used pins.

[Bassman59]

Chipscope is available for the free webpack license, why need to pay ?

Because once upon a time, ChipScope was not included with the free WebPack. It was a separate purchase and download. We bought a floating license for it. It is one of those things that you don't use very often, but when you need it, you're glad you have it. At some point, ChipScope became a free option. Like I said, "once upon a time."

by the way, I still could not get the ILA to be triggered even after I changed the trigger value for both 'clk' and 'resetn' signals.

You never trigger on the clock.

You shouldn't trigger on the reset, especially since the reset might be absorbed into the fabric in a way that it's not exposed to ILA.

Trigger on a signal that you're trying to analyze!

Someone told me to connect BUFG in between SYS_CLK and ILA. So, I modified the ILA coding to the following.  However, I have some other error related to BUFG though.

50MHz clock crystal --> SYS_CLK --> FPGA IO pin A10 --> BUFG --> ILA

Vivado synthesis should be smart enough to infer the BUFG, so this is not necessary.

Code: [Select]

`ifdef USE_ILA
`ifdef XILINX

Doesn't Vivado have the equivalent of the ChipScope Core Inserter, where eliminates the need to instantiate the logic analyzer cores in your code? Just use that.

[promach]

Someone suggested to change the "Position" field from 0 to something else, say 300 , and the ILA works in capturing internal FPGA signals.  May I know why ?

However, the ILA still could not trigger on dq_w signal though

[promach]

Now, I am facing sample buffer overfill (at 497241 %) issue which leads to chipscope GUI software non-responding.

How do I CLEAR the sample buffer content ?