Multiple WAIT statements in a single process (for synthesis)

Discussion in 'VHDL' started by rnbrady@gmail.com, Jul 3, 2006.

  1. Guest

    Hi folks

    It would appear to me that synthesis tools can now handle multiple WAIT
    statements inside a single process. The case I'm interested in is that
    with several
    wait until rising_edge(clk);
    statements.

    My questions:

    1. Is this allowed for synthesis?

    2. This would appear to imply some sort of state-machine (actually just
    a counter in this case). Would the synthesis tool use this state
    machine for resource sharing? Strange question but bare with me.
    Example:

    process
    begin
    wait until rising_edge(clk);
    a <= b + c;
    wait until rising_edge(clk);
    d <= e + f;
    end process;

    Would two combinatorial adders be instantiated, or just one which is
    multiplexed according to the FSM/counter?

    This could provide a very interesting way to explore the area vs delay
    trade-off.

    Thanks in advance,
    Richard
    , Jul 3, 2006
    #1
    1. Advertising

  2. KJ Guest


    > It would appear to me that synthesis tools can now handle multiple WAIT
    > statements inside a single process. The case I'm interested in is that
    > with several
    > wait until rising_edge(clk);
    > statements.
    >
    > My questions:
    >
    > 1. Is this allowed for synthesis?
    >

    According to your first sentence you've stated that it can.....I can say
    that I've never tried it, and I'm suspect of how well it would be accepted
    but there have been odder things.

    > process
    > begin
    > wait until rising_edge(clk);
    > a <= b + c;
    > wait until rising_edge(clk);
    > d <= e + f;
    > end process;
    >
    > Would two combinatorial adders be instantiated, or just one which is
    > multiplexed according to the FSM/counter?
    >

    Assuming that the synthesis tool accepted it, it might see that it could
    combine them....if it was interested in optomizing space instead of timing.

    > This could provide a very interesting way to explore the area vs delay
    > trade-off.
    >

    I doubt that it would be a good way to explore anything. You feed the
    synthesis tool two things: code that defines the logic and constraints of
    various forms (i.e. clock speed performance requirements, pin locations, the
    target device/family etc.). The goal of any synthesis tool is to implement
    the logic within the stated constraints...no more, no less.

    KJ
    KJ, Jul 4, 2006
    #2
    1. Advertising

  3. Interesting problem.

    In your original problem you assigned to the outputs a and d. Have a look at
    the generated schematic.
    http://www.cs.utwente.nl/~molenkam/multiwait/multi_wait_2_outputs.pdf
    (Operand are 2 bits). I can imagine that using one adder is not optimal in
    this case.
    However still something like an FSM is needed since in the first state
    output a is calculated and in the next clock cycle output d is calculated
    (and you have remember output a), etc.

    Based on your case have a look at the following case in which only one
    output is used (output d).
    http://www.cs.utwente.nl/~molenkam/multiwait/multi_wait.pdf

    library IEEE;
    use IEEE.std_logic_1164.ALL;
    use IEEE.numeric_std.ALL;
    entity demo is
    port (b,c,e,f : in unsigned(1 downto 0);
    d : out unsigned(1 downto 0);
    clk : in std_logic);
    end demo;

    architecture multi_wait of demo is
    begin

    process
    begin
    wait until rising_edge(clk);
    d <= b + c; -- NOTE output a is changed in d.
    wait until rising_edge(clk);
    d <= e + f;
    end process;

    end multi_wait;

    Egbert Molenkamp

    <> wrote in message
    news:...
    > Hi folks
    >
    > It would appear to me that synthesis tools can now handle multiple WAIT
    > statements inside a single process. The case I'm interested in is that
    > with several
    > wait until rising_edge(clk);
    > statements.
    >
    > My questions:
    >
    > 1. Is this allowed for synthesis?
    >
    > 2. This would appear to imply some sort of state-machine (actually just
    > a counter in this case). Would the synthesis tool use this state
    > machine for resource sharing? Strange question but bare with me.
    > Example:
    >
    > process
    > begin
    > wait until rising_edge(clk);
    > a <= b + c;
    > wait until rising_edge(clk);
    > d <= e + f;
    > end process;
    >
    > Would two combinatorial adders be instantiated, or just one which is
    > multiplexed according to the FSM/counter?
    >
    > This could provide a very interesting way to explore the area vs delay
    > trade-off.
    >
    > Thanks in advance,
    > Richard
    >
    Egbert Molenkamp, Jul 4, 2006
    #3
  4. On 3 Jul 2006 15:36:08 -0700, wrote:

    >Hi folks
    >
    >It would appear to me that synthesis tools can now handle multiple WAIT
    >statements inside a single process. The case I'm interested in is that
    >with several
    > wait until rising_edge(clk);
    >statements.
    >
    >My questions:
    >1. Is this allowed for synthesis?


    By some tools, yes. It's usually known as an "implicit
    state machine".

    >2. This would appear to imply some sort of state-machine (actually just
    >a counter in this case). Would the synthesis tool use this state
    >machine for resource sharing? Strange question but bare with me.


    >Example:
    >
    >process
    >begin
    > wait until rising_edge(clk);
    > a <= b + c;
    > wait until rising_edge(clk);
    > d <= e + f;
    >end process;


    This example is effectively the same as

    process begin
    if rising_edge(clk) then
    case state is
    when S0 => a <= b+ c;
    when S1 => d <= e + f;
    end case;
    end if;
    end process;

    If the tools can resource-share one, they can do the other.
    Again it depends on the tool, and of course the options you've
    selected for any given run.

    >This could provide a very interesting way to explore the area vs delay
    >trade-off.


    It could. It did! Synopsys Behavioural Compiler, Mentor Monet and
    I guess a bunch of other tools aimed to do exactly this - allow you to
    move from a more algorithm-like description to a hardware
    implementation. In practice, to use them well it was necessary to
    tweak endless constraints and options to drive the tool to do the
    optimisations and transformations that you really wanted. Tool
    vendors will be more authoritative than I can, but I think it's fair
    to say that the technology in those tools has found its way into the
    current generation of "C synthesis" products.

    By the way: there's one extremely unpleasant consequence of
    implicit state machine coding style. How do you implement
    a reset???!!!
    --
    Jonathan Bromley, Consultant

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

    Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
    Jonathan Bromley, Jul 4, 2006
    #4
  5. Ricardo Guest

    I have never worked this way (and probably won't), but can't something
    like this work?

    ....
    sig <= rest_cond when rst_i = '0';
    wait until (rising_edge(rst) or rst = '1');
    wait until rising_edge(clk);
    --rest of the code
    ....

    When the process loops to the first sentence, if it finds rst = '1' it
    will not reset. but if it finds a reset = 0, it goes to initial
    condition and will wait the reset to be over.

    It sounds very strange to me, but anyway... I won't work this way
    either, IMHO.

    Regards,

    Ricardo

    Jonathan Bromley escreveu:

    > On 3 Jul 2006 15:36:08 -0700, wrote:
    >
    > >Hi folks
    > >
    > >It would appear to me that synthesis tools can now handle multiple WAIT
    > >statements inside a single process. The case I'm interested in is that
    > >with several
    > > wait until
    > >statements.
    > >
    > >My questions:
    > >1. Is this allowed for synthesis?

    >
    > By some tools, yes. It's usually known as an "implicit
    > state machine".
    >
    > >2. This would appear to imply some sort of state-machine (actually just
    > >a counter in this case). Would the synthesis tool use this state
    > >machine for resource sharing? Strange question but bare with me.

    >
    > >Example:
    > >
    > >process
    > >begin
    > > wait until rising_edge(clk);
    > > a <= b + c;
    > > wait until rising_edge(clk);
    > > d <= e + f;
    > >end process;

    >
    > This example is effectively the same as
    >
    > process begin
    > if rising_edge(clk) then
    > case state is
    > when S0 => a <= b+ c;
    > when S1 => d <= e + f;
    > end case;
    > end if;
    > end process;
    >
    > If the tools can resource-share one, they can do the other.
    > Again it depends on the tool, and of course the options you've
    > selected for any given run.
    >
    > >This could provide a very interesting way to explore the area vs delay
    > >trade-off.

    >
    > It could. It did! Synopsys Behavioural Compiler, Mentor Monet and
    > I guess a bunch of other tools aimed to do exactly this - allow you to
    > move from a more algorithm-like description to a hardware
    > implementation. In practice, to use them well it was necessary to
    > tweak endless constraints and options to drive the tool to do the
    > optimisations and transformations that you really wanted. Tool
    > vendors will be more authoritative than I can, but I think it's fair
    > to say that the technology in those tools has found its way into the
    > current generation of "C synthesis" products.
    >
    > By the way: there's one extremely unpleasant consequence of
    > implicit state machine coding style. How do you implement
    > a reset???!!!
    > --
    > Jonathan Bromley, Consultant
    >
    > DOULOS - Developing Design Know-how
    > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
    >
    > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
    >
    > http://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.
    Ricardo, Jul 4, 2006
    #5
  6. KJ Guest

    > By the way: there's one extremely unpleasant consequence of
    > implicit state machine coding style. How do you implement
    > a reset???!!!
    > --


    'Extremely unpleasant consequence' is a bit of an understatement. If the
    tool supports this style but does not also implement initial value
    assignments then this would be fatal. If it does support inital value
    assignments then it has at least implemented a reset (i.e. at power on prior
    to the clock) but the primary use of this coding style would be in leading
    would be designers astray in thinking that they can really design something
    like this to actually work.

    Trying to answer a couple simple question to the original post should lead
    one to understand why this style, while valid VHDL code, should not be used
    to design real circuits: How do you know (or control) which rising edge of
    'clk' is the very first one and which is the second? If you don't then how
    are you going to know when 'a' has been updated or 'd' has? Or on which
    clock cycle the inputs 'b', 'c', 'e' or 'f' are valid?

    KJ
    KJ, Jul 4, 2006
    #6
  7. Guest

    Thanks for all the input.

    My reason for posting was actually an idea I saw in a textbook, where
    an arithmetic expression with multiple additions and multiplications is
    implemented in two ways:

    1. Combinatorially (area hungry)
    2. Using registers to allow resource sharing of arithmetic units

    The second approach requires registers to store the intermediate
    results, mutliplexers to select operands, and a FSM to control the
    registers and multiplexers, activating them in the right sequence (and
    as I now realize, a reset circuit).

    The question is: what is the best way to produce this structure? If it
    could easily be inferred from a single process statement with multiple
    wait statements, then that would be an interesting option. However, I
    think you have all convinced me that a more explicit approach is the
    best option.

    Thanks,
    Richard
    , Jul 5, 2006
    #7
    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. walala
    Replies:
    4
    Views:
    2,106
    Ralf Hildebrandt
    Sep 8, 2003
  2. walala
    Replies:
    4
    Views:
    1,199
    Technology Consultant
    Sep 9, 2003
  3. HeEm
    Replies:
    7
    Views:
    383
    Dennis Lee Bieber
    Mar 14, 2007
  4. amirsadig
    Replies:
    0
    Views:
    610
    amirsadig
    Mar 24, 2007
  5. Colin Beighley
    Replies:
    8
    Views:
    2,741
Loading...

Share This Page