a metamodel and model-based design rule checking dsl ......automation (eda) software suite kicad 1....

A Metamodel and Model-based Design Rule Checking DSL forVerification and Validation of Electronic Circuit Designs

Adrian Rumpold and Bernhard BauerInstitute of Computer Science, University of Augsburg, Germany

Keywords: Domain-specific Modeling, Model-based Analysis, Model-based Testing and Validation, SystemsEngineering, Electronic Design Automation, Design Rule Checking.

Abstract: Development of embedded systems depends on both software and hardware design activities. Qualitymanagement of development artifacts is of crucial importance for the overall function and safety of the finalproduct. This paper introduces a metamodel and model-based approach and accompanying domain-specificlanguage for validation of electronic circuit designs. The solution does not depend on any particularelectronic design automation (EDA) software, instead we propose a workflow that is integrated into a modular,general-purpose model analysis framework. The paper illustrates both the underlying concepts as well aspossible application scenarios for the developed validation domain-specific language, MBDRC (Model-BasedDesign Rule Checking). It also discusses fields for further research and transfer of the initial results.

1 INTRODUCTION

Embedded hardware and computing have becomepervasive aspects of modern technology, whichwe encounter under a variety of different names:cyber-physical systems, embedded systems, smartdevices, and not least the Internet of Things.While different in their concrete use cases andimplementation, they all share a common underlyingconcept, the close connection between software andhardware aspects. Their design and developmentactivities differ, but ultimately both need to beactively quality managed in order to attain a sufficientlevel of quality. This quality may be expressed interms of freedom from errors, but may also refer toaspects such as reliability, dependability, and safety,depending on the application domain.

Hardware design, and the design of electroniccircuits in particular, differs significantly from theactivities in a software development process, sinceit touches on both the abstract design of electroniccircuits as well as their physical embodiment in theform of printed-circuit boards (PCB), assemblies,and higher integration levels. Nonetheless, bothdomains rely on tool support to identify mistakesby the developer, enforce design rules, or validatecertain properties of the system under development.Electronic design automation (EDA) tools commonlyinclude such functionality, but only offer it as part

of a manual workflow within the software package— mostly only available as non free, proprietarysoftware with the risk of vendor lock-in.

This paper proposes a model-based solution tothe challenge of automatic validation of electronicdesign rules, outside of a particular EDA tool suite.As a prerequisite, we introduce an Ecore-basedmetamodel for electronic circuits and illustratethe transformation from industry-standard textualdescription formats into this model representation.Based on this modeling approach, we then introduceMBDRC, a textual domain-specific language fordescription of design rules for electronic circuitsrepresented as instances of the EDA metamodel,demonstrate its applicability and describe furtherresearch opportunities.

A caveat: Similar approaches are also found –using similar terminology – in the domain of VLSI(very large scale integration) design of integratedcircuits on the silicon level – however, this paperis not aimed at these applications but rather acomponent-level view of embedded hardware.

Outline

Section 2 discusses related work, regarding boththe domain of electronic design automation andthe metamodeling and analysis approaches shownin this paper. We introduce a metamodel for

Rumpold A. and Bauer B.A Metamodel and Model-based Design Rule Checking DSL for Verification and Validation of Electronic Circuit Designs.DOI: 10.5220/0007381303170324In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 7th International Conference on Model-Driven Engineering andSoftware Development), pages 315-322ISBN: 978-989-758-358-2Copyright c© 7th International Conference on Model-Driven Engineering and Software Development by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

315

electronic circuits based on the KiCad open-sourceEDA software in section 3. Based on thismodeling approach, we develop MBDRC, a textualdomain-specific language and an associated analysisworkflow for validation of electronic design rulesin section 4. This section also demonstrates theapplicability of our proposed approach in two realisticuse cases. Section 5 summarizes the key results of thispaper and suggests starting points for further researchbeyond these initial efforts.

2 RELATED WORK

Metamodeling

The de-facto standard for simulation of electricalcircuits is the SPICE tool (Nagel, 1975; Quarleset al., 1993). SPICE uses a textual format fordescription of circuits on a component level, theirelectrical connections, and simulation parameters.The structural description forms a netlist, whichlists instances of components, their terminals or pins(external connection points), and nets (the electricalconnections between these terminals). A similarnetlist format lies at the heart of our metamodel usedfor circuit description, introduced in section 3.

Although it focuses on a chip-level view, thework by Fischbach et al. (2014) proposes an abstract,highly generic metamodel for netlists, also looselybased on the SPICE format.

In the automotive domain, the AUTOSARstandard (Automotive Open System Architecture)provides a metamodel specification for thedescription of ECU (electronic control unit)hardware resources (AUTOSAR, 2017). Usingthis metamodel, electronic components commonlyfound in the automotive field can be describedon a hardware element level, with pins and pingroups forming their connection. While the standardallows for hierarchical nesting of hardware elements,the metamodel is not well suited for capturingcomponent-level design models of hardwareassemblies. Rather, it addresses a higher levelof abstraction, and as such can be regarded more of acomplement to the metamodel proposed in this work,rather than a substitute.

Previous effort has been directed atstandardization of a common format for exchangeof electronic designs, leading to the creation of theElectronic Design Interchange Format (EDIF, seeIEC 61690-2:2000). This interchange format mostlycovers lower-level aspects of VLSI design (verylarge scale integration). As such, it is not suited

well for describing circuits on a component level.Nonetheless, its modeling approaches for schematicscan also be applied in the context of this paper.

Electrical and Design Rule Checking

While current research in electrical engineering hasshifted towards low-level validation of integratedcircuit designs, related academic literature exists thatapplies to the checking of electrical and design ruleson a circuit level:

Pelz (1992) proposes a general set-basedinterpreted approach for design-rule anddesign-for-testability checking, which transformsnetlists (specified in the common SPICE format) intoan equivalent abstract set representation. Validationsare subsequently performed by interpretation of adomain-specific language over this set representation.Their work is primarily focused on VLSI design,nevertheless it serves as a fundamental example of theuse of domain-specific languages for the validationof EDA designs. The approach provides sufficientexpressiveness, however it requires significant mentaleffort for construction and validation of the actualvalidation scripts.

Furthermore, commercial EDA software packagesinclude a variety of built-in design rules, on which thispaper draws to derive realistic application scenariosfor the developed validation language.

Model Analysis

Rumpold et al. (2017); Pröll et al. (2018) havepreviously introduced a conceptual and toolingframework for complex model-based analyses withapplications across various domains. They describea modular architecture based on domain-specificmodeling languages and associated analyses, whichcan be combined into arbitrary analysis workflows.We expand upon this framework in this paper, byadding support for models from the EDA domain andimplementing an accompanying analysis wrapper forthe MBDRC validation language.

3 A METAMODEL FORELECTRONIC CIRCUITS

In this section, we describe a metamodel thatallows capturing information about the structure ofelectronic circuits, metadata associated with them, aswell as a facility for modeling libraries of electronicparts used during circuit design.

MODELSWARD 7th International Conference on Model-Driven Engineering and Software Development - 7th International Conference onModel-Driven Engineering and Software Development

316

Figure 1: Terminology for common schematic elements.

3.1 Motivation and Foundations

Our metamodel closely follows the representationused by the popular open-source electronic designautomation (EDA) software suite KiCad1. Chapters11 and 15 of the official Eeschema (the schematiclayout component of KiCad) documentation describethe generation of netlists and the file format usedby KiCad in greater detail (Charras and Tappero,2018). The reasons for choosing this format as thebasis for the EDA metamodel are twofold: First,the free and open-source nature of the KiCad toolsuite ensures that the schematic capture software isuniversally available. Secondly, the format combinestwo concepts that benefit from a close connection,the modeling of the actual schematic as well as theabstract parts underlying the design. Similar textualrepresentations exist for virtually all EDA softwarepackages, the OrCAD Capture User Guide includes acomprehensive overview (Cadence Design Systems,2016, ch. 20).

Conceptually, a schematic of an electronic circuitdenotes the component symbols for the parts ofthe circuit and electrical connections between them.These connections between components form thebasis for netlists, which list all nets formed byelectrically connected parts (or their connectionpoints, such as pins or pads on an integrated circuit).Figure 1 illustrates how these concepts relate to thegraphical representation of circuit diagrams. Fromthis structural description of electronic circuits theEMF metamodel for netlists shown in fig. 2 wasderived.

EDA tools frequently include a library of commoncomponents, including their schematic symbols andinformation about physical properties such as pinassignments and their package. These libraries canalso be extended by the designer, to accommodate forspecific parts not available in the generic library.

Figure 3 shows our metamodel for suchcomponent libraries. Parts are grouped insideuniquely identified libraries and carry information

1http://www.kicad-pcb.org

Figure 2: Metamodel for netlists.

Figure 3: Metamodel for electronic component partlibraries.

about their physical package and pin assignment, aswell as textual fields stored as key-value pairs.

These key-value pairs can convey arbitraryadditional information about a part or a specificcomponent instance in a circuit, such as manufacturerpart numbers, links to supplementary documentation,or simulation models and parameters.

The EDA metamodel has been defined asan instance of the EMF Ecore meta-metamodel.An accompanying parser allows to directly loadfile-based netlist representations as created by theKiCad software. This parser transforms the textualnetlist into a proper instance of the EDA metamodel,which can be supplied as an input to the analysisframework introduced in the next section.

3.2 Description of Metamodel Elements

Part. A template element that abstractly describesa single electronic part and its basic properties(name and description, as well as alternativenames [aliases]).

A Metamodel and Model-based Design Rule Checking DSL for Verification and Validation of Electronic Circuit Designs

317

Library In order to improve usability, EDA toolscommonly group related parts into libraries, e.g.by function or manufacturer.

Footprint. In order to produce a printed circuitboard (PCB) from a schematic, all componentsneed to be assigned a footprint, which describesthe physical packaging of the part. Since a singlepart may be offered in a variety of packages by itsmanufacturer, a single Part model element canbe associated with multiple Footprint elementinstances, whereas only a single footprint ispermitted for a concrete component in a circuit.

Pin. A single external connection point for a part,identified by its ordinal number with respect to thefootprint of the part. A pin is further characterizedby its mode of operation, e.g. output, input,or power supply pins of a part. Each partmay contain any number of pins, although mostelectrical components contain at least two pins(notable exceptions are e.g. test points used forquality assurance and debugging purposes, whichonly contain a single connection point).

Field. Both library parts as well as componentscan carry arbitrary metadata in the form ofkey-value pairs, which may be used to conveyadditional information about the underlyingcircuit element (such as documentation referencesor procurement information).

Netlists. The collection of all nets in a circuit.

Net. An electric connection between one or morenodes. Nets are identified by a numeric code andmay be assigned a unique name. In a hierarchicalschematic, nets may also be designated as local,i.e. not visible outside the current hierarchy level.

Node. A node is the point where a single pin of acomponent makes connection with a net.

Component. A concrete instance of a library parton a circuit diagram. A component is identifiedby its reference designator on the schematic,usually comprised of a single-letter prefix and anumeric counter (e.g. C12 for a capacitor; seeIEEE Std 315-1975 for comprehensive reference).Components are assigned a value, which furthercharacterizes the component (e.g. the resistanceor capacitance values for passive elements, or theconcrete part name for a library part with multiplealiases). A unique timestamp allows to accuratelymatch components, even when their designatorchanges, e.g. when the schematic is formatted in adifferent layout and designators are re-numbered.

3.3 Use Cases

The EDA metamodel described in this sectionforms the basis for the MBDRC validation languageintroduced below. However, other use cases besidescircuit validation are possible, for example:

BOM Generation. Since the netlist model containsinformation about all components in a circuit, as wellas additional metadata, a bill of materials (BOM) canbe generated from it. The BOM lists all parts in acircuit, their designators, values, as well as additionalprocurement and/or assembly information. Identicalparts can be grouped together to improve readabilityand conserve space.

The generation of a BOM is one example for theclass of model-to-text (M2T) transformations that ispossible using the EDA model as input.

Model Versioning. Given a representation of anelectronic circuit as a model at different points intime, analysis of the evolution of the system over timein a semantic manner becomes possible (see Selic(2003, p. 23)). A persistent storage of these modelsallows to compare circuits between arbitrary revisionsbased on changes in the model elements, similar toapproaches already found in the software modelingdomain.

Furthermore, these snapshots can serve asbaselines, from which different design variantscan be derived; for example to evaluate differentimplementation options. Since our metamodelfollows the Ecore meta-metamodel and is basedon the set of Eclipse EMF technologies, modelversioning approaches could be easily constructedusing the EMF Compare2 feature (see also Brun andPierantonio, 2008).

4 MBDRC — A DSL FORMODEL-BASED DESIGN RULECHECKING

4.1 Foundations

This section introduces a textual domain-specificlanguage – MBDRC – for validation of electroniccircuits based on the metamodel described above. Itsname stems from the design rule checking (DRC)activities that form an integral part of the design ofelectronic circuits. Conventionally, such checks are

2https://www.eclipse.org/emf/compare


318

directly integrated into EDA tool packages, with littleroom for customization or secondary use outside thedesign tool.

We propose to separate the validation of designrules from the actual EDA tool used to designthe system. This split enables use cases beyondthe classical support of circuit designers in theirdaily work: For example, a standalone designvalidation can provide automated quality assessmentsof electronic designs in a similar fashion tostate-of-the-art software engineering practice in thefield of Continuous Integration. Analysis resultscan be visualized as part of a product qualitydashboard, enabling a high-level overview of asystem’s development progress.

Furthermore, a stand-alone validation approachbased on open technologies can help to alleviatethe effects of vendor lock-in caused by the use ofproprietary software solutions.

4.2 Language Definition and Elements

The MBDRC language is a textual domain-specificlanguage defined using the Eclipse Xtext languageengineering toolkit.3 It utilizes the EDA metamodelfrom the previous section to express rules used toassess the validity of a given electrical circuit design.

Overall Structure. As the top-level entity, anMBDRC script file may contain an arbitrary numberof named rules. These rules provide a semanticgrouping for validation expressions, against which agiven netlist should be validated.

Validation expressions comprise a number offirst-order logic expressions over the elements andattributes of the EDA metamodel introduced in theprevious section.

Validation Expressions. Rules are composed ofone or multiple quantified first-order predicates,denoted by the forall and exists keywords inthe MBDRC language (corresponding to the ∀ and∃ quantifiers). If a rule contains more than onequantifier, the overall rule is considered the logicalconjunction of these quantified expressions.

Every quantified expression may reference anarbitrary number of target variables, which will bebound during evaluation by the interpreter. The listof target variables immediately follows the quantifierkeyword (see the following section for concreteexamples of the syntax). Each variable is associatedwith a type, either component, pin, or net, and must have

3https://www.eclipse.org/Xtext

a unique identifier. These variable definitions arecollected in the sets C,N,P or components, pins, andnets for each quantified expression.

Individual quantified expressions are evaluated bybinding the quantified variables to all combinationsof components, nets, and pins of the netlist. Allconstraints in the quantified expression are thenevaluated using this valuation; if multiple constraintsare specified, the overall result is obtained as theirlogical conjunction.

The actual constraints are propositional logicformulae (using ∨,∧,→,¬), with support for equalityand inequality comparisons (<,>,≤,≥,=, 6=), aswell as property expressions on target variables,function calls, and array types.

Validation expressions can be scoped to onlyspecific subsets of a netlist by specifying a whereexpression. During evaluation, only variableassignments that fulfill the scoping condition will befurther validated against the rule body. By selectingappropriate scope conditions, the rule body can besimplified in order to improve readability and ruleevaluation performance. Besides this main functionof narrowing the scope for the rule body, the whereclause also allows for a traversal of model structure,in a similar fashion to joins in SQL. This feature isfurther described in the next subsection.

Type Checking. Expressions in the MBDRClanguage are strongly typed and continuously typechecked during the development of the script insidethe editor as well as during the interpretation of thescript.

The language supports both primitive types(boolean, integers, strings), complex types (as definedby the EDA metamodel), as well as sets of these.

Function expressions are statically typed, i.e. theirparameter and return values types must be known atdesign time. Overloads of different return types arenot currently supported in the DSL.

4.3 Rule Script Execution

The MBDRC domain-specific language forms thebasis for an automated validation of a given netlistagainst a set of design rules. While in theorythe analysis could be performed inside standalonevalidation tool, we envision its use in a more complexworkflow. Therefore, the MBDRC analysis has beenintegrated into the model-based analysis frameworkpreviously described in Rumpold et al. (2017); Pröllet al. (2018). The addition of the EDA metamodelproposed in the previous section adds a new modelingdomain to the set of domain specific modeling


319

Figure 4: Execution workflow for an MBDRC analysis.

languages already included in the base framework(see Rumpold et al. (2017, fig. 1) for details).

The MBDRC analysis is available as one analysisunit along the execution graph to be processed by theanalysis framework. It depends on a previous loaderstep, which transforms the textual representation ofthe input netlist into a proper domain model, andproduces one or multiple analysis result objects.These describe the success or failure of each MBDRCrule that was validated, including detailed informationabout rule violations. Figure 4 illustrates the flow ofinformation and dependencies between the steps ofMBDRC validation.

The results can then be further processed,depending on the use case for the analysis: Inan interactive setting, it might be desirable tohighlight each circuit element that violates anydesign rules to aid the designer in fixing theseproblems. If the analysis is used to producea quality report document, a more coarse-grainedlisting of all passed or failed design rules canbe generated, omitting information about individualcomponent-level elements. Generating such reportscan be delegated to downstream model-to-text stepsin the execution flow, to promote a proper separationof concerns between analysis modules.

4.4 Application Examples

The following section aims to illustrate thecapabilities of the MBDRC language by applyingit to two common tasks found in the EDA designprocess.

This selection of examples in this paper is byno means exhaustive, but rather seeks to provide anoverview of the language elements and their possibleapplications.

Validation of Documentation and ManufacturingInformation

Besides the structural information, the EDAmetamodel introduced in the previous section alsoallows to attach metadata to each component in a

circuit, or to the underlying library part, in the formof arbitrary key-value fields.

One use case for this information is to verify theavailability of parts from a distributor and monitorthe life cycle status of critical components as part ofobsolescence management (see IEC 62402:2007 as anexample for a relevant international standard).

The following MBDRC code snippet enforces thateach component must be annotated with a distributoror manufacturer part number, unless it is activelymarked as not being a critical part for the BOM (billof materials):

Listing 1: MBDRC code for validation of procurementmetadata.

rule BOMValidation {forall (component c) {

// Every component must declare its// manufacturer/distributor part numberconstraint c.bom_critical != "no" ->

(c.distr_no != "" || c.manf_no != "");}

}

Listing 1 illustrates the basic structure of anMBDRC script: Each validation rule, identifiedby an arbitrary name, may contain one or morequantified expressions to specify the target modelelements. Each quantified validation expressiondefines constraints to be verified against matchingelements from the netlist model under test. Bothblock and single-line comments may be added tothe script in a syntax familiar from the C or Javaprogramming languages.

Electrical Rules Checking

As a more comprehensive demonstration of thecapabilities of the MBDRC language, this exampleshows the implementation of simple electric ruleschecks as a composite MBDRC rule. These checksare commonly found in EDA tools to prevent logicalerrors during design of an electronic circuit and serveto validate the design during the schematic capturephase of the product life-cycle.

ERC rules for example guarantee that no twopower sources are directly connected, or thatcomponents are not shorted out (which effectivelyrenders them useless in the circuit, since they arebypassed). Most commercial EDA packages includea variant of this check; fig. 5 depicts the configurationof the pin compatibility matrix in the KiCad ERCchecker as one representative example.

Listing 2 shows the implementation of a subset ofthese checks in the MBDRC language. The exampledemonstrates some of the more advanced features ofthe DSL:


320

• Multiple quantified expressions can be combinedto form composite rules. The overall ruleevaluation result is formed by taking the logicalconjunction of each quantified expression in therule.

• where (p1.net == p2.net): Scope filters canselectively apply constraints to model elementsmatching a filter expression. Complex propertyexpressions (references to other model elements;in this example the net associated to a single pin)allow for comfortable model traversal similar tojoins in relational databases.

• p2.mode in ["output", "power_out", "3state"]: Thelanguage supports sets of primitive types andmembership testing for element properties, as asyntactical shorthand to improve readability.

• card(p.nets) <= 1: Function expressions allowcomputation of values from model properties(the example determines the number of nets apin is connected to as the cardinality of theset). The set of available functions is currentlyfixed, future research may add the possibilityof declaring additional functions as part of theMBDRC language.

• not exists: In order to improve readability, theresult of quantified expressions may be negated.This does not change the expressiveness of thelanguage, since the negation might also be pushedinside the expression (compare first-order logic:¬∃x.P(x)⇔∀x.¬P(x))

• severity=info and message "Pin mode unspecified": Rulesmay specify a custom level of severity (info,warning, error) as well as a informative messageto be displayed to the user, if the rule is found tobe violated during evaluation.

Figure 5: ERC pin compatibility validation rules providedby KiCad.

Listing 2: MBDRC code for validation of electricalconnection rules.

rule ERC_PinTypes {// Connected pins must have compatible modesforall (pin p1, pin p2) where (p1.net == p2.net) {constraint p1.mode == "power_out" ->

!(p2.mode in ["output", "power_out", "3state"]);constraint p1.mode == "output" -> p2.mode != "output";constraint p1.mode in ["openCol", "openEm"] ->

!(p2.mode in ["output", "power_out"]);}

// Pins marked as ’do not connect ’ must not be// attached to any other net in the schematicforall (pin p, net n) where (n == p.net) {

constraint p.mode == "NotConnected" -> card(n) <= 1;}

// Warn for unspecified pin modesnot exists (pin p) severity=warn {

message "Pin mode unspecified";constraint p.mode == "unspc";

}}

5 CONCLUSION

This paper has introduced two key results: First,we have proposed a general-purpose metamodel forelectronic circuits derived from an industry-standardnetlist representation. The metamodel allowscapturing structural information about electroniccircuits, as well as metadata and library informationabout the parts used in these circuits.

Subsequently, we have described a textualdomain-specific language for the analysis andvalidation of circuits represented as instances ofthis metamodel. Several application examplesdemonstrate the language features as well as theDSL’s suitability as a complement to the validationfunctionality found in common EDA tools.

We foresee that our approach can supplementthe established design workflow for electroniccircuits, by uncoupling the checking of design andelectrical rules from any concrete EDA softwaresuite. This additional freedom allows for easier toolinteroperability and enables new use cases for theseanalyses.

Future Work

Based on our preliminary research introduced in thiswork, we envision a number of possible scenariosfor further research, expanding the scope bothtowards more abstract system-level views, as well assub-circuit level design activities.

Generation of Validation Code. The firstprototype of the MBDRC DSL uses a separate


321

parser to validate the rules defined in an MBDRCscript against a concrete netlist. This approachfacilitates the rapid co-evolution of the languagesyntax and its associated semantics, but does notfully utilize the power of the model-based approach.Instead, validation code for a given set of rules canbe generated directly. The set of technologies forimplementation of the first prototype of the DSL waschosen with this extension in mind: Xtext offers richsupport for generating Java (among other languages)code from a DSL script (see Bettini, 2016, ch. 5).

Physical Layout Validation. While the currentimplementation of the MBDRC language is based onthe metamodel for the abstract circuit representationembodied by netlists, the same concepts hold forthe validation of physical circuit layouts. Here, thevalidation focuses on the positioning and electricalconnections between components on a printedcircuit board (PCB). Common questions during PCBdesign revolve around minimum clearance betweenadjacent tracks on the board, physical dimensions ofcomponents, or violations of manufacturing processcapabilities (e.g. minimum drill sizes for holes orminimum track widths that can be manufactured).

The EDA metamodel can be extended to alsoinclude the physical positioning of components ona printed circuit board, the tracks that correspond tonets, as well as the physical dimensions of the boardand the components to be placed on it. By addingappropriate mathematical operations to the MBDRClanguage, it can then be used to answer these physicaldesign questions.

Test Plan Generation. Our last suggestion forfurther research focuses on the test of hardwarecomponents. Based on the model representation,as well as higher-level descriptions of requirementsand associated test goals, we envision a strategy forplanning of testing activities: By establishing a modellink between requirements, test goals, as well as theactual components under test in a single integratedmodel, test cases may be derived that fulfill these testgoals. One example might be the goal of verifyingthe correct function of fault tolerance mechanisms bymeans of fault injection. The circuit model providesthe necessary information about the available signalsas well as potentially affected components, while thetraceability of the model allows to identify affectedsoftware components. The integrated view on boththese domains allows for a clearer picture of thedependencies between components, as well as thenecessary development steps in order to achievecertain test goals.

REFERENCES

AUTOSAR (2017). Specification of ECU ResourceTemplate. Specification 060.

Bettini, L. (2016). Implementing Domain-SpecificLanguages with Xtext and Xtend. Packt Publishing,Birmingham, Mumbai, 2nd edition.

Brun, C. and Pierantonio, A. (2008). Model Differencesin the Eclipse Modelling Framework. CEPISUPGRADE, IX(2):29–34.

Cadence Design Systems (2016). OrCAD Capture UserGuide. Technical Documentation.

Charras, J.-P. and Tappero, F. (2018). EeschemaReference Manual. http://docs.kicad-pcb.org/master/en/eeschema.html.

Fischbach, R., Heinig, A., and Schneider, P. (2014).Design rule check and layout versus schematic for3D integration and advanced packaging. In 2014International 3D Systems Integration Conference(3DIC), pages 1–7, Kinsdale, Ireland. IEEE.

IEC 61690-2:2000 (2000). Electronic design interchangeformat (EDIF) - Part 2: Version 4 0 0. InternationalStandard IEC 61690-2:2000, InternationalElectrotechnical Commission, Geneva, CH.

IEC 62402:2007 (2007). Obsolescence management- Application guide. International StandardIEC 62402:2007, International ElectrotechnicalCommission, Geneva, CH.

IEEE Std 315-1975 (1975). Graphic Symbols for Electricaland Electronics Diagrams. Standard 315-1975,Institute of Electrical and Electronics Engineers.

Nagel, L. W. (1975). SPICE2: A Computer Programto Simulate Semiconductor Circuits. PhD Thesis,EECS Department, University of California, Berkeley,Berkeley, CA, USA.

Pelz, G. (1992). An interpreter for general netlist designrule checking. In Design Automation Conference,1992. Proceedings., 29th ACM/IEEE, pages 305–310.IEEE Comput. Soc. Press.

Pröll, R., Rumpold, A., and Bauer, B. (2018).Applying Integrated Domain-Specific Modelingfor Multi-concerns Development of ComplexSystems. In Pires, L. F., Hammoudi, S., and Selic,B., editors, Model-Driven Engineering and SoftwareDevelopment, pages 247–271. Springer InternationalPublishing.

Quarles, T., Newton, A. R., Pederson, D. O., andSangiovanni-Vincentelli, A. (1993). SPICE3 Version3f3 User’s Manual. Department of ElectricalEngineering and Computer Science, University ofCalifornia. Berkeley, CA.

Rumpold, A., Pröll, R., and Bauer, B. (2017).A Domain-aware Framework for IntegratedModel-based System Analysis and Design. In5th International Conference on Model-DrivenEngineering and Software Development, pages157–168. SciTePress.

Selic, B. (2003). The pragmatics of model-drivendevelopment. IEEE Software, 20(5):19–25.


322

a metamodel and model-based design rule checking dsl ......automation (eda) software suite kicad 1....

Documents