The behavioral simulation of complex systems, for example, automotive mixedmodeembedded system, requires reliable model implementation. In order to achieve this requirement, we present a systematic development methodology, which is divided in four steps, as follows:
(A)model specification definition,
(B)model design and implementation:
(1)conceptual model definition,
(2)primitive elements definition,
(3)VHDLAMS primitive elements implementation,
(4)primitive elements verification,
(5)VHDLAMS hierarchical model implementation,
(C)tradeoff,
(D)conformance test:
(1)model verification,
(2)model validation.
Figure 3 shows the model development methodology flow chart.
The model accuracy is very important for signal integrity investigation. Simulation speedup is mandatory for simulating complete networks in a reasonable CPU usage time. At last but not least, it is necessary to care about convergence issues. It does not matter how fast and accurate the model is if it is not able to converge in all operating conditions [10]. The proposed development methodology faces these aspects, finding a compromise between them.
The previews steps are detailed in the next subsections.
2.1. Model Specification Definition
The model specification can be divided in two different categories, according to the kind of model that must be implemented:
(i)generic device model,
(ii)real silicon device model.
The generic device model is the model of a generic device, that is, a model that fulfills the protocol specification (e.g., the Controller Area Network protocol (CAN)). It means that the model specification is based on the specifications defined by the protocol, respecting the protocol requirements as operation modes, timing characteristics, electrical parameters as voltages levels, I/O signals characteristics, I/O pins impedances, and so forth. It is also compliant with the functionalities defined in the protocol.
The generic device model can be used as proof of concept for silicon design development, as support tool during the digital block design and verification and it also can be tuned for representing a real silicon device.
On the other hand, the real silicon device model is the model of a real device. In this case, the model specification is based on the device data sheet (that is compliant with the protocol specification).
The real silicon device model can be used for testing and verifying the behavior of the invehicle network topologies.
The model specification should address the following:
(i)the model requirements, for example, bus operating modes, power supplies validity ranges, timings, electrical characteristics, and so forth;
(ii)the model parameterization, for example, typical behavior and corner cases parameters;
(iii)the features, for example, statistic simulation, monitoring system, diagnosis, power consumption estimation, and so forth;
(iv)the model evaluation definition, that is, how the model accuracy must be evaluated.
2.2. Model Design and Implementation
The model design and implementation goes from the conceptual model definition until the code implementation.
2.2.1. Conceptual Model Definition
The conceptual model is defined considering all parameters described in the model specification. It consists of describing how the model requirements are broken down into a collection of components, how the components fit together and interact, and how they work together to meet the specifications. It is a mathematical/logical representation of the problem [11]. Furthermore, each component has to be decomposed until the level of primitive elements, that is, basic circuit cells.
In practical terms, it consists of taking the transceiver and dividing it in a hierarchical way, until the primitive elements level (also called basic cells). The result is a hierarchically composed model. The advantage of the methodology is that the primitive elements can be reused for modelling different subsystems (i.e., reusability) [12].
2.2.2. Primitive Elements Definition
The definition of how the primitives elements are implemented is one of the most important steps of behavioral modelling. It is necessary to pay special attention to the possible discontinuities in the analog domain of the mixedmode circuit, because the discontinuities can cause convergence problems and instability. Therefore, smooth transitions of the analog variables should be used.
The primitive elements contain one or more definitions. Each definition is implemented by an architecture in the VHDLAMS primitive elements implementation (please refer to Section 2.2.3). The behavior of the primitive elements can be described at different abstraction levels. One can use mathematical expressions in a very high level of abstraction, while the other can use a low level of abstraction modeling approach resulting in a description very close to the electronic circuit.
As example of primitive element definition lets us consider the model which represents a MOS transistor. It has three terminals (G, D, S) and the voltage level at the terminals defines the region of operation (cutoff, linear, and saturation). Four different architectures using different abstraction levels were defined and are presented as follows.

(a)
First Definition
The first definition uses a low level of abstraction, considering the physical parameters of a real silicon transistor for modelling the complete behavior of all operation regions. The mathematical expressions are defined as [13]
Cutoff region, :
Linear region, :
Saturation region, :
where is electron mobility, is oxide capacitance per unit area, is channel width, is channel length, is drainsource current, is gatesource voltage, is threshold voltage, and is drainsource voltage.
The result is a description similar to the one used in transistor level simulators, as Spice, for example.

(b)
Second Definition
Using a higher abstraction level, the transistor can be implemented describing each operation region by means of a linear approximation. The result is a piecewise linear model. The behavior of the model is controlled by the voltage between G and S terminals. If is smaller than , the transistor is in cutoff region; otherwise it behaves as follows:
Saturation region, :
Linear region, :
Cutoff region, :
where is saturation current, is output resistance, , and and are model parameters.
In order to avoid a null derivative, a linear current term is added in all operation regions. Therefore, the output current will be
The vi characteristics of the piecewise linear transistor are shown in Figure 4.

(c)
Third Definition
The piecewise linear architecture has two points of firstorder derivative discontinuities: the transition between cutoff and linear regions and the transition between linear and saturation regions. Substituting the piecewise linear equation of the linear region by means of a Taylor series expansion polynomial equation we obtain a smoothed transition between the linear and saturation regions. The model definition is given by
Saturation region, :
Linear region, :
Cutoff region, :
where
Adding the linear current to all operation regions we have
This definition has a DC characteristic closer to the real transistor, increasing the model accuracy, and a smoother transition on point. Figure 5 shows the vi characteristics of the third definition.

(d)
Fourth Definition
The fourth definition makes use of the hyperbolic tangent approximation, which has a natural asymptotic characteristic. Moreover, only two regions must be defined to describe the whole transistor operation, as follows:
Active region, :
Cutoff region, :
where , , and is leakage current.
The output characteristics are shown in Figure 6.
Further information about the primitive cells definition can be found in [10].
The availability of primitive element with more than one definition allows to build higher hierarchies with different performances, which can be used according to the user needs. Please refer to Section 3.
2.2.3. VHDLAMS Primitive Elements Implementation
After defining the mathematical expressions which represent each one of the primitive elements, it is time to convert it to the VHDLAMS language description. A VHDLAMS code file is written for each primitive element/architecture.
2.2.4. Primitive Elements Verification
Before using the primitive element it is necessary to verify if it is correctly implemented. Test cases are generated in order to verify the primitive elements behavior. If the element has more than one architecture, the same test cases are used. All the element architectures must be verified.
If the verification tests are successful, the basic cell is ready to be used. Otherwise, it is necessary to review the primitive element definition.
2.2.5. VHDLAMS Hierarchical Model Implementation
The VHDLAMS hierarchical model implementation is based on the conceptual model definition. Usually the implementation is divided in steps, according to the number of hierarchical levels. Further test cases are generated in order to verify the correct model behavior at the different levels. This procedure improves the model reliability and helps to solve design problems, once undesirable behaviors are detected early at lower hierarchical levels.
2.3. Tradeoff
One of the main difficulties on developing mixedmode behavioral circuits is on finding a tradeoff between speed, accuracy, and convergence. The accuracy is strictly related with the level of abstraction used during the primitive elements implementation. The lower the abstraction level is, the more accurate is the model. Low abstraction levels usually use mathematical equations which require high computational effort. The first important point is on finding a good relationship between accuracy and speed. The second one is related to the convergence issue. Discontinuities between piecewise regions must be avoided as well as null firstorder derivatives. Refer to Section 2.2.2.
The tradeoff between speed, accuracy, and convergence is faced by applying the available architectures implemented in the basic cells. Architectures with different abstraction levels give different performances in terms of accuracy and speed as well as different levels of convergence stability.
The methodology allows implementing different architectures for the same behavioral model, each one presenting different abstraction level, accuracy, speed, and convergence performance. The use of one or other architectures depends on the user requirements. Accurate models are important for signal integrity analysis, while faster models can be used for simulations which focus on, for example, the functionalities verification.
In addition, different architectures can include or not some supported features. It means that, with the same accuracy, the model can be faster if some features are not implemented. Please refer to Section 3.2.
2.4. Conformance Test
The conformance test is divided in two parts: verification and validation. These two concepts are often considered as a single process, but actually there is a distinct focus on each one: verification focuses on the model capability and validation focuses on the model credibility [14].
2.4.1. Model Verification
Verification is the process of determining if the model implementation accurately represents the conceptual description and specifications [14]. It consists of verifying all the model requirements (operating modes, validity ranges, timings, electrical characteristics, etc.), the correct parameterization, and the implementation of the supported features.
The model verification is the main purpose of the conformance test. A set of test cases are defined, in order to fully verify the model. The test cases are independent of each other. For each test case the following must be defined:
(i)the purpose,
(ii)the configuration setup,
(iii)the execution steps,
(iv)the pass/failure criterion.
The pass/failure criterion is defined according to the model specification. Examples are reported in Section 3.
The model robustness is also verified, considering stress conditions during the test cases.
The test cases are basically defined according to the conformance test of the communication protocol, for example, Flexray physical layer conformance test specification [15] for the Flexray communication system.
If the model fails during the verification tests, it is necessary to return to the preview steps. In this case, it is necessary to analyze the failure results to decide where to act. If the model implements wrong behavior, it is necessary to review the conceptual model definition. If the model behaves correctly, but it is not sufficiently accurate, it may be necessary to use another primitive element architecture (tradeoff step). If the simulation does not converge, it is necessary to review the primitive elements definition (see Figure 3).
The model verification must be done for the generic and for the real device models. Examples of model verification are reported in Section 3.1.
2.4.2. Model Validation
Validation process checks if the model accurately represents the real device from the perspective of the intended use of the model [14]. It consists of comparing the model simulation results with the device measurements.
The model validation can be done just for real device models. Refer to Section 3.2.