Lab #1: Introduction to Design Methodology with FPGAs part 1 (80 pts)

Transcription

1 Nate Pihlstrom, Lab #1: Introduction to Design Methodology with FPGAs part 1 (80 pts) Objective The objective of this lab assignment is to introduce and use a methodology for designing HDL-based FPGAs. A. DESIGN METHODOLOGY - AN INTRODUCTION ASIC chips and FPGAs are designed systematically. Designers follow a "design flow," which specifies the steps that will be taken to design and verify a chip. ASIC design flows involve several steps, from specification and design entry to place-and-route and timing closure of the circuit in silicon. Design flows for FPGA-based circuits are simpler than those for ASICs, because FPGA technology uses a pre-fabricated architecture of characterized and configurable devices, and programmable interconnect. This eliminates the place-and-route step that accompanies cell-based ASIC methodology, and its attendant problems with "timing closure." We will follow the major steps of the FPGA design flow shown in Figure 1. Design Specification (1) Design Partition (2) Design Entry: Verilog Model (3) Block Level Verification (4) Pre-Synthesis Sign-Off (6) Synthesis and Implementation (7) Configuration Bitstream Download (8) Prototype Functional Testing (9) Design Integration and System Verification (5) Final Sign-Off (10) Hardware Prototype Figure 1: Design flow for ECE 4200 FPGA-based designs 1. Design Specification The design flow begins with a written specification for the design. The specification document can be a very elaborate statement of functionality, timing, silicon area, power, testability, fault coverage, and other criteria that govern the design. In our initial lab exercise the specification will consist of a description of the functional characteristics that are to be implemented in a design. 2. Design Partition In today's methodologies for designing ASICs and FPGAs, large circuits are partitioned to form an architecture, i.e., a configuration of functional units communicating through their ports, with each unit described by a behavioral model of its functionality. The process by which a complex design is progressively partitioned into smaller and simpler functional units is called top-down design or hierarchical design. Even though the architecture consists of functional units that are simpler than Page 1 of 8 Lab1 Version 1.5

2 the whole, designers don't form their gate-level implementation directly. Instead, they write so-called behavioral models for each functional unit, which are ultimately and automatically synthesized into a gate-level circuit (structure). High-level synthesis begins with an abstract (algorithmic) behavioral description of a system and seeks an architecture that will implement its functionality. This approach to design is beyond the scope of this lab. 3. Design Entry: Verilog Model Design entry creates a description of the design in an electronic format. Traditionally, a schematic or structural description would describe a design. Hardware description languages, like Verilog, which supports structural and behavioral modeling, describe modern designs. Structural modeling connects primitive gates to create a specified functionality, e.g., an adder, just as parts are connected on a chip or a circuit board. But gate-level models are not necessarily the most convenient or understandable models of a circuit, especially when the design involves more than a few gates. Many modern ASICs have several million gates on a single chip! Also, truth tables become unwieldy when the circuit has several inputs, limiting the utility of user-defined primitives. Architectural partitioning forms a structural model, but the functional units in the architecture have much more complexity than basic combinational logic gates, and are modeled behaviorally. Traditionally, designers have designed at the gate (structural) level, but modern design methodology decomposes and represents a design at a meaningful level of abstraction, and then synthesizes it into gates. Synthesis tools translate and map the HDL description into a physical technology, such as an ASIC standard cell library, or a library of programmable parts, such as field programmable gate arrays (FPGAs). Behavioral modeling is the predominant descriptive style used by industry, enabling the design of massive chips. Behavioral modeling describes the functionality of a design, i.e., what the designed circuit will do, not how to build it in hardware. It specifies the input-output model of a logic circuit and suppresses details about physical, gate-level implementation. Behavioral modeling encourages designers to (1) rapidly create a behavioral prototype of a design (without binding it to hardware detail), (2) verify its functionality, and then (3) use a synthesis tool to optimize and map the design into a selected physical technology. If the model has been written in a synthesis-ready style, the synthesis tool will remove redundant logic, perform tradeoffs between alternative architectures and/or multilevel equivalent circuits, and ultimately achieve a design that is compatible with area or timing constraints. By focusing the designer's attention on the functionality that is to be implemented, rather than on individual logic gates and their interconnections, behavioral modeling provides freedom to explore alternatives to a design before committing it to production. Aside from its importance in synthesis, behavioral modeling provides flexibility to a design project by allowing portions of the design to be modeled at different levels of abstraction and completeness. The Verilog language accommodates mixed levels of abstraction so that portions of the design that are implemented at the gate level (i.e., structurally) can be integrated and simulated concurrently with other portions of the design that are represented by behavioral descriptions. 4. Block Level Verification In general, a design should be partitioned along functional lines into smaller functional units, each having a common clock domain, and each of which is to be verified separately. The verification process is threefold, and includes (1) development of a test plan, (2) development of a test-bench, and (3) execution of the test. i. Test Plan Development Page 2 of 8 Lab 1 Version 1.5

3 A carefully documented test plan is developed to specify what functional features are to be tested and how they are to be tested. For example, the test plan might specify that an exhaustive simulation of its behavior will verify the instruction set of an ALU. Test plans for sequential machines must be more elaborate to ensure a high level of confidence in the design. A test plan identifies the stimulus generators, response monitors, and the "gold" response against which the design will be tested. Your grade, and your company's future, will depend on the care that you take in developing and executing your test plan. ii. Testbench Development The testbench (TB) is a Verilog module in which the device under test (DUT) has been instantiated together with pattern generators that are to be applied to the inputs of the model during simulation. Graphical displays and/or response monitors are part of the TB. The testbench is documented to identify the goals and sequential activity that will be observed during simulation (e.g., "Testing the opcodes") Note: If a design is formed as an architecture of multiple modules, each must be verified separately, beginning with the lowest level of the design hierarchy, then the integrated design must be tested to verify that the modules interact correctly. In this case, the test plan describes the functional features of each module that will be tested and the process by which they will be tested, but it also specifies how the aggregate is to be tested. iii. Test Execution and Model Verification The testbench is exercised according to the test plan, and the response is verified against the original specification for the design, e.g., does the response match that of the prescribed ALU? 5. Design Integration and System Verification After each of the functional sub-units of a partitioned design has been verified to have correct functionality, the architecture must be integrated and verified to have the correct overall functionality. This requires development of a separate testbench whose stimulus generators exercise the input/output functionality of the top-level module, monitor port and bus activity across module boundaries, and observe state activity in any embedded state machines. This step in the design flow is crucial and must be executed thoroughly to ensure that the design that is being signed off for synthesis is correct. A separate test plan for the system is developed at the beginning of this step. 6. Pre-Synthesis Sign-Off A demonstration of full functionality is to be provided by the testbench, and any discrepancies between the functionality of the Verilog behavioral model and the design specification must be resolved. Sign-off occurs after all known functional errors have been eliminated. 7. Synthesis and Implementation After all syntax and functional errors have been eliminated from the design and sign-off has occurred, a synthesis tool is used to create an optimal Boolean description. In general, a synthesis tool removes redundant logic and seeks to reduce the area of the logic needed to implement the functionality and satisfy performance (speed) specifications. 8. Configuration Bitstream Download Xilinx FPGAs are configured by downloading a bitstream from a host PC through a parallel port to a connector on the prototype board, and into an on-chip SRAM. The bitstream stored in the SRAM determines how the chips "configurable logic blocks" (CLBs), input/output blocks (IOBs) and Page 3 of 8 Lab 1 Version 1.5

4 interconnect will be configured. The contents of the on-chip SRAM are volatile, i.e., the chip must be powered at all times. It is crucial that the correct part be specified, and that the pins be mapped correctly to the I/O of the model. (Note: The programming switch (SW9) on the Digilab board must be in the PROG position while downloading. If the parallel port is to be used as a functional port, switch SW9 must be moved to the "PORT" position after downloading the bitstream). 9. Prototype Functional Testing Once the bitstream has been downloaded successfully (indicated by LED9 on the prototype board), the part may be exercised to verify that the prototype works as intended. Figure 2 shows a framework for post-synthesis verification of a design. This step compares the response of the gatelevel hardware realization to the response of the behavioral model. This can be done by a testbench that instantiates both models, and drives them with a common stimulus. The responses can be monitored by software and/or by visual/graphical means. Post-synthesis verification in an FPGA design flow can reveal software race conditions in the behavioral model that cause timing to occur in a different clock cycle than expected1. Careful modeling can prevent this outcome. Our postsynthesis verification will be based on a prototype board-level demonstration of the design. Verilog Model Logic Synthesis Gate Level Description Stimulus Generation Test-Bench for System Verification Response Comparator Pass/Fail Figure 2: Post-synthesis functional verification 10. Final sign-off Final sign-off occurs after the lab instructor has witnessed a working design. Congratulations! Schedule a meeting with your venture capitalist. Following the methodology presented in our lab exercises will prepare you to follow a methodology as part of a design team in industry. This methodology might seem cumbersome, but experience has shown that it works better than chaos. We don't get "to do our own thing" if we want the silicon to work. Systematic methodologies reduce the Page 4 of 8 Lab 1 Version 1.5

5 risk of error and increase the likelihood of success. The methodology is not fool-proof, but neither is a free-wheeling alternative, which is more likely to be very costly in the long run. B. DESIGN OF A SIMPLE SEQUENTIAL MACHINE This objective of this part of the assignment is to start the design of a simple sequential machine as an example to illustrate the steps of the design flow. The machine, ALU_machine_4_bit, will be designed and implemented on the Digilent board. The machine's block diagram is in Figure 3 and the top-level I/O is in Table 1. 3 Opcode Alu_machine_4_bit Data 4 Data_A Opcode Alu_4_bit Alu_out 5 Alu_out Data_B 4 4 Reg_out[3:0] Register D Q D Q D Q D Q clk reset Go Control clk load reset Led_wait Go Led_rdy Led_idle Led_wait Led_rdy Led_idle Figure 3: Architecture for ALU_machine_4_bit Name Direction Width Purpose clk input 50MHz clock (20ns period) reset input Asynchronous active high reset Page 5 of 8 Lab 1 Version 1.5

6 Opcode input [2:0] The opcode Data input [3:0] Input data 2 s complement Go input Load Data into register Alu_out output [4:0] ALU output 2 s complement Led_idle output Machine is in reset state Led_wait output Register is loading Led_rdy output Ready for new op-code or data Table 1: I/O ports for ALU_machine_4_bit 1. ALU_machine_4_bit Design Specification: The machine is to operate as follows: Led_idle will indicate that the machine is in its "reset" state. When Go is asserted the internal register is to be loaded with the content of Data[3:0] and is to assert Led_wait until Go is de-asserted. After Go is de-asserted, Led_rdy is to assert. While Led_rdy is asserted the slide switches may be used to set an opcode and/or a new value for Data[3:0]. As the slide switches and/or Data are changed, the effect should be apparent at Alu_out. The cycle is to repeat if Go is re-asserted while Led_rdy is asserted, i.e., the storage register is to be re-loaded. The machine is to be synchronized by the rising edge of a clock, and have an asynchronous active-high reset. Additional specifications will be given below. 2. ALU_machine_4_bit Design Partition We begin with the architectural partition of ALU_machine_4_bit shown in Figure 3. The architecture has three functional sub-units: an ALU, a storage register, and a state machine controller. The ALU implements an instruction set (described below), and the controller directs the operations of the machine. One input datapath of ALU_machine_4_bit is connected to the internal storage register and the other is connected to one data port of the ALU. The output of the register is connected to the other data port of the ALU. The datapath is to be controlled by Control, a state machine that will be described below. The manual slide switches on the prototyping board will control the opcode and the input datapath of ALU_machine_4_bit. Board LEDs will indicate the internal status of the system (i.e. Led_idle, Led_wait, and Led_ready) and are derived from the state within Control. Our design of ALU_machine_4_bit will be progressive. The ALU, ALU_4_bit will be designed and separately verified in this lab. The state machine controller, Control, and Register will be designed in Lab #3, along with a programmable clock generator. In Lab #4 we will integrate the individually verified functional units, verify that the integrated design has the correct functionality, and achieve final pre-synthesis sign-off. In Lab #6 we will synthesize the design into a working prototype on the Digilab board. Do not attempt design integration yet. Proceed to Step 6 (Pre-Synthesis Sign-Off) for each individual unit discussed below. We will execute Step 5 of the design flow (Design Integration and Verification) in Lab #4. 3. ALU_4_bit Design Entry: Verilog Model In this step block ALU_4_bit will be designed in Verilog to implement the operations enumerated in Table 2. Opcode Meaning ALU Operation 000 Add Data_A + Data_B 001 Sub Data_A Data_B 010 Not_A ~Data_A Page 6 of 8 Lab 1 Version 1.5

7 011 Not_B ~Data_B 100 A_and_B Data_A & Data_B 101 A_or_B Data_A Data_B 110 ReductionOR_A Data_A 111 ReductionAND_B &Data_B Table 2: ALU_4_bit Opcodes Note that the output of ALU_4_bit, Alu_out, is a 5-bit word in 2 s complement and the inputs of ALU_4_bit, Data_B and Data_A, are 4-bit words in 2 s complement. You will need to keep track of the sign bit yourself or use the Verilog signed construct. 4. ALU_4_bit - Block Level Verification In this step a test plan for ALU_4_bit will be written, the test-bench will be designed, and the test plan will be executed. i. Test Plan Development Write a test plan that specifies the functional features that are to be tested and how they will be tested. You must verify your design for a suitable number of patterns that cover the data and opcodes of the ALU. As an example, complete Table 3 for patterns that you choose. Include at least these patterns in your test-bench, along with others that you choose. Be sure to pick a mixture of negative and positive values as well as 0 for Data_A and Data_B. Data_A 0100 Data_B 1000 Opcode Alu_out Alu_out Alu_out Alu_out Alu_out Alu_out Alu_out Add Sub Not_A Not_B A_and_B A_or_B ReductionOR_A ReductionAND_B Table 3: Test cases for ALU_4_bit ii. Testbench Development Using the test plan, write a test-bench that verifies the functionality of ALU_4_bit. To make the test-bench self checking, use the data in Table 3 to predict the expected result and flag an error if they do not. Do not simply replicate ALU_4_bit in your test-bench but rather use Table 3 as the expected results and code these expected results into your testbench. iii. Test Execution and Model Verification Using the test-bench developed in ii. Testbench Development, implement the test plan written in i. Test Plan Development. Deliverables 1. Source code of ALU_4_bit 2. Source code of the test-bench. 3. Test plan for ALU_4_bit including Table 3 Page 7 of 8 Lab 1 Version 1.5

8 4. Demonstration of the operation of the test-bench to the lab instructor using any simulator Grading 1. Demonstrations: a. Correct operation of the ALU_4_bit model - 20 pts b. Demonstration of test-bench 20 pts 2. Final Report a. Completeness of test-plan 20 pts b. Final report 20pts Page 8 of 8 Lab 1 Version 1.5