Should i care about AXI4 for my project ? - Page 1
Forum section: electronics / general

author: ker2x
author_rank: Regular Contributor
timestamp: October 13, 2019, 04:20:18 pm
content: Friendly greetings !I'm a beginner, i haven't received my board yet and the lasts time i played with FPGA was a few years ago with Xilinx ISE and a bare Spartan-6 FPGA (with UART usb interface). It was a disasterI'm back, with a proper dev board from Digilent and a much easier to use vivado.So i'm playing with vivado in the meantime (webpack edition) and the block designs.I like it, of course, and now i want to create my own block and IP and make my project (a 6502 computer, it's the end-goal, but i won't start with that).Every single tutorial i watched to create blocks, they created AXI4 module.I'm not really sure want AXI4 really is to be honest. To me, it just look like a protocol (+ some other convention) as a common interface to talk to the Zynq, Microblaze, and a bunch of IP so they are compatible to each-others.But now i'm a bit confused, since all blocks used AXI4, does it mean i can't create useable block without using AXI4 ? it is a requirement ?Should i bother with it because i'll be glad later in the future that my blocks use AXI4 ? Or because it will help me to design better reusable module at the cost of higher complexity ?Or is it just Xilinx pushing marketing hype for AXI4 ?The answer will be "it depends", probably. If i wanted to add a microblaze in my project i guess the answer would be "yes because you have to". But if i don't use a microblaze or a zynq ... ?Of course, i don't really want to use AXI4 since i'm not even sure what it is in the first place. But if you tell i should use it... well... i willPS : i triple checked the UART block that come with the board and it's an AXI block. So i have to have design at least 1 AXI module.PPS : do i even make sense or did i completely misunderstood the whole axi stuff ? (it's highly probable)thank you

author: ataradov
author_rank: Super Contributor
timestamp: October 13, 2019, 04:37:29 pm
content: AXI is the native bus of the CPU core. So if you want a peripheral that is directly attached to the CPU bus, then yes, AXI is unavoidable. But for typical peripherals, like timers and GPIO port AXI is a huge overkill.Typically there are AXI-to-XXX bridges, where XXX is a simpler bus. In the AMBA architecture it will probably be APB bus.I have not followed the latest development with buses, I don't believe they would want you connecting UARTs on the CPU bus. That just does not make any sense. So in any case, it is likely to be connected to some sort of AXI-AXI bridge.And if you don't want to use any of the processor cores, then there are easier ways to get a UART working. But if you want to talk to their IPs from your logic, then you have to use AXI, obviously.

author: ker2x
author_rank: Regular Contributor
timestamp: October 13, 2019, 04:51:43 pm
content: Quote from: ataradov on October 13, 2019, 04:37:29 pmFrom what i understand from the (simple) tutorials, they just create a simple verilog source (a few line of code for a full adder), click on a magic button to generate the AXI block and the whole AXI stuff is just a wrapper.The "original" verilog code doesn't care about AXI, bus communication, eventual protocol negociation, etc.Still from my understanding, using AXI allow the block design tool to understand that the clock is a clock, the reset is a reset, and so on, in order to autoconnect everything.And probably do some other automagic stuff like generating the wizard in order to modify the block configuration. (eg: bus width)My question still remain despite that. Do i have to use AXI in order to create block useable in the designer ?And even if it's not a hard requirement : should i do it anyway ?

author: ataradov
author_rank: Super Contributor
timestamp: October 13, 2019, 05:03:29 pm
content: Quote from: ker2x on October 13, 2019, 04:51:43 pmWell, it would have to care to a certain extent if it has logic that is driven by the commands from the bus. If it is an adder, it would have to know how to take two input values and return the result.Quote from: ker2x on October 13, 2019, 04:51:43 pmIf you want to use processor cores, then you have to use AXI, for sure. I have not worked with Vivado to tell if its designer is useful without the processor core. I personally would stay away from graphical drag and drop designers as far as I can.

author: ker2x
author_rank: Regular Contributor
timestamp: October 13, 2019, 05:22:27 pm
content: Quote from: ataradov on October 13, 2019, 05:03:29 pmI'm not planning to use any IP except the ones provided by digilent : UART and DDR2 Controller."Digilent will provide a VHDL reference module that wraps the complexity of a DDR2 controller and is backwards compatible with the asynchronous SRAM interface of the CellularRAM, with certain limitations."I will use it because i understand that DDR2 is notoriously difficult to use for a beginner.I understand why you wouldn't want, or even recommend, to use a graphical tool. Because you know how to do stuff without it.But... i already tried in the past. With a barebone FPGA and Xilinx ISE. The entry barrier was just too much for me. I gave up, it was too much. i had to learn everything from zero without anyone to help me.And i still don't know anyone in my social circle who even know that FPGA exist and that Verilog isn't something made by VeritasSo, yeah, i'll use graphical magic.

author: ataradov
author_rank: Super Contributor
timestamp: October 13, 2019, 05:28:08 pm
content: The DDR wrapped into SRAM-like interface is a good idea and it should be very simple to use.The graphical designer in this case will solve the easiest part of the problem. You will still have to write the code behind the blocks. And interconnecting the blocks from the code is trivial.I think the designer will confuse you even more, not help. The designers is fine for CPU-based system with buses, since it is a lot of similar signals going to the peripherals. Doing that from the code is annoying.

author: ker2x
author_rank: Regular Contributor
timestamp: October 13, 2019, 05:38:58 pm
content: Quote from: ataradov on October 13, 2019, 05:28:08 pmWell, my end goal is to create a CPU inspired from the 6502 and a full computer while i'm at it. So...My first project will involve playing a lot with the VGA port. I just can't wait to do some graphical demo, understanding VESA and the differents mode, sprites, characters, keyboard, sound, ...Basically doing some hardwired stuff involving a computer, but without the CPU yet.Then display the bits in RAM to the screen, then add some keyboardy stuff, blip and bloup from the audio, and so on.building block i'll later be able to partially or fully reuse.It's mostly wishful thinking of course. it will probably instead involve a lot of tears, sweat, andbloodfrustration.

author: ataradov
author_rank: Super Contributor
timestamp: October 13, 2019, 05:43:03 pm
content: This is a good goal and overall I would not call this unimaginable even for a beginner. There are lots of examples for all of this.But again, the designer is not going to be helpful here at all. Modern designer in Vivado is not the same thing as graphical entry languages of the old days, it is just a way to connect blocks together. This is easy to to from the code. The hard part is to fill the blocks with the actual logic.

author: ker2x
author_rank: Regular Contributor
timestamp: October 13, 2019, 06:00:07 pm
content: Quote from: ataradov on October 13, 2019, 05:43:03 pmWell, yeah.I could use pen and paper to draw some block diagram. Just like one would do a class diagram when writing OOP, or UML for a database design.I just came out of a long debate because i wanted to do my project out of TTL chips and everyone tried (successfully) to convince me to use an FPGA.I finally got convinced when someone told me i could simply create 74xx chips in verilog/vhdl and connect them using the graphical tool. (well, it convinced me but that would be silly to actually do it)And now you guys tell me to not even use the graphical tool, you'll kill me before i even receive my card. give me a break, my poor mind is breaking

author: ker2x
author_rank: Regular Contributor
timestamp: October 13, 2019, 06:01:15 pm
content: And we're super offtopic btw, my question was about AXI

author: Someone
author_rank: Super Contributor
timestamp: October 13, 2019, 11:26:10 pm
content: Quote from: ker2x on October 13, 2019, 04:20:18 pmStart with the big picture, a 6502 computer, good. Now throw away all your thinking so far as its taken you away from the goal.Quote from: ker2x on October 13, 2019, 04:20:18 pmIf you blindly use things you don't understand it ends up like this:https://www.eevblog.com/forum/fpga/unspecified-io-standard-in-vivado-when-trying-to-set-axi-gpio-to-1-bit-width/Quote from: ker2x on October 13, 2019, 06:00:07 pmThe high level tools such as the system level block "flow" are designed around high level abstractions. It can be abused to doschematic entryas is available in other tools, but that isn't supported so you're on your own.People have moved away from schematic entry because:its hard to edit, add a new part in the middle of a schematic and you need to move everything around to fit, add a line of code is easyits hard to compare, diff tools on text entry make it easy to follow/track changes to a designthere is no standard, your schematic design is not portable to other tools or possibly even other devicesbut back to your original questions..Quote from: ker2x on October 13, 2019, 05:22:27 pmThere are many different UART "IP" available. You don't mention the actual board or chip you plan to use, there are different UARTS. Some are already in the "hard" resources and cannot be changed, but most are just a wrapper around some lower level code which implements the UART on the FPGA fabric. If you have a different interface and aren't using hard resources, then you usually create your own UART "IP" to match your requirements.Building an AXI compliant 6502 could be an interesting project, and would let you reuse all the AXI IP. But your original plan was likely the opposite of taking the typical 6502 and building your own peripherals.

author: asmi
author_rank: Super Contributor
timestamp: October 14, 2019, 01:49:57 am
content: Quote from: ataradov on October 13, 2019, 04:37:29 pmI'm sorry, but what bus is simpler than AXI MM/AXI Stream? I think it's as simple as it gets.

author: Someone
author_rank: Super Contributor
timestamp: October 14, 2019, 01:58:06 am
content: Quote from: asmi on October 14, 2019, 01:49:57 amMost things without wait states/logic, there are plenty of busses in use that are non-blocking.

author: exmadscientist
author_rank: Frequent Contributor
timestamp: October 14, 2019, 04:58:05 am
content: Quote from: Someone on October 14, 2019, 01:58:06 amWhen talking about AMBA/AXI4, it is important to remember that there are three flavors of it:AXI4, which really should be called "AXI4-Full"AXI4-LiteAXI4-StreamThe Full and Lite protocols are indeed pretty heavyweight. (But they might make sense if you'd be rolling your own version of any of the features they provide.) AXI4-Stream, in contrast, is nice and lightweight. On my last FPGA project I converted the interface for any module I touched over from "homebrew handshaking" to AXI4-Stream; mostly this just involved renaming a few signals. It's a great starting point for gluing together logic blocks, and is my go-to for the interface of a new custom component.

author: ataradov
author_rank: Super Contributor
timestamp: October 14, 2019, 05:03:01 am
content: But in any case, it is probably not a good idea to have many "slow" peripherals attached to the main CPU bus. Closing timings with a lot of slaves may be hard. Even if you use AXI entirely, it will be better to hide the peripherals behind AXI-to-AXI bridges.

author: ker2x
author_rank: Regular Contributor
timestamp: October 14, 2019, 05:24:09 am
content: The board is a Nexys 4 DDR.The USB-UART chips is a FT2232HQ from FTDI, the block provided is just the Xilinx UART-lite IP, it use AXI4-Lite.The ethernet port have no controller on its own so it's Xilinx IP too, i have no use for it (yet).The USB/SDCARD controller is a PIC24, i believe it's just SPI.The VGA port is just 14 resistor and physical connecter, no IP are provided, nor needed. i want to develop my own.Misc device (temperature, ...) are either I2C or SPI.As for the DDR2/SRAM block, i didn't check yet, but from my understanding it won't be a Xilinx IP.

author: ker2x
author_rank: Regular Contributor
timestamp: October 14, 2019, 05:51:30 am
content: Quote from: ataradov on October 14, 2019, 05:03:01 amIt's too early for me yet to be confident about my design. But :I'm not planning to connect any peripherals to the main CPU Bus. I have a slow 8bit 6502 connected to a fast & massive 128MB DDR2.The floppy will be in RAM, Screenbuffer in RAM, everything in RAM, so the periperhals will be much faster than the cpu. Why bother to do any other way ?I could even use the BRAM for the computer RAM. I have 4Mb On the Artix-7 100 and the max adressable ram in 16bit is 64Kb.

author: ataradov
author_rank: Super Contributor
timestamp: October 14, 2019, 05:54:46 am
content: For 6502 none of this discussion matters at all. You can approach it the most unoptimal way you can think of and it will work fine. It starts to be a concern when you need your buses to work at > 100 MHz.

author: ker2x
author_rank: Regular Contributor
timestamp: October 14, 2019, 06:02:46 am
content: Quote from: ataradov on October 14, 2019, 05:54:46 amExactly

author: ker2x
author_rank: Regular Contributor
timestamp: October 14, 2019, 06:19:19 am
content: If i wanted to do serious number crunching with my FPGA i would have bought a Zynq.I know my self, I would have ended up with a glorified Raspberry Pi and spend all my time playing with HLx and/or SDAccel. And do C/OpenCL instead of Verilog.

author: asmi
author_rank: Super Contributor
timestamp: October 14, 2019, 02:01:06 pm
content: Quote from: Someone on October 14, 2019, 01:58:06 amLike what? AXI uses the simplest handshake method there is (ready/valid). AXI specification allows tying ready high if the slave is always able to accept data.Please show an example of "non-blocking" bus that would still guarantee data delivery.

author: asmi
author_rank: Super Contributor
timestamp: October 14, 2019, 02:07:39 pm
content: Quote from: exmadscientist on October 14, 2019, 04:58:05 amYou make it sound like they are interchangeable. They are not. AXI Full and Lite buses are memory-mapped, while AXI Stream is not. If you need to provide addressable access to your registers, or need to have such access to something else on a bus, there is no other option.Quote from: exmadscientist on October 14, 2019, 04:58:05 amThis is good if you need to stream data (hence the name).

author: rstofer
author_rank: Super Contributor
timestamp: October 14, 2019, 05:33:59 pm
content: Until very late in the ISE game the Xilinx IP wasn't available at no cost. Hence, I have never used it. But the AXI stuff is related to the Xilinx MicroBlaze core and, if you're just doing a 6502, you won't be using that at all.Another hint: I have a fully functional IBM 1130 minicomputer and an implementation of the LC3 processor along with a couple of Z80 projects and I have never used a bit of Xilinx IP. It just doesn't play into what I want to do - build CPUs. Now, if I were building some 'gee whiz' project that needed a fully featured core and I didn't want to build all of the logic, of course I would head for MicroBlaze. That project would be about the application, not the core.Here's the thing, CPUs are, at their heart, nothing but state machines. You need to know how to code them. I would start by looking at the state diagram for the LC3 project and think about how that kind of diagram could be used to describe a 6502. Not necessarily a cycle accurate implementation but a functionally equivalent one. Or you can go for cycle accuracy, there's a core like that on OpenCores.orgFirst up, you must install the Digilent board files because they are going to help you create the Constraints File for your project. You say you like Vivado more than ISE? Wait until you deal with the new and improved Constraints File. What a gigantic PITA! Nevertheless, it is what it is and the board files give you a leg up. On reflection, I'm not so sure about that but install them anyway. There's a discussion at Digilent, I think.The next step is Hello World - a blinking LED. The clock frequency is 100 MHz so you need to divide by 50 million of so. Implement a 25 bit counter and use the high bit to drive the LED pin. I have attached a .vhd and .xdc file for your perusal. I apologize for the regrettable entity and file names but I ripped the code from my LC3 project rather than starting from scratch. Exercise: Build another project and name the files and entity properly as HelloWorld to match what I assume is your project name. Pare down to a minimal set of libraries. They will all be necessary later but not for a blinking LED.When you create the project, don't forget to click on the Boards tab and find your board rather than the device. You can choose to add the source and constraint file (in separate steps) as you create the project. If you do, they will be considered 'imported' and a little farther down in the files tree. Or, you can create, copy and paste the files. That gives you a chance to name the files properly. Then all you need to do is a little Replace LC3 with HelloWorld to clean up the mess.I have forgotten where my fully featured .xdc file came from I have included one for your use.ETA: When I first started with ISE, I found a step-by-step tutorial to make an LED blink. It was very helpful! Vivado seems more involved so I thought I would add a README.txt file that should come somewhere close to the proper procedure for creating the HelloWorld project given the files in the .zip archive

author: rstofer
author_rank: Super Contributor
timestamp: October 14, 2019, 05:43:18 pm
content: Remember, VHDL doesn't like open collector 'wired and' buses. Actually, it isn't VHDL that has a problem, it's the internal construction of the chip.You may think you can 'Z' a signal but what will probably happen is that the bus will be implemented as a MUX. If you have several registers that talk on a bus, you might as well start right off implementing the MUX. When you draw the block diagram, just put the MUX on paper right from the beginning. ISE used to whine and snivel about attempts to implement wired-and. I'm not sure about Vivado.You can create in-out signals on IO pins as would be required to talk to off-chip devices like memory over a bi-directional bus.

author: rstofer
author_rank: Super Contributor
timestamp: October 14, 2019, 07:18:53 pm
content: Quote from: ker2x on October 13, 2019, 06:00:07 pmI have only used schematic entry once and that was to instantiate a full adder because I couldn't seem to figure out how to do it in code. That was a long time ago...If you wanted to build up 74xx components, as they are called, you would simply create the code in a file and instantiate it in your design. This will leave you with a Port Map of the IO pins. You connect the various pins to other devices with common everyday signals which you have to declare at the top of the file. There's nothing special about this, every device you add, whether UART, RAM or any other component is instantiated the same way.Assume that in another file, named uartRx.vhd, I have designed the entity for the UART receive component. In an upper level, in my case the top level, I want to incorporate it in the design and wire it up. That instantiation looks like this:Code:-- uartRX is the KEYBOARD device -- INPUTinst_uartRx: entity work.uartRxPort Map (clr => Reset,clk => ClkIn,ce16 => ce16,serIn => Tx,rxData => KBDRin(7 downto 0), -- 'in' from the CPUs point of viewnewRxData => newRxData);Every signal on the left of the => symbol is defined in the entity file. Every signal on the right is where I connect it at this level.You can see how a 7400 would have 8 inputs and 4 outputs (1A, 1B, 1Y; 2A, 2B, 2Y; 3A, 3B, 3Y, 4A, 4B, 4Y) where the As & Bs are inputs to the entity (outputs from some other logic) and the Ys are the outputs (inputs to logic at this level).

author: rstofer
author_rank: Super Contributor
timestamp: October 14, 2019, 07:45:26 pm
content: FreeRangeVHDL Listing 9.1 shows a method for defining those logic chips you wanted to use. Of course, you have to decide if you are defining a logic gate, perhaps 1 of 4 NANDs in a 7400) or you are defining the chip which will have ports for all 8 inputs and 4 output. Your choice.

author: Someone
author_rank: Super Contributor
timestamp: October 14, 2019, 11:21:35 pm
content: Quote from: asmi on October 14, 2019, 02:01:06 pmYou're probably arguing the semantics of "bus" now, an async SRAM has no handshake and offers up a bus, the same sort of interface can be applied to any number of register interface peripherals.

author: rstofer
author_rank: Super Contributor
timestamp: October 15, 2019, 01:05:35 am
content: Quote from: ataradov on October 13, 2019, 05:03:29 pmIn terms of creating blocks with VHDL or Verilog (and maybe System Verilog, IDK), nothing is unique about Vivado. Just add a blank file to the system and start typing. Because I want to build very simple things, I don't use any of the Xilinx IP. If I ever get to the point of using DDR memory and don't plan to use Digilent's component, darn right I will use the MIG IP. Nobody in their right mind wants to code that interface. If that drags in some other requirements, I would get over it. Just go with the flow...Here's some really good news: There is NO schematic editor in Vivadohttps://forums.xilinx.com/t5/Design-Entry/Schematic-Design-Entry-Tool-in-Vivado/td-p/278260As to the UART, I think I grabbed it from OpenCores.org. There are 3 files: Receiver, Transmitter and BaudRateGenerator. There's no copyright so I don't know who wrote it. If it seems useful, I can zip up the files. It certainly works ok for my LC3 project but there are many alternatives out in the wild.The parameters for the divider in the baud rate generator are given at the top level, in my case. Ordinarily, the parameters are given in the generator itself but I didn't want them buried that deep in the tree. Just in case I had to change baud rates.ETA: OpenCores has some dodgy code and I have read many threads where people don't like OpenCores. Well, I guess you get what you don't pay for! Like all open source, some is good, some is bad. It can't hurt to look and at least see how somebody else approached the problem.

author: rstofer
author_rank: Super Contributor
timestamp: October 15, 2019, 01:13:21 am
content: In your other thread, I discussed Hamster_nz's code to initialize BlockRAM at design time from the contents of a .hex file. Think about how you plan to boot your 6502. When first turned on, all of the BlockRAM is zeroed. You need boot code and the way to do it is to use a 6502 assembler to create a .hex file and Hamster_nz's code to build the .hex file into the .bit file.As an exercise for the reader, use the .hex file as a loader to read an OS off of the SD card. SD card reader code by others. Note that OpenCores has their own bus interface so it might take a bit of effort to convert their SD card code to something you can use.Big hint: I find the 'dd' command in Linux to be very helpful for laying down raw images on SD and CF cards.ETA: If the boot code is initially in the BlockRAM, it will be present at boot time - once! If you use a Reset signal to reset the state of the core, that's not the same as loading the .bit image so the code won't be present (necessarily). One way to solve this is to create a process that copies the code from another chunk of BlockRAM into the main memory at boot time. I do this on my IBM1130 as the first few states of the FSM before I ever get to Instruction Fetch. Or you could map the block in and out of the memory map. Lots of alternatives but just realize when you will, and won't, have BlockRAM initialized.

author: exmadscientist
author_rank: Frequent Contributor
timestamp: October 15, 2019, 05:10:16 am
content: Quote from: asmi on October 14, 2019, 02:07:39 pmYou are, of course, quite right. Slightly less hastily, the points I was trying to make were:Don't confuse AXI4-Stream and AXI4-Lite/Full. They are very different protocols.If you find yourself re-implementing features that AXI4-Lite would provide for you, such as addressing &c, you should consider just adopting AXI4-Lite instead of writing your own half-baked implementation.If you are writing something for which AXI4-Stream might be appropriate, consider just adopting it outright. The AXI4-Stream specification was carefully thought through by skilled engineers. If you adopt it, you can leverage their work and quickly build robust, well-defined, clearly extensible interfaces. The standard is also simple and easy enough to understand that this is readily feasible. The effort saved in documentation alone can pay for itself quickly.

author: OwO
author_rank: Super Contributor
timestamp: October 15, 2019, 10:00:47 am
content: Quote from: asmi on October 14, 2019, 02:01:06 pmActually there is an easier to use handshake protocol (ready/strobe), where data strobes are still allowed N cycles after ready is deasserted... well easier to use when you want to close very tight timings.

author: xlnx
author_rank: Contributor
timestamp: October 15, 2019, 10:42:21 am
content: The #1 reason to use AXI4 is that it is a standard. Once every IP complies with a standard, you can focus on their functionality rather than their interfacing. AXI4-Stream and AXI4-Lite are indeed very, very simple. For proper handshaking only a couple of registers are needed. I have written a short introduction in my blog here:http://que.no/index.php/2016/03/13/principles-of-fpga-ip-interconnect/I would much rather use AXI4 which is a synchronous protocol, rather than "ready/strobe" which might be asynchronous depending on the actual meaning of "ready/strobe".I have an example VHDL code for an extremely simple AXI4-Lite target with register access if that is of interest.

author: OwO
author_rank: Super Contributor
timestamp: October 15, 2019, 11:00:46 am
content: AXI is what I use for large scale integration (big modules) and internally I can use whatever is most appropriate.Quote from: xlnx on October 15, 2019, 10:42:21 amIf you mean synchronous as in synchronous logic, then yes it absolutely is synchronous, but if you mean synchronous as in sending a request, waiting for its completion, then continuing then it is not synchronous and that's the point. Being able to close timing means you must accept some latency in flow control, which means very well that data can continue to flow for a bit after you decided it shouldn't. The way to deal with that is a skid buffer, and using AXI requires small skid buffers everywhere while a delayed flow control protocol allows a few bigger skid buffers:https://www.eevblog.com/forum/fpga/some-thoughts-on-axi-pipe-handshake-protocol-and-timing-closure/

author: xlnx
author_rank: Contributor
timestamp: October 15, 2019, 11:23:25 am
content: A double-buffer or FIFO is required only if you need to clock data on every clock cycle - apart from that AXI4 (Lite or Stream) does not *require* a buffer. In fact, for AXI4-Lite, there is typically so much latency in communicating with a peripherel, that having extra buffers is a waste of resources. As I said, all handshaking can be handled using a couple of registers, and you get a synchronous design - which is very much desired in RTL code.

author: Ditiris
author_rank: Contributor
timestamp: November 01, 2019, 01:25:56 pm
content: ker - looks like this got a bit off topic. Hopefully you have a good idea of what AXI is by now. I would say look at the HDL generated by Vivado for an AXI-Lite peripheral and make sure you understand it. That will allow you to talk to your processor or any other block you create within the AXI system.

author: rstofer
author_rank: Super Contributor
timestamp: November 01, 2019, 06:17:37 pm
content: I was at the Pynq site yesterday and there is a lot of discussion about making custom IP and connecting it to the AXI interfaces. I'm not saying it applies here because, in my view, it clearly doesn't but it is worth the time to watch a couple of videos and study the workflow for use with Zynq processors.https://github.com/Xilinx/PYNQ_Workshop