design flow

Complex system and telecommunication chips ranging from 100,000 to 1 million gates are typically developed by multiple teams. Natural language specifications derived from a lengthy source document are a source of ambiguity and confusion, especially when the design teams are scattered around the globe. Using a graphical HDL design entry tool minimizes the errors introduced by passing design information among different teams or members of the same team, because the designers can automatically transfer the information and the verification patterns within a single design environment.

Figure 1	Overall design flow
The overall design flow is the same for standard and graphical HDLs, but the graphical HDL offers better interfaces between levels of abstraction.

Graphical HDL tools can effectively represent both a design specification and its implementation. They can create an environment in which the designer can convert a design from one level into another either manually or automatically. By applying successive refinements to the design, designers can use the tools from the specification level down to the final design (see Figure 1). At each step, even at the specification level, they can simulate the design to ensure that the design matches the original specifications.

Consider the use of a graphical HDL tool (Speedchart from the late Speed Electronic) to create a data processing unit. The example demonstrates how such tools can streamline the design flow by using information from previous steps in the flow, thereby making it easier for various teams working on the design to communicate and ensure that the original specifications are met.

Traditional design flow

In traditional design flows, ASIC design groups receive the specifications on paper in a readable format. The document describes functionality; design requirements, such as timing, power consumption, and gate count; operating conditions; and interfaces. Most of the time, the document provides an architectural breakdown specifying each block separately, along with block interconnectivity information.

The specification document may contain text blocks, tables, flowcharts, state diagrams, and block diagrams. It provides information about signal or data labels, data formats, register definition, and access mode. It describes the operating modes of the system--test mode, normal mode, and the like. For mixed software and hardware systems, the specification document also describes the protocols needed to transmit or access data.

Figure 2	Levels of abstraction
The design moves to lower levels of abstraction--from algorithmic behavioral specification (a), to clocked behavioral specification (b), to design for synthesis unpartitioned (c), and then partitioned (d)--as a function of the resolution and accuracy necessary for that level.

Traditionally, none of the specifications are provided in an executable form. Consequently, the system engineer can't prove that his specifications are complete and correct, and the designer isn't sure that he's interpreting the documents correctly. Thus ECOs can't be avoided, and the resulting designs rarely match the original specification documents.

Start with an algorithmic model

In complex systems, the design should follow a top-down design and verification flow. Good practice begins with an algorithmic model of the system, which is a simulatable specification that doesn't require the implementation of a detailed clocking scheme. For each logic block, designers can write test benches that specify input data streams and expected output data streams corresponding to the algorithmic behavioral specification.

Unfortunately, algorithmic models can't be used to model chip interfaces such as Utopia or PCI, for which clocks, timing, and signals are part of the specifications. Those interfaces require a clocked behavioral specification that models the operation of the core cells. Modeling at the behavioral level confirms the interfaces between blocks of glue logic and core cells. A critical prerequisite for this step is that behavioral models for the design's core cells are available. (The Virtual Socket Interface Alliance is promoting the availability of such models; see the group's Web site at www.vsi.org.) While one engineer is verifying the behavioral models, others start the creation of behavioral models and corresponding test benches for all the new blocks to be designed.

After verifying the behavioral models, the design team creates the RTL models. Power and timing requirements determine the function and granularity of the RTL blocks. An initial design phase, known as "design for synthesis," implements the desired functionality with as high a granularity as possible. The design team can evaluate performance with timing estimators or with the target cell library after completing synthesis. If the required performance isn't attained, the team may have to redesign some of the glue logic blocks or resort to a finer granularity. The performance of the synthesizer will affect the granularity. If synthesis times are too long, it may be necessary to repartition an RTL design, even if the design team can fully synthesize the original code and achieve the desired performance.

Graphical HDL flow

Unlike paper documents, an electronic specification can be refined in successive steps, providing a continuum in the design process. Graphical HDL tools can back up the different steps of the flow and encourage the reuse of data from one step to the other. Reusing the data from previous steps improves the designer's ability to trace specifications and enhances the communication among the various teams. It also allows easier back annotation of design changes.

The design team adopted a graphically based flow in designing a data processing unit. The unit processes flags and counters that are checked and modified on requests issued by a controller.

The team created an algorithmic behavioral specification in the form of a simple block diagram with inputs and outputs (see Figure 2a). Here, a set of input data is assumed available at any time and is processed as soon as the control signals request it. A new set of data becomes available after processing. The way the data is processed depends on its current values and the values of the control data.

Figure 3	Flow diagram
The system engineer derives a list of inputs and outputs from the paper specification and enters them as a template in a graphical tool to create the top-level symbol. Then he attaches a flowchart. The resulting graphical representation implements the behavioral specification.

Design teams commonly use flowcharts to describe behavioral specifications. They can edit the flowcharts using a graphical HDL tool's flowchart editor or generate them automatically from behavioral code and, significantly, simulate and verify them with a test bench. Using the latest software technology, the team can directly embed such flowcharts in the original paper specification as executable specifications.

The clocked behavioral specification represents the same function synchronized with a clock (see Figure 2b). Here, the data is processed in separate time frames, and the operating resources--adders, shifters, multiplexers, and the like--are shared. The clocking scheme determines the design's maximum operating frequency, which corresponds to the critical path of all operations performed during one clock cycle.

State diagrams are an effective way to represent clocked specifications. Advanced state diagram design automatically infers a control section that controls the operations to be performed at different clock cycles and a datapath section that performs the actual operations.

The design for synthesis is derived from the clocked specification. In our example, the data is represented by several 16-bit values that must be calculated (see Figure 2c). Real designs, though, can't afford to have so many buses, so the data is commonly saved in storage arrays (RAMs, FIFOs, register banks) where it can be retrieved, processed, and restored. In this case, the data is stored in a RAM.

In design for synthesis, the designer must follow synthesis guidelines. Advanced graphical design tools can determine if the design matches the synthesis guidelines.

The partitioned design explicitly separates the control and operating sections. We recommend the separation for two major reasons. First, the synthesis tool performs better, because the designer can use dedicated algorithms for each section, and synthesis time is reduced when the synthesis tool handles smaller units. Second, it's possible to share design resources, such as datapath or arithmetic units. In addition, partitioning the behavioral implementation allows the design team to optimize critical parts of the design or use precharacterized macrocells. Separating the control and datapath logic, however, means that the designer must provide instructions that control the operations and data flows of the datapath (see Figure 2d).

Successive refinements

The designer can apply the proposed design flow to any typical controller-based design. The flow is based on successive refinements that stop when the design goals are met. Depending on the complexity of the design unit and the timing, power, and gate count requirements, the designer determines how far to go.

Figure 4	State diagram of the specification
The bubble chart representation gives the designer the ability to keep track of data values and flows without getting consumed in the minutia of HDL code. Transition priorities are shown inside the bubble on the transitions; dotted states are drop-through states used for branching. The diagram is evaluated at each clock cycle.

Finally, in order to ensure that these refinements are error-free, it's necessary to develop in parallel a corresponding test bench to validate each design step (see Figure 1 again). This task is not trivial. The designer must carefully design the test bench to verify only that the implementation conforms to the specification. That means that he must refine the test bench stimuli along with the design process. Typically, he must add clock generation or communication protocols. At the same time, he must extract the relevant responses from the simulation data.

More about the specification steps

Behavioral specification
The system engineer derives a list of inputs and outputs from the paper specification and enters them as a template in a graphical tool to create the top-level symbol. Then he attaches a flowchart to this symbol. The resulting graphical representation implements the behavioral specification (see Figure 3). It's easy to embed the top-level symbol in a test bench and verify it. Compared with textual C or HDL code, such a graphical representation is easier for the system engineer to debug and for the design team to understand.

Clocked specification
It's possible to execute the flowchart described previously as a program. All operations are performed within the same time frame. In this case, the number of hardware operators necessary to implement the specification is equal to the total number of operators described in the flow. However, clocking the flowchart allows the circuit to perform a reduced number of operations during each clock cycle, thereby allowing the synthesis algorithm to share expensive hardware resources. Resource sharing affects the design's critical path and its maximum operating frequency.

State diagrams provide a powerful alternative representation for clocked flowcharts. A state diagram is easy to derive from the flowchart (see Figure 4). The state machine is activated when some control or reset signal is enabled. Each state represents a processing state, in which one or more operations are performed on the data. The next state is selected depending on the value of the control data.

State diagrams

Conditions are attached to the transitions. Prioritizing the transitions enforces the evaluation of the transition. The number attached to a transition indicates its priority and gives the transition's evaluation order: the higher the number, the lower the evaluation priority. In our example, a transition without condition implements the False choice of the if branch. Transition conditions are evaluated at the clock edge. This approach ensures that the designer can synthesize the state machine. When a state is reached, the state machine executes the statements attached to the entry of that particular state.

Figure 5	Control flow
The implementation diagram, evaluated at each clock cycle, produces synthesizable HDL code. Transition priorities are shown inside the bubble on the transitions; dotted states are drop-through states used for branching. It controls the operation flow and generates the memory addresses and control signals for the memory cycle and datapath unit.

Drop-through states implement the equivalent of nested ifs. They're used for branching purposes and don't cost a clock cycle when at least one of the exit conditions is always true. They're also very useful for improving the clarity of a state diagram representation.

Obviously, the state diagram obtained from a one-to-one translation of the flowchart is not the only valid clocked specification. Designers can modify the processing order as long as it doesn't affect the result. States such as pr_data_3_5 show two operations performed in the same clock cycle. To share the operator, it's necessary to include an additional state. For some applications, though, the additional state isn't critical. Instead, the longest path of the state machine gives the maximum number of clock cycles required to ensure the stability of the calculation process.

Figure 6	Memory cycle and datapath unit
When a new state is reached in the diagram in Figure 5, it triggers a memory cycle, shown here.

The states can be highlighted during simulation. The system engineer can perform a coverage analysis to help complete the test patterns and obtain full coverage of the behavioral simulation. At that point, the clocked specification is complete and the design team can begin implementation.

Implementing the specification

To implement the specification, the state machine must undergo more transformations. All the data is stored in and accessed from a RAM. Thus a single RAM data in and data out bus, an address bus, and memory access control signals replace all existing parallel 16-bit input and output buses. All operations are explicitly implemented in a calculation unit, which can later be shared with other blocks of the design. These operations require an additional control signal at the state diagram level, or they can be controlled by using the state vector information.

All the data is first accessed from the RAM, processed, and returned to the RAM. A concurrent state diagram implements this cycle, triggered by activity from the main state diagram (see Figures 5 and 6). To avoid flip-flop inferring, the memory access signals OE and WE are defined in asynchronous action blocks. Support of asynchronous statements and drop-through states is mandatory for state machine design tools.

The various operations that the calculation unit performs can be divided into four categories:

data_out_xx<=data_in_xx+1	-- increment

data_out_xx<=data_in_


	xx+diff(15 downto 0)	-- diff_calc

data_out_xx<=data_in_xx+err	-- err_calc

data_out_xx<=data_in_


	xx+current-old;	-- update

A control signal triggers a specific calculation depending on the current state. The type of calculation is defined for every state, as well as the address of the current data value and the newly calculated data. A third concurrent state machine implements the calculation as a case statement.

To complete the design, we needed to trigger the memory cycle with a synchronization signal as soon as a state is reached. At the end of the cycle, the synchronization signal is reset and the next state transition is enabled.

The HDL code generated from the graphical representation of the original specification is fully synthesizable. We could then simulate the graphical representation with the test bench and verify the result.

After synthesis, the design team must ensure that it's met all timing and area specifications. Synthesis directives and timing constraints can be added at the graphical RT level. Some graphical HDL tools can explore and specify the synthesis process.

The table shows the results that we obtained after synthesizing our design, including the synthesized behavioral specification. The synthesis of the real implementation shows a threefold improvement in gate count compared with the behavioral specification. In our case, the partitioning process did not affect the gate count when compared with the unpartitioned design.

Roger Zinszner was with Speed Electronic SA in Neuchâtel, Switzerland, from its foundation in 1988 until its demise in 1997. His responsibilities included promoting the company's VHDL modeling activities and developing the graphical HDL tool Speedchart. He's now with EM Microlectronic-Marin, in Marin, Switzerland, a low-power semiconductor company, where he's the design support manager.

Juergen Wolf has been with Siemens since 1986. He is currently a product development manager at Siemens Microelectronics, Inc. in San Jose, having recently transferred from Siemens Semiconductor in Munich, Germany. Previously, he worked for 10 years at Siemens Public Network, also in Munich, as an ASIC design engineer and tool expert for hardware acceleration and simulation. He was project manager for two projects involving Speedchart.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  May 1998