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

Wishbone master gives pop from empty queue error in Modelsim #692

Closed
abyszuk opened this issue Nov 12, 2020 · 5 comments
Closed

Wishbone master gives pop from empty queue error in Modelsim #692

abyszuk opened this issue Nov 12, 2020 · 5 comments

Comments

@abyszuk
Copy link

abyszuk commented Nov 12, 2020

I have a problem driving simple Wishbone slave from VUnit WB master. It fails already on the first transaction with message
Error: Pop from empty queue. Waveform of faulty behaviour looks like this:
image

After a bit of investigating I've found out that error comes this process:
https://github.com/VUnit/vunit/blob/master/vunit/vhdl/verification_components/src/wishbone_master.vhd#L146
which is receiving message sent here:
https://github.com/VUnit/vunit/blob/master/vunit/vhdl/verification_components/src/wishbone_master.vhd#L97

I think that the problem is connected with delta cycles. My WB slave logic looks like this:

ack_int <= rd_ack_int or wr_ack_int;
wb_o.ack <= ack_int;
wb_o.stall <= not ack_int and wb_en;

The wb_o.ack and wb_o.stall signals are set in the same delta cycle. But it looks like WB master expects that ack should be set at least one delta cycle later (assuming that I correctly understand how VUnit message passing works).

@slaweksiluk is my reasoning correct?

VUnit 4.4.0
Modelsim SE (Linux) 10.7a

slaweksiluk pushed a commit to slaweksiluk/vunit that referenced this issue Nov 12, 2020
Fails on modelsim, but working properly on ghdl.
slaweksiluk pushed a commit to slaweksiluk/vunit that referenced this issue Nov 12, 2020
@slaweksiluk
Copy link
Contributor

It seems yours wb slave use combinatorial ack response? I reproduced it, but only on modelsim. Ghdl does not need fix. It looks like race condition, but according to it should never happen in VHDL? So one of the simulator is wrong, question is which one.

Moreover I remember I had some ghdl/modlesim mismatches in my testbenches, but couldn't figure out the source of problems. This issue might prove something is wrong with delta cycles ordering.

@abyszuk
Copy link
Author

abyszuk commented Nov 12, 2020

My wb slave is generated with Cheby generator
I'm attaching the example file it generates (mind the extension - Github limitation).
qsm_regs.txt

I'm not sure if this really shouldn't happen. ACK and STALL should be asserted in the same delta cycle.
If so, then both processes in WB master should be woken up at the same time. But they can't really be executed at the same time in simulator because internally everything is single threaded. And if that is true then (I think) it boils down to which process is evaluated first within a delta cycle.
At least that's how I understand it.

Below is expanded delta cycle view from Modelsim:
image

@slaweksiluk
Copy link
Contributor

What I'm not sure about is if VHDL LRM permits implementation dependent behavior - which we see in this case as modelsim gives different result than ghdl. Anyway, does the fix in slaweksiluk@91b7790 work for you?

@abyszuk
Copy link
Author

abyszuk commented Nov 13, 2020

Yes, it fixed this problem. Thank you!

Now I see another problem. It seems that WB master is dropping transactions if I queue them without any pause in-between:

write_bus(...);
read_bus(...);
write_bus(...);
(...)

But it works properly if I add wait_until_idle() calls after each transaction.
I didn't have time to investigate this properly yet. I'll give you an update after the weekend, after I'm done with current deadline at work.

@slaweksiluk
Copy link
Contributor

ok great, please close this issue and do not hesitate to open new one when more bugs found

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

No branches or pull requests

3 participants