Re: [vhdl-200x-ft] Ft19 process_comb

I am a believer in process_comb, process_latch, and process_ff
or some other notation to convey the same information.

The original intent of a process sensitivity list is
to convey design intent. Designers have found, however, that
in the RTL coding process, except for registers, everything
really belongs on the sensitivity list.

In my mind, process (all), or process_all, is a kludge.
It says that we really did not need that sensitivity list
and so lets add some syntax that says forget about it.
However, that is all this additional syntax does.

Process_comb is just like process all, except for synthesis
tools it also conveys design intent. It says, this logic
is only to create combinational logic. Two common problems
with statemachines are to leave things off sensitivity lists
and to accidentally have latches in the design. Process_comb
addresses both of these issues. It builds a complete sensitivity
list and it indicates to the synthesis tool that if the
following code does imply a latch - then error - don't
produce any hardware.

The reason I made it erroneous rather than error is that
I do not think we need to require simulation tools to do
checking (at least initially), but I do want to
require synthesis tools to do checking (which would be
accomplished by adding it to a future revision of 1076.6).
Granted I would prefer that simulators see this as an error,
but I did not want to add that burden on the first pass -
however since it is erroneous, they could choose to signal it
as an error. While early detection is preferred, keep in
mind if simulators don't signal it, it is not any worse
than what we have now. Also keep in mind that if we decide
to go with process (all), then simulators will never have
this capability - process(all) can also be used for latches.

With these semantics, process_comb will make design reviews
easier. The question of whether the sensitivity list is
correct reduces to did they use process_comb (sure this
also applies to process (all) too). The question of whether
any unintended latches are in the design reduces to did
the synthesis tool produce gates.

Note 1076.6-2004 added the combinational attribute
that can be applied to a process label. Process_comb
accomplishes the same goal, however, an attribute
is specified in the declaration region and, hence, easy to
miss wereas process_comb is specified at the point of use
and easy to see.

Initially process_ff is going to have a small return because
the sensitivity list for a ff is small:

ARegProc : process(clk, nReset)
begin
   if nReset = '0' then
      AReg <= '0' ;
   elsif rising_edge(Clk) then
      AReg <= A;
   end if;
end process ;

This translates to:
ARegProc : process_ff
begin
   if nReset = '0' then
      AReg <= '0' ;
   elsif rising_edge(Clk) then
      AReg <= A;
   end if;
end process ;

Long term, we can hopefully benefit from optimization.
Currently this process runs on both rising and falling
edges of clock. However for all compliant 1076.6-2004
registers, events only are generated on the active edge
of clock or when nReset changes to 0. So one optimization
simulation vendors could take advantage of with this
register style is to not run the process on the falling
edge of clock. At an earlier meeting (summer 2003) we looked
into adding syntax to the sensitivity list to allow running
only on rising or falling edge, but did not
come up with anything acceptable.

Note that 1076.6-2004, does allow multiple edge registers
and registers with rising and falling edges, however, it
also requires that each clock be explicitly specified
with clock edge notation (such as rising_edge, falling_edge):

TwoEdgeReg : process_ff
begin
   if rising_edge(Clk) then
      TwoReg <= A;
   elsif falling_edge(Clk) then
      TwoReg <= B;
   end if;
end process ;

Long term supporting process_ff means that simulators will
gain some smarts with respect to sensitivity lists, which
perhaps they will choose to apply in other places such as:

AReg <= '0' when nReset = '0' else A when rising_edge(Clk) ;

With the flexability of register coding styles added in
1076.6-2004, some register coding styles may be harder
to create an efficient sensitivity lists for than others,
however, I don't think we have a problem with creating a
correct sensitivity list. RTL code is only sensitive
to events - attributes like 'active are not supported.
Hence putting everything on the sesitivity list is only an
efficiency issue and not a correctness issue. As a result,
to create a sensitivity list, put everything on the
sensitivity list, and then remove things that are detected to
be synchronous to the clock.

If necessary, rather than supporting all of the ways to
create clock, we could constrain it to rising_edge and
falling_edge (this proposal also proposes creating these
functions for bit). This is reasonable as there is no
pre-existing code we need to support and rising_edge/
falling_edge are a good readable way to express a clock edge.

For conveying full designer intent of code, with the current
syntax we need to have an attribute for combinational (1076.6-2004)
and a a sensitivity list. Process(all) only replaces the
sensitivity list. Process_comb replaces both. I think this
is a good thing. I think over the long term, process_ff
will give us the ability to have faster simulations through
more intelligent sensitivity lists - only running on the
rising edge of clock.

I share the concern that these are point solutions and
that something more general may be more appropriate,
however, I am not real concerned as we have covered the
hardware design space fairly well. I would welcome
an alternate proposal that still captures the space here.
I would be concerned with an "attribute-like" approach as
it is probably inappropriate to apply two (such as latch
and ff) together like can be done with an attribute.

Regards,
Jim

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~