In a previous post, VHDL Physical Type is not Synthesizable, or is it?, I pointed out that VHDL synthesis tools can indeed synthesize VHDL physical types. In the example I gave, all computations with physical types were done at elaboration time, so that the synthesis tool does not really have to deal with physical types at all.
I choose a example that was too weak and I want to make that right. So here is my new claim:
VHDL synthesis of physical types works perfectly well.
Short and powerful: no “but”, no “caveat”. Synthesis works fine if, even signals have a physical type or if there are computations on physical types. If you have access to a (modern) VHDL synthesis tool and you can try this out for yourself. If not, nobody will be interested in your uninformed opinion.
Side note: about VHDL synthesis
There are dozens of constructs that are marked as not for synthesis in traditional courseware, including:
- bits, booleans and integers
- generics (other than integer)
- ports of record types or multi-dimensional records
- initial values of signals
- and much more…
My first step will be to demonstrate which (none, some or all?) of them them are wrong. When I do that, a lot of traditionalists will argue that: “OK, it might work for you, but it’s still bad practice because blah blah blah.” When that happens, the discussion has shifted from “the tools can’t handle it” to “the humans don’t want to handle it.” We can then get to the reasons why humans don’t want to handle those particular constructs. We can have an informed discussion on a case by case basis to see if there is a valid argument to be made.
I don’t want to force anybody in to using any of these constructs. I’m just worried that VHDL educators are scaring people away from useful and powerful VHDL language features that could save engineers a lot of work.
Back to physical types
But for now, let’s focus on physical types. To pin everybody to the facts, here is a VETSMOD: Get better feedback from your VHDL code snippets example of physical types in action:
library ieee; use ieee.std_logic_1164.all; entity testPhysical is port(clk : in std_logic; rst : in std_logic; strobe : out std_logic ); end entity testPhysical; architecture RTL of testPhysical is type number_of_eggs is range 0 to 255 units eggs; dozen = 12 eggs; gross = 12 dozen; end units; signal egg_basket : number_of_eggs; begin name : process(clk) is begin if rising_edge(clk) then if egg_basket = 1 gross then egg_basket <= 0 eggs; strobe <= '1'; else egg_basket <= egg_basket + 1 eggs; strobe <= '0'; end if; end if; end process name; end architecture RTL;
This (contrived) example synthesizes perfectly and efficiently (Altera Quartus 11.1) to the following RTL:
I’m pretty sure that this synthesized RTL view would be identical if you use
std_logic_vector types. I didn’t try that, so feel free to prove me wrong.
- VHDL Physical Type is not Synthesizable, or is it? (blog post)
- Clock edge detection (blog post)
- List of known VHDL metacomment pragma's (blog post)
- VHDL Pragmas (blog post)
- Opening VHDL files in Sigasi, using Quartus (blog post)