Practice Problems for Hardware Engineers
arxiv.org
arxiv.org
Section 17 is mostly testing for rote learning, I'm guessing these questions are taken from some university course?
My favourite quesiton is 18.a) "Verilog Syntax/compile errors" which asks you to spot all the mistakes (while ignoring behaviour) and hint at a fix -- but since you're allowed to ignore all behaviour a valid (and reasonable) fix is actually to delete it all.
Beyond these superficial issues I'm mostly interested because my company takes in a lot of EE graduates for beginner FPGA roles, and in our experience almost all undergraduate instructive material is 30 years out of date. Almost all graduates still seem to get taught that VLSI design is done by manually instantiating combinatorial gates and D type flip flops.
And in honesty, I think this document falls into the same trap, section 18 asks the learner to design a transparent latch as a single module. It's very rare to want put a transparent latch in an FPGA, and you'd never dedicate an entire entity to describing one. It also asks for an 8-to-1 mux, a 4 bit shift register, and a 16 bit shift register.
However I think question 18.f) "FSM – Verilog Design of a Crosswalk Controller" is actually a very good example of the right sort of question (for, say midrange/advanced beginner), which will focus the students' attention on "normal" RTL design. Specifically I like that is requires specific clock timings (assert X for 32 clock cycles, assert Y for 10 cycles), as I think off-by-one timing errors in FSMs are a very common problem for beginners.
A more difficult extension (perhaps a part of student's first introduction to concurrency in an FPGA) would be to design a crosswalk controller with slightly more complexity.. maybe multiple buttons or multiple junctions or whatever.
What are some of the concepts in FPGA development that aren't taught in academic settings?
If I had to guess I'd wager its stuff in the tooling infrastructure that's built up peripheral or in parallel to HDL - thinking things like Simulink model generation (for digital filter applications), HLS tooling, Chisel, cocotb, Python/TCL build systems (insert grumbling about Vivado GUI here), etc.
My impression is that there hasn't been any revolutionary syntactic developments in HDL syntax in a while, but I also haven't done a whole lot of FPGA work since leaving college.
Clock domain crossing methods. And clocking, PLLs, clock distribution, reset strategies etc.
HW/SW co-design with CPUs acting as control paths and APIs to allow SW to supervise and control the HW efficiently.
Modern languages and tools - SystemVerilog, esp for verification is a good example. Formal verification tools.
Debugging and testing. JTAG, Scan chains, BIST etc.
In short, what we see in our graduates' teaching is a wrong-assumption that VHDL/verilog design is a bit like designing for 74-series chips, where you work out that you need to splat down a load of and/or/not gates and individually wire them up to some flipflops. This is reflected in section 18 of the problems, where students are asked to design simplistic low-level entities (sregs, muxes, and a single transparent latch). This is wrong because the true building blocks in the bottom of an FPGA are not individual and/or/not gates so there's no use in designing as if they were.
This leads to a situation where people have done their VLSI/FPGA module at university but they arrive without knowledge of core fundamentals such as: * Not clocking flops with data * Design for even mild levels of concurrency (it's common for courses to never get students to make two FSMs talk to each other even in the same clock domain -- pretty sure this document doesn't do this in section 18) * Thus everyday problems such as race conditions and deadlock will never have been covered.
IMO the very-incomplete nature of such courses also which attempts to pile concepts on top of each other too quickly without adequate explanation means that people come out of courses without really understanding how little of the basics that they know.
I accept that universities only ahve so much time to teach their students, and there is little academic pedagogical value in spending time on specific technologies, but the general poor approach could definitely be a lot better.
tldr; I agree that there hasn't been any revolutionary development in HDLs, but most universities missed the mark on teaching the basics when they first wrote their FPGA courses in the 1990s, and they haven't got much better since.
(P.S. if anyone wants to create a HDL without the crippling expressiveness flaws of either VHDL or verilog, I will personally transmute myself into a solid gold toilet especially for them)
if anyone wants to create a HDL without the crippling expressiveness flaws of either VHDL or verilog, I will personally transmute myself into a solid gold toilet especially for them
If I ever do this, and get rich off of it, count on me to seed fund your personal transformation XD
You'll be asked to draw a low-side drive with a MOSFET and an inductive load, given a circuit to analyze and find bugs, etc. Asked basic stuff. Ohm's Law, Smith chart if RF. No trivia like this.
If SW people are asked to build linked lists, reversing tree structures etc, I would assume these questions for EEs, CSEEs would be asked too. I know I've asked similar things in the past.
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.
Why? I shouldn't have to look in multiple places to see what the FSM "code" is doing, and the tools don't care.
http://www.sunburst-design.com/papers/CummingsSNUG2003SJ_Sys...
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/
Ivan Sutherlands Verilog HDL reference guide has been extremely useful for many, many years:
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.
Considering the practice problems were hosted on Arxiv, this was exactly what I expected. What did you expect?