RyanW

This complexity may be problematic for me. I need to create my own simple FMC card to connect to some custom 16 channel LVDS interface. I really need something that can get to this without extra steps on a devboard. The ZedBoard could do this for me and I have experience using basic Zynq devices, but I really need the Video Codec Unit eventually. The Ultrascale+ MPSoC devices do scare me a bit, because it seems its always different and more complicated whenever I look at boards for it and I am worried I will run into roadblocks that take too much time to solve. The goal is eventually to develop a daughter board for the Kria, whether by contracting it out, or by me taking a stab at it. It seems that the XCZU5EV-SFVC784-1-E chip on the Gensys is very close to the Kria chip, so I am hoping to use this board to get developing things without daughter board roadblocks on the Kria devkits (can't get the right voltages/IO on the AI or Robot starter kit). I'm trying not to run into that problem again. a 1.8V HP bank (or even a 2.5V HR) would be perfect for my use cases.

So is this to say that the Platform MCU can re-assign bank voltages after the FPGA has been programmed? I thought that the bank voltages would need to be powered during the bitstream process. So if I can force the Platform MCU to reassign the bank voltages, does that mean I should be setting that in the PL and that the bank voltages on Zynq can be swapped after programmed?

Hello, I am a little confused on how to set the VADJ on the Genesys XU-5EV. According to the reference manual external VADJ_LEVEL1 and VADJ_LEVEL0 signals control the state of VADJ. How can I ensure that these two signals both are signaled to 1 and 1 upon boot. I suppose I will need to ensure these signals reach their levels before the platform management starts its booting process. What are the tips on this as I really need the capability of easily getting 1.8V on the LPC FMC and the usage of the video codec unit; otherwise I would consider the ZedBoard option with jumper headers for VADJ. I do not yet have the board to play around with, so some of this is still just conceptually abstract to me.

Thanks for this. I figured there was probably some way to do this, but for the time being I just had to work with my cobbled together solution.

I had this same misunderstanding starting out. The voltage constraints are there to tell Vivado what voltage you have externally supplied to it. The only way to change the voltage on those IO banks is to physically change the incoming voltage source to the pins on the FPGA that supply those IO banks. Just glancing at the Zybo Z7, it doesn't seem to have a pin header switch or any other way to switch the bank voltages; and considering this is a dev-board, there's not really a good way to go in and hack away voltage supply to those pins. I know on the Zed Board, there are some bank voltages you can control with a pin header jumper, and there are probably some other boards that have that capability as well. If you really need to use this board for this application at 1.8V. It seems digilent has a PMOD connector that could probably help you out. I don't know what your target data-rate is, but you can check to see of the chip can handle it by viewing the data sheet. (It seems to say max data rate for translating to 1.8V is 75 Mbps on the features page, but their charts are confusing as I'm calculating slightly higher). Digilent PMOD Level Shifter: https://digilent.com/shop/pmod-lvlshft-logic-level-shifter/ Digilent PMOD Level Shifter References: https://digilent.com/reference/pmod/pmodlvlshft/reference-manual?redirect=1 TI SN74LVC1T45 Datasheet: https://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf

Hello, I have a Cora Z7-10 and it appears that the USB Type-A functionality of this board is not working. When measured, I get 0 volts across the power rails on the USB 2.0 pins. I also checked this on the single core version of the board I have and I got the same results. I can't access any peripheral USB devices I am trying to hook up to the board due to this issue. I tried to power the board with an external power supply thinking that maybe the USB was shutting down or not turning on due to some circuitry things, but after powering it in both USB and external modes, the USB Type-A port still seems to be inactive/has zero volts on its power rails. Everything else on the board appears to work well, and I have been using them for around a year now (just never tried anything with USB up till now). Is there something I need to do to enable the functionality of the USB host port for the Cora Z7-10/7s?

Thank you for the response, that makes sense for the reasoning, although I liked having the better chip on it.

Hi, I had a similar problem using the Cora Z7-07S. To make sure we're on the same page. I'm changing this in the file $PETALINUX_PROJECT/components/plnx_workspace/device-tree/device-tree/zynq-7000.dtsi I just commented out that reference to CPU1. /*cpu1: cpu@1 { compatible = "arm,cortex-a9"; device_type = "cpu"; reg = <1>; clocks = <&clkc 3>; };*/ And then replaced the reference to cpu1 with cpu0 in the PTM. ptm@f889d000 { compatible = "arm,coresight-etm3x", "arm,primecell"; reg = <0xf889d000 0x1000>; clocks = <&clkc 27>, <&clkc 46>, <&clkc 47>; clock-names = "apb_pclk", "dbg_trc", "dbg_apb"; //cpu = <&cpu1>; cpu = <&cpu0>; out-ports { port { ptm1_out_port: endpoint { remote-endpoint = <&funnel0_in_port1>; }; }; }; }; I'm not sure if that second PTM physically exists in this chip or not, but doing just this worked for me on my system. The ptm1 is referenced only in one other spot in my device tree, so I'm considering taking out the chain of references stemming from the cpu1 to ptm1. From what I can tell a PTM is A "Program Trace Macrocell (PTM) is a real-time trace module providing instruction tracing of a processor." so it would seem that is has something to do with tracking instructions in a debug mode or something inside the processor, and it would stand to reason there would be one per core, so the second one seems extraneous.

Hello, this post mostly goes out to Digilent staff, but I'd like to hear other's input on this as well. I noticed a couple months ago that the Cora Z7-10 was discontinued and only the single core option is now available. Is this due to chip shortages/supply chain issues? Is there any plan to bring this version of the board back? I have both the single and dual core, and unfortunately the single core model does not play nice with the Xilinx toolchain for petalinux. I was eventually able to get linux working on the single core, but I had to modify the zynq-7000.dtsi to exclude references to the second core. All the bare metal stuff works nicely. I just thought it seemed odd to discontinue the product when I thought the pin-outs on both chips were the same (I could be entirely wrong on this). https://digilent.com/shop/cora-z7-zynq-7000-single-core-and-dual-core-options-for-arm-fpga-soc-development/

Hello everyone, I am having a great deal of trouble figuring out how to setup drivers for the Xilinx DMA IP core in Linux/Petalinux Project. I have a bare-metal application setup currently that work well at 400MB/s from the PL to PS and streams data from AXI stream generator I made to simulate a video stream. That works well, but I need to be able to transfer data from the PS side to a PC via Ethernet and I was hoping to use Linux to handle that interaction. I essentially want a proxy driver that I can control from user-space to initiate the transfer upon interrupt from the DMA engine. I was doing direct register programming before and reprogramming upon interrupt in the bare-metal application. Is there some way to do this from user-space with provided drivers somewhere, or does it take a different approach? If there are some provided drivers that take a different approach that is fine, I just need the data in the PS from the PL. Is there anything someone can point me to for the right direction? I am even considering doing a direct register programming mode of the AXI DMA IP core handled entirely in the PL portion along with the interrupts. This would allow me to poll some arbitrary AXI lite interface to see if I received an entire image frame or not yet. And read the data most like likely out of an MMAP portioned of memory, which maybe I could define in the device-tree although I've had problems setting that up as well. I would want to avoid this however as it seems like its just a work around and it seems better to do things the right way. How/where do I find/setup the Xilinx DMA kernel drivers and tie them to the Linux DMA framework? I then Imagine I would need to create my own proxy module to tie the syscalls together at that point. I'm still not sure how it would allow me to program a destination address and transfer length to the AXI DMA IP core or handle the interrupts to reset the interrupt and reprogram the engine. Can anyone help weigh in on this?

I made made the sysroot by running the 2 commands after I had setup and built the base project: petalinux-build--sdk petalinux-package --sysroot When running this command: I see that the file does exist, only it seems to exist in a sub-folder right under where the path specified in the error message pointed to. The output is shown below. ./images/linux/sdk/sysroots/cortexa9t2hf-neon-xilinx-linux-gnueabi/usr/lib/arm-xilinx-linux-gnueabi/11.2.0/crtbeginS.o EDIT: Slight mistake in the section above, this is being run inside the project folder, not the /tools/Xilinx/Vitis/2021.2 directory as specified in the error message. However, similar results were obtained as shown below ./gnu/aarch32/lin/gcc-arm-linux-gnueabi/cortexa9t2hf-neon-xilinx-linux-gnueabi/usr/lib/arm-xilinx-linux-gnueabi/10.2.0/crtbeginS.o There were a couple of other things I should note/have questions about. When I packaged the sysroot, this message below popped up. How can I run this inside of Vitis? It seems important, but when I source this file from the terminal and then subsequently launch Vitis from that environment, it still fails to compile. SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /home/bryan/Vivado/Testing/LinuxTest/pLinux/images/linux/sdk/environment-setup-cortexa9t2hf-neon-xilinx-linux-gnueabi There is also this message I see when I compile the project platform in Vitis. I can't figure out why it does not want to copy; when I check the file, I see that it is owned by me. Copying the sysroot data, this may take few minutes... WARNING: Failed to copy boost::filesystem::copy_file: Permission denied: "/home/bryan/Vivado/Testing/LinuxTest/pLinux/images/linux/sdk/sysroots/cortexa9t2hf-neon-xilinx-linux-gnueabi/usr/bin/sudo", "/home/bryan/Vivado/Testing/LinuxTest/Vitis/LinuxPlat/export/LinuxPlat/sw/LinuxPlat/linux_domain/sysroot/cortexa9t2hf-neon-xilinx-linux-gnueabi/usr/bin/sudo" Note: the project path is slightly different than in the original question because I eventually deleted that whole project directory, but this one is setup just the same, it only has slightly different names.

A nice quick tip is that you can also boot over JTAG which is a bit less of a hassle. Just have the board connected to some JTAG, typically over the USB/Serial connection/cable on dev boards. From the petalinux project root: petalinux-build petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --u-boot --fpga images/linux/system.bit --force petalinux-package --prebuilt --force petalinux-boot --jtag --prebuilt 3 And connect to it normally over the serial cable. The base image is something like 16MB. so its not too bad to load onto to it with JTAG, but if the image starts to get larger from packages whatnot it might take a while, and depending on the RAM, I'm not sure if it will load at all. I still can't get TFTP boot to work, so JTAG will have to do for me for now.

Hello everyone, I'm having some difficulty getting applications to compile in Vitis for deployment on embedded Linux. I thought the way I setup the platform project was correct because the included header files were found by Vitis. However, when I compile the program it seems to fail. The weird thing is that it actually did compile and run on my Cora Z7-10 when I hadn't populated all the fields for the platform project. So I believe I may be doing something incorrectly here. How am I supposed to setup the Vitis project properly to get applications for Linux to compile on them? Above is how I setup my platform project in Vitis with (what I think is) the relevant petalinux directory information. Building target: HelloWorldApp.elf Invoking: ARM v7 Linux gcc linker arm-linux-gnueabihf-gcc -L/home/bryan/Vivado/Tutorials/Linux_UIO/Vitis/LinuxUIOPlat/export/LinuxUIOPlat/sw/LinuxUIOPlat/linux_domain/sysroot/cortexa9t2hf-neon-xilinx-linux-gnueabi/lib -L/home/bryan/Vivado/Tutorials/Linux_UIO/Vitis/LinuxUIOPlat/export/LinuxUIOPlat/sw/LinuxUIOPlat/linux_domain/sysroot/cortexa9t2hf-neon-xilinx-linux-gnueabi/usr/lib -o "HelloWorldApp.elf" ./src/helloworld.o --sysroot=/home/bryan/Vivado/Tutorials/Linux_UIO/Vitis/LinuxUIOPlat/export/LinuxUIOPlat/sw/LinuxUIOPlat/linux_domain/sysroot/cortexa9t2hf-neon-xilinx-linux-gnueabi -Wl,-rpath-link=/home/bryan/Vivado/Tutorials/Linux_UIO/Vitis/LinuxUIOPlat/export/LinuxUIOPlat/sw/LinuxUIOPlat/linux_domain/sysroot/cortexa9t2hf-neon-xilinx-linux-gnueabi/lib -Wl,-rpath-link=/home/bryan/Vivado/Tutorials/Linux_UIO/Vitis/LinuxUIOPlat/export/LinuxUIOPlat/sw/LinuxUIOPlat/linux_domain/sysroot/cortexa9t2hf-neon-xilinx-linux-gnueabi/usr/lib /tools/Xilinx/Vitis/2021.2/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ld.real: cannot find crtbeginS.o: No such file or directory /tools/Xilinx/Vitis/2021.2/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ld.real: cannot find -lgcc /tools/Xilinx/Vitis/2021.2/gnu/aarch32/lin/gcc-arm-linux-gnueabi/x86_64-petalinux-linux/usr/bin/arm-xilinx-linux-gnueabi/arm-xilinx-linux-gnueabi-ld.real: cannot find -lgcc collect2.real: error: ld returned 1 exit status make: *** [makefile:38: HelloWorldApp.elf] Error 1 Above is the error I'm getting when attempting to compile in Vitis. Seems like maybe I'm setting up the settings for the compiler or the sysroot wrong?

Zygot, I've been thinking about this response this week. And I think the best option here is like you said So I'll be trying out a couple different solutions. I still like direct LVDS input the best out of the options so I will be getting a board which can more cleanly do this.

Thank you for the response Zygot, and yes I have a bit of pickle here. I understand that there are tons of problems to be solved in this design. I may be hitting this problem with the wrong hammer. The overall goal is to deserialize data from the image sensor I have and collect the data into the onboard DDR memory. I have 4 LVDS channels of data running at 462Mbps each and a LVDS pixel clock that runs at 66MHz. Its a 1:7 deserialization. The initial plan was to use the ISERDES module on the inputs with the LVDS lines, but due to the bank voltage being 3.3V, I would need to terminate it with a 100 Ohm resistor across the lines, which I can't do with the dev board. I had looked into XAPP585 (LVDS Source Synchronous 7:1 Serialization and Deserialization Using Clock Multiplication Application Note) a while back and for Artix-7 SDR designs, it would seems as if I'd be able to drive it 464Mbps, which I believe is due to the global clock buffer only being able to handle 464Mhz. It also seemed like it could potentially go higher if I didn't drive it through a global clock buffer to around 600Mbps. The PMODS are supposedly differentially routed with 100 Ohm impedance (+/- 10%) as stated in the reference manual Digilent gave. I kind of assumed they were all trace matched to each other, but it could be they're only trace matched for the individual pair.I was hoping they could potentially get high enough speeds to accommodate what I need. They also have a single MRCC pair that I was planning on driving the clock line into. I would have preferred to use it for the direct LVDS implementation to help mitigate some of the signal integrity issues single-ended would face on the board. But yeah, I would need a termination resistor for this bank voltage. For LVDS inputs, this FPGA should be able to handle LVDS on a 3.3V, but it does require external termination. I found this in a chart Xilinx put out on their forums here (https://support.xilinx.com/s/article/43989?language=en_US). So the next factor I wanted to try, and I liked this option the best, was using a TI LVDS to LVTTL IC like the DS90CR288A, but they are all out of stock until 5/2023. Otherwise it would have let me deserialize right on the chip for 4channel with a common pixel clock into 28 single-ended bits + a 66MHz single ended clock. And I felt that would be way more manageable. There was some other chips that I could get like the DS90CR218A, which actually has plenty of stock. But it only has 3 LVDS input channels + a clock, and I wasn't sure splitting the clock signal between two chips for a data stream like this was a good idea. I recently found some literature talking about bifurcated termination where once it splits, the impedance goes to 2Z and then terminate 2Z at both chips. But I am not sure if that's such a good idea anyhow, especially considering all the data needs to be aligned with each other. So this is how I got here. The current plan is to use something like a SN65LVDT352PW which just shifts the level from LVDS to single ended LVTTL with a max switching of somewhere around 500Mbps. I was making an interim board that plugs directly into the sensors outputs and the plugs directly into the pmods with just the level shifter chips on board, so I could keep the lines short enough from sensor to chips and from chips to FPGA. I've been having fun learning about making controlled impedance lines for what its worth. This was not my favorite option, but its the option I have right now. I suppose getting a different FPGA dev board might be what I really need to do, but this is hand I'm playing currently. I've checked for a lot leaks, but I'm still fearful my boat is going to sink anyways. This is all pretty new territory for me. The fastest signals I've ever dealt with before were definitely less than 10MHz, so I've just multiplied that by 50. Writing this is at least a good recap to justify things to myself at least. I still think it might be possible, but what scares me the most is I will have no way to verify what the signals even look like, like I;ve always been able to do in the past. My oscilloscope is a measly 1G Sa/s 200MHz bandwidth scope, so It's even hard to even see the pixel clock on it. edit: I thought I would include the board I was making to kind of show the idea. LVDS goes in the left and LVTTL goes out the right. It just plugs right into both boards without the need for cables. It's a bit whack right now and nowhere near done, but that's the concept anyways. The impedance is supposedly right for a JLCPCB 4 layer stackup. If I went with the LVDS to 28 bits out, I would make a shield-like implementation for the Cora Z7-10 that also plugs directly into the sensor board.