I have a Xilinx Zynq development board and I am starting to teach myself to build systems for Zynq. The recommended flow described in UG873 is a very long sequence of graphical menu clicks, pull-downs and forms. The tools t hen produce a great deal of machine generated code.
I am wondering if it is possible to use a more conventional approach to bui lding hardware and connecting it to the AXI bus of the ARM processor. I gr eatly prefer to directly instantiate components in my HDL code. I find str ait HDL development easier to maintain in the long run and less sensitive t o changes in FPGA compiler tools.
Has anyone on this group succeeded in going around the PlanAhead/XPS graphi cal flow for building systems for the Zynq ARM?
I've seen people do just that, but it's a very tedious and error-prone task . If I had to do it myself, I would first generate a known-good system in X ilinx Platform Studio (XPS), and use the generated HDL code as a starting p oint.
Guy Eschemann Ingenieurbüro ESCHEMANN Am Sandfeld 17a
Best advice I can give is just to accept that the tools were written to make it difficult to do what you want to do. Try not to get upset at them - it is counterproductive.
I've done it though - GUI-free Zynq scripting nirvana achieved.
The documention is poor; the only way to work out what to do is to run through the GUI and see what it does. That said, the following guides are indispensable:
- Xilinx Platform Specification Format Reference Manual (psf_rm.pdf)
A file & directory diff tool is useful for before/after comparisons. I use winmerge.
Planahead can be scripted in TCL without needing the GUI. It saves a journal file (.jou maybe?) that you can use as a starting point for your own script.
You will need to write your design in the form of an XPS peripheral and integrate it using XPS.
Again, run through the tools, creating a dummy peripheral template to see where it puts all the files.
Constraints:
- No inferred FPGA bidirectional I/O. Inputs ok, outputs ok. Inout not ok unless using instantiated iobuffers. Deal with this either by instantiating buffers or by having separate foo_I, foo_O and foo_T ports instead of a single "inout" foo port on your design. They must have those exact _I, _O and _T suffixes. (BTW, _T is an active low enable.) The tools will do the right thing and infer the buffers for you. N.B. Most Xilinx cores, e.g. from MIG will instantiate their I/O primitives, so aren't a problem here.
- Your "peripheral" must have a lower case name.
- The Zynq PS has an AXI-3 interface in silicon. You must make an AXI-4 or AXI-4-lite interface, and the tools will insert an AXI-3 to AXI-4 shim for you. I did not find a way around this (not that it's a problem).
- Not a hard constraint, but it makes things a lot easier: Use the official names for the AXI-4 signals, as the tools can recognise them.
- XPS wants the peripheral files buried about 7 levels of directory down. Your .pao file (see below) can point back up to your original source files (in a more reasonable location) but if running on Windows (yes, even 64 bit Windows) you will run into a hard limit of 260 character paths. Solution: use Linux, or copy all your source files down into the bowels of XPS's directory structure.
- You will need to keep the exact directory structure that the GUI tools create. The tools crash a lot if you change anything from the way the programmers at Xilinx tested it. This gets really hard to debug, as the error message is usually just "unexpected termination" or something equally unhelpful.
Important files:
- my_project.ppr - planahead project file, points to fileset.xml
- sources_1/fileset.xml - points to my_system.xmp
- my_system.xmp - project file, points to my_system.mhs.
- my_system.mhs - a sort of crude HDL definition of the connections between your core "my_peripheral", the AXI fabric, the ARM (curiously known as processing_system7) and the FPGA I/O. This is created by XPS, but you can edit it by hand.
- my_peripheral.mpd - port definitions of your core
- my_peripheral.pao - list of source files for your core.
I hope this helps, and let us know how you get on.
uilding hardware and connecting it to the AXI bus of the ARM processor. I greatly prefer to directly instantiate components in my HDL code. I find s trait HDL development easier to maintain in the long run and less sensitive to changes in FPGA compiler tools.
hical flow for building systems for the Zynq ARM?
It is definitely possible but not trivial. What you need is the NGC file an d the instantiation model for the zynq interface. This you can get from XPS . Create an empty project with only a zynq in it to get these two files. Th en you can instantiate the model (which has no content) and make connection s to the +3300 nets. During implementation point to the ngc file and you ar e done.
Similar question was just posted on the Xilinx forums - I'll say here what I did there:
We've done this for all of our designs in Xilinx involving a processor (PPC405, PPC440, microblaze) and expect to do the same in the future for ARM based designs.
Use a bare-miniumum XPS flow - often just using one of the Xilinx examples - something wih just small block RAM for boot, maybe a UART, and not much else.
Generate the netlist, and then never look back at XPS - all ISE and makefile (or Vivado and TCL ) from then on.. The original netlist is used as a reference and modified as needed.
Xilinx strongly discourages this flow. But it's worked great for us for many years.
It's nice to hear that others in this thread have the same frustrations, and have done similar things to workaround. I've never been sure if we were alone with our unhappiness of EDK/XPS/whatever they're calling it now. It's basically a BAD schematic capture tool - if it were easier to use it'd be state of the art for the mid 80s....
You're basically describing a netlist along with parameter (generic) settings. HDL is perfect for this, no need for MHS and other cruft. Add some assertions, and/or connectivity checks in ngdbuild or somewhere, and be done with it. No MHS, no PAO, no BMM, no XCO - stop inventing new / poorly defined languages / etc - when exiting standard solutions exists.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.