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.

Return to the VHDL Page

Last edited 2 Nov 2000

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.

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.