I am looking to transfer data from the zynq ddr to a custom ip, then store the result on the sd card. The sd card is connected through the emio pin, so it is available to the PL. So far, I can access the DDR from Windows, so I put files there. All I need is to connect each component in vhdl to send and receive data from each other. My current Block diagram has AXI stream FIFo, AXI DMA, BRAM generator, and BRAM controller. I've read different tutorials, and only find how to set up the hardware, but not how to connect each piece. Any ideas?
Block Design
The easiest way is using a Linux distro to access the SD card.
Afterwards you can use AXI4 or AXI4S to communicate.
DMA is you friend to copy data from RAM to AXIS and back.
If you want to transfer data directly using AXI4 you can test it with devmem from busybox by accessing the corresponding register. This can be AXI BRAM Controller or AXI GPIO for example.
Related
Is there a way to access NodeMCU's EEPROM using Lua?
I would like to store data to the EEPROM on NodeMCU but I cannot find any libraries to do so in Lua.
You have the Flash memory accessible through the normal File interface and the NVram on the RTC chip accessible through the RTC User Memory Module.
I am using a i.Mx6 Sabre Lite board running Linux Kernel 3.14.18 and board is supposed to act as a USB Device (USB Gadget). One Vendor specific interface need to be added into CDC/NCM Configuration. CDC/NCM Configuration by default has two standard interfaces - Communication & Data. I have added third interface (Vendor specific) to CDC/NCM Configuration. This interface has two Bulk (IN & OUT) Endpoints. I can verify this newly added interface once board is connected to PC using "lsusb".
Problem:
I cannot see the newly added interface getting exposed to user-space on i.Mx Board or PC, like standard NCM interfaces can be seen as usb0 (Ethernet device) on i.Mx Board as well as on PC and I can PING to/from board using usb0.
If I have to hookup this newly added interface with some g_"driver" (just like standard NCM interfaces are hooked to g_ether); then what is the best choice for BULK I/O?
How to make this newly added vendor specific interface available to i.MX6 user space so as to do read/write on it from Linux Application? I came to know about GadgetFS; but any example would be
Hope someone must have tried similar thing in Linux-USB and can guide.
A vendor-specific interface does not use a standard protocol, so it is not possible to use one of the standard drivers. (And bulk is not a protocol, it is a mechanism to implement your own protocol.)
To access such an interface, you have to use the low-level functions from something like libusb.
Is there any AXI4Lite slave IP (Verilog, VHDL) available under GNU GPL?
I want to test a virtual AXI4 master in a uP system and hence this requirement.
Just an AXI4 slave or AXI3 slave will also do (I can strip down the signals to make it AXI4Lite compatible).
Any links, source code will be helpful.
You can use AXI slave template implemented in the following repository (VHDL, BSD license):
https://github.com/sergeykhbr/riscv_vhdl
File types_nasti.vhd implements general methods to work with the AXI bus. NASTI is the other name of the AXI interface invented by this team
http://riscv.org to avoid trademark usage problems.
The project structure is very similiar to Gailser's LEON3 implementation but it implements 64-bits Rocket-Chip CPU (RISC-V ISA) and several AXI4 modules: UART, GPIO, IRQ controller etc.
A clear idea about AXI protocol can be obtained at AMBA AXI and ACE Protocol Specification AXI3, AXI4, and ....
Other opencore small purpose IP is available at opencore website.
Many YouTube videos are also helpful for beginners. video site.
A detailed understanding about AXI IP is a must thing for designing it.
Could anyone please tell me about the AXI bus and its signals. I would also want to know about AXI bus to wishbone bus wrapper to implement it in VHDL.
I am looking at the implementation of a register in FPGA and then give the corresponding commands from LINUX to drive the LED's on a zedboard. wishbone bus is used to transfer the data and make communication with the register.
Here are some documents for the AMBA (Advanced Microcontroller Bus Architecture) including AXI and AXI-Light:
Xilinx UG761 - AXI Reference Guide
ARM - AMBA Open Specifications
Wikipedia article
If you are going to write a GPIO to register mapping module for WishBone, why don't you write a AXI to register / GPIO mapper and spare the AXI2WB bridge?
I thought OpenCores has a AXI2WB wrapper, but I can't find it.
I know, that this is an old question, but as there is no answer providing link to the right HDL source, I'd like to propose a few:
There is an AXI to WB bridge written in Verilog by Daniel Strother (it was written in 2011)
On OpenCores there is a very simple AXI4-Lite to Wishbone bridge (the project contains also AXI4-Lite to IPbus bridge) written in VHDL by me and my colleague.
few days ago I asked here about implementing USB. Now, If I may, would like to ask few more questions, about thing I dind´t quite understood.
So, first, If I am right, Windows has device driver for USB interface, for the physical device that sends and receives communication. But what this driver offers to system (user)? I mean, USB protocol is made so its devices are adressed. So you first adress device than send message to it.
But how sophisticted is the device controller (HW) and its driver? Is it so sophisticated that it is a chip you just send device adress and data, and it writes the outcomming data out and incomming data to some internal register to be read, or thru DMA directly to memory?
Or, how its drivers (SW) really work? Does its driver has some advanced functions like send _data to _device? Becouse I somewhat internally hope there is a way to directly send some data thru USB, maybe by calling USB drivers itself? Is there any good article, tutorial you know about to really explain how all this logic works? Thanks.
The USB protocol stack has several layers and is quite complex. You really need to read a good book on USB (e.g. USB Complete) to get an understanding of how it all fits together. The bottom line though is that you want to go as high up the protocol stack as you can, ideally using a system level API (e.g. if it's a USB HID device then just treat it like any other HID device, rather than thinking if it as a USB device - ditto for mass storage devices, etc).