system_stub.v confusion

[AndyC]

Hi Guys,

I am a bit confused about system_stub.v in the projects.

For the headless 7020 the system_stub.v begin used is :

C:/Development/parallella/fpga/AC-parallella-hw/fpga/projects/parallella_7020_headless/parallella_7020_headless.srcs/sources_1/imports/parallella_7020_headless

Now say I change something in XPS that changes the system.v file, the system_stub.v file in .../edk/parallella_7020_headless/ is being updated correctly, but this /sources_1/imports/parallella_7020_headless one is never being updated.

Why is the project set up like this?

Cheers

Andy

[yanidubin]

I'm not sure how the import mechanism works (in particular when it triggers a copy) - but I suspect possibly only when you create the project? For instance, if you use planAhead to Save Project As, and select to import all sources, you'll end up with many items in the imports folder.

So for consistency, since you are using a reference into the EDK for the remainder of the system files, your project should be referencing the system_stub.v (which as you say is updated correctly). I cannot explain why it has been set up like this, and I think there is room for improvement (you may have seen my related gripes ).

I think there are two ways to deal with it - one is the above, remove the file in imports, and refer to the original in the EDK folder. This way you get the changes. I think this approach works until you want to create a second project and not have to re-fork or use a git branch per project (that way lies madness!). The issue of course is that you simply can't have different projects needing different PS configs pointing to the same PS files.

My favored option (which I've been using for several personal projects) is to to move all the system stuff (including system_stub.v) into the project sources folder. Each project refers to its own copy, and the project can be cloned using planAhead to nicely handle divergent ideas / explorations. Because there is no way for multiple Processing System setups to interfere with each other - but you can still share cores (you couldn't if use used fork/branch hackery) between projects.

Note - I realised I forgot to mention system_stub.v in my gripe/Tutorial0. So far it hasn't bothered me because I haven't messed with system_stub.v yet. But since my Porcupine has now also arrived...

[AndyC]

Hi Yani,

Thanks for the reply.

There is another issue, the system_stub.v generated by XPS also has a "module system(...)" section.

If you try to synthesise using the generated file you get:

[HDLCompiler 687] Illegal redeclaration of module <system>.

This is because this section is already in "system.v"

So I have to cut this section out of system_stub.v each time!

The whole thing confuses the hell out of me!

[yanidubin]

Ah, okay - sorry about that, I should have checked first. I can confirm that the system_stub.v I use in planAhead is not the one from the system/hdl folder - the difference being the system module. So they have always been different.

I'm out of my depth here too. In the next weeks I expect I'll be tackling the same issue to remap peripherals.

There has always been a disconnect with the XPS/planAhead for me - there is some level of of overlap (both can generate a bistream - I think I've seen ZedBoard tutorials that generate the bitstream right up from a blank XPS project and don't even use planAhead), and yet the workflow I use involves a bit of both - I expect there are other ways to drive the tools, but I'm not enough of an expert to know how well that will work given the setup of the parallella-hw projects.

What I would suggest is that if altering aspects of the system causes the interface there to change (because you want to remap EMIO and such), I would try manually applying the delta to the system_stub which planAhead uses. Or, if it is easier, and the only difference is the system module, take a copy and remove that.

This way, you are still updating the routing to the actual pins (from the PS design), and should expect planAhead to generate a bitstream which connects what you've configured in the XPS up to the pins. That makes a certain sort of sense to me anway - but take it with a grain of salt. Failing that, I think we need an expert.

[AndyC]

Yeah that is basically what I do, cut/paste the generated system_stub into the referenced file.

All I know is that I am glad I don't have to use these Xilinx tools for a living!

A case in point, I tried speeding up plan ahead by enabling multi processor, one part can use 2 cores and another 4 cores. It sped it up the build by around 10% but the bitstream was always corrupt!

Quality software.

[yanidubin]

As an aside - I thought I'd share something on the topic of imports I realised tonight. Might be you already knew of it.

You may recall I endorsed copying files into the project manually, then editing fileset.xml by hand to refer to them in situ. This is because I didn't know you can right click on a resource to copy it into your project. Very useful if using planAhead, since as soon as you start mapping peripherals, there's a bunch more files you should import (so as not to impact other projects). In the case of the system stuff, it touches these behind the scenes. But with verilog modules / constraints, you know what you're about to edit, so can easily import it beforehand.

Since it remembers where a file was copied from, you can right click and Replace File at any time, and it'll grab a fresh copy of the original. So if you did have a scenario with the original file being updated after you'd imported it, then this would make grabbing a fresh copy (while manual), a bit easier.

As we discussed, I don't think this is your problem. There are two different files called system_stub.v. One in fpga/projects/parallella_7020_headless, and one in fpga/edk/parallella_7020_headless. However you could consider using this as an easy way to grab a copy of the edk version each time - if all you are doing is removing the system module which causes the conflict. Import and delete module.

[AndyC]

Hi Yani,

No I didn't know you could do that. Very useful tip thanks.

I Really need to take a look at the PlanAhead manual!

Cheers

Andy