Microelectronics

VHDL models for Board-level Simulation: Source code examples

This page contains the VHDL source code examples described in the document VHDL Models for Board-level Simulation. The document provides recommendations for development and usage of VHDL models intended for Board-level simulation. All models for Board-level simulation delivered to ESA should be developed in accordance with VHDL Modelling Guidelines.

Board-level simulation can be defined as simulating the functionality of one or several printed circuit boards built with standard components, possibly incorporating Application Specific Integrated Circuits, ASIC, and Application Specific Standard Products, ASSP. Board-level simulation is also known under the names rapid or virtual prototyping and sometimes system simulation. The purpose of Board-level simulation is to verify the behaviour of the board design.

The complete example directory containing the VHDL code example has been tared and compressed for convenient retrieval.


Predefined packages used for models intended for board-level simulation

The following packages are predefined and should be located their corresponding VHDL libraries.
* ESA.Simulation
In this package the enumerated type SimConditionType is defined, to be used to select Worst, Typical or Best Case values for timing parameters in VHDL models for Board-level simulation.
* ESA.Timing
This package defines three array types, indexed by the SimConditionType, needed for timing generics when using Vital Delay Types. The types are intended to be used in VHDL models for Board-level simulation.

The two packages above should not be modified or moved to a different library. The packages are also located in the esa_lib.html file.

* IEEE.Vital_Timing Package Header
* IEEE.Vital_Timing Package Body
This package defines standard types, attributes, constants, functions and procedures for use in developing ASIC models. Specifically a set of subprograms for timing checking are defined.
* IEEE.Vital_Primitives Package Header
* IEEE.Vital_Primitives Package Body
This package defines standard types, constants, functions and procedures for use in developing ASIC models. Specifically a set of logic primitives are defined.

Model for board-level simulation

A model for board-level simulation is characterised by its accurate modelling of the component behaviour, simulation performance, and ease of use for board designers.

Hierarchy for models for board-level simulation is introduced to obtain good source code readability and to separate different modelling aspects. The outlined hierarchy scheme below is based on two of these aspects, namely timing and functionality. Since these usually stem from two different lines of documentation and representation, the Data Sheet and the Component model, the model should be partitioned taking this into account. A partitioning also enables separate verification of the two domains of the model.

The example below shows how a model for board-level simulation of a Bit Modulator has been implemented. Only parts of the model have been completed, but should be sufficient to present the modelling ideas. The following design units are located in the library BitMode_Lib, and are contained in the file bitmod_lib.html:

* BitMod_Timing
The timing parameters should be defined as deferred constants in a separate package, allowing the values to be changed by only re-analysing the package body.
* BitMod (BoardLevel)
The timing checking in the model should be contained in the BoardLevel architecture, including setup and hold time checking, clock-to-output and propagation delay scheduling.
* BitMod_Configuration
Configuration specifications in the architecture should be avoided, allowing the usage of the more flexible configuration declarations outside the models.
* BitMod_Definition
This package defines conversion functions used for the BitMod design which are not contained in the IEEE Std_Logic_1164 package.
* BitMod_Core (Behavioural)
The functionality of the device should be modelled in the functional core, and be independent of timing. There should not be more entities comprising the functional core than there are blocks in the architectural block diagram.


Verification of models for board-level simulation

Model verification is performed to ensure that the model fulfils its requirements, both on functionality and timing.

The following design units are located in the library BitMod_TB_Lib, and are contained in the file bitmod_tb_lib.html:

* MISR_Definition
This package defines the MISR subprogram used by the Test Generator for the verification of the Bit Modulator.
* TestDefinition
Since several functions are normally used in more than one architecture of the test generator, sub-programs could be declared in a separate package or in the declarative part of the entity.
* TestGenerator
The test generator should generate stimuli and acquire response data for comparison with the expected results in order to verify the behaviour of the test object. The test generator could have more than one architecture, implementing different test suites verifying different functions. An architecture of a test generator should include processes that generate the test suite, evaluate test results, generate list files, perform output data compression etc.

For complete verification, all external objects should be modelled in the test generator, e.g. protocol machines, bus interfaces etc. allowing for generation of non-nominal stimuli such as inducing incorrect or corrupted accesses, error injection etc., which is normally only possible when having full controllability and observability.

* TestGenerator (Functional)
This test suite will test the full functionality of the model, except the mode when Built In Self Test, BIST, is activated. The activation of the BIST would preclude the test suite to be evaluated using fault simulation. The BIST is tested in the architecture X_Handling.
* TestGenerator (X_Handling)
This test suite will test the following: all inputs will be applied all nine Std_Logic values; all checkers for unknown values on inputs; the handling of each unknown input value will be checked; the propagation of each unknown input value will be checked.
* TestGenerator (Timing)
This test suite will test all timing constraint checkers (both with and without timing violations). The test suite can be executed for different simulation conditions using the SimCondition generic declared in the entity.
* TestBench (Structural)
The test bench contains the model to be verified and a test generator.
* FunctionalTest
Configuration declaration selecting the functional test suite and deactivates the timing checkers of the Bit Modulator.
* X_HandlingTest
Configuration declaration selecting the test suite for verification of the checker for unknown inputs and the BIST mode.
* WorstCaseTest
Configuration declaration selecting the timing test under Worst Case simulation conditions.
* TypCaseTest
Configuration declaration selecting the timing test under Typical Case simulation conditions.
* BestCaseTest
Configuration declaration selecting the timing test under Best Case simulation conditions.


Board designs

The interfaces of a board design should follow the same requirements as previously suggested for models intended for board-level simulation. All timing parameters, such as clock-to-output and propagation delays, which are affected by the interconnection between the board design and other equipment, should have a corresponding timing generic with a default value declared as a deferred constant in a separate timing package.

Two approaches are presented: the architecture containing the timing information of the board, and the architecture only containing the connectivity and a separate configuration declaration containing the timing.

The following design units are located in the library BoardDesign_Lib, and are contained in the file boarddesign_lib.html:

* BoardDesign_Timing
In this package, all timing parameters for the Board Design are defined as deferred constants; their value can be modified by re-analysing only the package body.
* BoardDesign
This is an example of a simple board with three serially connected Bit Modulators.
* Configured
This architecture contains information on connectivity and timing related information. Selection of entity/architecture for the BitModulator is made here.
* Unconfigured
This architecture only contains information on connectivity, no timing related information or selection of entity/architecture is made here. That is deferred to a configuration declaration.
* BoardDesign_Configuration
Configures the board with the explicit timing of the design. If other timing is needed, a new configuration could be derived. The generics SimCondition and TimingChecksOn are propagated down the hierarchy.


Verification of board designs

A test bench should be developed for the board design analogous to the test bench for a model intended for board-level simulation. A test generator with one or multiple architectures with test suites should be instantiated together with the board design in the test bench architecture. Selection of simulation conditions and test suites should be done by using configuration declarations with the same names as have been defined for the verification of models intended for board-level simulation: WorstCaseTest, TypCaseTest and BestCaseTest.

The following design units are located in the library BoardDesign_TB_Lib, and are contained in the file boarddesign_tb_lib.html:

* TestGenerator
* TestGenerator (Timing)
This test suite will test all timing constraint checkers (both with and without timing violations). The test suite can be executed for different simulation conditions using the SimCondition generic in the entity.
* TestBench (Structural)
The test bench connects the test object and the test generator.
* WorstCaseTest
Configuration declaration selecting the timing test under Worst Case simulation conditions.
* TypCaseTest
Configuration declaration selecting the timing test under Typical Case simulation conditions.
* BestCaseTest
Configuration declaration selecting the timing test under Best Case simulation conditions.


Home Return to the VHDL Page

Sandi Alexander Habinc (sandi@ws.estec.esa.nl)

Last edited 3 September 1996


DISCLAIMER

All information is provided "as is", there is no warranty that the information is correct or suitable for any purpose, neither implicit nor explicit.

This information does not necessarily reflect the policy of the European Space Agency.


COPYRIGHT 1996 EUROPEAN SPACE AGENCY. ALL RIGHTS RESERVED.

This article may be redistributed provided that the article and this notice remain intact. This article may not under any circumstances be resold or redistributed for compensation of any kind without prior written permission from European Space Agency.