Is it worth learning SOPC Builder, DSP Builder & Nios Processor?

High speed applications don't necessarily require a high-speed MCU.

Granted, the NIOS isn't as fast as dedicated MCUs but there are other benefits when you don't require processor grunt:

1. Lower chip, pin count
2. Integration. As many or as few peripherals can be integrated into the MCU as required - all done in 'software'.
3. Customisation. Custom instructions can be added to the MCU for application-specific performance enhancement.
4. Integrated development tools.
5. Flexibility. Useful during proof-of-concept or R&D phases. Can also be used to support families of products with different feature sets.

FWIW we have implemented the NIOS in 2 commercial products for a customer so far.

Regards,

On the SOPC Builder side of things I can flatly state that the tool itself is very poor for anything other than the most minimal of 'programmable systems on a chip'. That being said, it can be a good tool if your design does fit into that 'minimal' definition. Specific area where it is not very good are:

- GUI. Once you have 'too many' components, the GUI is nearly impossibly slow to work with.

- Build time. Again once you have 'too many' components and even just by making innocious changes to the .PTF file the build time can sky rocket out to over a day and sometimes never complete ('never' meaning I waited more than a day than gave up). 'Normal' build times should take minutes.

- Miserable error reporting. When SOPC Builder fails for whatever reason, there is typically no message or log file with any information regarding what it didn't like, just the command line that it invoked that caused the error.

- Components that you design can't pass generics other than std_logic or integers through the tool chain using the 'Component Editor'. I tend to like to pass 'time' types for those cases where the underlying widget needs to know how much time elapses per clock cycle because it needs to do something every so much time, or wait a certain amount of time for something etc.

- Quality of results. Where to begin? - Multi-mastering logic to a shared resource performance drops rapidly (like after ~3-4 masters). SOPC Builder has no controls for improving it so you'll have to do it yourself. - Multi-slave read side logic back to a master drops (but not nearly as quickly as with the multiple masters). SOPC Builder has no controls for improving it so you'll have to do it yourself. - Even after making the above two design changes and implementing them into the SOPC Builder flow I was only able to get the design from ~45 MHz up to ~75 MHz. That's a big improvement but I needed to get to over ~110 MHz. So I gutted the last remaining code that SOPC Builder generates and wrote it myself and was able to get up to 133 MHz without any trouble.

I should note also that my completely gutting and not using any of the SOPC Builder generated code I did not take advantage of any 'specific knowledge of my particular design' when I rewrote that code. I simply coded it per the Avalon specification itself. The end result was virtually identical logic resource usage and ~3x speed improvement.....and code now that was in no way limited to only being usable with Altera.

All of these were submitted to Altera support and I worked with the FAE on this and as of Quartus 6.0 SP1 all of the above problems appear to still exist. For a while Altera seemed to be willing to help but I submitted so many bug reports that they ended up dropping my problems as not being 'important enough for them to work on' because most other users don't have these types of problems. When pressed on what made my design 'out there' the response was the size of the design. My design has a lot of interfaces but darn near all of them were simple point to point connections connecting components that implemented portions of a processing pipeline....not at all a 'difficult' thing to do, but apparently it was too taxing for SOPC Builder. The targetted part was a Stratix II EP2S60 so while I was in the 'big' family I was only using the mid-range part in that family. Prior to using SOPC Builder (and even after on other bugs I discover) support response from Altera has been good so it's not just 'me'....well, I hope not.

Having said all THAT though, I can also say that the Avalon bus specification itself is excellent and can recommend using it. Designing to that specification does not in any way lock you into an Altera implementation. It's only when using SOPC Builder to tie it together that you've locked into Altera. Mainly for the above mentioned reasons though I don't use SOPC Builder.

Another option is OpenCore's Wishbone but that specification is actually not as good as Avalon in many ways. OpenCores seems to have a SOPC Builder like tool to tie together the components but it too is limited in the number of components that it can tie together. I haven't used it so I can't comment on the quality of that tool.

As for NIOS, without some application in mind you can't really say whether any processor is 'good' or 'bad'. There are several companies out there developing NIOS related stuff (do some Googling) so somebody must be using it. NIOS has all of the tool support and can run uCLinux so it would seem to be OK for many apps. The custom instructions should allow you to speed up the code sections that need it with real hardware which is pretty much out of the question with most other processors. Bottom line is you have to benchmark it yourself using code somewhat representative of what your major areas of concern are.

KJ

Heh, interesting. I had a design with a modest amount of components that was generating in about 4-5 minutes. I used this design for several weeks until the project was complete.

Not longer after, I inherited an existing design from a customer which I was to extend. It had quite a few more components, but most of them were empty shells or instantiations of the same component.

I hit generate and the system would 'hang'. I spent over a day trying to find the problem - upgrading Quartus, upgrading NIOS, cloning the customer's development environment, etc. Then I started a 'generate' and got distracted doing something else. A few hours later I switched back to SOPC Builder and to my complete surprise - the build had finished!

(I should add that the developer responsible for the project was by this time on his honeymoon in Europe, so I couldn't ask anyone how long it should take.)

Not knowing how long it took, I tried to generate again and it hung. But I let it go and finally saw the process spit out more messages as it continued the build. I was stunned with the seemingly exponential time increase.

Yes, I've traced through perl and other scripts to find build problems...

I found that out the hard way too!

You found yourself in the 'too hard basket'! ;)

Yes, and wishbone components wrap nicely in the component builder too.

One slightly tricky thing we did was implement a SHA1 hasher around the opencores DMA engine, so that simply using DMA to read a block from, say, Compact Flash, calculated the SHA1 hash value. That required some gymnastics in SOPC builder - we had to write an Avalon 'pass-thru' component whose memory space overlapped everything else so DMA addresses required no translation from PIO addresses and also (by educated guesswork) had to get the component ordering in the SOPC GUI just right for it to work properly!

Regards,

Hi KJ,

I was told that this was also recognized by Altera themselves, and that SOPC Builder will have had a complete overhaul in Quartus II 6.1. The PTF file will be gone (I vaguely remember a slide mentioning XML combined with something else as the replacement).

Having designed and debugged a few SOPC Builder bits and pieces, I can't say how happy I am that Altera finally took this horribly over-evolved proof-of-concept code behind the barn and shot it. Kudos to the guys that kept it going in the meantime, and I'm really curious about the successor.

As a sidenote, if you run SOPC Builder on Solaris or Linux, you'll cream your pants over the speed at which the generator runs on those platforms - the generator is written in Perl and doesn't need the Cygwin emulation there. I've witnessed tenfold speed improvements on large (30+ components) designs.

Best regards,

Ben

Cygwin is a great piece of work, but there are three things it does badly, all of which hit SOPC Builder. You can get endless trouble if you have more than one installation on the same machine, especially if one application (i.e., Quartus/SOPC Builder) selfishly adds its own copy to your path, and it is slow at creating new processes and working with files (because it has to add Posix semantics on top of Windows). For Quartus/SOPC Builder, Altera would do much better by shipping a native windows perl interpreter - then we would get close to *nix speed.