11-15-2012 01:27 PM
I'm trying to use the axi_vdma core (v5.02.a) on a Digilent Atlys board to receive HDMI input, write it to memory (for processing), then output it over HDMI.
I have been using the axi_hdmi core and following the documentation provided by Digilent in DSD-0000332 (from http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS), just making the addition of setting "C_USE_FSYNC = 0" in the VDMA core, otherwise the output from the HDMI port doesn't work.
So far, I've managed to get the output working, displaying a pattern I've generated and put into memory using the MicroBlaze.
The problem comes when I add in HDMI input, by enabling S2MM in axi_vdma and connecting it up to the reciver of the axi_hdmi core. With the same code running on the MicroBlaze, the initialisation of the VDMA core now fails and returns an error.
I've tracked it down to the write channel reset timing-out in xaxivdma.c (around line 259), which explains why it works fine when S2MM is not enabled, but I have no idea why the channel won't complete its reset. I've tried increasing the timeout, but it just never seems to finish the reset.
Does anyone have any suggestions as to why the write channel isn't resetting correctly?
I've attached my system.mhs and the C file that works fine for initialising the VDMA core when it just has output connected.
11-15-2012 05:54 PM
Hmm, there was a known issue in another function of the driver with an incorrect soft reset being called. This looks like the same kind of thing. Can you try and just comment out the soft reset in the driver and see if it helps?
11-16-2012 04:36 AM
If I remove the reset of the write channel, it doesn't come up with the error, and the C file I attached last time does run, however the write channel then doesn't work later in the program.
For example, if I use the full xaxivdma_example_intr.c file (attached), it fails when trying to set the frame store of the write channel, which is the next operation that uses it.
Therefore it does look like the reset is necessary in xaxivdma.c, so I can't just get round the problem by removing it.
Do you have any other suggestions about what could be causing the reset to never complete?
As far as I can see in my system.mhs file, the read and write channels are both connected up the same, so I don't see why one is resetting fine while the other isn't.
11-16-2012 05:25 AM
11-16-2012 06:41 AM
Yes, the reset in XAxiVdma_SetFrmStore is the one I was talking about before (known in v5.02.a of the core and v4.01.a of the driver). This one can be safely removed and I suspect the other one you found is in the same boat. The core actually wipes the configuration registers (back to their initial state) after a soft reset. Therefore, you can see why calling at the end of a configuration function is self-defeating.
Anyway, moving on. It sounds like you're making progress slowly. So where does the code get stuck now? You might try reading back the VDMA registers with XMD and posting those as well.
So that example code assumes you have hooked up the interrupts from the VDMA to an interrupt controller in the system. I see your interrupt controller isn't connected to any of the VDMA signals.
static XIntc Intc; /* Instance of the Interrupt Controller */
static XScuGic Intc; /* Instance of the Interrupt Controller */
11-17-2012 09:00 AM
Thanks again for your help.
After connecting up the interrupts, and trying a different HDMI source (one that doesn't appear to care about EDIDs and things, and just transmits continuously) I've managed to get some kind of video input.
I've tried re-enabling the reset code that I commented out, now that I'm using a diffent HDMI input, and the system still seems to work. I think the hanging may have been caused by the S2MM interface not getting any fsync signal (or something similar) due to the way it's wired up to get this from the axi_hdmi core, and no HDMI input being present to send a signal.
I think a poor axi_hdmi core from Digilent is to blame for some of the issues (as well as slightly incomplete documentation that doesn't mention connecting interrupts or changing FSYNC settings), and the EDID/DDC implementation in the core also doesn't appear to work properly, or at least not for the HDMI devices I've tried.
Now, my HDMI input is working to a point, but the signal isn't syncing properly (see attachment). This may be down to the axi_hdmi core though, rather than axi_vdma as it doesn't seem to like actual HDMI input (i.e. HDMI with audio rather than DVI-style) - something like http://forums.xilinx.com/t5/Spartan-Family-FPGAs/xapp495-bugs-S6-DVI-HDMI-input/m-p/137964.
I had similar problems with sync with the PLB HDMI example from Digilent - both that and what I'm using now are based on xapp495.
My idea now is to try to get parts of xapp460 (which has both DVI and HDMI decoders) and mix it with the xapp495 bits in the axi_hdmi core (which has just a DVI decoder) and hopefully that will sort out syncs (unless the problem is still with the axi_vdma core).
02-06-2013 08:25 AM
Hi russelljoyce, I am wondering if you manage to solve this problem with the digilent axi hdmi and axi vdma? I am trying to do the same thing, and I just see noises on the display.
02-21-2013 08:30 AM
I have having the same problem.
In xaxivdma.c, line 256, the reset to the write channel does not complete.
Is this fixed in the newer version or is the workaround just to comment out the reset. Russel, did you have any luck in getting this to work? What was the final workaround?
Any info would be great.
02-25-2013 04:15 AM
In the end I found that the write channel will reset only if it has an active signal on the HDMI input port - I believe a part of the core clocks off the HDMI signal, so if it's not there it will just time-out while waiting for the channel to reset.
One thing to note though: a lot of HDMI sources require valid EDID information to be received before they'll start transmitting any other data over the cable. I've found some sources don't need an EDID (a cheap component-to-HDMI box I have, for example, sends video as soon as it detects a cable), but most do (all computers that I've tried just ignore the HDMI connection until they get an EDID). Also some are more picky than others about reading an EDID (my MacBook seems to want to read the EDID about three times before it's satisfied with it, where a different PC just reads it once).
I've found the default EDID implementation in the axi_hdmi core to not work reliably for some sources. In the end, I disabled it (through the core options in EDK) and connected up an I2C core to the DDC pins on the HDMI input port instead, like is done in the older HDMI demo from Digilent (DSD-0000326 at http://www.digilentinc.com/atlys). I did have to tweak the MicroBlaze C code from this a bit in order to get it working, as the default seemed to send the EDID too fast and it wasn't getting to the source properly.
I've attached a cut-down copy of what I'm using for the MicroBlaze code to set up my HDMI, VDMA, and control the EDID over I2C. It won't work as it is, but will hopefully make a useful starting point. What I did intially to get this working was have the VDMA setup trigerred by a button on the board, so I could start it manually once I knew the EDID transmission was successful.
It certainly took a fair bit of time and effort to get AXI HDMI working nicely on the Atlys, but it's definitely possible in the end.
Also, regarding my HDMI sync issues above and getting the garbled image input, this was due to the HDMI core by defualt not liking HDMI signals that include audio data. I've posted a fix to http://forums.xilinx.com/t5/Spartan-Family-FPGAs/xapp495-bugs-S6-DVI-HDMI-input/m-p/297505/ which solves this problem.