style for coding latches

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

Paul Baxter

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


"Paul Baxter" <> schreef in bericht
news:3f365445$0$18493$ ...
> 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

Paul Baxter wrote:
>
> 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.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

Tim Hubberstey

"Paul Baxter" <> wrote in
message news:3f365445$0$18493$ ...

> 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:
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.

Jonathan Bromley

Tim Hubberstey <> wrote in message news:<>...
> Paul Baxter wrote:
> >
> > 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.
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 =>
-- );
-------------------------------------------------------------------------------

Best regards,

Charles

Charles M. Elias

Jonathan Bromley wrote:

>
> 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=vh...late+test_this

-- Mike Treseler

Mike Treseler

Mike Treseler wrote:
>
> Jonathan Bromley wrote:
>
> >
> > 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.

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.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

Tim Hubberstey

Tim Hubberstey wrote:

> 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

Mike Treseler