style for coding latches

[Paul Baxter]

In VHDL I'm forever writing process statements to produce
1) a simple clocked FF
2) As above with async reset
3) As above with clock enable

I must write things like

process (clk, reset)
begin
if (reset = '1') then
signal <= '0';
elsif (rising_edge(clk)) then
if (enable = '1') then
signal <= next_signal_value;
end if;
end if;
end process;

At the risk of looking stupid, surely there is a simpler way.

signal <= next_signal_value when (rising_edge(clk)); -- ??

Paul

 

[Egbert Molenkamp]

s <= '0' when reset='1' else
nexts when (rising_edge(clk));

works if your synthesis support VHDL'93. Otherwise an additional else is
needed:
s <= '0' when reset='1' else
nexts when (rising_edge(clk)) else
s;

Egbert Molenkamp

 

[Tim Hubberstey]

In VHDL I'm forever writing process statements to produce
1) a simple clocked FF
2) As above with async reset
3) As above with clock enable

I must write things like

process (clk, reset)
begin
if (reset = '1') then
signal <= '0';
elsif (rising_edge(clk)) then
if (enable = '1') then
signal <= next_signal_value;
end if;
end if;
end process;

At the risk of looking stupid, surely there is a simpler way.

signal <= next_signal_value when (rising_edge(clk)); -- ??

Lets refer to the following template as REF (the one you listed is
actually the templace for a FF with clock enable):

process (clk, reset)
begin
if (reset = '1') then
Async assignments
elsif (rising_edge(clk)) then
Sync assigmnents
end if;
end process;

There are, indeed, many ways of writing this that are equivalent.

The truly important question, however, is what can you be sure will be
recognized as a FF all synthesizers that see your code. This may or may
not include your shortened version. I agree that REF is wordy BUT it is
recognized by all synthesizers I've dealt with recently (really old
synthesizers often required WAIT statements but I don't think any of
those are still around). Further, REF is embedded in many editors so
it's not really a great hardship to use it. Synthesis tools are based to
a very large extent on pattern recognition. If you don't supply them
with a pattern that they recognize, the results will probably not be
optimal. This is less of an issue for FPGAs than for ASICs but there can
still be detrimental effects. This is the reason for the little-known
(and possibly little-followed) spec on synthesizable VHDL, 1076.6 - VHDL
Register Transfer Level Synthesis.

If you want to create a test case with all the methods you can think of
and then run it through all the synthesizers that exist, you could
create a list of constructs that work, at that moment. But I personally
feel that this would just be "busywork" since REF is a perfectly
acceptable (albeit verbose) template and, since REF is the only
"standard" that I am aware of that all synthesizers seem to agree on
(and is supported in 1076.6), I would be reluctant to use anything else
because it might just stop working in the next rev of the tool.

 

[Jonathan Bromley]

In VHDL I'm forever writing process statements to produce
1) a simple clocked FF
2) As above with async reset
3) As above with clock enable

I must write things like

[...]

Other respondents have clarified why it needs to be like that.

My question is: why are you spending so much time creating
such simple processes? Instead of fighting to make the
template smaller, the _right_ approach is surely to make
each template do so much work for you that the overhead of
writing the template is negligible. My personal rule of
thumb is that a typical process will have around 40 lines
of code in the clocked branch, but I've seen and written
processes with far more than that.
--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: (e-mail address removed)
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Charles M. Elias]

Lets refer to the following template as REF (the one you listed is
actually the templace for a FF with clock enable):

process (clk, reset)
begin
if (reset = '1') then
Async assignments
elsif (rising_edge(clk)) then
Sync assigmnents
end if;
end process;

There are, indeed, many ways of writing this that are equivalent.

The truly important question, however, is what can you be sure will be
recognized as a FF all synthesizers that see your code. This may or may
not include your shortened version. I agree that REF is wordy BUT it is
recognized by all synthesizers I've dealt with recently (really old
synthesizers often required WAIT statements but I don't think any of
those are still around). Further, REF is embedded in many editors so
it's not really a great hardship to use it. Synthesis tools are based to
a very large extent on pattern recognition. If you don't supply them
with a pattern that they recognize, the results will probably not be
optimal. This is less of an issue for FPGAs than for ASICs but there can
still be detrimental effects. This is the reason for the little-known
(and possibly little-followed) spec on synthesizable VHDL, 1076.6 - VHDL
Register Transfer Level Synthesis.

If you want to create a test case with all the methods you can think of
and then run it through all the synthesizers that exist, you could
create a list of constructs that work, at that moment. But I personally
feel that this would just be "busywork" since REF is a perfectly
acceptable (albeit verbose) template and, since REF is the only
"standard" that I am aware of that all synthesizers seem to agree on
(and is supported in 1076.6), I would be reluctant to use anything else
because it might just stop working in the next rev of the tool.

Tim,

You could make a component like this:
-------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
-------------------------------------------------------------------------------
package ffs_pkg is

component d_ff is

port ( data : in std_logic := '1';
clock : in std_logic;
enable : in std_logic := '1';
q : out std_logic;
aset : in std_logic := '0';
aclr : in std_logic := '0';
sclr : in std_logic := '0'
);

end component d_ff;

end package ffs_pkg;
-------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use work.ffs_pkg.all;
-------------------------------------------------------------------------------
entity d_ff is

port ( data : in std_logic := '1'; --optional
clock : in std_logic; --required
enable : in std_logic := '1'; --optional
q : out std_logic; --required
aset : in std_logic := '0'; --optional
aclr : in std_logic := '0'; --optional
sclr : in std_logic := '0' --optional
);
end d_ff;

architecture arch_d_ff of d_ff is

begin
pd_ff : process (clock, aset, aclr )
begin
if aset = '1' then
q <= '1';
elsif aclr = '1' then
q <= '0';
elsif rising_edge( clock ) then
if sclr = '1' then
q <= '0';
elsif enable = '1' then
q <= data;
end if;
end if;
end process pd_ff;
end arch_d_ff;
-------------------------------------------------------------------------------
-- This is a template for instantiating the component. Only required port
-- signals need be used; others can be omitted.
-------------------------------------------------------------------------------
--U1 : d_ff
-- port map ( data => ,
-- clock => ,
-- enable => ,
-- q => ,
-- aset => ,
-- aclr => ,
-- sclr =>
-- );

 

[Mike Treseler]

Other respondents have clarified why it needs to be like that.

My question is: why are you spending so much time creating
such simple processes? Instead of fighting to make the
template smaller, the _right_ approach is surely to make
each template do so much work for you that the overhead of
writing the template is negligible. My personal rule of
thumb is that a typical process will have around 40 lines
of code in the clocked branch, but I've seen and written
processes with far more than that.

I have to line up with Mr. Bromley on this one.
VHDL design is about writing synchronous
processes that that each infer many flops and registers.

Related thread:
http://groups.google.com/groups?q=vhdl+template+test_this

-- Mike Treseler

 

[Tim Hubberstey]

I have to line up with Mr. Bromley on this one.
VHDL design is about writing synchronous
processes that that each infer many flops and registers.

I don't agree. To paraphrase your statement: VHDL design is about
writing synchronous processes that each infer the appropriate number of
flops and registers for the situation.

Sometimes you need to write processes that infer just a couple of FFs,
like for clock domain synchronizers or registered I/O pads. Sometimes it
is necessary to group a small number of FFs together under one instance
name to make it easier to attach constraints. And sometimes you write
code that infers hundreds or even thousands of FFs inside one process
that spans hundreds of lines. I've done all of these things at various
times. It simply depends on what the job requires.

The whole point of my previous post is that you shouldn't stray too far
from the "template" that the synthesizers are looking for or you won't
get the results you want. When the synthesizer documentation says "write
your code this way in order to infer this structure", you'd better do it
or expect to not be pleased with the results.

 

[Mike Treseler]

Sometimes you need to write processes that infer just a couple of FFs,
like for clock domain synchronizers or registered I/O pads.

You've got me there.

I do generate lots of little synchronizing shift register processes.

And there's always a few proprietary things like PLLs that
I can't avoid.

However for the guts I like big processes and signals only
for io and interprocess communication.

Of course there are many ways to skin a cat.


-- Mike Treseler