Pure HDL Xilinx Zynq Arm Instantiation

[peter dudley]

Hello All,

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 then produce a great deal of machine generated code.

I am wondering if it is possible to use a more conventional approach to building 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 strait HDL development easier to maintain in the long run and less sensitive to changes in FPGA compiler tools.

Has anyone on this group succeeded in going around the PlanAhead/XPS graphical flow for building systems for the Zynq ARM?

Any advice or opinions are appreciated.

Pete

 

[Allan Herriman]

On Mon, 24 Jun 2013 03:03:15 -0700, peter dudley wrote:

Hello All,

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 then produce a great deal of machine generated code.

I am wondering if it is possible to use a more conventional approach to
building 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 strait HDL development easier to maintain in the long run and less
sensitive to changes in FPGA compiler tools.

Has anyone on this group succeeded in going around the PlanAhead/XPS
graphical flow for building systems for the Zynq ARM?

Any advice or opinions are appreciated.

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)
- Xilinx PlanAhead Tcl Command Reference Guide (UG789)

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, fo 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.


Regards,
Allan

 

[Guy Eschemann]

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 Xilinx Platform Studio (XPS), and use the generated HDL code as a starting point.

Guy Eschemann
Ingenieurbüro ESCHEMANN
Am Sandfeld 17a
76149 Karlsruhe, Germany

Tel.: +49 (0) 721 170 293 89
Fax: +49 (0) 721 170 293 89 - 9
Guy.Eschemann@gmail.com
Follow me on Twitter: @geschema
http://noasic.com
NEW: http://fpga-exchange.com
http://fpga-news.de

 

On Monday, June 24, 2013 3:03:15 AM UTC-7, peter dudley wrote:

Hello All,
I am wondering if it is possible to use a more conventional approach to building 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 strait HDL development easier to maintain in the long run and less sensitive to changes in FPGA compiler tools.
Has anyone on this group succeeded in going around the PlanAhead/XPS graphical flow for building systems for the Zynq ARM?

It is definitely possible but not trivial. What you need is the NGC file and 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. Then you can instantiate the model (which has no content) and make connections to the +3300 nets. During implementation point to the ngc file and you are done.

 

[Mark Curry]

In article <3a29b759-dd7a-4b12-9f7c-83608402c247@googlegroups.com>,
peter dudley <padudle@gmail.com> wrote:

Hello All,

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 then produce a great deal of machine generated code.

I am wondering if it is possible to use a more conventional approach
to building 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 strait HDL development easier to maintain in the
long run and less sensitive to changes in FPGA compiler tools.

Has anyone on this group succeeded in going around the PlanAhead/XPS
graphical flow for building systems for the Zynq ARM?

Any advice or opinions are appreciated.

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.

Ok - got a little <ranty> there... I'm done.

--Mark

 

[peter dudley]

Thanks to all you guys for understanding what I am trying to do and why.

The consensus is that it is difficult but possible.

I think it is worth a try.

 

[Philip Herzog]

On 02.07.2013 17:41, peter dudley wrote:

The consensus is that it is difficult but possible.
I think it is worth a try.

Please, let us know about your experience.

- Philip
--
If your photographs aren't good enough, you aren't
close enough. (Robert Capa)