Introduction
Hardware design in electronic system level (ESL) is becoming mainstream, but there are still a lot of questions about its generality. Many engineers believe that the abstractions that are at the heart of the ESL design process are not applicable to a large subset of designs, particularly control-dominated designs. The purpose of this article is to show the value that design abstraction offers for control-dominated designs.
Abstraction
Abstraction is a concept that everyone has an intuitive understanding of, but few can cite a formal definition. We can define abstraction in a number of different ways. We can look at abstraction analytically, or we can look at the mechanisms used to implement design abstractions. For the purposes here, we will take the analytic approach following a paper by Thomas Melham1, and cited by Chris Wilson2. We can define four abstraction mechanisms which are useful for verification:
- Structural Abstraction
The more abstract representation describes what the less abstract representation does, not how it does it. In the context of verification, the more abstract representation is a reference model and the less abstract representation is the design under test - for our purposes, RTL. Typically, the more abstract representation has fewer states then the less abstract one.
- Behavioral Abstraction
The more abstract representation describes the outputs of the less abstract design for a subset of the possible inputs. That is, for the abstract model, some of the possible input conditions result in "don't care" output values.
- Data Abstraction
The more abstract representation represents inputs and outputs as compound data types. An example is treating a bit vector as a signed integer (or a fixed-point or floating-point number).
- Temporal Abstraction
The more abstract representation describes the outputs corresponding to an input sequence, but does not describe the timing of those outputs.
It is relatively easy to see how these abstractions are useful in verification, where an abstract model is used as a reference model for a design under test. These mechanisms can also be useful in the synthesis context. In particular, if we think of an RTL model as being a fully-specified design, and the abstract reference model as the specification, then if the abstractions are well-defined, an automatic process, synthesis, can generate the RTL model from the specification. Synthesis, of course, is a one-to-many mapping of higher-level code to lower-level code. As long as the generated RTL design satisfies the design constraints, it does not matter which of the many possible RTL designs is produced. The quality of the RTL code may be judged by a number of different metrics (area, power, layout congestion, etc.), which may or may not be the subject of design constraints.
Abstraction and Control-Dominated Designs
A common definition of a "control-dominated" design is one which is realized by interacting finite state machines3. An equivalent definition is a design composed of communicating concurrent processes. The key feature of such a design is the communication mechanism, or protocol. As a practical matter, a control-dominated design is one dominated by its communication protocol with one or more processes (either internal or external).
At first glance, the abstraction mechanisms described don't seem to be too applicable to this kind of design.
- Structural Abstraction
The abstract description must explicitly describe the communication protocol, usually defined in terms of a timing diagram (or equivalent). Thus, there needs to be explicit specification of when one process must wait for a signal from another process. This usually corresponds directly to states in a state machine. Other states, however, may be abstracted as the implementation may have more states than those explicitly required by the communication protocol.
- Behavioral Abstraction
Communication protocol specifications are usually reasonably complete, so there is not a lot of opportunity to abstract away behavior. There is often some, however.
- Data Abstraction
There is not a lot of opportunity here, as communication protocols simply move bit vectors from one process to another. How they are interpreted is usually unimportant.
- Temporal Abstraction
There is some opportunity for temporal abstraction when describing communicating processes. The communication protocol specifies when control signals have to have valid values but most protocols have variable parts where the timing of the description may be less precise than the timing of the implementation.
An Example of a Control-dominated Design
Access to a memory uses a relatively simple protocol, where an address is put on an input port and the data is read on the data port the following cycle. A write is done by putting the data to be written on the data port along with the address and a write-enable signal on input ports. While simple, access to a memory using such a protocol requires two interacting finite state machines (FSMs), one in the accessor and one in the memory.
The example below shows code for the ACALL instruction for an 8051 micro-controller in both RTL and higher-level code4 The RTL code is written in VHDL, and has a case for each state of the execution FSM. All of the protocol steps for reading and writing memory are explicitly written out, as well as a similar protocol for adding one to the stack pointer (sp).
RTL Description of ACALL instruction
-- sp <- sp + 1
-- mem(sp) <- pc(7-0)
-- sp <- sp + 1
-- mem(sp) <- pc(15-8)
-- pc(10-0) <- reg_op1(7-5),reg_op2
--
when OPC_ACALL =>
case exe_state is
when ES_0 =>
START_RD_RAM(R_SP);
exe_state <= ES_1;
when ES_1 =>
exe_state <= ES_2;
when ES_2 =>
alu_op_code <= ALU_OPC_ADD;
alu_src_1 <= ram_in_data;
alu_src_2 <= C0_8;
alu_src_cy <= '1';
exe_state <= ES_3;
when ES_3 =>
GET_PC_L(pcl);
alu_op_code <= ALU_OPC_ADD;
alu_src_1 <= alu_des_1;
alu_src_2 <= C0_8;
alu_src_cy <= '1';
ram_out_data <= pcl;
START_WR_RAM(alu_des_1);
exe_state <= ES_4;
when ES_4 =>
GET_PC_H(pch);
ram_out_data <= pch;
START_WR_RAM(alu_des_1);
exe_state <= ES_5;
when ES_5 =>
ram_out_data <= alu_des_1;
START_WR_RAM(R_SP);
exe_state <= ES_6;
when ES_6 =>
SET_PC_2(reg_op1(7 downto 5),
reg_op2);
exe_state <= ES_7;
when ES_7 =>
SHUT_DOWN_ALU;
cpu_state <= CS_1;
exe_state <= ES_0;
end case;
SystemC description of ACALL instruction
// sp <- sp + 1
// mem(sp) <- pc(7-0)
// sp <- sp + 1
// mem(sp) <- pc(15-8)
// pc(10-0) <- reg_op1(7-5),reg_op2
//
case OPC_ACALL:
{
sfr_sp = iram[sp];
iram[++sfr_sp] = reg_pc(7,0);
iram[++sfr_sp] = reg_pc(15,8);
reg_pc = (reg_op1(7,5),
reg_op2);
break;
}
The higher-level code is written in SystemC, but the key abstraction is hidden by the memory reference "iram[++sp]." Because SystemC provides the capability to define a class "iram" that has its own "[]" operator, the memory reference "iram[]" can be interpreted according to the memory access protocol. Thus, a synthesis program can produce exactly equivalent RTL code from the higher-level code. The other abstraction in this code fragment is the use of the ++ operator to cause addition by one. Again, the "++sfr_sp" expression can be translated exactly into the RTL code, invoking a separate ALU module to do the increment.
What does this example demonstrate about abstraction? The HL code does not represent the FSM states explicitly, but it does specify the memory access protocol in the iram class definition. Evaluating this example according to our abstraction categories:
- Structural Abstraction
There is clearly structural abstraction here. The protocol state transitions are explicitly described, but other states are not. That is, the description completely specifies the states required by the memory protocol "" additional states could be created if there was any advantage to doing so. This can be seen by the use of the "++" operator. In the RTL code, the increment operator is implemented by communication (using a protocol) with an ALU. In the HDL code, the same structure could be described, or, alternatively, an incrementer might be used inline, resulting in fewer cycles in the overall FSM.M
- Behavioral Abstraction
This code does not illustrate behavioral abstraction. Inputs and outputs are equivalent in the two descriptions.
- Data Abstraction
This code illustrates data abstraction only in the sense that the ++ operator has been introduced. However, in the RTL code, the ALU does treat the sp data as an integer, so we might conclude that the level of data abstraction is the same.
- Temporal Abstraction
This code is more temporally abstract than the RTL, in the sense that the FSM schedule is not specified.
Conclusion
The common perception that high-level coding is not useful for control-dominated designs is not true. While the gain in abstraction level is not as great as it is for data-dominated designs, it is still meaningful, resulting in a reduced amount of code for equivalent function. It is well-accepted that less code results in fewer bugs, and it is generally true that high-level synthesis programs can optimize the resulting RTL as well as or better than humans can when writing interacting FSMs.
References:
1. Thomas Melham, Abstraction Mechanisms for Hardware Verification, University of Cambridge Computer Laboratory, Cambridge, England.
2. http://bugsareeasy.wordpress.com/2009/01/03/abstraction-101-making-sense-of-complex-systems/
3. Fummi, Rovati, Sciuto, Functional Design for Testability of Control-Dominated Architectures, TODAES, vol.2, no. 2, April 1997
4. This code fragment is taken from the Dalton project at UC Riverside, written by Tony Givargis, http://www.cs.ucr.edu/~dalton/i8051
About the Author:
Dr. Sanguinetti is CTO of Forte Design Systems. He has been active in computer architecture, performance analysis and design verification for 20 years. He founded Chronologic Simulation and was the principal architect of VCS, the Verilog Compiled Simulator, and was a major contributor to the resurgence in the use of Verilog in the design community. Dr. Sanguinetti's Ph.D. is in Computer and Communication Sciences from the University of Michigan. He can be reached at John Sanguinetti
|
