ZipCPU
commented
2 years ago To start a transfer, you'll need to write to the control register to set the busy bit. I tend to also automatically clear the error bit at the same time, since the design will not start once an error has been received until the error is acknowledged. You can find the start logic here, and learn of how I'm handling the AXI-lite control bus here--should you be interested. If you use a declaration like this:
typedef struct S2MM_S { unsigned a_control; unsigned a_unused1[3]; unsigned *a_dest; unsigned a_unused2; unsigned a_len; unsigned a_unused3; } S2MM;
and declare a variable as,
static volatile S2MM const _s2mm=((S2MM ) / your S2MM address /);
you should then be able to kick the transaction off with:
// Set the two high bits of the control register // Bit 31 starts the transaction // Bit 30 clears any prior transaction _s2mm->a_control = 0xc0000000;
If you look here, you'll see where I kick it off in a Verilator based simulation.
The control register offers other options for dealing with the IP as well. For example, if you want to make sure that the IP never drops samples, you can set r_continuous (bit 28). This will create backpressure (I know, you can't handle backpressure ..) when the design is idle or the FIFO is full. It will also ready itself for a next transfer even while the FIFO isn't empty. There's a third benefit to r_continuous: the design will then tell you about any overflows, by interrupting the CPU and setting the overflow flag.
If your design is busting the 4kB boundary with its burst size, then that is an error that I will fix. I can look at that today. As a temporary fix, you can set the LGMAXBURST local parameter to the maximum burst size for your data width. Something like:
localparam LGMAXBURST = $clog2(4096 * 8 / C_AXI_DATA_WIDTH);
A "proper" fix (which I'll work on) should clip this at a maximum of either 8 or half your FIFO size, but the above should work as a temporary fix if you already know that you are breaking the 4kB boundary. Once fixed, AWLEN should range from zero to (1<<LGMAXBURST)-1. (If your address isn't aligned with the burst size, then the first burst will attempt to align it --- so not all bursts will start with a full length.)
Beware of configuring the IP for packet sizes other than those you expect. Unlike Xilinx's IP, which will halt on TLAST, this IP will transfer the length you request independent of when/where TLAST shows up. I consider this a "feature", but it might surprise those who are familiar with Xilinx's IP. (Stopping on TLAST is a future capability I would consider adding as an option ...) If you sync on TLAST, the S2MM IP will then wait until it sees a TLAST before it starts collecting at the top of the next packet. This means that, if you configure the IP for a packet size of 256 and send a packet of size two followed by a packet of size 256, the IP will copy 256 items from the stream to memory--2 from the first packet and 254 from the next, before
The design does put a bit of a timing load on S_AXIS_TREADY, so if you struggle to meet timing then a skid buffer might be appropriate on the input AXI stream. I think Xilinx calls these AXI slices. It should be easy enough to add one to the IP if necessary.
Dan
baileyji
Hi Dan, Managed to get the core implemented without too much trouble and have (I think) a rudimentary python driver (gist here) for in with PYNQ (interestingly the core shows up as a PYNQ Heirarchy around a DefaultIP, I suspect because of the way vivado wraps RTL in block designs).
The short of this is "How does one move the core from "idle" to "busy"?
From the ILA I see that data is passing through the core (WDATA is toggling) and after writing an address with my driver it is read back as I'd expect and I see AWADDR outputting the value I set so I don't seem to have an endian issue (0x500000000, the base address of some MIG DDR4 I'm using).
After writing length I can read that back and what I set it to impacts AWLEN but no writes have been issued. the command register always seems to be reading 0x90000, which I infer is telling me the FIFO is 512 long (as I set in vivado).
AWLEN started out at 255 (and stayed there for any large transactions), which as I understand it, is not a legal value for a burst with 256b TDATA (anything above 128 would cross a 4k boundary). Even if it is formally allowed, I've repeatedly seen xilinx docs that indicate crossing that boundary is not a good idea, so I'll be keeping an eye on if the smartconnect or MiG chokes.
I've looked though the verilog to see how I should tell the core to start and short of a couple of bits you have labeled as "reserved" but in fact seem to be related to start and prestart I'm drawing a blank.
Apologies if these implementation details aren't familiar or are largely irrelevant. I figure more (clear) info is better than less.
Finally, quick note on how I'm planning to use this: I feed it a stream that asserts TLAST between every other and every 256th clock (not transaction). So the stream will have between 2 and 256 beats every 256 clocks (generally this will be steady state, i.e. the same 128 beats out of 256 possible will be there every time, over and over). The core does not accept back pressure (its TREADY input is tied high as its fed from and ADC). I'd configure axis2mm to sync on TLAST (a very nice bonus) and capture some multiple of 32 (bytes) N (active beats i.e. 128) M (the number of sets I want, ~0.5-4 GiB of data). I'd start the core and let it spew unmolested into the MIG (which does have enough bandwidth) with it finishing after the total number of bytes and hopefully not griping that it has seen M TLAST assertions along the way.