1. Библиотека VITAL
Проектирования систем на основе
программируемой логики
д.т.н. Хаханова И.В, каф.АПВТ, ХНУРЭ
2/22/2011 e-mail: hahanova@mail.ru, 1
2. Цель лекции и содержание
Цель – изучить принципы построения
моделей вентильного и dataflow
уровней
План
1. История и причины создания
2. Структура библиотеки
3. Совместимость моделей Level 0
4. Совместимость моделей Level 1
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 2
ХНУРЭ e-mail: hahanova@mail.ru
3. 1. Создание VITAL(1)
VITAL - VHDL Initiative Towards ASIC Libraries
Идея создания VITAL-библиотек возникла в
1992 г на международном форуме
пользователей VHDL(VHDL International
Users' Forum).
Причины создания:
Пользователям были нужны ASIC библиотеки в их
VHDL-приложениях
Разработчики ASIC нуждались в единой
стандартной ASIC-библиотеке
Разработчики EDA-сред нуждались в средстве
помогающем использовать VHDL для
возрастающего рынка ASIC
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 3
ХНУРЭ e-mail: hahanova@mail.ru
4. 1. Создание VITAL (2)
Стандарт
IEEE P1076.4: Timing Methodology (VITAL)
Разработка VITAL стандарта выполнялась на
основе существующего:
Формат передачи задержек Stantard Delay
File(SDF)
некоторые элементы из пакета Std_Timing группы
VHDL Technology Group, а также специальные
временные и поведенческие техники,
предложенные Rian&Rian(фирма)
существующие ASIC библиотеки
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 4
ХНУРЭ e-mail: hahanova@mail.ru
5. 2 Элементы VITAL (1)
“VITAL-совместимые модели
”(“VITAL compliant models”)
“VITAL-совместимые программы моделирования
”(“VITAL compliant simulators”).
Пять областей стандартизации VITAL:
VITAL_TIMING
• Пакет, содержащий типы данных и подпрограммы для разработки
временных моделей макроячеек.
VITAL_PRIMITIVE
• Пакет определяет множество обычно используемых комбинационных
примитивов.
VITAL_SDFMAP
• Правила преобразования SDF данных в значения VHDL Generic -
констант для VITAL моделей.
VITAL compliant Level 0 Models
• Правила описания интерфейса
VITAL compliant Level 1 Models
• Правила описания архитектуры
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 5
ХНУРЭ e-mail: hahanova@mail.ru
6. VITAL Data Flow
Инструменты
имплементации
Симулятор,
Например,
Active-HDL
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 6
ХНУРЭ e-mail: hahanova@mail.ru
8. 3. Совместимость моделей уровня Level 0
Уровень совместимости моделей Level 0
определяет совместимость моделей на
уровне интерфейса.
Задан способ описания имен портов и generic-
констант, таким образом чтобы можно было
применять back-annotation параметры,
передаваемые через формат Standard-Delay-File
(SDF).
Все порты устройства должны иметь тип
std_lociс_1164: для однобитовых сигналов
использовать тип std_logic, для массивов –
std_logic_vector. Такой же тип должны иметь
все остальные сигналы в проекте.
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 8
ХНУРЭ e-mail: hahanova@mail.ru
9. Типы Generic-параметров для времени
Generic-параметры, используемые для обратной передачи
временных параметров должны быть одного из заданных в
пакете VITAL_Timing типов данных:
TYPE TransitionType is ( tr01, tr10, tr0z, trz1, tr1z, trz0 );
TYPE TransitionArrayType is ARRAY (TransitionType range <>) of TIME;
SUBTYPE DelayTypeXX is TIME;
SUBTYPE DelayType01 is TransitionArrayType (tr01 to tr10);
SUBTYPE DelayType01Z is TransitionArrayType (tr01 to trz0);
TYPE DelayArrayTypeXX is ARRAY (natural range <>) of DelayTypeXX;
TYPE DelayArrayType01 is ARRAY (natural range <>) of DelayType01;
TYPE DelayArrayType01Z is ARRAY (natural range <>) of DelayType01Z;
TYPE TimeArray IS ARRAY ( natural range <> ) OF TIME;
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 9
ХНУРЭ e-mail: hahanova@mail.ru
10. Соглашения по декларации имен generic-констант
Имя константы может иметь одну из следующих форм:
<VITAL_prefix>
<VITAL_prefix>_<port1-name>
<VITAL_prefix>_<port1-name>_<port2name>_<condition>_<edge1>_<edge2>
<VITAL-prefix> ::=
Приставка Описание
tipd Interconnect Path Delay (IPD) Задержка пути межсоединения
tpd propagation delay Задержка распространения
tsetup setup constraint Время установки
thold hold constraint Время хранения
trelease release constraint Время освобождения
trecovery recovery constraint Время восстановления
tperiod period where min or max is not specified Период без указания минимальной и
максимальной величин
tperiod_min minimum period Минимальный период
tperiod_max maximum period Максимальный период
tpw minimum pulsewidth Минимальная ширина импульса
tdevice indicates to which subcomponent the Описывает компонент которому
spec. applies прилагается параметр
tskew indicates to which subcomponent the Описывает компонент которому
spec. applies прилагается параметр
tpulse for path pulse delay для задержки импульса пути
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 10
ХНУРЭ e-mail: hahanova@mail.ru
13. Фрагмент интерфейса для триггера X_FF.2
tpw_CLK_posedge : VitalDelayType := 0.010 ns;
tpw_RST_posedge : VitalDelayType := 0.010 ns;
tpw_SET_posedge : VitalDelayType := 0.010 ns;
tpw_CLK_negedge : VitalDelayType := 0.010 ns;
tipd_I : VitalDelayType01 := (0.000 ns, 0.000 ns);
tipd_CLK : VitalDelayType01 := (0.000 ns, 0.000 ns);
tipd_CE : VitalDelayType01 := (0.000 ns, 0.000 ns);
tipd_RST : VitalDelayType01 := (0.000 ns, 0.000 ns);
tipd_SET : VitalDelayType01 := (0.000 ns, 0.000 ns));
-- synopsys translate_on
port(
O : out STD_ULOGIC;
CE : in STD_ULOGIC;
CLK : in STD_ULOGIC;
I : in STD_ULOGIC;
RST : in STD_ULOGIC;
SET : in STD_ULOGIC);
end component;
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 13
ХНУРЭ e-mail: hahanova@mail.ru
14. Back-Annotation
Backannotation – процесс обновления значений
generic-констант, задающих временные параметры, с
использованием внешней временной информации.
Back-Annotation generic-параметры не могут быть
использованы в ситуации, когда их значения должны быть
известны до начальной фазы инициализации
моделирования.
Back-Annotation generic-параметры могут быть использованы
как реальные значения, ассоциированные с формальными
параметрами подпрограмм, вызываемых из пакета
VITAL_Timing.
Back-Annotation generic-параметры могут быть использованы
для декларации временных констант, имеющих тип
DelayType01Z, которые получают свои значения только из
подпрограммы VitalExtendToFillDelay.
Back-Annotation generic-параметры могут быть связаны с
generic-параметрами копии компонента в структурной
модели.
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 14
ХНУРЭ e-mail: hahanova@mail.ru
15. Архитектура VITAL-совместимой модели
Внешние задержки на входы модели
Описание
функциональности
и временных
параметров
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 15
ХНУРЭ e-mail: hahanova@mail.ru
16. Модель распределенной задержки
Distributed delay – величина задержки между входом
и выходом состоит из задержек отдельных
структурных элементов, находящихся на пути между
двумя контактами
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 16
ХНУРЭ e-mail: hahanova@mail.ru
17. Пример использования распределенной задержки
entity AO2 is
generic (tdevice_A1_Q : DelayType01 := (10 ns, 11 ns); — Device delay for A1
tdevice_A2_Q : DelayType01 := (10 ns, 11 ns); — Device delay for A
tdevice_O1_Q : DelayType01 := (11 ns, 12 ns));— Device delay for O1
port (Y : OUT std_logic; A, B, C, D : IN std_logic);
end;
architecture Level1DistributedDelay of AO2 is
— This attribute indicates that model is VITAL LEVEL1 compliant
attribute VITAL_LEVEL1 of Level1DistributedDelay : architecture is TRUE;
begin
—————————————————————————————-
— This block is used for Distributed delay modelling.
—————————————————————————————-
VITAL_NETLIST : block
SIGNAL A1Out, A2Out : std_logic; — local signals only
begin
— Concurrent procedure calls to VITAL_Primitives
A1: VitalAND2 ( q => A1Out, a => A, b => B,
tpd_a_q => tdevice_A1_Q,
tpd_b_q => tdevice_A1_Q);
A2: VitalAND2 ( q => A2Out, a => C, b => D,
tpd_a_q => tdevice_A2_Q,
tpd_b_q => tdevice_A2_Q);
O2: VitalOR2 ( q => Y, a => A1Out, b => A2Out,
tpd_a_q => tdevice_O1_Q,
tpd_b_q => tdevice_O1_Q);
end block;
end;
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 17
ХНУРЭ e-mail: hahanova@mail.ru
18. Pin-to-Pin delay
Задается задержкой между отдельными контактами
В одной ASIC-ячейке не могут быть применены
одновременно оба способа описания задержек.
Все выполняемые функции
должны быть описаны в
процессе с именем
VitalBehavior, что позволяет
повысить скорость
моделирования.
Никаких других блоков и
процессов не должно быть
использовано в архитектуре.
Метки TimingCheck:,
Functionality: и PathDelay:
должны указывать на первую
линию каждой секции процесса
VitalBehavior, соответственно.
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 18
ХНУРЭ e-mail: hahanova@mail.ru
19. Timing Checks Section
Секция Timing Check состоит из одного оператора if, проверяющего
единственное условие – значение generic-константы TimingChecksOn.
Операторы в конструкции if выполняются, когда TimingChecksOn = TRUE.
Ветвь then оператора if должна содержать только вызов подпрограммы
VITAL_Timing. Ветвь else не разрешена. Приняты следующие дополнительные
парвила:
Каждая проверка временных параметров возвращает значение переменной типа
std_logic, которое должно означать, что нарушение произошло и обнаружено.
Временная проверка не должна управлять ни выходным сигналом, ни каким либо
другим сигналом.
Временная проверка не должна выполнять ни каких действий, кроме вывода внешнего
сообщения об ошибке..
Пример описания секции Timing Check
————————————————————————————
— Timing Checks Section
————————————————————————————
TimingCheck: If (TimingChecksOn) then
— do timing checks on *_ipd signals
— the ‘output’ of this section are violation flags
— one per violation check.
end if;
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 19
ХНУРЭ e-mail: hahanova@mail.ru
20. Functionality Section
Секция Functionality может содержать
один или несколько вызовов подпрограмм из пакета
VITAL_Primitives;
операторы присвоения значений временным (temporary)
переменным.
Пример описания секции Functionality
————————————————————————————
— Functionality Section
———————————————————————————-
Functionality: violation := Tviol_<FirstTest> OR Tviol_<SecondTest>
OR ... Tviol_<LastTest>;
— call to VITAL_Primitives subprogram which determine the
— output with the timing violations considered as an additional
— input parameter
VitalStateTable (
StateTable => DLE24_tab,
DataIn => ( violation, CLK_ipd, CLRZ_CLK_ipd, RL_CLK_ipd),
NumStates => 5,
Result => Results,
PreviousDataIn => PrevData );
Y_zd := To_X01(A_ipd);
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 20
ХНУРЭ e-mail: hahanova@mail.ru
21. Path Delay Selection Section
В этой секции модели обрабатывается задержка пути. Каждый выходной сигнал
должен управляться вызовом процедуры VitalPropagatePathDelay(...). Задачей
подпрограммы VitalPropagatePathDelay(...) – определить соответствующую
задержку, используемую для изменения значений выходного сигнала.
Пример описания секции Path Delay
————————————————————————————
— Pin-to-Pin Delay Section
————————————————————————————
— One call to VitalPropagatePathDelay for each output signal.
PathDelay: VitalPropagatePathDelay(
OutSignal => Q2, — Actual OUTPUT signal
OutSignalName => “Q2”,
OutTemp => Q2_zd, — Zero delayed internal Output signal
— First of two input pins which affect the output Q2
Paths(0).InputChangeTime => Clock_ipd’last_event,
Paths(0).PathDelay => VitalExtendToFillDelay(tpd_clock_q2),
Paths(0).Condition => (RESET = ‘0’),
— Second of two input pins which affect the output Q2
Paths(1).InputChangeTime => Data_ipd’last_event,
Paths(1).PathDelay => VitalExtendToFillDelay(tpd_data_q2),
Paths(1).Condition => (RESET = ‘0’),
GlitchData => GlitchData,
GlitchMode => MessagePlusX,
GlitchKind => OnEvent);
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 21
ХНУРЭ e-mail: hahanova@mail.ru
23. Использование функций примитивов
ARCHITECTURE PinToPinDelay of AndOr IS
attribute VITAL_LEVEL1 of PinToPinDelay: architecture is TRUE;
BEGIN
VitalBehavior: PROCESS (A, B, C, D)
VARIABLE AND1_Out, AND2_Out, Q_Zd: std_ulogic;
VARIABLE GlitchData_Q: VitalGlitchDataType;
BEGIN
-- Functionality section
AND1_Out:= VitalAND2 ( A, B );
AND2_Out:= VitalAND2 ( C, D );
Q_zd:= VitalOR2 (AND1_Out, AND2_Out, ResultMap => DefaultECLMap);
-- Path delay section
VitalPathDelay01 (OutSignal => Q, OutSignalName => 'Q', OutTemp => Q_zd,
Paths => ( 0 => (InputChangeTime => A’last_event,
PathDelay => tpd_A_Q, PathCondition => TRUE),
1 => (InputChangeTime => B’last_event,
PathDelay => tpd_B_Q, PathCondition => TRUE),
2 => (InputChangeTime => C’last_event,
PathDelay => tpd_C_Q, PathCondition => TRUE),
3 => (InputChangeTime => D’last_event,
PathDelay => tpd_D_Q, PathCondition => TRUE)),
GlitchData => GlitchData_Q, DefaultDelay => VitalZeroDelay01,
Mode => OnDetect, XoN => TRUE, MsgOn => TRUE,
MsgSeverity => WARNING);
END PROCESS;
END;
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 23
ХНУРЭ e-mail: hahanova@mail.ru
24. Логические примитивы
ARCHITECTURE DistributedDelay OF AndOr IS
attribute VITAL_LEVEL1 of DistributedDelay: architecture IS TRUE;
signal AND1_Out, AND2_Out: std_ulogic;
BEGIN
I1: VitalAND2 (AND1_Out, A, B, tdevice_I1_Q, tdevice_I1_Q);
I2: VitalAND2 (AND2_Out, C, D, tdevice_I2_Q, tdevice_I2_Q);
I3: VitalOR2 (Q, AND1_Out, AND2_Out,
tdevice_I3_Q, tdevice_I3_Q);
END;
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 24
ХНУРЭ e-mail: hahanova@mail.ru
25. Таблица символов VITAL
type VitalTableSymbolType is (
'/', -- 0 -> 1
'', -- 1 -> 0
'P', -- Union of '/' and '^' (any edge to 1)
'N', -- Union of '' and 'v' (any edge to 0)
'r', -- 0 -> X
'f', -- 1 -> X
'p', -- Union of '/' and 'r' (any edge from 0)
'n', -- Union of '' and 'f' (any edge from 1)
'R', -- Union of '^' and 'p' (any possible rising edge)
'F', -- Union of 'v' and 'n' (any possible falling edge)
'^', -- X -> 1
'v', -- X -> 0
'E', -- Union of 'v' and '^' (any edge from ФXХ)
'A', -- Union of 'r' and '^' (rising edge to or from 'X')
'D', -- Union of 'f' and 'v' (falling edge to or from 'X')
'*', -- Union of 'R' and 'F' (any edge)
'X', -- Unknown level
'0', -- low level
'1', -- high level
'-', -- don't care
'B', -- 0 or 1
'Z', -- High Impedance
'S' -- steady value
);
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 25
ХНУРЭ e-mail: hahanova@mail.ru
26. Структура таблицы истинности
Truth Table
DataIn
Map to X01
Section
Output
Result
Map to X01Z
Таблица истинности дешифратора 2 в 4
Constant DecoderTable: VitalTruthTableType(0 to 3, 0 to 5) :=
-- Input Pattern Response
-- D1 D0 Q3 Q2 Q1 Q0
(( '0', '0', '0', '0', '0', '1'),
( '0', '1', '0', '0', '1', '0'),
( '1', '0', '0', '1', '0', '0'),
( '1', '1', '1', '0', '0', '0'));
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 26
ХНУРЭ e-mail: hahanova@mail.ru
27. Структура таблицы состояний
Таблица состояний D-триггера
с синхронизацией по переднему фронту
Constant DFFTable: VitalStateTableType :=
--RESET D CLK State Q
(('0', '-', '-', '-', '0'),
('1', '1', '/', '-', '1'),
('1', '0', '/', '-', '0'),
('1', 'X', '/', '-', 'X'),
('1', '-', '-', '-', 'S'));
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 27
ХНУРЭ e-mail: hahanova@mail.ru
28. Преимущества VITAL моделей(1)
Для ASIC разработчиков:
Улучшение переносимости проектов между различными EDA
проектами.
Повышение скорости моделирования без выхода из среды
VHDL проекта (в 10-15 раз)
Возможность использования стандартных VITAL-
подпрограмм для пользовательских моделей.
Для поставщиков полупроводниковой продукции:
Единые библиотеки, поддерживаемые всеми основными
средами моделирования EDA.
Точная поддержка временных параметров для
субмикронной продукции.
Сокращение стоимости разработки и эксплуатации
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 28
ХНУРЭ e-mail: hahanova@mail.ru
29. Преимущества VITAL моделей(2)
Для разработчиков EDA:
Концентрация на создании инструментов и проектов, а не
библиотек.
Стандартные методы создания моделей позволяют повысить
оптимизацию и сократит сложность проекта
Для проектировщиков микросхем и систем:
Отдельные VITAL-подпрограммы доступны всем пользователем.
Стандартизация пакетов гарантирует одинаковое поведение на
различных инструментах и платформах
VITAL-примитивы позволяют упростить создание VHDL-моделей
Подпрограммы управления VITAL pin-to-pin задержкой позволяют
легко добавить временные параметры в поведенческую модель
Временная проверка VITAL может быть использована для поиска
ошибок функционирования проекта.
Использование SDF back-annotation может быть необязательным,
допускается внесение всех временных параметров в модель
Множество смешанных пользовательских моделей имеет “Level0”
Пользовательские модели “Level 1” будут обрабатываться в 10-15
раз
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 29
ХНУРЭ e-mail: hahanova@mail.ru
30. Выводы
1 Click to add Title
2 Click to add Title
3 Click to add Title
4 Click to add Title
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 30
ХНУРЭ e-mail: hahanova@mail.ru
31. Контрольные вопросы и задания
1. В программе ISEWebPack создать проект и модель триггера
или счетчика (что больше нравится), или взять готовую.
2. Выполнить синтез и имплементацию полученного устройства.
3. На этапе Place&Route сгенерировать vhdl-модель для
анализа временных параметров и sdf-файл.
4. Открыть vhdl-файл, лучше в Active-HDL. Проанализировать из
каких компонентов состоит модель устройства после
имплементации. Как реализована функциональность, как
временные параметры.
5. В какой библиотеке находятся компоненты, составляющие
модель? Найти их реализацию в данной библиотеки.
6. Проанализировать код компонента. Определить является ли
он совместимым по level0 или level1. Какие generic-константы
он имеет. Как реализована функциональность. Где
вычисляются задержки.
7. Оформить свои выводы, можно на листике от руки, можно
печать.
За все 5 баллов.
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 31
ХНУРЭ e-mail: hahanova@mail.ru
32. Контрольные вопросы и задания
1. Причины создания стандарта IEEE Std
1076 –Vital?
2. Пять областей стандартизации VITAL?
3. Объяснить принципы совместимости
модели Level0 и Level1.
4. Что такое SDF, где используется?
5. Как реализуется и где применяется
Vital Data Flow?
2/22/2011 д.т.н. Хаханова И.В, каф.АПВТ, 32
ХНУРЭ e-mail: hahanova@mail.ru
