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
Statistics: Posted by AndyC — Tue Sep 30, 2014 5:43 am
]]>
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.
Statistics: Posted by yanidubin — Sat Sep 27, 2014 11:58 am
]]>
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.
Statistics: Posted by AndyC — Fri Sep 26, 2014 10:15 am
]]>
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.
Statistics: Posted by yanidubin — Fri Sep 26, 2014 9:57 am
]]>
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!
Statistics: Posted by AndyC — Fri Sep 26, 2014 8:04 am
]]>
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...
Statistics: Posted by yanidubin — Fri Sep 26, 2014 7:22 am
]]>
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
Statistics: Posted by AndyC — Wed Sep 24, 2014 10:42 am
]]>