vhdl type conversions

Try: case state is when Idle => dbg_state dbg_state dbg_state dbg_state dbg_state dbg_state NULL; end case;

(1) Try comp.lang.vhdl instead. (2) Write a function to do the type conversion - it makes life far easier in the long run - and use a case statement inside that function:

subtype slv3 is std_logic_vector(2 downto 0); function to_slv3(s: state_type) return slv3 is begin case s is when idle => return "000"; when read_config => return "001"; ....etc.... end case; end;

And then you can simply drive the output...

dbg_state "000", read_config => "001", ... );

And then you can use that lookup table like a conversion function:

dbg_state state_dbg, ... );

Constant lookup tables are extremely efficient, and the code for them is extremely easy to write and maintain, but you can't use them in a port map as you can a conversion function.

HTH

library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; ... function mode2vec (arg : STATE_TYPE) return std_logic_vector is begin return std_logic_vector( to_unsigned(STATE_TYPE'pos(arg),3) ); end function mode2vec; ... dbg_state

dbg_state

thanks for all the answers! just tried it and yes it works in ise too!

Urban Stadler

Thanks for reporting the results.

-- Mike Treseler

No, indeed I don't.

If I say (truthfully) "tools A and B support feature F", and it happens that tool C also supports feature F, then vendor C is quite likely to give my employer a hard time for the perceived unfair publicity. I would much prefer to say "some tools support feature F", and allow people to find out for themselves from their chosen (or candidate) vendors if it matters to them.

If I were to get involved in "who supports what" feature comparisons, I would be duty bound to be far more thorough and careful than would ever be possible in a newsgroup posting. In particular, I would need to prepare my comparisons and submit them to all the vendors before publication so that they could correct any factual inaccuracies before going to press.

I have no desire to be a stooge of any of the tool vendors, but it is also very important to me and to my employer that we treat them all fairly. We cannot avoid discussing specific tools as part of our training courses, and we must scrupulously avoid bias.

By contrast, a customer of one single vendor has (almost) no such obligation of impartiality and, give or take a few legalistic constraints, can say whatever they want about the tool they have purchased.

Sorry to disappoint :-)

Fair enough. Please do keep posting the clever hdl ideas. We'll dish the reviews.

I would suggest that designers maintain a non-proprietary module/entity that covers all of the hdl features considered important. Doing this makes it much easier for me to evaluate new tools or new revisions of old tools. It is also makes quick work of writing a bug report when I can freely attach the code and error message.

-- Mike Treseler