zygot

My opinion is that for someone just starting out learning about FPGA development should start with a board just like yours. FPGA devices with an embedded hard ARM complex just adds to the complexity... and there's plenty of complexity for a beginner in programmable logic to master. A very small percentage of my projects involve a processor in the FPGA, whether a soft-processor like MicroBlaze or a hard processor like ARM. At some point you need to be able to create you own IP and designs that are FPGA vendor agnostic. And even if you are targeting a ZYNQ ir the like, you will need to have good logic design experience. Trust me, the Arty can keep you busy for a very long time honing those skills. I think that a lot of people ( especially those who work for ARM Holdings ) see the ZYNQ as a microprocessor with some FPGA logic attached. I see it as an FPGA with an attached, relatively high performance microprocessor. A lot of my projects are just that... one or more FPGA devices that communicate with a PC or SBC via PCIe or USB 3.0. This can usually provide more processing horsepower and flexibility than an ARM based FPGA. Software development is easier as well. My ZYNQ projects usually require two software projects; one for ARM and one for a PC. If you are building a small embedded system then ZYNQ is a pretty nice way to go. Put off the ZYNQ platform until you have mastered logic design verification and debugging. When you need to use an ARM-base device you will be in a much better place to do so effectively.

Unfortunately, for simple basic beginner's projects like yours, the ZYNQ architecture just gets in the way and makes such projects like yours more complicated. For a "2 input AND gate" project you really don't need a PC connection. But when you want to control a more complicated design you will need a more complicated user interface. The easiest way to connect your board to a PC is the PS UART. But, for now, you really just want to create some logic and control that from a PC. The good news is that yes you can do that. For $15 or less you can buy a 3V compatible TTL USB UART cable or breakout board from either Sparkfun or Adafruit. You only need 2 pins on a PMOD connector and an HDL UART component to achieve your aim. In this case the ARM cores are idle an not involved. No ARM software design. The best way to do the design is with VHDL or Verilog. At some point you will want the ZYNQ PS to communicate with a design in the PL. For high speed data transfer you need AXI slave or master components in the PL. This is for more advanced developers if you want to have an all HDL PL design. The easy way around that is to use a board design that uses some of the various AXI IP provided for free with Vivado. I prefer to have Vivado create an HDL wrapper for the board design and then instantiate the wrapper in my own toplevel HDL entity. I tend to use the least amount of AXI IP possible for a lot of reasons. The board design flow can be quick and easy, or just limiting and frustrating; it ll depends on what you are trying to accomplish. I only use the board design flow for ARM based FPGA project, and then use the minimal amount of Xilinx board design IP as possible. There's an even easier way to write PS code to read and write registers in the PL by muxing the unused PS UART to the EMIO that connects to the PL directly. As a matter of fact I just happen to be working on a demo to do just that. I can write an addressable 32-bit register in the PL and read back the new register value in less than 10 us. I can also read an addressable 32-bit register in the PL in under 6 us. All of this by using the PS UART registers, just like I'd do for a micro-controller. If you want to have faster access, then you can just address smaller register sizes like 8 bits. Hopefully, I'll have the demo in shape to post within the week. While this method isn't good for high speed data transfers between the PS and PL logic, it certainly works fine enough for a project like yours. It's also a nice way to view PL logic states for debugging purposes... potentially even better than the Xilinx ILA and VIO IP. It's quite possible to using one PS UART to connect to a PC and the second one to connect to the logic at a much higher data rate. Actually, a lot of nice things align nicely with this method for ZYNQ. I've been using a similar, but slower and more complicated scheme for years as a debugging aid for non-processor FPGA designs. There's generally more than one way to do things. I generally prefer the simpler way, when it's available and gets the job done.

The MIG example design is fully synthesizable and can be run on hardware as long as your platform has the resources to support the ILA and VIO components. The example design is, in my opinion, overly complicated and hard to follow. The tutorial remedies some of that. The MIG IP, like many of the Xilinx IP, could use some cleanup and love. I've never found the Xilinx User Forums to be particularly helpful. Xilinx's position on its tools seems to be: Everything works as it should, and if it doesn't you can try tracking down all of official errata and design advisories ( that may or may not be germane to your tools version, and if you still can't figure it out then it's your fault, because everything that we provide is as it should be, and while we don't actually address all of the issues presented by customers with official design advisories that's not our problem. If you have any questions regarding following the tutorial, I'd appreciate you posting them there. I've made it clear why I don't think that it's possible to create a general tutorial to fit all platforms and designs and why the tutorial needs to be interactive.

I recommend that you stick with the memory parts listed in the reference manual for your board Make sure that you are writing a sufficient amount of data to support whatever the DDR PHY data rate is. If the UI data width is half the number of bytes/s that the DDR PHY data rate is, then you will have to write 2 UI data words to the UI FIFO per write command. Each read command will provide half of the DDR burst data. Make sure that you understand how to handle the situation when the UI rdy signal is de-asserted. Make sure that your device supports the clocking rates needed for your MIG choices. I've posted a tutorial here: https://forum.digilentinc.com/topic/22197-a-guide-to-using-ddr-in-the-all-hdl-design-flow/ that might help. A good place to start, is to implement the MIG example design on your hardware. There's a lot to be gleaned from the exercise.

To anyone struggling with DDR for processorless designs, have you looked at this? https://forum.digilentinc.com/topic/22197-a-guide-to-using-ddr-in-the-all-hdl-design-flow/

I agree with this, in general. But Vivado 2019.1 ( or was it 2019.2 ? ) changed the way that it handled the IP database, so any old code using any Xilinx IP got broken. Not a huge deal; I just had to re-created the IP. This includes basic IP like MMCM, BRAM based memory, etc. I've had the experience of FIFO IP eliminating a feature that old HDL code depended on. That's why many companies never use FPGA vendor IP at all. Most of the problems I've had lately resolve around IP, particularly FIFOs, that get broken in newer tool versions. Fortunately, Xilinx doesn't make such drastic changes that often. We'll ignore the really old ISE versions for this discussion. Recently, while trying to use demo projects from an FMC mezzanine card vendor, all board design, I've discovered that the "same" IP instantiated in a board design can be quite different than when instantiated in and HDL. I mention this to point out that when you never use a particular design flow, ( in my case board design ) you might be apt to make incorrect assumptions about the tools.

I agree with you ( about wanting to clear up posts that are confusing or just plain wrong) ... and hate to inform you that this statement, from you, is incorrect. I own 2 different boards made by and sold by Digilent that require a device licence..... both Kintex based. Of course you know this according to your previous post. I really am happy to be corrected when I make a misstatement... but if you are going to add the accusation that someone is "spreading misinformation" than you should be doubly careful about what you post yourself... everyone, including the both of us, has made "unfortunate" posts. We can correct mistakes without adding slander or personal attack element. If you really dislike everything about what I post, that's OK with me; but try to the facts from the emotions. I feel comfortable suggesting that anyone install new tools verify device support and ( among quite a few other things ) OS version compatibility; though to a degree you can sometimes get away with fudging the host OS version. BTW, I second your observation about doing ARM based FPGA development on a Linux host.

What @D@ncovers is (somewhat) Series7 specific. If you get bored because you've mastered all of the intricacies of AXI then you can purchase an UltraScale+ MPSoC and take on ACP and ACE PS-PL interfaces. Worry about cache coherency and snoop control units too. It'll never stop. A lot has changed with those devices verses the Series7 devices.. something that I'm working on now. Personally, I'd advise someone with a plain FPGA platform like the Arty A-whatever or Arty 7-whatever to put off AXI and soft processors and just concentrate on developing your logic development chops. Of course if all depends on what goals you want to accomplish. I believe that it's pretty easy to jump into endeavors that are beyond one's skill level. There are a lot of facets and levels to this programmable logic design stuff.

@asmi Well, it's true that sometimes the newest versions of FPGA vendor tools add free support for devices that previous tool versions don't. If you are just starting out in FPGA development and are installing a vendor toolset for the first time, then I'd recommend installing the very latest... if the latest also supports your PC OS. You should always check the list of supported devices and OS versions for any toolset version you intend to install from any vendor. If you have a lot of code developed on older tools, then I'd recommend being very careful about migrating to newer versions unless you have a driving requirement to do so. Among the list of reasons is newer tool versions breaking code developed by older versions. All FPGA vendors do this on occasion. Another reason is that the free vendor IP that your old code depended on may well get changed significantly, or removed altogether. What might work for one person may be a big hassle for others. Questions to the Digilent Forums about Digilent demo projects would seem to prove my point. I haven't even thought about changing to the latest edition of Vivado for some time, but Vivado ML does support devices that previous versions don't, like the ZU7EV, which does require a license for the Vivado versions that I have installed. So, your point is well taken that keeping apprised of changes to supported devices might make the hassle of migrating to a newer tool version something to consider. Another thing to consider is whether the new tools break all of your old code... like Vivado 2019.2 did for me, and it's hard to know that until you install the new version. So, is the fact that the very latest Vivado ML ( I assume that this is what you get if you install the latest Vitis tools ) supports the ZCU106 device enough to make me want to install the new tools? I don't know. Do I want to abandon Vivado 2019.1 and the SDK and take a chance with the changes and bugs in the latest? It's been some time since installing a newer version of FPGA tools has been a "home run". For the most part, Vivado 2020.2 has been idle as I can generally work faster with the known bugs in Vivado 2019.1/SKD unless node-locked licenses are in the way. As of Vitis 2020.2 Xilinx still doesn't support this board with the software development tool directly. Deciding on which version of a vendor toolset you want to use isn't always a simple endeavor. I should have written that some devices and tool combinations require a node-locked license as that would be more accurate. Thanks for your post. But, you are over-simplifying a topic in your zeal to zing me on an admittedly poorly post.

Xilinx Document Navigator. Use it. It used to be a lot easier to find technical information and application notes from Altera and Xilinx but this tool installed with Vivado is the best way to browse what's available from Xilinx. Lately, I've found it difficult to even use DocNav as most of the time I have to be logged into my Xilinx user account to access information. For some reason DocNav on Centos has been crashing after downloading one document. The cookie wars between those monetizing the internet and those trying to protect user security seems to be getting out of hand these days. You can also find information about various industry standard busses from ARM. Digilent and other vendors like ADI have IP repositories in Github that include a some AXI HDL examples. @D@nhas some useful insights here: https://zipcpu.com/ If you are going to use ARM based FPGA devices effectively then you need to learn how the AXI or AMBA busses that connect the ARM cores to the logic work. Not everyone owning a ZYNQ based platform posting to the Digilent Forums want to be bothered, or has the time, or has the skill needed to design interfaces to these busses. That's the only reason why I'd suggest using alternate means. A good place to start would be UG761_axi_reference_guide.pdf available from DocNav. Beware that there are subtleties about the use of AXI for ARM based FPGA devices that aren't immediately obvious. Debugging ZYNQ software that encounters AXI buss faults as a result of poor or incomplete AXI-logic interfaces is difficult. Since ZYNQ devices use ARM cores I'd suggest referring to the ARM documentation. I've written AXI IP but don't use it enough to consider myself an expert. Even Xilinx has issues with it according to a few sources.

@asmi I'm quite OK with you keeping me honest... you seem so enjoy it so much; even when you don't catch a misstatement at least others get as alternate view. Don't stop doing it. Many perspectives are better than one. Always. And, of course I'm not immune from making incorrect statements. But, at least take me to task with things that I've written. I wrote that Vivado doesn't create testbenches for users' designs, not that users' can write testbenches. Personally, I've never seen a testbench provided for a board design, but that doesn't mean that no one does it. The GUI drag and drop design flows offered by Intel and Xilinx just don't promote good practices in my opinion, and because it's compelling I see it as a trap for inexperienced users. I've worked for lot of companies as a contractor or employee and never came across any source code that created a board design, or any project involving one. As to the professional comment; that was poor choice of words on my part. I never said that you couldn't add multiple testbenches to Vivado. I personally don't find that Vivado makes it easy to support design and verification the way that I prefer to do it. That's why I still use the free version of ModeSim provided with Quartus for logic designs that don't have vendor specific primitives, regardless of the tool or device that I'm using. Not that ModelSim doesn't have it's issues. But ModelSim doesn't crash and burn the way that Vivado has done for me on quite a few occasions and isn't buggy. But if anyone is happy with what they are doing, I'm happy for them. Nonetheless, I still encourage those starting out with FPGA development to stick with the HDL design and verification flow.

What kinds of projects are you expecting to do with your FPGA platform purchase? Transceivers and user programmable Vccio bank voltages tend to be expensive options; as do high performance IO connectors. Trying to find the "one board for all purposes" platform is hard. UltraScale devices usually require at least a node-locked device license that will limit your ability to migrate to new tool versions. Also, UltraScale devices are not the same as Series 7 devices in terms of advances IO features.

I'm using Win10 Pro, but I don't see a reason why you can't install the tools on the Home edition. You can find all of the necessary install requirements and information concerning the tools in the same place where you download them. Be prepared for some pain as Vitis plus Vivado install files are HUGE. Spartan 7 is supported for free, as are all of the Artix7 devices.

Well, in that case you need to start looking at the hardware. Since your PHY only supports 10/100 Mbps you have a chance. You have a few things to look at: Broken cables Broken magnetics in the RJ45 connector Broken PHY Broken FPGA The 1 GbE Ethernet PHYs on Digilent boards always come up out of hardware reset in auto-negotiation mode. So, I can power up two boards, connect a cable between the RJ45 connectors and see that this had taken place via the LED indicators. I don't know how the PHY on your board is set up to work post power-on. PHYs that I've used have automatic crossover capability, so you never need a crossover cable. Ethernet has the same problem that RS-232 has... uni-directional signalling connected to the same connector pins; Ethernet just addresses the solution differently. I make use of the Ethernet PHYs on many FPGA platforms all the time. I use some really old boards and have only had an issue once, with the Zedboard Ethernet. The physical layer of Ethernet is pretty robust and I am not aware of any common issues with it failing. I've never had one fail on a PC. An unlikely situation is that your FPGA is damaged, but still somewhat functional. Are all of the other pins on the IO bank that connect the PHY to the FPGA still functioning normally? Personally, I wouldn't rely on FLASH configuration as a test of the bitstream, as that's just one more potential problem; I'd configure via JTAG using the old, known good, bitstream. Debugging is easier when you reduce the number of variables to the minimum and take advantage of known good vectors that are available. Have you inspected the RJ45 connector for physical damage?

Well, the first line of my reply was a direct answer to your question. Perhaps you failed to notice that, while I mentioned that you could use the drag and drop board design flow, I gave some pretty strong hints that perhaps you shouldn't. Except for ZYNQ designs that include a ZYNQ subsystem block, I've never used the board design flow. My answer is based on vendor demo projects that I've seen that proves my point that it's possible, sans processor. That doesn't mean that AXI is never involved. There are, as I've mentioned IP that, if put into a board design, will force you to use and AXI interface. In this case you will be trusting the tools to work out all of the AXI details for you. There's a wide range of board design IP blocks available that cover a lot of logic structures that could be done in HDL text format. A large number doesn't mean sufficient to do anything that you want to do. When you say, FPGA logic, what exactly are you thinking about? If it's in the IP catalog, then, with some effort, you can build a board design without writing one HDL source file. I can't think of anything that I'd want to do that way. Whether you use the board file design flow or the HDL design flow you still have to assign pin constraints, like location, IOSTANDARD, and such. If your project setting specifies a device, then you will have to make your own constraint file. If your project setting specifies a board, then the tools will take care of at least the pin locations for you, as well as default IOSTANDARD (most of the time). If you want a different IOSTANDARD or want to set slew, or output current, then you'll have to use the tools to do that. I much prefer writing HDL source code and constraints myself. I can control these and keep track of them as I see fit. But, my way isn't the only way to do things. If you have some logic that is in a Verilog or VHDL source file and you want to connect the board design to your HDL, this is possible too. In fact, all of my ZYNQ designs are done this way. The board design has the ZYNQ subsystem block and any AXI IP that I don't want to write for myself. I have Vivado create a wrapper, that I instantiate into my own toplevel source file, or use as a template to instantiate the board_design.v that is created when you generate the board design. All of the signals that go to pins are made external in the board design. The HDL toplevel then has these on the entity port. My constraints file then includes all of the pin and timing constraints. The board design then is just one of many source files in the overall design. I should mention that any ports on a IPI block that you can connect a wire to can be made external and connected to your own HDL code. While I can give you a correct answer to your question, I can't offer assistance or a tutorial on a design flow that I never use, or strongly discourage. Perhaps, you'll get replies to your question from someone who loves the board design approach for real world projects. Like training wheels on a bicycle, there's a time when they are helpful, then there's the rest of the time where they just interfere with letting you do what you want to do on your bike. I get the attraction of GUI drag and drop design. I also get the limitations and frustrations, especially when you want to implement an old design in newer tools and something goes wrong. There's a larger issue with the board design. Vivado can't write testbenches for custom designs. In my world every source file has it's own testbench. Vivado just isn't designed to accomodate professional FPGA development in terms of simulation.

Yes. Yes, for ZYNQ devices as well. No hard processor, no soft processor necessary. As your designs get more complicated you will find it a lot easier to ditch the "training wheels" and just create all HDL designs. There are other reasons to ditch the board design flow too. To name one, some Xilinx IP instantiated in the board design flow has fewer options and design choices than when they are created as standalone HDL IP cores. I could go on but you should do what is comfortable... until it's not. Just saying, there's a great big world out there outside the garden walls.... Inside the enclosure, Xilinx takes care of the details for you... up to a point, anyway. Outside the garden you are responsible for the details. More works means more control over what you want to accomplish. For anyone thinking that the HDL design is too hard, consider that the a lot of the free IP ends up as HDL source code that you can read and learn from.

Xilinx Replaced the long-lived SDK, starting with Vivado 2019.2, with Vitis. You can download and use Vitis and Vivado for free from Xiinx, though not all devices are supported for free. Vitis includes most of the old software development tools, but Vivado still creates the HW bitstream.

Sorry, I totally misread your question. In this case you will need to create a board design with the ZYNQ processor subsystem and add AXI IP connecting the PL to the PS. You have a few options using Xilinx AXI IP. The simplest would be AXI GPIO. This might work for small amounts of data. There are a number of master and slave AXI busses in the PS that connect to slave or master AXI controllers implemented in the PL. For lots of high speed data you can DMA streaming data directly into/out of the PS DDR. It's also possible to use and AXI BRAM controller and BRAM in your PL to pass data using the native ARM DMA controller. Again, you have a number of options with free Xilinx IP. It all depends on how much data and what the data rate is when selecting the best IP. The best way to connect the PL to the PS would be to write you own AXI master or slave controllers. AXI stream controller IP have the easiest HDL interfaces, though the AXI bus protocol can be complicated to use properly. If you know how to implement a UART in VHDL, then an almost trivial option would be to connect one of the unused PS UARTs to the PL through the EMIO. With a little effort you can then just write PS software to read write registers in your PL HDL design. The UART is good for ASCII encoded data transfer; though it's possible that when transferring data between the PS and PL you can do binary mode. 921600 baud would work fine. For that matter, it's quite possible to connect one of the PS Ethernet MACs to your PL via the GMII interface. This approach would require some knowledge about Ethernet packet structures; though it is possible to transfer data between logic and a processor without using any standard packet type. [edit] When you connect PS functional blocks to the EMIO instead of PS pins there is no AXI bus to contend with. Use the Vivado IP catalog to see what's available for your device and then get the IP reference manual for it from Xilinx DocNav installed with Vivado. I don't do a lot of ZYNQ designs but have implemented all of the possibilities mentioned in this post.

I have some questions in order to understand what exactly it is that you intend to do: What Ethernet PHY are you using? Are you connecting the PHY to a PS MAC through the EMIO? What kind of Ethernet speed do you expect to use? The Cora Z7 has limited options for IO connecting an IO to the FPGA. Writing VHDL and implementing it on a board are not equivalent things. It's not possible to provide a good answer to your question without knowing more details.

There's no question that Xilinx ( and other vendors have changed their Ethernet related IP of for logic designs... and not in a way that users would prefer. One likely issue is licensing of the Temac core. You can get a free, limited time, evaluation license for free, but once it expires you may not be able to build designs without getting a new license. I have no idea if Xiinx allow you to perpetually obtain free evaluation licenses for the same core. This is one reason to avoid free stuff. It's not likely that your Ethernet PHY has gone bad... though the one on my Zedboard ( a PS connected interface ) hasn't been working for some time. There's no license for PS peripherals. I haven't had the time to resolve this issue but suspect the RJ45 connector. I don't have a suspicion as to why this would fail. There are some obvious tests to perform here. The first one would be to use an old bitstream that was know to work. If the Ethernet interface sill doesn't work then perhaps the PHY or magnetics in the RJ45 connector is worth looking into. In the old days, Altera used to have time limited evaluation for some of its IP. But that scheme actually had a timer buried in the logic that required a JTAG connection to operate and would stop after n minutes. Xilinx has never had such a thing to my knowledge. Regardless, it's hard to imagine that there would be logic that magically knows the date in order to terminate an evaluation session.. especially after reconfiguration and over many power cycles. Another thing to check are the Vivado messages related to your Ethernet block.

I really should get around to posting the DDR3 performance for the Opal Kelly XEM7320. It as 3 SYZYGY ports but no UART so a port will be a bit more work than I can afford at the moment.. We can come up with a pretty good estimate for maximum real work data rates for the XEM7320 though: 400 MHz DDR4 PHY clock * 4 byte DQ interface * 90% of peak = 400*4*2*0.9 = 2.88 billion bytes/s. This is certainly more than sufficient to capture 4 ADC1410 ZMOD channels which happens to be something that I've done, at a lower data rate.

With the exception of TMDS_33 there are no differential IOSTANDARD possibilities for any of Digilent's so called high speed differential PMODs. Please refer to ug471_7Series_SelectIO for information about Series7 IO capabilities. Digilent needs to revise it's advertising and nomenclature to avoid confusion. Digilent does make boards with an FMC connector or SYZYGY ports that have a user selectable Vadj.

I don't see anything wrong with what you've presented, in terms of using the IOSTANDARD. You are correct that TMDS_33 is the only available differential signalling for your board. You might try starting off with an SDR output instead of a DDR output first. Your ODDR primitive should be a clock and dc balanced but perhaps isn't the best choice. Anyway, try connecting whatever is driving the _p side of the differential obuf with a single-ended obuf driving a different pin on the same PMOD as a sanity check. It's a good idea to understand what TMDS is. It might be interesting to use a shift register that repeats a word as your data source.

In Verilog you can use localparam like this: 'ifdef FPGA localparam MAX_MEMORY = 1024; 'else localparam MAX_MEMORY = 2048; 'endif It's so easy to confuse Verilog syntax with C syntax.. for me at least.

To complete the board test results for the boards that I have access to here's something that might be of interest. There aren't too many ZYNQ based boards with external memory connected to the PL. The ZCU106 happens to be one. For some reason Xilinx has decided not to support it with recent versions of its tools.... the ZCU106 4:1 controller with an 1200 MHz PHY clock and 64-bit DQ bus has a ui_clk of 300 Mhz with 512-bit data 013B5577 = 20665719 --> wtimer --> 0.06888573 seconds 01000000 = 16777216 --> wcount --> 1073741824 bytes --> 15,587,289,617 bytes/s to write 1 GB 011087E7 = 17860583 --> rtimer --> 0.05953528 seconds 01000000 = 16777216 --> rcount --> 1073741824 bytes --> 18,035,387,152 bytes/s to read 1 GB 00000000 = 0 --> errors It's almost astonishing, to me at least, that the test runs at 300 MHz on hardware; but there it is. Again, you get an average data rate of about 90-94% of the 19200 million bytes/s peak. The UltraScale+ uses the DDR4 SDRAM MIG 2.2 in Vivado 2019.1. pg150-ultrascale-memory-ip now covers this version. There's no flexibility in the IP design due, in part to the extreme clocking and timing specifications for the DDR4 memory. The MIG constraints files now abstracts pin constraints by using BOARD_PIN instead an actual pin number, and doesn't define any of the other pin constraints so that it's very difficult to find, or more importantly manage, the source code. This is the way that Xilinx is moving; less control for you over your projects and source maintenance, and more obfuscation of the details. Like it or not, you get a MicroBlaze embedded in your design to accomplish the calibration. The only good news is that the Hardware Manager can find and report the calibration status and results. If, for some reason it can't find the embedded processor, then you can't download code or run any application on the UltraScale+ processor(s)... and yes, I managed to do that briefly. But who can argue with 16 GB/s of data storage bandwidth? The DDR4 core is a very complex IP and good luck to anyone having to debug it for a custom board. I had to restart the project a few times. If you start with a board design and include the DDR4 block you HAVE to connect an AXI interface to the memory. Who want's to do that? The whole purpose of having the PL get access to external memory is for your HDL design to use it. But you can create a basic board design with just the ZYNQ and then create the DDR4 core as general purpose IP. Then your code can instantiate the ZYNQ and MIG core with the UI and run the design without doing any SW design of any kind.