Scaffolding of Project-based Learning of Hardware Design via Test Automation

Rajesh C. PANICKER

Department of Electrical and Computer Engineering,
College of Design and Engineering (CDE)

*rajesh@nus.edu.sg

 

Panicker, R. C. (2023). Scaffolding of project-based learning of hardware design via test automation [Poster presentation]. In Higher Education Campus Conference (HECC) 2023, 7 December, National University of Singapore. https://blog.nus.edu.sg/hecc2023proceedings/scaffolding-of-project-based-learning-of-hardware-design-via-test-automation/
 

SUB-THEME

Others

 

KEYWORDS

Project-based learning, scaffolding, self-checking testbench

 

CATEGORY

Poster Presentations

 

INTRODUCTION

The technological revolution that we are witnessing is enabled by advances in hardware design, and hence designing powerful computing hardware is a popular topic. The course EE4218 “Embedded Hardware System Design” at NUS is designed to provide students with the knowledge and experience in designing a complete system that involves custom hardware and software. However, hardware design is a field with a relatively steep learning curve. Project-based learning (PBL) is a powerful technique frequently employed in engineering courses (Hadim et al, 2002). In EE4218, students learn hardware design and hardware-software co-design concepts through a project that involves developing a system that performs a classification task using a neural network, accelerated using a custom co-processor written in a hardware description language (HDL).

 

CHALLENGES IN PBL OF HARDWARE DESIGN

To ensure the success of PBL, appropriate scaffolding is crucial (Condliffe et al., 2017). This is especially the case with hardware design, where evaluating the functionality of the design after each change can take substantial time and effort. Students incur several tens of minutes, even for minor changes, if they test it directly as a full system. If the result obtained is not as intended, there is no easy mechanism to debug the mistake. This can be a demotivating factor for students, based on the qualitative comments from past student feedback. This is despite providing some scaffolding in the form of a series of four labs, with a wiki (Panicker, 2023) used as a platform for information dissemination and interaction. Though there are no user-friendly tools that exist for full-system simulation (to the best of the author’s knowledge), the co-processor (a component of the system that is the main design challenge) can be tested to a good extent via simulation of the HDL code. While students were required to test the co-processor via simulation in the past, many students did not do so given the complexity of creating an HDL testbench for this purpose. This resulted in them trying directly as a full system, with less than desirable outcomes.

 

SCAFFOLDING VIA TEST AUTOMATION

In order to provide further scaffolding, in a subsequent semester, a sample automated (self-checking) testbench (Bergeron et al, 2012) was provided. This allowed some level of automation in testing their designs in simulation before venturing into full-system testing. Students could use the provided testbench to test a simple skeleton hardware code provided and modify it to test their own hardware in an automated manner. The stimulus (inputs) and the desired response (outputs) can be stored in a text file, which is then used by the testbench to determine the functionality of the HDL code. To ensure that students make use of this self-checking testbench, it was made a mandatory requirement for the first lab itself. Testing via simulation using a testbench also allows students more options for debugging, as opposed to a full-system test. It also provides more instantaneous feedback for the students.

 

RESULTS

The use of the provided self-checking testbench before a full-system test improved the students’ ability to meet the project requirements substantially. The number of students who managed to meet the outcome of implementing a functional system with a HDL-based co-processor increased from 74% (class size: 43) to 89% (class size: 36). The qualitative comments, as well as the module learning outcome survey, also showed improvements, though these could be due to a combination of factors and not necessarily due to the intervention detailed here alone.

 

CONCLUSIONS AND FUTURE WORK

The primary outcome/student achievement from the project improved significantly after the introduction of a self-checking testbench as a scaffold. Hence, we believe the intervention is an improvement, though it does take away the students’ chance to design a testbench from scratch. Future directions include exploring options to do larger-scale, system-level testing through simulation.

 

REFERENCES

Bergeron, J., (2012). Writing testbenches: functional verification of HDL models. Springer Science & Business Media.

Condliffe, B., (2017). Project-based learning: A literature review. Working Paper. MDRC.

Hadim, H. A., & Esche, S. K. (2002, November). Enhancing the engineering curriculum through project-based learning. In 32nd Annual Frontiers in Education (Vol. 2, pp. F3F-F3F). IEEE.

Panicker, R. C., (2023). EE4218 Labs. https://wiki.nus.edu.sg/display/ee4218

 

Viewing Message: 1 of 1.
Warning

Blog.nus accounts will move to SSO login, tentatively before the start of AY24/25 Sem 2. Once implemented, only current NUS staff and students will be able to log in to Blog.nus. Public blogs remain readable to non-logged in users. (More information.)