Upgraded Zybo Base System ?

[gdeest]

Hi,

 

I plan to develop labs based on the Zybo Base System. Students would have to create an IP using Vivado HLS (a custom accelerator for some image processing algorithm), add it to the base system and write software using this IP.

 

The problem is, the Zybo Base System has not been updated for the latest versions of Vivado (I'm using 2014.3.1) and the automatic ugprade process does not run smoothly. Is there an updated version available somewhere ?

 

Thanks in advance,

 

Gaël Deest

 

 

[sbobrowicz]

Quick update: I don't think I'm going to have time to post a good "from scratch" version of this project for a couple weeks, so I've passed the version that I created off to our support team. I've updated all the README's, binaries, and main.c, so everything should work as expected, but the Vivado project is still very dirty and throws critical warnings. If you need a working copy of the ZYBO BSD in vivado 2014.4 and don't want to follow the steps I mentioned in my last post, then contact support@digilentinc.com and mention this post. 

[sbobrowicz]

Well its been way too long coming, but I finally got the project to work in 2014.4 tonight.

 

Had to rebuild the i2s core from scratch using the Create and Package IP tool in 2014.4. It should have been simple enough, but the core has 6 AXI stream interfaces, and every time I got near finished creating them all, Vivado would crash! After I finally got through it, I swapped out the old I2S core with the new one, rebuilt, and the base_demo project worked perfectly! No more lock-ups when trying to initialize the audio demo.

 

I pushed the fixed I2S core to the (work in progress) Digilent Vivado IP Library: https://github.com/DigilentInc/vivado-library. You can download the repository, and then copy vivado-library/ip/axi_i2s_adi_1.2 folder into the source/vivado/hw/lib/Digilent folder of the zybo_bsd project. Then open the project in 2014.4 and let the tools upgrade the project and all of the IP cores (done from the IP Status tab next to the messages tab). You will then have to manually add the new 1.2 version of the I2S core and remove the old one. The new core shows up in the "Add IP" Window as "AXI I2S Audio". All ports and parameters on the two cores are named the same and are functionally equivalent, so the new core should be hooked up in exactly the same way. After doing so, rebuild the project and ignore any warnings. After exporting to SDK, you can create the base_demo project like the README says. If it fails to build, you likely just need to change the 55th line of main.c to:

#define AUDIO_CTRL_BASEADDR XPAR_AXI_I2S_ADI_0_S00_AXI_BASEADDR 

I'm going to rebuild the project from scratch in 2014.4 in order to get rid of the warning and clean up the block diagram a bit (not to mention fix this problem). I'll post here again when it goes up. I can't really say for sure when I'll get to this, I'm pulled in a lot of directions these days... Do my best to get it up by the end of next week.

[Korken]

Hi,

 

I too have this problem, I was planning to use this in a course but the upgrade spits a lot of errors.

Is there any upgraded version available Digilent?

 

Thanks!

 

Edit: I am running Vivado 2014.4.

 

Best Regards

Emil Fresk

Luleå University of Technology

Sweden

[JColvin]

Hi,

 

After talking with the support team, this particular project has been having issues when attempting to get it updated to newer versions of Vivado. As per their response, we're hoping to have a fix sometime in the near future.

 

 

Seems the Audio core stops responding to AXI requests and causes programs to halt in the revved versions of the project. It's on my list to fix it, I'm hoping to have something up in a week or so

 

Thanks,

JColvin

[Korken]

Hi,

Thank you for taking the time!

[JColvin]

Thanks for working hard on that Sam! It sounds like was super frustrating.

[zygot]

I use Vivado 2014.1 and 2014.2 on a 64-bit Win7 system as well as Vivado 2014.4 on 64-bit Centos 6.6. Curiously, I've never been able to resolve issues trying to build the zybo_base_system using either version on the Win7 box but had no issues creating a working demo with Vivado 2014.4 on Centos without editing anything from the 2013.4 source. Xilinx is notorious for releasing versions of tools that simply don't work. I have perpetual licences tied to Vivado 2014.2 so it would be nice if I could use it to develop applications for the ZYBO board but one only has so many hours to devote to solving problems that one hasn't created. I mention this because there may be folks who might find this information helpful.

[Squirrel]

sbobrowicz, I would like to pick your brain a little on the I2S adapter if you don't mind since you have been working with it recently.

 

I am running FreeRTOS with an audio task running at 48KHz. I am also running the codec in 48KHz mode. I realize that every frame of the audio output task, I am not guaranteed that the FIFO will be empty enough to write both the left and right samples. However, if I keep track of which I wrote every frame, I would expect that the I2S adapter would do the same:

u8 writeToCodecInterface(u32 data0, u32 data1)
{
	u8 writeMask = 0x00;

	// From the VHDL:
	// I2S_FIFO_STS_REG
	// 0x0000000 (hardcoded)
	// rx_fifo_full
	// rx_fifo_empty
	// tx_fifo_full
	// tx_fifo_empty

	// Check if the FIFO is full
	if (AXI_I2S_ADI_mReadReg(AUDIO_CTRL_BASEADDR, I2S_FIFO_STS_REG) & 0b0010)
	{
		return writeMask;
	}

	AXI_I2S_ADI_mWriteReg(AUDIO_CTRL_BASEADDR, I2S_TX_FIFO_REG, data0);
	writeMask = 0xF0;

	// Check if this filled the FIFO
	if (AXI_I2S_ADI_mReadReg(AUDIO_CTRL_BASEADDR, I2S_FIFO_STS_REG) & 0b0010)
	{
		return writeMask;
	}

	AXI_I2S_ADI_mWriteReg(AUDIO_CTRL_BASEADDR, I2S_TX_FIFO_REG, data1);
	writeMask = 0xFF;

	return writeMask;
}

And the frame logic:

// Per frame...
if (0xF0 != writeMask)
{
	writeMask = writeToCodecInterface(left, right);
}
else
{
			writeMask = writeToCodecInterface(right, left);
}

What I get at the output is, however, not expected. It seems like the adapter loses track of where it is and will randomly swap the output data from left to right and right to left. If I instead poll after writing the left sample like in the reference design, such that I write the right channel 'fast enough', I get good audio (at the expense of timeline, so this is also not a good result). This indicates to me that the entire FIFO is 'dumped' at once to the adapter?

 

Is there a better way to do all of this? Anything interrupt driven? Anything even simpler than using DMAs and just using a register based approach? I will not need any buffering as the real-timeliness is taken care of for me.

[sbobrowicz]

Hey Hamster,

 

Using manual register writes to the FIFO requires that you're working in an environment with dependable real-time characteristics. I've never used FreeRTOS before, but I assume it does a good job of actually executing the task at close to a 48KHz frequency... even if that is the case though, you might be experiencing an underflow here and there. The FIFO is only 8 24-bit words deep, which is actually only four samples, with left and right audio data alternating (left first). An underflow or overflow condition of this FIFO could cause the left and right channels to effectively swap, which is what you are experiencing.

 

Are you preloading the FIFO after you immediately enable it? I would recommend doing this with about 4 words of data (or 2 samples, L1,R1,L2,R2). This should help prevent underflows (your code looks like it already handles overflows properly).

 

As for how the FIFO is transmitted, it should be emptied at a constant rate of 96KHz (in your case). I2S is a physical interface very similar to SPI with SCLK typically operating at 64 times the audio sample rate (24 bits of audio and 8 padding bits per channel).

[Squirrel]

I am not so sure about the hamster thing, but I am sure about the following:

• The FreeRTOS handler for the AXI register write occurs at nearly exactly 48KHz (validated with an oscilloscope). Sometimes maybe +/- 100Hz under heavy loading, which was not the case in my baseline testing of the AXI_I2S_ADI
• If I pre-fill the buffer every frame until it is full as a defensive measure, things get even worse; I see the left and right channels swapping rapidly for maybe 50 or so samples. I don't have a trace handy to verify the exact behavior
• I have never had luck getting reasonable audio out with 32-bit data where the (two?) most significant bits were not both zeros or ones, i.e. it acts as if it is getting truncated at the (30th?) bit. This indicates, at least to me, that the padding may be getting munged up or something more sinister may be going on. I didn't look at the scope trace too in depth, but I think it was the 30th.

I did see some clock domain crossing in the AXI_I2S_ADI, and although I haven't read the entire VHDL source directory this seems perhaps a little bit suspect... is the underlying FIFO designed for this to work nicely?

Eventually, I made my own AXI peripheral which mitigates the clock domain crossing by clocking the AXI interface at a rate multiple of 12.288MHz an lets me operate with full 32-bit inputs (obviously truncated to 24, but truncated on the least significant side only). It is simplified without a FIFO (because I don't need one in this case), but it still may be useful to others... if I wanted to share this, where may the most appropriate place be?

[zynq_tech]

I'm using Vivado 2016.2 and  the original ZBS worked. I then substituted

sbobrowicz's

updated core and it also works ( very nice work ! ). Is it possible to take a given IP core, such as the AXI_I2S_ADI, and view its internal Block design ?

Are there docs on using this I2S IP ( I see there are 2 options for using the DMA feature, for example. So what's the difference between them ? ) ?

Where is the Digilent page for its IP library ?

[JColvin]

Hi zynq_tech,

I'll ask some of our applications engineers about the documentation and the block design question, but you can view all of Digilent's IP on our GitHub account here.

Let me know if you have any more questions.

Thanks,
JColvin

[zynq_tech]

Thanks for the link and the tech support submittal, JColvin.

[sbobrowicz]

On 7/15/2016 at 11:13 PM, zynq_tech said:

updated core and it also works ( very nice work ! )

Thanks 

On 7/15/2016 at 11:13 PM, zynq_tech said:

Is it possible to take a given IP core, such as the AXI_I2S_ADI, and view its internal Block design ?

This IP core was designed as HDL, so no block diagram exists for it. It is possible to look inside the IP folder and view the HDL though. 

On 7/15/2016 at 11:13 PM, zynq_tech said:

Are there docs on using this I2S IP ( I see there are 2 options for using the DMA feature, for example. So what's the difference between them ? ) ?

Unfortunately we don't have any documentation for this core. We will try to circle around and document the cores such as this one that don't have documentation, but I can't give you a timeline on when this will happen. The different modes let it be used with either an axi_dma (which works on both Zynq and microblaze designs), or the Zynq pl330 DMA (only available on Zynq boards). You can see a reference demo that uses it with an axi_dma here: https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-video-dma-audio-demo/start . Hopefully that should be enough to teach you how to use the core with an AXI DMA.

I think ADI may have some code out there that demonstrates how to use the audio codec with the PL330. I do know that the Linux driver uses the core with the PL330 DMA.