Co-Simulation/Техническое задание

Ссылки сюда (13) →

Co-Simulation

• Техническое задание
• Описание FT2232H
• Описание FT232H
• (TUMPA) TIAO USB Multi Protocol Adapter
• (TUMPA) Litle
  • Компиляция и запуск в QuestaSim
• Описание макета
• Примеры кода

---

Литература

• Литература

---

• Словарь терминов
• Дневник
• История проекта
• Схема эмулятора
• Схема эмулятора на примере
• Схема эмулятора

* PSL * VHDL * OS-VVM *

Исходные данные

Исходными данными являются:

• Программная часть
  • HDL модель, состоящая из двух частей
    • модуль верхнего уровня (тестбенч).
      • Разрешенные языки: VHDL [, Verilog, SystemVerilog, SystemC ?]
    • и входящий в него модуль (port map), который будет реализован в аппаратном ускорителе.
      • Разрешенные языки: VHDL, Verilog (то, что поддерживается синтезатором)
  • Софт для синтеза и имплементации (размещения и загрузки) в ПЛИС HDL-модели.
  • ModelSim/QuestaSim — программа моделирования программ на языке VHDL/SystemC
  • Специальное ПО (для автоматизации эмуляции) - то что нужно разработать

• Входные параметры
  • число внутренних связей, выводимых на временные диаграммы

• Аппаратная часть
  • ПЛИС
  • Кабель для программирования ПЛИС
  • кабель для коммуникации между аппаратной и программной частью эмулятора
    • USB
    • COM (RS232) ?

Аппаратная инфраструктура эмулятора

Эмулятор включает программную часть, выполняемую на ПК и, подключённую к нему по стандартному интерфейсу USB (COM), аппаратную часть.

Для программирования FPGA может потребоваться отличный от USB (COM) интерфейс.

Блок схема инфраструктуры

В ПЛИС размещаются следующие компоненты:

• модуль верхнего уровня (имя entity - hes_top, файлы hes_top_e.vhd и hes_top_a.vhd), включающий:
  • приёмник
  • передатчик
  • блок основной схемы
  • блок формирования общего сброса
  • блок формирования общего синхросигнала
  • блок формирования управляемого синхросигнала
  • драйвер -
  • монитор -
  • кодер -
  • декодер -

Пример

Исходное описание

1) Имеется исходное описание тесбенча, включающего блок DUT (entity и architecture), работу которого планируется эмулировать (моделировать) аппаратно в ПЛИС.

Рисунок 1 — Исходное описание (edit)

2) Для блока DUT необходимо выделить:

• число входов. Также нужно определить тип сигналов, всего предполагается 4 группы:
  • цифровые сигналы, от изменения которых не меняется состояние выходов (11 входов: DI[7:0], INC/DEC, EN, LOAD);
  • синхросигнал с активным положительным фронтом (1 вход: CLK);
  • синхросигнал с активным отрицательным фронтом (нет);
  • асинхронный сигнал, изменение которого приводит к изменению выходов, при этом в отличии от синхросигнала активным уровнем может являться 0 или 1 (или оба этих состояния) (1 вход: RST).
• число выходов (8 выходов: DO[7:0])
• число внутренних сигналов, которые необходимо вывести для просмотра на временных диаграммах (4 сигнала: INT_SIG[3:0])

Следует зафиксировать порядок следования всех сигналов.

Как действовать если активных сигналов несколько (синхросигналов и асинхронных сигналов)?

Могут ли меняться 2 активных сигнала одновременно? Как это будет реализовано в ПЛИС?

Ограничение: в DUT не может быть кольцевого генератора, т.е. выходы не должны изменяться независимо от изменения входов

Модифицированное описание

3) В исходном описании тестбенча интерфейс (entity) блока DUT остаётся неизменным, а архитектура блока DUT заменяется.

Рисунок 2 — Модифицированное описание тестбенча (edit)

Алгоритм работы нового блока DUT следующий:

1. Установка начального значения на входах в аппаратном эмуляторе (вызов соответствующей функции)
2. Ожидается изменение активных сигналов (синхросигналы или асинхронные сигналы)
3. При изменении активного сигнала запоминается состояние всех входов и фиксируется активный сигнал, т.е. на каком активном сигнале произошло событие.
4. Происходит вызов функции, которая посылает команды и данные аппаратному эмулятору. Т.е. отсылает состояние входов и вид события (где оно произошло) и ожидает ответ (вызывается соответствующая функция) - изменённое состояние всех выходов и внутренних сигналов.
5. Происходит приём данных от эмулятора о новом состоянии всех выходов и внутренних сигналов, после чего они назначаются соответствующим выходам и внутренним сигналам.
6. Переход к ожидаю события (пункт 2)

Описание интерфейса функций отправления и приёма данных

Аппаратная часть эмулятора

4) Алгоритм работы аппаратного эмулятора:

1. Ожидание приёма команды и данных
2. Приём данных - состояния входов блока DUT и событие на активном сигнале
3. Установка полученных значений на входах блока DUT
4. Запуск события на активном сигнале
5. Сохранение значений выходов и внутренних сигналов блока DUT
6. Передача на ПК значений выходов и внутренних сигналов.

Структура компонентов в ПЛИС

Рисунок 3 — Структура компонентов в ПЛИС (edit)

Рисунок 3b — Структура компонентов в ПЛИС (edit)

Рисунок 3c — Структура компонентов в ПЛИС c RS232 (edit)

Временные диаграммы работы эмулятора

Рисунок 4 — Временные диаграммы работы эмулятора ([edit])

Описание содержания полей в сообщениях

(Редактировать)

Как это будет...

4.4.4 Controlled and uncontrolled time

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 Маршрут

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

Существуют четыре основных этапа маршрута эмуляции, участвующих в построении системы верификации с SCE-MI окружением:

• компиляция программной модели
• создание инфраструктуры
• обработка аппаратной модели
• построение программной модели

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.

5.2.4 SceMiClockPort macro

The SceMiClockPort macro supplies a controlled clock to the DUT. The SceMiClockPort macro is parameterized so each instance of a SceMiClockPort fully specifies a controlled clock of a given frequency, phase shift, and duty cycle. The SceMiClockPort macro also supplies a controlled reset whose duration is the specified number of cycles of the cclock.

Figure 5.5 shows the symbol for the SceMiClockPort macro, as well as Verilog and VHDL source code for the empty macro wrappers.

VHDL Macro Wrapper:

entity SceMiClockPort is
  generic(ClockNum         : natural := 1;
          RatioNumerator   : natural := 1;
          RatioDenominator : natural := 1;
          DutyHi           : natural := 0;
          DutyLo           : natural := 100;
          Phase            : natural := 0;
          ResetCycles      : natural := 8);
  port(Cclock : out std_logic;
       Creset : out std_logic);
end;
 
architecture EmptyMacro of SceMiClockPort is
begin
end;

Figure 5.5 SceMiClockPort macro

All of the clock parameters have default values. In simpler systems where only one controlled clock is needed, exactly one instance of a SceMiClockPort can be instantiated at the top level with no parameters specified. This results in a single controlled clock with a ratio of 1/1, a don’t care duty cycle (see 5.2.4.3), and a phase shift of 0. Ideally, this clock’s frequency matches that of the uclock during cycles in which it is enabled. The SCE-MI infrastructure always implicitly creates a controlled clock with a 1/1 ratio, which is the highest frequency controlled clock in the system. Whether or not it is visible to the user’s design depends on whether a SceMiClockPort with a 1/1 ratio and a don’t care duty cycle is explicitly declared (instantiated).

In more complex systems that require multiple clocks, a SceMiClockPort instance needs to be created for each required clock. The clock ratio in the instantiation parameters always specifies the frequency of the clock as a ratio relative to the fastest controlled clock in the system (whose ratio is always 1/1).

For example, if a cclock is defined with a ratio of 4/1 this is interpreted as, “for every 4 edges of the 1/1 cclock there is only 1 edge of this cclock”. This defines a “divide-by-four” clock. It is sometimes necessary to establish a timebase which is associated with the fastest clock (the 1/1 clock) in the system. An implementation should provide a mechanism by which this can be done.

5.2.4.1 Parameters and signals

ClockNum=1

This parameter assigns a unique number to a clock which is used to differentiate it from other SceMiClockPort instances. It shall be an error (by the infrastructure linker) if more than one SceMiClockPort instances share the same ClockNum. The default ClockNum is 1.

RatioNumerator=1, RatioDenominator=1

These parameters constitute the numerator and denominator, respectively, of this clock’s ratio. The numerator always designates the number of cycles of the fastest controlled clock that occur during the number of cycles of “this” clock specified in the denominator. For example, RatioNumerator=5 and RatioDenominator=2 specifies a 5/2 clock, which means for every five cycles of the 1/1 clock that occur, only two cycles of this clock occur. The default clock ratio is 1/1. For more information refer to section 5.2.4.

DutyHi=0, DutyLo=100, Phase=0

The duty cycle is expressed with arbitrary integers which are normalized to their sum, such that the sum of DutyHi and DutyLo represent the number of units for a whole cycle of the clock. For example, when DutyHi=75 and DutyLo=25, the high time of the clock is 75 out of 100 units or 75% of the period. Similarly, the low time would be 25% of the period. The phase shift is expressed in the same units; if Phase=30, the clock is shifted by 30% of its period before the first low to high transition occurs. The default duty cycle shown in the macro wrappers within Figure 5.6 is a don’t care duty cycle of 0/100 (see 5.2.4.3).

ResetCycles=8

This parameter specifies how many cycles of this controlled clock shall occur before the controlled reset transitions from its initial value of 1 back to 0.

ClockName

The clock port’s name is derived from its instance label.

Cclock

This is the controlled clock signal the SCE-MI infrastructure supplies to the DUT. This clock’s characteristics are derived from the parameters specified on instantiation of this macro.

Creset

This is the controlled reset signal the SCE-MI infrastructure supplies to the DUT.

5.2.4.2 Deriving clock ratios from frequencies

Another way to specify clock ratios is enter them directly as frequencies, all normalized to the clock with the highest frequency. To specify ratios this way requires the following.

Make each ratio numerator equal to the highest frequency.

Use consistent units for all ratios.

Omit those units and simply state them as integers.

For example, suppose a system has 100Mhz, 25Mhz, and 10Mhz, 7.5 Mhz, and 32kHz clocks. To specify the ratios, the frequencies can be directly entered as integers, using kHz as the unit (but omitting it!):

100000 / 100000 - the fastest clock
100000 / 25000
100000 / 10000
100000 / 7500
100000 / 32

Users who like to think in frequencies rather than ratios can use this simple technique.

Note: An implementor of the SCE-MI macro-based interface may wish to provide a tool to assist in deriving clock ratios from frequencies. Such a tool could allow a user to enter clock specifications in terms of frequencies and then generate a set of equivalent ratios. In addition, this tool could be used to post process waveforms (such as .vcd files) generated by the simulation so the defined clocks appear in the waveform display to be the exact same frequencies given by the user.

5.2.4.3 Don’t care duty cycle

The default duty cycle shown within the macro wrappers in Figure 5.6 is a don’t care duty cycle. Users can specify they only care about posedges of the cclock and do not care where the negedge falls. This is known as a posedge active don’t care duty cycle. In such a case, the DutyHi is given as a 0. The DutyLo can be given as an arbitrary number of units, such that the Phase offset can still be expressed as a percentage of the whole period (i.e., DutyHi+DutyLo).

For example, this combination:

DutyHi=0, DutyLo=100, Phase=30

means the following:

a) I don’t care about the duty cycle. Specifically, I don’t care where the negedge of the clock falls.

b) If the total period is expressed as 100 units (0+100), the phase should be shifted by 30 of those units. This represents a phase shift of 30%.

Another example:

DutyHi=3, DutyLo=1, Phase=2

means:

a) I care about both intervals of the duty cycle. The duty cycle is 75%/25%.

b) The phase shift is 50% of period (expressed as 3+1 units).

It is also possible to have a negedge active don’t care duty cycle. In this case, the DutyLo parameter is given as a 0 and the DutyHi is given as a positive number (> 0).

For example:

DutyHi=1, DutyLo=0, Phase=0

means:

a) I don’t care about the duty cycle. Specifically, I don’t care where the posedge of a clock falls.

b) The phase shift is 0.

In any clock specification, it shall be an error if Phase >= DutyHi + DutyLo.

Note: The intent of the don't care duty cycle is to relax the requirement that each edge of a controlled clock must coincide with a rising edge of uclock. A controlled clock with a posedge active don't care duty cycle, i.e., with DutyHi given as 0, is not required to have its falling edge coincide with a rising edge of uclock. Similarly, a controlled clock with a negedge active don't care duty cycle, i.e., with DutyLo given as 0, is not required to have its rising edge coincide with a rising edge of uclock. Hence, the don't care duty cycle enables controlled clocks to be the same frequency of the uclock. Conversely, the maximum possible frequency of a non-don't care duty cycle controlled clock is 1/2 the frequency of the uclock. Since the implicit 1/1 controlled clock is specified to have posedge active don't care duty cycle, it may be as fast as uclock.