You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to discussion in steveicarus/iverilog#223 seems that it is better not to use zero delay inertial updates from VPI for clock synchronized data. It is because Icarus is free to choose between this update and other already pending events.
In this concrete testbench what happens is:
sc_vpi_module::value_change is called for tb_top.clk_i.
From SystemC code change of stb_i, we_i, data_i is scheduled with zero inertial delay.
Icarus processes change of stb_i, we_i, data_i and schedules change of write_en_w due to assign write_en_w = stb_i & we_i & ~ack_o.
Icarus processes always @ (posedge clk_i or posedge rst_i) because of clk_i change before. This is how it ends up that stb_i and we_i are updated but write_en_w is still zero.
Together with using non-zero inertial delay it makes sense in uart_wb_vpi to subscribe only to clock change because everything should be syncrhonized to it.
For me uart_cfg_div does not get set:
Moreover above vardump diverges from what $display outputs:
In last output write_en_w becomes 1 only after data_i is already zero.
How can it be possible?
The text was updated successfully, but these errors were encountered: