Behavioral Hardware
Description Languages
Behavioral Hardware
Description Languages






Behavioral vs.. RTL Thinking
Gotta have style
Structure of Behavioral Code
Data Abstraction
HDL Parallel Engine
Verilog Portability Issues
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 1’bz (Verilog)
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.
Behavioral vs.. RTL Example
ACK==0
REQ=1
ACK==1
ACK==0
REQ=0
ACK==1
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 <= STATE;
Case STATE is
…
When MAKE_REQ => REQ <= ‘1’;
If ACK = ‘1’ then NEXT_STATE <= RELEASE; End if;
When RELEASE => REQ <= ‘0’;
If ACK = ‘0’ then NEXT_STATE <= …; End if;
…
End case;
End process COMB;
Behavioral vs.. RTL Example
(continued)

RTL Thinking (Continued)
SEQ: process (CLK)
Begin
If CLK’event and CLK = ‘1’ then
If RESET = ‘1’ then
STATE <= ….;
Else
STATE <= NEXT_STATE;
End if;
End if;
End process SEQ;
Behavioral vs.. RTL Example
(continued)

Behavioral Thinking
Process
Begin
…
Req <= ‘1’;
Wait until ACK = ‘1’;
REQ <= ‘0’;
Wait until ACK = ‘0’;
…
End process
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
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.
VHDL vs.. Verilog Structures
VHDL
Verilog
Entity and Architecture Module
Procedure
Task
Function
Function
Package and Package
Body
Module
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.
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
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
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

Yn=a0xn+a1xn-1+a2xn-2+b1yn-1+b2yn-2
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;
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
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.
Data Abstraction in VHDL :
‘Real’

Use a constant array of reals
Type real_array_typ is array(natural range<>) of real;
Constant a: real_array_typ(0 to 2) := (0.5, 1.125987);
…

Can use for-loop to compute equation




Function variable are dynamic


Simple
Efficient
Independent of number of terms in the filter
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
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
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
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
Data Abstraction in Verilog:
‘Records’ (continued)
Module atm_cell_typ;
Reg
Reg
Reg
Reg
Reg
Reg
[11:0] vpi;
[15:0] vci;
[2:0] pt;
clp;
[7:0] hec;
[7:0] payload [0:47];
End module;
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 < 48; I = I+1) begin
Cell.payload[I]=8’hFF;
End
End
End module
Data Abstraction in Verilog:
Another method for ‘Records’
(continued)

File atm_cell_typ.vh
‘define
‘define
‘define
‘define
‘define
‘define
‘define
…
‘define
ATM_CELL_TYP [53*8:1]
VPI [12:1]
VCI [28:13]
PT [31:29]
CLP [32:32]
HEC [39:33]
PAYLD_0 [37:40]
PAYLD_47 [423:416]
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
Data Abstraction: ‘MultiDimensional Arrays’

Useful to represent linear information

Single Dimensional




Fixed length data sequences
Lookup tables
Memories
Multi-dimensional


Planar data (representing graphic data)
Application specific
Data Abstraction: ‘MultiDimensional’ (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
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
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
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;
…
Data Abstraction in Verilog:
‘Lists’




Can’t!
Write the lists using ‘C’ or ‘C++’
Must use a PLI (Programming Language
Interface) to interface the ‘C’ model to
the simulator
PLI’s are simulator dependent, so now
reducing portability
Data Abstraction: ‘Files’

Another way of getting input or capturing
output






Creates complex configuration management
Don’t 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
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.
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
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
HDL Parallel Engine:
Concurrency

2 problems


Describing concurrency
Executing concurrency
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
HDL Parallel Engine: Executing
Concurrency

Executing concurrency

How do you execute concurrently on a
machine that is sequential?



Must emulate parallelism – similar to a multitasking 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
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
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
HDL Parallel Engine: The
Simulation Cycle (continued)
HDL Parallel Engine: The
Simulation Cycle (continued)
HDL Parallel Engine: Parallel
vs.. Sequential


Use sequential descriptions when possible for
behavioral modeling
Misuse of concurrency in Verilog
Reg clk;
Initial clk = 1’b0;
Always #50 clk = ~clk;

Better code:
Reg clk;
Initial
Begin
Clk = 1’b0;
Forever #50 clk = ~clk;
End
HDL Parallel Engine: Parallel
vs.. Sequential (continued)
HDL Parallel Engine: Parallel
vs.. Sequential (continued)
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
HDL Parallel Engine: Driving
vs.. Assigning (continued)
Verilog Portability Issues

Left as an exercise for student to
explore and read about