Honored ContributorHi
I have a design that has to be supported on two issues of PCB. One has a Cyclone3 in a 144 pin package, the other has a Cyclone3 in a 240 pin package. Ultimately all of the PCB's will be the same, however, at this stage I need to support both. Is there an easy way of doing this without having two separate Quartus projects? Regards Ian.
Honored ContributorRegardless of whether it's the same density or migration-compatible, you could just put together a TCL script to run, or come up with different revisions of the same project (and use the pull-down at the top of the screen to select which one to build before compiling). This would allow you to use common VHDL/Verilog source files for both projects, and then build which one you want.
There is a QPF file for an entire project, and then individual QSF files for each revision in that project. For argument's sake, say you have two revisions of your project: myproject_144 myproject_240 The myproject_144.qsf file would contain all of the specific build information (pinout, device, etc.) for the 144-pin Cyclone. Then, myproject_240.qsf would contain all of the same info that targets the 240-pin Cyclone. If you create the revision when all of the source files (VHD, etc.) up-to-date, they will both share all of the common source. You just need to make sure that if you add common source files down the road, you add them to both revisions (one at a time). To build, you just select your revision from the pull-down menu at the top of the Quartus window (select myproject_144 or myproject_240), and then hit the compile button, and you will have the proper build. To automate the building of both (run it and then let it go), you could paste this info into the TCL script window (or put it in it's own TCL script): load_package flow project_open -revision myproject_144 myproject_top execute_flow -compile project_close project_open -revision myproject_240 myproject_top execute_flow -compile project_close Assuming your top-level project is called "myproject_top", this set of commands will sequentially build the two projects. By necessity, I have 7 flavors of my current project (that each take ~20 minutes to build), so I can kick off a build and come back a few hours later to 7 .SOF files. Hope this helps.Honored ContributorIf you need to support the old PCB production for a temporary period (until you definitely shift to the new one) you may keep the old pof (or any other programming file) file for your production and simply use the same project with new pin assignments to produce the new configuration file.
Does this sound good to you?Honored ContributorDid you check whether the Quartus device migration feature will let you select both packages at the same time? If you use that feature, Quartus will compile using a pin-out that works in both packages.
Honored ContributorKeeping the old pof would be an option but there are still updates being made to the project which I'd like to get on both revisions on board.
My current procedure is to make changes on my development hardware (the new issue of board) that uses the 240 pin device, then make a copy of the project, change the device, assign pins and recompile. This all seems a bit tedious and I wondered if there was an easier way. Ian.Honored ContributorHonored ContributorI was backward on the device migration suggestion. That feature is for more than one density in the same package, not more than one package of the same density. Support for automated migration between different packages was I think called "SameFrame" for APEX families. Newer families don't support it.
Honored ContributorPin assignments can be changed quickly by sourcing a tcl script. So if you get your project set up for device A, then close the project and open the .qsf file and just grab the set_location_assignment lines and save that to a file called pins_for_A.tcl for instance. Then do the same for device B. Then, right before you compile, just open a tcl console (alt+2) and type : source pins_for_A.tcl and then hit compile. If you wanted to get really fancy you could customize your toolbar with a tcl command button that sourced the file for the device you wanted to compile for.
Honored ContributorHi
Thanks for the suggestions. I'll try to do something with TCL as suggested. Cheers Ian.
