Austin the Altera Mole

What 'changed' is the calendar. For the past several years, Altera's version numbering on Quartus has been the last digit of the year followed by .0 (for the first release in the calendar year), .1 for the next, etc. No, I'm not kidding.

Kevin Jennings

Sorry for the delayed response -- I just got off the phone with the fruit basket place ;-)

We've released new versions of the Quartus II software at least twice per year for quite a while now. As Kevin correctly observed, our version numbers happen to line up with .. Each major release of the software incorporates new features in a variety of areas.

Here's a partial list of major features in the past couple of releases:

QII 7.0: Cyclone III device support, including TimeQuest Timing Analysis and PowerPlay Power Analysis and Optimization.

QII 6.1: Stratix III device support. Multi-processor support (parallel compile). Chip Planner tool. Advanced I/O Timing (I/O + board trace timing & signal integrity). Mjor GUI changes, including dockable windows.

QII 6.0: TimeQuest Timing Analyzer. Project Manager Interface.

In addition, we're constantly changing the synthesis, placement and routing algorithms "under the hood" that optimize the quality of results for your design. This affects the critical path delay, dynamic and static power, and density (# of LEs required) of your design, as well as compile time and memory footprint of the software.

And of course, we're fixing bugs, updating timing models, adding support for device features, adding assembler support, adding new OSes, etc. We release "Service Packs" of the software between major releases to more frequently roll out these sorts of changes.

So if you don't care about Stratix III or Cyclone III devices, don't want faster & better compilation results, don't need to interface with a PCB, and aren't hitting any bugs that affect your design, there's no reason for you to move to QII v7.0. However, the migration experience is fairly painless, and you may find yourself liking some of the new features you can by migrating.

Regards,

Paul Leventis Altera Corp.

Awesome!

You could probably just get away with sending 3 SPARTAN Extra crunchy apples.

Anyways, the reality is XST is suprisingly good for small to medium designs so don't listen to Austin.

And yes, we usually use Synplicity.

Ricky.

Paul,

Thanks for this morning's good laugh.

Wondered where you were hiding.

Welcome back.

Austin

What's with all the xilinx altera rivalry in the world? I mean.. I can seem THEM being rivals... being competitors and stuff.... but why US, the users? We'd be far better off if we just picked whatever part was best for our individual application. At work, I've generally used xilinx - just because they have best fit the applications I was looking for. When I'm mucking around with a project at home, Altera is usually better because I can get much more FPGA in a QFP package that I stand a chance at soldering by hand. Brand loyalty seems so silly to me... why? to avoid learning another one of those wildly difficult tool sets? (psst... I'm joking... neither is too challenging!) Anywho... does anyone actually have a legitimate reason for brand loyalty? Or is it just the PC/Mac/Linux crap rehashed?

Why do Ford owners give Chevy drivers flak?

Us Honda drivers laugh at both.

-a

Un bel giorno Paul digitò:

Familiarity with the development tools? Better app notes/technical support?

--
emboliaschizoide.splinder.com

Paul,

For the same reasons as you spelled out we wanted to migrate from QII

6.0 to QII 6.1 unfortunately, the signed multiplier did not get inferred correctly in QII 6.1. I can still remember checking with the QII documentation to see if we incorrectly described the logic. But everything was according to the docs on Altera's website.

The point is that it is this kind of unpredictable behavior between releases of the tools that give us cold feet when it comes to moving an existing project to a new release of the software.

-sanjay

Sanjay,

I totally hear ya on different versions of the tools. We try to stick with one version on a project start to finish... for some of our older projects that have been around a few years, we've got people running ISE 6-something around here for that very reason. As for inference templates changes from version to version - I've only used the vendor's synthesis tool on smaller hobby projects. For the larger stuff here, Synplify seems to be pretty stable in that regard. I'm just saying, when starting on a new project, clean slate... I don't understand the drive to go one way or the other, because it really depends upon the application.

Hi Sanjay,

Yes, there are always risks moving between versions of software. We spend literally months between when we're finished programming a Quartus II version and when we actually release it. That time is spent running tons of tests -- every single old test we have lying around, plus a bunch of new ones we write to cover new cases. However, we cannot cover every possible form of input to the tool. Did you file a bug report on your issue? Bug reports turn into new tests that get run with each release, filling holes in our code coverage.

In your case, was it a relatively small piece of code whose synthesis changed? Or was it a complex piece of code? I don't know if in this case it was a bug (somebody broke inferencing?) or just a subtle change in the myriad of choices/trade-offs the synthesis tool must make.

One approach to reduce the amount of change between releases is to lock down the version of your synthesis tool -- be it Quartus or a 3rd party tool. But you can continue to update your Quartus back-end to get the latest & greatest P&R, timing, features, etc. I like to think the *stability* and overall quality of Quartus does not degrade from release to release -- in fact, as measured by number of IEs (internal errors) per compile as reported by users, it has been steadily improving.

As suggested by yourself and another poster, sometimes the best approach is to lock down to one version of the software for your entire design cycle. We certainly have customers who do this. When the family you are designing to is reasonably mature (for example, has Final timing models), this may be the best solution. Or you could take the Microsoft user approach -- wait until the first Service Pack release when any of the little problems have been shaken out!

Regards,

Paul Leventis Altera Corp.

Paul,

I agree,

(this is getting pretty unusual, isn't it? Fruit basket must have been spiked with something...)

Locking down a release for a project is just smart engineering management. When I ran development groups, each project manager submitted the tools they were to use, and the tools were all placed under ECO control. AT various times I would have QA audit the project, to be sure we had control of our software.

If something horrible happened, and the tool had to change, at least it was a structured process, and there was a paper trail to show what, where, and why. Additionally, an archive of everything would be made at the transition point, just in case.

Austin

Paul, I fall in the same camp as you do... i.e. look at the best architecture for a project. But lately with a processor inside the FPGA, we find that the decision to move to a different vendor at the start of any project gets a bit complicated as the software developers would also like a say in the decision.

It would be interesting to see how others approach this problem. Maybe a different thread.

Best, Sanjay

Hi Paul,

In my case, the piece of code was just a simple signed 14x10 bit multiplier with some muxes around it - I'd say about 200 lines of verilog. BTW, I am guessing that one way to lock down QII as synthesis tool would be to generate intermediate files after the synthesis stage with old version of QII and then feed those files into the latest version of QII for back-end. Did you have any other way to do it?

Thanks. Best,

-sanjay