case statement

J

Just an Illusion

Officially yes (ieee 1076 Annexe A, sequential_statement, if_statement,
case_statement_alternative, sequence_of_statement, and 1076.6),

But now your code can become a little bit confusing if you have too lot
of imbrication.

Do you have a problem with them ?

Rgrds,
JaI
 
J

JJ

you can nest sequential statements. If your code is for rtl it can create
sh*tloads of logic so do this sparingly.
 
D

DrB

I would opine that it is the natural way to code state machines and
suchlike:
- outer case to lay out the current states, as choices
- inner case (within the choices) to select the next state / outputs
- obviously within a process, clocked and gated by an appropriate clock and
(optional) clock enable

If the definition of next state / output is best expressed by (further)
nested case statements then do so. Equally, if prioritised choices are
appropriate use if constructs. Computers are good at reducing human
readable logic to concise boolean equations - as long as the logic is
synchronous.

Additionally, if the outputs are registered the use of variables for
NextState enables the output logic to use them as inputs, simplifying the
logic which expresses NextOutput. Using a cascade of case statements;
firstly to define NextState, secondly to define NextOutput.

The only serious constraints on complexity are:
- what your simulator and synthesiser will stand
-- Model Sim, Leonardo and Synplicity will accomodate the foregoing, others
tools may stall
- what your FPGA / CPLD will accomodate
-- which reduces to a speed / size trade, do you want it in Tc or in three
gates

HtH

DrB
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,572
Members
45,046
Latest member
Gavizuho

Latest Threads

Top