I am writing a driver for my tb, now I feel puzzled when it comes to the timing, I am ok with other key points like virtual interface and get_next_item() methods, but how to code the main driving part where the timing is concerned?
In reply to Marina.Miao:
In your driver’s run_phase you have to implement the timing required by the spec of your functional interface. This includes the correct generaition of all control signals and the timing with respect to clock cycles. In other words the driver has to implement the interface protocol.
In reply to chr_sue:
In reply to Marina.Miao:
In your driver’s run_phase you have to implement the timing required by the spec of your functional interface. This includes the correct generaition of all control signals and the timing with respect to clock cycles. In other words the driver has to implement the interface protocol.
Need to take care of input and output skews. This can be achieved using clocking block by mentioning the skews in it.
In reply to mbhat:
Yes, I have implemented interface using clocking block and modport, and skew is included, the main problem for me I think is the correct generation of all control signals and timing with respect to clock cycles. I am doing it for the first time so I am still struggling here.
There are just five signals here: valid, start, length that indicates the packet length, and ready, It must be easy, but for me it is not. QAQ(crying)
Thanks anyway.
In reply to Marina.Miao:
You should have in your interface spec waveform visualizing the behavior of all your signals. Follow these descriptions.
In reply to Marina.Miao:
Then the timing should be described in words like this: The start bit becomes high, then the data are transmitted (data length is 8 bit) afterwards the stop bit is asserted…
In reply to chr_sue:
No, QAQ, it not like that, just description for each signals, no timing descriptions .
In reply to Marina.Miao:
Could you please post the desription for one signal? What kind of DUT do you have?
If you are not provided with timing details, maybe the input signals are from standard protocol I/F? I2C? APB? AHB? etc. You need to check the standard documentation for the timing.
In reply to chr_sue:
RxReady output This signal is used by Transport to backpressure data from Adapter Layer. It is high when Transport ingress can accept data from Adapter Layer. When interfacing logic layer, this signal should be always high.
Just like this.
In reply to Marina.Miao:
If you have only this kind of information you have to ask your designer for some waveforms describing how the interface is working, because this is an absolute need.
In reply to chr_sue:
Thank you very much for all your replies, more experienced verification colleague said it’s simple enough so waveform is not necessary.
In reply to chr_sue:
if I want to randomize the ‘ready’ signal on the bus, how can I implement in my driver?
I currently do it in this way:
define a rand variable ready in the class driver_cfg, create a substance of driver_cfg in the build_phase of driver class, then use driver_cfg.randmize() with {constraint of ready}, but I don’t know how to implement in the constraint.
In reply to Marina.Miao:
I’d recommend you should whatch this course:
https://verificationacademy.com/courses/basic-uvm
BTW, is ready an input or an output signal?
In reply to chr_sue:
ready is DUT’s input signal, so my tb drive this signal, at the same time the driver sample data according to valid and ready, and then encapsulate into items.
BTW, I have learned all the basic_uvm course last year or so.
In reply to Marina.Miao:
Looks like you should have another look tto the basics.
What you have to do is to define:
(1) a seq_item which contains all your data members you need
(2) a sequence which generates seq_items
(3) a sequencer/driver pair
(4) construct them
(5) then you can execute your sequence on the sequencer.
The details are described on the basics video.