eecs 470 lab 3

EECS 470 Lab 3 - SystemVerilog Style GuideDepartment of Electrical Engineering and Computer Science College of Engineering University of Michigan
27th/28th January 2022
(University of Michigan) Lab 3: Style 27th/28th January 2022 1 / 43
Overview
Administrivia
Finite State Machines
Project 2
Administrivia
Administrivia
Homework Homework 2 is due Monday, 7th Febuary at 10:00PM (via
Gradescope)
Projects
Project 2 is due Monday, 31st January at 11:59PM (via submission script)
Help
We are available to answer questions on anything here. Office hours can be found on the course web site.
Easier to debug
Important for group work
Mandatory in projects 1-3
Verilog Style Guide
Verilog Style Rules
We want to approximate this solution
By creating a set of rules to follow
Format We’ll look at a bad example
Then how to fix it
Derive a rule
Verilog Style Guide Brevity
begin
else if (foo[2]) bar = 4'b0100;
end
begin
else if (foo[2]) bar = 4'b0100;
end
end
end
vs.
always_ff @(posedge clock)
end
end
end
end
vs.
always_ff @(posedge clock)
end
end
Brevity Rule
Rule Brevity is strongly correlated with the optimal solution. Be brief, where you can.
Use meaningful names for signal; wire wire; is confusing
Comment your designs; (a ^ b ~^ c) | (&d) is unintelligible without an explanation
Conceptualize what you need to build before you start writing Verilog. A state machine diagram will be make the Verilog much easier. . .
Verilog Style Guide Indentation and Alignment
Indentation
Readability – easier to trace down
Clarity – easier to check what is in a given scope
Indentation by Example
end
end
Indentation by Example
end
end
Indentation Rule
Rule Items within the same scope should have the same indentation.
Alignment
Readability – easier to trace down
Clarity – easier to check that everything is assigned
Alignment by Example
end
end
end
end
(cond3) ? (foo3&~bar2) : 0;
(cond2) ? (foo2 + cnt3) :
(cond3) ? (foo3 & ~bar2) : 0;
(cond3) ? (foo3&~bar2) : 0;
(cond2) ? (foo2 + cnt3) :
(cond3) ? (foo3 & ~bar2) : 0;
Alignment Rule
Rule Assignments should be aligned by column. Ternary statements should have the conditionals aligned, and each “if” should be on a new line.
Verilog Style Guide SystemVerilog Features
SystemVerilog Types
User-defined Types
Types can be named informatively, e.g. arch reg t
Structs
About struct A package of signals (wire or logic) Basically follow C conventions
List of signal declarations Named with t ending
Syntax
struct
List of signals between braces ({}) Name after braces, followed by a semicolon (;)
Structs
logic b; //other structs, like
arch_reg_t c; //<-- this line
} example_t; //named with _t
Example typedef struct packed {
Usage Example prf_entry_t [31:0] prf;
assign prf[1].valid = 1'b0;
Enums
About enum List of possible values, but named instead of numbered
Good for state machine states
Can be shown in DVE instead of the associated value
Syntax
enum
List of values between braces ({}) Name after braces, followed by a semicolon (;)
Enums
IDLE, //=0, by default
RESET //=9
ADD = 2'b00, //The value associated with
MULT = 2'b10, //a particular name can be
NOT = 2'b11, //assigned explicitly.
assign n_state = IDLE;
Enums
DVE Example
Typedef
About typedef
Necessary for reuse of a struct or enum Without a typedef, a struct/enum must be redefined at each
instance declaration
Syntax
typedef
Name for the type followed by a semicolon (;)
Typedef by Example
typedef enum logic [3:0] {
typedef logic [63:0] addr;
Procedural FSM Design
FSM Process All states should be typedef enum
All next state logic should go into a combinational block, following all combinational rules
All resets should be synchronous (to the clock)
All output assignments should go in their own combinational block
The only logic in the sequential block should be the state assignment (to the computed next state)
module fsm(
/* next state = f (inputs, state) */
end
end
end
endmodule
module turnstile(
end
else state <= #1 next_state;
end
endmodule
Coverage
So last time we talked about why to write a testbench
We also talked about how to write a good testbench
All metrics that we talked about are rather qualitative, though
How do we quantitatively measure how good a testbench is - code coverage
Code Coverage Types
Line Coverage — This metric measures statements in your HDL code that have been executed in the simulation
Toggle Coverage — This metric measures the bits of logic that have toggled during simulation. A toggle simply means that a bit changes from 0 to 1 or from 1 to 0. It is one of the oldest metrics of coverage in hardware designs and can be used at both the register transfer level (RTL) and gate level.
Condition Coverage — This metric measures how the variables or sub-expressions in the conditional statements are evaluated during simulation. It can find errors in the conditional statements that cannot be found by other coverage analysis.
Code Coverage Types Cont.
Branch Coverage — This metric measures the coverage of expressions and case statements that affect the control flow (such as if-statement and while-statement) of the HDL. It focuses on the decision points that affect the control flow of the HDL execution.
FSM Coverage — This metric verifies that every legal state of the state machine has been visited and that every transition between states has been covered.
For more information about coverage, feel free to ask us or search online!
-cm line|cond|fsm|tgl|branch|assert
The arguments specifies the types of coverage: line Compile for line or statement coverage. cond Compile for condition coverage. fsm Compile for FSM coverage. tgl Compile for toggle coverage. branch Compile for branch coverage assert Compile for SystemVerilog assertion coverage.
If you want VCS to compile for more than one type of coverage, use the plus (+) character as a delimiter between arguments, for example:
-cm line+cond+fsm+tgl
./simv -cm line+tgl
urg -dir simv.vdb -format text
Note: To use urg, you need to run the following command in the terminal:
module load vcs
you should then see a generated directory named urgReport and within it you’ll find a hierarchy.txt it should have something like:
Coverage example Cont.
88.67 100.00 77.33 mstage[0]
93.19 100.00 86.37 mstage[1]
88.67 100.00 77.33 mstage[2]
84.15 100.00 68.29 mstage[3]
79.63 100.00 59.25 mstage[4]
75.11 100.00 50.21 mstage[5]
70.59 100.00 41.17 mstage[6]
66.07 100.00 32.13 mstage[7]
Coverage Cont.
We will come back to this later in the final project. As part of milestone 1, you will need to submit a module along with a testbench and we will grade you based on your coverage percentage, but that’ll be much later. In the meanwhile... Give it a try on your project 2 testbench!
Project 2
Finite state machine implementation
Synthesis
Project 2
Pipelined Multiplication
Partial Products Multiply the first n bits of the two components
Multiply the next n bits, etc.
Sum the partial products to get the answer
Project 2
× 0 1 0 1
0 0 0 1 1 1 0 0 0 0 0 0 0 1 1 1 0 0
+ 0 0 0 0 0 0
1 0 0 0 1 1
Decimal Multiplication 7
3 5
Project 2
multiplier: 00000111 partial product: 00000000
0 0 0 0 1 0 1 1 × 0 0 0 0 0 0 1 1
0 0 0 0 0 0 0 0
Project 2
multiplier: 00000111 >> 2
partial product: 00100001
0 0 0 0 1 0 1 1 × 0 0 0 0 0 0 1 1
0 0 1 0 0 0 0 1
Project 2
multiplier: 00000001 partial product: 00100001
0 0 1 0 1 1 0 0 × 0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 0
Project 2
multiplier: 00000001 >> 2
partial product: 01001101
0 0 1 0 1 1 0 0 × 0 0 0 0 0 0 0 1
0 0 1 0 1 1 0 0
Project 2
Pipeline Depth
Figure out the sizes of all the structures as a function of pipeline depth
This would be an optimal place to use `define
Synthesis
Clock Periods (Tclk) Optimize inner module (mult stage.v) first, then outer (mult.v) Understand set dont touch
Synthesis is time consuming; ≈ 10 minutes for both mult stage and mult
Project 2
Guess-and-check
Loop from the top bit of the guess to the bottom
Basically binary search for a solution
Hardware Implementation
How do we implement this in hardware?
Project 2
√ value
On a reset guess initialized to 32’h8000 0000 value is clocked into a register
guess gets the next bit set each time we cycle through the FSM again Square guess (multiply it with itself)
Wait until the multiplier raises its done
if guess <= value Keep the current bit
else Clear the current bit
Move to the next bit
After the last bit, raise done
Project 2
64’hFFFF FFFF FFFF FFFF
It must take less than 600 cycles to compute a square root
Remember to use the 8-stage multiplier for this
Remember to check for proper reset behavior
Remember the reset pragma (//synopsys sync set reset
‘‘reset’’)
Project 2
Lab Assignment
Assignment is posted to the course website as Lab 3 Assignment. If you get stuck. . .
Ask a neighbor, quietly Put yourself in the help queue
When you are finished, put yourself on help queue to get checked off.
If you are unable to finish today, the assignment needs to be checked off by next Friday.

eecs 470 lab 3

Documents