Absolute paths preventing project re-use

Use Tcl?

Project -> Generate Tcl File For Project

Generates a script that I think can be used directly to re-synthesize a project.

I generally write Tcl synthesis scripts from scatch, and use the above menu option to find out Tcl syntax for options (rather than looking them up in the scripting manual). This scheme allows you to use just the Quartus Tcl command-line to synthesize a project (it generates the .qpf, qsf, files etc). Its completely independent of Quartus version.

Given that you are sending him encrypted IP, I assume its not locked to your work machine.

What evaluation boards do you have? If I have the same one, I'll send you a simple example script and design files.

Cheers,

Dave

Thanks, Dave.

I'm not sure I understand what you're saying though.

Are you saying that using Tcl would resolve absolute path references that Quartus creates in the intermediate files?

The IP is not locked to my machine - we have a floating license.

Also, I did use Tcl to do the synthesis and place-and-route, and my colleague is trying to use the "quartus_asm ..." command to generate a programming file, and that's where the absolute path reference occurs.

--- Quote Start ---

I'm not sure I understand what you're saying though.

Are you saying that using Tcl would resolve absolute path references that Quartus creates in the intermediate files?

--- Quote End ---

Right. You use Tcl to re-create the project, hence there are no "Quartus files" that you transfer. You collaborator re-creates the identical project. Even if there are absolute paths, they are absolute on his machine.

Try the Create Tcl File for project option and see what happens :)

Cheers,

Dave

Ah, now I see what you're saying.

Problem is, he and I have separate roles and machines assigned - I do the synthesis and fit on mine, and he generates the programming file for testing. Probably not the most efficient of setups, but essentially it's not his role to re-create and re-run the project on his end.

Since I've already compiled the project, I thought it'll be easy to just pass it over to him for the rest of the testing. Seems like that's not the case.

I appreciate your pointers though - thanks!

--- Quote Start ---

Problem is, he and I have separate roles and machines assigned - I do the synthesis and fit on mine, and he generates the programming file for testing. Probably not the most efficient of setups, but essentially it's not his role to re-create and re-run the project on his end.

--- Quote End ---

Strange setup ... you've gone to all of the trouble to place-and-route, why not just generate the programing file?

What 're-creation' is he doing that verifies what you have not already done?

If your respective machines are powerful enough, you could both share a common Virtual Machine image; you use it to synthesize and then he uses it to verify.

Personally, I use Tcl scripts for synthesis and simulation, and check things into and out of CVS across multiple machines and virtual machines. Other than having a source location environment variable and a build location environment variable, everything is pretty much machine and tool version independent (the build folder is filled with quartus and modelsim directories based on the tool version number).

Cheers,

Dave

Appreciate your advice, Dave.

The reason why I don't/can't generate the programming file is that for some projects, I don't have all the IP licenses and my colleagues does. So getting synthesis and fit done is as far as I can go.

In an ideal setup, I would definitely want to do everything on my machine before passing the design over to him and his team. Will definitely think about how to streamline this process. Your setup definitely sounds a lot more optimized for Quartus.

The /incremental_db directory stores post-fit information and is common to all designs(meaning you have no choice but to store them there). Please file an SR, as the archive should be pointing to them with relative paths.

One thought is that you could export the partition as a .qxp. Now it's not in the /incremental_db, but a single file that can be added to your project just like it's a source file.

Finally though, .qxp files made from encrypted IP still need the source IP to look at(and it has to be in the same path as the original) and you still need a license. It's supposed to work that it can't be used to get around not having a license.

Thank you, Rsyc, for the export partition tip.

It does make sense to export the design as a partition, although I fear that the absolute path references will remain. As my colleague has the encrypted IP's license, licensing won't be a problem, but absolute paths would be.

Nevertheless, I tried exporting the entire partition with:

quartus_cdb --incremental_compilation_export=exported.qxp --incremental_compilation_export_post_fit=on --incremental_compilation_export_routing=on --rev=myRev myProj

... but quartus_cdb crashed with a long stack trace. :(

(This is Quartus ver 11.0 SP1 by the way)

--- Quote Start ---

Please file an SR, as the archive should be pointing to them with relative paths.

--- Quote End ---

Sure thing, hopefully it will help other people who run into similar issues.

--- Quote Start ---

The reason why I don't/can't generate the programming file is that for some projects, I don't have all the IP licenses and my colleagues does. So getting synthesis and fit done is as far as I can go.

--- Quote End ---

I see. That is a little frustrating.

--- Quote Start ---

In an ideal setup, I would definitely want to do everything on my machine before passing the design over to him and his team. Will definitely think about how to streamline this process. Your setup definitely sounds a lot more optimized for Quartus.

--- Quote End ---

You could use a common virtual machine, or run the Quartus software on a Linux server that you both log into and do your personal tasks. That server would have the IP licenses.

Cheers,

Dave