> Hi KJ,
>
>> 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'.
>
> 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.
>
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.
> Best regards,
>
>
>
> Ben
>
>
>
Reply by Ben Twijnstra●September 30, 20062006-09-30
Hi KJ,
> 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'.
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
Reply by Mark McDougall●September 28, 20062006-09-28
KJ wrote:
> - 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.
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.
> - 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.
Yes, I've traced through perl and other scripts to find build problems...
> - Components that you design can't pass generics other than std_logic or
> integers through the tool chain using the 'Component Editor'.
I found that out the hard way too!
> 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.
You found yourself in the 'too hard basket'! ;)
> Having said all THAT though, I can also say that the Avalon bus
> specification itself is excellent and can recommend using it.
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,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply by KJ●September 28, 20062006-09-28
<jjlindula@hotmail.com> wrote in message
news:1159383143.067882.307120@k70g2000cwa.googlegroups.com...
> Hello, I've been seeing more training at Altera concerning their SOPC
> Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if
> these tools are gaining acceptance in the engineering world? A
> co-worker used the Nios processor a few years ago and said that it was
> slow so they didn't use it in their project. Are these tools useful for
> high-speed applications? If anyone can comment on these tools I'd
> greatly appreciate it.
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
Reply by Mark McDougall●September 27, 20062006-09-27
jjlindula@hotmail.com wrote:
> Are these tools useful for
> high-speed applications? If anyone can comment on these tools I'd
> greatly appreciate it.
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,
--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply by Antti●September 27, 20062006-09-27
jjlindula@hotmail.com schrieb:
> Hello, I've been seeing more training at Altera concerning their SOPC
> Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if
> these tools are gaining acceptance in the engineering world? A
> co-worker used the Nios processor a few years ago and said that it was
> slow so they didn't use it in their project. Are these tools useful for
> high-speed applications? If anyone can comment on these tools I'd
> greatly appreciate it.
>
> Thanks,
> joe
learning is almost always worth (something).
NIOS (or any soft-core CPU) - is not as fast as dedicated CPU's today
can be, and equally is the bus structure and peripherals also not as
fast as they can be in dedicated MCU's - so the real advantages come
from the combination of configurable processor core, user selectable
peripheral, AND user added IP cores.
a small task that may take up 99% of the CPU time could possible
be moved to FPGA hardware directly and only consume 1% of the
FPGA resources. That would give you a feeling like the CPU did
come 100 times faster!
if using the softcore processor alone, then it want compete with
dedicated CPU's it has never been the goal also.
Antti
Reply by jjli...@hotmail.com●September 27, 20062006-09-27
Hello, I've been seeing more training at Altera concerning their SOPC
Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if
these tools are gaining acceptance in the engineering world? A
co-worker used the Nios processor a few years ago and said that it was
slow so they didn't use it in their project. Are these tools useful for
high-speed applications? If anyone can comment on these tools I'd
greatly appreciate it.
Thanks,
joe