I am trying to send .read and .write register transactions through the reg_adapter. The reg adapter here converts the reg transaction into a SPI one and vice versa when it receives the response. The way the custom SPI works is , For every READ transaction that I send , I get the rd_data back in the next cycle. Is there any way that I can route the data back to the test , after every register transaction ?
Example:-
base_test.sv :-
T1 reg.write(uvm_status, spi_write_data) ; // I want to simultaneously read the current data on the MISO lines
T2 reg.read (uvm_status, spi_read_data) ;
T3 reg.read (uvm_status, spi_read_data) ; // spi_read_data will have the data which I wrote in transaction T1
In reply to bvnirliptha24:
How you see your data depends on the protocol you have implemented.
One way to break this behavior with respect to the registers is to use for the read the backdoor access. Best is to use instead of the read a peek, because peek is a dedicated backdoor command.
In reply to chr_sue:
Thanks for the response .
Yes. I understand what you are saying but what I actually want is to check if the protocol is working via reg_transactions. The “base_test.sv” runs multiple register transactions.
Problem I have : All the reg transactions are sent on the MOSI lines and for each transaction that is sent on the MOSI lines, I want to read data on the MISO lines and send it back to the “base_test.sv” which I dont know how. I made the changes in driver to get the data back till bus2reg in adapter but not back to test. As mentioned earlier I get the data back in the next cycle/frame [ If Cycle 1 is READ, then I get data back in Cycle2]. The test has access to only the RAL API calls like .read, .write, .peek etc…
I can use the virtual spi interface handle to get access but I am not sure if its the right way.
Lets take for Example the following sequence :-
MOSI LINES =========== Wrt[0xA] || Rd || Write[0xB] || Read || Write[0xC]
MISO LINES =========== garbage || garbage || rd_data=0xA|| garbage || rd_data=0xB
I will be missing the check on “rd_data=0xA” since data is not returned back to base_test.sv.
Is there any alternative to this or a better way to test the same?
Any kind of help is much appreciated.
Regards
Nirliptha
In reply to bvnirliptha24:
Why do you want to bring your read data to your test. I believe you want to check if your data are correct this is a typical task for a scoreboard. But in your case you caan do something I do verifying DDR designs. I perform the checking directly in the sequence. May be this is a good solution also for you.
In reply to chr_sue:
Perfect. The best way would be to implement a scoreboard as you said. That would give a greater perspective in all ways.
Thanks a lot for the suggestion.
In reply to chr_sue:
Actually this is very nice problem to solve. Using the scoreboard is just a workaround here but does not solve the real problem.
Lets say I have a reg.read from two threads on to the uvm ral.
The read happens in 1st cycle and resp data comes in next cycle.
From the test’s perspective we expect the reg.read to return when the read is actually complete.Because we expect it to give back the data read. i.e resp data comes in the next cycle
In the next cycle we want to be able to execute an new read item on the driver too.
So driver needs to be aware of two things
- The first read is complete only in the 2nd cycle ( item_done in 2nd cycle).
- It needs to accept an new sequence item(new read) in the 2nd cycle.
There are examples of pipelined driver on the web. However none of them are uvm ral based.
I am wondering how this can be accomplished ?