Approach to changing IO assignments in Qsys with script

[RayHaynes1]

I have a design where I need to change some pin assignments in Qsys between builds (an operational build and a backup build). Looking to fully automate the building of both designs. I have a working makefile that builds the design but requires manually changing IO assignments in Qsys. All I'm looking for is some guidance on how to approach this. I could keep 2 copies of qsys files and in I think in make I change the which qsys file I'm using but that's makes too qsys designs to support. 

My gut says I would make sense to partition off the IOs that are changing into two different TCL scripts and then some how run make twice with each of the scripts included. This way there is only one base design and the additional TCL scripts create the different variations. 

I guess begs a little bigger question, would it be better to run make from a bash script or run bash commands from within make?  

Before I spend a bunch of time trying different approaches I was hoping someone more expert than myself (that would be most people) might shed a little light on the pluses/minuses to the different ways of doing this. Sorry if this is a bit vague but I just need to be pointed in a direction that makes sense.

Thanks

Ray 

[sstrell]

I/O assignments are not stored in the Platform Designer file (.qsys).  They are stored in the project settings file (.qsf) which is basically a Tcl script.

You could do complicated scripting to switch things, but it would be much easier to use the revisions feature of Quartus.  Each revision of a Quartus project creates a new .qsf file that can start by being based off the original.  You can make a new revision and edit the I/O assignments in the new revision.  You can then simply switch back to the original revision when needed, either in the GUI or through scripting.

All this is in Project menu -> Revisions.

[RayHaynes1]

The part I want to change is stored in .qsys file

<parameter name="LOANIO_Enable">No,No,No,No,No,No,No,No,No,No,No,No,No,Yes,No,Yes,No,Yes,Yes,No,Yes,No,No,Yes,No,Yes,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,Yes,No,Yes,No,No,No,No,No,Yes,No,Yes,No,No,No,Yes,Yes,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No,No</parameter>

My goal is to script the whole dual build so it's a simple matter to build after code changes. I'll look into the revision thing. Thanks for the info.

[sstrell]

OK you didn't mention that this was loaner I/O for the HPS and you don't mention which device this is.  Loaner I/O are fixed pins from the HPS that the FPGA has access to as GPIO.  The use of those pins is governed by the first-stage bootloader for the processor, which is created based on the parameter settings for the HPS in Platform Designer.

Are you saying you want to keep using the same physical pins and connect different signals to them or you want to use completely different pins for different revisions?  The revisions thing may work but if you need to change which physical pins should be used as loaner I/O, you have to change the HPS parameters, regenerate the Platform Designer system, and recreate the bootloader.

Not sure why you need to switch between two setups this often.  I'd just create two projects since this is essentially two different boards you are designing for.

[RayHaynes1]

Sorry for my lack of detail. This is for a CycloneV part and for a single board design.

We are supporting have 2 slightly different product variations each product version requires dual boot with a different loaner I/O configuration. Once changes are make to the common code base we need a simple way to build the 2 systems each with dual boot. Up to now we have been running through the GUI to make all of the changes for the 4 different builds (**bleep** load of steps including building and incorporating the HPS boot code into the image).

I was tasked with creating some kind of script to automate the build of the 2 systems (each with 2 images). This is my first dealing with Altera (besides the Max Plus stuff +30 years ago) so it's been a steep learning curve. I have managed to cobble together a bash build script that swaps out 2 different .qsys files which set the loaner IOs and 4 different verilog include files to set the IOs and system type. A bit of a brute force but it fits the requirement of minimum divergence of the main code base for the different systems. 

Thanks for responding to my post. There is still much for me to learn.

Ray  

[sstrell]

If you have multiple complete system designs (.qsys files), then you can use the revisions feature.  Just set which .qsys to use for each revision.  Revisions work with anything that can be changed in the .qsf file.  That includes which files make up the project.

[RayHaynes1]

I guess my question would be how would I change the revision setting with a bash script? Currently running Quartus 16 and I trying to bring the design forward but many issues with the bootloader and other things. And I'm not currently running any TCL (haven't figured out how to mix bash scripting and TCL yet) so I think I'm ok with my current approach as kludgy as it is for now. Lots of other stuff to do.

But thanks again for responding. Just a small rant. I have been working with FPGA for decades now and they are the worse environment to do design in. I need to know bash, TCL, c, and others that escape me right now, all outside of the HDL which is the real meat of the project and I think my approach is cobbled together? The whole FPGA build environment is far worse. rant over.

Ray     

[sstrell]

I don't know much about scripting, but the Quartus scripting guide is here:

https://www.intel.com/content/www/us/en/docs/programmable/683432/23-4/faq.html

And revision commands are here:

https://www.intel.com/content/www/us/en/docs/programmable/683463/23-4/project-revision-commands.html

[SyafieqS]

Let me know if there is any update from previous reply

[RayHaynes1 · Accepted solution]

Just to close this item out here is what I ended up doing, best way? probably not.

I decided against using the revision feature because we use git version control using it would complicate things. If we didn't use git I would have definitely looked into using it.

So what I ended up with is a bash script that copies each of the uniquely named .qsys files to the soc_system.qsys file and runs a makefile which builds the fpga. Only the uniquely named .qsys files are checked into git, the soc_system.qsys is not. If the I/O ever needs to be modified the working pair of uniquely named .qsys files will need to be updated manually but that is very rare in our system (we are in production support mode).

Thanks for the different ideas.