Example - 1

Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.

data_out = 0;
data_out = (grant_access) ? data_in : data_out;assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;if (!rst_n)else
module foo_bar(data_out, usr_id, data_in, clk, rst_n);output reg [7:0] data_out;input wire [2:0] usr_id;input wire [7:0] data_in; input wire clk, rst_n;wire grant_access;always @ (posedge clk or negedge rst_n)beginendendmodule

This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1.

Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below.

data_out = 0;

assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;data_out = (grant_access) ? data_in : data_out;if (!rst_n)else
always @ (posedge clk or negedge rst_n)beginendendmodule