issue with Chipscope

S

steve

Guest
Hi,
I'm new to FPGA design but I have a minor issue with chipscope .


To get access 'inside' the user core i use 'core generator' followed by the
usual incantations of sticking the pre-generated deffs at the start of the
user_logic. (who thought up this half assed system?)

Then I break my signals out and mask into chipscope (all is well with the
world for 90% of my signals).

BUT I have the following user enumerated types

type FIFO_CNTL_SM_TYPE is (IDLE, RD_REQ, WR_REQ);


signal fifo_cntl_ns : FIFO_CNTL_SM_TYPE;

signal fifo_cntl_cs : FIFO_CNTL_SM_TYPE;

how do i mask this damned thing into chipscope, I just get errors about the
types not matching,.

TRIG2(31 downto ????) => fifo_cntl_cs ,

Thanks

steve
 
steve wrote:

Then I break my signals out and mask into chipscope (all is well with the
world for 90% of my signals).
BUT I have the following user enumerated types

type FIFO_CNTL_SM_TYPE is (IDLE, RD_REQ, WR_REQ);
signal fifo_cntl_ns : FIFO_CNTL_SM_TYPE;
signal fifo_cntl_cs : FIFO_CNTL_SM_TYPE;

how do i mask this damned thing into chipscope, I just get errors about the
types not matching,.
Click to expand...
The synthesis report has the state encodings.
Next time, try vhdl simulation, and you can use the enum names directly.

-- Mike Treseler
 
On Fri, 3 Jul 2009 09:19:32 +0800, steve wrote:

BUT I have the following user enumerated types

type FIFO_CNTL_SM_TYPE is (IDLE, RD_REQ, WR_REQ);
signal fifo_cntl_cs : FIFO_CNTL_SM_TYPE;

how do i mask this damned thing into chipscope, I just get errors about the
types not matching,.

TRIG2(31 downto ????) => fifo_cntl_cs ,
Click to expand...
You need a conversion function.

TRIG2(31 downto 29) => to_slv(fifo_cntl_cs),

You don't want to introduce any additional logic if you
can avoid it, so it makes sense for the conversion
function to match the internal encoding that XST has
created - see Mike's post.

In practice that's likely to be one-hot. So you could do
something like this in which each output represents one
state. It has the advantage that it won't
need to be rewritten if you add or change state names:

function to_slv(code: FIFO_CNTL_SM_TYPE)
return std_logic_vector
is
constant LAST: integer :=
FIFO_CNTL_SM_TYPE'POS(FIFO_CNTL_SM_TYPE'HIGH);
variable result: std_logic_vector(0 to LAST);
begin
result := (others => '0');
result(FIFO_CNTL_SM_TYPE'POS(code)) := '1';
return result;
end;

If you're short of pins on the ChipScope, you could
simply convert the integer FIFO_CNTL_SM_TYPE'POS(code)
to a std_logic_vector and put that out instead.

XST is happy with the 'POS and 'HIGH attributes; I'm
not sure it will be OK in all synthesis tools,
although there's really no excuse for it not being.

Do be aware that adding any such decoder, to observe
an enumerated signal, may change the optimization
so that the enumeration is encoded differently.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
On Fri, 3 Jul 2009 12:31:13 +0800, Mike Treseler wrote
(in article <7b5fs9F224u62U1@mid.individual.net>):

steve wrote:

Then I break my signals out and mask into chipscope (all is well with the
world for 90% of my signals).
BUT I have the following user enumerated types

type FIFO_CNTL_SM_TYPE is (IDLE, RD_REQ, WR_REQ);
signal fifo_cntl_ns : FIFO_CNTL_SM_TYPE;
signal fifo_cntl_cs : FIFO_CNTL_SM_TYPE;

how do i mask this damned thing into chipscope, I just get errors about the
types not matching,.

The synthesis report has the state encodings.
Next time, try vhdl simulation, and you can use the enum names directly.

-- Mike Treseler
Click to expand...
Hi Mike,

I don't want to simulate it , because i have a 'double clocking' bug that
does not show up in simulation, this has to be a hardware probe, into
User_logic,.
These signals do not show up due to them being optimized out.

We are talking about direct injection of the chipscope core into the user
logic, not it sitting externally.
 
On Fri, 3 Jul 2009 16:55:47 +0800, Jonathan Bromley wrote
(in article <isgr45p80p9t0fgcsqe03k4537lk68ffc3@4ax.com>):

On Fri, 3 Jul 2009 09:19:32 +0800, steve wrote:

BUT I have the following user enumerated types

type FIFO_CNTL_SM_TYPE is (IDLE, RD_REQ, WR_REQ);
signal fifo_cntl_cs : FIFO_CNTL_SM_TYPE;

how do i mask this damned thing into chipscope, I just get errors about the
types not matching,.

TRIG2(31 downto ????) => fifo_cntl_cs ,

You need a conversion function.

TRIG2(31 downto 29) => to_slv(fifo_cntl_cs),

You don't want to introduce any additional logic if you
can avoid it, so it makes sense for the conversion
function to match the internal encoding that XST has
created - see Mike's post.

In practice that's likely to be one-hot. So you could do
something like this in which each output represents one
state. It has the advantage that it won't
need to be rewritten if you add or change state names:

function to_slv(code: FIFO_CNTL_SM_TYPE)
return std_logic_vector
is
constant LAST: integer :=
FIFO_CNTL_SM_TYPE'POS(FIFO_CNTL_SM_TYPE'HIGH);
variable result: std_logic_vector(0 to LAST);
begin
result := (others => '0');
result(FIFO_CNTL_SM_TYPE'POS(code)) := '1';
return result;
end;

If you're short of pins on the ChipScope, you could
simply convert the integer FIFO_CNTL_SM_TYPE'POS(code)
to a std_logic_vector and put that out instead.

XST is happy with the 'POS and 'HIGH attributes; I'm
not sure it will be OK in all synthesis tools,
although there's really no excuse for it not being.

Do be aware that adding any such decoder, to observe
an enumerated signal, may change the optimization
so that the enumeration is encoded differently.
Click to expand...
Hi Jonathan,

Thanks for your concise description, it's exactly the guidance I needed.
Being new to FPGA's I did not realize how gash these tools were.

As regards , changing the logic/ optimization, I'm already aware of that.
when I try and put my chipscope external to my user_logic and probe
internally, sometimes the stuff is accessible , other times it disappears, I
keep looking to see if paul Daniels is behind me..

Like I say these tools and systems are gash, good job Xilinx would never
dare charging for them. ;-)

Just trying this......
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:Xst:portability/export/Port_Main.h:143:1.17 - This application
has discovered an exceptional condition from which it cannot recover.
Process will terminate. For technical support on this issue, please open a
WebCase with this project attached at http://www.xilinx.com/support.



Steve
 
On Fri, 3 Jul 2009 18:38:25 +0800, Symon wrote
(in article <h2kna0$m0k$1@news.eternal-september.org>):

Steve,
Use the 'core inserter' instead.
HTH., Syms.
Click to expand...
It is better you do not comment if you do not read the post.
 
steve escribió:
On Fri, 3 Jul 2009 16:55:47 +0800, Jonathan Bromley wrote
(in article <isgr45p80p9t0fgcsqe03k4537lk68ffc3@4ax.com>):

On Fri, 3 Jul 2009 09:19:32 +0800, steve wrote:

BUT I have the following user enumerated types

type FIFO_CNTL_SM_TYPE is (IDLE, RD_REQ, WR_REQ);
signal fifo_cntl_cs : FIFO_CNTL_SM_TYPE;

how do i mask this damned thing into chipscope, I just get errors about the
types not matching,.

TRIG2(31 downto ????) => fifo_cntl_cs ,
You need a conversion function.

TRIG2(31 downto 29) => to_slv(fifo_cntl_cs),

You don't want to introduce any additional logic if you
can avoid it, so it makes sense for the conversion
function to match the internal encoding that XST has
created - see Mike's post.

In practice that's likely to be one-hot. So you could do
something like this in which each output represents one
state. It has the advantage that it won't
need to be rewritten if you add or change state names:

function to_slv(code: FIFO_CNTL_SM_TYPE)
return std_logic_vector
is
constant LAST: integer :=
FIFO_CNTL_SM_TYPE'POS(FIFO_CNTL_SM_TYPE'HIGH);
variable result: std_logic_vector(0 to LAST);
begin
result := (others => '0');
result(FIFO_CNTL_SM_TYPE'POS(code)) := '1';
return result;
end;

If you're short of pins on the ChipScope, you could
simply convert the integer FIFO_CNTL_SM_TYPE'POS(code)
to a std_logic_vector and put that out instead.

XST is happy with the 'POS and 'HIGH attributes; I'm
not sure it will be OK in all synthesis tools,
although there's really no excuse for it not being.

Do be aware that adding any such decoder, to observe
an enumerated signal, may change the optimization
so that the enumeration is encoded differently.


Hi Jonathan,

Thanks for your concise description, it's exactly the guidance I needed.
Being new to FPGA's I did not realize how gash these tools were.

As regards , changing the logic/ optimization, I'm already aware of that.
when I try and put my chipscope external to my user_logic and probe
internally, sometimes the stuff is accessible , other times it disappears, I
keep looking to see if paul Daniels is behind me..

Like I say these tools and systems are gash, good job Xilinx would never
dare charging for them. ;-)

Just trying this......
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:Xst:portability/export/Port_Main.h:143:1.17 - This application
has discovered an exceptional condition from which it cannot recover.
Process will terminate. For technical support on this issue, please open a
WebCase with this project attached at http://www.xilinx.com/support.



Steve
Click to expand...
With a simple SM you can use a simple approach,

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

If XST use one-hot encoding this code are only connections.

Walter,
 
steve escribió:
As regards , changing the logic/ optimization, I'm already aware of that.
when I try and put my chipscope external to my user_logic and probe
internally, sometimes the stuff is accessible , other times it disappears, I
keep looking to see if paul Daniels is behind me..

Like I say these tools and systems are gash, good job Xilinx would never
dare charging for them. ;-)
Click to expand...
FPGA and Xilinx software are not easy to drive, as a Porsche, but when
you know how; you have a good chance to win;

user_logic sound as you are using others cores into your project, correct ?

Walter
 
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:Xst:portability/export/Port_Main.h:143:1.17 - This application
has discovered an exceptional condition from which it cannot recover.
Click to expand...
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.

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. Might give
the tools rather less of a headache. I synthesized
a small design with the conversion function in it,
so there's no fundamental problem!

Walter's simpler approach needs an extra signal
in any case.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
steve wrote:

It is better you do not comment if you do not read the post.
Click to expand...
Got it.
On thunderbird that's

Message,
Create filter from message,
OK


-- Mike Treseler
 
On 3 jul, 12:19, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

Walter's simpler approach needs an extra signal
in any case.
Click to expand...
I make a mistake; TRIGs must be TRIG2 but where is the "extra"
signal ?

TRIG2(x) must be directly connected to FFx;

Walter.
 
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;
Click to expand...
I agree that there is no new hardware.

In the original post, steve wrote:

TRIG2(31 downto ????) => fifo_cntl_cs ,
Click to expand...
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.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
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.
Click to expand...
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.
 
On Fri, 3 Jul 2009 22:37:57 +0800, Walter wrote
(in article <h2l545$2v0l$1@adenine.netfront.net>):

steve escribió:

As regards , changing the logic/ optimization, I'm already aware of that.
when I try and put my chipscope external to my user_logic and probe
internally, sometimes the stuff is accessible , other times it disappears,
I
keep looking to see if paul Daniels is behind me..

Like I say these tools and systems are gash, good job Xilinx would never
dare charging for them. ;-)


FPGA and Xilinx software are not easy to drive, as a Porsche, but when
you know how; you have a good chance to win;

user_logic sound as you are using others cores into your project, correct ?

Walter



Hi walter,
Click to expand...

Yep, there is a bit of everything , networking , ppc, PLB, OPB2PLB bridge
buttons & led's for debugging, it is a computer forensics project for my
thesis.


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.

my background is software, and we are really spoiled for tools and debugging
setups, I was actually shocked at how bad and messy the hardware development
kit is. (i might take a look at Altera later)

But your solution has been great, I also filed a webcase with xilinx over the
above problem.

Anyway thanks for helping out a noob.

Steve
 
On Fri, 3 Jul 2009 23:19:43 +0800, Jonathan Bromley wrote
(in article <748s45hkmqurk1bhgjr5gvoqfk123tlmj0@4ax.com>):

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:Xst:portability/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.

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. Might give
the tools rather less of a headache. I synthesized
a small design with the conversion function in it,
so there's no fundamental problem!

Walter's simpler approach needs an extra signal
in any case.
Click to expand...
That was my second thought :) , and the damned thing compiles and works!!
You can stick the result of the conversion into a variable:

signal dummy :std_logic_vector (0 to
NAND_WR_SM_TYPE'POS(NAND_WR_SM_TYPE'HIGH));
.......

TRIG3(0 to NAND_WR_SM_TYPE'POS(NAND_WR_SM_TYPE'HIGH)) => dummy, --"000",
--to_slv(nand_wr_ns),

once I had the 'mental' tools , the solution presented it's self.


Steve
 
On Sat, 4 Jul 2009 03:44:48 +0800, Jonathan Bromley wrote
(in article <vmns45dl2t79d4rtc77p9g7mig36inv94f@4ax.com>):

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.
Click to expand...

Yep the chipscope comes in as:

component icon

PORT (
CONTROL0 : INOUT STD_LOGIC_VECTOR(35 DOWNTO 0));

end component;



component ila
PORT (
CONTROL : INOUT STD_LOGIC_VECTOR(35 DOWNTO 0);

CLK : IN STD_LOGIC;

TRIG0 : IN STD_LOGIC_VECTOR(31 DOWNTO 0);

TRIG1 : IN STD_LOGIC_VECTOR(15 DOWNTO 0);

TRIG2 : IN STD_LOGIC_VECTOR(23 DOWNTO 0);

TRIG3 : IN STD_LOGIC_VECTOR(31 DOWNTO 0));


end component;

sorry I thought this would be common code , so i did not post it.
This is built using the code generator.

I don't use the data ports, but instead tie my signals to the trigger ports,
so i can use any of them to trigger on.

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

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.
Click to expand...
Hi walter,

It's only 'simple' if you are a diehard VHDL programmer , I'm 2 weeks into
this, have all the xilix documentation and god knows how many VHDL books
No where in chipscopes manuals is this mentioned, but it is exactly the sort
of thing people need to debug.

But what is really anoying , is the fact that you cannot turn off sections
of VHDL optimization to stop signals disappearing. (yes I know about keep and
noopt ,but they don't make a difference)

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

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.
Click to expand...
Hi Walter,

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

steve
 
On Fri, 3 Jul 2009 16:55:47 +0800, Jonathan Bromley wrote
(in article <isgr45p80p9t0fgcsqe03k4537lk68ffc3@4ax.com>):

On Fri, 3 Jul 2009 09:19:32 +0800, steve wrote:

BUT I have the following user enumerated types

type FIFO_CNTL_SM_TYPE is (IDLE, RD_REQ, WR_REQ);
signal fifo_cntl_cs : FIFO_CNTL_SM_TYPE;

how do i mask this damned thing into chipscope, I just get errors about the
types not matching,.

TRIG2(31 downto ????) => fifo_cntl_cs ,

You need a conversion function.

TRIG2(31 downto 29) => to_slv(fifo_cntl_cs),

You don't want to introduce any additional logic if you
can avoid it, so it makes sense for the conversion
function to match the internal encoding that XST has
created - see Mike's post.

In practice that's likely to be one-hot. So you could do
something like this in which each output represents one
state. It has the advantage that it won't
need to be rewritten if you add or change state names:

function to_slv(code: FIFO_CNTL_SM_TYPE)
return std_logic_vector
is
constant LAST: integer :=
FIFO_CNTL_SM_TYPE'POS(FIFO_CNTL_SM_TYPE'HIGH);
variable result: std_logic_vector(0 to LAST);
begin
result := (others => '0');
result(FIFO_CNTL_SM_TYPE'POS(code)) := '1';
return result;
end;

If you're short of pins on the ChipScope, you could
simply convert the integer FIFO_CNTL_SM_TYPE'POS(code)
to a std_logic_vector and put that out instead.

XST is happy with the 'POS and 'HIGH attributes; I'm
not sure it will be OK in all synthesis tools,
although there's really no excuse for it not being.

Do be aware that adding any such decoder, to observe
an enumerated signal, may change the optimization
so that the enumeration is encoded differently.
Click to expand...

Hi Jonathan,

this worked fine for one instance , but even with 50% of the FPGA spare , I
started getting routing errors if I did more than one instance of a variable,
which is real stupid when I think about it.

I guess it's down to some interaction with chipscope.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top