"E.S." <emu@ecubics.com> wrote in message
news:ui3tc.160$UP5.83@fe39.usenetserver.com...
>
> Sitting long nights to get the tools working ?
> priceless ;-)
>
> cheers
>

Yeah, but once you figure out all the quirks you're Super Man!  Able to
drive any nail with your new hammer!

(at least that's what I keep telling myself , but then comes along version
2,3,4... plus XP updates :)

Some of my favorite efforts in delving into this world of fpga's and soft
cores has been separating the truly usefull feature/tools from the marketing
checkoffs.  Altera support told me that to bring out internal signals using
Signal Probe would require placing the signal into a register.  But wasn't
the whole point of SP to avoid full rebuilds? :)

(I'm sure SP is extremely usefull once mastered, just don't have "priceless"
hours right now and no one here is letting loose with the secrets)

:)
Ken

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:40B4A67A.FBE59F51@yahoo.com...
> Kenneth Land wrote:
> >
> > "Jon Beniston" <jon@beniston.com> wrote in message
> > news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
> > <snip>
> > >
> > > You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
> > > you're obviously not concerned about price anyway ;)
> > >
> > > Cheers,
> > > JonB
> >
> > Hard to imagine an embedded project without an fpga.  Might as well have
> > only one chip (fpga + softcore cpu) and save the board space since
you're
> > most likely going to require an fpga anyway. (board space == $$$, parts
> > count == $$$)
> >
> > The reason you would want to use a softcore over hard is because it can
be
> > *exactly* customized to any application.  Need 27 serial ports and
timers?
> > no problem.  Need none?  don't waste the pins or money.  Need more
> > processing power?  add custom instructions/external parrallel logic or
> > another softcore cpu (or 8!).
> >
> > I've seen hard core projects fail, but a soft core project can only fail
> > from early abandonment.  More/harder work can always find a solution,
> > because the hardware can become anything you're willing to realize.
>
> Ok, how about an 8 bit CPU with an 8 input, 10 bit ADC and a brown out
> detector?  I think this costs less than $3 and comes in a 28 pin TSSOP
> or a 5 x 5 mm QFN.  MCUs often have advantages since they are typically
> mixed signal chips, not just digital.  It can be pretty hard to beat an
> MCU with an FPGA when you need even just a little bit of analog.
>
> -- 
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com

If you didn't know you needed an ADC before you started then yes you are out
of luck.  Not so much because there's no ADC on your board, but because you
can't produce an initial design that's in the ballpark.  But yes you are
literally correct.  There are many things that an FPGA can't do.  I was
thinking more in the realm of what processing you might want to do on those
8 input channels - especially after the customer or salesmen started with
the post production design ideas :)

You sound like one of my kids "What if Godzilla shows up and steps on your
board?"

enough :)

Ken

"E.S." <emu@ecubics.com> wrote in message
news:v33tc.124$UP5.25@fe39.usenetserver.com...
> Kenneth Land wrote:
> > "E.S." <emu@ecubics.com> wrote in message
> > news:GsOsc.20467$zs2.931@fe39.usenetserver.com...
Microblaze (no grapes) - so you say "They are probably sour anyway")
>
> OK, I got it. Thanks ;-)
>
> But I wasn't even thinking about the NIOS <--> MicroBlaze
> competition (?)
>
> More along the lines, how I like to expand my processors. And
> my software guys are trying to kill me each time we invent a new
> instruction ;-)
>
> Cheers
>

You'd be treated better here!
I'm more of a software guy, but I'd be very happy if my hardware guy took
the initiative to add instructions to my NiosI/II!


Take care

>Can you explain how it "blows away" custom instructions?  I don't know what
>the FSL interface is, so I can't compare them myself.
>
>  
>
You should take a look at xilinx app.note529   
http://direct.xilinx.com/bvdocs/appnotes/xapp529.pdf
It will explain FSL a little more and also why FSL interfaces are better 
for HW acceleration that custom instructions.

G�ran

Kenneth Land wrote:

> "Jon Beniston" <jon@beniston.com> wrote in message
> news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
> <snip>
> 
>>You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
>>you're obviously not concerned about price anyway ;)

I don't think it is so easy to calculate. Having a chance to change
"hardware" at a very late stage of a project, can save you a lot of
money.

BTW, how many poeple in this group are really selling millions of 
boards, so it make sense to cut a dollar on the chip, but spend it
in software instead ?

> Hard to imagine an embedded project without an fpga.  Might as well have
> only one chip (fpga + softcore cpu) and save the board space since you're
> most likely going to require an fpga anyway. (board space == $$$, parts
> count == $$$)

Sitting long nights to get the tools working ?
priceless ;-)

> The reason you would want to use a softcore over hard is because it can be
> *exactly* customized to any application.  Need 27 serial ports and timers?
> no problem.  Need none?  don't waste the pins or money.  Need more
> processing power?  add custom instructions/external parrallel logic or
> another softcore cpu (or 8!).

But probably you didn't spent enough time to get the 
requirements/specification straight in the first place ?

> I've seen hard core projects fail, but a soft core project can only fail
> from early abandonment.  

Or delays ...

> More/harder work can always find a solution,
> because the hardware can become anything you're willing to realize.

But you need a boss with a good sense of humour ;-)

cheers

Kenneth Land wrote:
> "E.S." <emu@ecubics.com> wrote in message
> news:GsOsc.20467$zs2.931@fe39.usenetserver.com...

>>>Ever heard the term "Sour Grapes" ?
>>
>>Heard before, but why in this context ?
> 
> Uh.. Because you're saying you don't want something you can't have, even
> though it's of great value. (Custom Instructions with Nios (the grapes) vs.
> Microblaze (no grapes) - so you say "They are probably sour anyway")

OK, I got it. Thanks ;-)

But I wasn't even thinking about the NIOS <--> MicroBlaze
competition (?)

More along the lines, how I like to expand my processors. And
my software guys are trying to kill me each time we invent a new
instruction ;-)

Cheers

In article <bf780a06.0405252226.60e2d1f0@posting.google.com>,
Stifler <seannstifler69@hotmail.com> wrote:
>Also, custom instuctions are probably as stupid as a window register
>file. Why do you need a custom instuction so bad? I believe it's
>simply hardware acceleration. There's several ways to accomplish
>hardware acceleration. Altera's custom instuction can bog down your
>processor Fmax. It goes right into the middle of the pipe. Why not
>simply have your processor launch off a separate process while it
>continues to grind away at top speed?

Likewise, this is the whole BLEEPING point of having a coprocessor
interface: it gives you a separate pipeline for your instructions, etc
etc etc, so you can have the advantages of a "custom" extention to
your instruction set, without having it in the pipeline or even
necessarily in the critical path...


Chimaera (a hard processor design with an in-the-pipeline
reconfigurable unit for custom instructions) was, IMO, a failure
compared to GARP (a hard processor design with a reconfigurable unit
as a MIPS coprocessor, with its own specialized memory interfaces).

Yet Chimaera was a useful failure, an incredibly valuable negative
result: showing just how little one could achive with in-the-pipeline
custom instructions.

Especially since, for custom instructions, you are often dealing with
large working sets (otherwise you don't really benefit in the first
place), so having a coprocessor with its own optimized (eg, streaming,
strided-streaming) memory access ports is a huge win over
"in-the-pipeline" custom instructions.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Kenneth Land wrote:
> 
> "Jon Beniston" <jon@beniston.com> wrote in message
> news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
> <snip>
> >
> > You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
> > you're obviously not concerned about price anyway ;)
> >
> > Cheers,
> > JonB
> 
> Hard to imagine an embedded project without an fpga.  Might as well have
> only one chip (fpga + softcore cpu) and save the board space since you're
> most likely going to require an fpga anyway. (board space == $$$, parts
> count == $$$)
> 
> The reason you would want to use a softcore over hard is because it can be
> *exactly* customized to any application.  Need 27 serial ports and timers?
> no problem.  Need none?  don't waste the pins or money.  Need more
> processing power?  add custom instructions/external parrallel logic or
> another softcore cpu (or 8!).
> 
> I've seen hard core projects fail, but a soft core project can only fail
> from early abandonment.  More/harder work can always find a solution,
> because the hardware can become anything you're willing to realize.

Ok, how about an 8 bit CPU with an 8 input, 10 bit ADC and a brown out
detector?  I think this costs less than $3 and comes in a 28 pin TSSOP
or a 5 x 5 mm QFN.  MCUs often have advantages since they are typically
mixed signal chips, not just digital.  It can be pretty hard to beat an
MCU with an FPGA when you need even just a little bit of analog.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

"Stifler" <seannstifler69@hotmail.com> wrote in message
news:bf780a06.0405252226.60e2d1f0@posting.google.com...
> Landman,
>
> Also, custom instuctions are probably as stupid as a window register
> file. Why do you need a custom instuction so bad? I believe it's
> simply hardware acceleration. There's several ways to accomplish
> hardware acceleration. Altera's custom instuction can bog down your
> processor Fmax. It goes right into the middle of the pipe. Why not
> simply have your processor launch off a separate process while it
> continues to grind away at top speed?
>
> I can think of several ways to stomp a custom instruction depending on
> what it is. How about using a dual port ram and write a bunch of data
> to it. Have my user logic attached to the other side and process it.
> Tell me when it's done. Or, use a DMA to transfer a burst of data to a
> user peripheral.
>

What's next, "My dad could beat up your dad" ?  You are arguing about
something you aparently neither know about nor care about, so why bother?

I've got no idea about what an FSL interface is, having not looked closely
at the MicroBlaze, so I don't know how it compares to other solutions -
certainly not enough to declare it "stupid".  But there are many ways to do
hardware acceleration of a soft cpu on an fpga, and there are many sorts of
tasks that could be accelerated - what is the big problem with Altera
offering one more?  I'm sure it is possible to cause yourself problems by
using it badly, such as trying to do a slow process in a single clock cycle
and thus reducing your fMax, or stalling the processor for hundreds of
cycles - that's bad design on the user's part, not the fault of the custom
instruction concept.  If your application calls for fast, simple custom
operations, however, then the custom instruction mechanism cuts down the
overhead quite significantly.  You choose the hardware acceleration method
that matches the requirements.


> Altera hypes this custom instruction crap. It's the same hype as the
> windowed register file. It's the same joke. It's probably as stupid of
> an idea as having a windowed register file. Which they just chucked.
> Along with the 16 bit instructions.
>

Windowed register files have some advantages over traditional register
banks, and some disadvantages - and how they affect you depends on the
application.  Sun's SPARC processors are good for some uses, and poor on
others.  There are lots of choices when designing processors - register
setup and instruction formats are two of them.  What makes the "best" design
will depend on many factors, such as application, speed, fpga size, fpga
design, code density - and it will also change over time, as the developers
come up with better designs, and as development tools improve.  But just
because the Nios II is in many ways better than the Nios I, doesn't make the
Nios I suddenly "crap" or "a joke".  When your favourite crisp manufacturer
comes out with a "new, even tastier" variety - does that mean that the old
type is suddenly terrible, and that the company should be condemed for ever
advertising it?


> As someone already mentioned, MicroBlaze has an FSL interface for
> hardware acceleration. It probably blows away Altera's custom
> instruction.
>

Can you explain how it "blows away" custom instructions?  I don't know what
the FSL interface is, so I can't compare them myself.

>
> "Kenneth Land" <kland1@neuralog1.com1> wrote in message
news:<10b7qg7fqd1cod1@news.supernews.com>...
> > "Jon Beniston" <jon@beniston.com> wrote in message
> > news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
> > <snip>
> > >
> > > You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
> > > you're obviously not concerned about price anyway ;)
> > >
> > > Cheers,
> > > JonB
> >
> > Hard to imagine an embedded project without an fpga.  Might as well have
> > only one chip (fpga + softcore cpu) and save the board space since
you're
> > most likely going to require an fpga anyway. (board space == $$$, parts
> > count == $$$)
> >
> > The reason you would want to use a softcore over hard is because it can
be
> > *exactly* customized to any application.  Need 27 serial ports and
timers?
> > no problem.  Need none?  don't waste the pins or money.  Need more
> > processing power?  add custom instructions/external parrallel logic or
> > another softcore cpu (or 8!).
> >
> > I've seen hard core projects fail, but a soft core project can only fail
> > from early abandonment.  More/harder work can always find a solution,
> > because the hardware can become anything you're willing to realize.
> >
> > Ken

"E.S." <emu@ecubics.com> wrote in message
news:4KLsc.19641$zs2.4918@fe39.usenetserver.com...
> Uncle Noah wrote:
>
> > In Microblaze there is no way to add your own custom instructions. It
> > is not an extensible processor but just provides the means to add
> > peripherals to a small SoC. Correct me if i am wrong. I just hope that
> > the tools (assembler, simulator, debugger) can be retargeted for the
> > new ISA. Or be able to use inline assembly with the new instructions.
> > The corresponding hardware should be built by some RTL description i
> > would give.
>
> Sorry, but I think that "custom instructions" are the worst idea.
> Than you have to update (with new versions/revisions) not only your
> design, but also the whole toolchain ? (assembler/linker/cc ?)
>

The custom instructions are already available in the toolchain, with
pre-defined macros for the assembly instructions.  When you want to actually
use them for something, you can define new names that make more sense in
your application.  Gcc does a pretty good job of optomising such assembly
macros, so you don't lose anything.  I don't know about Nios II (I haven't
looked in detail yet), but on the Nios I you can also tell gcc to use custom
instructions automatically for certain operations.  For example, if you know
your code requires a lot of divisions, you can make a custom hardware
divider and tell gcc to use it for all divisions.

> And there is still tha chance, that the whole CPU slows down, because
> of your new instruction, so you even loose, not gaining anything :(
>

That would be the case if your custom instructions execute too slowly, so
that your cpu's max frequency were reduced.  The obvious answer then would
be to use multi-cycle custom instructions.

> Much simpler to access a "accelarator" memory mapped, or as a
> peripheral, or whatever interface you have for it.
>

Sometimes that is the case - it depends on what you are doing.  Memory
mapped peripherals require memory-style access, however, including loads,
stores and address calculations, whereas custom instructions get their data
immediately.  For fast peripherals, custom instructions will save a lot of
overhead.