Parallella Community

Thanks Mutki - I wasn't aware of Project ARA, so thanks for mentioning that It would be cool indeed to have the likes of the Epiphany accessible from a smartphone.

Hi Yani,
Thank you very much for sharing the tutorial.
It is very helpful for me.
I tried to follow the "Create new project" tutorial, I've found a easy way to copy version.v and XPS settings.

PlanAhead > Project Manager Window > Design Sources > Global Include,

Right Click version.v, "Copy File Into Project",

parallella_z7_top > system_stub,

Right Click system_i, "Copy File Into Project".

The files are copied to project_name.srcs/sources_1/.

I could create a new project and generate a bitstream successfully.

Thanks Shodruk,

Glad it helped, and thanks for the feedback

I didn't know of the import method you described when I wrote Tutorial 0, and only discovered it as I was writing tutorial 3 - so I make use of it in that. I tried to go back and update this first one to use the same method, but found that when you import System (as opposed to plain Verilog files like version.v), it copies a whole bunch of extra files it simply doesn't need to - only three are required (xmp,mhs,xml). Take a look in your sources_1/imports folder immediately after using import if you want to see what I mean. But if you use the (manual) copy method once for your base project (or start from the output of the tutorial) you need not worry about this ever again - system is then already part of the project (where I think it should have been to start with), and you use the described method to import any Verilog file you are about to modify (covered in Tutorial 3).

So while there is nothing wrong with importing System using the import method (it will still build just fine), I prefer to keep my repository clean, with only the bare minimum of checked in files (no generated files), and copies minimal (hence only files being modified) to make managing merging with upstream changes (for example once we move from ISE to Vivado) simpler if few files are really being modified.

So there is a balance between sharing what I think should be common practice versus a simpler tutorial - and so I may yet change it / move it to an advanced section - because it may be I'm the only one pedantic about such things. However this tutorial was really all about settings things up "right" for repo cleanliness / removing inevitable conflicts (once you have a few projects on the go), and is already something of an "opinion piece", so it will remain as is for now.

Keep the feedback coming
Yani.

In case anyone is wondering why I haven't posted any further tutorials (or FuseSOC pgrogress) in the last week, is the reason. That is, I've been somewhat sidetracked with selecting/configuring my first hosting, and also cobbling together a lightweight blogging framework to serve up my current WordPress posts. This will make writing tutorials much simpler (especially now that it is mostly diffs rather than screenshots), and also allow me to some things with javascript I couldn't on free WordPress.

The site is not really live as such - but if anyone wants to take a look and give some feedback, please feel free. I expect some conversion failures still exist, but I'll smooth these out over time. Future posts will only be available on this site, and WP will receive only updates where I got things wrong. Now I can write everything comfortably in markdown, I don't wish to touch WP any further.

I expect within a few weeks I'll be closing comments on WP (but otherwise leaving stuff up for anyone who has bookmarked content ) and putting up an advisory that the latest version can be found on the new site.

P.S. You might have noticed a subtle name change. Parallellogram, while being a conjugation of Parallella (obvious) and Gram ("a thing drawn or written"), and also an obvious play on Parallelogram (the shape), I realised was going to look too much like a simple mis-spelling of Parallelogram (especially to anyone not acquainted with the Parallella). So I have gone for Parallellagram instead - which might improve on this slightly?

Thanks Yani,
I understand.
I look forward to your next article.

is now up - this provides instructions on creating/connecting an IP Core using the AXI4 interface to communicate with the ARM. This is more suited to a larger chunk of memory (BRAM), compared with the limited register set based approach seen last time with AXI4Lite.

Not particularly exciting in and of itself - but certainly if you have an idea of what you want to do with it, you have all you need there.

I realise I need to write up the sequels for Tutorials 1 and 2. I have taken these further, but put them down about 2 months back (I have been busy writing tutorials, migrating to a new hosting solution, and porting FuseSOC). For AXI4Lite, I threw together a (very) basic ALU. For AXI4, I implemented an image smoothing algorithm.

So I will revisit these projects, get them into a reasonable state, and make an instructional tutorial for each. With these will come python scripts for on-target testing, as that is what I use myself during development. Loading in pixels one at a time is for suckers

Beyond that, I might investigate / cover a better tool for loading arrays of data into/out of the FPGA / reading back. The tool I've appropriated to date is really not suited to the task. After that? Nothing planned as yet. Hopefully AXI4-Stream when I have it working - but haven't been looking into this for a good month or more.

Thanks for sharing you success story! A great example showing the power of openness and sharing.
Andreas