Behavioral Hardware Description Languages

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 1’bz (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 ACK==0 REQ=1 REQ=0 ACK==1 ACK==0 ACK==1

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 <= 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;

7. 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;

8. Behavioral vs.. RTL Example (continued) • Behavioral Thinking Process Begin … Req <= ‘1’; Wait until ACK = ‘1’; REQ <= ‘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

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 • Yn=a0xn+a1xn-1+a2xn-2+b1yn-1+b2yn-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 range<>) 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 [11:0] vpi; Reg [15:0] vci; Reg [2:0] pt; Reg clp; Reg [7:0] hec; Reg [7:0] payload [0:47]; 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 < 48; I = I+1) begin Cell.payload[I]=8’hFF; End End End module

25. Data Abstraction in Verilog: Another method for ‘Records’ (continued) • File atm_cell_typ.vh ‘define ATM_CELL_TYP [53*8:1] ‘define VPI [12:1] ‘define VCI [28:13] ‘define PT [31:29] ‘define CLP [32:32] ‘define HEC [39:33] ‘define PAYLD_0 [37:40] … ‘define PAYLD_47 [423:416]

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’ • 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

33. 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

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 = 1’b0; Always #50 clk = ~clk; • Better code: Reg clk; Initial Begin Clk = 1’b0; 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