Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UVM VIP testing environment #20

Open
datachiii opened this issue Dec 26, 2024 · 9 comments
Open

UVM VIP testing environment #20

datachiii opened this issue Dec 26, 2024 · 9 comments

Comments

@datachiii
Copy link

Hello,

Your work is very comprehensive, and the functionality is quite complete. I want to try using your IP in my test environment to observe its behavior. There are a few questions I’d like to ask:

  1. I am using a UVM VIP for testing. While observing the waveform, I noticed that the b_resp is received at the master interface but is not forwarded to the slave interface in the crossbar. This causes a UVM_ERROR. Please advise where I should start troubleshooting to track down the issue?

  2. Since I cannot fully observe the behavior, I’d like to ask about the outstanding scenario. Assuming there is only 1 master and 1 slave, if the addr input consists of 3 consecutive transactions (with valid as a level signal), will the crossbar immediately forward all three transactions(like receiving data from slave interface can keep aready hold 3 clk )?

  3. It seems that the master/slave num parameters can be adjusted to any number. However, I noticed that the top is set to 4x4. If I change it to m=2 and s=2, will it still work as expected?

Thank you for your patience in reading my questions.
I greatly appreciate your assistance and look forward to your response.

@dpretet
Copy link
Owner

dpretet commented Dec 26, 2024

Hello,

thanks for your interest for this IP :) Good to see somebody is exercising it with UVM.

1/ Do you mean you have a wrong BRESP value or the whole write response channel is not forwarded? In my environment, I didn't notice any problem with BRESP. Maybe could you attach a waveform so I could take a look to help you (VCD format).

2/ Yes, the core will forward all the transactions as long you configured enough outstanding requests (MSTx_OSTDREQ_NUM and SLVx_OSTDREQ_NUM). All channels are fully independent in AXI.

3/ No, for the moment you can't change the number of masters and slaves. The parameters are placeholders for a future update. Please refer to #12 and #13 for more details. The switching fabric needs few updates to support any number of master and slaves. Probably I'll do it in the next months, for the moment I work on #9.

Best,
Damien

@datachiii
Copy link
Author

datachiii commented Dec 27, 2024

Hi Damien,

Thank you so much for taking the time to reply. I truly appreciate your guidance and support.

The response channel is stuck, and the read channel is in the same situation.
(a) In the B channel, the master interface successfully received the response from the slave and sent it to the crossbar.
But that resp in the crossbar is not forwarded to the slave interface.
(b) In the R channel, the iready signal in the master interface (which I think corresponds to the valid signal for the crossbar) drops, leading to the master interface can't transfer data to crossbar.

Maybe my parameters setting are wrong?
I see the check limit mask id must be greater than 0
This means id 0-15, it can't identify where it comes from?

VCD waveform
Top module (modified to fit my environment)
file.zip

@dpretet
Copy link
Owner

dpretet commented Dec 28, 2024

Hello,

I took a look to the waveform and many things are incorrect.

  • srst is unused, but you don't tied them to 0. Read the documentation about clocks and reset to understand how to connect that correctly
  • IDs are very important to help routing the completion back to the original master. In the waveform, I see for instance the first read request with ARID=0x01, but you setup MST0_ID_MASK = 0x10. So all request must use this mask. Please read the documentation explaining the routing rules in the AXI fabric of the core.
  • many signals are X or Z, please drive them to ease waveform debug.

To start your journey, I would advise you to run the simulation and check the waveform generated. The test REDAME explains how to execute a test case.

Best,
Damien

@datachiii
Copy link
Author

datachiii commented Dec 30, 2024

Hi, Damien
after reading your document,
I have implemented a restriction on the range of IDs output by the pattern.
It successfully worked in the my 4-to-1 test case. Thank you very much for your help,
and I look forward to your future updates!

@dpretet
Copy link
Owner

dpretet commented Dec 30, 2024

Good news bro, have a good journey 😎

@dpretet dpretet closed this as completed Dec 30, 2024
@datachiii
Copy link
Author

datachiii commented Dec 31, 2024

Hi Damien,

I greatly appreciate your help earlier. I successfully implemented the 2-to-2 with the outstanding.

Currently, I am testing the DECERR testcase, which means the address sent by the master is outside the slave's address range. I noticed that in the waveform, as soon as the AW signal reaches the crossbar from slave interface, crossbar immediately determines that a DECERR should be sent, without waiting for WLAST. In other words, as soon as the W signal is sent to the crossbar, the crossbar simultaneously sends out BRESP (DECERR). This behavior seems unusual?
Could you kindly confirm if this is expected?
wave

Additionally, I observed that if both AW and W are sent from the VIP at the same time, the W signal enters the crossbar one clock cycle later than the AW signal when passing through the slave interface (as the crossbar's ready signal is asserted later). Could this be due to the need to ensure the address is valid (i.e., no DECERR) by waiting for the AW signal to arrive first? I’m wondering if my assumption is correct?
wave

Thank you for your assistance again!

@dpretet
Copy link
Owner

dpretet commented Dec 31, 2024

Hello,

Yes it’s expected, but I know it’s not very compliant with AXI4. I implemented this behavior to save area. Moreover, it could cause an ordering problem if several requests with the same ID are issued but one is misrouted. I planned to fix the ordering rules for read request with #9 but the write channels for this corner case definitely deserve a fix, thanks for pointing it ! Good to see somebody is exercising the core with a true verification flow and a VIP 😎 Can you tell me which simulator and VIP are you using?

Best,
Damien

@datachiii
Copy link
Author

datachiii commented Jan 2, 2025

Hi Damien,
I greatly appreciate your clarification. I am using VCS and UVM VIP.

  1. Yes, According to the AXI4 specification, bvalid should only be asserted after aw & wlast handshakes are completed. but I totally understand why you would implement it this way because if the address is incorrect, the response must return DECERR regardless of the wdata. error handling is reasonable although it is a little bit unusual. Like mentioned before, to handle DECERR, aw need to sent to crossbar first before w to ensure that data is not written to an illegal address, even though spec doesn't limit aw before w.
  2. I also have another question:
    why is a FIFO necessary in this system if not cdc? From my understanding, Is it used to handle outstanding transactions? like when the slave is not ready(if not ready and many requests maybe outstanding_size should be bigger? cuz relates to buffer size), it needs a register required to store the data temporarily?

Once again, I sincerely thank you for your time

@dpretet
Copy link
Owner

dpretet commented Jan 2, 2025

Hello,

Yes, FIFOs are used across the core as buffers for outstanding requests storage. If an interface and the switch core are synchronous, I use single clock FIFO, else I use an asynchronous (dual clock) FIFO to handle the CDC.

Damien

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants