ZedBoard Hardware Design - Recent Threads

Vivado BRAM Instantiation Issues

dniemann17 — Tue, 24 Jun 2025 14:39:07 GMT

Hello!

We are currently working on a project which requires us to extend a previously created memory interface on a ZedBoard from being 4k in size to 256k (A 1/4 of a MB).
We had previously created a file, called pocket_core_top_mem.v which instantiated a 4k long memory (4 xilinx_tdpram_1024x36 modules) that has been working for the longest time. This old interface used only 4 blocks of 140 available Block RAM modules on the zedboard for the project (50 blocks are used elsewhere, leaving 86 remaining).
[View:/cfs-file/__key/communityserver-discussions-components-files/319/pocket_5F00_core_5F00_top_5F00_mem.v.txt:40:47]
While doing this, we simply started by trying to nest multiple memory files (using xilinx_tdpram_1024x36 modules), where we would have a .v file and module for 16k ram (4 4k modules), a file for 64k ram (4 16k modules), and finally a top file which consisted of 4 64k modules. (called pocket_core_mem_16k.v, pocket_core_mem_64k.v, and pocket_core_top_mem_nested.v here).
[View:/cfs-file/__key/communityserver-discussions-components-files/319/pocket_5F00_core_5F00_mem_5F00_16k.v.txt:40:47][View:/cfs-file/__key/communityserver-discussions-components-files/319/pocket_5F00_core_5F00_mem_5F00_64k.v.txt:40:47][View:/cfs-file/__key/communityserver-discussions-components-files/319/pocket_5F00_core_5F00_top_5F00_mem_5F00_nested.v.txt:40:47]
Unfortunately, when we went to build the project, it ran through with no errors and wrote the bitstream but unfortunately only 2 RAM blocks were instantiated in the implemented design and I was only able to read and write to 0x100 of the memory space I programmed in. In Vivado, it was only reporting that 51 of the 140 RAM blocks were instantiated.
So, I then created and ran a simulation in Icarus Verilog on my files to see if I could indeed read and write to the higher address blocks. This simulation worked and proved my files didn't have a design error.

I was dumbstruck and thought it was how Vivado interpreted my file methodology that was making the error occur. So, I then simply made a single file (named pocket_core_top_mem_single.v here) with 64 xilinx_tdpram_1024x36 modules in it.
This STILL only had 2 RAM blocks instantiated when Vivado finished building and writing the bitstream:

I also ran simulations to confirm if this file worked or not, and they confirmed the file worked.
[View:/cfs-file/__key/communityserver-discussions-components-files/319/pocket_5F00_core_5F00_top_5F00_mem_5F00_single.v.txt:40:47]

Would there be anything that could be preventing Vivado from instantiating these 64 BRAM blocks that I may have missed?

Regards,
Daniel

Configure core0 with petalinux and core1 baremetal on Zedboard 2018.3

caferba — Tue, 29 Apr 2025 12:04:18 GMT

Hello,

I am working with the Zedboard 2018.3 Rev F and I'm having issues when trying to launch an application on CPU1 from petalinux 2018.3 on CPU0. After loading the firmware and starting nothing happens. It seems that the baremetal application on cpu1 is not starting. I have followed the UG1186 documentation for A9-zynq platforms.

root@avnet-digilent-zedboard-2018_3:/lib/firmware# echo hello-linux.elf > /sys/class/remoteproc/remoteproc0/firmware

root@avnet-digilent-zedboard-2018_3:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state

remoteproc remoteproc0: powering up remoteproc@0

remoteproc remoteproc0: Booting fw image hello-linux.elf, size 2534900

remoteproc remoteproc0: registered virtio0 (type 7)

remoteproc remoteproc0: remote processor remoteproc@0 is now up

root@avnet-digilent-zedboard-2018_3:/lib/firmware# virtio_rpmsg_bus virtio0: rpmsg host is online

system-user.dtsi:

/include/ "system-conf.dtsi"

/ {

chosen

{

bootargs = "uio_pdrv_genirq.of_id=generic-uio";

};

/ {

reserved-memory {

#address-cells = <1>;

#size-cells = <1>;

ranges;

vdev0vring0: vdev0vring0@3e800000 {

no-map;

compatible = "shared-dma-pool";

reg = <0x3e800000 0x4000>;

};

vdev0vring1: vdev0vring1@3e804000 {

no-map;

compatible = "shared-dma-pool";

reg = <0x3e804000 0x4000>;

};

vdev0buffer: vdev0buffer@3e808000 {

no-map;

compatible = "shared-dma-pool";

reg = <0x3e808000 0x100000>;

};

rproc_0_reserved: rproc@3e000000 {

no-map;

reg = <0x3ed00000 0x00400000>;

};

amba {

elf_ddr_0: ddr@0 {

compatible = "mmio-sram";

reg = <0x3e000000 0x400000>;

};

remoteproc0: remoteproc@0 {

compatible = "xlnx,zynq_remoteproc";

firmware = "firmware";

vring0 = <15>;

vring1 = <14>;

srams = <&elf_ddr_0>;

};

Thank you

Carlos

Connecting Zedboard to Vivado - Hardware Manager not Detecting

eb_air — Fri, 21 Mar 2025 19:12:04 GMT

Hello,

I have been struggling to detect my Zedboard on Vivado's Hardware Manager run in a Linux OS. When I went into the Hardware Manager, I could connect into the local hardware server, but the Zedboard did not show up. I used version 2023.2 and 2022.2, but both versions had the same problem. I tried the JTAG and UART modes with no success. I am confused with the problem here because if I run lsusb, I see "232H Single HS USB-UART/FIFO IC" for the JTAG interface and "Cypress Semiconductor Corp. CDC ACM serial port", which I assume means the drivers are properly installed.

Is there something I am doing wrong here?

RE: Connecting Zedboard to Vivado - Hardware Manager not Detecting

eb_air — Mon, 24 Mar 2025 14:12:20 GMT

Alright, I will look into that.

RE: Connecting Zedboard to Vivado - Hardware Manager not Detecting

dyessgg — Sat, 22 Mar 2025 13:56:19 GMT

If I remember correctly, that is the location of the script. It's actually just setting up some udev rules for the USB device.

RE: Connecting Zedboard to Vivado - Hardware Manager not Detecting

eb_air — Sat, 22 Mar 2025 03:22:48 GMT

I have not done that yet. Is that in "data/xicom/cable_drivers/lin64/install_script/install_driver" ? If not, where can I find it?

RE: Connecting Zedboard to Vivado - Hardware Manager not Detecting

dyessgg — Fri, 21 Mar 2025 23:23:15 GMT

Did you load the JTAG cable drivers? They don't install as part of Vivado installation.

RE: Je1 GPIO - Cant seem to access upper pins

PurplePig — Fri, 14 Mar 2025 17:03:11 GMT

The memory Viewer was not accurate. I added a printf and hot the expected value. XSCT could not read that address.

Je1 GPIO - Cant seem to access upper pins

PurplePig — Fri, 14 Mar 2025 11:33:58 GMT

# Xilinx Zedboard (Zynq 7020) GPIO 0

I am working with a new Zedboard with the Zynq 7020 processor.

I was trying to strobe the pins on the JE1 PMOD port

To this end I defined the following pins

```

File: helloworld.c

61: int iPortPins[10];

62:

63: #define JE1 13

64: #define JE2 10

65: #define JE3 11

66: #define JE4 12

67: #define JE7 0

68: #define JE8 9

69: #define JE9 14

70: #define JE10 15

71: #define LED 7

72:

```

and configured them as follows

defined as

what I had observed as that the GPIO_0 DIRM and OEN were not allowing the GPIO 0 pins to

drive the PMOD so I explicitly set them

What I observed is I was only able to write the lower 8 bits of each of these registers.

### before

code to change **DIRM** and **OEN**

```

u32 pGPIO_0_DIRM = 0xE000A204;

Xil_Out32(pGPIO_0_DIRM, (u32)(iMask));

u32 pGPIO_0_OEN = 0xE000A208;

Xil_Out32(pGPIO_0_OEN, (u32)(iMask));

```

### after

Note that bits 8-15 were ignored.

This is also the case if I try to modify them from the ide memory window. If I write 0xffffffff only the lower 8 bits are modified.

(Both DIRM and OEN)

Why is this?

RE: Je1 GPIO - Cant seem to access upper pins

PurplePig — Fri, 14 Mar 2025 11:41:02 GMT

Source

/******************************************************************************
*
* Copyright (C) 2009 - 2014 Xilinx, Inc.  All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* Use of the Software is limited solely to applications:
* (a) running on a Xilinx device, or
* (b) that interact with a Xilinx device through a bus or interconnect.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* XILINX  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* Except as contained in this notice, the name of the Xilinx shall not be used
* in advertising or otherwise to promote the sale, use or other dealings in
* this Software without prior written authorization from Xilinx.
*
******************************************************************************/

/*
 * helloworld.c: simple test application
 *
 * This application configures UART 16550 to baud rate 9600.
 * PS7 UART (Zynq) is not initialized by this application, since
 * bootrom/bsp configures it to baud rate 115200
 *
 * ------------------------------------------------
 * | UART TYPE   BAUD RATE                        |
 * ------------------------------------------------
 *   uartns550   9600
 *   uartlite    Configurable only in HW design
 *   ps7_uart    115200 (configured by bootrom/bsp)
 */

#include <stdio.h>
#include "platform.h"
#include "xil_printf.h"

#include "xgpiops.h"
#include "xparameters.h"

XGpioPs_Config	*psGPIO_Config = NULL;
XGpioPs 		my_Gpio;

int				Status;
int				Status2;

int				iPortPins[10];

#define JE1		13
#define JE2		10
#define JE3		11
#define JE4		12
#define JE7		0
#define JE8		9
#define JE9		14
#define JE10	15
#define LED		7

void pause(u32 u32Pause)
{
	volatile u32 ii = 0;
	for( ii = 0; ii< u32Pause; )
	{
		ii++;
	}
}

int main()
{
	volatile u32 	ii 		= 0;
	volatile u32 	iMask 	= 0;
	int				iPinCount = 0;

	init_platform();

	iPortPins[iPinCount++] = JE1;
	iPortPins[iPinCount++] = JE2;
	iPortPins[iPinCount++] = JE3;
	iPortPins[iPinCount++] = JE4;
	iPortPins[iPinCount++] = JE7;
	iPortPins[iPinCount++] = JE8;
	iPortPins[iPinCount++] = JE9;
	iPortPins[iPinCount++] = JE10;
	iPortPins[iPinCount++] = LED;


    print("Hello World. \n\rBienvenidos!\n\r");

//	SlcrUnlock();

//	u32 pUnlock = 0xF8000008;
//    Xil_Out32(pUnlock, (u32)(0xdf0d));

//    u32 pMIO_PIN_00 = 0xF8000700;
//    Xil_Out32(pMIO_PIN_00, (u32)(0x1601));
//    Xil_Out32(pMIO_PIN_00, (u32)(0x1601));
//    Xil_Out32(pMIO_PIN_00, (u32)(0x0601));

	psGPIO_Config 		= XGpioPs_LookupConfig( XPAR_PS7_GPIO_0_DEVICE_ID );
    Status 	= XGpioPs_CfgInitialize(&my_Gpio, psGPIO_Config, psGPIO_Config->BaseAddr);

    if ((Status == 0) && (Status2 == 0))
    {

    	for (ii=0; ii < iPinCount; ii++)
    	{
    		XGpioPs_SetDirectionPin( &my_Gpio, iPortPins[ii], 1);
    		XGpioPs_WritePin( &my_Gpio, iPortPins[ii], 1);
    		iMask = iMask | (1 << iPortPins[ii]);
    	}

    	u32 pGPIO_0_DIRM = 0xE000A204;
    	Xil_Out32(pGPIO_0_DIRM, (u32)(iMask));

    	u32 pGPIO_0_OEN = 0xE000A208;
    	Xil_Out32(pGPIO_0_OEN, (u32)(iMask));

    	while(1)
    	{
	    	for (ii=0; ii < iPinCount; ii++)
	    	{
	    		XGpioPs_SetDirectionPin( &my_Gpio, iPortPins[ii], 1);
	    		XGpioPs_WritePin( &my_Gpio, iPortPins[ii], 0);
	    	}
        	pause(10000000);

	    	for (ii=0; ii < iPinCount; ii++)
	    	{
	    		XGpioPs_SetDirectionPin( &my_Gpio, iPortPins[ii], 1);
	    		XGpioPs_WritePin( &my_Gpio, iPortPins[ii], 1);
	    	}
        	pause(10000000);
    	}
    }

    print("Successfully ran Hello World application");
    cleanup_platform();
    return 0;
}

RE: UART drivers not working in Win10 Pro/Home 64bit

sunnykryoon — Sat, 22 Feb 2025 00:39:18 GMT

Thank you so much! I signed up here just to write this comment. I think this answer has saved a lot of people's time over the past 8 years. You saved me a lot of time. Thank you!

UART drivers not working in Win10 Pro/Home 64bit

rathseg — Wed, 15 Mar 2017 13:09:37 GMT

Hi,

I just got a Zedboard and I am trying to get it up and running but I am getting stuck right at the very beginning with getting the UART connection to work. I followed the included instructions with the board. I got the Green Power light, blue done light, "digilent" image on the OLED, and a solid amber light on the UART LD11.

I went to the next step that says you need to install the driver for the Cypress CY7C64225 USB-to-UART. I found the the 1.3 install guide from here: http://zedboard.org/support/documentation/1521 I went to the Cypress site, got the CypressDriverInstaller_1 file and installed it. It said it installed fine(* there are discrepancies with the install guide after install, which I will get to in a minute ). The amber light turned off instead of blinking. Tried reconnecting the Zedboard, turning on/off, restarting computer. In all cases, the UART amber light is off and I cannot connect with a terminal program.

Compared with the install guide there are some things that are different in the device manager. There is no device listed as "CypressUsbConsoleWindowsDriver" as Figure 4/Step 9 shows. Under Ports ( COM and LPT ), it is called USB Serial Port ( COM4 ), not "Cypress Serial". USB Serial Port is the Zedboard as it only appears if I turn on the Zedboard. Going into the properties for the USB Serial Port under Port Settings->Advanced as steps 10 and 11 indicate, there is no option for Enable Port Persist, but under "Com Port Number" dropdown box ( bottom of the picture step 11 ), there is an option for "enable RTS-DTR Flow Control" and "Other Serial Device Setup" with the option "Compatible I2C Slave Device Address (7 bit Even Address ) with 0x42 in the textbox. USB to UART Adapter is under "Universal Serial Bus Controllers" but is not mentioned in the install guide.

I started checking the forums and found this post: http://zedboard.org/content/uart-driver-does-not-work-new-pc and tried ALL the suggestions there with no change. That thread was pretty old so I thought I'd start a new one. If I uninstall everything and turn on the zedboard I can get the solid amber light back.

I also tried hooking up the Zedboard to a laptop running Windows 10 Home 64-bit, with the exact same results.

OS: Windows 10 Pro 64 bit

USB Serial Port Version number after Cypress driver install: 3.13.0.59 dated 10/13/2105

USB to UART Adapter Version number after Cypress driver install 3.13.0.59 dated 10/13/2015

I'm pretty much out of ideas at this point and could use some more suggestions. A few other details.

Thanks in advance.

Setting up PLL for use with FPGA fabric

hawx2020 — Mon, 06 Jan 2025 20:58:15 GMT

Hi,

I'm having trouble setting up the 33MHz PLL clock so that I am able to access it from the FPGA fabric. I've never used a PLL before and I've only ever used the FPGA fabric on the zedboard so I'm not quite sure where to start. If anyone has any advice or an example project, that would be greatly appreciated.

Thanks!

RE: Setting up PLL for use with FPGA fabric

iksevas — Mon, 06 Jan 2025 21:57:05 GMT

The PicoZed product targets that device. There are reference designs on this page:

https://www.avnet.com/wps/portal/us/products/avnet-boards/avnet-board-families/picozed/

More up-to-date BSPs are on a SHAREPOINT site. https://avnet.me/ZedSupport

Either way, you will see in the Vivado portions that there is typically a 100MHz fabric clock provided from the block design that gets created from the 33MHz reference clock.

RE: Setting up PLL for use with FPGA fabric

hawx2020 — Mon, 06 Jan 2025 21:49:33 GMT

Hi, it's the Zynq-7000 XC7Z020-CLG484-1. I tried following some tutorial that was using the block designs, but I couldn't get it to work. I was probably doing something wrong though. Do you have an example?

RE: Setting up PLL for use with FPGA fabric

iksevas — Mon, 06 Jan 2025 21:29:38 GMT

Stupid question but what platform are you targeting? Most of the SOC (Zynq-7000) or MPSoC (Zynq UltraScale) have a 33MHz reference clock into the system - there is a simple GUI in Vivado that will allow you to forward a version of this clock to the FPGA fabric for use. This clock can be synthesized into different frequencies depending on your need. It should be as simple as setting up your block design properly in the tools.

RE: audio passthrough using SPI in PL

michaelkellett — Sun, 05 Jan 2025 16:52:18 GMT

The spi_drive code is suspect because it doesn't use reset and the state machine may start up in any state.

Pressing the enable button should kick things off - you shouldn't need to auto start the driver writing to the codec registers but if those missing resets are spoiling things it won't work.

It's normal when working on FPGA code to simulate before running on actual hardware. It will help you understand what is going on much better if you can get into that habit.

If you don't have access to a simulator you should sort that out first - it is a necessary tool.

You could modify the spi driver to toggle spare output pins as it does certain things so you can see if it is working.

Or connect a scope to the SPI mosi output to the codec and look for the *** config. signals.

The data sheet for the ADAU1761explains the timing of all signals very well - you need to study that document carefully.

audio passthrough using SPI in PL

Former Member — Sat, 04 Jan 2025 02:26:03 GMT

Hi!

I'm new to FPGA and ZedBoard, and for educational purpose, I'm trying to recive signal from microphone(or LINE_IN) and passthrough it to headphones(or LINE_OUT). Eventually I'm going to create a sound recognition system(frequency detection to be precisie), but for now, I want to properly set up audio codec, and check on headphones if I can hear myself. I found interesting project here: https://www.rtlaudiolab.com/page/4/ (part1-5) that describes how to passtrough audio using SPI communication. I set up everything, just like on this website, but have a problem with SPI driver(which is the codec audio if I understand that correctly), because the data_in are going nowhere. I don't know if that's how it supossed to be, but common sense tell me that it shouldn't be that way. Also, I can generate a bitstream and program zedboard, but i can't hear nothing.

I would be thankful for any advice and help.

PS. Acording to website of the project, i should press BTNC before i could hear anything but that doesn;t help either.

Here are screenshots from the vivado:

RE: audio passthrough using SPI in PL

Former Member — Sun, 05 Jan 2025 16:09:16 GMT

Hey, thanks for your effort. I really appreciate that. I found that earlier, and even assign it for another button, but it doesnt help either. I wanted to simply check the audio codec, if it's working properly. I won't be sending any signal to audio output further in the project. What I need is having digitilized signal on known "port", to further analisys. But for now, I have struggle with audio codec :(

I have a question about that master module, especially abaout that part that you mentioned, and the few lines under that. If I'm correct, I could simply start the procedure of configurating codec after reset? With that, I would have one button to reset and start sending messages.

Also, if you could explain in your own words what exactly is bit clock and LR clock, and about that internal synchronisation. I will be very grateful.

RE: audio passthrough using SPI in PL

michaelkellett — Sun, 05 Jan 2025 15:37:25 GMT

I can't review the code in your link because its written in Verilog which I can understand but never use if I can help it. So I am not confident in spotting bugs in Verilog code.

Having said that, there is a bug in the spi_controller block diagram which casts huge doubt on the utility of the whole rtaudio project as a learning aid.

i_reset input to the spi_master block is grounded, if you look at the code for the spi_master block you will see that all this should happen when reset is asserted:

        if (i_reset) begin
            fsm_state <= IDLE;
            spi_data_counter <= \'b0;
            spi_cs_n <= 1\'b1;
            data_out_shift <= \'b0;
            done <= 1\'b0;
            spi_mosi <= 1\'b0;
            data_out_shift <= \'b0;
            o_data_out <= \'b0;
            o_busy <= \'b0;

It is possible that the complete project will work, or often work depending on the way the registers start up, but not certain. To fail to initialise a standard block like the SPI in this way, is what I would call an unforgivable error. It is a deliberate action (not an error of omission) which will result in an uncertain design. To do this in a published teaching style project is beyond sloppy ! Do NOT trust this project .

Moving on ........

The SPI_MASTER is a standard block of code (the audiolab article says:

"The SPI Master is a generic module that implements the master device in a single-slave SPI bus. In addition to the standard SPI signals, the clock phase and polarity of the SPI Master can be changed at runtime using the corresponding input ports. The bit width of a transaction can be adjusted during the module instantiation." )

Using standard blocks of code is common but, as in this case, frequently results in features in the code that are not required for your specific application. SPI is a bidirectional protocol, but you only need on direction so some unwanted connections are to be expected. You have a miso pin but you don't need it.

In section 5 of the rtaudio project they have a block diagram of the audio pass through:

This is a bit of it and you can see that they connect the codec_adc_data output directly to the codec dac_data input. This is a trivial and pointless audio pass through application in which the data is never read properly into the FPGA and the bit clock and LR clock rely on internal synchronisation in the codec chip. It will tell you if the codec is working but not that you can actually read and write digitised data from/to it.

The do cover this later:

I have not checked their code at all !

(If you have considered using VHDL then let me know - I could then provide some code examples (but not for your hardware, although obviously modifiable.)

RE: audio passthrough using SPI in PL

Former Member — Sun, 05 Jan 2025 12:34:49 GMT

Hey, I read the documentation of the audio codec, and i get it that to set up the SPI communication i have to pull ~CLATCH 3 times low, and it is written in spi_driver. I also understand that those other "messages" have to be sent, to properly work, but in that implementation, i dont understand what is going on in spi_master, especially that half of the code includes clock_phase and clock_polarity that are grounded. If you or anyone could look at the example here: https://www.rtlaudiolab.com/004-zedboard-audio-codec-spi-controller/ and tell me if thats correct i would be thankful.

Also, i dont understand why i_spi_miso get involved here, cause the whole spi_controller has only sending the configuration to o_spi_mosi, so why we have the reading option here. Below i'm putting screenshot of whole spi_controller for the record.

About that clock that you mentioned, the i_codec_lr_clock and bit_clock are nowhere used. The clock generator are "creating" 45MHz clock that is send to mclock, in that project was said that if I want to sampling in 44.1kHz, the mclock should be 1024xfs, in documentation i found it too(in the case of not using internal PLL).

About the example, unfortunately I didn't found another example of setting audio codec with SPI using only PL. It's not that I can't use it, just prefer to use PL if thats possible.

RE: audio passthrough using SPI in PL

michaelkellett — Sun, 05 Jan 2025 10:29:00 GMT

I'm seriously puzzled by your diagram.

The SPI controller does not appear to have any reset or parallel data input/output - how does it know what config data to send out, when to send it etc etc.

If you want to accept analogue input data on the ADC input to the codec and output analogue data on its audio output DAC you will need to initialise the codec, then the FPGA can accept serial digital data from the codec ADC and buffer it , read from the buffer and output serial digital data to the codec which will use its DAC to convert it to analogue audio data.

I'm not sure that you have got the hang of how to clock the codec and the FPGA, the LR clock from the codec will be synchronous with the M clock into the codec. It is unlikely that you will run the FPGA synchronously with the LR clock and you may well have a choice between clocking data out of the codec synchronously with M clock of FPGA clock. There will be timing constraints in the codec spec about clocking and the MUST be observed if you want it to work correctly.

I suggest that you find a complete working example of a pass through application for your hardware and study it carefully. Then try tweaking it a bit. I took a quick look at the example you linked and although I didn't like its use of video rather than static diagrams it probably covers a lot of what you need. Have you been able to make it work ?

RE: audio passthrough using SPI in PL

Former Member — Sat, 04 Jan 2025 15:23:48 GMT

Yeah, I should've said that earlier. The audio codec on zedboard is ADAU1761. The I2C is default, and for set up SPI, in spi_driver_inst there are 3 dummies write sends to spi_master. Also in documentation of that codec was said so. As i told before, I'm new to FPGA, and i dont understand everything that has been written in that intances, and I'm not sure why there's need to configure SPI eventually, because I only need the audio output to use further in PL. Could you help me understand that? My job for now is to short the LINE_IN and LINE_OUT to make sure that board is working properly.

Also, in audio_proccessor_inst there are simple assign o_codec_dac_data to i_codec adc_data. Is that could work, or something is missing?. Of course the name of that pins are from constraints file dedicated to this zedboard.

RE: audio passthrough using SPI in PL

jc2048 — Sat, 04 Jan 2025 14:52:28 GMT

Qualification: I don't use Vivado and don't own a Zedboard, so this is just in very general terms.

The audio data streams in to the FPGA on the i_codec_(xxx) inputs.

Given the names, it's most likely the CODEC chip has an I2S output. Serial data on adc_data, clock on bit_clock, and the left-right qualifier on lr_clock.

It's possible that the CODEC being used here has a register set that needs to be loaded via SPI at the start (sometimes they're I2C, sometimes SPI, and sometimes there's no setup and it's just done by strapping inputs on the CODEC chip). Normally that would be done from a processor, but can also be done from logic (it's usually quite a small selection of options, so not too onerous). Try going down a level into the spi_controller_inst and see if there's not only a shift register for the SPI, but also a simple state machine to sequence everything and a store of the values that will be sent in sequence to the CODEC.

If that's the case, the i_spi_miso input would come from the CODEC, for reading back register contents, but may not actually be necessary to get the CODEC set up (there's a good chance it could work just by pushing the right data at it).

Hopefully that will get you a bit further.

RE: Zedboard troubleshooting : Power LED and DONE LED does not turn ON

bidrohini — Mon, 28 Oct 2024 14:37:17 GMT

Recheck the PGOOD (Power Good) signals associated with different voltage rails. If the PGOOD signals aren’t asserted correctly, the board may not proceed with its boot sequence. This is why the DONE LED is not illuminating.