Behavioral%20Hardware%20Description%20Languages

1
Behavioral Hardware Description Languages
2
Behavioral Hardware Description Languages

• Behavioral vs.. RTL Thinking
• Gotta have style
• Structure of Behavioral Code
• Data Abstraction
• HDL Parallel Engine
• Verilog Portability Issues

3
Behavioral vs.. RTL Thinking

• RTL coding has many guidelines.
• Example RTL Guidelines
• To avoid latches, set all outputs of
  combinatorial blocks to default values at the
  beginning of the block
• To avoid internal buses, do not assign regs from
  two separate always blocks
• To avoid tristate buffers, do not assign the
  value Z (VHDL) or 1bz (Verilog)

4
Behavioral vs.. RTL Thinking (continued)

• Subset of VHDL or Verilog for RTL coding has been
  developed based on synthesis tools.
• Structured for hardware structures and logical
  transformations (to match synthesis technology.
• This becomes insufficient when writing
  testbenches.
• If this mindset is kept verification task
  becomes tedious and complicated.

5
Behavioral vs.. RTL Example
ACK0
REQ1
REQ0
ACK1
ACK0
ACK1
6
Behavioral vs.. RTL Example (continued)

• RTL Thinking
• Type STATE_TYP is (, MAKE_REQ, RELEASE, )
• Signal STATE, NEXT_STATE STATE_TYP
• COMB process (STATE, ACK)
• Begin
• NEXT_STATE lt STATE
• Case STATE is
• When MAKE_REQ gt REQ lt 1
• If ACK 1 then NEXT_STATE lt RELEASE End if
• When RELEASE gt REQ lt 0
• If ACK 0 then NEXT_STATE lt End if
• End case
• End process COMB

7
Behavioral vs.. RTL Example (continued)

• RTL Thinking (Continued)
• SEQ process (CLK)
• Begin
• If CLKevent and CLK 1 then
• If RESET 1 then
• STATE lt .
• Else
• STATE lt NEXT_STATE
• End if
• End if
• End process SEQ

8
Behavioral vs.. RTL Example (continued)

• Behavioral Thinking
• Process
• Begin
• Req lt 1
• Wait until ACK 1
• REQ lt 0
• Wait until ACK 0
• End process

9
Gotta Have Style

• Synthesizeable subset puts unnecessary
  constraints.
• With the degrees of freedom in behavioral,
  unmaintainable, fragile, non-portable code is
  easy to achieve.
• Must have discipline Code will have to be
  changed
• Fix functional bugs
• Extend functionality
• Adapt to new design

10
Structure of Behavioral Code

• Structure for maintainability
• Encapsulation hides implementation details
• Structuring is the process of allocating portions
  of the functionality to different modules or
  entities.
• Structure behavior based on functionality or need.

11
VHDL vs.. Verilog Structures
VHDL Verilog
Entity and Architecture Module
Procedure Task
Function Function
Package and Package Body Module
12
Encapsulation Hides Details

• Encapsulation is an application of the
  structuring principle.
• Hides the details and decouples the usage of a
  function from its implementation.
• Simplest technique Keep declarations local.
• Encapsulate useful subprograms.
• Useful functions and procedures that can be used
  across an entire project or multiple projects.
• Encapsulating Bus-Functional Models
• Type of subprogram. Used to apply complex
  waveforms and protocols to a DUV.

13
Data Abstraction

• Need ability to make testbench easier to
  understand
• Use Data Abstraction
• Reals
• Records
• Multi-dimensional arrays
• Lists
• Files
• Interfacing High-Level Data Types

14
Data Abstraction - Reals

• Synthesizeable models limited
• Bits, bit vectors, integers
• Behavioral only has language limitations
• Work at same level as design
• ATM Cell
• SONET Frame
• PCI Action

15
Data Abstraction Real Example

• DSP design (real numbers)
• floating point vs.. fixed point (with bit
  vectors)
• Verifying using fixed point just verifies
  implementation, not intent
• Using floating point is much easier and verifies
  intent
• Example
• Yna0xna1xn-1a2xn-2b1yn-1b2yn-2

16
Data Abstraction in Verilog Real

• Could use define symbols for floating point
• define a0 0.500000
• define a1 1.125987
• Violates data encapsulation principle
• Defines are global, thus polluting name space
• Using parameters is better approach
• Parameter a0 0.5000000, a1 1.125987

17
Data Abstraction in Verilog Real (continued)

• Implement the filter using a function
• Verilog has a limitation
• real numbers
• Can not be passed across interfaces in a function
• Can not be passed in tasks
• Module ports can not accept them
• Use built-in feature realtobits and bitstoreal
  to translate across the interface

18
Data Abstraction in Verilog Real (continued)

• Necessary to take coefficients into DUV
• Use conversion function to take floating point
  into fixed point.
• Using these functions now make testbench easier
  to implement and understand.

19
Data Abstraction in VHDL Real

• Use a constant array of reals
• Type real_array_typ is array(natural rangeltgt) of
  real
• Constant a real_array_typ(0 to 2) (0.5,
  1.125987)
• Can use for-loop to compute equation
• Simple
• Efficient
• Independent of number of terms in the filter
• Function variable are dynamic
• Created every time procedure is called thus
  cannot maintain state of filter as a variable
  local to function
• Can not use globals VHDL function can not have
  side effects, procedures can

20
Data Abstraction Records

• Ideal for representing packets or frames where
  control or signaling information is grouped with
  user information
• Example ATM cell
• 53 byte packet
• 48 bytes are payload
• VHDL nor Verilog support Variant records

21
Data Abstraction in VHDL Records

• Type atm_payload_typ is array(0 to 47) of integer
  range 0 to 255
• Type atm_cell_typ is record
• Vpi integer range 0 to 4095
• Vci integer range 0 to 65535
• Pt bit_vector(2 downto 0)
• Clp bit
• Hec bit_vector(7 downto 0)
• Payload atm_payload_typ
• End record

22
Data Abstraction in Verilog Records

• Verilog does not support records directly
• Can be faked
• Module only contains register declarations
• Each register becomes field in record

23
Data Abstraction in Verilog Records (continued)

• Module atm_cell_typ
• Reg 110 vpi
• Reg 150 vci
• Reg 20 pt
• Reg clp
• Reg 70 hec
• Reg 70 payload 047
• End module

24
Data Abstraction in Verilog Records (continued)

• Module testcase
• Atm_cell_typ cell()
• Initial
• Begin test_procedure
• Integer I
• Cell.vci 0
• For (I 0 I lt 48 I I1) begin
• Cell.payloadI8hFF
• End
• End
• End module

25
Data Abstraction in Verilog Another method for
Records (continued)

• File atm_cell_typ.vh
• define ATM_CELL_TYP 5381
• define VPI 121
• define VCI 2813
• define PT 3129
• define CLP 3232
• define HEC 3933
• define PAYLD_0 3740
• define PAYLD_47 423416

26
Data Abstraction in Verilog Another method for
Records (continued)

• File testcase.v
• include atm_cell_typ.vh
• Reg ATM_CELL_TYP actual_cell
• Reg ATM_CELL_TYP expect_cell
• Initial
• Begin test_procedure
• // Receive the next ATM cell
• Receive_cell(actual_cell)
• If (actual_cell ! expect_cell)
• End
• End module

27
Data Abstraction Multi-Dimensional Arrays

• Useful to represent linear information
• Single Dimensional
• Fixed length data sequences
• Lookup tables
• Memories
• Multi-dimensional
• Planar data (representing graphic data)
• Application specific

28
Data Abstraction Multi-Dimensional (continued)

• VHDL supports multi-dimensional arrays
• Verilog does not naturally
• Must reproduce what a compiler does in creating a
  multi-dimensional arrays
• Map a multi-dimensional array into a single array
• This creates reusability issues
• Must use techniques similar to records

29
Data Abstraction Lists

• Ability to implement dynamic arrays
• Similar to one-dimensional arrays
• Use memory more efficiently than arrays
• Must be access sequentially while arrays can be
  access randomly

30
Data Abstraction Lists (Continued)

• Partially used memory model is called sparse
  array.
• Size of each individual region effects
  performance of simulation
• Smaller size less memory is used but more
  regions are looked up
• Larger size more memory used, improved lookup
• Sparse memories implemented using lists
• List grows as more memory is referenced

31
Data Abstraction in VHDL Lists (Continued)

• Memory regions are records
• Process
• Subtype byte is std_logic_vector(7 downto 0)
• Type region_typ is array(0 to 31) of byte
• Type list_el_typ
• Type list_el_ptr is access list_el_typ
• Type list_el_typ is record
• Base_addr natural
• Region region_typ
• Next_region list_el_ptr
• End record
• Variable head list_el_ptr

32
Data Abstraction in Verilog Lists

• Cant!
• Write the lists using C or C
• Must use a PLI (Programming Language Interface)
  to interface the C model to the simulator
• PLIs are simulator dependent, so now reducing
  portability

33
Data Abstraction Files

• Another way of getting input or capturing output
• Creates complex configuration management
• Dont recommend using them
• If you do, must have good use practiced
  established
• Can be used to help eliminate recompilation
• Can be used to program bus functional models
• Refer to book for some examples for Verilog/VHDL

34
Data Abstraction Interfacing to High-Level Data
Types

• Typically this is not done since the design only
  understands wires
• Use Bus Functional Models where models understand
  the high-level data types and stimulates the
  wires based on certain conditions.

35
HDL Parallel Engine

• 3 necessary components for modeling hardware
• Connectivity ability of describing a design
  using simpler blocks then connecting them
  together
• Time ability to represent how the internal
  state of a design evolves
• Concurrency ability to describe actions that
  occur at the same time, independent of one
  another
• C lacks all three components could create
  them, but time it takes to do this is great. Use
  a language that supports it by default.
• VHDL and Verilog handle them different

36
HDL Parallel Engine

• Time is unit less relative values in Verilog, but
  in VHDL time is absolute
• Connectivity implemented by instantiating modules
  within modules and connecting the pins to wires
  or registers in Verilog, but in VHDL connectivity
  is done by entities, architectures, components,
  and configurations.
• Concurrency one must understand details

37
HDL Parallel Engine Concurrency

• 2 problems
• Describing concurrency
• Executing concurrency

38
HDL Parallel Engine Describing Concurrency

• Describing concurrency
• In VHDL concurrent processes are described
  sequentially
• In Verilog concurrent processes are the always,
  initial blocks, and continuous signal
  assignments. The exact behavior of each instance
  is described sequentially like in VHDL

39
HDL Parallel Engine Executing Concurrency

• Executing concurrency
• How do you execute concurrently on a machine that
  is sequential?
• Must emulate parallelism similar to a
  multi-tasking operating system via time sharing
• One caveat though no restriction on how long a
  process can control the processor. Assumes the
  designer has taken care of that.
• Ensuring that parallel constructs properly
  cooperate in the simulations is crucial

40
HDL Parallel Engine The Simulation Cycle

• For a given time step
• Simulation engine executes each of the parallel
  tasks
• During execution, these tasks may perform
  assignments of future values.
• Once all processes are executed they are all
  waiting for something, zero-delay values are then
  scheduled for the current time step
• Processes that are effected by the new values are
  then re-executed
• This continues until there is nothing left to do
  for the current time step

41
HDL Parallel Engine The Simulation Cycle
(continued)

• When the current time step is done, either
• Process is waiting for specific amount of time
• Future value to be assigned after a non-zero
  delay
• In the above situations, the simulator advances
  time to the next time period where there is
  useful work
• If Neither of the above in which case the
  simulator stops on its own
• The zero-delay cycles within a time step are
  called delta cycles.
• Simulation progresses along 2 axis zero-time and
  simulation time
• VHDL simulators assign new values before
  executing processes, while Verilog does the
  opposite

42
HDL Parallel Engine The Simulation Cycle
(continued)
43
HDL Parallel Engine The Simulation Cycle
(continued)
44
HDL Parallel Engine Parallel vs.. Sequential

• Use sequential descriptions when possible for
  behavioral modeling
• Misuse of concurrency in Verilog
• Reg clk
• Initial clk 1b0
• Always 50 clk clk
• Better code
• Reg clk
• Initial
• Begin
• Clk 1b0
• Forever 50 clk clk
• End

45
HDL Parallel Engine Parallel vs.. Sequential
(continued)
46
HDL Parallel Engine Parallel vs.. Sequential
(continued)
47
HDL Parallel Engine Driving vs.. Assigning

• Driving is used to describe the output on a wire.
  To model properly, a device must be continuously
  driving its value onto that wire.
• VHDL - signal
• Verilog type of wire (wire, wor, wand, trireg)
• Assigning is used to describe the saving of
  something into memory
• VHDL variable
• Verilog - reg

48
HDL Parallel Engine Driving vs.. Assigning
(continued)
49
Verilog Portability Issues

• Left as an exercise for student to explore and
  read about