|
|
|
|
|
|
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
IP Configuration Management with Abstract Parameterizations by Holger Lange, sci-worx GmbH 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 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.:
2.2 Challenges
3 Approach 3.1 Parameters 3.1.1 Classification A parameter is an abstract data type with the following properties:
Table 1: Parameter properties 3.1.2 Recognition
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:
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
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): The number of banks in turn would be (Banks): and so on. A constraint for Data_width and Banks is expressed as (Data_width): {(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)} Another constraint is e.g. that (Size / (Data_width * Banks) must be a power of 2. Resolved to Size that is Valid values for Technology would be expressed as (Technology, Size): 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:
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 Figure 2: Parameter definition template The configuration header looks like this: 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 • Parameter consistency checker • Parameter Editor and GUI for other tools • Hierarchical preprocessor SDA-VPP 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
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
Home | Feedback | Register | Site Map |
|
|
|
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |
