07-01-2021 09:15 AM
I am currently facing a problem whilst attempting to exchange data between the PL and PS of a Trenz Electronic TE0808-04-BBE21-AS MPSoC module. The following test fails my expectations:
07-23-2021 04:05 AM
I just took a quick read of your VHDL design looking for common errors. I found two.
While not technically a bug, let me note that you've set the respective xVALID lines to 0 on every clock cycle, only to be overridden by the logic following. A better choice might be to set them to zero if xREADY is true.
07-23-2021 08:54 AM
No, you're not there yet. Here are the first two bugs I found:
The first bug is that you can't test for RLAST without also testing for RVALID && RREADY. Unless RVALID && RREADY are both true, RLAST is meaningless. In this case, because you don't check for RVALID && RREADY, your design moves on to the write stage of the design and lowers RREADY. The read channel of the bus will then hang. In the best of cases, you might come back and get the burst on the next time around--but then you'd be way out of synch.
Will RLAST always be high when RVALID is low? No. But if RVALID is low then you can't depend upon its value.
The second problem I found was in the write channel. In this case, your first beat of a 64-beat packet starts with WLAST set.
When setting up this test case, I was surprised that your design doesn't have an AXI reset input, ARESETN. This will also lead to a protocol error. Your state machine and your AWVALID, WVALID, and ARVALID signals all need to be reset if ARESETN is ever low.
FYI: The trace above came from a 2 second formal verification run. It took me longer to set it up, snap pictures of the trace, annotate them, and write back than it did to find the bugs themselves.
07-23-2021 11:44 AM
I was acting under the impression that the protocol only allows for an xLAST signal to be asserted during xVALID. I see now that, to quote the AXI specifications: "The master must assert the WLAST signal while it is driving the final write transfer in the burst", does not imply it cannot be asserted otherwise.
As for the WLAST starting out asserted, I have no idea why. Maybe you modified the code? It should start out undefined:
When it comes to the reset signal, I plan to test the design on a reconfigurable partition, and as far as I understand, all registers are cleared upon writing the bitstream. Therefore I thought I had no need for a reset. Would you have it there in any case?
On a different note, mind telling me what HDL simulator you use?
Thanks again, Dan.
07-23-2021 12:16 PM
The reset signal is a required AXI signal, perhaps all the more so if you are trying to work within a reconfigurable partition.
I generated the traces using SymbiYosys, and plotted them using GTKWave. The formal properties I used were my own. SymbiYosys also selects values, 1'b0 or 1'b1 to any disadvantage it may cause, for values that would otherwise be 'x. That's why WLAST wasn't 'x, but rather a value chosen by the solver to your disadvantage.
When I need to do simulation, I tend to chose Verilator. Verilator works by converting Verilog (not VHDL) source to C++, and then running the C++ as the simulation. It does not implement 'x values, since 'x isn't supported in C++. Verilator doesn't necessarily play well with Xilinx's IPs, but then I'm not known for using Xilinx IPs. When Verilator doesn't work for me, then I've been known to use Icarus Verilog or (on one project) XCellium. (I'm not much of a VHDL type.)
07-27-2021 05:33 AM - edited 07-27-2021 05:35 AM
You're right of course, I marked your reply as the solution. Thank you again.
I get the expected results doing one of the following before reading the DRAM:
The functions are declared in xil_cache.h.