Chapter 17

Behavioral Modeling in using HDLs

Abstract

This chapter introduces the concept of behavioral modeling. There is a real need to abstract to a higher level in many designs to make the overall system level design easier. There is less need to worry about details of implementation at the system level if the design can be expressed behaviorally, especially if the synthesis method can handle any clock, partitioning or implementation issues automatically. Using system level, or behavioral, analysis, decisions can be made early in the design process so that potentially costly mistakes can be avoided. Preliminary area and power estimates can be made and key performance specifications and architectural decisions can be made using this approach, without requiring to have detailed designs for every block.

Keywords

Model Abstraction

High Level Modeling

17.1 Introduction

There is a real need to abstract to a higher level in many designs to make the overall system level design easier. There is less need to worry about details of implementation at the system level if the design can be expressed behaviorally, especially if the synthesis method can handle any clock, partitioning, or implementation issues automatically.

Furthermore, by using system level, or behavioral, analysis, decisions can be made early in the design process so that potentially costly mistakes can be avoided. Preliminary area and power estimates can be made and key performance specifications and architectural decisions can be made using this approach, without requiring to have detailed designs for every block.

17.2 How to Go from RTL to Behavioral HDL Descriptions

The abstraction from an RTL (Register Transfer Level) hardware description language (HDL) to behavioral is straightforward in one sense, in that the resulting HDL (whether Verilog or VHDL) is actually simpler. There is no need to ensure that correct clocking takes place, or that separate processes are implemented for different areas of the architecture, or even separate components instantiated.

It is useful to consider an example to illustrate this point by looking at the difference between the RTL and behavioral HDL in an example such as a cross product multiplier. In this case we will demonstrate the RTL method and then show how to abstract to a behavioral model. First, consider the specification for the model in Figure 17.1, which has the data path model as shown in Figure 17.2.

f17-01-9780080971292
Figure 17.1 Cross product multiplier specification.
f17-02-9780080971292
Figure 17.2 Cross product multiplier data path model.

17.3 Implementing the Behavioral Model using VHDL

The first task is to define the types for the VHDL for the entity of the model and this is shown in the following code. Notice that we have defined a new type, sig8, that is a signed type and a vector based on this for the cross product multiplications.

1 library ieee;

2 use ieee.std_logic_1164.all;

3 use ieee.numeric_std.all;

4 package cross_product_types is

5 subtype sig8 is signed (7 downto 0);

6 type sig8_vector is array

7 (natural range <>) of sig8;

8 end package;

The entity can now be put together and is shown as follows. Notice that for RTL we require both a clock and a reset.

1 library ieee;

2 use ieee.std_logic_1164.all;

3 use ieee.numeric_std.all;

4 use work.cross_product_types.all;

5

6 entity cross_product is

7 port (

8 a , b : in sig8_vector (0 to 7);

9 clk, reset : in bit;

10 result : out signed (15 downto 0)

11 );

12 end entity cross_product;

The basic architecture can be set up with the basic internal signals defined, and the processes will be explained separately.

1 architecture rtl of cross_product is

2 signal I : unsigned (2 downto 0);

3 signal ai , bi : sig8;

4 signal product , add_in , sum , accumulator : signed (15 downto 0);

5 begin

6 control : process (clk)

7 begin

8 if clkevent and clk = 1 then

9 if reset = 1 then

10 i <= (others => 0);

11 else

12 i <= i + 1;

13 end if;

14 end if;

15 end process;

16 a_mux : ai <= a(i);

17 b_mux <= bi <= b(i);

18 multiply : product <= ai * bi;

19 z_mux : add_in <= X 000 when i = 0 else accumulator;

20

21 accumulate : process (clk)

22 begin

23 if clkevent and clk = 1 then

24 accumulator <= sum;

25 end if;

26 end process;

27

28 output : result <= accumulator;

29 end;

Notice that there are two processes, one for the accumulation and the other to handle the multiplication. One important aspect is that it is not immediately obvious what is going on. Even in this simple model it is difficult to extract the key behavior of the state machine. In a complex controller it verges on the impossible unless the structure is well known and understood, which is an important lesson when using any kind of synthesis tool using VHDL or Verilog at any level.

Now reconsider using behavioral VHDL instead. The model uses the same packages and libraries as the RTL model; however, notice that there is no need for an explicit clock or reset.

1 library ieee;

2 use ieee.std_logic_1164.all;

3 use ieee.numeric_std.all;

4 use work.cross_product_types.all;

5

6 entity cross_product is

7 port(

8 a,b : in sig8_vector (0 to 7);

9 result : out signed (15 downto 0)

10 );

11 end entity cross_product;

In this model, the architecture becomes much simpler and can be modeled in a much more direct way than the RTL approach.

1 architecture behav of cross_product is

2 begin

3

4 process

5 variable sum : signed (15 downto 0);

6 begin

7 sum := to_signed (0,16);

8 for i in 0 to 7 loop

9 sum := sum + a (i) * b (i);

10 end loop;

11 result <= sum;

12 wait for 100 ns;

13 end process;

14

15 end architecture;

Notice that it is much easier to observe the functionality of the model and also the behavior can be debugged more simply than in the RTL model. The design is obvious, the code is readable and the function is easily ascertained. Note that there is no explicit controller; the synthesis mechanism will define the appropriate mechanism. Also notice that the model is defined with a single process. The synthesis mechanism will partition the design depending on the optimization constraints specified.

Note the wait statement. This introduces an implicit clock delay into the system. Obviously this will depend on the clock mechanism used in reality. There is also an implied reset. If an explicit clock is required then use a wait until rising_edge(clk) or similar approach, while retaining the behavioral nature of the model.

17.4 Implementing the Behavioral Model using Verilog

As before, the model (in this case a Verilog module) can now be put together and is shown here. Notice that for RTL we require both a clock and a reset.

1 module cross_product (

2 clk, // clock

3 rst, // reset

4 a, // number a

5 b, // number b,

6 result // result of the product

7 );

8

9 input clk;

10 input rst;

11

12 input signed [7:0] a;

13 input signed [7:0] b;

14

15 output reg [15:0] result;

16

17 reg [2:0] i;

18

19 always @ (posedge clk)

20 begin

21 if (rst = 1) then

22 i = 3 b’000;

23 else

24 i = i + 1;

25 end if

26 accumulator <= sum;

27

28 if (i =0) then

29 addin <= 0;

30 else

31 addin <= accumulator;

32 end if

33 end

34

35 ai <= a [ i ];

36 bi <= b [ i ];

37 multiply <= ai * bi;

38 result <= accumulator ;

39

40 endmodule

Again, even with Verilog which generally has a little simpler syntax than VHDL, in this simple model it is difficult to extract the key behavior of the state machine. In a complex controller it verges on the impossible unless the structure is well known and understood, which is an important lesson when using any kind of synthesis tool using VHDL or Verilog at any level.

Now reconsider using behavioral code instead. The model uses the same packages and libraries as the RTL model; however, notice that there is no need for an explicit clock or reset.

1 module cross_product (

2 a, // number a

3 b, // number b,

4 result // result of the product

5 );

6

7 input clk;

8 input rst;

9

10 input signed [7:0] a;

11 input signed [7:0] b;

12

13 output reg [15:0] result;

14

15 reg [2:0] i;

16

17 always @ (a or b)

18 begin

19 for (i = 0; i < 8; i = i +1) begin

20 begin

21 ai <= a [ i ];

22 bi <= b [ i ];

23 accumulator <= accumulator + ai * bi ;

24 end

25 end

26

27 result <= accumulator ;

28

29 endmodule

Notice that it is much easier to observe the functionality of the model and also the behavior can be debugged more simply than in the RTL model. The design is obvious, the code is readable and the function is easily ascertained. Note that there is no explicit controller, as the synthesis mechanism will define the appropriate mechanism. Also notice that the model is defined with a single module. The synthesis mechanism will partition the design depending on the optimization constraints specified. This is easily parameterized, modified and clear.

17.5 Summary

Behavioral modeling is a useful technique for both initial design ideas and also as the starting point for an RTL design. It is important to remember, however, that quite a lot of behavioral HDL cannot be synthesized and is therefore purely for conceptual design or use in test benches. In order to make this a practically useful design tool, the designer can take advantage of the ability of VHDL to have numerous architectures, or Verilog to have numerous submodules, and, by using the same test bench, validate the RTL against the behavioral model to ensure correctness.

In summary, we can use behavioral modeling early with high impact to:

• Carry out fast functional simulation;

• Make performance criteria/ Design trade-offs;

• Investigate nonlinear effects;

• Look at implementation issues;

• Carry out topology evaluation.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.6.77