Boolean Network Simplification using Satisfiability Don’t care Conditions

I will leave it to an LRM expert to provide a more detailed answer, but in short, your approach should be valid - I ran a quick test with a recent version of Quartus, and it handles '-' like it's supposed to - the logic generated is reduced as expected when the output is defaulted to '-' ('X' works too, by the way). More on the approaches you listed:

• Not assigning the signal isn't really an option for your example, of course, if you don't want latches. If it's a clocked process, you're slightly better off, but you'll still get enables where you might not need them. Maybe I'm missing your intent here.

• '-', as previously noted, is probably the best option, for both semantic and practical reasons.

• Depends on what you mean by "undefined". 'X' is technically "unknown". 'U' is for uninitialized signals, which ModelSim displays as "X" for hex representations. 'X' does seem to work, though, as I noted above.

Another alternative would be to do the optimization yourself and remove one case from being tested explicitly:

if instruction(15 downto 8) = "11111001" then
  write_data <= std_ulogic_vector(resize(signed(instruction(7 downto 4)), 16));
else
  write_data <= std_ulogic_vector(resize(signed(instruction(7 downto 0)), 16));
end if;

This has significant disadvantages (mostly related to code clarity), though, and I would probably opt for a more ideal solution.

Incidentally, '-' is also commonly used with std_match(), which I would consider using for your decoding, e.g.:

if std_match(instruction(15 downto 8), "1100----") then

Though at that point, you're probably better off just using case?.

I think you're going into far too much detail too early on. I've designed complex state machines many years ago and this kind of problem is going to be a bit tricky to get right.

Step 1, is to get the behaviour right. Don't even think about assigning binary numbers to represent the states yet. Clearly from your postings, you haven't really got the whole behaviour worked out.

Step 2 is assign state codes and go through the an implementation technique such as the algorithimic state machine method (ASM) to design and simplify the logic, assuming you are building a logic circuit to implement it. Then you can worry about physical implementation on chips such as field programmable logic sequencers (FLPS), or even FPGA's (field programmable gate arrays), and the representation of the design can either be as a schematic (schematic capture) or a hardware description language (HDL) based.

Don't worry about any of that yet. Just focus on designing the behaviour first.

You've gone straight into a state diagram. That's your end result. That's what you're trying to achieve, so you can then build the state machine.

I think you need to start thinking about using say, a UML sequence diagram to illustrate the behaviour. Each traffic light and sensor (inductive sensor) will be an object on the sequence diagram, and the sensors will trigger a set of behaviour, in a UML sequence diagram time flows down the page, so you can easily represent time based behaviour and what happens to the lights after the inductive sensor has been triggered.

So, I'd suggest design the time based behaviour using a sequence diagram first, then when you've got that right, got what you want, then you can move to a state diagram. Then you can move to building it.