Multiple WAIT statements in a single process (for synthesis)

[rnbrady]

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

 

[KJ]

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

 

[Egbert Molenkamp]

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

 

[Jonathan Bromley]

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
(e-mail address removed)
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]

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:

 

[KJ]

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

 

[rnbrady]

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