Important points to note before using the Nios CPU core

... brought to you by the MAIDEN Project Team ... written by Horace Chan

Overview:

For various reasons, our group's path to a working design with an integrated Nios CPU core was long and sometimes fustrating.  The long hours spent debugging integration problems and lincense issues are the motivation behind this application note.  Hopefully this application note will save you some time debugging and increase your group's chances of success in getting a working system on chip design.

The tools we used for our working Nios design:

License issues:

Our first attempts at making a Nios CPU core was done via the SOPC Builder v2.7 in Quartus II v2.2 under the UNIX environment.  The SOPC Builder would generate a custom core without problems, but when we attempted to compile the Quartus Project with the SOPC Builder under Quartus II v2.2, we recieved this error message from the compiler:

> Can't compile design containing encrypted file
> .../ee552/test_nios/sopc_parameters_0.tdf -- current license does not allow this file to be opened

After confering with the course TAs and lab administrators, we were still not able to resolve this issue.  Instead of continuing to expend our resources resolving this issues, our TA suggested using an older version of Quartus where he had been succuessful in generating a custom core.

Using the Mentor Graphics Leonardo Spectrum Synthesis tool for the Nios core:

In the Nios tutorial, Altera specifies that when using either the Megafunction Wizard generator or the SOPC Builder to generate the Nios core, it automatically uses the Mentor Graphics Leonardo Spectrum Synthesis tool to synthesize the Nios entity.  To prepare Quartus for the external synthesis tool, we have to change the Assignment menu > EDA/Synthesis tool settings and specify the Leonardo Spectrum (Level 1)  tool as the tool for Design entry/synthesis.

For further information on using Mentor Graphics Leonardo Spectrum Synthesis tool to synthesize designs for use in Quartus, refer to this app-note.

Large designs and long compile times:

As we began integrating the Nios core with the rest of our design, our project soon grew to use a significant portion of the resources of the APEX20EFC200 chip.  In fact, at one point we had to reduce the number of registers that the Nios' contains (from 256 * 32b registers down to 128 * 32b) to allow for other custom VHDL components (encryption/decryption unit in our case) to use the on board EABs (embedded array blocks) for memory purposes. 

The increase in design size and complexity also increases the compile (espeacially the fitting ) time.  In testing stages, our CPU and Blowfish encryption unit took upwards of 70% of the chip's LEs (logical elements) and 90% of the EABs, this resulted in significantly difficult place and route and fitting problem for the compiler and led to LONG compile times of over 16 minutes (running on Pentinum 4 1.8Ghz 256mb ram Windows 2000 machines).  We found this long compile time to be difficult to work with, as each change to the CPU core interface represents (10 minute core generation + 16 minute compile) of wait time prior to being able to test the design.  Perhaps better simulation and debugging tools in later versions of Nios core (we were using v1.1.1, at the time of writing Nios is into v.3.0) will improve this situation.

Also, as the design gets complex, we found that the maximum clock frequency of our design drop below the 33.3Mhz that the Nios core was quoted to operate at in Megafunction wizard, so beware of timing issues that may surface. 

Last edited by Horace Chan on March 25th, 2003