-
Notifications
You must be signed in to change notification settings - Fork 136
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
Single Cycle CFU instruction issue with Vexriscv #747
Comments
Hi Bala: have you seen this bug when running under Verilator? The trace files produced by Verilator are a great debugging tool for this kind of issue. If the problem is still not obvious then, could you please point to your code and post a picture of the traces (as seen in, say, gtkwave) across the CFU interface. Thanks! |
Hi @alanvgreen , |
Hi @bala122 , sorry I missed this (thanks @alanvgreen !). I'm glad you figured it out. Did the waveform capture help with debugging the issue? |
Hi @tcal-x , |
Hi @tcal-x and @alanvgreen ,
I've checked my cfu interface as well, cmd_ready and cmd_valid are asserted. Im not sure if it's vivado or some issue in CFU itself. I'll try with a multi-cycle interface and let you know if it persists. |
Also @alanvgreen , @tcal-x , |
Hi @bala122 -- when you say simulation, do you mean using Renode ( You can look at the closed PRs on github to see what has been merged since your last update (unfortunately, it takes a bit more work now with all of the semi-automated Renode and TFLM updates). If you were using Verilator simulatino and did NOT see the same error, then that does point to an implementation issue, possibly although unlikely a bug with Vivado, but more usually not meeting timing. If you were using Renode, then there may be a logic error with the CFU interface, on either side. There may be an issue when a CFU instruction immediately follows a conditional branch -- it is worth checking the disassembly (build/software.elf.dis) to see if this occurs. If so, you can try inserting a no-op between the conditional branch and the CFU instruction. Here's an example of adding a no-op in the C/C++ code: https://github.com/google/CFU-Playground/blob/main/common/src/perf.cc#L147. |
Hi @tcal-x , @alanvgreen and @mithro ,
Please try to reproduce this issue (2nd one could be easier) and see if it occurs for you. I'll try to get some simulation data for this. Unfortunately, it takes a very long time to run the trace as well and at times I've seen that it gets stuck in simulation (hangs at cfu commands) while in synthesis it finishes with the above bus malfunction. Anyway, I'll try to get some trace data for this. Thanks, |
I'll have to confirm the 2nd issue again- I'm sorry, I'm guessing it was a design issue regarding my CFU instruction decoding, where upon examining the trace, I've noticed it resetting all my accum regs often when I didn't intend to. However, I've still seen instances of bus issues a year back when I was performing a verilator simulation and I had to run the cfu command twice in order to get back accumulator values. |
@bala122 thanks for the update; I'm trying to find time to take a closer look. |
Hi @tcal-x and @mithro ,
I'm experiencing issues with the working of the Vexriscv core, it's CFU bus and execution of single cycle CFU instructions.
Take the below case, where I have a bunch of single cycle cfu instructions running in a loop.
What Im seeing is that some of these instructions , say cfu_op1(3,0,0) are executing twice , even though I didn't intend it to. I have experienced this before with the multi-cycle cfu interface with the Vexriscv core. However, I assumed that the single-cycle cfu interface+ Vexriscv core would work. Do I pull the latest version of the g-cfu repository and have you guys come across this and resolved this bug or is this still there in the Vexriscv core?
Please suggest alternate methods to resolve this as well.
This is the cfu single cycle interface Im using:
Thanks,
Bala.
The text was updated successfully, but these errors were encountered: