Section 11.5 Physical testing
The final step is to physically test the prototype: does the hardware actually work? Does it produce the expected outputs in response to its inputs? In large scale digital designs, creating a testing procedure is a design problem in itself, carried out in parallel with the system design. It is not an afterthought. In this class our designs are quite simple, but it is no less important to think carefully about how to test a design, and then to do the physical testing. No matter how confident you are of your simulations, until you carry out a successful physical test, you do not have a working design.
In order of increasing complexity, here are some of the tools available to you for physical test.
- Voltmeter, for power supply and constant logic levels
- LEDs, for constant and very slowly changing logic levels
- Seven-segment display, for constant and very slowly changing hexadecimal signals
- Toggle switches, for applying constant logic levels.
- Pushbutton switches, for applying momentary logic levels.
- Function generator, for applying high-speed time-varying stimuli, digital and analog
- Terminal emulator, for applying serial text input (see Chapter 18)
- Analog oscilloscope, for observing the detailed shape of a digital signal
- Digital oscilloscope, for observing multiple time-varying logic signals at once.
In addition, you can use previously tested subsystems as input or output devices. As you develop a project, always be thinking about how you can use these tools to test it.
FPGA development boards, like the Basys3, often provide a rich set of ports for input and output. For example, the Basys3 has 16 slide switches, five pushbutton switches, sixteen single LEDs, four seven-segment displays, a VGA video port, and four twelve-pin peripheral module (Pmod) sockets. You can use eight of the twelve pins of any available Pmod socket to bring out signals from your design for observation by an oscilloscope. Just route the signal to an entity port and map it to the Pmod pin through the XDC file.
The philosophy we want you to adopt in this course is “top-down design, bottom-up testing”. By this, we mean that you think carefully about the design, as a whole, and have a solid paper design (block diagram) before writing any VHDL code. Break the design into smaller, testable modules. Write the VHDL for each module in turn, simulating, implementing, and physically testing, module-by-module. It is never a good idea to write a bunch of VHDL for an entire project and hope it will work. There will be bugs, and by building and testing one small module at a time, you will have the bugs confined to a small space where they are easier to find and correct. Moreover, “modular build-and-test” does not mean “modular code and simulate”. Until you carry out a successful physical test, you do not have a working design!
To wrap this chapter up, the following table summarizes the correspondence between the steps of a gate oriented design flow, Section 1.6, and the FPGA design flow.
| Step | Gate level flow | FPGA flow |
Capture |
Logic diagram |
HDL model |
Verification |
Schematic simulator |
Testbench |
Synthesis |
Select ICs |
Infer resources from HDL model |
Translate logic diagram to netlist |
Generate netlist |
|
Implementation |
Place ICs on breadboard |
Select specific FPGA resources |
Route wiring between ICs |
Determine routing paths |
|
Generate bitstream and configure FPGA |
||
Verification |
Physical test | |
