36. Программы. Этапы моделирования систем в SV.

Системная спецификация
➢Реализуется технической маркетинговой группой
▪ Системная архитектура – Проектирование сверху вниз
➢Н бе ольшая высококвалифицированная группа инженеров.
▪ Блоковый уровень – Плоский стиль (Flat Design Style)
➢Несколько инженерных команд, работающих параллельно
▪ Интеграция – Проектирование снизу вверх
▪ Системная верификация – Симуляция, эмуляция и прототипирование
▪ Завершение проекта – Физические & временные параметры
▪ Выпуск продукции – Производство & Маркетинг
 Тут ссылка на лекцию, там намного конкретнее по каждому пункту. (оставил это на
выбор отвечающего)

37. Блок синхронизации. Описание событий через блок синхронизации.

// единственное что нашел в лекциях
Триггеры с синхронизацией по фронту.
Модель D-триггера, управляемая передним фронтом представлена листингом 11.13. а), результат синтеза – рис. 11.15
а). В интерфейс устройства включает следующие порты: С – вход синхронизации, D – вход данных, Q – выход данных.
Следующая модель (листинг 11.13 б), рис. 11.15 б)) представляет устройство с синхронизацией по заднему фронту и
использованием сигнала асинхронного сброса CLR.
Последние две модели иллюстрируют применение синхронной установки S (листинг 11.13 в), рис. 11.15 в)) и сигнала
разрешения синхронизации CE (листинг 11.13 б), рис. 11.15 б)).
Листинг 11.13. Verilog-модель D-триггера

а) // D-триггер

б) // С асинхронным сбросом
 в) // С синхронной установкой

г) // С сигналом разрешения синхронизации

а)                                                                б)

в)                                                                г)
Рис. 11.15. Синтез моделей D-триггера с синхронизацией по фронту

38. Создание и использование классов с псевдослучайным

генерированием значений полей.
Тест может быть создан с помощью генератора псевдослучайных значений
(constrained-random tests (CRT)). Прямой тест (directed test) находит
запланированные ошибки, в то время как CRT-тест обнаруживает случайные
(незапланированные) ошибки:
Модификатор rand означает, что данные могут формироваться, получая
новое значение или повторяя какое-либо из предыдущих. При применении
модификатора randc значение может появиться повторно, только после того
как будут перебраны все возможные комбинации.
Листинг 13.1. Пример класса с псевдослучайными значениями
class Packet;
// Случайные переменные
rand bit [31:0] src, dst, data[8];
 randc bit [7:0] kind;
// Ограничение значений src
constraint c {src > 10; src < 15;}
endclass

Packet p;
initial begin
p = new; // Создание пакета
assert(p.randomize());
transmit(p); // Какая-то пользовательская функция, которая передает значения
дальше
end
Управляющие генерацией константы записываются в конструкцию constraint
и группируется с помощью фигурных скобок { }. Такие скобки используются,
потому что в них заключается декларативный код, а не процедурный, где
необходимо применять begin...end. Если в процессе генерации значения
возникнет ошибка, то функция randomize возвращает 0, что отслеживается с
помощью прямой ассерции.

39. Создание и использование ограничений для

псевдослучайного генерирования значений. Условные
ограничения, выбор значений из массива, приоритеты значений.
(приоритеты не найдены!)
Класс Stim (Листинг 13.2) содержит класс с псевдослучайной генерацией
значений и несколькими блоками констант. Первый блок c_stim задает
диапазон возможных значения для len. Множество значений может быть
создано также с помощью оператора inside, как для переменной dst. При
этом задается условие, что данное ограничение будет действовать, если бит
congestion_test равен 1.
SystemVerilog создает множество возможных значений и выбирает из
него значения с равной вероятностью, если нет других условий ограничения
переменной.
class Stim;
const bit [31:0] SRC_ADDR = 42;
typedef enum {READ, WRITE, CONTROL} stim_t;
randc stim_t type; // Переменная типа перечисления
rand bit [31:0] len, src, dst;
bit congestion_test;
constraint c_stim {
len < 1000;
len > 0;
src inside {0, [2:10], [100:107]};
if (congestion_test) {
dst inside {[SRC_ADDR - 100 : SRC_ADDR + 100]};
}
}
endclass

______________________________

Пример правильного и неправильного описания констант с помощью

операторов отношения представлен листингом 13.3.  Как видно из примера,
переменная может появляться в нескольких условиях, при этом допускается
в выражении использовать только один оператор отношения (<, <=, ==, >=
или >). 
Листинг 13.3 Переменные ограничения описаны в определенном порядке
class bad;
 rand bit [15:0] a, b, c;
constraint good {0 < a; // Правильное описание
a < b;
b < c;}
constraint bad {0 < a < b < c;} // Неправильно, приведет к ошибке
endclass

_______________________________________________________________________________

Допускается выполнять выбор значения из набора, представленного

массивом.
integer fives[4] = '{ 5, 10, 15, 20 }; 
rand integer v; constraint c3 { v inside {fives}; }
В примере (листинг 13.5) таким образом осуществляется выбор дня недели
DAYS_E из массива choices, имеющего тип enum. Список choices может быть
легко изменен перед генерированием значения. В случае использования
оператора randc, система генерирования переберет все возможные значения
перед повтором уже присвоенных.
Листинг 13.5 Выбор из множества возможных значений
class Days;
typedef enum {SUN, MON, TUE, WED,
THU, FRI, SAT} DAYS_E;
DAYS_E choices[$];
rand DAYS_E choice;
constraint cday {choice inside {choices};}
endclass

Days days;
initial begin
days = new;
days.choices = ‘{Days::SUN, Days::SAT};
assert (days.randomize());
$display("Random weekend day %s\n", days.choice.name);
days.choices = ‘{Days::MON, Days::TUE, Days::WED, Days::THU, Days::FRI};
assert (days.randomize());
$display("Random week day %s", days.choice.name);
end
Если необходимо добавить или удалить данные из динамического массива,
следует осторожно использовать оператор inside, из-за его особенностей.
Например, существует множество значений, заданное очередью, из которых
должно быть выбрано и удалено только одно. Это потребует создать N
ограничений, где N–количество элементов, остающихся в очереди.

Обычно ограничения активны все время. В ситуациях, когда необходимо

отключить действие ограничений на некоторое время SystemVerilog
предлагает две формы условных операторов:  импликации “->” и “if-else”.
// Блок ограничений с оператором импликации
class BusOp;
...
constraint c_io {
(io_space_mode) -> addr[31] == 1’b1;
}
Если присутствуют выражения для обеих ветвей условия true-false, то
предпочтительней использовать оператор if-else.
 // Блок ограничений с оператором if-else
class BusOp;
...
constraint c_len_rw {
if (op == READ)
len inside {[BYTE:LWRD]};
else
len == LWRD;
}
В блоках ограничения, поскольку это декларативный код,  используются
фигурные скобки {}. В процедурном коде применяется “begin...end”.

40. Псевдослучайное генерирование значений: управление блоками

ограничений.
Класс может содержать несколько блоков ограничений. Например, одна
группа управляет разрядностью данных транзакции, а другая – длиной
транзакции. Тогда для того, чтобы включать или отключать ограничения,
можно применять метод constraint_mode(). В формате <имя
ограничения>.constraint_mode(), этот метод управляет единственным
ограничением.
Листинг 13.11 Использование constraint_mode
class Packet;
rand int length;
constraint c_short {length inside {[1:32]}; }
constraint c_long {length inside {[1000:1023]}; }
endclass

Packet p;
initial begin
p = new;
// Создание длинных данных long, отключаа ограниничение для
коротких short
p.c_short.constraint_mode(0);
assert (p.randomize());
transmit(p);
// Создание коротких данных, через отключение всех ограничени
// а затем разрешается использования ограничений для коротких
данных  
p.constraint_mode(0);
p.c_short.constraint_mode(1);
assert (p.randomize());
transmit(p);
end

41. Методы определения полноты тестирования. Виды coverage.

Существует два типа метрик покрытия:
1) code coverage - автоматически формируется на основе кода проекта
(оценивает полноту тестирования с точки зрения проверки операторов, описывающих модель
устройства.)
2) functional coverage – (использует пользовательскую метрику, определяющую, какая часть
спецификации проекта, указанной в плане тестирования, была проверена.)
 Ключевые аспекты функционального покрытия:
 определяются пользователем и не могут быть автоматически получены из кода проекта.
 основываются на спецификации проекта и поэтому не зависят от реального кода модели или
структуры.
Конструкции функционального покрытия в SystemVerilog осуществляют следующие действия:
 Сбор информации о покрытии переменных и выражений, а также о перекрестном покрытии между
ними.
 Автоматическое или пользовательское создание корзин покрытия
 Фильтрацию условий на нескольких уровнях
 Использование событий и последовательностей для автоматического переключения сбора значений
(sampling) покрытия
 Покрытие вызовов процедур и очередей.
 Управление и регулирование формирования покрытия с помощью директивы 

42. Создание  и использование covergroup.

Конструкция covergroup наследует спецификацию модели покрытия. Спецификация covergroup может

включать следующие компоненты:
 События синхронизации, которые определяют моменты считывания значений для точек 
 Множество точек покрытия (coverage points)
 Перекрестное покрытие между точками покрытия
 Необязательные формальные аргументы
 Опции покрытия
Конструкция covergroup является определенным пользователем типом. После декларации она может
иметь несколько копий, которые могут быть реализованы в различных контекстах. Конструкция
covergroup может быть записана в пакете, модуле, программе, интерфейсе  или классе. 

Синтаксис декларации covergroup:

covergroup covergroup_identifier [ ( [ tf_port_list ] ) ] [ coverage_event ] ;
{ coverage_spec_or_option }
endgroup [ : covergroup_identifier ]

coverage_spec_or_option ::=
{attribute_instance} coverage_spec | {attribute_instance} coverage_option ;

coverage_option ::=
option.member_identifier = expression | type_option.member_identifier = expression

coverage_spec ::=
cover_point | cover_cross

coverage_event ::=
clocking_event | @@( block_event_expression )
block_event_expression ::=
block_event_expression or block_event_expression | begin hierarchical_btf_identifier
| end hierarchical_btf_identifier

Синтаксис реализации объекта covergroup:

covergroup_variable_identifier = new [ ( list_of_arguments ) ]
(сори за некст ответ, но я хз что тут может быть важно , а что нет)
Если указано событие синхронизации, то оно определяет моменты времени для сбора значений с точек
покрытия. В противном случае, пользователь должен задать синхронизацию с помощью процедурных
операторов. Это можно выполнить через встроенный метод sample(). Опция strobe может быть
использована для изменения моментов считывания данных. Когда опция strobe не установлена, значения
точек покрытия считываются по событию экземпляра модели покрытия. Если событие синхронизации
встречается несколько раз за время моделирования, то значения точек покрытия должны быть также
прочитаны несколько раз.
В качестве альтернативы для синхронизации может быть использовано выражение блокового события,
считывание контрольных точек покрытия может быть выполнено в начале или конце работы заданного
именного блока, задачи, функции или метода класса. Если выражение блокового события начинается с
ключевого слова begin, за которым следует иерархический идентификатор, обозначающий именной блок,
задачу, функцию или метод класса, то событие переключаются сразу до выполнения первого оператора
указанных конструкций. Выражение блокового события, которое описано с помощью ключевого слова
end, выполняется сразу после последнего оператора указанной конструкции.
Группа покрытия covergroup может содержать одну или несколько точек покрытия, которые задаются
переменной или выражением. С каждой точкой покрытия связывается множество корзин определяемых
значениями, которые записываются в корзины, или передаваемыми значениями. Корзины могут быть
явно определены пользователем или автоматически созданные с помощью инструментов моделирования. 
enum { red, green, blue } color;
covergroup g1 @(posedge clk);
c: coverpoint color;
endgroup

Предыдущий пример представляет группу покрытия g1 с одной точкой покрытия, связанной с

переменной color. Значения переменной color записываются по указанному событию синхронизации - 
положительному фронту clk.
Поскольку точка покрытия не имеет явно определенных корзин, то будут автоматически создаты три
корзины, по одной для каждого значения типа перечисления. Группа покрытия может также содержать
описание перекрестных точек между двумя или больше точками покрытия или переменными.
Допускается использование любых комбинаций более чем двух переменных или предварительно
декларированных точек покрытия. 
Например:
enum { red, green, blue } color;
bit [3:0] pixel_adr, pixel_offset, pixel_hue;
covergroup g2 @(posedge clk);
Hue: coverpoint pixel_hue;
Offset: coverpoint pixel_offset;
AxC: cross color, pixel_adr; // пересечение 2 переменных 
// (неявное задание точек покрытия coverpoint)
all: cross color, Hue, Offset; // пересечение 1 переменной и 2 точек покрытия coverpoints
endgroup

В примере создается группа покрытия g2, которая содержит две точки покрытия и две декларации
пересечения покрытий cross. Явно заданные точки покрытия с метками Offset и Hue определены для
переменных pixel_offset и pixel_hue. Далее для переменных color и pixel_adr задается анализ совместного
покрытия. 
В группе покрытия могут присутствовать одна или несколько опций, контролирующих и
регламентирующих структуру и способ сбора информации о покрытии. Опции покрытия могут быть
заданы для группы покрытия в целом или для отдельных ее пунктов. 

17.2 Использование covergroup в классах

Размещение группы покрытия в классе, обеспечивает простейший способ для создания подмножества
покрытия свойств класса. Интеграция покрытия в класс обеспечивает интуитивный и ясный механизм для
определения модели покрытия связанной с классом. Например,
class xyz;
bit [3:0] m_x;
int m_y;
bit m_z;
 covergroup cov1 @m_z; // встроенная covergroup
coverpoint m_x;
coverpoint m_y;
endgroup

function new();
cov1 = new;
endfunction
endclass
В примере значения полей m_x and m_y класса xyz собираются при каждом изменении переменной m_z.
Если группа покрытия определяется внутри класса и нет явной декларации переменной данной группы в
пределах класса, то она будет иметь такое же имя, которое группа покрытия получила при описании.
Таким образом, в предыдущем примере переменная cov1 соответствует группе покрытия. 
Встроенная в класс группа покрытия может определять модель покрытия для защищенных и локальных
свойств класса без возможности ее переопределения в классе наследнике. Класс может иметь несколько
групп покрытия. Следующий пример представляет класс MC, содержащий две группы покрытия.
class MC;
logic [3:0] m_x;
local logic m_z;
bit m_e;

covergroup cv1
@(posedge clk);
coverpoint m_x;
endgroup
covergroup cv2
@m_e ;
coverpoint m_z;
endgroup
endclass

В covergroup cv1 является членом класса, значение переменной m_x собирается по каждому
положительному фронту сигнала clk. Значения локальной переменной m_z собираются другой группой
covergroup cv2. Каждая группа покрытия собирает значения по различным событиям синхронизации.