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

Subject: Re: ANDY: [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 - 09:24:53 PST

Jim,

Inlined below are my comments:

Jim Lewis wrote:
Andy,
This code is dangerous as currently some synthesis tools
may produce a register, but others ignore the sensitivity
list and create a latch.  It is not portable.
main: process (clk)
begin
  if clk = '1' then -- means rising edge clock
    do_rising_edge_stuff(inputs, outputs);
  end if;
end process;

I caution you away from this coding style as
you will run into problems when you synthesize on
different synthesis tools.
I don't use anything but rising_edge() and falling_edge(), but a lot of users (and tools) do.


The COND operator has no effect on edge semantics.
In your examples the edge implication comes from
the sensitivity list.


What you are saying regarding the clock and enable is
not true for registers as only clk is on the sensitivity
list.  Your concerns are true for latches, which requres
all signals read in a process to be on the sensitivity list.



The following code
1) IS NOT PORTABLE BETWEEN SYNTHESIS TOOLS
2) May create register with load enable.

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. It is not currently supported, although I would like the original syntax supported for synthesis.  Like I said, it already simulates correctly.  If it were to be allowed, and the implicit cond() call added to it, then you get the above situation which is very confusing.


like using component definitions/configurations/instantiations
> instead of entity instantiation.
Last I checked some synthesis vendors do not support entity
instantiation.  This is why I show it, but don't focus on it
in my classes as the place I would recommend using it, it is not
permitted to be used.
Synplicity and Synopsys both support it, though synopsys had, at one time, a bug involving entity instantiations within entity instantiated architectures.  Their docs say it is fully supported.  If some vendors don't support it, demand that they do, or switch.  This is not a standards issue, it is a compliance issue.  If more users tried it, and demanded that it worked, then it would be supported everywhere.  It already is supported on all the tools I use.


Like using std_logic and std_logic_vector everywhere when integer and boolean are simpler, easier to read and write, and faster to simulate.
If you use an integer as a port, what direction are the bits that
result in the implementation.
Hook up to the port with an integer, so it does not matter. AFAIK, the highest numbered bit is msb, but I don't use integers as primary (device) ports, since I want compatibility with the gate level model in the test bench.


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?

Using integers, If A + B exceeds the range Y (-8 to 7), it will assert an error.  You have to tell it if you want to clip or modulo (just like vhdl, it does not assume anything).  If you want the implied behavior of vectors, then you modulo.  On the other hand, if you want to find out when/if it rolls over, then don't do anything, and the simulator will tell you.  Then you can increase the range (perhaps just on Y).  If you want to handle the over/under flow, then test the results of the operation before assigning it (if a+b < - 8 or a + b > 7 then...).  Ada has a really nice feature for testing the range of an expression relative to the range of a type or subtype.

Y <= (A + B) mod 8; -- modulo and division by fixed powers of two are supported by synthesis.

Integers let you do much more interesting things too:

How about:
signal y : natural range 0 to 255;
signal b: natural range 0 to 64; -- different length addend

Y <= (Y + B) mod 256; -- accumulator

or, if you want to do something when it rolls over, using the carry output of the adder:

if Y+B > 255 then -- optimizes to an 8/6 bit adder with carry out; this will not work with vectors!
  do_something();
end if;
Y <= (Y + B) mod 256;  -- uses same adder as above

Try that with vectors!  It can be done, but it is not nearly as readable from a behavioral point of view.  In the designs I have created, debugged or reviewed, behavioral errors outnumbered hardware problems 10 to 1.

In a small (20K gate) FPGA, just changing the 9 bit internal address bus from unsigned vector to integer sped up the RTL sim by 2.5X!  That's 2.5X more test cases you could run.  That's when and why I started using integers.

I just wish support for 64 bit unsigned integers was standard.

Andy


The proposed implicit call to COND is a terrible idea,
> providing precious little benefit for a monumental loss in clarity.
If done right it will work well.
The only way it will get in the language is if it is done right.

Cheers,
Jim
I maintain that there is no way to "do it right" without flying in the face of the main strength of vhdl.

Later,

Andy

This archive was generated by hypermail 2b28 : Wed Dec 17 2003 - 09:26:53 PST