Co-Simulation/Техническое задание
- Техническое задание
- Описание FT2232H
- Описание FT232H
- (TUMPA) TIAO USB Multi Protocol Adapter
- (TUMPA) Litle
- Описание макета
- Примеры кода
Содержание |
4.4.4 Controlled and uncontrolled time
-Fig-4.5-cclock-and-uclock.png)
Any transactor can instruct the SCE-MI infrastructure to stop the controlled clock and thus cause controlled time to freeze.
- All transactors are told by the SCE-MI infrastructure when the controlled clock is stopped.
- Any transactor shall function correctly if controlled time is stopped due to operations of another transactor, even if the transactor in question does not itself need to stop the clock.
- A transactor might need to stop the controlled clock when performing operations that involve decomposition or composition of transactions arriving from or going to a message channel.
- The DUT is always clocked by one or more controlled clocks which are controlled by one or more transactors.
- A transactor shall sample DUT outputs on valid controlled clock edges. The transactor can use a clock control macro to know when edges occur.
- All transactors are clocked by a free running uncontrolled clock provided by the SCE-MI hardware side infrastructure.
4.5 Work flow
There are four major aspects of work flow involved in constructing system verification with the SCE-MI environment:
- software model compilation
- infrastructure linkage
- hardware model elaboration
- software model construction and binding
4.5.1 Software model compilation
The models to be run on the workstation are compiled using a common C/C++ compiler or they can be obtained from other sources, such as third-party vendors in the form of IP, ISS simulators, etc. The compiled models are linked with the software side of the SCE-MI infrastructure to form an executable program.
4.5.2 Infrastructure linkage
Infrastructure linkage is the process used by in the macro-based use model that reads a user description of the hardware, namely the source or bridge netlist which describes the interconnect between the transactors, the DUT, and the SCE-MI interface components, and compiles that netlist into a form suitable for emulation. Part of this compile process can involve adding additional structure to the bridge netlist that properly interfaces the user-supplied netlist to the SCE-MI infrastructure implementation components. Put more simply, the infrastructure linker is responsible for providing the core of the SCE-MI interface macros on the hardware side. As part of this process, the infrastructure linker also looks at the parameters specified on the instantiated interface macros in the user-supplied bridge netlist and uses them to properly establish the dimensions of the interface, including the:
- number of transactors
- number of input and output channels
- width of each channel
- number of clocks
- clock ratios
- clock duty cycles
Once the final netlist is created, the infrastructure linker can then compile it for the emulation platform and convert it to a form suitable to run on the emulator.
The Infrastructure linkage process is optional as when only the function-based and pipes-based use models are used as this step is provided natively by the interfaces for these two use models.
4.5.3 Hardware model elaboration
The compiled netlist is downloaded to the emulator, elaborated, and prepared for binding to the software.
4.5.4 Software model construction and binding
The software executable compiled and linked in the software compilation phase is now executed, which constructs all the software models in the workstation process image space. Once construction takes place, the software models bind themselves to the message port proxies using special calls provided in the API. Parameters passed to these calls establish a means by which specific message port proxies can rendezvous with its associated message port macro in the hardware. Once this binding occurs, the co-modeling session can proceed.
4.6 Macro-based SCE-MI interface components
The SCE-MI run-time environment consists of a set of interface components on both the hardware side and the software side of the interface, each of which provides a distinct level of functionality. Each side is introduced in this section and detailed later in this document (see Chapter 5).
4.6.1 Hardware side interface components
The interface components presented by the SCE-MI hardware side consist of a small set of macros which provide connection points between the transactors and the SCE-MI infrastructure. These compactly defined and simple-to-use macros fully present all necessary aspects of the interface to the transactors and the DUT. These macros are simply represented as empty Verilog or VHDL models with clearly defined port and parameter interfaces. This is analogous to a software API specification that defines function prototypes of the API calls without showing their implementations.
Briefly stated, the four macros present the following interfaces to the transactors and DUT:
- message input port interface
- message output port interface
- controlled clock and controlled reset generator interface
- uncontrolled clock, uncontrolled reset, and clock control logic interface
4.6.2 Software side interface components
The interface presented by SCE-MI infrastructure to the software side consists of a set of C++ objects and methods which provide the following functionality:
- version discovery
- parameter access
- initialization and shutdown
- message input and output port proxy binding and callback registration
- rendezvous operations with the hardware side
- infrastructure service loop polling function
- message input send function
- message output receive callback dispatching
- message input-ready callback dispatching
- error handling
In addition to the C++ object oriented interface, a set of C API functions is also provided for the benefit of pure C applications.
