issue with Chipscope

[Brian Drummond]

On Fri, 03 Jul 2009 16:19:43 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> wrote:

On Fri, 3 Jul 2009 18:48:55 +0800, steve wrote:

It looks like it will not work, after adding in the library , it compiles
fine, but as soon as it links up to chipscope....
to_slv(xxx)

FATAL_ERROR:Xstortability/export/Port_Main.h:143:1.17 - This application
has discovered an exceptional condition from which it cannot recover.

That'll be a bug, then

I'd guess it's related to the use of a conversion
function in the port map, which is perfectly legal
but isn't so commonly used, so maybe has not been
debugged as thoroughly as one might hope.

Possibly because the Chipscope core is a black box, or something other than
VHDL, so XST doesn't have access to both sides of the port. I have also brought
XST down with port type conversions. Can't remember where; probably connecting
to a memory model only available in Verilog.

Try using the conversion function to put the value
onto a new std_logic_vector signal, and then hook
that signal to the appropriate ports.

Definitely the answer in this case. (More of a headache with an inout port!)

- Brian

 

[Walter]

steve escribió:

On Sat, 4 Jul 2009 06:06:43 +0800, Walter wrote
(in article <4A4E80F3.3010803@adinet.com.uy&gt:

Jonathan Bromley escribió:
On Fri, 3 Jul 2009 10:44:18 -0700 (PDT), Walter wrote:

where is the "extra" signal ?
TRIG2(x) must be directly connected to FFx;
I agree that there is no new hardware.

In the original post, steve wrote:

TRIG2(31 downto ????) => fifo_cntl_cs ,
In other words, TRIG2() is not a signal in
his design; it's a port on the ChipScope
instance. So it's impossible to write what
you suggested; it's necessary to declare
an additional signal, use the three assignments
to put the appropriate values on that signal,
and then attach that signal to the ChipScope
port.

Nothing more than that: you need to declare
a suitable signal.
I agree, as basic as I forget to mention...

Here a more "complete" simple solution to a simple problem.

..
SIGNAL TRIG2 : std_logic_vector(31 DOWNTO 0);


..
TRIG2(31) <= '1' WHEN fifo_cntl_cs = IDLE ELSE '0';
TRIG2(30) <= '1' WHEN fifo_cntl_cs = RD_REQ ELSE '0';
TRIG2(29) <= '1' WHEN fifo_cntl_cs = WR_REQ ELSE '0';

--- IN CHIPSCOPE INSTANCE ---
...
TRIG2 => TRIG2,
...

When in trainings I recommend to all write code as simple as possible,
many times "complex" solutions or no common used structures are poorly
supported or totally unsupported in one or other synthesis tool.
I like your solution as generic solution, but if I have a more
"standard" or low level solution, thinking in the synthesis tool, I take
it.

Walter.


Hi Walter,

just to let you know this was the only solution that worked out finally.

steve

Hi steve,

As Jonathan remark, you can't assign values in this form directly to a
component port.

The work around is doing with de help of an extra signal :

SIGNAL TRIG2 : std_logic_vector(31 DOWNTO 0);

make the signal assignments :

TRIG2(31) <= '1' WHEN fifo_cntl_cs = IDLE ELSE '0';
TRIG2(30) <= '1' WHEN fifo_cntl_cs = RD_REQ ELSE '0';
TRIG2(29) <= '1' WHEN fifo_cntl_cs = WR_REQ ELSE '0';

if others bits of TRIG2 still unconnected place a '0' on each, think,
the syntheses tool, the ChipScope IP mmm...? Take safe way.

and then connect the signal to CHIPSCOPE instance port with :

TRIG2 => TRIG2,

No extra logic was created (if you use one-hot encoding) your state
machine FF was conected to CHIPSCOPE trig/data inputs.


Walter

 

[Walter]

Walter escribió:

The work around is doing with de help of an extra signal :

Apologies,

"The work around is doing with help of an extra signal :"

Walter,

 

[steve]

On Sat, 4 Jul 2009 23:14:54 +0800, Walter wrote
(in article <h2nrld$2gdh$1@adenine.netfront.net&gt:

Walter escribió:


The work around is doing with de help of an extra signal :



Apologies,

"The work around is doing with help of an extra signal :"

Walter,

Hi walter , yep i got it working.

Just one last question: on an "out" port:

ram_rb : out std_logic;
ram_data_O : out std_logic_vector(7 downto 0);
ram_data_T : out std_logic;

what is the best way to tap into this to feed it into chipscope ?

Keeping in mind that there are about 20 places in the code where it is set &
unset...... tying them directly to chipscope WHEN chipscope is IN your
user_logic will not work.

Steve

 

[Rob Gaddi]

On Sat, 4 Jul 2009 06:57:32 +0800
steve <steve@aol.com> wrote:

But my main issue was the double/triple clocking of a variable that
was only supposed to clock once on a signal transition. It of course
is controlled by the only signal i could not investigate.

[snip 2: snip returns]

This is a bit outside of your original request, but "a variable that
was only supposed to clock once on a signal transition" sounds AWFULLY
a lot like the classic rookie mistake of using data signals to clock
things, rather than running everything off of a system clock and just
synchronizing the data.

That sort of thing leads to situations that a) don't show up in
simulation and b) are murderously difficult to try to hunt down.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

 

[Andy Peters]

On Jul 3, 3:52 am, steve <st...@aol.com> wrote:

On Fri, 3 Jul 2009 18:38:25 +0800, Symon wrote
(in article <h2kna0$m0...@news.eternal-september.org&gt:

Steve,
Use the 'core inserter' instead.
HTH., Syms.

It is better you do not comment if you do not read the post.

I don't understand your comment, because Symon's suggestion is exactly
what I was thinking as I read through this thread.

I've never instantiated a chipscope core in any design. I've always
used the Core Inserter, which is actually one of Xilinx' better tools.
Its main benefits are:

a) you don't have to decide in advance what signals you will always
analyze. You do it after your coding is done.

b) It's not in your HDL at all, which helps if you'd like to simulate
or whatever.

c) When you're satisfied that the design is functioning, you simply
delete the core from your project and rebuild.

-a