I tried to sync the clock within a driver task but it was blocking because of which I put in the run phase directly. I am able to “get” the virtual interface vif in the connect phase and the test runs if I remove any clock check (but since the DUT is tied to the interface, it does not respond without the clock). Is there something I am doing wrong?
It would really help to show a complete example showing the behavior you are seeing.
Without seeing all of the code, there could be a variety of potential issues.
It is recommended to create the clocks at the testbench level and use them as inputs to your interfaces/modules. Also, you should use a forever block to generate a clock, not an always block.
and the display is showing only the first line.
This really is the complete record of clock appearing in the files. I do not own the module I am trying to verify so I am not sure how much I can share
I have another task in the driver run_phase which is executing correctly with @(posedge clk) removed. Is there anything specific you’d like to know?
You have a potential race condition with the 1st posedge of clk happening at time 0. Since the initial value of a bit is 0, you are assigning it to 1 at time 0. That will be a race condition with any code waiting on @(posedge clk) also at time 0.
You can avoid that race by making sure the first assignment to clk does not happen at time 0 (As I see Chuck just suggested).
If you want clk to start out with the value 1 instead of its default value 0, the declare it as
bit clk=1;
This initialization is guaranteed to occur before any initial or always block starts executing.
Thank you for the suggestion but the blocking seems to continue. I want to add that
1.the waveform shows the clock toggling but the statement is blocking
2.the task is in the same scope as the clock signal and I am able to update other signals through another task defined in the interface(clock becomes blocking in that too)
3. the interface itself is accessible since I can call the tasks through a virtual interface
I feel as if this is a silly mistake somewhere but I am out of ideas on where to look, because as I have said earlier, this is the only place where clock signal is referred to
EDIT: I have found that it is a delay problem and it gets solved by defining a default sequence instead of the seq.start() method. Do you know why it is happening?
In reply to dave_59:
Thank you. I do not have any requirement for the initial value. I have changed it to 0 but the issue still persists. The problem is that clock is blocking rather than not toggling itself. But I will keep this point in mind for the future…
Also, just noting my thanks for the explanations on backdoor access method in the DVCon paper. It was helpful
Can you please tell me why seq.start(sequencer) would lead to intolerance of delay in run task
You should never use a default sequence. The seq.start() method is the recommended method to start sequences. You would have to show your environment if you want more insight on why things aren’t working as expected.
In reply to cgales:
Okay, I have found the issue and it really is a silly one. I started out with a default sequence and changed it to seq.start later without incorporating the raise/drop objection. This meant that my initial code was running correctly but any delays would not be allowed to run. But since I didn’t put any delay and directly asked to wait for clock,I assumed it was a problem with the clock signal and tried to solve that.
Thank you for your time and responses.