Practice Problems for Hardware Engineers(arxiv.org)
arxiv.org
Practice Problems for Hardware Engineers
https://arxiv.org/abs/2110.06526
26 comments
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.
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.
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.
Modern SoC design with buses and switch fabrics - AMBA for example seems not be taught that much.
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.
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.
For context I'm in the safety critical industry where everything is old and slow, and you're slightly more likely to see FPGAs for "traditional" non-signal-processing reasons (bundle of logic with deterministic timing, custom PHY when you can't use a COTS PHY for cert reasons, Heterogeneous backup for an MCU etc). So my own thoughts probably skew a bit old fashioned -- strangely that also means that none of the things that you listed are important in view of the world!
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)
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)
Thanks for the detailed answer! I feel like my college HDL course was better than most given that they did give us exposure to wiring up FSMs together. (Not that I remember any of it.)
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
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
Agreed. The quality is all over the place. "MISR the BIST" sounds like a class in-joke that made its way into the document. But it makes the questions just that much more useless for non-students of this professor.
These are good for undergrad CompE or EE students for practicing before an exam, but irrelevant for industry hardware people.
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.
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.
Is there are a source, that you know of, with the types of problems actually encountered in industry? Paid or open. Paper or digital.
My examples were anecdotal based on hiring practices in my current company doing embedded systems. I don't know of any resources that'd help you gnab a job as an EE. I would say be familiar with the basics, first and second order circuits. Op amp configurations, transistors, edge cases, timing, etc.
Not so sure. There are questions related to pipelining, combinational tree loads, retiming etc. For backend ASIC stuff this is valuable things to know and understand. I would say quite a few of the material are quite far from trivial.
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.
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.
It would be more accurate to call it “Digital Electronics Academic Exercises”
Disagree with the answer to the first question on sizing. Resistive model doesn't seem appropriate for CMOS transition, the MOSFET will spend most of the time in saturation, so you don't need to upsizes gates just because they're in series. (The real answer in a modern process node is that parasitics dominate, and you need to simulate the design with the extracted parasitics from the layout. But I get that it's just an academic exercise.)
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.
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.
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.
Why? I shouldn't have to look in multiple places to see what the FSM "code" is doing, and the tools don't care.
I think Cliff Cummings have really good explanations, motivations for this:
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.
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.
Agree, weird mix of modern and super old-school.
Is the link down for anyone else?
I can confirm arxiv.org is down.
edit: it's back up now.
Why is the download section so small and in the corner of the page on arXiv.org desktop version and not in the main section under the title and preface/intro like on mobile?
You can read and see "Software Engineer" literally everywhere nowadays; It feels very strange to see "Hardware Engineer" in the title.
Ah yes, because "hardware engineer" means "digital ASIC designer" now, and "practice problem" means "pile of barely edited context-free questions without any explanation".
As someone who studied hardware engineering in college, the practice problems cover the core competencies in a degree on electrical/computer engineering. Reading through the practice problems I saw very few subjects that weren't at least touched on in undergrad. The fact that they come with solutions makes this a handy manual for students.
Considering the practice problems were hosted on Arxiv, this was exactly what I expected. What did you expect?
Considering the practice problems were hosted on Arxiv, this was exactly what I expected. What did you expect?
Call me crazy, but if it’s called “hardware engineering problems”, I expect at least 1 of them to deal with AC..
I guess the term is slightly overloaded. At least from my academic background (day job is in more traditional software), AC tends toward the more "electrical engineer" side of the specialization, while IMO these exercises are more "computer engineer" in nature. Not that one won't learn about AC in the inevitable EE classes, but digital electronics tend to be the focus.
I thought it was about designing bridges
[deleted]
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.