«

Jason Zheng wrote:

> I believe that this is really in the eye of beholder. It's hard to make
> conclusions without looking at some concrete examples.

Here's mine:
http://mysite.verizon.net/miketreseler/count_enable.v
http://mysite.verizon.net/miketreseler/count_enable.vhd
http://mysite.verizon.net/miketreseler/count_enable.pdf

> I think Mike Treseler's style makes it easy to auto-generate HDLs, but
> not necessarily easy for designers and analysts.

Synthesis generates netlists of primitive elements *from* the HDL code.
I write the HDL myself.

-- Mike Treseler

Mike,

I'm struggling to understand the real benefit of your subprograms.
They are not controlling any scope issues, and they don't appear to
help document any functional information (structural, yes, but not
functional). it would seem to me to be less verbose, and no less clear
to dispense with the overhead of subprograms and inline the code in
the process statement region, even if you included line comments like
"-- update regs here".

I can see the benefit of an init_regs procedure if your process
template supported synchronous or asynchronous resets (not at the same
time, but maybe decided by a generic).

I'm also curious why the implementation results in 6 bit registers,
when, as far as I can tell, only 5 bit registers are needed? Is it
because of the reset of all 6 bits? Maybe if you removed the "clear
carry" statements to the bottom of the procedure, it would optimize
out the register bits? Synthesis ought to be able to figure that out,
but I guess not. I prefer integers for this anyway; much easier to
deal with carry logic, and you can convert back to slv in the port
update section.

Andy

Andy wrote:

> I'm struggling to understand the real benefit of your subprograms.


I break the code into init, update_regs, and update ports
to allow changing the reset style

(v_rst, a_rst, s_rst, so_rst)

without otherwise touching the code.

It also makes breaking the template
slightly less likely during edits.
But this is certainly a style option, not a requirement.
Notice in the .v example, I use comments instead.

> I'm also curious why the implementation results in 6 bit registers,
> when, as far as I can tell, only 5 bit registers are needed?

That's just the RTL view.
One of the bits becomes an asynchronous carry out after synthesis.
I just describe the value updates. Synthesis works out wires vs regs.

-- Mike Treseler

On Jul 15, 5:05*pm, Mike Treseler <mtrese...@gmail.com> wrote:
> to allow changing the reset style
>
> *(v_rst, a_rst, s_rst, so_rst)
>
> without otherwise touching the code.
>

That's one area from the Keating's article that I'm interested in:
ability to control (from a generic, etc.) whether async or sync reset
gets implemented. It may be as simple as coding both with separate
reset signals, and at the highest level ensuring one and only one is
actually used, with the other constantly driven inactive (e.g. with a
generic-controlled generate). I'd have to experiment to see if that is
possible. Preliminary, local optimization may not be able to ignore
the async reset, and therefore fail to implement the sync reset
optimally if it is the ultimate one used. Maybe gating the two signals
locally with the generic would give it a better clue. Nevertheless,
implementing both is pretty trivial to maintain if the reset
assignments are in one procedure. The sensitivity list issue is not a
problem if there are no events on the async reset signal (or at least
none that make it true).

Whether to implement async reset with the typical "if reset ... elsif
rising_edge... end if" template, or the "if rising_edge...end if; if
reset...end if" template is really a matter of preference.

The former will warn you if you missed a reset assignment, but will
implement extra feedback (clock disable) muxes on missed
(intentionally or not) reset assignments. The latter is more flexible
and will allow you to simply not reset a register if not needed/
allowed (with no feedback mux implemented), but it won't warn you
about (unintentionally) missed ones either.

> That's just the RTL view.
> One of the bits becomes an asynchronous carry out after synthesis.
> I just describe the value updates. Synthesis works out wires vs regs.

OK, thanks for the clarification. When using the "if count - 1 < 0
then" trick with natural subtypes, the RTL view from Synplify shows
the combinatorial carry bit without the extra register, and that was
throwing me off.

Andy

I wonder when Gaisler's article was written? It appears to be a
chapter from a book, but I have not found it.

His support for using a record for internal registers is somewhat
negated if a single process is used.

The only thing that has kept me from using record ports is the
inability to have user defined (per element) port modes applicable to
record types. Since I don't recommend component declarations &
instantiations (preferring direct entity instantiations), the primary
advantage to records on ports is to simplify the plumbing of complex
buses through multiple levels of hierarchy. But if the records have to
be separated for in/out/inout ports, that means that separate record
types for the same entire bus have to be defined for master and/or
slave destinations, not to mention the translations required between
those types, virtually eliminating the encapsulation benefit.

Depending on when this was written (e.g. Synopsys did not fully
support entity instantiations until at least after 2001), this may
have been as bleeding edge as he could go, and the move to entity
instantiations and single, clocked process style may not have caught
on by that time. Nevertheless Gaisler clearly demonstrates important
SW engineering aspects applicable to HDL based hardware design, and
gets his reader to start thinking along those lines.

Andy

It is quite easy to use macros to do both in Verilog. Using macros
and pre-processor you can:

// For ASync reset
`define RESET posedge reset,

// For Sync reset
`define RESET

always @( RESET posedge clock ) begin: p_register
if ( reset ) begin
...
end else begin
...
end
end : p_register


In Verilog/SystemVerilog/VHDL using parameters/generics and generate
statement is a bit more verbose:


// Verilog 2001/SystemVerilog
parameter bit RESET_ASYNC = 0 // 0: SYNC, 1: ASYNC

generate
if RESET_ASYNC begin : g_ASync

always @( posedge reset, posedge clock ) begin: p_register
if ( reset ) begin
...
end else begin
...
end
end : p_register

end else begin

always @( posedge clock ) begin: p_register
if ( reset ) begin
...
end else begin
...
end
end : p_register

end
endgenerate


// VHDL
generic RESET_ASYNC : bit := '0'; // '0': Sync, '1': ASync

g_ASync: if RESET_ASYNC begin

p_register: process( reset, clock ) begin
if ( reset='1' ) then
...
elsif ( rising_edge(clock) ) then
...
end if;
endprocess p_register;

end g_ASync;

g_Sync: if not RESET_ASYNC begin

p_register: process( clock ) begin
if ( rising_edge(clock) ) then
if ( reset='1' ) then
...
else
...
end if;
end if;
endprocess p_register;

end g_Sync;

-- Amal

On Jul 16, 9:31*am, Andy <jonesa...@comcast.net> wrote:
> On Jul 15, 5:05*pm, Mike Treseler <mtrese...@gmail.com> wrote:
>
> > to allow changing the reset style
>
> > *(v_rst, a_rst, s_rst, so_rst)
>
> > without otherwise touching the code.
>
> That's one area from the Keating's article that I'm interested in:
> ability to control (from a generic, etc.) whether async or sync reset
> gets implemented. It may be as simple as coding both with separate
> reset signals, and at the highest level ensuring one and only one is
> actually used, with the other constantly driven inactive (e.g. with a
> generic-controlled generate). I'd have to experiment to see if that is
> possible. Preliminary, local optimization may not be able to ignore
> the async reset, and therefore fail to implement the sync reset
> optimally if it is the ultimate one used. Maybe gating the two signals
> locally with the generic would give it a better clue. Nevertheless,
> implementing both is pretty trivial to maintain if the reset
> assignments are in one procedure. The sensitivity list issue is not a
> problem if there are no events on the async reset signal (or at least
> none that make it true).
>
> Whether to implement async reset with the typical "if reset ... elsif
> rising_edge... end if" template, or the "if rising_edge...end if; if
> reset...end if" template is really a matter of preference.
>
> The former will warn you if you missed a reset assignment, but will
> implement extra feedback (clock disable) muxes on missed
> (intentionally or not) reset assignments. The latter is more flexible
> and will allow you to simply not reset a register if not needed/
> allowed (with no feedback mux implemented), but it won't warn you
> about (unintentionally) missed ones either.
>
> > That's just the RTL view.
> > One of the bits becomes an asynchronous carry out after synthesis.
> > I just describe the value updates. Synthesis works out wires vs regs.
>
> OK, thanks for the clarification. When using the "if count - 1 < 0
> then" trick with natural subtypes, the RTL view from Synplify shows
> the combinatorial carry bit without the extra register, and that was
> throwing me off.
>
> Andy

On Jul 16, 9:17*am, Amal <akhailt...@gmail.com> wrote:
> // VHDL
> generic RESET_ASYNC : bit := '0'; *// '0': Sync, '1': ASync
>
> g_ASync: if RESET_ASYNC begin
>
> * p_register: process( reset, clock ) begin
> * * if ( reset='1' ) then
> * * * ...
> * * elsif ( rising_edge(clock) ) then
> * * * ...
> * * end if;
> * endprocess p_register;
>
> end g_ASync;
>
> g_Sync: if not RESET_ASYNC begin
>
> * p_register: process( clock ) begin
> * * if ( rising_edge(clock) ) then
> * * * if ( reset='1' ) then
> * * * * ...
> * * * else
> * * * * ...
> * * * end if;
> * * end if;
> * endprocess p_register;
>
> end g_Sync;


I was thinking more along the lines of the following for VHDL (GAR is
generic):

process (clk, rst) is
variable ...
procedure init (...) is
...
end procedure init;
begin
if rst and GAR then
init;
elsif rising_edge(clk) then
if rst and not GAR then
init;
else
...
end if;
end if;
end process;

or, if you wanted selective initialization of individual registers
(without feedback muxes):

process (clk, rst) is
variable ...
procedure init (...) is
-- ...
end procedure init;
begin
if rising_edge(clk) then
-- normal sync processing
-- ...
if rst and not GAR then
init;
end if;
end if;
if rst and GAR then
init;
end if;
end process;

Note I haven't tried this yet, so the synthesis tool may have a
problem recognizing that it does not have to use an async and sync
reset, then optimize one away later, which could result in sub-optimal
sync reset implementation (using AND logic).

Andy

> On Jul 15, 5:05 pm, Mike Treseler <mtrese...@gmail.com> wrote:
>> to allow changing the reset style
>>
>> (v_rst, a_rst, s_rst, so_rst)
>>
>> without otherwise touching the code.

Andy wrote:
> That's one area from the Keating's article that I'm interested in:
> ability to control (from a generic, etc.) whether async or sync reset
> gets implemented.


The generic template cases I have tested are below.

-- Mike Treseler



------------------------------------------------------------------------
procedure template_v_rst is -- My default.
begin -- a_rst is logically equivalent
if reset = '1' then -- Assumes synched trailing edge reset pulse
init_regs; -- reg_v := init_c; Variables only,
elsif rising_edge(clock) then
update_regs; -- reg_v := f(reg_v);Variables only
end if; -- Synchronous init optional
-- (state_v = idle_c)
update_ports; -- will infer port wires ok for reset and clock
end procedure template_v_rst; -- out_port <= reg_v; ports only
------------------------------------------------------------------------
procedure template_s_rst is -- for use in template comparisons
begin
if rising_edge(clock) then
if reset = '1' then
init_regs;
update_ports;
else
update_regs;
update_ports;
end if;
end if;
end procedure template_s_rst;
-----------------------------------------------------------------------
procedure template_a_rst is -- for use in template comparisons
begin -- Has proven equivalent to v_rst for synthesis.
if reset = '1' then
init_regs;
update_ports;
elsif rising_edge(clock) then
update_regs;
update_ports;
end if;
end procedure template_a_rst;
---------------------------------------------------------------------
procedure template_so_rst is -- Optional Reset by Andy
begin -- Compatible with non-resettable blocks
if rising_edge(clock) then
update_regs;
end if;
if reset = '1' then
init_regs;
end if;
update_ports;
end procedure template_so_rst;
--------------------------------------------------------------------
begin -- process main
case template_g is
when a_rst => template_a_rst;
when s_rst => template_s_rst;
when so_rst => template_so_rst;
when others => template_v_rst;
end case;
end process main;
---------------------------------------------------------------------

-- for details see:
-- http://mysite.verizon.net/miketreseler/uart.vhd

On Fri, 10 Jul 2009, Jan Decaluwe posted:

|-----------------------------------------------------------------------|
|"Since I started with RTL design in 1991, my goal has been to raise the|
|abstraction level as much as possible. Two key characteristics of my |
|design style are: |
| |
|* using a single clocked process for both control and data operations |
|* using variables, including register inference from them |
| |
|Since the early days I am convinced that this is a superior coding |
|style." |
|-----------------------------------------------------------------------|

Why?

|----------------------------------------------------------------------|
|" Therefore, I always expected it would become the mainstream |
|style anytime soon. On this I have been dead wrong. In the past two |
|decades, the mainstream style has moved in the opposite direction. The|
|absolute low point was Cliff Cummings' guideline not to use blocking |
|assignments in a clocked process, which effectively bans variable |
|semantics for RTL designers. |
| |
|However, now there may a new fact. For the first time, a high-profile |
|publication is in the making with a different message. It is |
|appropriately called "The Art of Good Design". Interestingly, it is |
|being written by Mike Keating, the co-author of the Reuse Methodology |
|Manual (RMM). I believe the RMM is partially responsible for the |
|"unstructured chaos" we are in (Mr. Keatings' words). So it's good to |
|see that he is changing his mind." |
|----------------------------------------------------------------------|

How do you know that he has repented instead of noticed a marketing
possibility, like Grady Booch?

|----------------------------------------------------------------------|
|" I have the impression that the |
|change comes after a careful study and rewriting of real designs. Good|
|that someone takes the time to do this." |
|----------------------------------------------------------------------|

"Reuse Methodology Manual for System-on-a-Chip" was supposedly based
on experience of real designs.

|----------------------------------------------------------------------|
|"In a recent post on his blog, Mr. Keating announced a preview of |
|Chapter 3 of The Art of Good Design: |
| |
|http://synopsysoc.org/futureofdesign/?p=35 |
| |
|[..] Moreover, he discards the |
|guideline not to mix blocking and non-blocking assignments. He does |
|this implicitly, as all blocking assignments are encapsulated in |
|functions, but this doesn't fundamentally alter the conclusion. |
| |
|[..]" |
|----------------------------------------------------------------------|

I do not have time to read his blog now, but perhaps he has not
conciously discarded that rule. I remember a lecturer who insisted
that shared memory should always be used instead of message passing,
so students whose project was rejected because of message passing
pointed out with glee that the lecturer accidentally used message
passing in a later lecture.

I have seen much SystemC(R) code which was presented as an example of
object orientation which was not at all like OO.

Regards,
Paul Colin Gloster

> On Fri, 10 Jul 2009, Jan Decaluwe posted:
>
> |-----------------------------------------------------------------------|
> |"Since I started with RTL design in 1991, my goal has been to raise the|
> |abstraction level as much as possible. Two key characteristics of my |
> |design style are: |
> | |
> |* using a single clocked process for both control and data operations |
> |* using variables, including register inference from them |
> | |
> |Since the early days I am convinced that this is a superior coding |
> |style." |
> |-----------------------------------------------------------------------|

Colin Paul Gloster wrote:
> Why?



I find it easy to follow sequential
code with variable registers.
I don't have to fire up the simulator
or sketch boxes and arrows just
to figure out the design intent.

-- Mike Treseler