6 ms·

Practice Problems for Hardware Engineers

exmadscientist 5y ago
Ah yes, because "hardware engineer" means "digital ASIC designer" now, and "practice problem" means "pile of barely edited context-free questions without any explanation".
- vngzs 5y ago
  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?
  - xondono 5y ago
    Call me crazy, but if it’s called “hardware engineering problems”, I expect at least 1 of them to deal with AC..
    - vngzs 5y ago
      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.
    - dvh 5y ago
      I thought it was about designing bridges
- deleted 5y ago
  [deleted]
helsinkiandrew 5y ago
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?
xondono 5y ago
It would be more accurate to call it “Digital Electronics Academic Exercises”
unobatbayar 5y ago
You can read and see "Software Engineer" literally everywhere nowadays; It feels very strange to see "Hardware Engineer" in the title.
NextHendrix 5y ago
Is the link down for anyone else?
- qayxc 5y ago
  I can confirm arxiv.org is down. edit: it's back up now.
tuckerpo 5y ago
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.
- bobbybabylon 5y ago
  Is there are a source, that you know of, with the types of problems actually encountered in industry? Paid or open. Paper or digital.
  - tuckerpo 5y ago
    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.
- JoachimS 5y ago
  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.
JoachimS 5y ago
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
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.)
Farmadupe 5y ago
Gone over sections 16..19 - Several questions are clearly nonsense, eg 17.11) "MISR the BIST out of Z!Xussia" or vague eg 16.4b) "Explain at least 2 different types of data Perl/Python can handle". Question 18.h) "33-Dimensional Maze Router" is more of a strange fever dream than an actual question 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.
- vngzs 5y ago
  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.
- cushychicken 5y ago
  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.

Ah yes, because "hardware engineer" means "digital ASIC designer" now, and "practice problem" means "pile of barely edited context-free questions without any explanation".

vngzs 5y ago
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?
- xondono 5y ago
  Call me crazy, but if it’s called “hardware engineering problems”, I expect at least 1 of them to deal with AC..
  - vngzs 5y ago
    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.
  - dvh 5y ago
    I thought it was about designing bridges
deleted 5y ago
[deleted]

helsinkiandrew 5y ago

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?

xondono 5y ago

It would be more accurate to call it “Digital Electronics Academic Exercises”

unobatbayar 5y ago

You can read and see "Software Engineer" literally everywhere nowadays; It feels very strange to see "Hardware Engineer" in the title.

NextHendrix 5y ago

Is the link down for anyone else?

qayxc 5y ago
I can confirm arxiv.org is down. edit: it's back up now.

tuckerpo 5y ago

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.

bobbybabylon 5y ago
Is there are a source, that you know of, with the types of problems actually encountered in industry? Paid or open. Paper or digital.
- tuckerpo 5y ago
  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.
JoachimS 5y ago
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.

JoachimS 5y ago

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

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.)

Farmadupe 5y ago

Gone over sections 16..19 - Several questions are clearly nonsense, eg 17.11) "MISR the BIST out of Z!Xussia" or vague eg 16.4b) "Explain at least 2 different types of data Perl/Python can handle". Question 18.h) "33-Dimensional Maze Router" is more of a strange fever dream than an actual question 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.

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