Hi all,
I have a class tx_class, which compute the data and push_back into the queue (queue is declared in the interface)
snippet as mentioned below
vif.pxl_queue.push_back(o_payload); // data is push into the queue properly. o_payload is the output signal of tx_class
class rx_class:
But while getting at rx_class, I am getting all the data but some data’s are getting at same simualtion time(which is making an issues at the waveform, like 342f2b21 is missed and only 2c282e29 is shown in the waveform)
snippet as mentioned below
i_pixel_data_32 = vif.pxl_queue.pop_front();
frames = i_pixel_data_32;
`uvm_info(“FRAMER”, $sformatf(" Data from framer frames = %0h",frames ), UVM_NONE);
Output printed of rx_class at Transcript as mentioned below:
725955000: reporter [FRAMER] Data from framer = 342f2b31
725955000: reporter [FRAMER] Data from framer = 2c282e29
725974000: reporter [FRAMER] Data from framer = 252c2723
725974000: reporter [FRAMER] Data from framer = 2c27242b
if you see the simulation time, at “725955000” two different values are getting printed and only the last value(2c282e29) is updated in the waveform
Like wise @ 725974000, i am getting two different value but value 252c2723 is getting discarded and 2c27242b is updated in the waveform
So, Please anyone provide me your valuable suggestion to overcome this issues.
Thank you for the quick reply.
by the way, I have missed out to inform that at tx_class it works at 65Mhz clock
and rx_class works at 53Mhz.
Yes like you have mentioned to synchronize read on the clock edge, i have tried that alread
@(posedge vif.i_sys_clock) begin
if(vif.pxl_queue.size()>0) begin
i_pixel_data_32 = vif.pxl_queue.pop_front();
frames = i_pixel_data_32;
I believe the frequency is not the issues.
As pushing into queue and popping from Queue is not dependent to clock.
Of course it does not depend on a certain frequency. Ehat I emant you do not make a read on a clock edge.
To debug your issue you should print out the comands for writing into the queue. Using `uvm_info gives you also the time stamp.
Yes Dave exactly, I am not able to get the said above values in the waveforms.
So basically what I have done is, in the tx_class(which works at 65Mhz) I have push data into the queue via interface and at rx_class(which works at 53Mhz) I am popping the data.
After the simulation gets over, at Transcript all the data(which was pop in rx_class) are visible but not into the waveforms(data which are printed at the same simulation timing where first data is discarded and second data is captured into the waveform and respectively with third and fourth data)
The default for most waveforms is viewing data at the end of each time step. Viewing zero length transactions on a waveform is a tool specific feature.
This Siemens EDA sponsored public forum is not for discussing tool specific usage or issues. Please read your tool’s user manual or contact your tool vendor directly for support.
Dealing with the waveforms is not the best approach in this case. You should look where the transactions in the queue are coming from. There should be put or write commands.
In reply to chr_sue:
Here’s the flow how I have used analysis ports to queues…
From monitor of agent, I have call the function write and through analysis implementation data has been collected at the reference model (that is top_predictor, now tx_class and rx_class are instantiated inside the top_predictor class) at top_predictor a queue1 is used to collect the pixel data from the transaction packet (@ function write implementation).
From top_predictor Data from queue1 sent as input for tx_class(data received as per queue1 provided and works @ freq of 65Mhz), The output of tx_class is push into queue2 which is declared inside rx_class
Now from the queue2(all data received in queue2), I’m trying to Pop out data at every posedge sys_clock(53Mhz) and provide it as input to rx_class(so here is the issues that is happening).
So may I kindly know, what could be the possibility of going wrong?
You should make print-outs for each write call to see what has been sent at which time.
Use `uvm_info. This rovides all these information.
BTW why you are using queues instead of uvm_analysis fifos?
Ya I am doing that using `uvm_info for printing each write calls.
BTW top_predictor is uvm base class and tx_class and rx_class are SV base classes, so I have used queues for SV classes.
WIll uvm_analysis_fifo works even @ SV base class?
In my opinion it is a lot more easy.
If you are displaying the data sent to the queues you shoule see all the values you are storing there and the corresponding time.
As per my analysis, there’s no doubt of losing data from the queue(I have used `uvm_info to see the value in queue, it is displaying the expected data)
The only thing that hurdle me is when I’m trying to write into the input signal of rx_class, data couldn’t be written sequentially/systematically at every edge of clock(53Mhz).
I do not know your architecture in detail. But my guess is your problem is caused by the place where you are storing your transaction, the interface. The interface is cycle-based but the transaction processing is intended to be dfone in TLM blocks nand not in interfaces and modules.
Out of curiosity, I have tried reading data from the queue2 in the rx_class by using 65Mhz (which is actually suppose to read using 53Mhz), and I got the the data which was expected.
If I use 53Mhz for reading then the issues comes up, So basically it is related with the clock synchronizing.
You have mentioned uvm_analysis_fifo but will it supports for SV class base?
or is there any better approach instead of queues for SV class?
I have UVM Environment, and within the UVM component that is top_predictor I have instantiated that two SV class(tx_class & rx_class).
So basically this tx_class and rx_class is written as reference model purpose.
I believe mixing simple SV code with UVM code is not a good coding style.
But thios might not cause your problems. I guess it is caused by using your transactions in a clock synchrinized SV interface. Can you share your code privately?
My personal email is christoph@christoph-suehnel.de