15. Проверка синхронизации сигналов в Verilog HDL

Первая часть статьи Setup, hold, setuphold и recovery в Verilog HDL и вторая часть статьи Skew, period, width и nochange Verilog HDL.

15.4 Спецификаторы по контролю фронта(edge-control)

Спецификаторы edge-control можно использовать для управления событиями в проверках синхронизации на основе определенных переходов фронтов между 0, 1 и x. Синтаксис 15-15 показывает синтаксис для спецификаторов edge-control.

edge_control_specifier ::=
    edge [ edge_descriptor { , edge_descriptor } ]
edge_descriptor ::=
    01
    | 10
    | z_or_x zero_or_one
    | zero_or_one z_or_x
zero_or_one ::= 0 | 1
z_or_x ::= x | X | z | Z

01    Переход с 0 к 1
0x    Переход с 0 к x
10    Переход с 1 к 0
1x    Переход с 1 к x
x0    Переход с x к 0
x1    Переход с x к 1

Переходы фронтов, включающие z, рассматриваются так же, как и переходы фронтов, включающие x.

posedge clr

edge[01, 0x, x1] clr

negedge clr

edge[10, x0, 1x] clr

Однако, спецификаторы управления фронтами предлагают гибкость для объявления переходов по фронтам, отличных от posedge и negedge.

15.5 Нотификаторы: определяемые пользователем ответы на нарушения синхронизации

Нотификаторы проверки синхронизации обнаруживают нарушения проверки синхронизации поведенчески и, следовательно, предпринимают действия, как только происходит нарушение. Такие нотификаторы могут использоваться для печати информативного сообщения об ошибке, описывающего нарушение, или для распространения значения x на выходе устройства, сообщившего о нарушении.

Нотификатор — это reg, объявленный в модуле, в котором вызываются задачи проверки синхронизации, который передается в качестве последнего аргумента для проверки синхронизации системы. Каждый раз, когда происходит нарушение синхронизации, проверка синхронизации обновляет значение нотификатора.

Нотификатор является необязательным аргументом для всех проверок синхронизации системы и может быть опущен в вызове проверки синхронизации без негативного влияния на ее работу.

В таблице 15-13 показано, как переключается значение нотификатора при возникновении нарушений синхронизации.

Например:

$setup( data, posedge clk, 10, notifier ) ;
$width( posedge clk, 16, 0, notifier ) ;

primitive posdff_udp(q, clock, data, preset, clear, notifier);
    output q; reg q;
    input clock, data, preset, clear, notifier;
    table
        //clock data p c notifier state q
        //-------------------------------------
        r 0 1 1 ? : ? : 0 ;
        r 1 1 1 ? : ? : 1 ;
        p 1 ? 1 ? : 1 : 1 ;
        p 0 1 ? ? : 0 : 0 ;
        n ? ? ? ? : ? : - ;
        ? * ? ? ? : ? : - ;
        ? ? 0 1 ? : ? : 1 ;
        ? ? * 1 ? : 1 : 1 ;
        ? ? 1 0 ? : ? : 0 ;
        ? ? 1 * ? : 0 : 0 ;
        ? ? ? ? * : ? : x ; // При любом событии уведомляющего
                            // выход x
    endtable
endprimitive

module dff(q, qbar, clock, data, preset, clear);
    output q, qbar;
    input clock, data, preset, clear;
    reg notifier;

    and (enable, preset, clear);
    not (qbar, ffout);
    buf (q, ffout);
    posdff_udp (ffout, clock, data, preset, clear, notifier);

    specify
        // Определяем значения specparam для проверки синхронизации
        specparam tSU = 10, tHD = 1, tPW = 25, tWPC = 10, tREC = 5;
        // Определить значения задержки нарастания и спада пути модуля min:typ:max
        specparam tPLHc = 4:6:9 , tPHLc = 5:8:11;
        specparam tPLHpc = 3:5:6 , tPHLpc = 4:7:9;

        // Укажите задержки в пути модуля
        (clock *> q,qbar) = (tPLHc, tPHLc);
        (preset,clear *> q,qbar) = (tPLHpc, tPHLpc);

        // Время предустановки : data to clock, only when preset and clear are 1
        $setup(data, posedge clock &&& enable, tSU, notifier);

        // Времяудержания: clock to data, only when preset and clear are 1
        $hold(posedge clock, data &&& enable, tHD, notifier);

        // Проверка периода тактового сигнала
        $period(posedge clock, tPW, notifier);
        // Длины пульса : preset, clear
        $width(negedge preset, tWPC, 0, notifier);
        $width(negedge clear, tWPC, 0, notifier);

        // Времени восстановления: clear or preset to clock
        $recovery(posedge preset, posedge clock, tREC, notifier);
        $recovery(posedge clear, posedge clock, tREC, notifier);
    endspecify
endmodule

ПРИМЕЧАНИЕ — Данная модель применима только к UDP, чувствительным к границам. для моделей, чувствительных к уровням, необходимо использовать дополнительный UDP для x распространение должно быть сгенерировано.

Перевод Официального Стандарта Verilog HDL

15.5.1 Требования для точного моделирования

Для точного моделирования проверок синхронизации отрицательных значений применяются следующие требования:

1. Нарушение синхронизации происходит, если сигнал изменяется в окне нарушения, за исключением конечных точек. Окна нарушений, размер которых меньше двух единиц точности моделирования, не могут привести к нарушению синхронизации.
2. Значение задерживаемых данных должно быть тем, которое стабильно в течение окна нарушения, опять же, за исключением конечных точек.

Чтобы облегчить эти требования к моделированию, при проверке синхронизации создаются отложенные копии данных и сигналов отсчета, которые используются внутри системы для оценки проверки синхронизации во время выполнения. Времена установки и удержания, используемые внутри, корректируются для смещения окна нарушения и перекрытия сигнала отсчета.

Задержанные данные и сигналы отчета могут быть объявлены в рамках проверки синхронизации, чтобы их можно было использовать в функциональной реализации модели для обеспечения точного моделирования. Если в проверке синхронизации не объявлены сигналы с задержкой и присутствует отрицательное значение setup или hold, то создаются неявные сигналы с задержкой. Поскольку неявные задержанные сигналы не могут быть использованы при определении поведения модели, такая модель может вести себя некорректно.

Например:

$setuphold(posedge CLK, DATA, -10, 20);

Для CLK и DATA должны быть созданы неявные сигналы с задержкой, но доступ к ним невозможен. Функция Проверка $setuphold должна быть правильно оценена, но функциональное поведение не всегда будет точным. Старое значение DATA будет некорректно занесено в память, если DATA переходит между задержкой CLK и 10 единицами времени позже.

$setuphold(posedge CLK, DATA1, -10, 20);
$setuphold(posedge CLK, DATA2, -15, 18);

Неявные задержанные сигналы должны быть созданы для CLK, DATA1 и DATA2, по одному для каждого. Даже если CLK упоминается в двух разных проверках синхронизации, создается только один неявный задержанный сигнал, и он используется для обеих проверок синхронизации.

Пример 3

$setuphold(posedge CLK, DATA1, -10, 20,,,, del_CLK, del_DATA1);
$setuphold(posedge CLK, DATA2, -15, 18);

Явные задержанные сигналы del_CLK и del_DATA1 создаются для CLK и DATA1, а неявный задержанный сигнал создается для DATA2. Другими словами, для CLK создается только один задержанный сигнал del_CLK, а не один явный задержанный сигнал для первой проверки и другой неявный задержанный сигнал для второй проверки.

Задержанные версии сигналов, неявные или явные, должны использоваться в проверки времени $setup, $hold, $setuphold, $recovery, $removal, $recrem, $width, $period и $nochange. Эти проверки должны иметь свои пределы, скорректированные соответствующим образом. Это гарантирует, что уведомление будет переключено в нужный момент. Если скорректированный предел становится меньше или равен 0, предел должен быть установлен в 0, а симулятор должен выдать предупреждение.

Задержанные версии сигналов не должны использоваться для проверок синхронизации $skew, $fullskew и $timeskew, поскольку это может привести к изменению порядка переходов сигналов. Это приведет к тому, что нотификаторы для этих проверок синхронизации будут переключаться в неправильное время относительно остальной части модели, что, возможно, приведет к тому, что переходы в X из-за нарушения проверки синхронизации будут отменены. Этот вопрос должен быть решен в модели, возможно, путем использования отдельных нотификаторов для этих проверок.

Возможно, что набор отрицательных значений проверки синхронизации будет взаимно противоречивым и не даст решения для значений задержки задержанных сигналов. В таких ситуациях симулятор должен выдать предупреждающее сообщение. Несоответствие должно быть устранено путем изменения наименьшего отрицательного предельного значения на 0 и пересчета задержек для задержанных сигналов, и это должно повторяться до тех пор, пока не будет достигнуто решение. Эта процедура всегда приводит к решению, так как в худшем случае все отрицательные предельные значения становятся равными 0 и задержки сигналов не требуются.

Задержанные сигналы проверки синхронизации фактически задерживаются только при наличии отрицательных предельных значений. Если сигнал проверки синхронизации задерживается больше, чем задержка распространения от этого сигнала до выхода, то для изменения этого выхода требуется больше времени, чем его задержка распространения. Вместо этого он должен переходить в то же время, когда изменяется задержанный сигнал проверки синхронизации. Таким образом, выход должен вести себя так, как если бы его задержка уточняющего пути была равна задержке, применяемой к сигналу проверки синхронизации. Такая ситуация может возникнуть только в том случае, если для каждого фронта сигнала данных задано уникальное время установки/удержания или снятия/восстановления.

(CLK = Q) = 6;
$setuphold (posedge CLK, posedge D, -3, 8, , , , dCLK, dD);
$setuphold (posedge CLK, negedge D, -7, 13, , , , dCLK, dD);

Время установления -7 (большее по абсолютной величине из -3 и -7) создает задержку dCLK на 7 единиц. Поэтому выход Q не должен изменяться до истечения 7 единиц времени после положительного фронта импульса на CLK, а не 6 единиц времени, как указано в объявленном пути.

15.5.2 Условия при проверке отрицательного времени

Условия могут быть связаны как с сигналом отсчета, так и с сигналом данных с помощью оператора &&&. Когда время установки или удержания отрицательно, условия должны быть сопряжены с сигналом отсчета и данных более гибким способом. Этот пример иллюстрирует, почему.

(CLK = Q) = 6;
$setuphold (posedge CLK, posedge D, -3, 8, , , , dCLK, dD);
$setuphold (posedge CLK, negedge D, -7, 13, , , , dCLK, dD);

$setuphold( clk, data, tsetup, thold, ntfr, , cond1);

Аргумент timestamp_cond равен null, а аргумент timecheck_cond равен cond1.

Аргументы timestamp_cond и timecheck_cond связаны либо с сигналом отсчета, либо с сигналом данных в зависимости от того, какой из этих сигналов с задержкой возникает первым. timestamp_cond связан с сигналом с задержкой, который переходит первым, а timecheck_cond связан с сигналом с задержкой, который переходит вторым.

Сигналы с задержкой создаются только для опорного сигнала и сигнала данных, но не для любых сигналов условий, связанных с ними. Поэтому timestamp_cond и timecheck_cond неявно не задерживаются симулятором. Задержанные сигналы условия для полей timestamp_cond и timecheck_cond можно создать, сделав их функцией задержанных сигналов.

assign TE_cond_D = (dTE !== 1'b1);
assign TE_cond_TI = (dTE !== 1'b0);
assign DXTI_cond = (dTI !== dD);

specify
    $setuphold(posedge CP, D, -10, 20, notifier, ,TE_cond_D, dCP, dD);
    $setuphold(posedge CP, TI, 20, -10, notifier, ,TE_cond_TI, dCP, dTI);
    $setuphold(posedge CP, TE, -4, 8, notifier, ,DXTI_cond, dCP, dTE);
endspecify

Операторы назначения создают сигналы условий, которые являются функциями задержанных сигналов. Создание условий отложенных сигналов синхронизирует условия с отложенными версиями сигналов отсчета и данных, используемых для выполнения проверок.

Первый $setuphold имеет отрицательное время предустановки. Поэтому условие проверки по времени TE_cond_D связано с сигналом данных D. Второй $setuphold имеет отрицательное время удержания. Поэтому условие проверки по времени TE_cond_TI связано с сигналами отсчета CP. Третий $setuphold имеет отрицательное время предустановки. Поэтому условие проверки времени DXTI_cond связано с сигналом данных TE.

Окна нарушений для данного примера показаны на рисунке 15-4.

Использование задержанных сигналов при создании сигналов для аргументов timestamp_cond и timecheck_cond не обязательно, но обычно это ближе к реальному поведению устройства.

15.5.3 Нотификаторы при проверке отрицательного времени

Поскольку сигналы отсчета и сигналы данных задерживаются внутри, обнаружение нарушения синхронизации также задерживается. Нотификатор regs в отрицательных проверках синхронизации должен быть переключен, когда проверка синхронизации обнаруживает нарушение синхронизации, что происходит, когда нарушены задержанные сигналы, измеренные скорректированными значениями проверки синхронизации, а не когда нарушены незадержанные сигналы на входах модели, измеренные исходными значениями проверки синхронизации.

15.5.4 Вариант поведения

Как уже упоминалось, способность симуляторов Verilog обрабатывать отрицательные значения в $setuphold и $recrem должна быть включена с помощью опции вызова. Возможно, модели, написанные для приема отрицательные значения проверок синхронизации с задержкой сигнала отсчета и/или данных, могут быть запущены без этой опции вызова опции вызова. В этом случае задержанные сигнал отсчета и данных становятся копиями оригинальных сигнала отсчета и данных. То же самое происходит, если используется опция вызова, отключающая все проверки синхронизации используется.

15.6 Включение проверки времени с помощью обусловленных событий

Конструкция, называемая обусловленным событием, связывает возникновение проверок синхронизации со значением обусловленного сигнала. Синтаксис 15-16 показывает синтаксис для управляемого события проверки синхронизации.

timing_check_event ::=
    [timing_check_event_control] specify_terminal_descriptor [ &&& timing_check_condition ]
controlled_timing_check_event ::=
    timing_check_event_control specify_terminal_descriptor [ &&& timing_check_condition ]
timing_check_event_control ::=
    posedge
    | negedge
    | edge_control_specifier
specify_terminal_descriptor ::=
    specify_input_terminal_descriptor
    | specify_output_terminal_descriptor
timing_check_condition ::=
    scalar_timing_check_condition
    | ( scalar_timing_check_condition )
scalar_timing_check_condition ::=
    expression
    | ~ expression
    | expression == scalar_constant
    | expression === scalar_constant
    | expression != scalar_constant
    | expression !== scalar_constant
scalar_constant ::=
    1'b0 | 1'b1 | 1'B0 | 1'B1 | 'b0 | 'b1 | 'B0 | 'B1 | 1 | 0

Сравнения, используемые в обусловленной, могут быть детерминированными, как ===, !==, ~ или отсутствие операции, или недетерминированными, как == или !=. Когда сравнения детерминированы, значение x на формирующем сигнале не должно включать проверку синхронизации. Для недетерминированных сравнений значение x на формирующем сигнале включает проверку синхронизации.

Сигнал формирования должен быть скалярной сеткой. Если используется векторная сетка или выражение, приводящее к многоразрядному значению, то используется наименьший значащий бит векторной сетки или значения выражения.

Если для проверки синхронизации требуется более одного сигнала формирования, соответствующая логика должна быть объединена в отдельный сигнал вне specify блока, который может быть использован в качестве сигнала формирования.

Например:

$setup( data, posedge clk, 10 );

Здесь проверка синхронизации установки происходит каждый раз, когда на сигнале clk появляется положительный фронт.

$setup( data, posedge clk &&& clr, 10 );

$setup( data, posedge clk &&& (~clr), 10 ) ;
$setup( data, posedge clk &&& (clr===0), 10 );

and new_gate( clr_and_set, clr, set );

$setup( data, posedge clk &&& clr_and_set, 10 );

15.7 Векторные сигналы при проверке синхронизации

Любой или оба сигнала в проверке синхронизации могут быть вектором. Это должно интерпретироваться как одиночная проверка синхронизации, когда переход одного или нескольких битов вектора рассматривается как один переход этого вектора.

module DFF (Q, CLK, DAT);
    input CLK;
    input [7:0] DAT;
    output [7:0] Q;

    always @(posedge clk)
        Q = DAT;

    specify
        $setup (DAT, posedge CLK, 10);
    endspecify
endmodule

Если DAT переходит от ‘b00101110 к ‘b01010011 в момент времени 100 и если CLK переходит от 0 к 1 в момент времени 105, то проверка синхронизации $setup все равно сообщит только об одном нарушении синхронизации.

Симуляторы могут предоставлять возможность создания векторов в проверках синхронизации, что приводит к созданию нескольких однобитных проверок синхронизации. Для проверок синхронизации только с одним сигналом, таким как $period или $width, вектор шириной N приводит к N уникальным проверкам синхронизации. Для проверок синхронизации с двумя сигналами, такими как $setup, $hold, $setuphold, $skew, $timeskew, $fullskew, $recovery, $removal, $recrem, и $nochange, где M и N — ширина сигналов, в результате получается M*N уникальных проверок времени. Если есть нотификатор, то все проверки синхронизации срабатывают на этот нотификатор.

Если такая опция включена, то в приведенном выше примере будет шесть нарушений синхронизации, поскольку 6 битов DAT перешли.

15.8 Проверка отрицательного времени

Проверки времени $setuphold и $recrem могут принимать отрицательные значения, если включена опция отрицательной проверки времени. Поведение этих двух проверок синхронизации идентично по отношению к отрицательным значениям. Сайт описания в этом подпункте относятся к проверке времени $setuphold, но в равной степени применимы и к проверке времени $recrem.

Контрольные значения предустановки и удержания определяют окно нарушения синхронизации по отношению к фронту опорного сигнала, в течение которого данные должны оставаться неизменными. Любое изменение данных в течение указанного окна приводит к нарушению синхронизации. О нарушении синхронизации сообщается, и через нотификатор reg в модели могут происходить другие действия, например, принудительное переключение выхода flip-flop на X, когда он обнаруживает нарушение синхронизации.

Положительное значение времени установления и удержания подразумевает, что это окно нарушения пересекает сигнал отсчета, показанный на рисунке 15-5.

Отрицательное время удержания или установки означает, что окно нарушения сдвигается либо до, либо после фронта отсчета. Это может произойти в реальном устройстве из-за несоразмерных внутренних задержек устройства между внутренними тактовыми сигналами и сигналами данных. Эти внутренние задержки устройства показаны на рисунке 15-6, где показано, как значительные различия в этих задержках могут привести к отрицательным значениям установки или удержания.