On Fri, 3 Jul 2009 16:55:47 +0800, Jonathan Bromley wrote
(in article <[email protected]>):

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