Design and Debug with SystemVerilog

1
Design and Debug with SystemVerilog

• Michael Zuckerman
• HUJI, 2005

2
Agenda

• What is SystemVerilog
• C constructs
• Intent vs. Result
• Interfaces
• OOP

3
What is SystemVerilog

• Newest revision of Verilog
• Addresses designers wishes for enhancements
• Contains Verilog specific enhancements,
  constructs from C, Object - Oriented software,
  assertions and more

4
C Constructs

• typedef, enum, struct
• More convenient - adds readability to the design
• The debugger can have a view of all the types in
  the design

5
C constructs (2)

• typedef logic 70 ubyte
• typedef struct
• ubyte src
• ubyte dst
• ubyte 30 data
• packet_t
• task write_word(ubyte src, dst, ubyte 30 data)
• begin write_word_scope
• packet_t this_packet
• this_packet src, dst, data
• end
• endtask

6
Designers Intent vs. the Actual Result

• Always blocks in Verilog used to model
• Combinatorial logic
• Latches
• Sequential logic (like dffs)
• testbenches

7
Combinatorial logic

• A mux
• always _at_(i1 or i2 or select)
• if(select)
• out i1
• else
• out i2

8
What are the potential issues with this code ?

• always _at_(i1 or i2 or select1)
• if(select1)
• out i1
• else if(select2)
• out i2

9
Always block issues

• Incomplete sensitivity list simulation
  synthesis mismatch
• Simulators will add latch
• Synthesis will ignore the sen. list and put only
  comb. Logic
• Missing else clause implies adding latch
  during synthesis

10
Intent vs. the Result

• How can the tools recognize whether designer
  wanted to write a latch, or whether there is a
  bug in the module ?
• How to solve the simulation-synthesis mismatch ?

11
New always constructs in SystemVerilog

• always_ff to model a flip-flop
• always_comb for comb. Logic
• always_latch to model latch-based logic

12
always_comb

• The mux example with always_comb directive
• always_comb
• if(select)
• out i1
• else
• out i2

13
always_comb (2)

• Here all the tools will report errors
• Always_comb
• if(select1)
• out i1
• else if(select2)
• out i2

14
Intent vs. Result

• In the same manner, there are unique and
  priority key words, which are used with case
  and if-else statements
• Replace the ambiguous full_case and
  parallel_case in case statement

15
Interfaces

• Interfaces group the modules ports together
• May contain declarations of variables, tasks and
  functions
• The declarations are common to all the modules
  using the interface
• Can also contain assertions for proper use, and
  procedures for modeling

16
Interfaces - example

• interface chip_bus(input bit clk)
• bit request, grant, ready
• bit 630 address
• bit 310 data
• // protocol may change here
• endinterface
• module cpu (chip_bus io)
• endmodule
• module ram(chip_bus pins)
• endmodule

17
Interfaces example (cont.)

• module top
• bit clk 0
• // instantiate the interface
• chip_bus a(clk)
• // connect interface to module instance
• ram mem(a)
• // connect interface to module instance
• cpu cpu1(a)
• endmodule

18
Interfaces the benefits

• Provide separation of communication from the
  functionality of the modules
• Reduce duplication of connections between module
  ports
• Enable abstraction refinement
• Convenience for designing
• Easier for reuse
• Can be represented graphically

19
OOP

• Are used for testbenches
• Enable convenient extensions to the system
• Reusability
• Generalizations and additions
• Abstraction, encapsulation, clustering

20
Classes in SysVerilog

• Have data members, methods
• Are accessed via handles (references)
• Generic classes (parameterization)
• Single inheritance with polymorphysm

21
Class usage in SystemVerilog

• class Packet
• rand bit30 cmd
• int status
• myStruct header
• extern task set_cmd(input bit a)
• endclass
• task Packetset_cmd(input bit a)
• cmd a
• endtask

22
Class usage in SystemVerilog (cont.)

• class ErrPkt extends Packet
• bit 30 err
• function bit30 show_err()
• endfunction
• task set_cmd(input bit30 a)
• cmd a 1
• endtask // overrides Packetset_cmd
• endclass

23
OOP - Points for Considering

• Schematic view is only for design
• Testbenches should also be handled
• Waveform should handle transactions instead of
  bit level
• Behavioral view has statements and transitions in
  the RTL level
• Should have views of GFSMs or UML-like views
• Can also have test benches views, i.e constraints