prof sandip kundu ece 353 lab b (part b – verilog design approach)

Prof Sandip Kundu

ECE 353 Lab B

(Part B – Verilog Design Approach)

ECE353: 2 Computer Systems Lab 1 Moritz, Kundu

Class Information

If you missed the previous class• http://ece353.ecs.umass.edu• Labs B and D• Office hours

• Tu 10-11AM• Or send email for appointment

• Lecture notes and demo video posted online• Check demo schedule and report due date

• Demo signup link is active• Note: I am out of town this coming Tuesday, so no office hours Tuesday

http://ece353.ecs.umass.edu/


Recall What You Will Do

Design and implement a serial MIDI receiver• Hardware in an Altera Complex Programmable Logic Device (CPLD)

MAX 7000S (part number EPM7064SLC44-10)• Using ALTERA Quartus II software tools for synthesis• Debug - functional simulation (wave forms)• Debug of board - logic analyzer

Coding in Verilog Next we look at Verilog design issues


Design in Verilog

Acknowledgements • Builds on an internal course at BlueRISC, 2009 • Papers by Clifford Cummings – SNUG-2000

Please use slides and check links on the web for free Verilog references for refreshing your Verilog skills• Many Verilog books also available for purchase, e.g.,

• S Brown et al, “Fundamentals of Digital Logic with Verilog Design”• J Lee, “Verilog Quickstart”• …


Hardware Design – Outline

How to Approach the Design Phase Implementation with Verilog Requirement for Functional Simulation Summary


Translating Abstract Algorithms to Hardware

Identify hardware functionality in algorithm Divide and conquer

• Break into smaller ‘black-boxes’ when complicated• Think also about performance – what you do in a clock period

Focus on the heart of the problem first Stub-out all (or majority of) modules

• List inputs, outputs• Write comments - how outputs can be generated from inputs


Translating Abstract Algorithm to Hardware (contd.)

Implement one by one• Control-first design is intuitive for ordering your work

• FSMs, state-based outputs, output generation logic• Verification

Instantiate and wire together in top module


Example for Breaking Up (Modules Next slide)

This is an abstract Montgomery Multiplication algorithm.

Here first we try to understand how to partition this into hardware functionality… thinking hardware vs. software


Pieces Identified Implemented in Modules

Courtesy BlueRISC Inc


Stub-out – Start with Heart of the Problem



How to Approach Design Phase Implementation with Verilog Requirements for Functional Simulation Summary


In Which Order – Data vs. Control?

Control first design flow (preferred)- State-machines- State-based outputs- Output generation logic- Verification


In Which Order – Data vs. Control (contd.)

Data first design flow- Output generation logic- State-based outputs- State machines- Verification


Recall Modules

Defines ‘black-box’ piece of hardware

May be instantiated in other modules

Can instantiate other modules


Blocks in Modules

always• Commonly used, synthesizable• Evaluated whenever a signal in sensitivity list changes in simulator• Evaluated regardless of sensitivity list in actual hardware

initial• Commonly used, non-synthesizable• Useful for testbench creation• Setting initial conditions else triggered by external events

forever• Commonly used for generating clocks• forever clk = #5 ~clk;


Combinatorial vs. Sequential Blocks

Combinatorial• Generate signals inside a clock period• E.g., the next version of state_nxt, or signal_nxt (will see example shortly)

Sequential• Latch signal values on clock edges• E.g., signal <= signal_nxt;


Basic Value Manipulations


Mealy vs. Moore State Machines

Mealy - “event driven”- Next-state and Output depend on both current state and input

Moore - “state driven”- Next-state depends on both current state and input- Output depends only on current state


Mealy State Machine


Moore State Machine


Style of Coding – Recommendation

Many considerations like the quality of expected/resulting synthesis but also ease of debugging

A good convention is to separate combinational and sequential blocks entirely• No combinational code in the sequential block!• Sequential block has mainly assignments to latch signals at clock edge or

reset!• E.g.,

• state <= state_nxt• signal <= signal_nxt

• This keeps your code easy to read and debug and avoids subtle flaws


Coding Style: Block diagram, Module, and FSM

Note: if more states, we would call “next” “state_nxt”


More on Variables in Hardware – Adder Example

// sequential part, uses sum_out_nxt// Created in the above block from sum_out// See style followed!

//Continuous assignment


Continuous Assignment

E.g., assign data = …. in previous slide Simplest of the high-level constructs It is like a gate: it drives a value into a wire

• Left hand side is a wire Automatically evaluated when any of the operands change Combinational in nature


Blocking vs. Non-Blocking Statements

First block non-blocking (NB)• a,z updated after 5 time units

Second block blocking (B)• Evaluated in order• Total time 6 units• Value of b toggles 3 times


Coding Guidelines for B vs NB

Use NB in always blocks for sequential logic, e.g.,

Use B in always blocks for combinational logic

Otherwise pre-synthesis simulation might not match with that of synthesized circuit or has poor simulation performance

// Good // Bad


Example - Shift-Register in Verilog

Incorrect implementationalways @(posedge clk) begin

shift_reg[2] = shift_reg[3];



end

* ‘=‘ : Blocking Assignment

* Value in shift_reg[3] will be

assigned to shift_reg[0] directly

Correct implementationalways @(posedge clk) begin

shift_reg[2] <= shift_reg[3];shift_reg[1] <= shift_reg[2];shift_reg[0] <= shift_reg[1];

End

* ‘<=‘ : Non-Blocking Assignment* Updating will happen aftercapturing all right-side register

values



How to Approach the Design Phase Implementation with Verilog Requirements for Functional Simulation Summary


Simulation

Simulation time not real• No gate delays• All evaluations happen same time• Zero time for combinatorial logic• Time is “stopped” when needed• How to simulate accurately re: synthesis results?

REG_DELAY for sequential logic• Register outputs are valid just after the clock edge• Manual delay in simulation is inserted to mimic real world delay• Illusion for passage of “time” in simulation


Sensitivity Lists

Simulation depends on this list• // simulation matches synthesis

• always@(a or b)

out=a&b;• // simulation fails to match synthesis when ‘a’ toggles

• always@(b)

out=a&b; Consider that ‘a’ and ‘b’ are driven by independent logic (say, with different clocks). The flaw in the

second block may give false positive for testing an implemented protocol when ‘a’ switches prior to ‘b’ and prior to evaluation of ‘out’ - likewise this may result in a false negative for otherwise good logic */

Synthesis does not depend on list• Only exception is clock edges

• always@(posedge clk) if(reset)…else…


Verilog Debugging

Testbenches• Verilog code to exercise your logic

Waveforms• Check signals and control-flow visually



How to Approach the Design Phase Implementation with Verilog Requirements for Functional Simulation Summary


Summary – Preferred Coding Style Reviewed

Partition into modules (Lab B may not require multiple) Stub out all inputs and outputs and comment Separate combinational block(s) from sequential block

• FSM is implemented in combinational block• Next state is calculated in combinational block• Output is calculated in combinational block

• Sequential block mainly contains simple latching assignments Make sure you use NB statements in sequential and B in

combinational blocks Use intuitive names (signal, signal_nxt) and follow convention

• Remember this is hardware not software


Additional Information

Please consult course website Also check deliverables for the Lab in the Lab review document

prof sandip kundu ece 353 lab b (part b – verilog design approach)

Documents

kundu design

computer systems lab

kundu hardware design

verilog quickstart slide

verilog design issues

software slide

problem slide

kundu stub