- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
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.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If 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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Keeping 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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Did 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. --- Quote End --- I wondered about that, I'll give it a try. Thanks Ian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Regardless 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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pin 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Thanks for the suggestions. I'll try to do something with TCL as suggested. Cheers Ian.- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page