Just a few extra comments :
All say that case infers a parallel logic and if-elsif-else infers
a proirity encoder structure ...
They don't quite say this (or they'd lie).
"If ... elseif" has an implied priority (first test true -> next tests
are not taken)... but that makes no sense when you describe a truth table !
(as in my first encoder example)
Whatever the means to describe behaviorally the truth table, it
will end up the same, and by way of logic reduction it will lead
to implementations that may or may not be similar depending
on synthesis tools optimization goals, constraints, internal
logic reduction algorithm, etc...
Things may become different when complex operators are inferred.
The BIG difference is that, from a synthesis perspective,
describing a truth table isn't the same as describing higher
level structures !
What I mean is be wary of general rules about synthesis. There are more
than one tool, and tens of years of research behind them...
I think it's pretty dangerous to say "this does infer that".
Or you have to be damn accurate : given code snippet, given tool,
given version, given technology, given constraints, etc etc
problem of qulifying expression has been addressed by vhdl committee
and it is going be fixed soon.
1. I didn't mean it was a problem ! You just need to know the language.
Qualified expressions are just often unknown to newbies, but they
are extremely useful. write (L,"hello"); for example.
There's no problem in writing "case A&B" (a qualified expr does it).
It's also possible to get directly the two MSBs of A + B (vectors).
One just needs to know a bit more than the basics of VHDL.
2. What do you mean by "has been addressed..."? I don't want to start
another controversy, but VHDL200X isn't out of the woods.
We all just hope it will happen (out of IEEE and then into our tools)
before the EDA community majority has switched to SystemVerilog.
But there is absolutely no real need of a better VHDL for simple designs.
completness of case is an advantage to find the bugs.Lets take an
example....
It's MUCH easier to follow good coding rules which ensure that the
bad situation you mention will never happen in your design that
trying to test every signal again 'U' !
If you want to do this, be consistent and write a test for every
numeric vector, making sure it doesn't include any 'U'. Not cool.
Simple gross mistakes are easier to prevent than to detect.
I think this is the same with std_ulogic, which use was supposed
to help detect multiple drivers situations (it did). But there
are other ways to check this and so many other bad things are
to be tested at synthesis that everybody has dropped now this
unresolved type and obsolete style.
I dont know partiuclarly about one hot minimal decoder but
Synthesis tools say case statments are good for area opptimizations.
It's called hearsay I think.
Then, why doesn't it show up in the simple examples I gave ?
(XST 6.3.03i creates in fact a larger design with the "case" version)
I have reproduced below an old example that I sometimes used
in my courses. I kept it simple minded (no fancy function).
Why don't all synthesis tools give the simple OR gates ?
- The case version "looks" nicer, but check the gates count (with your tool).
- In the "if" solution : do you see a priority after synthesis ??
Chances are your synthesis tool will produce three times larger solution
with the case than with the if.
Don't believe ppt slides (nor me) !
Dont under estimate the number of gates as it is know
causing more static power.
0. How do you know you have "saved" some gates and achieved
and an optimal solution ? What do you compare against ?
In the example below, was 15 LUTs acceptable or not ? (without
the comments saying it was not).
1. The case doesn't always produce less gates, sometimes
the contrary as proved here.
I try to not underestimate anything ! I just check by myself
as much as I can and I encourage you, if you're sensitive to gate
count and QOR, to always verify and never simply "assume".
2. If design could be made significantly smaller by avoiding "ifs",
then don't you think the Synthesis tools would automatically do
the translation internally ? (they do, this and many other tricks)
3. There is one or two orders of magnitude higher potential gain
by smart implementation and good design know-how :
being a smart architect pays !
4. Most synthesis tools are smarter and smarter, so a good
understanding of your specific tool is also a good investment.
5. FPGAs and ASICs are two different worlds. What applies to one not
necessarily applies to the other. Synthesizing to LUTs and to GATEs
isn't the same. Don't forget Synopsys is an ASIC company.
Driving DC ins't the same as doing FPGA synthesis.
6. Significant Power consumption reduction requires other techniques
than using case instead of if (supposing that there is any gain
at all doing so).
7. Gate count is definitely less and less an issue, even in the
ASIC field ! Challenges have moved, and old books don't reflect this.
My experience is : Synthesis tools are often smarter than the designer
thinks, but there are also sometimes doing some apparently "stupid"
things (at least looking like such for unexperienced designers).
Just try Q <= A + B - A - B; -- unsigned vectors.
And please do *NOT* avoid the case statement when it is appropriate !!!
Again, HDL code should be as simple, clear and expressive as possible,
easy to understand and maintain, and not error-prone. I assign a higher
priority to these criteria in our designs.
After a good ground learning, learn by trying. This is fun anyway.
You must end up "thinking" like your synthesizer, then you'll be
real efficient.
Bert Cuzeau
"Let's save the poor IF from damnation !" Commitee
12, Gate(s) Lane
Mux Island
(donations accepted, FFs* and LUTs only)
* FlipFlops, not French Francs
----------------------------
-- HOTDECOD.VHD
-- -------------------------------------
-- One-Hot Decoder
-- -------------------------------------
-- ALSE.
http://www.alse-fr.com/english
-- This design must be synthesized as 3 x OR gates (4-inputs)
-- Any extra logic is unnecessary.
--
library IEEE;
use IEEE.std_logic_1164.all;
-- -------------------------------------
Entity HOTDECOD is
-- -------------------------------------
port ( A : in std_logic_vector(0 to 7);
Q : out std_logic_vector(2 downto 0)
);
end;
-- -------------------------------------
Architecture RTL_case of HOTDECOD is
-- -------------------------------------
-- check how many LUTS for this one...
-- How do you code this as a generic size decoder ?
begin
process (A)
begin
case A is
when "00000001" => Q <= "111";
when "00000010" => Q <= "110";
when "00000100" => Q <= "101";
when "00001000" => Q <= "100";
when "00010000" => Q <= "011";
when "00100000" => Q <= "010";
when "01000000" => Q <= "001";
when "10000000" => Q <= "000";
when others => Q <= "---"; -- don't care
end case;
end process;
-- Note : the "case" above is auto-full and auto-parallel in Verilog sense.
-- Quite obviously, one solution is :
-- Q2 = A0 or A1 or A2 or A3
-- Q1 = A2 or A3 or A6 or A7
-- Q0 = A1 or A3 or A5 or A7
end RTL_case;
-- -------------------------------------
Architecture RTL_if of HOTDECOD is
-- -------------------------------------
-- and how many LUTS for this one ?
-- Isn't this description easier to rewrite under
-- the form of a (size-independant) function ?
begin
process (A)
begin
if A(7) = '1' then Q <= "111";
elsif A(6) = '1' then Q <= "110";
elsif A(5) = '1' then Q <= "101";
elsif A(4) = '1' then Q <= "100";
elsif A(3) = '1' then Q <= "011";
elsif A(2) = '1' then Q <= "010";
elsif A(1) = '1' then Q <= "001";
elsif A(0) = '1' then Q <= "000";
else Q <= "---"; -- don't care
end if;
end process;
-- do you see a "priority" in the synthesized result ???
end RTL_if;
