IP Configuration Management with Abstract Parameterizations

by Holger Lange, sci-worx GmbH
& Martin Radetzki, sci-worx GmbH
Hannover Germany

Abstract. This work presents the Configuration Manager for Abstract Parameterizations (CoMAP), an extensible tool set which is independent of hardware description or programming languages and proprietary software. It extracts parameters from and (re)inserts their values into several kinds of file formats and converts them into a language-independent, user legible notation. The designer may provide as part of this notation additional parameter interdependencies which are expressed as relations and automatically checked for consistency. The main focus of CoMAP is on VHDL and Verilog based hardware design flows, but its modular design enables the integration of any parameter related language construct. The current demonstrator of CoMAP is being built upon a preprocessor backend which strips all parameters and unused optional code from an instance of a parameterized design. This eliminates problems with current code coverage, synthesis, and cross translation tools. In particular, issues with unused code, weak support for multiple instance generation in Verilog, VHDL generate statements, and different VHDL and Verilog parameterization features are addressed. Although the methods of CoMAP were originally developed for IP configuration and adaptation, they can also be applied to the integration of IP into SoC as well as to building platform based or derivative designs.

1    Introduction
As the productivity gap between the growth of design complexity and the designers' limited abilities to accelerate their work while keeping the required quality level increases, design reuse provides a means to cope with this problem aggravated by the simultaneously growing effort to shorten times to market. The project "Intellectual Property Qualification" (IPQ) [10] at sci-worx deals with IP adaptation which is a key issue in design reuse. Sci-worx focuses on customer-specific IP adaptation/modification and parameterizable IP. This paper starts with a state-of-the-art report and subsequently gathers requirements and suggestions concerning configurable/parameterized IP as well as platform based design. Finally the IP/SoC tool set Configuration Manager for Abstract Parameterizations (CoMAP) is presented which assists the designer with the issues detected.

At sci-worx several application specific solutions for parameterization can be found. Two of them serve as examples, the methodologies applied in other projects being similar.

The SDRAM controller (SDC) is configured by setting the values of some VHDL generic statements (RAM timings, bus widths etc.) as well as tying some input signals to a predefined level, thus indicating e.g. size and organization of the attached SDRAM. There are several versions of the entity definition where the generics are kept. The file containing the version needed for a special case (synthesis for a specific RAM type, simulation) is copied onto the work file. Any change common to all file versions has to be carried out for each file.

The Viterbi decoder (FE_VIT) was designed applying almost the same configuration techniques as above. Constants are kept in a global package. There are two versions (high/low throughput) of the package file, one of them is used as the working copy. Any change common to both file versions has to be implemented separately in each version. As a global package is modified, a complete recompile has to be performed every time the configuration is changed. The separation of the two versions is done manually. There is no automatic adaptation of the test bench, therefore every variant has to be verified separately.

There are some recent papers focussing on the topic of hardware parameterization. The most comprehensive work by Wolfgang Thronicke [8] introduces a parameter information model and a parameter flow graph which aims to capture the parameterization process as a whole. Based upon this theory a parameter description format is developed dealing with parameters and their associated properties. The format is implemented in two versions, SYBES (proprietary) and P-XML (a document type definition for XML). A graphical parameter editor is as well supplied as a scheduler for parameterization tasks using the parameter flow graph as input. Schubert, Jährig and Anheier [1] present a parameterized cryptographic library to enable reuse of cryptographic modules in SoC designs. They use VHDL generic, generate and configuration constructs to configure values for some cryptographic features (e.g. block length) as well as interface size and functionality. [2] proposes the exploitation of parameterization capabilities that VHDL provides to overcome the widening design gap, enabling reuse of configurable library modules. A heavily parameterized memory access system for reconfigurable computers including caching and streaming functions is described in [4] and [5]. The parameterization is achieved by using Verilog parameters, built-in- and external (VPP, [9]) preprocessor statements. When talking about hardware parameterization, one also has to take into account configurable test benches. An approach for testing configurable processor cores is shown in [3].

Some valuable work has been brought forward in the domain of software configuration management, which faced challenges a couple of years ago quite similar to those the hardware designers encounter nowadays. [6] underlines the importance of parameterization throughout configuration management of (software) product families, -lines and single components. It appears that the importance of configuration management itself increases with product complexity. Both preprocessor statements (#ifdef...) and templates are considered parameterization techniques. An exhaustive source on the subject of software configuration management is [7], applying mathematical approaches such as feature logics and version sets to software (re)engineering.

Although a lot of work has been done, most of the approaches found suffer from a missing general view. Either the solutions are tailored to a specific application, or their methodology is restricted to certain tools or programming/HD languages. A modular parameterization and configuration management tool that can easily be integrated into an evolving design flow and adapted to new EDA tools is still missing.

2    Requirements

Taking into account the state of the art in science as well as at sci-worx some requirements for adaptable IP emerge. They are split into two parts. The first part gives an outline of the desirable features, i.e. what should be covered. The second part describes the efforts needed to achieve these goals.

2.1    Parameterization of IP Modules

Several aspects emerge for the parameterization of IP modules, e.g.:

• Qualitative parameterization, i.e. in/exclusion of code to choose from architectural or functional alternatives
• Quantitative parameterization, i.e. setting values for attributes, e.g. bus widths or pipeline stages
• Description of configurations in different architectures or tools in a single concept
• Consistency check of interdependent parameters
• Platform integration and interface property description

2.2    Challenges

• Methodology for parameterizing the design, reference model, verification environment, constraint
• Parameter recognition, classification and extraction out of different file formats
• Abstract parameter notation (extensible, user readable)
• Description of legal/illegal parameter combinations
• Has to work with Verilog HDL, VHDL and cross-translation
• Configuration via script (user readable) and GUI

3    Approach
Due to the diversity of the tools involved according to the requirements an abstract parameter representation will be described. At first glance, an implementation using XML (see also [8]) seems to be promising as XML is an internet standard and platform independent. But taking into account the demanded user legibility XML is not an optimal choice compared to Modula- or VHDL-style record representations. In the last part of this chapter the central parts of a Configuration Manager for Abstract Parameterizations (CoMAP) are sketched.

3.1    Parameters
There are several definitions for the term "parameter", and at least as many notions of a parameterization. To clarify the meaning for this approach, a practical classification scheme is given in the next section. The mapping of several kinds of parameters (e.g. VHDL generics or constants) to the classification scheme, called parameter recognition, is described in the last part of this chapter.

3.1.1    Classification

A parameter is an abstract data type with the following properties:

Property	Description
Name	Unique key together with Location
Location	•    hierarchical (block) •    physical (filename) if necessary Unique key together with Name
Comment	Description of parameter, correct use, ...
Value	The actual value of the parameter
Type	String (length), Int (MinMax), Float (MinMax), Fix (MinMax), Enumeration, Boolean, ...
Modifiable	May the parameter be modified?
Strippable	Should the parameter be removed on shipping?
Dependent parameters	List of Parameters whose values depend on Value Key: Name, Location (self reference is possible)
Dependency Relation Check	See below
Dependency Relation Check
•    checks whether the value of the dependent parameter is allowable in relation to certain independent parameters and returns a valid range •    two polynomial or special (e.g. log, pow) functions determine an upper resp. lower bound of the valid range (steady interval) for the dependent parameter. These functions must not take ranges as arguments. •    alternatively a set of n-tuples (discrete relation) defines valid combinations of n-1 independent parameters and 1 dependent parameter •    the elements of the tuple may be exact values, ranges (integer interval) or functions a range (integer interval) as constant function input yields a set of valid parameter values. Note that ranges are allowed here in contrast to the bounding functions above.
Inputs	•    Values of independent parameters E Type of independent parameters •    Value of dependent parameter E Type of dependent parameter
Outputs	•    OK / out of range •    Valid range / set (length, MinMax, enumeration)

Table 1: Parameter properties

3.1.2    Recognition
Parameterizable file formats provide many different kinds of parameter constructs. Two categories of parameters are distinguishable. First there are non-hierarchical parameters. They are valid only in the same module, block or section where they are defined and supported by all parameterizable file formats (example: VHDL constant). The second kind is the hierarchical parameter. It is valid in the same section where it is declared and may be defined with a default value in that place, but generally this value is overridden by a definition on a higher hierarchical level (example: VHDL generic/generic map, Verilog parameter/defparam). Most parameterizable file formats feature the notion of hierarchical parameters.

Figure 1: Hierarchical parameters

These two types of parameters are sufficient to cover the parameterization process of a design, while the restriction to only two classes enables the migration into one notation. The next step is finding representatives for the classes in each file format. The following table maps them for selected formats:

	Hierarchical Parameter	Non-hierarchical Parameter
VHDL	generic/generic map	constant, generic
Verilog	parameter/defparam	parameter, `define
C	-	constant, #define
Specman e	Hierarchical (generation) constraints	Flat (generation) constraints
Constraint file	Placement constraint	Timing-/placement constraint
Synthesis script	_	File positions, option variables

Table 2: Parameter classes in several file formats

For each of these real world parameters a parser extracts their value as well as their data type and determines their relative location in the file format. In case of a hierarchical VHDL or Verilog HDL parameter this location is a position in the design hierarchy tree. The key made of the location data and the name of the parameter is then stored in the abstract parameter notation format along with value and data type.

3.2    An example for dependency relations
The dependency relations introduced by the parameter classification (section 3.1.1) are elaborated in this chapter. Consider a memory system with the following parameters:

• Size: the memory size in bytes
• Banks: number of parallel memory banks
• Addr_width: width of address bus
• Data_width: width of a data word per bank in bytes
• Technology: Name of technology

Assume that technology X may be used for memory sizes up to 64KByte and technology Y for sizes between 32KByte and 128KByte. The dependency relation (in this case a function) for Addr_width is given by

(Addr_width):
{Log(Size / (Data_width * Banks), 2)}

The number of banks in turn would be

(Banks):
{Size / (Data_width * Pow(Addr_width, 2))}

and so on. A constraint for Data_width and Banks is expressed as

(Data_width): {(1), (2), (4)}
(Banks): {(1), (2), (4)}

which is a set of singleton tuples representing valid values not depending on other parameters. As an alternative one could write

(Data_width): {Pow(0..2, 2)}
(Banks): {Pow(0..2, 2)}

Another constraint is e.g. that (Size / (Data_width * Banks) must be a power of 2. Resolved to Size that is

(Size): {Data_width * Banks * Pow(0..1000, 2)}

Valid values for Technology would be expressed as

(Technology, Size):
{("X", 0..65536), ("Y", 32768..131072)}

3.3    Configurations

A file containing the descriptions of several parameters is called a configuration. Preceding the parameter section there is a configuration header encapsulating the following properties:

Property	Description
Name	Name of the configuration
Comment	Description of configuration, purpose, ...
Technology	ASIC, FPGA (type), ...
Area	Gate count (min/typ/max)
Speed	Clock frequency (min/typ/max)
Power consumption	Estimated or real value (min/typ/max)
Company information	Company name, contact, designer

Table 3: Configuration properties

The existing fixed attributes listed above may be replaced by an attribute definition feature for the designer in future versions. The parameter stripper/update tools (see below, chapter 3.5) can work on several configurations "checked out" from one configurable master file set in parallel, e.g. in different directories.

3.4    Abstract Parameter Notation

The Abstract Parameter Notation (APN) is a user-legible, VHDL/Modula record-style representation of the parameter classification (see 3.1.1) and the configuration header (see 3.3). Each definition of a parameter or configuration corresponds to a block. A block is delimited by a line containing the keyword for the type of definition and the same line prefixed by the keyword "end". Keywords followed by a colon ":" signify a statement. Every line may take only one statement, thus making any statement delimiter oblivious. The fields of the definition records may be arranged in an order different from the one shown below.

A parameter definition is represented as follows:

parameter Name of parameter
  location: Hierarchy/filename
  comment
    Comment on purpose
  end comment
  value: Parameter value
  type: Data type
  modifiable: yes|no
  strippable: yes|no
  dependants
    name: name of dep. parameter
    location: loc. of dep. par.
    …
  end dependants
  constraints
    (max: upper boundary function
     min: lower boundary func.) |
     relation
       dependency relation
     end relation
     …
    )
  end constraints
end parameter Name of parameter

Figure 2: Parameter definition template

The configuration header looks like this:

configuration Name of config.
  comment
    Comment on purpose
  end comment
  technology: Target technology
  area: Gate count (min/typ/max)
  speed: Clock freq. (min/typ/max)
  power: Consumption/dissipation
  company: Name of company
  author: Designer/programmer
end configuration Name of config.

Figure 3: Configuration template

3.5    Tools

A few tools are currently developed to work on configurations and source files. They are implemented largely in a string processing environment, preferably Perl. Perl is available on almost all platforms and provides code portability as well as easy integration of graphical user interfaces (Tk), parsers, structured programming and file handling.

• Parameter extractor
Searches source files for free parameters, i.e. parameters not bound to other parameters directly (x := y) or via a function (x := 2^y), and generates the above-mentioned abstract notation. The extractor takes care of generic map, defparam/# or similar statements in other languages and automatically resolves the occurring dependencies. If comments are found they will be extracted as well. Each source file format will be handled by an appropriate backend module. Any new tool can easily be integrated by adding another module.

• Parameter consistency checker
Verifies all constraints and dependencies and reports parameter settings not meeting a specific constraint.

• Parameter Editor and GUI for other tools
Configurations represented in the abstract notation are edited either directly with an ASCII-editor or by means of a graphical Parameter Editor, which supports formatted entry of actual parameter values, properties and dependencies in labeled fields. The GUI also acts as front end, configurator and job flow control for the tools described above.

• Hierarchical preprocessor SDA-VPP
SDA-VPP is a tool built around SDA1 and the Verilog PreProcessor. As it is already in use it is described in greater detail in a separate chapter.

3.6    Hierarchical preprocessor SDA-VPP

In this chapter the SDA-VPP preprocessor is presented. It is applied at sci-worx in order to build an instance of the parameterized design by stripping parameters and replacing them with their constant values. As a main benefit EDA tools (e.g. Synopsys, VNavigator) are not confused by code in/exclusion statements (if...generate, if (parameter == value) then) any more. Moreover, on shipment only the version ordered by the customer will be delivered.

Furthermore SDA-VPP generates multiple instances of a design entity/module. This is achieved by unrolling a for or while loop preprocessor construct. For every loop iteration a hard instantiation is produced, providing a replacement for the VHDL generate statement that especially troubles code coverage analysis. The missing support in the older but still widespread Verilog versions is overcome as well.

The preprocessor kernel VPP (an extension to the original Verilog PreProcessor by J. Ching [9]) is executed by a Perl class that analyzes the output of SDA  in order to generate the instance versions of the parameterized design entities/modules. VPP provides Verilog built-in preprocessor style statements including loops, conditional branching, operators and variables. It also supports hierarchical parameter overriding. Toplevel parameter settings are kept in a separate file. Both the instances and non-parameterized entities/modules are then again passed through SDA to build the final design tree, makefile or compile template for the design instance.

4    Conclusions

The heterogeneous and changing design environment requires an abstract and flexible representation of parameters. A tool for automatic parameter extraction of different file formats is essential to help the designer to build an initial parameter configuration. The GUI-based parameter browser and consistency checker enables a powerful configuration management and may even be used as a module generator. Modularized backends provide for easy upgrading to new design tools while leaving the kernel parts of CoMAP untouched. The hierarchical preprocessor SDA-VPP solves issues with unused code, VHDL generate statements and weak support for multiple instance generation in Verilog.

References

1. A. Schubert, R. Jährig, W. Anheier. Cryptographic Reuse Library, Proc. 2nd Forum on Design Languages, Lyon, 1999
2. J. Wilberg. Supporting Design Reuse by Parameterized VHDL Libraries, IHK Workshop Rechnerunterstützter Systementwurf in Theorie und Praxis, Sankt Augustin, 1996
3. M. Puig-Medina, G. Ezer, P. Konas. Verification of Configurable Processor Cores, Proc. 37th Design Automation Conference, Los Angeles, 2000
4. H. Lange. MARC: Ein parametrisiertes Speicherzugriffssystem für adaptive Rechner, Diploma Thesis, TU Braunschweig, 2001
5. H. Lange, A. Koch. Memory Access Schemes for Configurable Processors, Proc. 10th International Conference on Field Programmable Logic and Applications, Villach, 2000
6. M. Svahnberg, P. Bengtsson. Software Product Lines from Customer to Code, Research Report, Department of Software Engineering and Computer Science, University of Karlskrona/Ronneby, Sweden, 2000
7. A. Zeller. Configuration Management with Version Sets, PhD thesis, TU Braunschweig, 1997 (http://www.infosun.fmi.uni-passau.de/st/papers/zeller-phd/)
8. W. Thronicke. Konzept und Realisierung einer allgemeinen Parametrisierungsstrategie von Systemmodellen unter besonderer Berücksichtigung der Wiederverwendbarkeit, Dissertation, Uni Paderborn, 2000
9. J. Ching. VBPP v1.01 http://www.surefirev.com/vpp/vbpp-1.0.html
10.  IPQ project homepage.