Digital Signal Processing - IP and Algorithms

[david_va]

I'm importing the XFFT core to XPS using the create/import peripheral wizard, and specifying an AXI4-Stream interface.  The wizard creates a template with the usual AXI4-Stream signals (slave and master TREADY, TDATA, TLAST, TVALID).  I'm instantiating the XFFT core created by coregen inside the template, but the core has many more signals, including master and slave config TDATA, TREADY, and TVALID; master status TDATA, TVALID, and TREADY; and event signals.  My end goal is to connect the XFFT to an AXI VDMA, but the VDMA Stream outputs don't seem to contain the config, status, and event signals...how should I manage the extra signals on the XFFT to be sure XPS will be able to correctly connect it to the AXI VDMA?

[bwiec · Accepted solution]

I would say it kind of depends on your system.

My guess is that you're going to need some sort of logic 'shim' between the two cores or at least handle some of those extra signals. You will want to consider that the VDMA is sort of generic in the sense that it just takes streaming data and pushes it to memory. It doesn't necessarily expect an 'FFT' core to be driving it. Many things can drive it, so in that way, it is generic. Yes, the data (AXIS) interfaces should be compliant, but the FFT core has many other features that the VDMA doesn't care about that need to be taken care of by you.

Perhaps a block diagram or something would be helpful.

[david_va]

I see what you are saying regarding the logic 'shim'.  I'll give that a shot.  I took a look at the XFFT MPD file as well, and it's more clear how the signals are assigned to the AXI4 Streaming bus.  I think it'll be possible for me to route the config, status, and event signals to some software-accessible memory-mapped registers in a logic 'shim' off of the AXI4 or AXI4-Lite bus, and leave the data signals connected to the VDMA for normal streaming operation.  Thanks for your help.

[david_va]

I'm stuck.  The XFFT is not functioning in my design and I can't determine why.

I generated a simple XFFT pcore and simulated the HDL files.  I've attached the HDL and MPD files for the core.  Here are the simulation results:

It is functioning in simulation.  The testbench loads normalized values from 0 to 63 into the XFFT, where a value is loaded once every two clock cycles by asserting S_AXIS_TVALID high for one cycle.  The data is processed and output after an expected delay, where the yellow cursor is.  I am using version 8 of the XFFT with the AXI4 Stream bus.

I have the XFFT connected to an AXI VDMA in XPS, where the VDMA MM2S channel is the master to the XFFT, and the XFFT is the master to the S2MM channel.  I'm using a software application to control the design.  I've verified through Chipscope that the VDMA does transfer data to the XFFT (I'm only using one "frame" of 64 values at the moment).  The bus being monitored below is the MM2S from the VDMA, which is attached to the S_AXIS on the XFFT:

However, nothing comes from the XFFT core.  The following capture is a forced trigger on the M_AXIS from the XFFT, which is connected to the S2MM bus on the VDMA.  These values don't change:

I have verified that the VDMA works by connecting its MM2S and S2MM buses and reading and writing the same data to different areas in memory.  At this point I'm pretty sure something is going on with the XFFT, but I can't determine what.

My theories at this time are:

• The AXI4 Stream signals on the XFFT are not being assigned correctly (I had to do the port descriptions in the MPD file by hand)
• The XFFT doesn't "see" a full frame of 64 values from the VDMA, though it should based on the Chipscope results
• Microscopic boogeymen hiding in the transistors

However I'm not sure how to debug those theories so any advice would be greatly appreciated.  I've also attached the MHS file for better clarity of the XPS design.

[david_va]

MHS File:

[david_va]

Here's the VHDL, I had to rename the extension because the forums weren't allowing me to attach vhdl.  I apologize for the multiple posts, I couldn't see a way to attach multiple files.

[bwiec]

How many points in your FFT? 64?

If you're concerned that things may not be hooked up correctly, you might want to probe the signals on the FFT core itself, to make sure data is actually making it all the way to the core. Especially since the VDMA is working for you. That way, we can determine if it is something in the core itself or the interface. Also, you may want to probe the event signals of the FFT too. This can give more clues.

I'd be curious to see what tvalid looks like further back. It looks like it was high for a while before the start of the chipscope capture.

Also, how fast are you running this design? Are you meeting timing?

[david_va]

Hi bwiec, thanks for the reply.

My FFT is configured to a transform length of 64.

I am meeting timing for the design, or at least EDK is not throwing any errors during synthesis.

As for TVALID, here's a capture with data before the trigger:

I'm in the process of setting up chipscope to probe the FFT signals directly, I'll post again when I get the results.

[david_va]

Well, I found the problem, but still don't have a solution.  The reset signal to the core is not getting assigned correctly (and I suspect maybe the clock too, though the synthesizer didn't like me trying to scope the clock), so it's staying in a constant reset state.

Here's a chipscope capture with the slave, master, and event signals on the instantiated FFT core:

The ARESETN is always 0, so the core is always reset.  I've attached the MPD file for the core again.  I know from my initial chipscope captures that the reset signal is 1 at the port to the core wrapper, but doesn't seem to propagate to the XFFT correctly.  How should I make the assignment in the MPD so it does (I'm assuming the HDL is correct since it's a simple port to port connection)?  There's an attribute line in the HDL:

attribute SIGIS of ACLK : signal is "Clk";

Do I need a similar line for the ARESETN signal? 

[bwiec]

Hmmm I don't see anything immediately obvious that is wrong with your setup/code.

Can you look in XPS in the ports tab of your xfft pcore. Drop down the AXI bus interface and make sure that the reset is being correctly assigned.