inside or outside of the case statement ?

[Calvin T]

Hi all,

I hope you folks can help settle a debate regarding statement position
from a legacy design.

My coworker thinks position of 2 statements right after the big ELSE
statement is okay as if.

I think such position makes these 2 staments concurrent to the case
statement and may cause unexpected result.

These 2 statements should be moved inside the case statement as shown
below and one statement, e_reset_b <= '1' ; added in event_mux state
if the intention is to keep e_reset_b signal staying HI at the end.

While simulations currently show the same result in both cases, which
approach is correct or more reliable ?

Thanks,

Calvin

=================================================================

process (clk, nreset)
begin
if nreset = '0' THEN
er_state <= idle;
e_reset_b <= '1' ;
e_mux <= '0' ;
elsif rising_edge( clk) then
IF nlfm = '0' THEN
er_state <= idle;
e_reset_b <= '1' ;
e_mux <= '0' ;
ELSE
e_reset_b <= '1' ; -- <---------------- should NOT be
here
e_mux <= '0' ; -- <---------------- should NOT
be here
case er_state is
when idle =>
e_reset_b <= '1' ; -- <---------------- should be here
e_mux <= '0' ; -- <---------------- should
be here
if event_reset = '1' then
er_state <= event_rst ;
end if;
when event_rst =>
if event_reset = '0' then
er_state <= event_mux ;
end if;
e_reset_b <= '0' ;
when event_mux =>
e_reset_b <= '1' ; -- Added to stay HI at the end
e_mux <= '1' ;
when others =>
er_state <= event_mux;
e_reset_b <= '1' ;
e_mux <= '1' ;
end case;
END IF;
end if;
end process;

 

[jens]

Your coworker is correct - it's OK and there are no unexpected
results. I would take that concept one step further and assign
default values outside of the if statement and only assign non-default
values when necessary, as it makes it much easier to read, understand
and maintain. Something like this:

process (clk, nreset)
begin
if nreset = '0' THEN
er_state <= idle;
e_reset_b <= '1' ;
e_mux <= '0' ;
elsif rising_edge( clk) then

-- default values
e_reset_b <= '1' ;
e_mux <= '0' ;

IF nlfm = '0' THEN
er_state <= idle;
ELSE
case er_state is
when idle =>
if event_reset = '1' then
er_state <= event_rst ;
end if;
when event_rst =>
if event_reset = '0' then
er_state <= event_mux ;
end if;
e_reset_b <= '0' ;
when event_mux =>
e_mux <= '1' ;
when others =>
er_state <= event_mux;
e_mux <= '1' ;
end case;
END IF;
end if;
end process;

 

[Mike Treseler]

process (clk, nreset)
begin
if nreset = '0' THEN
er_state <= idle;
e_reset_b <= '1' ;
e_mux <= '0' ;
elsif rising_edge( clk) then
IF nlfm = '0' THEN
er_state <= idle;
e_reset_b <= '1' ;
e_mux <= '0' ;
ELSE
e_reset_b <= '1' ; -- <--------- should NOT behere
e_mux <= '0' ; -- <--------- should NOT be here
case er_state is
when idle =>
e_reset_b <= '1' ; -- <---- should be here
e_mux <= '0' ; -- <---- should be here
if event_reset = '1' then
er_state <= event_rst ;
end if;
when event_rst =>
if event_reset = '0' then
er_state <= event_mux ;
end if;
e_reset_b <= '0' ;
when event_mux =>
e_reset_b <= '1' ; -- Added to stay HI at the end
e_mux <= '1' ;
when others =>
er_state <= event_mux;
e_reset_b <= '1' ;
e_mux <= '1' ;
end case;
END IF;
end if;
end process;

While simulations currently show the same result in both cases, which
approach is correct or more reliable ?

That ELSE clause can only happen at the end of reset
so I expect that it isn't doing anything.
I would take it out in any case.

Since I don't know what e_reset_b does,
you will have to decide if it should
be driven by any idle state, or directly by nreset.


-- Mike Treseler

 

[Mike Treseler]

That ELSE clause can only happen at the end of reset
so I expect that it isn't doing anything.

Sorry, I misread the code. See Jens' posting.

I should have said,
"If your testbench can't see the difference,
it is incomplete."

 

[Calvin T]

Sorry, I misread the code. See Jens' posting.

I should have said,
"If your testbench can't see the difference,
it is incomplete."

Are these 2 statements and the CASE statement (as in the original
version) or the IF statement (as Jens suggested) concurrent or
sequential ?

If all 3 are concurrent, can a signal, i.e. e_mux, get conflicting
values at any specific time ?

For example, when the state machine is in event_mux state, default
sets e_mux to '0' and event_mux state sets e_mux to '1' ?

Calvin

 

[Dave]

Are these 2 statements and the CASE statement (as in the original
version) or the IF statement (as Jens suggested) concurrent or
sequential ?

If all 3 are concurrent, can a signal, i.e. e_mux, get conflicting
values at any specific time ?

For example, when the state machine is in event_mux state, default
sets e_mux to '0' and event_mux state sets e_mux to '1' ?

Calvin

These statements are inside of a process, which makes them sequential
by definition. Statements outside of a process are concurrent. Being
inside or outside of a process is what distinguishes the sequential
and concurrent statements in VHDL.

Dave

 

[Calvin C]

Hi Jens,

Another coworker of mine and I talked about your suggestion today.

He strongly believed that having different assignment statements to
the same signal both inside and outside of an "if" statement may
confuse the synthesis tool (i.e. Synopsys or Synplicity) since all
assigned values to the same FF must be evaluated within one clock
cycle.

Despite of the fact that the statements are sequential, the synthesis
result is unpredictable; the netlist may end up with an incorrect
implementation!

While I thought it should be okay, it seems I have nothing else to
back me up.

Is this a valid concern ?

Thanks,

Calvin

 

[joris]

As far as I know, the tool is really broken if it gets confused by such a construct;

 

[KJ]

Hi Jens,

Another coworker of mine and I talked about your suggestion today.

He strongly believed that having different assignment statements to
the same signal both inside and outside of an "if" statement may
confuse the synthesis tool (i.e. Synopsys or Synplicity)

Beliefs are totally irrelevant in this discussion. You and your
coworker should spend a bit more time actually using the tools and
testing these 'beliefs'.

since all assigned values to the same FF must be evaluated
within one clock cycle.

The synthesis tool does not 'evaluate all assigned values within one
clock cycle'. You make it seem like if there were 100 assignments to
the same signal that the synthesis tool would maybe get tired or run
out of time before the next clock comes along or while trying to
figure out what to set the signal to.

That's not at all what synthesis does. What synthesis *does* do is
compute the boolean logic equivalent of what you've written, sum of
products, and gates, or gates, things like that. Once it can express
a signal as a boolean function of 4-6 other signals, it can then map
this boolean function to a lookup table memory device which can then
implement whatever that boolean logic it happens to be...if that
signal is inside a clocked process, it enables the flop in that logic
block.

If there are other hardware structures inside the target device that
it can take advantage of, then it will instead stop at the point where
it recognizes that structure in the code (i.e. when it sees y <= a *
b; and it has hardware multiplier in the target device, it will map
that signal to a multiplier rather than spell out the boolean logic to
implement the multiplier...if it has no such multiplier hardware then
yes it will compute the boolean logic)

Despite of the fact that the statements are sequential, the synthesis
result is unpredictable; the netlist may end up with an incorrect
implementation!

And you have proof of this rather strange assertion?

Turning source code into boolean logic is not rocket science (although
doing a good job of it and coming up with fast, compact logic is a bit
tougher task).

Every tool has bugs that have yet to be discovered and eradicated. If
you were to actually come up with some source code that demonstrated
your statement, you should file a bug report, find a temporary work
around and get on with it but don't assume that this is somehow
generally true of all synthesis tools. Try the same code with another
tool and it probably works.

The discovery of a bug is not proof that 'the synthesis result is
unpredictable the netlist may end up with an incorrect
implementation!' it is the discovery of a bug...that will get fixed in
some future release. I've submitted dozens of these to the tool
suppliers. Doing so improves the tool eventually for everyone.

While I thought it should be okay, it seems I have nothing else to
back me up.

Opinions are cheap, everyone has one. It seems that it hasn't
occurred to you, that the only 'backup' you need is actual
results...you'll get that by testing your ideas and your coworker's
ideas on a real tool. It looks like you'll both be surprised at how
well the tool really does.

Is this a valid concern ?

No, but don't take my word for it (see above regarding the value of
opinions).

Instead try doing some homework and you'll come away much better off
than any good feelings you could get from a newsgroup. I suggest the
following regimen:

1. Write some code that you or your co-worker 'believe' would be
troublesome for the synthesizer to handle that is legit for a
synthesizable design (i.e. no delay lines, no transparent latches if
the target device doesn't have hard latches, etc.)
2. Synthesize it
3. Create a testbench and simulate the original design
4. Substitute the post route simulation model for your original design
and re-run the testbench
5. If your results differ, wrap it up as a test case and submit a bug
report to the synthesis supplier.
5a. Find a work around to the bug...you'll need it until the bug gets
fixed. If you can't find a work around pressure the supplier to find
one because you're stopped and won't use their part until you have a
work around.
6. If your results do match, go back to step 1. Do not exit this loop
until you're satisfied that the generalizations that you and your
coworker have are completely baseless.

KJ

 

[Jan Decaluwe]

Hi Jens,

Another coworker of mine and I talked about your suggestion today.

He strongly believed that having different assignment statements to
the same signal both inside and outside of an "if" statement may
confuse the synthesis tool (i.e. Synopsys or Synplicity) since all
assigned values to the same FF must be evaluated within one clock
cycle.

A signal is not a FF. A FF may be inferred from signal behavior.

Despite of the fact that the statements are sequential, the synthesis
result is unpredictable; the netlist may end up with an incorrect
implementation!

Not true.

While I thought it should be okay, it seems I have nothing else to
back me up.

You have: you can easily do some small experiments where
your coworker thinks it will go wrong, and you will see that
it's always OK.

Is this a valid concern ?

No. The confusion comes from a misunderstanding of VHDL semantics,
and the capabilities of synthesis.


Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[Mike Treseler]

Despite of the fact that the statements are sequential, the synthesis
result is unpredictable; the netlist may end up with an incorrect
implementation!

If I knew the expected netlist in advance,
I wouldn't need synthesis at all.

For the last 9 years, I have found that fpga synthesis netlists
always sim the same as my code, unless there is a warning.

While I thought it should be okay, it seems I have nothing else to
back me up.

I would consult the Oracle, Modelsim.

The whole point of simulation is that
I can see what my *code* does, with synthesis out of the loop.

-- Mike Treseler

 

[Andy]

I think I'd quit asking that co-worker for advice on synthesis.

He/she does not have a clue.

Andy

 

[prano2]

Hello everyone,
I'm a newbie in vhdl. And i'm having a project to build a 5 stage pipelined risc 32-bit microprocessor.
I have completed building all the modules that is alu, memory, register files etc. I'm having problem in how to implement pipelining concept.
Plz can any one guide me in coding the pipelining concept.
Thanks in advance!