--- Quote Start ---
Sure, just encode the combinational outputs separately, either with explicit assign statements or using a separate case statement.That's a separate issue than encoding the state machine itself.
--- Quote End ---
To do this you have to copy-paste transition conditions from the state machine? Distributing them all over the code?
--- Quote Start ---
As a general rule I think it's bad practice to have combinational signals flow through a state machine unclocked to create combinational outputs. I understand that there are times where that's the only option, but those times are pretty rare in my experience. If you allow yourself to code that way as general practice then you probably end up creating combinational outputs even when NOT necessary.
--- Quote End ---
That's pure conjecture ... see also below.
--- Quote Start ---
Bottom line is that I think the multi-process approach makes reading and debugging the code much more difficult. Especially if you don't give special names to clocked vs. non-clocked state machine outputs. If you don't do that then it can become very confusing. If combinational outputs are used as an exception then you can assign them separately with a comment block to explain the what and why.
I've been a consultant for a very long time so have worked in many different organizations. I try to adopt coding practices that make it as easy as possible for my customers to maintain my code after I leave. Good business practice. State machine coding is a big part of that, and I use state machines as often as I can because they can be self-documenting if you take the time to add appropriate comments.
--- Quote End ---
You must assess that these combinational outputs
eventually are used in some other
synchronous process further down or up the hierarchy. E.g. I always instantiate a counter component if I need to count something. To load a downcounter with some value by the state machine I either need a combinatorial output, or in the case of a synchronous output load one value less. If I want to test the counter in the next clock, as the state machine has stepped to another state too, I have a problem with the external counter being loaded with the synchronous output, as the counter has not been loaded with that new value yet.
--- Quote Start ---
This is all just my personal opinion based on many years of doing this stuff. Please don't take offense. I'm just trying to share my experiences and what works for me. All the Mealy/Moore multi-process state machine crap that gets taught in schools and perpetuated in books is just bad information IMO.
--- Quote End ---
None taken.
I too couldn't care less either whether Moore or Mealy or the two together are doing the job. But your style is exactly one of those two, or am I mistaken? I had to look it up (searching at least 5 VHDL books) and it is
moore. So I most often do
mealy things :)
--- Quote Start ---
Edit: While I'm at it I may as well make half the world angry and do a little VHDL trashing. For the life of me I can't understand why anyone writing rtl code would want to use VHDL vs. verilog/systemverilog. It used to be that VHDL was much more capable for modeling, but systemverilog has changed that.
--- Quote End ---
I nowadays mostly code in
myhdl (http://www.myhdl.org) ... and for VHDL I use a good editor:
sigasi (http://www.sigasi.com) (Which also does some Verilog)
--- Quote Start ---
For synthesizable rtl code VHDL is just way too much work to write and to read. If I never had to read a line of VHDL code again I would be a happy man!!
Bob
--- Quote End ---
If we compare VHDL as being Pascal/Ada like and Verilog as C-like (as you Verilog-guys classify them), I can quote an old boss of mine:
if you get a pascal program compiled without errors, you have a good chance it will run. with c on the other hand you are nowhere yet. I once wrote some VHDL code to compare all these styles and posted it on
all programmable planet, but the sponsor of that web-site pulled it off the air without a warning, and I seem to have lost the text ... I put the VHDL source code here:
https://gist.github.com/josyb/a84d067f0a468d0931599f1891bc83ff I haven't got much free time lately, but let's define a non-trivial exercise and compare the coding styles and the QoR.
One more defence: the latest book on VHDL:
effective coding with vhdl, principles and best practice by
ricardo jasinsky Page 510:"The two-process styles offers several advantages [over the one-process style]".
Josy
Honored Contributor
