READEE – Decision Support for IP Selection using a ... - CiteSeerX

READEE – Decision Support for IP Selection using a Knowledge-Based Approach Peter Oehler1, Ivo Vollrath1, Peter Conradi2, Ralph Bergmann1, Thomas Wahlmann2

1

Centre for Learning Systems and Applications, Dept. of Computer Science University of Kaiserslautern, PO-Box 3049, 67653 Kaiserslautern

2

Institute for Computer Structures, Dept. of Computer Science University of Siegen, Hölderlinstr. 3, 57068 Siegen

Abstract Our paper describes the fundamentals of an IP selection support tool that can be used over the Internet as well as in intranets of larger companies. Such a tool can be used to support the board and chip design activities of electronic circuit designers by informing about available products as IPs or chips to purchase. Online IP catalogues as they have been emerging lately may contain thousands of IPs but they typically provide only little selection support and little detailed information on the properties of the IPs. This can make it impossible for a designer to evaluate a number of IPs of the same type according to his special purposes. By combining abstract domain knowledge and a similarity-based search approach, the selection assistant we describe is capable of evaluating a database of IPs according to the designer's needs. Due to this assistant's ability to automatically evaluate IPs it can hide confidential information from the user while still offering high quality retrieval results. A first prototype of the system has been presented at DATE'98 and is online at http://wwwagr.informatik.uni-kl.de/~readee/. It covers the special case of DSPs. In our paper we present a framework that extends the concepts of this prototype to a general IP selection support application. We also present concepts for IP modelling, taxonomies, classifications of IP parameters and quality measures for IP characterisation and design space representation.

1 Introduction More and more electronic companies do not hesitate to use IPs (“Intellectual Properties”) from third parties inside their complex electronic systems. An IP is a design object whose major value comes from the skill of its producer (Lewis 1997), and a redesign of it would consume significant time. A designer who wants to reuse designs from the past must have a lot of experience and knowledge about existing designs, in order to be able to find candidates that are suitable for reuse in his specific new situation. More and more IP vendors arise, offering their IPs especially in the internet. Searching in such IP databases can be an extremely time consuming task

because, first, the public domain documentation of IPs is very poor and second there are currently no intelligent tools to support the designer in deciding whether a given IP from a database can be easily adapted to meet the specification of his new application. A simple but typical reuse scenario from the designer's point of view consists of a few main steps: 1. 2. 3. 4. 5. 6.

Make a specification for a new application. Find a catalogue of reusable designs that contains IPs of the new application's domain. In the catalogue, search for the IP that is best reusable for the new application. Obtain (buy) this IP from the IP provider. Try to reuse the IP. Finally, find out whether a good decision was made, i.e. whether a profit was gained by reusing the IP. This article is mainly concerned with steps 3 and 5. There are a number of reasons why intelligent search assistants are needed to support the designer in searching a catalogue of IPs: • IP databases can be very large. Standard search approaches, like keyword search or decision trees, tend to fail to keep the number of matching IPs small. The IPs retrieved have to be individually examined by the designer. This can be very time consuming. • Evaluating the usability of an IP for a specific problem often requires that the user makes himself familiar with many details of the design. Even if the user is an expert in the application domain of the IP, extracting certain information out of a data sheet can be very difficult because the technical data contained therein is partly described on a very low technical level. • Design information on soft core IPs (Oehler et al. to appear), described using a hardware description language, must be protected against plagiarists. Because of this there is not much information available on soft core IPs for a designer before he actually buys them. It is therefore absolutely impossible for him to tell the difference between a number of IPs with similar purposes but different implementations. The Concern of READEE All these arguments make clear that a database of reusable designs requires a search facility that possesses more intelligence and knowledge than currently available systems can provide. In the near future, electronic applications can be expected to grow so complex that their designers cannot be expected to be specialists in the reusable components they are going to employ for their project. So, retrieval assistants capable of providing real selection support (and possibly guidance in configuring the retrieved designs) are highly recommended. The READEE1 project has been initiated to explore and realise new methods to overcome these problems. However, looking at typical IPs described with hardware description languages like VHDL or Verilog HDL, it is obvious that a complete analysis of such designs with respect to a given target application can be extremely complex and calculation intensive. Moreover, a designer who decides to reuse existing hardware components often does not ex1

READEE [´redI]: Reuse Assistant for Designs in Electronic Engineering; funded by the foundation “innovation” (Stiftung Innovation) of Rhineland-Palatinate, Germany; Corporate partners: Centre for Learning Systems and Applications at the University of Kaiserslautern; Engineering office “Dr. Peter Conradi & Partner”; tecInno GmbH, Germany

pect to find an IP that exactly meets his requirements – he just wants to find a design that is easily adaptable or to which he can easily adapt his application framework. The READEE project applies and extends case-based reasoning (CBR), which is a mature software technology for building knowledge-based systems (see Lenz et al. 1998 for a stateof-the-art collection of CBR applications; see also wwwagr.informatik.uni-kl.de/~lsa/CBR/). Unlike traditional knowledge-based approaches, CBR does not solve new problems (e.g. design problems) from scratch, but by reusing solutions to previous problems (called cases) stored in a case base. Within this paradigm, CBR employs a simple but powerful idea: “similar problems have similar solutions”. Therefore, cases appropriate for reuse are selected based on the similarity to the new problem to be solved. However, having a good notion of similarity, i.e., a notion of similarity that approximates reusability, is the key for the successful application of this technology and was also a core challenge for the development of the IP reuse selection approach developed in READEE and presented in this paper. The implementation of the READEE software is performed on top of the commercial CaseBased Reasoning software tool CBR-Works2 but extend this tool in several ways. Several fielded applications using this tool have already been realised, e.g. an online selection tool for operational amplifiers from Analog Devices (Vollrath et al. 1998). After a brief discussion of an existing reuse database section 3 introduces some fundamental concepts of our READEE prototype. Section 4 introduces a more general conception of using CBR techniques for the reuse of IPs. This conception involves an IP taxonomy and distinguishes between three different kinds of IP parameters. To support the adaptation (i.e. determination of parameter values) of IPs to new application designs, we propose an approach that utilises constraint nets to describe the design space of IPs.

2 An Existing Database In July 1997 Design & Reuse (Behnam et al. 1998) launched an online catalogue for IPs. This catalogue was very successful right from the start, which indicates that there is a big demand for reusable designs. The Design & Reuse “yellow pages” basically provide two different search facilities: First, there is a hierarchical IP taxonomy which serves as a selection tree for IPs and families of IPs, and second there is a keyword search that enables a user to search across the boundaries of the taxonomy. There are general points of criticism that apply to these search techniques: Keyword search is only a syntactical search. A search for a “short cycle time”, for example, would fail to find components with a “high clock rate”, which is a more or less equivalent property. In addition to that, more abstract information like “good for high fidelty audio applications” can not be deduced from low-level attributes like “signal-to-noise ratio” and “dynamic range” by a syntactical search. A taxonomy, on the other hand, holds some more information about categories of designs. A drawback of a purely taxonomic search is that there is no information about the relations (exchangeability or equivalence, for example) between two categories on the same hierarchical level. However, such information would be very beneficial to have in a reuse tool. Another problem with selection trees is that the user is forced to make decisions in a predefined order. If, for some reason, she/he cannot (or does not want to) make a decision at some point, she/he is forced to make several inquiries in sequence. Figure 1 illustrates this problem with an ex2

CBRWorks was developed collaboratively by the University of Kaiserslautern and TecInno GmbH and is now marketed as commercial product by TecInno.

Figure 1. Part of a selection tree. ample taken from the Design & Reuse “yellow pages”: A user looking for an 8 bit microcontroller is forced to make a decision (RISC or CISC) he rather would not care about. It is not possible to generally solve this problem by re-organising the tree because there might be another user looking for a RISC microcontroller, so the order of decisions cannot be globally optimised.

3 The READEE Prototype The READEE prototype (introduced at DATE983, see Vollrath and Oehler, 1998; online at http://wwwagr.informatik.uni-kl.de/~readee/) is an example of an intelligent approach towards selection support for reusable components. This first prototype is specialised on digital signal processors (DSPs). A user can specify his requirements of a DSP both on higher and lower levels of abstraction. A typical low-level requirement would be: “supply voltage = 5V”. More abstract specifications could state characteristics of the intended application, for example: “I want to realise a fast fourier transformation (FFT) with up to 512 samples per frame.”. Part of the consultation interface of READee is shown in Fig. 2. This prototype employs the concept of evaluation models as described in (Oehler et al. to appear). These models include knowledge about the key features of the components in the data base. A complex design typically has certain qualities that are difficult to extract – even for experts – from the component's data sheets or from a complex design description. However, an intelligent retrieval assistant must know about those qualities that are important for the selection decision of a human designer. To represent a DSP within the READEE prototype, the computing performance of a processor is characterised by an instruction table as an abstract model instead of lots of details on architectural features. This table contains typical DSP operations like • • • •

3

arithmetic or logic operation, one or no fetch, one store, multiply or addition or subtract, two fetches, one store, MAC (multiply and accumulate) repeat, two fetches, (additional) data transfer,

DATE98: Design, Automation and Test in Europe, Conference in Paris 1998

Figure 2. The user interface of the READEE prototype for DSP selection.

For each family of DSPs (which have the same instruction set) these operations are specified by the number of cycles needed for their execution and the number of words needed for their programming. We have chosen three different performance profiles, where an engineer can specify his intended application. Two of them are the most commonly used signal processing operations, while the third general-purpose one will enable the user to characterise additional arbitrary applications: • Filter (parameters: FIR/IIR, filter degree)

• FFT (parameter: number of samples) • General-purpose (parameters: requested data memory and internal variables, how often typical DSP operations will be executed and how often they occur in the program code) The filter and FFT specifications are specialisations of the general-purpose profile. They are internally mapped to the general-purpose parameters. To get the most suitable DSPs it is preferable to use “high-level” operations for the general-purpose profile. Evaluation models supporting similarity calculations are used for different tasks: • The clock frequency is derived as an integer multiple of the user-specified sample frequency. This integer multiple equals the available number of cycles per sample of a DSP. If the user-specified maximum power consumption is critical, the clock frequency is reduced appropriately. • The user-specified performance profiles are mapped onto the data, code and generalpurpose memories, the general-purpose registers and the available number of cycles per sample of a DSP, respectively. • After the individual ratings of these high level qualities have been assessed by the evaluation models they are combined to an overall similarity value which is a measure for the expected (re-)usability of the DSP with respect to the user's application. More simple requirements, such as “word length”, “pricing category” or “power consumption” are also taken into account by the overall similarity value. The result of a READEE consultation is a list of DSPs sorted by their reusability for the user's specification (see Fig. 2). The user has the option to further refine his specification in case his initial specification was not precise enough to produce a satisfying result. The system also has the ability to explain what makes the proposed DSP suitable for the specification. It also points out certain problematic attribute values that lead to a significant reduction of similarity. Some of the information needed for the calculations described above may not be explicitly found in data sheets. Therefore it has to be provided by a human expert when the case base is put together. This human expert ideally is the designer of the reusable design or IP.

4 Using CBR techniques for the reuse of IPs There are some basic differences in the representation of DSPs and IPs: • A DSP will normally have no variable parameters, whereas a soft core IP is parameterisable (a parameterisable DSP core would be classified as an IP). • There is only one model needed for all general-purpose DSPs (as described in the previous section), instead of one for every class of IPs. An IP with fixed parameters offers just a design point. That means, it can only be used for one specific application. On the other hand, an IP which is parameterisable, e.g. a variable word length, spans a design space. Therefore, parameterisable IPs are more flexible to use and the chances that they will be reused are much better. Soft core IPs are usually written in VHDL or Verilog. The automated analysis of VHDL or Verilog code for the extraction of relevant parameters does not seem to be successful (Lehman et al. 1996). The reason is that it is not trivial to decide what an algorithm or an RTL description is made for or which function it performs, respectively, just by looking at its code.

We take another approach which offers an internal representation structure where an IP provider can characterise his IP. The characterisation is done by attributes (as described in subsection 4.2). The distinction between different IPs results from a functional description. The underlying VHDL or Verilog description is, therefore, not necessary. 4.1 An IP taxonomy IPs can be classified by a taxonomy very similar to that proposed by (Behnam et al. 1998), see Fig. 3. This figure shows only a part of an IP taxonomy, extensions are visualised by three dots. An edge represents an Is-A relation between a class and its parent class. This classification is reasonable as each class of IPs requires very different kinds of attributes for their characterisation. These attributes are organised in a taxonomic, object-oriented way. As new classes or IPs always may arise, both taxonomy and kinds of attributes have to be expandable and must evolve over time. To gain satisfying retrieval results it is important to limit the depth of the taxonomy and use intelligent retrieval methods as early as possible. This mostly eliminates the deficits of simple selection trees as described in section 2. 4.2 IP parameters and measures Attributes of IPs can be divided into the following three main groups. Measures like area (gate count), power dissipation, computational latency and the delay on the critical path tpdmax or the maximum clock frequency ( fclkmax = 1 tpdmax ), respectively, always depend on the structure a design is mapped to. These measures differentiate tremendously for different design styles: synthesis from RTL descriptions, high-level synthesis from algorithmic descriptions or a software implementation on a DSP. Today, soft core IPs are mostly described at RT level, but this is not mandatory. Application specific parameters are important for the user to characterise his concrete application. Examples for application specific parameters of a Discrete Cosine Transform (DCT)

Figure 3. An IP taxonomy.

are given in Sect. 4.3.2 IPs which are partially not parameterisable have fixed values for the respective parameters. For example, most IP providers offer only 8 by 8 matrix DCT or IDCT which means that the number of rows and columns are both determined to a value of 8. Design space parameters can span the design space in different ways. Examples are: • Parallel vs. sequential: If one operation, like a MAC operation for a filter, has to be processed m times in parallel, the hardware realisation can use one operator in a sequential order (the slowest solution, like in a DSP) or m operators in parallel for the fastest solution or a number of operators from 1 to m . • Pipelining at the word-level: A chain of operations can be processed completely in one clock cycle, or registers can be put between the different operations and the computation needs several clock cycles where the clock speed increases. The length of a pipeline is variable. • Parallel vs. serial (pipelining at the bit-level): An operation can be processed bit-serial, which means bit by bit. Solutions inbetween process subword by subword. The values of design space parameters are not necessarily important to know for a user. The main differences between application specific and design space parameters are: • Application specific parameters are important for the functionality of a class of IPs whereas design space parameters are provider/architecture specific (but application specific parameters, which increase the programmability/flexibility of an IP are provider/architecture specific, too). • Both have a great impact on the measures, but only the design space parameters will exchange measures like gate count vs. maximum clock frequency; see Fig. 4 as an example. For characterisation of IPs, additional parameters are required. More or less they may be clas-

Figure 4. Example of a design space: the IP measures depend on one design space parameter and the word length

sified as application specific parameters. Industry standards reflect the quality and the applicability of an IP. Examples from different domains are: ISO/IEC 11172 (MPEG-1), ISO/IEC 13818 (MPEG-2), CCIR 601 NTSC or PAL, PCI Rev. 2.0/2.1, software compatible with TMS320C5x etc. Industry standards sometimes need more parameters than one keyword only. For example, • MPEG-2 Video (not all combinations are supported by the standard): which profile: Simple, Main, SNR scalable, Spatial scalable, High, Multiview, 4:2:2 which level: Low, Main, High-1440, High • MPEG-1 or MPEG-2 Audio: Layer 1, 2, 3 Furthermore, industry standards may have different semantics for different categories of IPs: • MPEG-2 for a video encoder/decoder means: “fulfils the standard” (dependent on the additional parameters) • MPEG-2 for a DCT/IDCT means: “can be used for an MPEG-2 video encoder/decoder” I/O ports can be divided into one part which is always the same for one class of IPs (for example, the main input and output signals) and another part which is provider specific and enhances the programmability/flexibility of an IP. Reference or target technology, like: 0.5µm CMOS process, Xilinx XC4000 etc. Estimations of measures are only valid for the specified target or reference technology. We need formulas to convert measures from one technology into another one, even if they are inaccurate. 4.3 A Circuit Design Example 4.3.1 Specification The example IP described in this section implements a discrete cosine-transformation (DCT) of an 8x8 frame. It is a two-dimensional transformation (2D DCT) which is used for example in MPEG-Encoders. Additionally, with the same IP, it is possible to realise an inverse cosinetransformation (IDCT). 4.3.2 The Design Space of the DCT-IP By using the VHDL ‘generics’ command we designed a scalable IP in such a way that it can be applied in a design space with the axis “clock frequency” and “word length”. Application specific parameters are important for the user to characterise his concrete application. Examples for a Discrete Cosine Transform (DCT) or its inverse (IDCT) are: internal and external word lengths, number of rows, number of columns, type of output or type of round, clock frequency, latency, subword length and the resulting gate count estimation. This DCT example was simulated with VHDLsim 3.3a by Synopsys and the synthesis computing was made with the Synopsys Design-Compiler 3.3. Figure 5 shows the cost estimation of the chip area (in units of gate count) as a function of the choice of clock frequency and word length (compare this graph to Fig. 4). In its final state, the READEE tool will have the ability to handle chip products and IP’s. To do so, it is necessary to represent the IPs and products, including their individual design spaces. Constraint nets are an appropriate means for representing such complex dependencies

Figure 5. Cost estimation of the chip area of the DCT-IP.

between parameters. Constraint systems can be applied to determine a design point appropriate for a specific application. 4.4 A constraint net Dependencies between parameters and measures can be expressed by a constraint net which orthogonally overlays the taxonomy (Fig. 3). In general, constraint nets represent and bidirectionally resolve dependencies between attributes (Günter 1995). Concerning IPs, they can express the usable design space offered by an IP design. This can be seen as an abstract model of an IP. Such a model is just an estimation, as the measures also strongly depend on the chosen optimisation parameters of the synthesis tool, the floorplanning etc. Design space parameters and a constraint net are case-specific, spanning the design space of one IP design only. User constraints referring to measures and other user requests are propagated through the constraint net and hereby the values of other measures and parameters are restricted or even determined. Figure 4 illustrates how a constraint net can operate. The user specifies an area and a timing constraint, represented as upper limits in Fig. 4. The propagation through the constraint net results in one value (C) for that design space parameter (this could be a set of possible values in the general case). This propagation also decreases the upper bound of the word length for which this design point lies just at the area and/or timing limitations. Other measures like latency are hereby reduced, too. Figure 6 shows the design-space model for a two-dimensional discrete cosine transform in a pipelined realisation (variable Subword). The bidirectional dependencies are visualised by dotted lines. In principle, it is also valid for a great number of IPs. For the implementation by a constraint net the following functions and their reverse functions are needed: • a function ensemble architecture expense (Area = gate count, for example), • a function ensemble critical path,

Figure 6. Design-space model of a two-dimensional discrete cosine transform.

• a function power dissipation, P = fclk Pgate Area Activity , for example, • a function number of clock cycles (#CC) versus word length n and the number of pipeline stages. Functions relative to the critical path only limit the maximum clock frequency fclkmax . The effectively used clock frequency fclk can be chosen smaller, therefore the power dissipation decreases and the latency time increases. Some simplifications are useful for the implementation of a design space by a constraint net: • only one word length, oriented on an external word length. Internal word lengths are multiplied by a factor between 2 and 2.5, • other application specific parameters are neglected, • only one design space parameter: Subword. The generation of the functions for area and critical path can be done in different ways: • summing from sub-blocks like adder or multipliers and comparing this with synthesis runs, • function generation from synthesis runs by the use of statistical programs, • representation by discrete value tables. Design space points which are not in the table are interpolated. 4.5 IP selection flow with READEE The following five tasks, consecutively processed, build together a proposal for an IP selection flow with READEE. This flow consists of an IP taxonomy, general parameters and measures for IP characterisation, and a constraint net, as described above. Application Selection: The user starts at the top of an IP taxonomy (class IP in figure 3). He can navigate through the taxonomy or search for keywords which shortly characterise each IP class. The aim is to identify an unambiguous IP class into which the application he is going to develop fits into. At the top level of the taxonomy only the measures exist. For each specialisation to a subclass the parent attribute values are more and more restricted and new attributes can appear.

Parameter Specification: All attributes of a chosen class (and their ranges) are presented to the user who can specify them interactively. Retrieval: When the user has sufficiently cut down his object of desire, he starts a retrieval process, preselecting IPs by similarity calculations and constraint propagation. Parameter Determination: The user can choose one of the proposed IPs from a result list. Its design space parameters are presented, already being reduced due to the previous constraint propagation. He may further reduce all parameters that have not been determined yet. Necessary changes are automatically propagated through the constraint net. The selection is finished, if all parameters are determined. Reuse: The user can now synthesise the selected IP. He needs a synthesis tool, the license from the IP provider, and the parameter values derived during the last three steps. Both, application selection and retrieval operate on the IP taxonomy. The choice how much will be done by application selection and which decisions are left to the retrieval process are up to the user. The taxonomy should be foolproof, i.e., it must not be too detailed since that would confuse the user. For example, a microprocessor core can be specialised into subclasses of 8-bit µP, 16-bit µP, etc. It seems however, to be better to express the word length by attributes only, using the retrieval mechanism for searching. Classes should be defined broad enough that the user can easily point to the class that covers his specific problem. On the other hand, classes should be defined close enough that a reasonable number of common application specific parameters can be pre-determined.

5 Conclusions and future work This contribution has demonstrated a prototype for the selection of DSPs which successfully uses enhanced CBR techniques. An abstract IP model was presented which allows the adaptation of this approach to the area of IP reuse. Furthermore, an IP selection tool was proposed. For the next prototype some extensions to CBR-Works are required: the description of more general attribute values like ranges and enumerations as well as the integration of a constraint system. Built upon these extensions, we need to develop different modelling styles for comfortable expression of constraint nets, representing the design space of IPs. The characterisation of a concrete IP, especially the extraction of the design space curves (see Fig. 4) can only be done by the IP designer himself, as he is the only one who has in-depth knowledge on his design. For studying appropriate procedures we started an application example where a discrete cosine transform has been designed in a parameterisable form and the resulting design space curves could be extracted for representation in a constraint net. We hope that we will be able to utilise the results of our circuit design example (cf. Sect. 4.3) to develop a structured proposal for IP providers that guides them in characterising their IPs. With a growing IP market a sophisticated representation of the design-space of IPs will become a must. Otherwise the search for suitable IPs will become very difficult for a designer. With the concepts developed within the READEE project it will be possible to accurately describe an IP's qualities. Due to the system's ability to automatically evaluate IPs it can hide confidential information from the user while still offering high quality retrieval results.

References Behnam, B., Babba, K., and Saucier, G.: IP Taxonomy, IP Searching in a Catalogue. Design, Automation and Test in Europe Conference (DATE98), Designer Track. Palais des Congrès, Paris (1998) 147–151 Bergmann, R.: Effizientes Problemlösen durch flexible Wiederverwendung von Fällen auf verschiedenen Abstraktionsebenen. PhD Thesis, University of Kaiserslautern (1996) Bergmann, R., Wilke, W., Vollrath, I., Wess, S.: Integrating General Knowledge with ObjectOriented Case Representation and Reasoning. In: Burkhard, H.-D., Lenz, M.: Proceedings of the 4th German Workshop on CBR – System Development and Evaluation. Informatik-Bericht Nr. 55. Humboldt University, Berlin (1996) 120–127 Günter, A. (Ed.): Wissensbasiertes Konfigurieren – Ergebnisse aus dem Projekt PROKON. Infix, Sankt Augustin, (1995) Lehmann, G., Wunder, B., Müller-Glaser, K. D.: VYPER! Eine Analyseumgebung zur rechnerunterstützten Wiederverwendung von VHDL-Entwürfen. In GI/ITG/GME-Workshop “Hardwarebeschreibungssprachen und Modellierungsparadigmen”, Darmstadt, Germany, (1996) Lewis, J.: Intellectual Property (IP) Components. Artisan Components, Inc., http://www.artisan.com/ip.html, (1997) Oehler, P., Vollrath, I., Conradi, P., Bergmann, R.: Are You READEE for IPs? In Proceedings of the 2nd Workshop “Reuse Techniques for VLSI Design” 1998 in Karlsruhe, Germany (to appear) Vollrath, I.: Ähnlichkeitsbasiertes Retrieval zur Wiederverwendung Elektronischer Schaltungen. Diploma Thesis. University of Kaiserslautern, Germany (1997) Vollrath, I., Oehler, P.: READEE – a Similarity-Based Reuse Assistant. Design, Automation and Test in Europe Conference (DATE98), University Booth Demonstration Abstracts. Palais des Congrès, Paris (1998) Vollrath, I., Wilke, W., Bergmann, R.: Case-Based Reasoning Support for Online Catalogue Sales. IEEE Internet Computing Vol. 2, No. 4, July–August (1998) Wahlmann, T.: Diploma Thesis. University of Siegen, Germany (1998)