Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Jim Lewis (Jim@synthworks.com)
Date: Wed Dec 17 2003 - 10:43:26 PST
Andy,
>>> main: process (clk)
>>> begin
>>> if clk and enable then -- = rising_edge(clk and enable) = gated
>>> clock, not clock enable!
>>> do_rising_edge_stuff(inputs, outputs);
>>> end if;
>>> end prodess;
>>
> The above code was an example of a conversion of a syntax that was
> requested in a SNUG paper a couple of years ago.
In 1076.6-1999 and P1076.6-200X (VHDL RTL Synthesis Coding Styles
Standard), it was decided that it would
be either difficult or impossible to get synthesis tool
vendors to evaluate the process based on the sensitivity list.
As a result all portable coding styles specified by the standard
must some how imply a clock edge inside the process, indepdendent
of the sensitivity lsit.
Hence, to do what you want, P1076.6-200X (comming soon) supports:
if rising_edge(Clk) and enable then
Rising_edge returns boolean. Hence we need the overloaded logic
operators. As Steve corrected me, the overloaded logic
operators allow mixed boolean and std_ulogic and return std_ulogic.
Hence, using std_logic rather than explicit boolean expressions
will either produce the same result or produce a result that
is more accurate.
BTW, if you want a gated clock, P1076.6-200X has an attribute
that can be set on a clock signal to transfor the above code
into a gated clock:
attribute GATE_CLK : boolean;
attribute GATE_CLK of Clk : signal is true;
. . .
GatedClockProc : process(Clk)
begin
if rising_edge(Clk) and LoadEn='1' then
Q <= D ;
end if ;
end process ;
>> For signed math:
>> signal A, B, Y : integer range -8 to 7 ;
>>
>> -- What do you need to add here to get Y in the correct range?
>> Should it clip or should it modulo?
>> Y <= A + B ;
>
> I've got a better question: arithmetically, what will the above, using
> vector addition do?
There is nothing to debate about integers. There is a desire
to make them more useful for design. My point above,
is that unsigned math is easy. Signed math takes some work
to make it work well as an integer.
Vectors always does modulo:
signal A, B, Y : signed (3 downto 0) ;
Y <= A + B ;
Vectors do allow different sizes.
The largest array needs argument needs to match the size of the result.
The other one gets extended by the rules of the type (signed, unsigned).
So, your accumulator:
signal Y : unsigned (7 downto 0) ;
signal B : unsigned (5 downto 0) ;
Y <= Y + B ;
Need a carry out (unsigned), no problem:
signal cY : unsigned (8 downto 0) ;
cY <= ('0' & Y) + B ;
Y <= cY(Y'range) ;
. . .
if cY(cY'left) = '1' then -- detecting carry out
With vectors, I know I am going to get the same quality
optimization on every synthesis tool.
With integers, I would be concerned about how well the
synthesis tool optimized the expressions to effect the sharing:
Y <= (Y + B) mod 256 ;
if (Y+B) > 255 then
With this coding, I would expect synthesis to take longer.
I prefer a little more explicit control over synthesis.
> I just wish support for 64 bit unsigned integers was standard.
Hopefully we can either add this or some arbitrarily large integer
(because 64 bit will tap out also).
> I maintain that there is no way to "do it right" without flying in the
> face of the main strength of vhdl.
So far as I can see the proposal has stood up to all testcases.
Regards,
Jim
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Wed Dec 17 2003 - 10:45:06 PST