Xilinx ChipScope Tutorial

Hello All,

I have written one simple tutorial which will give students quick hands on session for using xilinx's ChipScope Pro. Have a look at it :

**broken link removed**

Comments/suggestions appreciated.

elecrom said:

Hello All,

I have written one simple tutorial which will give students quick hands on session for using xilinx's ChipScope Pro. Have a look at it :

**broken link removed**

Comments/suggestions appreciated.

Click to expand...

Hi could you please post a VIO core example ?

Maybe anyone has seen or made similar manual for signaltap?

blooz said:

Hi could you please post a VIO core example ?

Click to expand...

You could check out these youtube vids from xilinx:

YouTube - How to use ChipScope Pro - (Ch 1)
YouTube - How to use ChipScope Pro - (Ch 2)
YouTube - How to use ChipScope Pro - (Ch 3)

Together with DS284 on chipscope VIO that should get you started pretty quickly. Worked for me about 1 month ago...

hope that helps!

PS: personally I use instantiation of the primitives, instead of blahflowblah to randomly insert it. Instantiating it yourself comes with the price of reading the fine manual, and has as advantage more predictability, less surprises IMO.

Is it necessary to do a pin assignment When we use ....Chipscope debug cores ...today I experimented with spartan 3 ..kit .....did not the pin assignment stage just skipped ...just used the vio core and assigned to vio core the signals to monitored as well as the signals to be driven into the hardware ....everything went fine ..able to implement the design in FPGA but the signals doesn't change even after changing the status of toggle buttons ...etc .skipping the pin assignment stage the real trouble ?......

If you are worried that some signals are trimmed then you should check the synthesis logs. If the signal of interest is optimized away it will tell you so.

But to answer your specific question, no you do not need an assignment to an external pin to be able to view a signal with chipscope. That is part of why it's so useful. You can look at internal signals without having to route them outside to a pin.

Also, I don't know if you are used to working with fpga editor, but I can recommend spending the time learning it. Whenever I get paranoid about things getting optimized in the manner of NOT-HOW-I-WANT-IT, then I find fpga editor to be very useful.

So the Key point is to learn ..FPGA Editor in order to have better idea....

If your main problem is that you don't see anything happening when you toggle the VIO bits in chipscope, then the first order of business is to check if the signal you are interested in has not been optimized away and is actually connected. For the "check if it was optimized" away, you don't need fpga editor. You can just check the synthesis logs / ISE console if you see a warning about that signal you are interested in.

I meant FPGA Editor more as a (IMO) very useful tool in case of weird stuff happening. Nothing beats being able to see what was actually placed & routed for debugging the weird stuff. Plus it gives you a better "gut feeling" for "when I write this HDL + those constraints, I get this.

But like I said, first I would check the basic stuff.

Also, if this is the first use of VIO's + chipscope, it might be a good plan to first make a little test project with just 1 module, a few registers with simple logic, and hook that up with chipscope. That's precisely what I did when learning chipscope. It saves you a whole lot of assumptions during a first attempt to learn something new.

mrflibble said:

If your main problem is that you don't see anything happening when you toggle the VIO bits in chipscope, then the first order of business is to check if the signal you are interested in has not been optimized away and is actually connected. For the "check if it was optimized" away, you don't need fpga editor. You can just check the synthesis logs / ISE console if you see a warning about that signal you are interested in.

I meant FPGA Editor more as a (IMO) very useful tool in case of weird stuff happening. Nothing beats being able to see what was actually placed & routed for debugging the weird stuff. Plus it gives you a better "gut feeling" for "when I write this HDL + those constraints, I get this.

But like I said, first I would check the basic stuff.

Also, if this is the first use of VIO's + chipscope, it might be a good plan to first make a little test project with just 1 module, a few registers with simple logic, and hook that up with chipscope. That's precisely what I did when learning chipscope. It saves you a whole lot of assumptions during a first attempt to learn something new.

Click to expand...

yes it was the problem ..even if the bits are toggled ....it does not have any impact on output...it seems .dead ....there was a couple of synthesis messages ....Which dealt with trimming ....so i have to turn off the optimization .....

today i tried to implement a simple one AND gate

but same thing happened could not get the output in chipscope ...


the error messages were

___________________________________
___________________________________

Synthesis Messages Wed Feb 23 17:16:34 2011

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

Synthesis Messages - Errors, Warnings, and Infos New
WARNING Xst:2211 - "C:/Users/FPGA/Desktop/and_debug/icon_01.v" line 12: Instantiating black box module <icon_01>. New
WARNING Xst:2211 - "ipcore_dir/vio_1.v" line 17: Instantiating black box module <vio_1>. New
WARNING Xst:646 - Signal <ASYNC_OUT> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
INFO Xst:2169 - HDL ADVISOR - Some clock signals were not automatically buffered by XST with BUFG/BUFR resources. Please use the buffer_type constraint in order to insert these buffers to the clock signals to help prevent skew problems.
WARNING Xst:616 - Invalid property "SYN_BLACK_BOX 1": Did not attach to D1.
WARNING Xst:616 - Invalid property "SYN_NOPRUNE 1": Did not attach to D1.
WARNING Xst:616 - Invalid property "SYN_BLACK_BOX 1": Did not attach to D2.
WARNING Xst:616 - Invalid property "SYN_NOPRUNE 1": Did not attach to D2.
_____________________________________________
______________________________________________

place and route messages


Place and Route Messages Wed Feb 23 17:15:28 2011

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

Place and Route Messages - Errors, Warnings, and Infos New
INFO Timing:3386 - Intersecting Constraints found and resolved. For more information, see the TSI report. Please consult the Xilinx Command Line Tools User Guide for information on generating a TSI report.
WARNING Par:288 - The signal D2/U0/I_VIO/UPDATE<1> has no load. PAR will not attempt to route this signal.
WARNING Par:288 - The signal D2/U0/I_VIO/UPDATE<0> has no load. PAR will not attempt to route this signal.
INFO Timing:2761 - N/A entries in the Constraints List may indicate that the constraint is not analyzed due to the following: No paths covered by this constraint; Other constraints intersect with this constraint; or This constraint was disabled by a Path Tracing Control. Please run the Timespec Interaction Report (TSI) via command line (trce tsi) or Timing Analyzer GUI.
WARNING Route:455 - CLK Net:c_OBUF may have excessive skew because 2 CLK pins and 1 NON_CLK pins failed to route using a CLK template.
INFO Timing:2761 - N/A entries in the Constraints List may indicate that the constraint is not analyzed due to the following: No paths covered by this constraint; Other constraints intersect with this constraint; or This constraint was disabled by a Path Tracing Control. Please run the Timespec Interaction Report (TSI) via command line (trce tsi) or Timing Analyzer GUI.
WARNING ParHelpers:361 - There are 2 loadless signals in this design. This design will cause Bitgen to issue DRC warnings.
WARNING Par:283 - There are 2 loadless signals in this design. This design will cause Bitgen to issue DRC warnings.


____________________________________
____________________________________

map messages


Map Messages Wed Feb 23 17:17:51 2011

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

Map Messages - Errors, Warnings, and Infos New
INFO LIT:243 - Logical network D2/ASYNC_OUT<1> has no load.
INFO LIT:395 - The above info message is repeated 1 more times for the following (max. 5 shown): D2/ASYNC_OUT<0> To see the details of these info messages, please use the -detail switch.
INFO MapLib:562 - No environment variables are currently set.
INFO LIT:244 - All of the single ended outputs in this design are using slew rate limited output drivers. The delay on speed critical single ended outputs can be dramatically reduced by designating them as fast outputs.
WARNING PhysDesignRules:372 - Gated clock. Clock net c_OBUF is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.
WARNING PhysDesignRules:367 - The signal <D2/U0/I_VIO/UPDATE<1>> is incomplete. The signal does not drive any load pins in the design.
WARNING PhysDesignRules:367 - The signal <D2/U0/I_VIO/UPDATE<0>> is incomplete. The signal does not drive any load pins in the design.



________________________________________________
________________________________________________


bitgen messages



Bitgen Messages Wed Feb 23 17:18:34 2011

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

Bitgen Messages - Errors, Warnings, and Infos New
INFO Bitgen:40 - Replacing "Auto" with "NoWait" for option "Match_cycle". Most commonly, bitgen has determined and will use a specific value instead of the generic command-line value of "Auto". Alternately, this message appears if the same option is specified multiple times on the command-line. In this case, the option listed last will be used.
WARNING PhysDesignRules:372 - Gated clock. Clock net c_OBUF is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.
WARNING PhysDesignRules:367 - The signal <D2/U0/I_VIO/UPDATE<1>> is incomplete. The signal does not drive any load pins in the design.
WARNING PhysDesignRules:367 - The signal <D2/U0/I_VIO/UPDATE<0>> is incomplete. The signal does not drive any load pins in the design.

WARNING Xst:616 - Invalid property "SYN_BLACK_BOX 1": Did not attach to D1.
WARNING Xst:616 - Invalid property "SYN_NOPRUNE 1": Did not attach to D1.

Click to expand...

Unless you are using Synplify, those properties won't do much...

WARNING Xst:646 - Signal <ASYNC_OUT> is assigned but never used. This unconnected signal will be trimmed during the optimization process.

Click to expand...

That seems to be problem number 1.

Try adding this to your .ucf file (or make a new one if you don't have one yet):


Also, check the constraints guide for the "SAVE" attribute.

hi ...

the code used is as follows /////////////////////////////
////////////////////////////////////////////////////////////
`timescale 1ns / 1ps

module xor_test( a,b,c);
input a,b;
output c;
reg c;
wire [35:0] CONTROL0 ;
wire [0:0] ASYNC_IN;
wire [1:0] ASYNC_OUT;

chipscope_icon U1 (
.CONTROL0(CONTROL0) // INOUT BUS [35:0]
);
chipscope_vio U2 (
.CONTROL(CONTROL0), // INOUT BUS [35:0]
.ASYNC_IN(ASYNC_IN), // IN BUS [0:0]
.ASYNC_OUT(ASYNC_OUT) // OUT BUS [1:0]
);
assign ASYNC_IN[0:0]=c;
assign ASYNC_OUT[1:0]={a,b};
always@(a or b)
begin
c=a^b;
end
endmodule
/////////////////////////////////////

Are you sure you are not confusing inputs and outputs?

For one, this part can never be right:


Since a,b are input and c is an output, I'd expect one of the assignments to swap left and right argument.

As in:

or something like that...

blooz said:

Hi could you please post a VIO core example ?

Click to expand...

Another good tutorial on VIO: **broken link removed**

Thank you Jack and Mr fibble ....As per the suggestion of Fibble the bug pointed out by him...fixed ..it was resolved and now the design works perfectly able to see the chipscope VIO core and virtual console ...

A couple changes were made to the code ...

A top level module was formed and the design under test was instantiated under it and entire code restructured as below ....and I followed the convention used in the Stanford chipscope tutorial ...

//top module
//top module wire deceleration
//Desiign under test Instantiation
//Icon core wire decelerations
//VIO core wire Decelerations
//Signal Assignments connecting VIO and Design under test
//ICON core Instance
//VIO core Instance
end topmodule

Glad you got it working blooz.

On the subject of chipscope... does anyone know good examples or tutorials for using Tcl/Tk scripts with chipscope?

Pressing buttons in the gui and having things happen is useful already, but I would like to do some automated testing via chipscope. So I would like to use Tcl/Tk for that, but I could not find an good example...

Also, thanks for the link Jack. Useful tutorial!

For smaller Design the Chipscope VIO Core Works fine ...But When i used the core to analyze a much bigger design an Instruction decoder for a 8 bit RISC system ......the output changes are so fast that i cannot actually figure out the output ...
Asynchronous input and output were used ......

That has nothing to do with big or small designs, but more with toggle rate. If you want to capture a bunch of high speed signals, then you probably should take a look at the chipscope ILA. That can capture your signals to BRAM, and then read it at your convenience...

https://www.xilinx.com/support/documentation/ip_documentation/chipscope_ila.pdf

the design under test was
//////////////////////////////////////////////////////
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\


//
// Copyright (c) 1999 Thomas Coonan (tcoonan@mindspring.com)
//
// This source code is free software; you can redistribute it
// and/or modify it in source code form under the terms of the GNU
// General Public License as published by the Free Software
// Foundation; either version 2 of the License, or (at your option)
// any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
//

module idec (
inst,
aluasel,
alubsel,
aluop,
wwe,
fwe,
zwe,
cwe,
bdpol,
option,
tris
);

input [11:0] inst;

output [1:0] aluasel;
output [1:0] alubsel;
output [3:0] aluop;
output wwe;
output fwe;
output zwe;
output cwe;
output bdpol;
output option;
output tris;

reg [14:0] decodes;

// For reference, the ALU Op codes are:
//
// ADD 0000
// SUB 1000
// AND 0001
// OR 0010
// XOR 0011
// COM 0100
// ROR 0101
// ROL 0110
// SWAP 0111

assign { aluasel, // Select source for ALU A input. 00=W, 01=SBUS, 10=K, 11=BD
alubsel, // Select source for ALU B input. 00=W, 01=SBUS, 10=K, 11="1"
aluop, // ALU Operation (see comments above for these codes)
wwe, // W register Write Enable
fwe, // File Register Write Enable
zwe, // Status register Z bit update
cwe, // Status register Z bit update
bdpol, // Polarity on bit decode vector (0=no inversion, 1=invert)
tris, // Instruction is an TRIS instruction
option // Instruction is an OPTION instruction
} = decodes;

// This is a large combinatorial decoder.
// I use the casex statement.

always @(inst) begin
casex (inst) // synopsys parallel_case
// *** Byte-Oriented File Register Operations
//
// A A ALU W F Z C B T O
// L L O W W W W D R P
// U U P E E E E P I T
// A B O S
// L
12'b0000_0000_0000: decodes = 15'b00_00_0000_0_0_0_0_0_0_0; // NOP
12'b0000_001X_XXXX: decodes = 15'b00_00_0010_0_1_0_0_0_0_0; // MOVWF
12'b0000_0100_0000: decodes = 15'b00_00_0011_1_0_1_0_0_0_0; // CLRW
12'b0000_011X_XXXX: decodes = 15'b00_00_0011_0_1_1_0_0_0_0; // CLRF
12'b0000_100X_XXXX: decodes = 15'b01_00_1000_1_0_1_1_0_0_0; // SUBWF (d=0)
12'b0000_101X_XXXX: decodes = 15'b01_00_1000_0_1_1_1_0_0_0; // SUBWF (d=1)
12'b0000_110X_XXXX: decodes = 15'b01_11_1000_1_0_1_0_0_0_0; // DECF (d=0)
12'b0000_111X_XXXX: decodes = 15'b01_11_1000_0_1_1_0_0_0_0; // DECF (d=1)
12'b0001_000X_XXXX: decodes = 15'b00_01_0010_1_0_1_0_0_0_0; // IORWF (d=0)
12'b0001_001X_XXXX: decodes = 15'b00_01_0010_0_1_1_0_0_0_0; // IORWF (d=1)
12'b0001_010X_XXXX: decodes = 15'b00_01_0001_1_0_1_0_0_0_0; // ANDWF (d=0)
12'b0001_011X_XXXX: decodes = 15'b00_01_0001_0_1_1_0_0_0_0; // ANDWF (d=1)
12'b0001_100X_XXXX: decodes = 15'b00_01_0011_1_0_1_0_0_0_0; // XORWF (d=0)
12'b0001_101X_XXXX: decodes = 15'b00_01_0011_0_1_1_0_0_0_0; // XORWF (d=1)
12'b0001_110X_XXXX: decodes = 15'b00_01_0000_1_0_1_1_0_0_0; // ADDWF (d=0)
12'b0001_111X_XXXX: decodes = 15'b00_01_0000_0_1_1_1_0_0_0; // ADDWF (d=1)
12'b0010_000X_XXXX: decodes = 15'b01_01_0010_1_0_1_0_0_0_0; // MOVF (d=0)
12'b0010_001X_XXXX: decodes = 15'b01_01_0010_0_1_1_0_0_0_0; // MOVF (d=1)
12'b0010_010X_XXXX: decodes = 15'b01_01_0100_1_0_1_0_0_0_0; // COMF (d=0)
12'b0010_011X_XXXX: decodes = 15'b01_01_0100_0_1_1_0_0_0_0; // COMF (d=1)
12'b0010_100X_XXXX: decodes = 15'b01_11_0000_1_0_1_0_0_0_0; // INCF (d=0)
12'b0010_101X_XXXX: decodes = 15'b01_11_0000_0_1_1_0_0_0_0; // INCF (d=1)
12'b0010_110X_XXXX: decodes = 15'b01_11_1000_1_0_0_0_0_0_0; // DECFSZ(d=0)
12'b0010_111X_XXXX: decodes = 15'b01_11_1000_0_1_0_0_0_0_0; // DECFSZ(d=1)
12'b0011_000X_XXXX: decodes = 15'b01_01_0101_1_0_0_1_0_0_0; // RRF (d=0)
12'b0011_001X_XXXX: decodes = 15'b01_01_0101_0_1_0_1_0_0_0; // RRF (d=1)
12'b0011_010X_XXXX: decodes = 15'b01_01_0110_1_0_0_1_0_0_0; // RLF (d=0)
12'b0011_011X_XXXX: decodes = 15'b01_01_0110_0_1_0_1_0_0_0; // RLF (d=1)
12'b0011_100X_XXXX: decodes = 15'b01_01_0111_1_0_0_0_0_0_0; // SWAPF (d=0)
12'b0011_101X_XXXX: decodes = 15'b01_01_0111_0_1_0_0_0_0_0; // SWAPF (d=1)
12'b0011_110X_XXXX: decodes = 15'b01_11_0000_1_0_0_0_0_0_0; // INCFSZ(d=0)
12'b0011_111X_XXXX: decodes = 15'b01_11_0000_0_1_0_0_0_0_0; // INCFSZ(d=1)

// *** Bit-Oriented File Register Operations
//
// A A ALU W F Z C B T O
// L L O W W W W D R P
// U U P E E E E P I T
// A B O S
// L
12'b0100_XXXX_XXXX: decodes = 15'b11_01_0001_0_1_0_0_1_0_0; // BCF
12'b0101_XXXX_XXXX: decodes = 15'b11_01_0010_0_1_0_0_0_0_0; // BSF
12'b0110_XXXX_XXXX: decodes = 15'b11_01_0001_0_0_0_0_0_0_0; // BTFSC
12'b0111_XXXX_XXXX: decodes = 15'b11_01_0001_0_0_0_0_0_0_0; // BTFSS

// *** Literal and Control Operations
//
// A A ALU W F Z C B T O
// L L O W W W W D R P
// U U P E E E E P I T
// A B O S
// L
12'b0000_0000_0010: decodes = 15'b00_00_0010_0_1_0_0_0_0_1; // OPTION
12'b0000_0000_0011: decodes = 15'b00_00_0000_0_0_0_0_0_0_0; // SLEEP
12'b0000_0000_0100: decodes = 15'b00_00_0000_0_0_0_0_0_0_0; // CLRWDT
12'b0000_0000_0101: decodes = 15'b00_00_0000_0_1_0_0_0_1_0; // TRIS 5
12'b0000_0000_0110: decodes = 15'b00_00_0010_0_1_0_0_0_1_0; // TRIS 6
12'b0000_0000_0111: decodes = 15'b00_00_0010_0_1_0_0_0_1_0; // TRIS 7
//
// A A ALU W F Z C B T O
// L L O W W W W D R P
// U U P E E E E P I T
// A B O S
// L
12'b1000_XXXX_XXXX: decodes = 15'b10_10_0010_1_0_0_0_0_0_0; // RETLW
12'b1001_XXXX_XXXX: decodes = 15'b10_10_0010_0_0_0_0_0_0_0; // CALL
12'b101X_XXXX_XXXX: decodes = 15'b10_10_0010_0_0_0_0_0_0_0; // GOTO
12'b1100_XXXX_XXXX: decodes = 15'b10_10_0010_1_0_0_0_0_0_0; // MOVLW
12'b1101_XXXX_XXXX: decodes = 15'b00_10_0010_1_0_1_0_0_0_0; // IORLW
12'b1110_XXXX_XXXX: decodes = 15'b00_10_0001_1_0_1_0_0_0_0; // ANDLW
12'b1111_XXXX_XXXX: decodes = 15'b00_10_0011_1_0_1_0_0_0_0; // XORLW

default:
decodes = 15'b00_00_0000_0_0_0_0_0_0_0;
endcase
end

endmodule
/////////////////////////////////////
////////////////////////////////////

I noticed the "casex" and "synopsys parallel_case" in there. Before you pick up bad habits based on that code, you might want to read this one:

http://www.sunburst-design.com/papers/CummingsSNUG1999Boston_FullParallelCase.pdf

Short version: don't use casex and don't use parallel_case.