Add lint check when a variable used in DUT is defined as an output in a clocking block

[katsui97]

I would like to withdraw my previous post (#5638). Please feel free to delete it.

I realized that I did not fully understand clocking blocks. My apologies.

DUT Example:

  logic [3:0] r_cnt;
  always_ff @(posedge CLK, negedge RST_X)
    if (~RST_X)
      r_cnt <= '0;
    else
      r_cnt <= 4'(r_cnt + 1'b1);

By defining a zero-skew (#0) clocking block as shown below:

  clocking cb @(posedge CLK);
    output test;
  endclocking

At the point where the @(cb) is encountered within the initial block of the testbench, the execution waits for the block to be released in the Observed region. At this stage, the DUT execution has already completed up to the NBA (non-blocking assignment) phase.
Assertion evaluations have not yet occurred at this point. If the testbench performs standard assignments (not using the clocking block definition) such as r_cnt = 0, the value will be overwritten.
This behavior aligns with the intended design.

Subsequently, assertion evaluations are performed after this, which is also the expected behavior.

In Verilator, non-blocking assignments within the initial block are forcibly converted to blocking assignments.
If I understand correctly, this behavior is intentional, effectively prohibiting non-blocking assignments to regular variables in the initial block. I agree with this approach. For variables defined as output in a clocking block (e.g., cb.test), only non-blocking assignments are allowed, and blocking assignments result in an error.
I believe this is a logical specification.

My Initial Misunderstanding
At first, I misunderstood the following:
I defined the clocking block as below:

  clocking cb @(posedge CLK);
    output r_cnt;
  endclocking

Then, within the initial block, I wrote something like cb.r_cnt <= 123; and assumed it would be updated via Re-NBA (rescheduled non-blocking assignment). However, the assignment was ignored, which seemed strange to me.

Upon further consideration, I realized that my understanding of clocking blocks was incomplete.

For variables like r_cnt that are modified in the DUT, forcibly changing their value (e.g., using force) might make sense. However, defining such variables as part of a clocking block in the DUT can lead to multiple drivers and effectively undermine the original purpose of the clocking block.

Feature Request
If possible, could you make it so that an error occurs when a variable used in the DUT (like r_cnt) is defined as an output in a clocking block?

As I am currently unemployed, I have not been able to verify this behavior with tools like VCS or Xcelium. However, I recall that even a very old version of ModelSim (free edition) produced an error in such cases.

Thank you for your understanding and support.