Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003

Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Andy D Jones (andy.d.jones@lmco.com)
Date: Wed Dec 17 2003 - 13:00:02 PST

Jim,

Inlined below:

Jim Lewis wrote:

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
Actually, it will support "if rising_edge(clk) and enable = '1' then"

Which does not require boolean overloading.


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. 
Agreed, and good.
My point above,
is that unsigned math is easy.  Signed math takes some work
to make it work well as an integer.
Seldom is a rollover in signed arithmetic really what you wanted.  But vector arithmetic will do that happily and silently for you.  When the algorithms are developed, they assume correct arithmetic, and integers deliver that, or warn you that it isn't happening.
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).
My example was poorly constructed to illustrate this, but integers allow different sizes of addends and results, so you could have a result that cannot overflow (8bit + 8bit = 9bit) without resorting to extra signals, concatenation and subranges.


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
And this is supposed to be easier to understand than the following equivalent using integers?

if y+b > 255 then -- carry out detected
...
y <= (y + b) mod 256;

Keep in mind that vhdl is not always read by vhdl experts.


   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've only tried this on the two synthesis tools we have (synplicity and synopsys), and both are identical in their optimization of this construct.

I have not noticed any degradation in synthesis time, but a huge reduction in simulation time. I spend a lot more time in simulation than 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).
Amen!



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.
I have no doubt that what you and others want to do will function "correctly" in all test cases.  But I still believe it removes necessary clarity, and will inevitably lead to the inclusion of boolean equivalency everywhere (expressions, etc.)

We use a lot of active low signals at the board interface, and the first thing I do is convert them to boolean, using is0(). (that's another thing I wish was synthesizable: conversion functions in port maps) to avoid the ambiguity, and remove the need to convert later.  So, I guess I'm already getting what you all seem to want, but without changing the language. That's one reason I'm resisting the change, since I don't see it as that beneficial, given my preferences of coding style.

In the ideal world, I wish that boolean 'registers' could be optimized to zero or one by the synthesizer, the same way they optimize state mapping.  There could be safeguards to protect primary ports, etc. Though not often needed in FPGAs (except for things like tri-state enables, resets, etc.), I would think ASICs could really use this to reduce combinatorial logic.  If we define a specific mapping from boolean to sul, then this is not likely to happen.

I guess we're just gonna have to agree to disagree on this. :^)

Andy


Regards,
Jim

This archive was generated by hypermail 2b28 : Wed Dec 17 2003 - 13:02:56 PST