Forum Discussion
Altera_Forum
Honored Contributor
9 years ago --- Quote Start --- Try me! Almost every state machine I write, inside an Avalon_ST module, has asynchronous outputs. Can you show me how to do that with a synchronous (only) process? --- Quote End --- 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. 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. 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. 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. 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. 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