Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Honored Contributor I
981 Views

10 things that should be enabled in Quartus by default, but are not...

Hello, I've compiled a list of things that have are enabled in Quartus by default, but really shouldn't be for most designs. I've seen issues in the lab with some of these default settings, so hopefully this helps saves you time... 

 

 

Version 1.1 

 

1. Enable “recovery removal analysis.” This will perform a synchronous analysis on all asynchronous inputs. Enabling this mode ensures that the output of all flops is deterministic and repeatable within each clock period, even after an asynchronous event such as reset. By default this is disabled in TAN and enabled in TimeQuest. 

 

2. Enable “clock latency.” Enabling this mode will perform analysis of delay on the clock network as a result of factors such as a PLL compensation delay. Designs that didn’t enable this and have added multicycle constraints to handle the way TAN interpreted offset vs. latency would have to remove the “corrective” multicycle assignments. By default this is disabled in TAN and enabled in TimeQuest. 

 

3. Enable “Report Combined Fast/Slow Timing” and “Optimize for fast-corner timing.” Enabling this mode will report timing results with both the fast (best case) and slow (worst case) timing models and ensure that the fitter is performing timing driven compilation for both corners. This needs to be enabled to ensure that timing is met on both slow and fast corners of the speed grade that has been selected. This is usually a trade off for compile time. 

 

4. Uncheck “Auto RAM Replacement” in Analysis & Synthesis Settings. This should be disabled because it “allows Quartus to change the functionality of the design” which means synthesis vs. simulation may diverge. Personally, I don’t like inferred RAM – I realize it makes your RTL technology independent, but inferred RAM isn’t always inferred the same, and I would prefer deterministic and repeatable. Inferred RAM works ok for simple dual port, single clock. Use at your discretion and check the compile warnings. 

 

5. Uncheck “Power-Up Don’t Care” in Analysis & Synthesis Settings. Disabling this setting will allow all flops to power-up set to zero instead of unknown. This allows the design behaviour to be more deterministic and repeatable at the expense of optimizing some of the logic surrounding it. 

 

6. Select power play power optimization to “Extra effort.” This will minimize the power of your design – if performance is more important (which it usually is) then leave this to “Normal compilation.” This is highly design dependent. 

 

7. Select minimum IO drive strength required for your application. The default drive strength used by Quartus for all IO standards is set to maximum (for everything pre-65nm) – this is ideal for IO timing, but not necessarily for power and SSN. This is highly design dependent and the maximum setting maybe ideal for your application. 

 

8. Select on-chip termination for the IO standard that you are using. By default these are set to off. For optimal signal integrity it is usually better to use on-chip terminations. This design dependent and will depends on results of signal integrity simulations. Note that receive differential termination (including S2GX receive GXB) and TTL serial termination are not turned on by default. Also note that not all LVDS inputs support on-chip differential termination. 

 

9. Enable “Generate Stratix II GX GXB Reconfig MIF.” This needs to be enabled in order for Quartus to generate the S2GX MIF files – this is only required for dynamic reconfiguration of transceiver ports, but there is really no reason why this should be disabled. 

 

10. Run each of the “design advisors”. This allows you to interactively allow Quartus to go through each design and makes recommendations to the switches set – this is selected in Tools>Advisors and is not normally ran after each compile. There are a number of recommendations for resource, timing, power and incremental compile that can improve your results. 

 

 

You can change most of these in your assignments_defaults.qdf file located in the quartus/bin directory. 

 

Thanks for reading!
0 Kudos
13 Replies
Highlighted
Honored Contributor I
55 Views

Good list. I wouldn't default PowerPlay Power Optimization to extra effort because it has a negative impact on design performance (Fmax) and I think on compile time as well. 

 

If you select on-chip termination, be sure to add the Rup/Rdown resistors to your board.
0 Kudos
Highlighted
Honored Contributor I
55 Views

Has the "Unused Pins" setting default been changed yet? If not, that would have to make your list. I once spent an entire day trying to figure out why my simple LED-flasher design wouldn't run on a Nios development kit. Turns out that the project had defaulted to setting all unused pins to "As Output Driving Ground."

0 Kudos
Highlighted
Honored Contributor I
55 Views

Thanks Astro ! I'll run through some of these in preparation...

0 Kudos
Highlighted
Honored Contributor I
55 Views

 

--- Quote Start ---  

Has the "Unused Pins" setting default been changed yet? If not, that would have to make your list. I once spent an entire day trying to figure out why my simple LED-flasher design wouldn't run on a Nios development kit. Turns out that the project had defaulted to setting all unused pins to "As Output Driving Ground." 

--- Quote End ---  

 

 

I agree this "burns" a lot of us. Pun intended. The reasoning behind defaulting as outputs driving GND is for power consumption reasons. Floating inputs may oscillate with noise causing unwanted power consumption. For a large device and package this really adds up. The downside is when using dev kits and not remembering that this setting must be changed every time!
0 Kudos
Highlighted
Honored Contributor I
55 Views

 

--- Quote Start ---  

I agree this "burns" a lot of us. Pun intended. The reasoning behind defaulting as outputs driving GND is for power consumption reasons. Floating inputs may oscillate with noise causing unwanted power consumption. For a large device and package this really adds up. The downside is when using dev kits and not remembering that this setting must be changed every time! 

--- Quote End ---  

 

 

OK, that almost makes sense. May I suggest "As inputs with weak pull-up" as the default? It's less likely to damage something than driving ground as well as able to deal with floating inputs. Seems win-win to me...
0 Kudos
Highlighted
Honored Contributor I
55 Views

Astroboy, 

I think your list is valuable! 

Regarding: 

"7. Select minimum IO drive strength required for your application. The default drive strength used by Quartus for all IO standards is set to maximum (for everything pre-65nm) – this is ideal for IO timing, but not necessarily for power and SSN. This is highly design dependent and the maximum setting maybe ideal for your application" 

I've always asked myself why Altera's default is max dirve strength!! 

By the way this is one of the 1st warning given for HardCopyII migrations. 

I would like to ask you if you are aware of a default change in 65nm. 

 

Thanks 

Cheers 

Bilotto
0 Kudos
Highlighted
Honored Contributor I
55 Views

 

--- Quote Start ---  

OK, that almost makes sense. May I suggest "As inputs with weak pull-up" as the default? It's less likely to damage something than driving ground as well as able to deal with floating inputs. Seems win-win to me... 

--- Quote End ---  

 

 

Seems reasonable to me too. The follow up argument made is that outputs driving GND will act as programmable grounds to help SSN, although I don't believe unconnected GNDs really helps SSN much. Simply having a tri-stated pin next to aggressors helps just as much as an output driving GND.  

 

So the real case to be made is to ask for a user specified default for all of these items listed above. I don't want to edit my qsf for each project, I want to login into Quartus on my machine have it know what defaults I set the first time I ran a project. Mysupport enhancement request...
0 Kudos
Highlighted
Honored Contributor I
55 Views

I would suggest this thread be called "10 default settings you might consider changing when you start a design" 

 

2. I don't think Altera should change the default whereas it would be a disaster for folks like me that have used Multicycles to get my desired setup relationship. 

 

4. Every synthesis tool I know can inferred RAM. They all have the same limitation that the HDL does not model the read-during-write case. Not sure any of the synthesis engines should stop inferring RAM by default. 

 

6. Extra effort power optimization can be costly to Fmax. I don't think this would be a good thing for most designs. 

 

7. As stated this greatly impacts IO timing. Probably not good for most designs. 

 

8. This burns power which by your last two request you seem to want to minimize by default. 

 

10. This cost compile time which I don't want to spend every time I run a compile. But turning this on by default will bring it to everyone's attention that Altera does have these tools. As long as it is easy to turn off, this seems reasonable. 

 

All 10 of these items are important to consider and just knowing about them will probably save many folks some troubles :-)
0 Kudos
Highlighted
Honored Contributor I
55 Views

 

--- Quote Start ---  

May I suggest "As inputs with weak pull-up" as the default? It's less likely to damage something than driving ground as well as able to deal with floating inputs. 

--- Quote End ---  

 

 

 

I recommend setting "Device and Pin Options --> Unused Pins --> Reserve all unused pins" to "As input tri-stated with bus-hold circuitry" for device families that offer that choice. As I said in a post for another topic, bus hold has no conflict with an unused pin being grounded on the board. With the weak pull-up, you'll have a little wasted power. 

 

 

I had noticed that this default changed in Quartus for some device families, so I checked to see what QII 7.1 gives for a few cases. When I created a new project for each of the following families, I got the following. It looks like your request has already been granted for most new families. 

 

  • "As input tri-stated with weak pull-up resistor" for Cyclone III (new family) 

  • "As input tri-stated with weak pull-up resistor" for Stratix III (new family) 

  • "As output driving ground" for Arria GX (new family, so not every new family has the change) 

  • "As output driving ground" for Stratix II and Stratix II GX (this is probably still the default for all older families too) 

0 Kudos
Honored Contributor I
55 Views

 

--- Quote Start ---  

So the real case to be made is to ask for a user specified default for all of these items listed above. I don't want to edit my qsf for each project, I want to login into Quartus on my machine have it know what defaults I set the first time I ran a project. Mysupport enhancement request... 

--- Quote End ---  

 

 

 

I think there's already a solution for this. I have not tested this idea, but I think you can personalize your defaults for new projects using the assignment_defaults.qdf file in the Quartus installation. 

 

.qsf files have something like this in the header: 

 

 

--- Quote Start ---  

# The default values for assignments are stored in the file 

# generic_test_case_assignment_defaults.qdf 

# If this file doesn't exist, and for assignments not listed, see file 

# assignment_defaults.qdf 

--- Quote End ---  

 

 

That assignment_defaults.qdf is in the Quartus installation. Mine is at C:\altera\71\quartus\bin and C:\altera\71\quartus\bin64. 

 

To find a legal value for anything you want to change in assignment_defaults.qdf, create a project with the value you want and look in the .qsf (probably easier and more reliable than looking it up in the .qsf documentation). 

 

The .qsf header lists generic_test_case_assignment_defaults.qdf. (I didn't check, but as I recall the name is taken from and must match the .qsf revision name, not the .qpf project name.) This .qdf was created when I opened my QII 6.1 project in QII 7.1. If you have a .qdf in your project directory like this, it will override the assignment_defaults.qdf in the Quartus installation--something to remember when you first open your project in a new Quartus version. 

 

There's some documentation in the Quartus II Handbook in Volume 2, Section I, Chapter 4, at "Quartus II Default Settings File". (Where it says the "win" directory, for QII 7.1 it's actually the bin and bin64 directories.)
0 Kudos
Highlighted
Honored Contributor I
55 Views

Hi, 

 

Setting power optimization to extra-effort shouldn't hurt Fmax much -- typically its in the range of a couple %. That said, you probably shouldn't compile with this all the time. Just wait until you're nearly finished the design and have closed timing, then engage power optimizations. 

 

As for "inputs tri-stated" default and reduced drive strength, both of these were changed in 65 nm families. Why didn't we change old families? Because the way Quartus deals with "defaults" is that if you haven't overrided a default in your project, then if we change the default from one Quartus release to the next you will (silently) have the settings for your design changed. If we changed the default drive strength, for example, then anyone migrating a design where they (foolishly) havn't explicitly selected a drive strength would suddenly see a reduction in their I/O performance. 

 

Nice list. 

 

Regards, 

 

Paul Leventis 

Altera Corp.
0 Kudos
Highlighted
Honored Contributor I
55 Views

Hi Folks, 

 

Point 9, regarding the GXB MIF files.  

 

Where is the option to tick this in V7.1 and v7.2 of Quartus? 

 

TTFN 

NN
0 Kudos
Highlighted
Honored Contributor I
55 Views

Hi Nios Ninja, 

 

This option can be set by clicking More Settings on the Fitter Settings page in the Settings dialog box. You have to make sure you've selected a S2GX.
0 Kudos