I think Cliff Cummings have really good explanations, motivations for this: http://www.sunburst-design.com/papers/CummingsSNUG2003SJ_SystemVerilogFSM.pdf http:

I think Cliff Cummings have really good explanations, motivations for this: http://www.sunburst-design.com/papers/CummingsSNUG2003SJ_SystemVerilogFSM.pdf http://www.sunburst-design.com/papers/CummingsSNUG2003SJ_Sys... http://www.sunburst-design.com/papers/CummingsSNUG2000Boston_FSM.pdf http://www.sunburst-design.com/papers/CummingsSNUG2000Boston... But in general, when I see people struggle with Verilog and think it is hard to understand, it is code which have a single (clocked) process implementing everything. With non-blocking assignments everywhere, understanding the flow becomes really hard to follow. Usage of blocking and non-blocking assignments also affects how Verilog stratified simulation model schedules events. So how you code will in fact can affect how and how fast your design simulates. Cliff Cummings and Ivan Sutheland have several papers on how coding style affects both simulation and synthesis results. Highly recommend both authors. Some of them are quite old, but many of them are still very much valid. http://www.sunburst-design.com/papers/ http://www.sunburst-design.com/papers/ Ivan Sutherlands Verilog HDL reference guide has been extremely useful for many, many years: https://sutherland-hdl.com/pdfs/verilog_2001_ref_guide.pdf https://sutherland-hdl.com/pdfs/verilog_2001_ref_guide.pdf In short, it matters because code is read by humans, and style affect how easy it to read, modify and maintain. And the tools (as much a tool can) do care and their results are affected by code style. During core development I often at least load/compile code using a number of tool (ModelSim, Vivado, Quartus, Icarus, Verilator, VCS, Libero etc), even though for a given project I probably will only use a single simulator and synthesis tool. It is often quite interesting to see how quite different the parsers will interpret code, what things will be flagged as problems.