3 ms·

Pretty good collection of questions. A bit weird with the the huge, hand drawn figures here and there in the questions section. Sometimes they seem to be illust

Pretty good collection of questions. A bit weird with the the huge, hand drawn figures here and there in the questions section. Sometimes they seem to be illustrations, sometimes a partial solution. Cool to see time borrowing included in the material. One thing I jumped on was the questions related to Verilog. This document is (c) 2021, but uses module declarations, syntax etc from Verilog pre 2001 (1995-ish). OTOH it actually teaches building FSMs with two processes, which is good to see. Also, there are quite a few minor errors in the material. Spelling etc. But overall a good set of digital electronics and VLSI questions.

evancox100 5y ago
Agree, weird mix of modern and super old-school.
CamperBob2 5y ago
OTOH it actually teaches building FSMs with two processes, which is good to see. Why? I shouldn't have to look in multiple places to see what the FSM "code" is doing, and the tools don't care.
- JoachimS 5y ago
  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.

evancox100 5y ago

Agree, weird mix of modern and super old-school.

CamperBob2 5y ago

OTOH it actually teaches building FSMs with two processes, which is good to see. Why? I shouldn't have to look in multiple places to see what the FSM "code" is doing, and the tools don't care.

JoachimS 5y ago
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.