FPGA Central

http://www.niktech.com

Hardware Features

· Data Path Width 32 bits
· Most instructions are 16 bit. PC Relative jump instructions are 32 bit.
· Four stage pipeline.
· Von Neumann Architecture (Data and Instruction in the same address space).
· Sixteen, 32 bit General Purpose Registers.
· Four USER defined instructions (with Register File Write back capability).
· Parallel execution of independent Load/Store, Multiply/Shift ,
User Defined Instructions and ALU instructions (In order issue; Out of
order completion)
· Some Conditional Instructions (Reduces branches & increases code density).
· Built in 32 bit Timer.
· Power Down Mode.
· 32x32 Multiplier (Multi cycle execution).

Software Development Tools
· GNU Assembler, Linker (binutils)
· GCC (C Compiler)
· GDB (Debugger) and Instruction Set Simulator
· Standalone C-Library (RedHat newlib)
· Modified version of DietLibc

Size and Performance.

Netlists for the current implementation is available for XILINX Virtex,
Spartan-II and Spartan-IIE; it
utilizes 1375 LUTs (809 slices); the size includes a 32 bit timer and a
32x32 bit LUT based multiplier.

The design has been tested to operate at 60MHZ on a Spartan-II (speed
grade -6).

Netlists, Documentation and Development tools can be downloaded from
http://www.niktech.com.

Hi Sandeep,

I guess it would fit into an Spartan-3 XC3S200, right? I'd like to test it
with this FPGA. How can we do that? (I see that there are synthesized
netlists on Niktech's website).

Regards,

--
Jaime Andrés Aranguren Cardona
[email protected]
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

"Sandeep Dutta" <[email protected]> escribió en el mensaje
news[email protected]..
> http://www.niktech.com
>
> Hardware Features
>
> · Data Path Width 32 bits
> · Most instructions are 16 bit. PC Relative jump instructions are 32 bit.
> · Four stage pipeline.
> · Von Neumann Architecture (Data and Instruction in the same address
space).
> · Sixteen, 32 bit General Purpose Registers.
> · Four USER defined instructions (with Register File Write back
capability).
> · Parallel execution of independent Load/Store, Multiply/Shift ,
> User Defined Instructions and ALU instructions (In order issue; Out
of
> order completion)
> · Some Conditional Instructions (Reduces branches & increases code
density).
> · Built in 32 bit Timer.
> · Power Down Mode.
> · 32x32 Multiplier (Multi cycle execution).
>
> Software Development Tools
> · GNU Assembler, Linker (binutils)
> · GCC (C Compiler)
> · GDB (Debugger) and Instruction Set Simulator
> · Standalone C-Library (RedHat newlib)
> · Modified version of DietLibc
>
> Size and Performance.
>
> Netlists for the current implementation is available for XILINX Virtex,
> Spartan-II and Spartan-IIE; it
> utilizes 1375 LUTs (809 slices); the size includes a 32 bit timer and a
> 32x32 bit LUT based multiplier.
>
> The design has been tested to operate at 60MHZ on a Spartan-II (speed
> grade -6).
>
> Netlists, Documentation and Development tools can be downloaded from
> http://www.niktech.com.
>
>

> Netlists, Documentation and Development tools can be downloaded from
> http://www.niktech.com.

1) are you going to release the HDL sources?
2) are you planning to port uClinux for MANIK?

Antti

>http://www.niktech.com
>
>Hardware Features
>
> ..
>Software Development Tools
>· GNU Assembler, Linker (binutils)
>· GCC (C Compiler)
>· GDB (Debugger) and Instruction Set Simulator
>· Standalone C-Library (RedHat newlib)
>· Modified version of DietLibc

The GCC - link seems to be broken ...

--
42Bastian
Do not email to [email protected], it's a spam-only account :-)
Use <same-name>@epost.de instead !

"Antti Lukats" <[email protected]> wrote in message news:<ckrbh1$kn7$04$[email protected]>...
> > Netlists, Documentation and Development tools can be downloaded from
> > http://www.niktech.com.
>
> 1) are you going to release the HDL sources?

Similarly to you Antti, are you going to be releasing the HDL source for NIOX?

Cheers,
Jon

>> The GCC - link seems to be broken ...

Thanks a for reporting this problem; It is fixed now.
http://www.niktech.com/manik-elf-toolchain.tar.gz

>> are you going to release the HDL sources?

We currently have no plans of releasing the HDL sources.
We do have plans to add more open source Cores to the package.

>> are you planning to port uClinux for MANIK?

Yes we have plans of porting Operating Systems to the processor;
uC/OS and uClinux seem to be good choices for a CPU like
MANIK.

Sandeep

--
-----------------------------------------------------------------
http://www.niktech.com
Specializing in FPGA based Processors
-----------------------------------------------------------------

"Jaime Andrés Aranguren Cardona" <[email protected]> writes:
> I guess it would fit into an Spartan-3 XC3S200, right? I'd like to test it
> with this FPGA. How can we do that? (I see that there are synthesized
> netlists on Niktech's website).

Why bother? There are comparable cores available that fit in an XC3S200,
and for which you get HDL source code, not just a netlist. I completely
fail to understand what MANIK brings to the party.

"Jon Beniston" <[email protected]> wrote in message
news:[email protected] m...
> "Antti Lukats" <[email protected]> wrote in message
news:<ckrbh1$kn7$04$[email protected]>...
> > > Netlists, Documentation and Development tools can be downloaded from
> > > http://www.niktech.com.
> >
> > 1) are you going to release the HDL sources?
>
> Similarly to you Antti, are you going to be releasing the HDL source for
NIOX?
>
> Cheers,
> Jon

Hi Jon,

lets put it that way, NIOX sources are obtainable

Antti

> I completely fail to understand what MANIK brings to the party.

An excellent question ; at the risk of staring a flame war I will say
"code size". Now, does "code size" matter ? It depends on a lot of
factors, but given the small amounts of BLOCKRAMs available
on a FPGA, it would matter in "most" cases, especially if the
code size saving is substantial.

I have done a comparison with MIPS and to eliminate different libraries
I have compared the sizes of the individual object files. Note the MANIK
tool chain merges text and data section into text section. In both cases
the sizes of the uninitialized global variables are not listed (size
command does not display it).

-----------------------------------------------------------------------
Dhrystone (complied with -O2)
MIPS
text data bss dec hex filename
1363 26 0 1389 56d dhry21a.o
620 0 0 620 26c dhry21b.o

MANIK
text data bss dec hex filename
919 0 0 919 397 dhry21a.o
416 0 0 416 1a0 dhry21b.o

While code size is the strongest suite of MANIK; it does have other
goodies; ability to execute multiple instructions simultaneously;
power down mode, built in timer; are just a few of them.

Following is a file by file comparison of a benchmark (099.go) from
the SPEC95 suite (Does not have any uninitialzed globals) . How much
will you save ? Give it a try with the MANIK toolchain .....

-------------------------------------------------------------------------
Files of 099.go (from SPEC95 benchmark)
-------------------------------------------------------------------------

MIPS
text data bss dec hex filename
3170 863 0 4033 fc1 g2.o
7824 0 0 7824 1e90 g22.o
69236 880 0 70116 111e4 g23.o
64318 1440 0 65758 100de g25.o
3448 0 0 3448 d78 g26.o
6804 8 0 6812 1a9c g27a.o
2596 224 0 2820 b04 g27b.o
11976 0 0 11976 2ec8 g28.o
27616 0 0 27616 6be0 g29.o
19600 1100 0 20700 50dc g2eye.o
0 49784 0 49784 c278 g2jlib2.o
7488 12 0 7500 1d4c g2jos.o
2760 0 0 2760 ac8 g2list.o
6803 5260 0 12063 2f1f g2reas.o
12372 0 0 12372 3054 g2s2.o
4730 4 0 4734 127e g2s3.o
29600 14484 0 44084 ac34 g2shp.o


MANIK
text data bss dec hex filename
3258 0 0 3258 cba g2.o
5232 0 0 5232 1470 g22.o
46320 0 0 46320 b4f0 g23.o
42522 0 0 42522 a61a g25.o
2220 0 0 2220 8ac g26.o
4480 0 0 4480 1180 g27a.o
1776 0 0 1776 6f0 g27b.o
7716 0 0 7716 1e24 g28.o
17784 0 0 17784 4578 g29.o
13660 0 0 13660 355c g2eye.o
49784 0 0 49784 c278 g2jlib2.o
4860 0 0 4860 12fc g2jos.o
1928 0 0 1928 788 g2list.o
12064 0 0 12064 2f20 g2reas.o
8268 0 0 8268 204c g2s2.o
3874 0 0 3874 f22 g2s3.o
33712 0 0 33712 83b0 g2shp.o
[
--
-----------------------------------------------------------------
http://www.niktech.com
Specializing in FPGA based Processors
-----------------------------------------------------------------

>Yes we have plans of porting Operating Systems to the processor;
>uC/OS and uClinux seem to be good choices for a CPU like
>MANIK.

Sciopta (the company I work for) should be easyly ported.
(If code-size and speed matters :-)
A reason why I downloaded the GCC :-)
--
42Bastian
Do not email to [email protected], it's a spam-only account :-)
Use <same-name>@epost.de instead !

Eric,

Would you mind to tell me where from?

Regards,

--
Jaime Andrés Aranguren Cardona
[email protected]
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

"Eric Smith" <[email protected]> escribió en el mensaje
news:[email protected]..
> "Jaime Andrés Aranguren Cardona" <[email protected]> writes:
> > I guess it would fit into an Spartan-3 XC3S200, right? I'd like to test
it
> > with this FPGA. How can we do that? (I see that there are synthesized
> > netlists on Niktech's website).
>
> Why bother? There are comparable cores available that fit in an XC3S200,
> and for which you get HDL source code, not just a netlist. I completely
> fail to understand what MANIK brings to the party.

I wrote:
> Why bother? There are comparable cores available that fit in an XC3S200,
> and for which you get HDL source code, not just a netlist.

"Jaime Andrés Aranguren Cardona" <[email protected]> writes:
> Would you mind to tell me where from?

http://www.opencores.org/

"Eric Smith" <[email protected]> wrote in message
news:[email protected]..
> I wrote:
> > Why bother? There are comparable cores available that fit in an
XC3S200,
> > and for which you get HDL source code, not just a netlist.
>
> "Jaime Andrés Aranguren Cardona" <[email protected]> writes:
> > Would you mind to tell me where from?
>
> http://www.opencores.org/

Hi Eric,

opencores is not solution for everything, there are a few cores with full
toolchain, but not so many. OR1K has full GNU toolchain support but its a
real huge ip core, so if you are looking for small cpu core with full GNU
toolchain support ? at opencores ? the answer is there barely is one, if you
want a small CPU with GNU toolchain and SUPPORT? I dont think you find it at
opencores at the moment.

but, I agree, any CPU cores from startup companinies should not be
considered at all if not available in HDL sources. So the MANIK does not
count either as it not available in HDL source.

Still room for another player!

Antti

"Antti Lukats" <[email protected]> writes:
> opencores is not solution for everything, there are a few cores with full
> toolchain, but not so many. OR1K has full GNU toolchain support but its a
> real huge ip core, so if you are looking for small cpu core with full GNU
> toolchain support ? at opencores ? the answer is there barely is one, if you
> want a small CPU with GNU toolchain and SUPPORT?

You don't get support for ANYTHING without paying for it.

But there are multiple cores for which there is a full GNU toolchain.
aeMB (32-bit) and several of the AVR cores (8-bit) come to mind, but
there are other choices.

Eric Smith wrote:
> "Antti Lukats" <[email protected]> writes:
>
>>opencores is not solution for everything, there are a few cores with full
>>toolchain, but not so many. OR1K has full GNU toolchain support but its a
>>real huge ip core, so if you are looking for small cpu core with full GNU
>>toolchain support ? at opencores ? the answer is there barely is one, if you
>>want a small CPU with GNU toolchain and SUPPORT?
>
>
> You don't get support for ANYTHING without paying for it.

And conversely, we've all paid for support and not
gotten anything at times (:

> But there are multiple cores for which there is a full GNU toolchain.
> aeMB (32-bit) and several of the AVR cores (8-bit) come to mind, but
> there are other choices.

Jim Stewart <[email protected]> writes:
> And conversely, we've all paid for support and not
> gotten anything at times (:

There's a saying that "you get what you pay for". What they don't
normally bother to tell you is that that is the *best* case.

Hi Antti,

Antti Lukats wrote:
> "Jon Beniston" <[email protected]> wrote in message

>>"Antti Lukats" <[email protected]> wrote in message

>>>1) are you going to release the HDL sources?

>>Similarly to you Antti, are you going to be releasing the HDL source for
> NIOX?

> lets put it that way, NIOX sources are obtainable

What does that mean?

You earlier wrote: "NIOS-II verilog also exists, but it will not be GPL
"

So, either it's available, or it's not. What's it to be?

John

<is about Anttis NIOS clone>
>> So, either it's available, or it's not. What's it to be?
>>
>> John
> http://ipcores.openchip.org
>

Hi Antti,

isn't 'Please ask for pricing' on a website with 'openchip' in the domain name a little bit
controversial ;-)
I know, providing the source code of a processor for free download to be 'open-source'
AND trying to sell the design is an unusual and problematic (or better no) business model.

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/

"John Williams" <[email protected]> wrote in message
news:cl9cas$gf8$[email protected]..
> Hi Antti,
>
> Antti Lukats wrote:
> > "Jon Beniston" <[email protected]> wrote in message
>
> >>"Antti Lukats" <[email protected]> wrote in message
>
> >>>1) are you going to release the HDL sources?
>
> >>Similarly to you Antti, are you going to be releasing the HDL source for
> > NIOX?
>
> > lets put it that way, NIOX sources are obtainable
>
> What does that mean?
>
> You earlier wrote: "NIOS-II verilog also exists, but it will not be GPL
> "
>
> So, either it's available, or it's not. What's it to be?
>
> John
http://ipcores.openchip.org

Antti

"Martin Schoeberl" <[email protected]> wrote in message
news:fX5ed.30157$[email protected]..
> <is about Anttis NIOS clone>
> >> So, either it's available, or it's not. What's it to be?
> >>
> >> John
> > http://ipcores.openchip.org
> >
>
> Hi Antti,
>
> isn't 'Please ask for pricing' on a website with 'openchip' in the domain
name a little bit
> controversial ;-)
> I know, providing the source code of a processor for free download to be
'open-source'
> AND trying to sell the design is an unusual and problematic (or better no)
business model.
>
> Martin

Hi Martin,

"open" doesnt have to mean that everything is free.

For all designs and ip cores copyrighted to openchip - the sources are
available, but not necessarily for free.

Also in my opinion several "open source licenses" are in many ways more
restrictive then commercial licenses.

So as example if I would make NIOX GPL it would prevent you using it in
commercial products without re-releasing the modified source and possible
your own ip as well. If you OTOH "buy" NIOX source code you are not bound to
such restrictions and can make profit anyway you like.

One of most problem with www.opencores.com is that the regulations there
make it real hard for the developers to benefit.

So openchip licensing is more flexible - make money and what more important
allow others to make money too. So the others will have more time to play
with their children (or have fun the way the like it).

Yes I have put "ask for pricing" - but did you ask? Maybe the price is $1
for you? Notice I might sell it for $1 to Martin - but under specially
taylored license. All you have to do is ask

Buying (if that option is available) is in many cases better and cheaper
than "getting for free". If you pay for something you are entitled to some
supprot (or money back) - getting for free means usually no support (and
nobody pays for your time you wasted because of lack of support).

Also selling something "enforce" more feedback then giving away for free.
And without feedback its really hard to find bugs and improve a product. As
example my MicroBlaze/uCLinux free version has been available for downloads
for several weeks, and there is ZERO feedback yet. Nothing.

Antti

"Antti Lukats" <[email protected]> wrote in message
news:clb407$fuf$02$[email protected]..
> "Martin Schoeberl" <[email protected]> wrote in message
> news:fX5ed.30157$[email protected]..
> > <is about Anttis NIOS clone>
> > >> So, either it's available, or it's not. What's it to be?
> > >>
> > >> John
> > > http://ipcores.openchip.org
> > >
> >
> > Hi Antti,
> >
> > isn't 'Please ask for pricing' on a website with 'openchip' in the
domain
> name a little bit
> > controversial ;-)
> > I know, providing the source code of a processor for free download to be
> 'open-source'
> > AND trying to sell the design is an unusual and problematic (or better
no)
> business model.
> >
> > Martin
>
> Hi Martin,
>
> "open" doesnt have to mean that everything is free.

"Open" doesn't mean it has to be zero cost.

However, "open source" generally means "free as in speech" (I know there are
differences between "open source software" and "free software"). That means
you can happily charge me for the core - but I can then modifiy it if I
want, and pass it on to others at whatever cost (if any) I want. If you
have trademarked the name, you can stop me using that name - I'd have to
find a new one for "my" version.

"Open" designs are ones where all information is freely available, and
anyone is free to implement them. The Sparc architecture is open - anyone
can make a new Sparc core (with a different name, of course), while
particular implementations are closed. The x86 architecture is propritery,
or "closed" - you need a license to be able to make an implementation.

>
> For all designs and ip cores copyrighted to openchip - the sources are
> available, but not necessarily for free.

That's fair enough, and a perfectly valid arrangement, and may well be the
best for both you and your customers. But it's not "open".

>
> Also in my opinion several "open source licenses" are in many ways more
> restrictive then commercial licenses.
>

That's certainly true - the GPL has very specific restrictions. That's why
people often use BSD-style licenses or modified GPL for such things as FPGA
cores or embedded software components.

> So as example if I would make NIOX GPL it would prevent you using it in
> commercial products without re-releasing the modified source and possible
> your own ip as well. If you OTOH "buy" NIOX source code you are not bound
to
> such restrictions and can make profit anyway you like.
>
> One of most problem with www.opencores.com is that the regulations there
> make it real hard for the developers to benefit.
>

That's why many of the cores have BSD-style licenses. It is also quite
possible to contact the authors and arrange another license if you want.

In fact, the GPL can give you the best of both worlds here - people can
download your core and use it, but are mostly restricted to non-commercial
work (i.e., their own work must also be GPL'ed). Great for hobby use,
accademica, and prototyping and experimenting. Companies looking to use it
commercially can try it out, then buy a licence before shipping. And you
get to call it "open" without people complaining.

> So openchip licensing is more flexible - make money and what more
important
> allow others to make money too. So the others will have more time to play
> with their children (or have fun the way the like it).
>
> Yes I have put "ask for pricing" - but did you ask? Maybe the price is $1
> for you? Notice I might sell it for $1 to Martin - but under specially
> taylored license. All you have to do is ask
>
> Buying (if that option is available) is in many cases better and cheaper
> than "getting for free". If you pay for something you are entitled to
some
> supprot (or money back) - getting for free means usually no support (and
> nobody pays for your time you wasted because of lack of support).
>

That is, of course, incorrect as a generalisation - as anyone who has tried
to get support for commercial products will realise. The quality of the
product, the quality of support, and the price you paid are seldom related.
I've had lots of experiance of getting good, fast and helpful feedback from
open source developers who have received nothing from me (except perhaps
some praise, or helpful feedback), and I've contacted commercial support
lines to find I know more about their products than they do. Of course, the
opposite occurs too - there is no rule.

Selling on the basis of "support" relies on reputation, not the price you
charge. Many people charge seperately for support and the product itself -
perhaps even giving the product away as fully open source (such as many
linux distributers). Whatever model works for you is fine - but it is
unreasonable to claim that since you charge money your support will
automatically be better.

> Also selling something "enforce" more feedback then giving away for free.
> And without feedback its really hard to find bugs and improve a product.
As
> example my MicroBlaze/uCLinux free version has been available for
downloads
> for several weeks, and there is ZERO feedback yet. Nothing.

Perhaps everyone thinks it works so well there is no need :-) ? For
something like that, however, there will not be many people trying it (do
many people know about it?), and people are likely to blame themselves for
problems rather than passing information back to you. Getting an active
community around a product can be difficult - I know how frustrating it can
be to release something as open source and get no reaction.


I wish you luck with your processor. As I said, I don't think anyone has
problems with your choice of licensing and pricing (although I suspect a GPL
version, perhaps less powerful or less optomised, and a commercial version
would help you get customers and feedback faster). It's just that "open"
means far more than "you get the source with the product" (even the Windows
source is available).

David


>
> Antti
>
>

"David Brown" <[email protected]> wrote in message
news:clia4n$pd1$[email protected]..
>
[snip long post deleted, check the thread]

> I wish you luck with your processor. As I said, I don't think anyone has
> problems with your choice of licensing and pricing (although I suspect a
GPL
> version, perhaps less powerful or less optomised, and a commercial version
> would help you get customers and feedback faster). It's just that "open"
> means far more than "you get the source with the product" (even the
Windows
> source is available).
>
> David

Thanks David - I wasnt expecting so understanding comments - yes most of
your points are valid - the name openchip - well its just is the name, and
when choosing the name I hade no intentions to make all openchip products
"open" in that sense that all the ip would would be freely downloadable. The
community isnt ready for that yet. I have made free software in the past
(search for PIP02 on the google as example) lot of my free (for non
commercial) sw has been used to create commercial bundles sold for profit,
no one ever contacted me back regarding obtaining the commercial use license
at all. So I have learned some lessons.

Regarding feedback, again I agree 100% with you it is actually amazing how
little feedback comes back. This is true for free products and also for
commerical products. If you have a commercial product, and you get no
feedback, it doesnt mean that the customers are happy, not at all. They just
do not give feedback.

The uCLinux platform simulator is downloadable for free, but requires
registration to the forum (similar to the uCLinux/NIOS required forum
registration at niosforum) - so I know there are at least 25 people
registered to gain access to the download. I would have hope maybe 1
feedback, but havent yet received any. In the meanwhile the simulator is
booting (almost completly) not only microblaze uclinux but also NIOS II
uclinux, but I will have to decide the licensing of it. This simulator is
written from scratch fully avoiding any GPLed source code useage. Except
that the HDL co-simulation uses iverilog so the the hdl sim is GPLed
(also the VPI module for what I will provide the source code freely of
course).

Thanks again for nice long commentary David!

Antti
PS testing aeMB and writing NIOX did give me many new knowlege about
assembly programming for microblaze/nios architectural differencies etc, so
I have gained something already.

Quiz:
Q: How is it possible that NIOS/e is so small ?
A: By using 6 cycle microsequencing and 16 bit ALU and internal datapaths.

The answer is my bet, but I am pretty sure that the way it is. NIOS II/e
uses 6 clock per cycle, those are requiered to fetch the operands in 16 bit
chunks and write them back in 16 bit chunks. 6 clocks. Nice idea

"David Brown" <[email protected]> writes:
> The x86 architecture is propritery,
> or "closed" - you need a license to be able to make an implementation.

Since when?

Are you asserting that the IIT, Nexgen, Rise, and Transmeta x86 designs
were licensed by Intel?

"Eric Smith" <[email protected]> wrote in message
news:[email protected]..
> "David Brown" <[email protected]> writes:
> > The x86 architecture is propritery,
> > or "closed" - you need a license to be able to make an implementation.
>
> Since when?
>
> Are you asserting that the IIT, Nexgen, Rise, and Transmeta x86 designs
> were licensed by Intel?

I don't know the details, nor how much needs licenses, but I believe AMD and
Intel have cross-licensing deals on their x86 architectures. I also
remember hearing about Intel suing companies for making one type of x86 chip
when they only had a license for a different generation of x86 designs. At
least some of the licenses Intel has provided have not been by choice, but
by court order.

However, it could be that all this refers to something other than the x86
architecture itself (maybe something to do with the implementation, or
arrangements of special registers, or whatever), and the x86 is not
proprietry. In that case, pick a different example, like ARM.

"Antti Lukats" <[email protected]> wrote in message news:<clb407$fuf$02$[email protected]>...
> ...
> So as example if I would make NIOX GPL it would prevent you using it in
> commercial products without re-releasing the modified source and possible
> your own ip as well. If you OTOH "buy" NIOX source code you are not bound to
> such restrictions and can make profit anyway you like.

GPL release does not preclude separate ("dual") commercial licensing.

>
> ...
>
> Also selling something "enforce" more feedback then giving away for free.

It is possible that customers are likely to be more annoyed by bugs in
a product they paid for, and have, by definition, been denied the
means to fix themselves.

In my experience there is no correlation between:
* shrinkwrap purchase and product quality
* shrinkwrap purchase and willingness or ability of developer to
listen. (It can be easily shown that beyond a certain modest size, a
software company is far less able to respond to customer issues than a
small, nimble individual or team with a reputation investment. In
particular, if the vendor is a monopoly, the battle is already lost.)
* shrinkwrap purchase and likelihood of customer to report bugs. (In
fact, the shrinkwrap customer is highly likely to be primed with
dismay and pessimism on approaching a commercial vendor: case in
point, Adobe.)
* probability of customer *fixing* bugs they find in shrinkwrap
purchase: Zero.

> And without feedback its really hard to find bugs and improve a product. As
> example my MicroBlaze/uCLinux free version has been available for downloads
> for several weeks, and there is ZERO feedback yet. Nothing.

Either nobody wants it, or they're happy with it as it is. I hope the
latter is the true explanation :-)

--Toby

>
> Antti