[mikeT 0]

Написал простой тест для улучшения понимания того, как работает симулятор SystemVerilog (Sheduling semantics).

 

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

Проект состоит из трех частей:

1) в качестве DUT простейший модуль счетчика

 

module counter
(
    input logic clk
);

//--- 
logic       ena = 0;
logic [7:0] cnt = '0;

//---
always_ff @(posedge clk) begin
    cnt <= cnt + 1;
    if(cnt == 1) begin
        ena <= 1;
    end
end

endmodule : counter

2) program observer - копирует состояние счетчика (подробности в коде)

program observer
(
    //---
    ref  logic           clk,
    
    //---
    ref  logic           ena,
    ref  logic [7:0]     cnt
);

//---
timeunit      1ns;  
timeprecision 1ps;  

//---
logic [7:0] ref_cnt1 = 'x;
logic [7:0] ref_cnt2 = 'x;

//---
initial begin
    forever begin
        @(posedge clk) begin
            if(ena) begin
                ref_cnt1 <= cnt;
                ref_cnt2  = cnt;
            end
        end
    end
end

endprogram : observer

 

3) модуль верхнего уровня

module tb
();

//---
timeunit      1ns;  
timeprecision 1ps;  

//---
parameter unsigned STOP_TIME = 80; 

//---
logic clk = 0;

//---
initial begin
    fork
        forever begin
            #5ns clk = ~clk;
        end
        #(STOP_TIME*1ns) $stop(2);
    join_any
end

//---
counter counter_inst
(
    .clk ( clk )
);

//---
observer observer_inst
(
    //---
    .clk           ( clk ),
    
    //---
    .ena           ( counter_inst.ena ),
    .cnt           ( counter_inst.cnt )
);

endmodule : tb

 

Краткое описание эксперимента

 

Observer только «наблюдает», т. е. я постарался исключить его влияние на состояние модуля counter или, другими словами, постарался исключить возможные переходы из Reactive region sets в Active region sets (IEEE Std 1800-2017, 4. Sheduling semantics).

Если я все правильно понимаю, вся работа, выполняемая в program observer, будет происходить в Reactive region sets, ref_cnt2 - Reactive, ref_cnt1 - Evaluate RHS в Reactive, далее работа в Re-NBA.

Т.е. по сути все события, которые обрабатываются в module counter должны были уже быть обработаны ранее (в Active region set, точнее в Active и в NBA регионах).

 

В таком случае, я ожидаю увидеть диаграмму вот такого вида:

Рис.1

 

И действительно, в Questa 10.4a картина именно такая.

 

Меняю слово program на слово module (еще endprogram на endmodule) для observer. Теперь должно стать вот так:

 

Рис.2

Снова все сошлось - теперь вся обработка идет в Active region sets и мы видим наблюдаемые значения с задержкой на один такт.

Запускаю Questa 10.7c. Для варианта observer как module картинка такая же как на Рис.2, т. е. все по теории (если я ее правильно понимаю).

А вот для варианта observer как program картинка по идее должна быть аналогична Рис.1, но в реальности мы получаем снова результат как на Рис. 2.

 

Вопросы

(1)

Правильно ли я понимаю, что в соответствии со стандартом (конкретно, раздел Sheduling semantics), все должно быть именно так, как происходит при моделировании с использованием Questa 10.4a?

(2)

Если при моделировании на Questa 10.4a сделать описание портов program observer вместо таких

program observer
(
    //---
    ref  logic           clk,
    
    //---
    ref  logic           ena,
    ref  logic [7:0]     cnt
);

 

Вот такими:

program observer
(
    //---
    input  logic           clk,
    
    //---
    input  logic           ena,
    input  logic [7:0]     cnt
);

 

То получим диаграмму не похожую ни на одну из двух предыдущих:

 

Рис. 3

Вот такое поведение я вообще объяснить не могу. Какая разница - ref или inputs в данном случае? Чтобы стало «правильно» (как на Рис.1) достаточно сделать вот такое объявление портов:

program observer
(
    //---
    input  logic           clk,
    
    //---
    input  logic           ena,
    ref    logic [7:0]     cnt
);

 

(3)

Если мы используем теперь Questa 10.7c то при любых манипуляциях с портами (input, ref, …) вид диаграммы будет всегда один и тот-же и он совпадает с Рис. 2. Вопрос - кто работает правильно (10.4а или 10.7с) или вообще никто из них?

 

 

 

Изменено 12 октября, 2020 пользователем mikeT

[LiNED 0]

С трудом представляю себе как вообще может получиться картинка 3. Для этого нужно чтобы Observer после posedge clk сработал еще и на изменение ena. Учитывая, что изменение ena неблокирующее, я вообще не представляю как получилась такая картинка.

Попробуй включить на времянке view -> expanded time -> events mode, затем view -> expanded time -> expand all, времянка покажет в каком порядке и как проходили все изменения, возможно разница в порядке обработки станет очевидна сразу.