07-24-2019 11:16 PM
Using Vivado 18.3
I've written a module to interface to the Master AXI-Stream interface of the AXI4-Stream FIFO v4.2 (pg080). Sadly it isn't working. I've simulated the module with what I "think" the FIFO is doing however it is only my interpretation.
Is there a simulation model around for the FIFO? I've considered just instantiating the FIFO in the test bench but I'm uncertain how to configure it or fill it full of data without first having to model the AXI-Lite interface. If there isn't a simulation model is it possible to force the configuration registers and data using the simulator?
Saving that, is there a generic AXI-Stream model that I can use to make sure my peripheral AXI-Stream slave interface is behaving.
I guess this is a lot of open ended quesitons. Ultimately I need to be able to model the interface so I can see why my module isn't getting data.
07-25-2019 01:58 AM
If I rember, try searching for BFM
the AXI Bus Functional Model
07-25-2019 02:12 AM
According to Xilinx "AXI BFM will be replaced by Xilinx AXI Verification IP in CY2017"
I've looked at using the AXI VIP and the AXI Traffic Generator so far.
I can't figure out how to drive the AXI VIP (I don't understand what the datasheet is telling me to do!) and the Traffic Generator just gives me unintelligable errors when I try to verify the design. Looking up the errors doesn't help.
So at the moment I'm stuck on how I can simulate and verify a simply AXI Stream interface. I thought the AXI bus was meant to make life easier .....
07-25-2019 04:00 AM
I thouhgt you had solved your FIFO problem by setting the TLAST attribute. Are you now still struggling again?
That was for when I was the AXI-Stream master talking to an AXI-Stream FIFO slave.
I'm now trying to understand the interface between the FIFO as the stream master and another module that is a stream slave. I'm doing something subtly incorrect I'm sure.
I'm finding it is almost impossible to find timing information that is usable for the FIFO Master AXI Stream. For example when the FIFO has data does it keep the TValid asserted 100% of the time, how does it respond to a TReady. I'd love to see a timing diagram but I can't find one.
The Xilinx FAE has basically told me "that it is not his role to train me". So at the moment I'm a little stuck and relying totally on help from the wonderful folk on this forum.
07-25-2019 04:16 AM
The Xilinx FAE has basically told me "that it is not his role to train me". So at the moment I'm a little stuck and relying totally on help from the wonderful folk on this forum
Ahm, okay ... so the first rule of AXI is that nothing happens unless xVALID & xREADY are true together on the same clock. The second rule of AXI is that if ever xVALID & !xREADY on one clock, the data must remain constant onto the next clock.
The subtle rule for building an AXI component that meets this criteria is never checking for xVALID & xREADY & something-else. If you do this, you will be guaranteed to drop data.
A second rule of AXI is that no combinatorial paths are allowed between inputs and outputs. Any stall signals you might have need to be registered. This means you'll need skid buffers, so that once you set a stall signal (i.e. !xREADY), it can still take a clock in order to take effect without losing data..
According to the AXI stream FIFO guide, it takes a couple clocks from the time you write data to the core until that data is available to be read on the other end. So while xVALID is equivalent to not_empty, it's not so quickly set. Other than this delay, I would just that the xVALID line should be high if ever there were data in the FIFO.
That said, many of the Xilinx products I've examined don't fill the AXI connection with data on every clock cycle. Their AXI-lite GPIO core take 4-5 cycles per write (IIRC)--cycles where data could be transmitted but it isn't. Their AXI-lite core takes a minimum of 2 cycles per transaction. Their full AXI core can handle one cycle per beat on the write interface, but not the read interface. Returning to the data sheet for this core, you'll see that in spite of the fact that the core can handle 32-bits input on a 100MHz clock, the fastest it can transmit data is 64MB/s. That means that there's about 5 clocks uncounted for somewhere between values. It may be that the core also lowers the xVALID line during this time as well.
Hopefully that's enough to get you started. If not, feel free to share some code and I might be able to make a more specific comment about something you are struggling with.