1 Introduction

To realize a high-quality and high-efficiency design more automated steps should be integrated into the design work-flow. Design automation of the analog part is today one of the bottlenecks in the design of complex circuits. Specifications for analog circuits are mostly written in text with the disadvantage of high degree of freedom for interpretation often leading to misunderstandings. This is also a handicap for exchanging and reusing of analog design intellectual properties (IPs). For example, the specification for LVDSFootnote 1 is described in an IEEE standard [8]. It contains about 20 circuit properties and uses about 32 pages to explain the background for these properties including formulas and schematics. Figure 1 shows one of the simplified LVDS driver testbenches and a driver specification table from the IEEE standard.

Fig. 1
figure 1

LVDS driver testbench and specification from the IEEE standard [8]

Full size image

There are many methodologies for describing specifications with a formal language. Specifications of analog circuits is exceedingly difficult to be described, due to its complex behavior and its various abstraction level and dependent specification properties. Temporal logic [9, 17] and behavioral modeling language [6, 10] are mostly used in existing methodologies and demonstrations for this problem. In fact, there is no accepted formal specification in the analog circuit industry.

The specification description language proposed in this paper should be formal, circuit independent, and machine-readable. It should contain the following information:

  • properties of analog circuits like gain, phase-margin, delay, etc.,

  • ports together with their characteristics,

  • operating parameters and environmental conditions,

  • information about measurement, testbench, and simulation for verification and

  • additional information needed for guiding an (automatic) synthesis process.

According to these requirements XML is selected. The following list shows some advantages offered by XML:

  • simplicity: information in XML is easy to understand, not only for human but also for computer,

  • good extensibility: tags can be created if they are needed. The meta data and their structure are contained in tags,

  • machine-readable: using context information the content coded in XML can be interpreted, evaluated, etc.,

  • openness: XML is a W3C standard, most popular programming languages provide parser or binding tools for it,

  • embeddability: XML documents can contain any possible data type and multiple data formats,

  • separating from presentation: XML describe the content not presentation. Views of the content are easily renderable and easily modifiable.

Therefore we propose an XML specification description format for analog circuits: Analog Specification Description in XML (ASDeX). An ASDeX-file could be used as a starting point in a top-down design flow as well as a final sign-off point after circuit design controlling e.g. characterization and property validation. ASDeX or eventually a striped version of it could also be used as an exchange format for analog IP description in the sense of IP-XACT [7]. A current version of ASDeX could be found at [2]. The rest of this paper is organized as follows. Section 2 provides some related works. Section 3 describes the concept of the ASDeX language and its classification of contents. In Sect. 4, the integration of ASDeX into an automatic validation work-flow based on the Essence Framework and the Meta-Simulator is introduced. Industrial examples and discussion about experimental results are presented in Sect. 5.

2 Related works

The work proposed in [4] is based on the Property Specification Language (PSL) to synthesize gate-level netlists directly from the formulated specifications. In the specification all of the behaviors of the digital circuit are written in PSL. This method makes the specification of digital circuits easier to modify and to read than a manual implementation in a behavioral description language, e.g. VERILOG. An example for a formal PSL specification from [4] is shown in Table 1. It describes a part of the properties of an Advanced High-Performance Bus (AHB). Assumption 3: The lock signal is asserted by a master at the same time as the bus request signal. Guarantee 5: Whenever HREADY is high, the signal HMASTLOCK copies the signal LOCKED.

Table 1 An example for a PSL specification
Full size table

The Signal Temporal Logic (STL) specification based on PSL and MITL [1] proposed in [13, 14] is targeted for specifying properties to be used for lightweight verification. It describes the properties of continuous signals using temporal logic and adopts the interpretation used in PSL. The work proposed in [12] considers more heterogeneous characteristics and develops a mixed-signal assertion language (MSAL). An associated automatic monitoring algorithm is also implemented. In Table 2 an MSAL specification is presented. At first it starts with a precondition which includes three conditions: temperature Temp is over 65 degrees, event e 1 is triggered at the beginning of the next cycle, the two bit vector n 1 n 0 equates (11) at next cycles. The post-condition is fulfilled if the signal frequency f out reaches the frequency 1 GHz three cycles later (X[3]).

Table 2 An example for a MSAL specification
Full size table

A designer-oriented approach to formal analog property specification, the Analog Specification Language (ASL), is introduced in [19] and applied in [18] to model checking in a formal verification flow for analog systems. It describes analog signals as states with time-constrained temporal operators. An example is shown in Table 3. The operator value determines an interval on a state space. The operation assign allows assignment to a numerical value to a variable. transition is an abstract reachability operation and selects states between two disjoint state areas. Assigned values are compared to specified values with the assert statements. All 3 ASL expressions together specify that the start-up time of a charge pump has to be below 3 us.

Table 3 An example for an ASL specification
Full size table

All specification languages described here are developed for assertion-based verification methodologies. Other approaches focus on describing the desired behavior of analog circuits using a behavioral modeling language. In [3] a formal specification based on VHDL-AMS is presented. The component information will be declared in a VHDL-AMS unit (entity). The behavior will be described in an architecture associated to each entity. In [20, 21] the possibility of using SystemC-AMS to specify analog and mixed-signal systems is discussed. The component interface will be declared in a SystemC-AMS module (SCA_MODULE). The behavior will be described in SCA_MODULE using different SystemC-AMS classes. Both, VHDL-AMS and SystemC-AMS, are high level description languages. However both are usually difficult to understand without additional documentation. Additionally it is difficult, sometimes nearly impossible, to write a consistent behavioral model for a complex specification. For example the modeling of the slew-rate and the output limiting of an operational amplifier needs a non linear differential equation, which is difficult to integrate with the differential equation of the transfer function modeling, the bandwidth, and transit frequency.

To provide a compatible IP description for multiple IP vendors or customers, and to enable importing and exporting of complex IP bundles between EDA tools for system-on-chip (SoC) design environments, we need a well-defined description format which directly concentrates on the above defined requirements. IP-XACT [7] provides a standard for the meta specification, and specifies an interface for accessing data in a vendor-independent manner. In [11] industrial IP integration flows based on the IP-XACT standard are demonstrated in various application areas. The IP-XACT standard is published in 1996, obviously makes exchanging and reusing of IPs easier. But until now the support to specifications of analog circuit by IP-XACT is not yet available. Our work takes the first step to reach this goal and to integrate the developed concept into a validation work-flow.

3 Structure of ASDeX

The specification has to collect all relevant information, which is then passed to the design automation processes as reference. Additionally this format should be modular and extensible for the demands of further applications. The utilization of ASDeX in a synthesis flow is shown in Fig. 2. In this paper we focus on the validation process. With the help of XML-Schema-Definition (XSD) [24] we define the structure of ASDeX and present them using an XSD-diagram. In an ASDeX description we formulate the identifier block design, the main block specification, and the four optional blocks internal_connections, function, testbench, and task (see Fig. 3).

Fig. 2
figure 2

ASDeX utilization in synthesis concept

Full size image
Fig. 3
figure 3

Structure of ASDeX

Full size image

3.1 Design block

Four identifier elements are in the design block: vendor, library, name, and version (see Fig. 4). This block could be used as reference keys for other ASDeX-files in hierarchical descriptions.

Fig. 4
figure 4

Structure of design block

Full size image

3.2 Specification block

Obviously, the block specification describes the properties of analog circuits (Fig. 5). It contains one string-block: spec_description, in which additional information is described in text form, and two sub-blocks: ports and properties (see Sects. 3.2.1 and 3.2.2).

Fig. 5
figure 5

Structure of specification block

Full size image

3.2.1 Ports

In this sub-block all of the ports of the design should be defined. In general, each circuit has at least two ports, e.g. input and output. Therefore, the ports definition should contain more than two blocks. Each port (see Fig. 6) has an attribute: either supply or signal. Figures 7a and 7b show the structure of both kinds of port definitions. The supply_mode or signal_mode defines the usage of the port, for example analog or digital, power or ground. The node supply_nature or signal_nature describes the electrical property of the port, for example voltage or current. The domain definition in a supply block would be referenced by use_domain (see Fig. 7b) in the signal block. If a circuit has more than one power supply, domains should be defined to make explicit, which supply domain a signal port belongs to.

Fig. 6
figure 6

Structure of port block

Full size image
Fig. 7
figure 7

Structures of supply and signal blocks

Full size image

3.2.2 Properties

In the properties sub-block we describe two different kinds of specification parameters used for characterizations and synthesis: operating conditions (op_conditions) and properties (property). Two important operating condition entries are e.g. op_supply (see Fig. 8) and op_temperature.

Fig. 8
figure 8

Structure of op_supply block

Full size image

Figure 9 shows the structure of the property block. In the test_port sub-block the ports, which are defined in the ports block, are referenced using the port name. For example in a delay measurement at least two test_port entries are needed for defining a delay path. In the spec_nature sub-block the nature of the property is defined, for example voltage, current, frequency, time, and so on. The target block defines the specified values (target_value) or a curve (target_wave). In target_wave a pwl (piecewise linear) curve pipe could be described using the value_pair (see Fig. 10). The information in measurement describes with which referenced task (use_task) and mathematical descriptions (use_function) as option this property should be measured. As the reference key in the node use_task a task name or the path of an external ASDeX task description could be defined. If a function was referenced, the variables and the parameters should be renamed according to the ports and measure configurations of the circuit. The redefinition of the variables and the parameters, will be described in Sect. 3.5.

Fig. 9
figure 9

Structure of property block

Full size image
Fig. 10
figure 10

Structure of target_wave block

Full size image

3.3 Function block

In the function block (see Fig. 11) a mathematical description can be called as a pre-defined ASDeX description with a ref_mathML_path or described in a MathML [23] format in the sub block mathML. E.g. a function can represent the behavior of an analog output (v_out=gain∗v_in), the logic function of a digital output (A=B+C), a formula which can be used to do a measurement (delay=t_output−t_input) or a pre-defined function call in an existing EDA tool. The names of the objects, which are to be calculated, e.g. a waveform, and the variables, which are defined in the function, e.g. parameters, will be listed. These lists are used for a mapping to the different port names of the in ASDeX described circuits. A default value for the variables could be defined in the variable_default. Each variable could be overridden while referencing of the functions in the property and task block (see Sect. 3.5).

Fig. 11
figure 11

Structure of function block

Full size image

3.4 Testbench block

In the testbench block testbench circuits are provided. In general such circuits would be used for special measurement setups which are not straight forward. Figure 12 shows the structure of the testbench block. In the netlist block there are five kinds of circuit sub-blocks: control, input, output, stimuli, and load. Each of them has an unbounded number of components, which are described by component_type, connected by con_ports, and additionally supplemented by parameter. This testbench description is based on a lightweight spice format.

Fig. 12
figure 12

Structure of testbench block

Full size image

3.5 Task block

In the task block the simulation settings are set up for the automatic validation of a single or groups of circuit properties. Figure 13 shows the structure of the task block. The property_name is a reference to the property which could be measured using the task. The test_path block defines the input and the output for the measurement. The defined ports are referenced by test_in and test_out using the port name. It is possible to define multiple test paths. The entries in the testbench blocks can be referenced using ref_testbench. The simulation_setup block offers the basic parameter settings for different kinds of simulations (e.g. transient analysis). In the ref_function block the mathematical description of the measurement or an external pre-defined function is referenced. The block port_mapping describes the relationships between the objects (object_in_function) in the function and the ports of the circuit. The variables in the pre-defined function could be overridden using the variable_override.

Fig. 13
figure 13

Structure of task block

Full size image

3.6 Hierarchical extension for description of a system

To describe the specification of a complex system a hierarchical extension to ASDeX is available. In a hierarchy all referenced ASDeX descriptions should be connected with each other. An extra block internal_connections is necessary for this purpose (see Fig. 14). All components in the hierarchy must first be listed with either a reference to an ASDeX description (design_id) or a basic_type with parameters. Connections between components are described with the connection block. Connections between components and the interface of the whole hierarchy are described in the interface block.

Fig. 14
figure 14

Structure of internal_connections block

Full size image

3.7 Classification of contents

A simple, not hierarchical ASDeX description is classified in Fig. 15a. The small arrows indicate the referencing relationships. The basic specification description could be referenced by testbenches and tasks, the functions could be referenced by tasks and properties, the testbenches and tasks could also be referenced by properties. In a hierarchy, the ports of each in ASDeX described design could be referenced by internal_connections to build the connections. Each level of the hierarchy has its own internal_connections block referencing the lower level design_id. The other blocks of each hierarchy describe the information only for their own level, comparable to a bottom-up specifying methodologgy.

Fig. 15
figure 15

Content classification

Full size image

4 Validation work-flow based on ASDeX, the Essence Framework and the Meta-Simulator

Figure 16 presents the whole validation work-flow based on the ASDeX description, the Essence FrameworkFootnote 2 and the Meta-Simulator.Footnote 3 The Essence Framework [16, 25] transforms the specification represented by the ASDeX-file into executable task, which validates for example a circuit property. All relevant information for building up a useful testbench, the simulation setup, and result calculation is extracted from the specification (see Sect. 4.2). For transformation templates are needed, which are provided via a template library. The templates contain methods available from the Meta-Simulator software library. The combination of specification data with Meta-Simulator methods enables property extraction based on analog simulation (characterization). For validation, the actual circuit properties have to be compared to the specification requirements. To get all circuit properties, a set of tasks will be generated and executed to run all needed simulations. Additional tasks can be generated to do the validation. The validation can also be part of a characterization task. This depends on the template setup. Key is the automated task generation based on the ASDeX input.

Fig. 16
figure 16

A validation work-flow based on ASDeX, the Essence Framework and the Meta-Simulator

Full size image

4.1 Meta-Simulator

The intention of the Meta-Simulator is to offer the possibility for providing templates which are vendor independent. This has the big advantage to build up a template library which can be used in different design environments and on different computing platforms without any changes. The Meta-Simulator software library is realized in PERL and consists of the three major objects testbench, simulator, and waveform. The methods of the testbench object are responsible for building up the test environment needed for property extraction. A subset of SPICE primitives is available. The analog circuit itself and more complex test configurations are included via netlists using a sub-circuit interface for connection. The simulator object provides methods for simulation control, different kinds of analysis (DC, AC, TRAN at the moment) and for accessing simulation results. Small plug in modules are used for interfacing the most popular commercial available SPICE level simulators. Including a new simulator requires only a new plug in. The waveform object is responsible for the post-processing of the simulation waveforms and provides a comfortable set of methods for waveform operations and measurements. Connected with ASDeX via an Essence Framework conform template all the methods can find the relevant information needed to deliver the required information based on analog simulation (see Fig. 16).

4.2 Task generation with the Essence Framework

A task in this work-flow means an executable PERL module for determining and validating one or more circuit properties. The Essence Framework uses the Mako concept [22], introduced with the PYTHON programming language, for converting templates into executable tasks. At first the ASDeX-file is read via the Essence Import Engine into the Essence Framework (see Fig. 16). Then the Essence Template Engine extracts all relevant information needed from the ASDeX-file to convert the selected template into an executable task, which determines e.g. a circuit property like gain. That means connection of the testbenches, setting up the simulations, and calculating the results is included in the generated task. The programming language used for the templates is independent from the Essence Framework. Only the Mako statements inside the template are evaluated by the Essence Template Engine. With this concept modeling in different languages (e.g. Verilog, VHDL, SystemC) is very easy by providing the appropriate template. Also documentation can be done with this concept. The validation work-flow is a further application. The templates for the validation work-flow are realized in PERL based on the Meta-Simulator software library. A template represents for example a general method for measuring circuit properties. A template can also provide a rule set for validating circuit properties, e.g. using formulas included in the ASDeX function block. The intention is to build up a small powerful template library which covers all characterization and validation needs. Which template to use can be referenced via the ASDeX property block. A simple example is shown in Table 4. A step time is defined in the simulation block of a task block with the value 1e−10, which is needed in the PERL executable task. In the Mako template the value of the <tstep> should be extracted and passed to the target PERL code. In this example, all the simulation settings defined in ASDeX are stored in an object sim_t, therefore the variable ${sim_t.TRAN.tstep.PCDATA} is processed by the Essence Template Engine resulting in the value 1e−10, which is identical with the value in the ASDeX description.

Table 4 A code example for the transformation from ASDeX to the target PERL code
Full size table

5 Industrial examples in ASDeX

The following examples demonstrate the description methodology of ASDeX for commonly used, small industrial analog circuits and the validation work-flow. In the industrial library not only one or two such small circuit designs, but several cells (possibly hundreds) should be automatically validated.

5.1 Low-voltage differential signaling

A low-voltage differential signaling (LVDS) Interface [8] contains a driver and a receiver. In this section we describe an industrial example with a LVDS driver (see Fig. 17). This driver has six ports with a resistor R_Terminal at the differential output. A specification table for the delay is also presented in Fig. 17.

Fig. 17
figure 17

LVDS driver model with a terminal resistor and a delay specification table

Full size image

Due to limited space we do not present the ASDeX examples in a complete XML form, but only with code snippets or pseudo code. In the following pseudo code (see Table 5) we describe the ports of the driver and a property named delay_example, which is shown in Fig. 17. Some generated code based on Meta-Simulator are listed at the right side of the table, also in pseudo code. An expected delay time should be larger than 0.2 ns and smaller than 0.8 ns. To measure the delay property a delayExample task is referenced.

Table 5 Conversion of the ports and the property from ASDeX to PERL
Full size table

In the function block for the delay measurement a mathematical description is defined in MathML using a pre-defined function from the Meta-Simulator library. This description will be used in the delayExample task. Table 6 shows an example about the extraction of data from the MathML through the ref_function block.

Table 6 Conversion of a Delay function from ASDeX to PERL
Full size table

To measure the delay property we need a testbench which is included within the ASDeX testbench block. We present in the following only the stimuli block in the netlist part. The testbench_name Testbench_Delay would be referenced in the task. In the con_port sub-block the name for the connecting port is defined, which is needed for port mapping. A piecewise linear voltage source connects to the input port IN_P of the LVDS driver. The parameter list for the voltage source for the differential inputs is formed by a piecewise linear function.

figure a

In the task description we need to define the path for delay measurement, simulation settings, and references from function and testbench blocks (see Table 7).

Table 7 Task description for the delay measurement
Full size table

5.2 LVDS system

A LVDS system contains several drivers and receivers for a parallel differential signaling [8]. The ASDeX description for such a system contains besides the internal_connections block also design, specification, testbench, function, and task blocks. Figure 18 shows an example structure of ASDeX description for the LVDS system. The predefined ASDeX files for the driver (LVDS_TX) and the receiver (LVDS_RX) are referenced through a design_id by the block internal_connections with a new component_name TX_1..n or RX_1..n. The interface_name are IN_11, IN_12, .. IN_n1, IN_n2, and OUT_1..n, which are defined in the specification block as the ports of this hierarchy.

Fig. 18
figure 18

Structure of an ASDeX description for a LVDS system

Full size image

The Meta-Simulator is not yet able to build a hierarchy automatically. Therefore, we need to build the circuit hierarchy into a black-box with additional tools according to the description in the internal_connections block. This black-box is considered as one circuit to be validated and passed to the Meta-Simulator. The remaining processes are the same as described previously in this paper.

figure b

5.3 ASDeX for an operational amplifier

The OP-amp is a basic block of analog circuits and its specification parameters are well known by designers. Certainly ASDeX can describe the specification of OP-Amps. Due to the limited space in this paper we discuss only a few properties without the measurement sub-blocks for an OP-Amp with five ports.

Gain is a commonly used parameter of an OP-amp. A possible description in ASDeX is as follows:

figure c

A gainExample task describing the measurement of the gain property of the OP-amp reads as follows.

figure d

5.4 Experimental results

5.4.1 Results from Meta-Simulator

Results from analog simulations are available as waveform data. Selection of waveforms and waveform processing is controlled via the used templates selected within tasks block. The task_name entry references the appropriate measurement template. For property calculation the formula referenced via the ref_function entry is used. In the LVDS case we look at delayExample and delayFunc. Figure 19 shows a screen-shot of a waveform resulting from the simulation of the task delayExample. An output log of a validation run for the LVDS example is shown in Fig. 20. Delay_1 is the delay between the ports IN_P and OUT_P. For delay_2 the delay between the ports IN_N and OUT_N is calculated. Both of the delay values are compared to the specification as described in Sect. 5.1. They are in the correct interval.

Fig. 19
figure 19

Waveform of the delay measurement

Full size image
Fig. 20
figure 20

Meta-Simulator based output log for the LVDS Example

Full size image

Figure 21 shows another screen-shot of a Bode diagram after an AC simulation of a task for gain measurement of the OP-amp. The magnitude and phase of the OP-amp output are plotted versus frequency. The result of the gain calculation is shown in Fig. 22. Compared to the gain specification in Sect. 5.3 the design requirement is not met.

Fig. 21
figure 21

Bode diagram of the OP-Amp output

Full size image
Fig. 22
figure 22

Meta-Simulator based output log for the OP-Amp Example

Full size image

5.4.2 A Further Attempt

As we known, a code generation based on the Essence Framework is oriented not only towards PERL in the Meta-Simulator library, but towards any target code. An attempt is started to validate the differential and the integral non-linearity (DNL and INL) of an analog digital converter (ADC) design. In this first attempt the Meta-Simulator as the backend simulation framework is replaced by a GNU Circuit Analysis Package (GNUCAP) [5]. A simple flash converter design (see Fig. 23) is specified at first using ASDeX. In the specification, this flash converter has one input port and four output ports. According to a voltage reference V REF =1.8 V, the step of the Least Significant Bit (LSB) is V LSB_ideal =0.36 V. The DNL could be calculated in Formula (1), where V s is the physical value corresponding to the digital output state. The INL describes the deviation between the actual output and the ideal output of an ADC. The result of the measurement is shown in Fig. 24. In general, the DNL of the ADC should be less than 0.1 LSB, the INL should be less than 0.2 LSB. According to this specification in Fig. 23 the DNL und INL of this circuit are in the correct interval.

$$ \mathit{DNL}=\biggl \vert \frac{V_{s+1}-V_s}{V_{\mathit{LSB}}}\biggr \vert -1 $$
(1)
Fig. 23
figure 23

Design of a flash converter

Full size image
Fig. 24
figure 24

DNL and INL calculation result of the ADC

Full size image

6 Conclusion

In this paper, a new specification description language ASDeX is introduced. It successfully describes the analog properties of two industrial examples and a hierarchical example in ASDeX. With the help of the Essence Framework and the Meta-Simulator an integration into a validation work-flow is demonstrated.

Currently, ASDeX is used in an automatic specification driven validation flow. Further work will focus on the investigation of hierarchical specifications for analog/mixed-signal (AMS) Systems, the extension for handling temporal logic, and the integration into a synthesis design flow, e.g. a topology synthesis method of analog circuits [15].