Lots more information to follow

John - thanks for reviewing this - and my premature publishing of the confusing hierarchy:

• https://soclabs.org/design-flow/fpga-prototyping ideally will become the generic Design Flow overview
• https://soclabs.org/design-flow/fpga-soc-prototyping-xilinxr-pynqr-platform is a project specific example

So in some ways the second is a project that refers (to and from) the Cortex-M0 reference design project and could potentially be linked to form the first as a design-flow example.

Guidance on how to repair hierarchy would be valuable: I could only think of copying to new area and then deleting the original(?)

Thank you so much Meredith for the detailed review feedback.

I have checked back into git the 'set_property top' fixes identified, but have struggled and failed to get to the bottom of the 'locked' IP issue you reported (which I fail to reproduce in my environment for some reason). I build up the TCL commands from running the IP packaging from the command line and despite spending a fair time digging through the Xilinx documentation have failed to find a clean alternative version. [Would you mind emailing me the journal-transcript when you next run the IPX packaging just in case this is different to what my environment gives?]

Very best wishes and do hope your FPGA prototype is making good progress

  --David

It looks as if the AAA Cortex-M0 deliverables were updated in the Southampton site and the paths do need to be repaired in tbench_M0.vc as you suspected.

I have had a quick look at the installation and it appears as if :

  .../aaa-ARM-ip/Cortex-M0/AT510-BU-00000-r0p0-03rel3/

may now be referenced using the updated "version independent" path

  .../aaa-ARM-ip/latest/Cortex-M0/

similarly the Corstone-101 IP:

  ...aaa-ARM-ip/Corstone-101_Foundation_IP/BP210-BU-00000-r1p1-00rel0/

to

  .../aaa-ARM-ip/latest/Corstone-101/

and the PL230 micro-DMA:

  .../aaa-ARM-ip/DMA-230_MicroDMA_Controller/PL230-BU-00000-r0p0-02rel2/shared/

to

  .../aaa-ARM-ip/latest/DMA-230/

I do hope this works for you - and the explicit relative path issues, inherited from Arm CMSDK are addressed by setting clean environment variables in the nanosoc deliverables

Sorry this is not straightforward. I have checked in the new preferred "/latest/" link paths into the repository so these should be ready when you have Southampton server access.

In the meantime, would you be happy to add a few more symbolic links to your installation of AAA IP bundles under the "arm-AAA-ip" directory you have built? If you create a directory at the top level named "latest" and then in that directory build symbolic links that match the new preferred pathnames then I think you should be able to make progress.

for example for Cortex-M0 CPU, but similarly for Corstone-101 and DMA230...

  in arm-AAA-ip/latest/ directory, create a soft-link something like :

     ln -s ../Cortex-M0/AT510-r0p0-03rel2/AT510-BU-50000-r0p0-03rel2    Cortex-M0

(or similar - such that ls -al shows your "latest/Cortex-M0" now points to the directory in the Arm IP that includes the logical verilog IP directory. And confirm this by listing what is visible at arm-AAA-ip/latest/Cortex-M0/logical/ )

This should then remove exact bundle part numbers and be ready for full server access when you can switch your link to the  managed AAA IP repository 

Following up the comments from John D, I suggest there are three distinct phases for this project:

1. HLS synthesis and validation and benchmarking in (Zynq) FPGA which has ample Processor and DDR Memory resources
2. Partitioning analysis for accelerator, bulk memory and control processing - both for bandwidth and area
3. Feasibility study for PCIe (hardware and driver stack), DDR memory and on-chip memory/processing (which would likely require specialized PHY and advanced semiconductor technology)

The project proposal as it stands I think would be very hard to fully complete successfully within a limited time (and budget) if the assumption is simply to map the transformer and memory system architecture to a 65nm process technology(?)