style for coding latches

Discussion in 'VHDL' started by Paul Baxter, Aug 10, 2003.

  1. Paul Baxter

    Paul Baxter Guest

    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, Aug 10, 2003
    #1
    1. Advertising

  2. 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, Aug 10, 2003
    #2
    1. Advertising

  3. 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, Aug 10, 2003
    #3
  4. "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, Aug 11, 2003
    #4
  5. 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, Aug 11, 2003
    #5
  6. 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=vhdl template test_this

    -- Mike Treseler
     
    Mike Treseler, Aug 11, 2003
    #6
  7. 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, Aug 12, 2003
    #7
  8. 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, Aug 15, 2003
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Keith R. Williams

    Re: Avoiding latches

    Keith R. Williams, Jul 14, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,197
    Keith R. Williams
    Jul 14, 2003
  2. Ken Smith

    Re: Avoiding latches

    Ken Smith, Jul 15, 2003, in forum: VHDL
    Replies:
    3
    Views:
    2,597
    Tim Hubberstey
    Jul 17, 2003
  3. Jan De Ceuster

    Re: Avoiding latches

    Jan De Ceuster, Jul 15, 2003, in forum: VHDL
    Replies:
    0
    Views:
    1,711
    Jan De Ceuster
    Jul 15, 2003
  4. calmar
    Replies:
    11
    Views:
    902
    calmar
    Feb 21, 2006
  5. Ken Varn
    Replies:
    0
    Views:
    473
    Ken Varn
    Apr 26, 2004
Loading...

Share This Page