FPGA Central

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,.

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 ,

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

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.

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

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

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.
>
>

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
>
>
>

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. ;-)
>

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.

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.

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.

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;

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.
--
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.

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,

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.
>

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.
>


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.
>

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.
>

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.
>


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.

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: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.

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

steve escribió:
> 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.
>>
>
> 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 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,

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

> 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

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

> [snip]
>
> 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