Verilog • Hardware Description Languages • Verilog -- structural: modules, instances -- dataflow: continuous assignment -- sequential behavior: always blocks -- pitfalls -- other useful features 6.111 Fall 2008 1 Lecture 3 Reminder: Lab #1 due tonight!Lab Check-off Policies • Last check-off is at 10:30p on Thursday. Please don’t assume that you can wait until the last minute! • No check-offs on Friday, Saturday • Sunday check-offs are 1 day late, Monday 2 days late, etc. • 20%/day late penalty – On-time check-off: 5 points – Sunday check-off: 4 points – … • All labs must be checked off (even if for 0 points) before you can start your final project. We’ve learned that if you’re struggling with the labs, the final project won’t go very well. 6.111 Fall 2008 2 Lecture 3The Need for HDLs A specification is an engineering contract that lists all the goals for a project: • goals include area, power, throughput, latency, functionality, test coverage, costs (NREs and piece costs), … Helps you figure out when you’re done and how to make engineering tradeoffs. Later on, goals help remind everyone (especially management) what was agreed to at the outset! • top-down design: partition the project into modules with well-defined interfaces so that each module can be worked on by a separate team. Gives the SW types a head start too! (Hardware/software codesign is currently all the rage…) 6.111 Fall 2008 3 Lecture 3The Need for HDLs (cont’d.) A behavioral model serves as an executable functional specification that documents the exact behavior of all the individual modules and their interfaces. Since one can run tests, this model can be refined and finally verified through simulation. We need a way to talk about what hardware should do without actually designing the hardware itself, i.e., we need to separate behavior from implementation. We need a Hardware Description Language If we were then able to synthesize an implementation directly from the behavioral model, we’d be in good shape! 6.111 Fall 2008 4 Lecture 3Using an HDL description So, we have an executable functional specification that • documents exact behavior of all the modules and their interfaces • can be tested & refined until it does what we want An HDL description is the first step in a mostly automated process to build an implementation directly from the behavioral model Logic Synthesis Place & route HDL description Gate netlist CPLD FPGA Stdcell ASIC • HDL→ logic • map to target library (LUTs) • optimize speed, area • create floor plan blocks • place cells in block • route interconnect • optimize (iterate!) Physical design Functional design 6.111 Fall 2008 5 Lecture 3A Tale of Two HDLs VHDL Verilog ADA-like verbose syntax, lots of redundancy (which can be good!) C-like concise syntax Extensible types and simulation engine. Logic representations are not built in and have evolved with time (IEEE-1164). Built-in types and logic representations. Oddly, this led to slightly incompatible simulators from different vendors. Design is composed of entities each of which can have multiple architectures. A configuration chooses what architecture is used for a given instance of an entity. Design is composed of modules. Behavioral, dataflow and structural modeling. Synthesizable subset... Behavioral, dataflow and structural modeling. Synthesizable subset... Harder to learn and use, not technology-specific, DoD mandate Easy to learn and use, fast simulation, good for hardware design 6.111 Fall 2008 6 Lecture 3Verilog data values Since we’re describing hardware, we’ll need to represent the values that can appear on wires. Verilog uses a 4-valued logic: Value Meaning 0 Logic zero, “low” 1 Logic one, “high” Z or ? High impedance (tri-state buses) X Unknown value (simulation) “X” is used by simulators when a wire hasn’t been initialized to a known value or when the predicted value is an illegitimate logic value (e.g., due to contention on a tri-state bus). Verilog also has the notion of “drive strength” but we can safely ignore this feature for our purposes. 6.111 Fall 2008 7 Lecture 3Numeric Constants Constant values can be specified with a specific width and radix: 123 // default: decimal radix, unspecified width ‘d123 // ‘d = decimal radix ‘h7B // ‘h = hex radix ‘o173 // ‘o = octal radix ‘b111_1011 // ‘b = binary radix, “_” are ignored ‘hxx // can include X, Z or ? in non-decimal constants 16’d5 // 16-bit constant ‘b0000_0000_0000_0101 11’h1X? // 11-bit constant ‘b001_XXXX_ZZZZ By default constants are unsigned and will be extended with 0’s on left if need be (if high-order bit is X or Z, the extended bits will be X or Z too). You can specify a signed constant as follows: 8’shFF // 8-bit twos-complement representation of -1 To be absolutely clear in your intent it’s usually best to explicitly specify the width and radix. 6.111 Fall 2008 8 Lecture 3Wires We have to provide declarations* for all our named wires (aka “nets”). We can create buses – indexed collections of wires – by specifying the allowable range of indices in the declaration: wire a,b,z; // three 1-bit wires wire [31:0] memdata; // a 32-bit bus wire [7:0] b1,b2,b3,b4; // four 8-bit buses wire [W-1:0] input; // parameterized bus Note that [0:7] and [7:0] are both legitimate but it pays to develop a convention and stick with it. Common usage is [MSB:LSB] where MSB > LSB; usually LSB is 0. Note that we can use an expression in our index declaration but the expression’s value must be able to be determined at compile time. We can also build unnamed buses via concatenation: {b1,b2,b3,b4} // 32-bit bus, b1 is [31:24], b2 is [23:16], … {4{b1[3:0]},16’h0000} // 32-bit bus, 4 copies of b1[3:0], 16 0’s * Actually by default undeclared identifiers refer to a 1-bit wire, but this means typos get you into trouble. Specify “`default_nettype none” at the top of your source files to avoid this bogus behavior. 6.111 Fall 2008 9 Lecture 3Basic building block: modules // 2-to-1 multiplexer with dual-polarity outputs module mux2(input a,b,sel, output z,zbar); wire selbar,z1,z2; // wires internal to the module // order doesn’t matter – all statements are // executed
View Full Document
Unlocking...