04-19-2019 04:12 PM
Today I ran into my typical problem with IP. Almost everything in the library has an AXI wrapper! AXI is fine for a lot of things, but in signal processing, some of us learned how to string blocks together with synchronous clocking such that FIFOs and handshaking (with their attendant real estate and power consumption) is not needed.
Today's example. The FIR compiler sounds like a wonderful tool. I have a product that needs several FIR filters with clock speeds ranging from 3.6 MHz down to 300 kHz. The ability of the compiler to optimize this and to overclock DSP blocks to pass multiple channels through a DSP block all sounds wonderful. It eliminates a lot of detail grunt work. Until you realize that each resulting DSP block is going to consume a few hundred LUTs for AXI stream interfaces that would accomplish absolutely nothing in my applicaton (except maybe get in the way and make me add more interface code to connect to them).
I also need two channels of CIC decimating filtering. Same problem. There's more AXI in those than filter!
So why can't we have a checkbox that enables or disables the generation of the interface?
I tried persuing an alternate approach--let it desing the thing and then edit out the AXI from the resulting verilog file. No joy. It doesn't produce a usable, editable verilog file. Foiled again. Guess I'd better start desiging an optimized FIR filter of my own from prmatives. Basically I can't really use most of the signal processing IP, because of its bloated interface. And this has nothing to do with the fact that the Arm processor uses AXI, because this doesn't even connect to the processor. It is just a set of RF signal processing blocks.
04-19-2019 06:58 PM
04-20-2019 06:06 AM
@whelm "AXI is fine for a lot of things, but in signal processing, some of us learned how to string blocks together with synchronous clocking such that FIFOs and handshaking (with their attendant real estate and power consumption) is not needed."
Yes! The everything-is-AXIS syndrome is quite annoying, e.g. Vivado SysGen changed the 'Complex Multiply' to only support AXIS, and moved the 'simple' pipelined complex multiply to 'Product'.
I've found that using a simple AXIS subset (data,valid,last) with no backpressure, along with simple shims (e.g. error flag on !READY | skid buffer | small fifo) to interface to any Xilinx IP cores that require the full control set, works out fairly well without adding much overhead to one's own code.
> Guess I'd better start desiging an optimized FIR filter of my own from prmatives.
There's an example of a full rate systolic FIR, inferencing DSP48s, over on this thread:
I've used the UG901 DSP48 inference examples ["Even Symmetric Systolic FIR"] to write similar code in the past.
04-22-2019 11:33 AM
Yes, it is frustrating. Any competent designer of streaming protocols for things like SDR knows how to flow signals synchronously through succesive blocks. The ADC or logic that is the signal source never stops supplying data at a fixed rate (and the DAC or logic that ultimately consumes the output never stops accepting data at a fixed rate). In between it is quite easy for any decent designer to flow that data through without back pressure and without any ready signals. The whole concept of asynchronous flow control in signal processing is a mark of ignorant, sloppy or lazy designers, and Xilinx should be ashamed of themselves for supporting it, let alone forcing it on users. A DSP block needs only an input clock, input data, and possibly an output clock (either as an input or an output). Anything beyond that is sloppy design. They could at least make the AXI interface an optionally selectable feature.
08-13-2019 03:46 AM
Is it possible to generate netlist using ISE (FIR compiler v5.0 without support to AXI) and use that in Vivado in anyway ?
I have one DSP design module using FIR's, DDS and other DSP IPs (without AXI) targetted for Spartan6 and now required to port the design to Ultrascale+ .
Problem here is when generating netlist in ISE can't target to Ultrascle+ and Vivado dont' support Spartan6.
Taking EDIF output from ISE using in Vivado for Ultrascale+ work ?
If required I can create a new thread.
08-13-2019 04:07 AM
If you know what cycle your sending body has valid data and you know your receiving body can accept in that cycle you don't need the asynchronous flow control in AXIS, just connect tvalid to tvalid and tie tready to high. AXIS is really a very small interface, fits easily with old style FIFOs too with few logic added, you can just do away with the things you don't need and the synthesis tool will remove the logic behind.
The FIR-compiler is great, unfortuately it is extremely slow trying to simulate the output from it, that's the main problem I have with it.