Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21600 Discussions

Incremental compilation and NIOS - Bottom Up

Altera_Forum
Honored Contributor II
1,695 Views

Hi all, I'm using incremental compilation in a mix mode (all is top down) but I would like to have the nios in Bottom Up so that the people that develop it can change its part and give me the .qxp file. 

 

I've imported it but now in the assembler it tell me that he can't do the .pof files because it need the encripted file "CPU_Supervisor.vhd". 

 

Have I to pass in the "master project" all the .vhd generated by the NIOS in order to make all work? Shouldn't be enough the .QXP? 

 

Thx in advice
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
926 Views

The quartus flow currently does: 

quartus_map 

quartus_merge 

quartus_fit 

 

So the quartus_map still reads in all the VHDL files for that hierarchy, and at the quartus_merge stage it is replaced with the .qxp file. So for now, yes, you still need this. I believe the next release will have changes to directly allow what you want. (You could make a wrapper file for the Nios that is empty, and then you don't need all the sub-files, which is a nice temporary workaround.) 

I am a little concerned about using Nios this way, just because if you re-generate the SOPC system, and the Nios creation is dependent on something else in the SOPC system, and hence a slightly different Nios gets created, you are basically ignoring those changes. I don't know the flow well enough to know if this will happen, but it's a concern. Especially since Nios by itself usually isn't that large, and therefore isn't that much of the compile time, it's introducing risk to save a few minutes. (I don't know the specifics of yous situation though, naturally)
0 Kudos
Altera_Forum
Honored Contributor II
926 Views

All the sopc is what is partitioned. 

I've created exactly what you told: a wrapper file that is on the main project. 

But when I've imported the .qxp it ask me only that files because it tell that it is encrypted. 

As workaround with the .qxp the other people give me the CPU_Supervisor.vhd that I put in the main directory of my project. 

 

I think that the problem went up only because I've told quartus to import the netlist and not the place and route, now I've fixed the partition also with logic lock and exported that in the "Nios" project and use the place and route (but I'll see that tomorrow, because each compilation is almost 1h of time). 

 

Thx Risc for the suggestion and for advice for potential drawback. 

We've chosen this way because in the "Sopc project there are also some other files created by the megawizard and in nios you've to specify the directory and a lot of time we've problem because we copy the directory of the project, then we change some IP in the new directory but the Sopc go for the old one (you can't give relative assignment, but you've to give the full directory name). 

 

I'll keep to update the thread with what I discover.
0 Kudos
Altera_Forum
Honored Contributor II
926 Views

Are you trying to use the .qxp for a design partition containing the entire SOPC Builder system? That is supposed to be supported. However, you might have run into a situation that exists for some IP with license-protected encrypted files. I didn't realize that this situation existed for Nios, but maybe it does. (Darkwave, I saw your post just above right after I posted this.) 

 

Because of the way the licensing protections work for some encrypted IP, you have to provide the original IP source code at the original pathname where the files were when the compile was done that generated the .qxp file. You are still able to get the benefits of the bottom-up flow with the .qxp file. You just have the added hassle of having to provide these source files in the correct location.
0 Kudos
Altera_Forum
Honored Contributor II
926 Views

What I was talking about is covered in the Quartus handbook, volume 1, Section I, Chapter 2. 

 

 

 

 

--- Quote Start ---  

Importing Encrypted IP Cores in Bottom-Up Flows 

 

Proper license information is required to compile encrypted IP cores. The license assignment is imported in to the top-level project when a design is imported as a .qxp file. However, the license assignment contains an absolute path to the licensed IP source files. Therefore, the .qxp file works correctly only if imported into a top-level project on the same computer as the lower-level project, or the IP files are installed in the same directory path location on both computers. 

 

To avoid this problem, you can include this partition in the top-level project instead of importing it, because IP cores generally do not require additional changes by a designer in the project team. You can set the partition that contains the core to Post-Fit after the first compilation to reduce future compilation times, because the partition will not be changing in any subsequent compilation. You can also set the partition to Empty to exclude the IP core from the database until you are ready to compile the entire design. 

 

If you do want to import an encrypted IP core, copy the encrypted IP source files to the top-level project's computer in exactly the same path structure. For example, if the IP encrypted source file was d:/work/my_encrypted_file.vhd, the top-level designer that imports the .qxp file must create the same folder and place the file in this location. 

--- Quote End ---  

0 Kudos
Altera_Forum
Honored Contributor II
926 Views

You can do relative paths. When you add them into menu, just edit the absolute path to make it relative. (I think if you add anything under the project directory, it is added relatively, and anything outside is an absolute path, but you can modify either one.) If that's all your trying to solve, I would recommend against the .qxp flow.

0 Kudos
Altera_Forum
Honored Contributor II
926 Views

 

--- Quote Start ---  

You can do relative paths. 

--- Quote End ---  

 

 

 

For the encryption issue, I was told that part of the hassle is having to have the same absolute pathname on the machine exporting the .qxp and the machine importing the .qxp. I don't know whether there is a way to make it work if one of those machines is Linux and the other is Microsoft Windows.
0 Kudos
Altera_Forum
Honored Contributor II
926 Views

Ok thanks both, I've missed that paragrah on qII handbook. 

The solution is simply to copy the CPU_Supervisor.vhd that was created by SOPC with the NIOS (Yes my partition include all the SOPC block). 

 

For the relative assignment you can do that in the Quartus II, but on SOPC you cannot (or at least I can only add path and not edit one (I'm speaking of the menu under Tools/Option/IP Search path of the SOPC Builder). 

 

If can be helpfull I'm using QII ver 8.0 sp1 (the last available). 

 

Thx both for the help/support
0 Kudos
Reply