go to Xputer pages

homepage  |  impressum  |  survey  | 

The History of KARL and ABL

TU Kaiserslautern

 Karlsruhe Institute of Technology (KIT) homepageInstitut für Technik der Informationsverarbeitung (ITIV) des Karlsruher Institut für Technologie (KIT)



Survey on KARL-related pages | KARL index (users etc.)

"KARL" stands for "KAiserslautern Register transfer Language" . 

"ABL" stands for "A Block diagram Language" .

The work reported here has been partly funded by the Commission of the European Communities.

This paper has been derived from the paper:
R. Hartenstein: The History of KARL and ABL; in:  J. Mermet (editor): Fundamentals and Standards in Hardware Description Languages; ISBN 0-7923-2513-4, Kluwer Academic  Publishers, September 1993.   

1 Textual KARL Versions
1.1 Non-procedural KARL versions
1.1.1 KARL-1
1.1.2 KARL-2
1.1.3 KARL-3
1.2 Procedural Extensions
1.2.1 CVS_BK
1.2.2 KARL-4
1.3 Generic Front Ends for KARL
1.4 Object-oriented design
2 Interactive Graphic Language ABL
3 Supporting Structured Design
3.1 Algebraic Structured Design
3.1.1 Recursive Hardware Description
4 The Intermediate Form RTcode
5 KARL-related CAD Tools
5.1 Simulators and Fault Simulators
5.2 Testing and Verification
5.3 Layout and High-Level Synthesis
5.4 KARL in teaching and chip design
6 Exploitation Efforts
7 Conclusions
8 Literature
8.1 Categorized References

This paper is not a tutorial. Because of limited space available here this paper gives only a limited survey on the evolution of the hardware description language KARL and its derivatives. We intend to stress such features, which are different from most other hardware languages. Before a comparison of KARL to other languages it is useful, to introduce a classification scheme for computer hardware description languages (CHDLs). There are graphic and textual languages. The number of abstraction levels covered differs between languages. That’s why we start with a look at the language classification scheme (also see[6]). We may distinguish at least four different kinds of descriptions (Fig.1 a):

  • procedural descriptions
  • functional descriptions
  • structural descriptions
  • topological descriptions

Fig.1 a is a modified version of the Gajski-Kuhn diagram, which does not distinguish functional and procedural descriptions as subclasses of behavioral descriptions. Another difference to Gajski-Kuhn is it, to distinguish pseudo-structural elements (to express partitioning without a physical meaning) from really structural descriptive elements (with a physical meaning). A third difference stems from the fact, that CHDLs do not deal with geometry (Fig.1 b). But there are only two CHDLs which are capable to express topology (which is close to geometry): uFP (by Mary Sheran [17]) and KARL (Fig.1 c).

1. Textual KARL Versions

KARL-1 through KARL-3 are non-procedural languages including topology features, such as being characterized by Fig.1c. All three textual languages (see sections 1.1.1thru 1.1.3) have been carefully designed to fit to a graphical companion notation ABL (such as logic diagrams fit to Boolean equations). For more details on ABL and its implementation see 2) The coexistence of ABL and KARL is illustrated by Fig.4.

Later on some extended versions of KARL have been introduced, by new language implementations (languages CVS_BK and KARL-4) and by implementation of preprocessors being filter programs to existing KARL compilers (languages superKARL and hyperKARL). CVS_BK and KARL_4 also cover procedural descriptions, so that they are fully dichotomic languages (see Fig.1 d). However, hyperKARL and superKARL have no procedural part, but have features to support functional extraction from personality matrixes of gate matrix layout (what we called MOL (Matrix-oriented Logic). For more details on CBS_BK and KARL-4 see sections 1.2.1 and 1.2.2. For more on extensions by filter programs see section 1.3 .

1.1 Non-procedural KARL versions

KARL-1 through KARL-3 are non-procedural languages including topology features, such as being characterized by Fig.1 c. All three textual languages have been carefully designed to fit to a graphical companion notation ABL (such as logic diagrams fit to Boolean equations). ABL stands for "A Block diagram Language".

ABL has already been introduced together with KARL-1 [1]. In order to support structured VLSI design also featuring wiring by abutment all three languages include topology operators like “:“ for horizontal abutment and “@“ or "("...")" for vertical abutment (KARL-3 and up), as well as juxtaposition ("•" for subword catenation and "|" for array catenation). These features are reflected by the Domino notation having been introduced with KARL-1 by the book [1]. Fig.4 illustrates this by a simple example (textual: fig. c) the use of block diagrams (a) and the Domino notation (fig. b). The language elements of KARL-3 are summarized by a number of tables in Fig.5 thru Fig.8.

1.1.1 KARL-1

The first version of KARL is the non-procedural hardware description language KARL-1 [2]. KARL has been introduced together with a graphic language called ABL (A Blockdiagram Language). Like the textual notation of Boolean equations and the graphic notation of logic diagrams also KARL and ABL are companion notations. With ABL the Domino notation (Fig.16, also see above and Fig.4 b) has been introduced. KARL and ABL are used throughout a text book on structured LSI design [1]. There has also been a KARL-1 implementation effort at Politecnico di Milano [26].

1.1.2 KARL-2

The second version KARL-2 has been developed at Kaiserslautern [3] [4] (now KA in KARL stands for KAiserslautern). Parsers and Simulators have been implemen-ted at Kaiserslautern and elsewhere [27], running on VAX under VMS and UNIX. The language has spread, also through courses, summer schools and similar events, as well as by license agreements and by mailing manuals and other material. An interesting semi-typological feature is the ":" horizontal abutment constructor for lateral abutment of functions as a concise notation for merging data paths. This lateral abutment includes automatic check and connection of ripple flow.

1.1.3 KARL-3

Immediately after talks on KARL and its application during a summer school at Schuola Reiss-Romoli (L’Aquila, Italy), Kaiserslautern has been asked to join the CVT proposal (CVT stands for CAD for VLSI in Telecommunications). This proposal and its successor CVS (CAD for VLSI Systems) have been approved by the Commission of the European Communities for being funded within the ESPRIT program. These two very large projects have been headed by Dr. Leproni at CSELT (Torino, Italy) provided a major break-through for KARL and ABL. During CVT the version KARL-3 has been developed and implemented at Kaiserslautern [5] (running on a number of different platforms) and integrated into the CVT software system. Finally several simulators have been available accepting RTcode, the intermediate form generated by KARL compilers [5][27][30] [31]. A physical modeling extension has been implemented [29] to connect a Tektronix DAS 9100 hardware analyzer to a KARL simulator.

1.2 Procedural Extensions

Also the first behavioral extension of KARL has been developed within CVT: a behavioral shell has been written around the KARL simulation system [32] [33]. To derive KARL-descriptions from matrix-oriented logic (MOL, such as PLAs and others) and for generic KARL descriptions 2 filter programs have been written [36][37]. These generic languages accepted by these preprocessors are called superKARL, or, hyperKARL, respectively.

1.2.1 CVS_BK

KARL-4 and CVS_BK. Within the CVS project (the successor of the CVT project) the language CVS_BK (CVS Behavioral KARL) has been implemented [34], so that also sources for high level synthesis [70] [64] and systolic array synthesis [65] [73] could be formulated.

1.2.2 KARL-4

Until beyond the end of the CVS project an improved version of CVS_BK has been developed at Kaiserslautern: KARL-4, especially polished also to fully support generic hardware descriptions [15].

1.3 Generic Front Ends for KARL

To extract KARL-descriptions from matrix-oriented logic (MOL, such as PLAs and others) and for generic KARL descriptions 2 filter programs have been written [36][37]. These generic languages accepted by these preprocessors are called superKARL, or, hyperKARL, respectively. These generic languages provide means to parameterize dimensions such as data path width, array size, fan-out size etc., and for recursive hardware descriptions of iteratively structured hardware. The behavioral extraction is supported by such features as well as by the bus de-scription primitives of KARL, which permit gate splitting needed to map transistor arrays.

1.4 Object-oriented design

Like software engineering, also hardware system design has complexity problems. In both areas bad design styles may lead to incomprehensible unmanageable structures. The term software crisis having been coined 1968 indicates common awareness of the problem. Mainly two approaches have been advocated by the field: teaching structured programming rules or similar concepts and discipline to follow such rules. Only good management (if available at all) has been really successful to achieve such discipline. That’s why now, after 25 years, the software quality problem has not yet been really solved. A more recent trend goes toward computer-aided guidance, by CASE (global guidance) and OOP (object-oriented programming): more local guidance. VLSI system design has learned from software engineering: hierarchical partitioning is one of the most important common concepts. Now CAD framework R&D efforts have goals similar to those of CASE: global guidance. But we also believe in local guidance in hardware design: object-oriented design. A very efficient way is guidance by languages. e. g. by block structure and data types.

With this goal in mind block structure and data type features of a new language (KARL-5) of this family have been specified during CVT [35], which thoroughly support the control part / data part dichotomy in a very general hierarchical way by data types like control, data, initialization etc. These partitioning schemes support structures like controller hierarchies or like the following schemes: a controller controls several data parts or several other controllers, a controller might be combinational (e. g. decoders in a smart memory array). Such structures mean a generalization of von-Neumann-like partitioning schemes.

The level of description of such hardware block structures is that known from the PMS notation [43] (PMS stands for Processor, Memory, Switch , where the term Switch denotes memory managers, I/O channels, LAN servers and similar equipment, and has no associations at all to the switching level). PMS is mainly a structural notation for hardware platforms. Although most parts in such structures are procedurally implemented, their behavior is hidden by non-procedurally looking external views. Boxes at that level represent non-procedural containers for procedural implementations.

Fig.10 shows a few simple PMS notation examples, where the following abbreviations are used: M for memory, Mp for primary memory, Ms for secondary memory, P for processor, Pc for central processor, L for link, T for transducer, K for controller, D for Data Operation, and X for external world. Fig.11 shows more complex PMS examples, where S stands for Switch, and C stands for stored program Computer. A Computer is defined to be an independent unit which includes a processor, private primary memory and switch (compare Fig.11 a). The examples illustrate, that the PMS scheme is hierarchical. scheme.

The PMS scheme is merely a structural hardware scheme. It does not reflect the relations of procedural objects hidden inside its boxes. An improvement is provided by the HIM scheme [39] [40], which partly is a generalization of the PMS scheme (HIM stands for Hierarchy of Interpretive Modules). HIM also supports nested machines [38] and semi machines and maps the interpretive relations between modules by structural restrictions.
HIM provides a unified model for virtually nested machines and physically nested machines (which is a performance issue [41]). It supports both views on control: the software point of view (programmable control: control store separated from the sequencer) and the hardware point of view (hardwired control: monolithic controller like finite state machine). Such a uniformity of partitioning is important flexibility w. r. to alternative implementations, such as e. g. emulation by microprocessor or industrial controller, or, direct implementation on silicon.

The HIM scheme provides for KARL-5 structural grammar rules and data types strictly distinguishing data side and control side, (horizontally) crossing (information) flow (evoke, feed back, see Fig.9 b, literals, etc.), crossing that boundary line, other horizontal flow, vertical flow (across boundaries of hierarchy levels, like initialize etc., see Fig.12).

Examples of HIM scheme applications are illustrated by Fig.12. Fig. a shows a non-primitive machine (a machine having an inner machine: i. e. nested machines) and fig. b shows the inner machine of it. KARL-5 is a KARL version having been specified to support a HIM-scheme -like block structure. Fig.13 shows an example scheme: the structure of a VLSI parallel sorter [44] having been derived from the bubble sort algorithm by parallelization of its inner loop. The highest level shows the processor (P) named Shuffle Sorter, split up into control Part (CP) and data part (DP), where DP consists of a switch part (SP) for I/O and an operation part (OP). This OP called SA (Swap processor Array) is an array of processors (called swap processors). So this is a generalized nested machine scheme where a processor has an array of inner machines. The control part of a swap processor is combinational (just a decoder D), which is a generalization of the dichotomic scheme (cp. Fig.9)

2. Interactive Graphic Language ABL

ABL. An interactive graphic ABL editor called ABLED [20] [21] has been implemented jointly by CSELT and Kaiserslautern within a CVT subtask headed by Guglielmo Girardi. ABLED is running on Apollo Domain under AEGIS and GKS. This hardware platform has been decided at a time, where SUN did not have distributors in Europe, and DEC did not offer workstations. The version GENMON has been derived from ABLED for design methodology descriptions [23].
Fig.14 thru Fig.17 illustrate the use of ABLED and its user interface a little bit. Fig.15 shows an example of ABLED’s fast dialog: the system’s query is directly placed into the view of the object being edited (<vector_decl> in fig. a), and the user directly types his answer into the same field (ACCU[31..0] in fig. b). This kind of dialogue is an advantage, since no separate dialogue boxes have to be pushed around in order to uncover the schematic. For cells ABLED provides two different views, from which the desired one may be selected by the user: an external view (example in Fig.14 a), and, an internal view (Fig.14 b). ABLED supports 4 different levels: pseudo switching level, gate level (example in Fig.14 b), non-procedural RT level (example in Fig.16 b), and abstract level (e. g. user-defined truth tables, transition tables etc.).
Fig.16 b illustrates extensive use of the Domino notation in synthesis of a 4 bit adder from 4 full adders FA and ABLED primitives (the dot "•" indicates a catenation, and, the box with curly brackets without a dot indicates subscripted splitting up an 8 bit word into 8 single bit words). ABLED supports the Domino notation through abutment by snap-in (see Fig.17 a and b) with automatic interconnect and on-line graphic syntax check (see example in Fig.17 b: in case of port mismatch ABLED refuses to create the interconnect).

ABLED includes several interfaces, such as a PICT generator [25]. An ABL2KARL translator helps to enter designs produced with ABLED into the KARL simulation system. Such ABL data structure translated into KARL may be further compiled into RTcode accepted by a number of other tools (see Fig.33).

3. Supporting Structured Design

To support design and especially teaching design a hardware description language should be simple and concise (i. e. it should be compact and precise). To support and teaching structured design a language needs to be powerful without being baroque. To meet these objectives a good language should not have too much philosophy. Rather it should provide natural modeling and familiar semantics. It should be self-explanatory to support intuitive use.
To find out, wether KARL or VHDL meet these objectives, let us compare the use of these two languages by a few simple examples: an AND gate, a 4 input multiplexer, and, connecting two bus drivers to a bus. Fig.18 shows an AND gate (a), its VHDL descriptions (b) and its KARL description (c). In the KARL description (c) you just write down an and expression as known from Boolean algebra and connect it by ".=" to the destination node ("terminal") Out1. In the VHDL description (b) you need to define a cell AND and to assign a label (U11) to it, because later on you will have to define a configuration block, which assigns a special architecture to the AND gate. We are also forced to introduce a delay in your AND cell (compare Fig.18 b).

Fig.19 shows a 4 input multiplexer (a), its partial VHDL description (c) and its complete KARL description (b). In (b) you write down a case expression similar to that known from programming languages like Pascal and connect it to the terminal node (Out1). In VHDL (c), however, you have to introduce delays (defined elsewhere) and a separate transport clause for each input: a lot of artifacts are needed, far away from the desired model.

Fig.22 shows the description of a bus with two drivers (a), the VHDL description (b), the KARL description (c) and the model in the KARL description (d). The open collector outputs of two and gates are drivers to a pullup bus (Fig.22 a).

Within VHDL description (b) a user-defined resolution function is needed, since buses are not included in the language semantics. That’s because VHDL does not permit more than one signal source to a node. This resolution function has to be defined in a procedural way - far away from the world of the hardware designer.
A KARL description of this example is much more simple, since all possible kinds of buses (tribus, upbus, downbus) are modeled by KARL primitives such, that the resolution functions are part of the semantics.
Fig.22 c shows the KARL description, which refers to a declaration "upbus Bus1". Defined by the KARL semantics an upbus is a "~1" (a soft "high"). Connecting drivers to such a bus node is directly mapped by the familiar switching level model [12] [13] of the “#“ connect operator (Fig.23 a).
Fig.23 b shows the KARL semantics of the oco driver, and fig. c the resolution function semantics between upbus and multiple oco driver connects to it. The bus example demonstrates, that KARL also covers the switching level in a technology-independent way. The KARL compiler converts such switching level structures into a directed internal form, so that it can be handled by a directed simulator (i. e. no switching simulator is needed, for more on transforming switch-level networks into an explicit functional representation see[11].

The inclusion of the bit value "undefined" in the KARL semantics also supports built-in ambiguous delay models. This is important for realistic modeling of racing conditions, what will be illustrated by the following example. Fig.24 a shows an intended transition from 00 to 11, which due to races could end up in an faulty transition to 01 or 10. This race condition will not be detected by a VHDL simulation.
Fig.24 b shows the result when both, q1 and q2 have the same delay. But also if different delay times are used for this model in VHDL, no race will be detected (only a faulty q1q2 will be outputted). KARL, however, provides an ambiguous delay as a language primitive (see example in Fig.24 d), which automatically reveals races by "?" output (Fig.24 c shows the KARL simulation result for the example in fig. a). The truth tables of all primitives - essentials of the KARL semantics - are carefully tuned for safe error propagation to primary outputs: a "?" detected there leads to the error roots by a backward "?" trace.

Fig.25 illustrates, that not only a language level being too low, but also a language level being too high, lead to a strong increase of description cost. From this point of view KARL is closer to algorithms in silicon than VHDL. VHDL also is very verbose. The above examples have shown that, compared to KARL, VHDL is not simple and does not support conciseness. The user is forced to create a huge framework around his problem, which does not directly contribute to the desired model. Missing semantics forces the creation of libraries of many natural things, which in case of KARL are part of the language semantics. These user-defined libraries needed for VHDL create incompatibility problems. Because of the need to cope with all these difficult problems VHDL creates jobs - for consultants and organizers of courses and user group workshops.

3.1 Algebraic Structured Design

Using KARL as a calculus to obtain a regularly structured design is illustrated by the following multiplier design example. The problem is the multiplication of a non-negative integer multiplicand X with a non-negative integer multiplier Y to obtain a non-negative integer product P. First we define a set of theorems (1) thru (5) for integer multiplication.


means, that multiplication of w by 2i equals w shifted left by i bit positions.


means: shift left by i positions equals shift right by -1 positions.


means, that shifting by i, and then shifting by j, is equivalent to shifting by i+j.


means, that shifting by i first, and then adding equals adding and then shifting. From (2) and (3) we may derive the following:


When we apply (3) to (5) we obtain:


Now let us use these for designing an integer multiplier. We use an example with two 4-bit operands: a multiplicand X and a multiplier Y of the following form.


The product P is obtained by the following mathematical formula.


Application of rule (1) converts this into the following form.


By theorem (5) we obtain the following form.


By reversing the accumulation sequence from I = 0, 1, 2, 3 to i = 3, 2, 1, 0 we obtain:


The following detailed form of this does not represent a regularly structured design.


The shift left by 4 at the output, which is not really significant, will be discussed later. By consecutive application of rule (3) we obtain the following form.


Adding C is permitted if C = 0. This leads to the form.


This represents a regularly structured design, since we may partition it into four layers which we call MultLayer. Since yi is a single bit only we obtain a multiplexer within MultLayer:


From (2) we obtain the cell MultLayer as shown by the ABL diagram in Fig.26 a.

Now we need another circuit, which generates all yi with i = 0, ... 3 to feed all ConAddShi layers. We call this circuit the Condition Bit Generator or, briefly CoBiGen. From the word Y(0) (Fig.26 c) the selector y0 is derived by selecting the least significant bit (Fig.26 c) by using the lsb standard function of KARL. The selector y1 for the next ConAddShi we obtain from Y shifted to the right: from Y(1) = shr(Y(0)) (see Fig.26 e), where y1 = lsb(Y(1)) of the next layer. To derive all yi for i = 0, ... 3 we assemble an iterative sequence of layers: the multiplier bit generator CoBiGen shown by Fig.27.

Finally we abut the CoBiGen (on the right side) with the 4 layers of ConAddShi (on the left side). We obtain the complete integer multiplier as shown by Fig.28 a. Both shr operators in each layer we serially connect from left to right, so that the adder overflow in producing intermediate products P(1), P(2), etc. finds room in the neighbor CoBiGen cell, which has been made available by the series of Y(1), Y(2), etc. with shrinking word length.
Now we may also interpret the shift left by 4 having been introduced by equation (11). By successively shifting the partial products to the right into the CoBiGens we moved the product to positions of lower weight. This is compensated be the "4 shl" in fig. (12). Fig.28 b shows the nMOS layout of this multiplier, developed 1980 at Kaiserslautern and manufactured later on a multi project chip brokered by the E.I.S. multi university project in 1984.

3.1.1 Recursive Hardware Description

Language features for recursive hardware descriptions are important ingredients for flexible support of generic description methods. The most compact and comprehensible textual recursive descriptions are obtained by using an extended functional notation, an alternative of the abutment expressions developed for KARL-3: slice expressions which are more mathematical and less topological. To derive floor plans from such descriptions it can easily be transformed back into the topology notation having been introduced above. The basic idea is the modeling vertically abutted functional cells (Fig.29) by nested functions. For example see the ABL diagram in Fig.29: abutment expression P @ Q will be replaced by nested function references P ( Q ( <operands> ) ). The make clause


will be converted into the ordinary functional expression, right of the ".=" connector in:


Fig. d illustrates the general scheme of layer to nested function conversion. Fig.29 b shows ABL diagram and make clause of a mixed layer / slice example. By conversion into a slice expression we obtain:


Slice expressions are based on the orthogonal flow convention shown in Fig.29 c: the "vertical" data flow through a sequence of layers is called main flow, the "horizontal" flow (e. g. ripple flow or control code distribution) is called serial flow. In slice expressions main flow is represented by parentheses, and serial flow is indicated by colons, like in (18). Multiple operands and multiple destinations are catenated by dots to fit to the slice expression, like in (18). The ABL diagram in Fig.29 e is expressed by the following slice expression:


With respect to implementation slice expressions are just a subset of the abutment expression implementation. In abutment expressions the attributes in, out, and bi are applicable to all 4 sides. In slice expressions "cells" have the following restrictions: front side may use out only, the back side in only, since by convention main flow always goes from back to front. Serial flow may go left or right or both (see Fig.29 c), so that at left and right all attributes are allowed: in, out and bi.
Fig.30 shows and explains an example of recursive description by slice expressions (for symbols and abbreviations see figure g). It is a bit level butterfly with a path width of 16. Fig. a shows its wiring pattern and fig b its connections to the environment (" \¢ " denotes, that the path width is inherited from the source). Fig. c shows a partitioning scheme applied to it. Fig.30 d shows the slice expressions of the cells in fig. c. The cell butterfly\¢-4 is a recursion: the butterfly is defined in terms of a smaller butterfly. Fig f is the textual version of fig. d (fig. e explains the conversion). The text in fig. f is concise and very compact. An equivalent VHDL description of this example would tightly cover an entire page, if possible at all (we didn’t take the effort to try such a description). Fig.31 shows the slice expression for Fig.28

4. The Intermediate Form RTcode

RTcode is the executable form of KARL descriptions. RTcode[28] is generated by the KARL compiler and is executed by KARL simulators (and other tools). RTcode has a bidirectional list structure which supports a wide variety of CAD algorithms. During the time of the CVT project RTcode has become an important interchange format used by more than a dozen different users. Fig.33 shows, how 7 non-KARL tools from different partners within the CVT project are integrated by means of a central RTcode interface such, that RTcode is a kind of design data base of a major part of the CVT software system. So RTcode is the backbone of an early CAD framework for VLSI design.

5. KARL-related CAD Tools

We distinguish simulation, test pattern development Most directly related to CHDLs are simulators - important CAD tools, more efficient than other kinds of simulators, are subject of section 5.1. Closely related to simulation is the area of testing. Section 5.2deals with KARL-related methods having been implemented for test pattern development and for verification: deriving functional test patterns from KARL descriptions, functional extraction from layout or from personality matrixes for verification purposes. Also integrating simulation and test pattern development is an approach of design for testability. Section 5.3 deals with using KARL and ABLED and their topology features for structured VLSI design within the framework of the CVT software package, as well as with high level synthesis and related methods and their support by CHDL use. Section 5.4 points out some practical experiences in commercial and academic chip designs and other practical applications. More literature on all this is referenced in [16] Fig.32 and Fig.33 help to achieve a partial survey on KARL-related tools.

5.1 Simulators and Fault Simulators

For KARL-1 only a single simulator implementation effort has been reported [26]. Three simulator implementations have been reported for KARL-2 [3] [27] [30]. From KARL-2 simulation experiences two example collections have been assembled [8][9]. Three different simulators have also been implemented for KARL-3 [5]. One of them, called SMART, is an event-driven simulator [31]. Another of them is a fault simulator [81] (also see next section). For these KARL-3 simulators a physical model extension has been implemented [29], which organizes the cooperation of a tester (Tektronix DAS 9100 digital analyzer) running concurrently with the simulator. All these simulators accept code generated from a non-procedural hardware description language. However, also for procedural extensions of KARL-3, the languages CVS_BK and KARL-4 a simulator has been implemented [34].

5.2 Testing and Verification

This section deals with KARL-based software for generation and evaluation of test patterns as well as for design verification and its support by extraction of KARL descriptions from layout.

KARL use in Testing and Verification. Also verification and test pattern generation and validation may benefit from CHDL use. Two KARL-based systems have been implemented, the KARATE system [86] [89] and the CVT test development environment [82] [83] including a KARL-based fault simulator (a version of the CVT KARL-3 simulator) and an automatic fault extractor [84]. Also an experimental KARL-based verifier has been implemented [93][94]. For verification support the REX system has been implemented at Kaiserslautern for extracting KARL descriptions from layout [99][100].

KARATE (KARL Automatic Test Extractor) is an automatic test pattern generator for KARL3 Hardware Descriptions which was developed in 1988 [89],[87]. Unlike most test pattern generators which are based on the D-Algorithm [90] [91] [92] KARATE also supports test pattern generation for sequential register transfer level descriptions and may be therefore used for test pattern generation at the early phases of a design process. A build in testability analysis guides the designer in finding an easy testable architecture.

Two innovative features of KARATE elaborate it from a simple test pattern generator to a flexible test pattern environment. These are:

  • explicit fault modeling
  • hierarchical test pattern generation

Explicit fault modeling means that KARATE's ATPG algorithm is independent of a specific fault model. Component test patterns specify tests for the unconnected hardware primitive. Different component test patterns libraries are provided for distinct fault models. Propagation properties of language primitives are specified in terms of functional patterns using symbolic functions.

The ATPG algorithm within KARATE consecutively applies component test patterns to each primitive of a netlist using functional test patterns of the other components to propagate values to the primary ports of the netlist. This process is done by a least cost depth first search algorithm with efficient heuristics to prune the search space [74].The algorithm works hierarchically by generating functional patterns for the master of each component instance in a hierarchical design, hereby reducing test pattern generation time by exploiting the design hierarchy.
Structural test patterns and functional test patterns may also be predefined for complex cells using KARATE's pattern editors. This allows support of design for testability techniques like build in self test or scan-path techniques. KARATE also provides a testability analysis that explicitly shows bad testable parts of a design.

Functional Test Patterns. Conventional systems for automatic test pattern generation work on flat gate level Hardware Descriptions and are restricted to the “stuck-at” fault model. KARATE generates test pattern generation at RT-, logic and switch level which do not rely on a specific fault model [75]. The hierachical test pattern generation process of KARATE allows support of DFT techniques like BIST or scan-path techniques. KARATE generates test pattern in various formats. Tester specific formats like EDIF200, SENTRY, Tektronix DAS 9100 and simulator activation languages SCIL and SCIL-3 [78]. The KARATE system has a comfortable user interface for testability analysis, pattern generation and editors to create functional test patterns and component test patterns and for library management. KARATE is implemented in VAX/VMS-PASCAL and runs under VAX-VMS. Test pattern generation for RT level descriptions of medium complexity run within a few CPU seconds on a VAX 11-750.

CVT test development environment. Fig.32 gives an overview [53] of the CVT test environment which was developed in cooperation with CSELT and Olivetti. This environment as well as its main program are called TIGER (Test pattern Interactive Generator Environment at RT level) [80]. The TIGER program is organized as a shell written around OFSKA and the KARL-3 system. But, in fact, TIGER is a test pattern generator using information provided by a testability analyzer OTAKA (Olivetti Testability Analyser based on KARL) [79], a fault simulator OFSKA (Olivetti Fault Simulator based on KARL) [81] (an interactive tool to evaluate fault coverage of given test patterns, allowing fault models of the type stuck-at, bridge, truth table change, function change), and FERT (Fault model Extractor at RT level) [84], a fault extractor. A fault generator OFGKA (Olivetti Fault Generator for nets described in KARL) supports OFSKA. FERT computes functional models with injected faults and extracts these faults from layout including parasitics and a physical fault set. FERT accepts a SPICE-NDL-like input format and generates RTcode format [76] as input for TIGER. Like KARATE, TIGER is also independent of an underlying fault model. The system requires more interaction by the user than KARATE but provides more support to for layout specific fault models. Fig.33 shows, how the above test pattern development system has been integrated into the CVT CAD software environment. Note the central role of RTcode, the intermediate form compiled by KARL compilers.

Verification and Register Transfer Extraction. The correctness of a design compared to its specification is generally validated by comparing the simulation runs of the register transfer specification and logic level simulation. The quality of this comparison is heavily dependent on the chosen set of stimuli patterns used for simulation. The Register Transfer Extractor REX and VERENA provide verification of a layout against its register transfer specification. REX[95][97][99] reconstructs an RT-level description out of a previously extracted circuit netlist by graph matching. The algorithm finds an optimal matching of isomorphic subgraphs to a library of RT-level circuit netlists. VERENA [93][94] is then used to determine the functional equivalence of the extracted register transfer netlist and the specification. REX has been developed at University of Kaiserslautern. VERENA was developed at University of Passau.

5.3 Layout and High-Level Synthesis

A substantial amount of synergism may be obtained from integrating a CHDL into the design process [61]. Several programs have been implemented for deriving layout or minimizing logic from KARL descriptions, deriving module generators form the KARL language, or, generating KARL descriptions from high level specifications.
Fig.33 shows the linkage between ABLED and the KARL simulation system to the interactive chip floor plan generator ARIANNA and to PLA design tools [53] like ASMA (algorithmic state machine assembly), SCOD (for state encoding), KMIN (for logic minimization), FOLD (for PLA folding), and FLAP (MOS layout generator for PLAs). This PLA tool set is interfaced to KARL through PLA2KARL. ARIANNA accepts RTcode and ABL data directly.
A systolic array synthesis program SYS3 generating KARL-3 descriptions has been implemented at Kaiserslautern [65] [73]. For a given algorithm (design problem) such a program generates a set of systolic array solutions. The size of such a set is controlled by constraint parameters (e. g. performance). New at that time has been the implementation of the SYS3 feature, which generates a KARL description of the complete VLSI array architecture as well as internal and external views of all cells needed such, that structured VLSI design is directly supported. New at that time has also been the feature, that all rotation and mirroring variants of solutions already generated, are eliminated automatically.
Also a CVS_BK-based logic optimizer has been implemented [70]. Enhanced standard cell / macro cell routing programs [71] yield surprisingly good results (e. g. routing channel width of 2 wires or less) for data paths and other structured hardware, when placement is derived from a CHDL representation [69]. This has been implemented by PSICO based on KARL-3 [72] and BACH based on CVS_BK [64]. Using SYS3 as a front end PSICO could derive layout from a high level specification of the algorithm to be cast into silicon. Only 2 CHDLs have been published which include topology primitives and wiring operators. One of them is KARL-3. That’s why by the University of Kyoto a language for designing module generators has been derived from it [66] [67].

5.4 KARL in teaching and chip design

KARL-3 has been used in designing several integrated circuits at Kaiserslautern, which have been manufactured on multi project chips assembled by the multi university E.I.S. project. KARL has also been used in completion of some industrial IC designs [54] [55] [56]. For teaching KARL is used or has been used, respectively, at Kaiserslautern and elsewhere (e. g. [60]). One of the first uses of [1] in teaching has been by C. V. Ramamoorthy at UC Berkeley. More references to KARL applications are found in [16].

6. Exploitation Efforts

An ABL and KARL User Group ABAKUS has been organized by Karin Lemmert and Andrea Wodtko, which provided licenses, distributed manuals and other application support material (e. g. [8], [9]) and even an ABAKUS Newsletter, and organized workshops. The number of licensee institutions finally reached 93. The 1st ABAKUS workshop in Passau (Germany, organized 1986 by Werner Grass, University of Passau) attracted 35 participants from 8 countries and the 2nd one at Igls (Innsbruck, Austria, organized 1988 by Bernhard Quatember, University of Innsbruck) attracted 44 from 6 different countries. Exploitation of KARL-based developments has also been a subgoal of the CVT and CVS exploitation efforts [101]. But commercially the final result is: VHDL is the winner. This has been achieved by a DoD-supported pressure group, also by killing CHDL, the worlds's only fully competent series of annual international conferences on hardware description languages (click here).

7. Conclusions

Before VHDL had been widely spread, KARL has been well accepted and widely used, mainly in industrial and academic research, but also for commercial applications. This is indicated by 93 licensees (holding site licenses), the number of simulators having been implemented (see section 5.1), the number of RTcode users (more than a dozen), a large number of CAD tools related to KARL or somehow connected to KARL software (we do not know the exact number), the number of KARL dialects [45] [46] [47] [48] [49] [50] and evaluations ([2] [51] [52] and others). This success would not have been possible without the massive funding received from the Commission of the European Communities within CVT and CVS project (part of the ESPRIT programme). At that time for VHDL only a slow Simulator has been available [19]. The conclusion is, that in the eighties, Europe has been far ahead of the rest of the world (not only due to KARL, but also other efforts (reported in this volume), like by the CONLAN group, the CHDL-based hardware verification scene, and others. But finally all commercialization efforts failed. What has been the reason for this? The European disease (lack of competitiveness, hesitating in launching innovative products)? The European IH (Invented Here: cannot be interesting - widely spread view in European industry) effect (the inverse of the American NIH (Not Invented Here: cannot be interesting - view widely spread among highest ranking US universities) effect)? Because VHDL has become a standard (although KARL is a completely different thing)? Is this standard really better than no standard at all?

8. Literature

The KARL user group ABAKUS (see section 6) collected KARL-related literature (reports and publications), as well as literature with KARL-related references. This list [16] (available for free, contact the e-mail address: abakus@informatik.uni-kl.de), which has been regularly updated until about 1986 or 1987, includes 299 entries. Because of space limitations the following section shows only a part of such references.

8.1 Categorized References
[1] R. Hartenstein: Fundamentals of Structured Hardware Design: A Design Language Approach at Register Transfer Level; North Holland; Amsterdam/New York, 1977.
[2] P. A. Anderson, M. Nygaard: A study of different languages for description and simulation of digital systems; report no. 6/78. Univ. Trondheim, Norway, 1978
[3] R. W. Hartenstein, E. von Puttkamer: KARL - a Hardware Description Language as a part of a CAD tool for VLSI; IEEE CHDL'79, Int'l Symp. on Computer Hardware Description Languages and their Applications, Palo Alto, California, USA, 1979; IEEE New York, 1979.
[4] R. Hartenstein, P. Liell: KARL-2 Language Reference Manual; Kaiserslautern 1983
[5] R. Hartenstein, K. Lemmert: KARL-3 reference manual; Univ. Kaiserslautern, 1984.
[6] R. Hartenstein: Classification of Hardware Description Languages; in [7]
[7] R. Hartenstein: Hardware Description Languages; Elsevier, Amsterdam, 1987.
[8] . N.: KARL-2 Hardware Description and Simulation Sessions: collection of examples; report, Kaiserslautern, 1984
[9] R. Hartenstein: KARL-2 application notes; CVT report; Univ. Kaiserslautern, 1983
[10] R. Hartenstein, U. Welters: Higher Level Simulation and CHDLs; in (eds.: W. Fichtner, M. Morf): Proc. IFIP Summer School on VLSI Design, Beatenberg, Switzerland, 1986; Kluwer Publishing Co., 1986
[11] R. Bryant: Boolean analysis of MOS circuits; IEEE Trans-CAD 6,4 (July) 1987
[12] J. P. Hayes: Digital Simulation with Multiple Logic Values; IE3 T-CAD 5,2 (Apr.1986)
[13] J. P. Hayes: A unified switching theory with applications to VLSI design; Proc. IEEE, vol. 70 Oct 1982
[14] R. Hartenstein: Einfuehrung in Methoden der Technischen Informatik; to appear: IT Press Verlag, Bruchsal, Germany, 1993
[15] R. Hauck: On Generic Hardware Descriptions; dissertation, Univ. Kaiserslautern, 1992
[16] N. N. KARL-related literature; Fachbereich Informatik, Univ. Kaiserslautern, 1993
[17] M. Sheran: uFP, an algebraic VLSI design language; Ph. D. dissertation, Oxford University, Technical Monograph INF 116 / 964-39, Oxford, UK, 1983
[18] R. Kolla, P. Molitor, H. Osthof: Einfuehrung in den VLSI-.Entwurf; Teubner, 1989
[19] M. Loughazail, M. Côté, M. Aboulhamid, E. Cerny: Experience with the VHDL environment; DAC (Anaheim) 1988


[20] G. Girardi, R. Hartenstein, U. Welters: ABLED: a RT level Schematic Editor and Simulator user Interface; Int`l EUROMICRO Symp.; Brussels, Belgium, 1985.
[21] G. Girardi, R. Hartenstein, U. Welters: KARL (textual) and ABL (graphic) : A User/Designer interface in microelectronics; in (Hrsg.: J. Encarnaçao): CAD-Schnittstellen und Datentransfer-Formate im Elektronik-Bereich; Springer-Verlag, 1986.
[22] G. Girardi: ABL data structure; CVT-report; CSELT, Torino, Italy, March 1984
[23] A. Bonomo, G. Girardi, A. Lecce, L. Maggiulli: GENMON: a specialized ABL editor for design methodology descriptions; 2nd ABAKUS workshop, Igls, Austria, 1988.
[24] U. Welters: ABL2KARL translator: Algorithm description; CVT report, Univ. Kaiserslautern 1984
[25] D. Finkler: PICT-Generator fuer das MLED-System; Univ. Kaiserslautern 1988

KARL Parsers and Simulators.

[26] P. Haselmeier: The KARL language compiler; rep.77-14; Politecnico I Milano, 1977
[27] H. Hedengran: A Parser for KARL-2, internal report; Dept. of Applied Electronics, The Royal Institute of Technology, Stockholm, Sweden, 1980
[28] R. Hartenstein, A. Mavridis: RTcode Instant for KARL-3 (revised edition), report, Fachbereich fuer Informatik, Univ. Kaiserslautern 1986
[29] R. Hauck, A. Hirschbiel: A Physical Model Extension for KARL Simulators; ABAKUS workshop; Passau, 1986.
[30] H. Baessmann, Ph. Besslich Ein Mikroassembler fuer die Register-Transfer-Sprache KARL-2; Bericht No. 1/86; F.B. Elektrotechnik, University of Bremen, 1986
[31] L. Lavagno, R. Manione: SMART, SiMulator At Register Transfer level; report, CSELT, Torino, Italy, 1987.

KARL extensions.

[32] N. N.: Specification of the CVT KARENE System; IMAG, Grenoble, 1984
[33] G. Girardi, A. Zappalorto: An experiment on designing with KARENE; the behavioral level; CVT report, CSELT, Torino, Italy, 1985.
[34] R. Hauck: CVS_BK User Guide, CVT report, Univ. Kaiserslautern, 1988
[35] R. Hartenstein, M. Ryba: Computer Structure Partitioning Schemes; in: (ed.: D. Edwards) Proc. IFIP - TC-10 Conf. on Design Methodologies for VLSI and Computer Architecture, Pisa, Italy, Sept. 19 - 21, 1988; North Holland, Amsterdam, 1988
[36] R. Hartenstein, R. Hauck: Functional Extraction from Personality Matrixes of MOL (Matrix-Oriented Logic) Circuits; IFIP CHDL'87, Amsterdam, 1987
[37] . Oelke: Implementierung der Sprache superKARL; Diplomarbeit, Fachbereich Informatik, University of Kaiserslautern, 1987
[38] R. Hartenstein: Microprogramming Concepts - a Step towards Structured Hardware Design; Micro 7 (1974), ACM New York, 1974.
[39] R. Hartenstein: Increasing Hardware Complexity - A Challenge to Computer Architecture Education; ISCA 1 (1973); ACM, New York 1973.
[40] R. Hartenstein: Hierarchies of Interpreters for Modelling Complex Digital Systems; Proc. GI 3rd Ann. Conf. Hamburg 1973; Springer-Verlag, 1973.I
[41] R. Hartenstein, G. Koch: The Universal Bus Considered Harmful; in: [42].
[42] R. Hartenstein, R. Zaks (eds.): The Microarchitecture of Computer Systems; North Holland Publishing Co./American Elsevier, Amsterdam/New York, 1975.
[43] D. P. Siewiorek, C. G. Bell, A. Newell: Computer Structures: Principles and Examples; McGraw-Hill, New York et al. 1982
[44] R. W. Hartenstein, K. P. Bastian, W. Nebel: VLSI-Algorithmen: innovative Schaltungstechnik statt Software; GME-Tagung Baden-Baden, 1985, VDE-Verlag, Berlin 1985

KARL dialects

[45] F. R. Wagner: KAPA - Uma Linguagem para e Descrição de Hardware no Nivel de Transferencia entre Registrados; Porto Allegre, RGS (Brazil), CPGCC - URGS, April 1987, 40 p., Relatorio de Pesquisa 68 (research rep. no. 68
[46] C. M. Dal Sasso-Freitas, F. R. Wagner, F. M. Oliveira: Especificação do Editor Grafico KAPA; Porto Allegre, RGS (Brazil), CPGCC URGS, April 1987, 62 p., Relatorio de Pesquisa 68 (research rep. no. 62)
[47] S. Marine, G. Girardi, A. Zappalorto: Draft proposal for the final definition of mixing behavior and structure in CVT KARENE system; CVT report; IMAG, Grenoble, France / CSELT, Torino, Italy, 1984
[48] S. Marine: IRENE un Langage pour la description, simulation et synthèse automatique du matériel VLSI; diss., INPG, Grenoble, 1986
[49] . Smit, B. J. F. van Beijnum, S. H. Gerez, R. J. Mukler: Proving Correctness of Digital Designs in the Multidimensional Design Space; in (Ed.: D. Borrione): From HDL descriptions to guaranteed correct circuit designs; North Holland, 1986
[50] G. Carlstedt: A Language for Behavior, Structure, and Geometry; Proc. Euromicro Symp., Venice, Italy, Sept. 1986, Microprogramming and Microprocessing 18, Dec. 1986
[52] P. Prinetto, M. Siviero: Descrizione e simulazione in ART* e KARL II del multiplicatore TRW MPY 24-MJ; Politecnico di Torino, Torino, Italy, 1985
[52] P. Prinetto, M. Siviero: Analisi comparata dei sistemi di simulazione ART* e KARL II; Politecnico di Torino, Torino, Italy, 1985

KARL Applications.

[53] N. N.: The CVT Software Catalogue (extended version); Univ. Kaiserslautern 1986
[54] R. Cecinati, R. Fossati, L. Licciardi, A. Pacchiotti, M. Paolini: The use of KARL-3 in the RIPAC chip design; Proc. 2nd ABAKUS workshop, Innsbruck, Austria, Sept. 1988
[55] G. Roos, E. Bernath, T. Buechner, S. Rust, T. Schwederski: Dedicated VLSI Processors for Image Processing; GME-Conf. on VLSI; Baden-Baden 1991; VDE-Verlag, 1991
[56] G. P. Balboni, V. Vercellone: Experiences in Using KARL-3 in Designing a CMOS Circuit for Packet-Switched Networks; ABAKUS workshop; Passau, Germany, 1986
[57] S. Rust: An experimental system design environment for chip design; Proc. 2nd ABAKUS workshop, Innsbruck, Austria, Sept. 1988
[58] N. Donati, N. Fatini: Experience on CVS_BK use on a signal processor circuit; Proc. 2nd ABAKUS workshop, Innsbruck, Austria, Sept. 1988
[59] A. Butterfield: From KARL to CIF - Automatic Conversion of High-Level RT Descriptions to an Equivalent High-Level Layout Description; internal report, CS Dept., Trinity College, Dublin, Ireland, 1986
[60] D. P. McCarthy: KARL as a Laboratory Instrument in Tertiary Computer Science Courses; internal report, CS Department, Trinity College, Dublin, Ireland 1986

Synthesis from KARL descriptions.

[61] R. Hartenstein, K. Lemmert: A CAD Tool Box around a Hardware Description Language; Proc. Int'l EUROMICRO Symp., Venice, Italy, 1986; North Holland, 1986
[62] K. Lemmert: SYS3 - A systolic synthesis system; dissertation, Kaiserslautern, 1989
[63] L. Lavagno, R. Munione: Automatic Layout Generation from (KARL) RT Level Descriptions; ABAKUS workshop; Passau, 1986
[64] A. Bonomo, M. Italiano, L. Lavagno, M. Maggiulli, M. Melgara, M. Paolini, I. Stamelos: BACH (Behavioral-Level Automated Compilation of Hardware): An Integrated ASIC Synthesis System; Proc. ESPRIT Technical Week, Brussels, Belgium 1988
[65] R. Hartenstein, K. Lemmert: SYS3: A CHDL-based Systolic Synthesis System; Proc. IFIP CHDL'89, Washington, D.C., Elsevier, 1989.
[66] V. G. Moshnyaga, H. Onodera, K. Tamaru, H. Yasuura: A Language for Designing Data-Path Module Generators; IEEE Int’l Design Workshop "Russian Workshop’92", Moscow, Russia; also: IFIP WG 10.5 Workshop on Synthesis, Generation and Portability of Library Blocks for ASIC Design, Grenoble, France, Mar 1992
[67] V. G. Moshnyaga, H. Yasuura: A Language for Designing Module Generators; Proc. SASIMI’92 - Synthesis and Simulation Meeting and Int’l Exchange, Kobe, Japan, 1992
[68] A. Bonomo, M. Italiano, L. Lavagno, L. Maggiuli, M. Melgara, M. Paolini, I. Stamelos: Easily testable data part synthesis in the BACH silicon compiler; Proc. 2nd ABAKUS workshop, Innsbruck, Austria, Sept. 1988
[69] A. Bonomo, G. Bussolino, G. Girardi, M. Italiano: From Structured RT Description to Floor-Plan; report; CSELT, Torino, Italy, 1986 - also: Proc. EUROMICRO Symposium, Portsmouth, UK, 1987; North Holland, Amsterdam, 1986
[70] C. Whiting: The CVS Logic Optimizer; ESPRIT rep; Brit. Telecom, Ipswich, UK, 1986
[71] L. Lavagno, R. Manione: Register Transfer to Layout Synthesis using enhanced Standard / Macro Cell Architecture; internal report; CSELT, Torino, Italy, 1986
[72] G. Arato, R. Manione: PSICO: a System for Automatic Layout Synthesis; report, CSELT, Torino, Italy, 1986.
[73] R. W. Hartenstein, K. Lemmert: A CHDL-Based CAD System for the Synthesis of Systolic Architectures; in (eds.: McCanny, McWhirter, Swartzlander): Systolic Array Processors, Prentice Hall, 1989.


[74] G. Alfs: A Heuristic Search Algorithm for the KARATE System, Diploma Thesis, Kaiserslautern University, 1987
[75] G. Alfs, R. W. Hartenstein, Andrea Wodtko: Explicit Fault Modeling and Hierarchical Test Pattern Generation in the KARATE System, Proc. EuroMicro '89, Koeln 1989
[76] R. Hartentstein, A. Mavridis: RTCode Instant; CVT report, Univ. Kaiserslautern, 1983
[77] P. Liell: Test Pattern Generation for Data Paths using Iterative Arrays of Cells; Ph.D. Dissertation; University of Kaiserslautern, 1983
[78] A. Mavridis: Languages for Simulator Activation and Test Description; in (R. Hartenstein, ed.): Hardware Description Languages; Elsevier Scientific, Amsterdam, 1987
[79] C. Segre, S. Morpurgo: Proposed Algorithm for a Testability Analysis Tool based on KARL; CVT report, Ing. Olivetti S.p.A., Ivrea, Italy, 1984
[80] I. Stamelos, M. Melgara: CVT TIGER: a RT-level Test Pattern Generation and Validation Environment; report, CSELT, Torino, Italy, 1985
[81] S. Morpurgo, C. Segre: Fault Simulation, at Register Transfer Level, of VLSI; Olivetti Research and Technology Review, no. 3, 1985, Ivrea, Italy 1985
[82] I. Stamelos, M. Melgara, M. Paolini, S. Morpurgo, C. Segre: A Multi-Level Test Pattern Generation and Validation Environment; International Test Conference, 1986
[83] S. Morpurgo, A. Hunger, M. Melgara, C. Segre: RTL Validation of VLSI: An Integrated Set of Tools for KARL; IFIP Int'l Symposium on Computer Hardware Description Languages, (CHDL'85); Tokyo, Japan, 1985
[84] M. Melgara, M. Paolini, R. Roncella, S. Morpurgo: CVT-FERT: Automatic generator of analytical faults at RT level from electrical and topological descriptions; Inter- national Test Conference, Philadelphia, USA, 1984.
[85] A. Mavridis: SCIL-3 - A Simulator and Tester Activation Language for VLSI Circuits; Dissertation, Fachbereich Informatik, University of Kaiserslautern, 1987
[86] A. Wodtko: On the Automatic Generation of Test Patterns From Mixed Level Hardware Descriptions; dissertation, Univ. Kaiserslautern, 1990
[87] G. Alfs, R. Hartenstein, A. Wodtko: The KARL/KARATE System - Integrating Functional Test Development into a CAD Environment for VLSI; Proc. ICCD, Port Chester, NY, USA, 1988
[88] R. Hartenstein, M. Ryba: Computer Structure Partitioning Schemes; in: (ed.: D. Edwards) Proceedings IFIP - TC-10 Conference on Design Methodologies for VLSI and Computer Architecture, Pisa, Italy, Sept. 19 - 21, 1988, North Holland,1988
[89] G. Alfs, R. W. Hartenstein, A. Wodtko: The KARL/KARATE system: Automatic Test Pattern Generation Based on RT Level Descriptions; Proceedings of the International Test Conference, Washington DC, USA, 1988.
[90] P. Goel, B. Rosales, PODEM-X: Am Automatic Test Generation System for VLSI Logic Structures, Proc. of the 18th Design Automation Conference, 1981, pp 260-268
[91] P. S. Bottorf, Test Generation and Fault Simulation, in: (ed.: T. W. Williams) VLSI Testing, North Holland, 1986
[92] M. H. Schulz, E. Trischler, T. M. Sarfert, SOCRATES: A Highly Efficient Automatic Test Pattern Generation System, IEEE Trans CAD, 7/ 1, January 1988, pp 126-137

Verification and Extraction

[93] W. Grass, N. Schielow: Verena: A Program for automatic verifications of the register transfer description; IFIP Int`l Symp. CHDL`85; Tokyo, Japan, 1985.
[94] W. Grass, R. Rauscher: A Practicable Strategy for the Verification of Interactive Microprogram Transformations; EUROMICRO’85, Brussels, Belgium; North Holland, 1985.
[95] R. Hartenstein, W. Nebel: Shifting Functional Design Verification Towards RT Level by Automatic Register Transfer Net Extraction; IFIP CHDL'87, Amsterdam, 1987
[96] R. Hartenstein, R. Hauck: Functional Extraction from Personality Matrixes of MOL (Matrix-Oriented Logic) Circuits; IFIP CHDL'87, Amsterdam, 1987
[97] R. Hartenstein, W. Nebel: Functional Design Verification by Register Transfer Net Extraction from Integrated Circuit Layout Data; Proc. IEEE COMP EURO, Hamburg, 1987
[98] H. Salzmann: Implementierung eines Technologie-unabhaengigen Schaltkreis-Extraktors fuer hierarchische Raster-orientierte Layouts; Dipl.-Arb.; Univ. Kaiserslautern, 1987
[99] R. Hartenstein, W. Nebel: Shifting Functional Design Verification Towards RT Level by Automatic Register Transfer Net Extraction; IFIP CHDL'87, Amsterdam, 1987
[100] R. Hartenstein, W. Nebel: Functional Design Verification by Register Transfer Net Extraction from Integrated Circuit Layout Data; Proc. IEEE Comp Euro, Hamburg, 1987
[101] L. Leproni: Exploitation report of the CVS project; CSELT, Torino, Italy, 1990

Survey on KARL-related pages | KARL index (users etc.)



© Copyright 1996, 2001, University of Kaiserslautern, Kaiserslautern, Germany