EDK : FSL macros defined by Xilinx are wrong

[Eric Crabill]

Hi,

I hope someone will correct me if I'm wrong on this...

For Xilinx FPGAs, all SLICE flip flops (and some other
synchronous elements, too, like BlockRAM output registers,
IOB flops, etc...) are initialized to a known state at
the end of configuration by an internal, chip-wide async
reset called GSR, or "global set/reset". It also happens
to be the case that there's another signal, GTS, or "global
three-state" that forces all I/O to be three-stated during
configuration. These signals are not "visible" in the FPGA
Editor view of the part at any place other than the STARTUP
component.

If you instantiate specific primitives, like FDC or FDP,
you are also making a request on how you want these to be
initialized by GSR (regardless of your use of an additional,
async user reset). FDC initializes to 0. FDP initializes
to 1.

If you code stuff like:

reg [1:0] myflop;

always @(posedge clk or posedge init)
begin
if (init) myflop <= 2'b10;
else myflop <= two_bit_whatever;
end

You have just inferred an FDC and and FDP, both of which are
initialized by GSR at configuration, and both of which also
have an asynchronous user control called "init".

For a more detailed look, try implementing the code above,
and then make a back-annotated netlist using netgen and you
will see that the simulation model has the init signal
logically OR'ed with a signal called GSR, located in the
glbl.v file that you are supposed to use during simulation
of back-annotated designs.

If you code stuff like:

reg [1:0] myotherflop;

always @(posedge clk) myotherflop <= two_bit_whatever;

You have just inferred two generic D flip flops, probably
FD components, and even though you don't have an asynchronous
user control on this, it will get initialized once at the
end of configuration, by the GSR signal. I believe FD will
default to 0, unless you specify otherwise.

If you repeat the exercise using netgen, you will see that
GSR is still used as an async reset, but there's no other
signal OR'ed with it.

The synthesis often moves inverters around, and many signals,
including ones through FF's, are actually the inverse of the
expected signal.

I would hope anyone doing this transformation would also change
the "initialization state" of the flip flop when they also change
it's sense -- otherwise the transformation is not really
transparent... (I would argue it's wrong)

Eric

 

[Peter Alfke]

While we are on the subject of asynchronous clear or initialization at the
end of configuration:
The problem is the non-synchronous and non-simultaneous timing of the
release of this reset/preset signal, while the user clock is already
running. (Sorry for the convoluted sentence).
That's where state machines can get screwed up: the asynchronous (p)reset
might linger a little longer on one flip-flop than on the other, and the
user clock might occur during this timing difference. Bad luck!
That's why smart designers identify such state machines and give them an
additional, longer and synchronous reset input. An SRL16 is a convenient
tool to control this delay.
This subject has been covered here many times, but it bears repeatung...
Peter Alfke

From: Eric Crabill <eric.crabill@xilinx.com
Organization: Xilinx, Inc.
Newsgroups: comp.arch.fpga
Date: Thu, 21 Oct 2004 10:59:36 -0700
To: glen herrmannsfeldt <gah@ugcs.caltech.edu
Subject: Re: Async reset


Hi,

I hope someone will correct me if I'm wrong on this...

For Xilinx FPGAs, all SLICE flip flops (and some other
synchronous elements, too, like BlockRAM output registers,
IOB flops, etc...) are initialized to a known state at
the end of configuration by an internal, chip-wide async
reset called GSR, or "global set/reset". It also happens
to be the case that there's another signal, GTS, or "global
three-state" that forces all I/O to be three-stated during
configuration. These signals are not "visible" in the FPGA
Editor view of the part at any place other than the STARTUP
component.

If you instantiate specific primitives, like FDC or FDP,
you are also making a request on how you want these to be
initialized by GSR (regardless of your use of an additional,
async user reset). FDC initializes to 0. FDP initializes
to 1.

If you code stuff like:

reg [1:0] myflop;

always @(posedge clk or posedge init)
begin
if (init) myflop <= 2'b10;
else myflop <= two_bit_whatever;
end

You have just inferred an FDC and and FDP, both of which are
initialized by GSR at configuration, and both of which also
have an asynchronous user control called "init".

For a more detailed look, try implementing the code above,
and then make a back-annotated netlist using netgen and you
will see that the simulation model has the init signal
logically OR'ed with a signal called GSR, located in the
glbl.v file that you are supposed to use during simulation
of back-annotated designs.

If you code stuff like:

reg [1:0] myotherflop;

always @(posedge clk) myotherflop <= two_bit_whatever;

You have just inferred two generic D flip flops, probably
FD components, and even though you don't have an asynchronous
user control on this, it will get initialized once at the
end of configuration, by the GSR signal. I believe FD will
default to 0, unless you specify otherwise.

If you repeat the exercise using netgen, you will see that
GSR is still used as an async reset, but there's no other
signal OR'ed with it.

The synthesis often moves inverters around, and many signals,
including ones through FF's, are actually the inverse of the
expected signal.

I would hope anyone doing this transformation would also change
the "initialization state" of the flip flop when they also change
it's sense -- otherwise the transformation is not really
transparent... (I would argue it's wrong)

Eric

 

[Mikeandmax]

yet another job outsourced

 

[Peter Alfke]

Another tidbit:
When Xilinx says reset or preset, we really mean that we force the flip-flop
into one state or the other. None of that trickery with virtual preset,
implemented by reset plus inverting D and Q (which would affect timing).
Peter Alfke

From: Peter Alfke <peter@xilinx.com
Organization: Xilinx,Inc
Newsgroups: comp.arch.fpga
Date: Thu, 21 Oct 2004 11:48:22 -0700
Subject: Re: Async reset

While we are on the subject of asynchronous clear or initialization at the
end of configuration:
The problem is the non-synchronous and non-simultaneous timing of the
release of this reset/preset signal, while the user clock is already
running. (Sorry for the convoluted sentence).
That's where state machines can get screwed up: the asynchronous (p)reset
might linger a little longer on one flip-flop than on the other, and the
user clock might occur during this timing difference. Bad luck!
That's why smart designers identify such state machines and give them an
additional, longer and synchronous reset input. An SRL16 is a convenient
tool to control this delay.
This subject has been covered here many times, but it bears repeatung...
Peter Alfke

From: Eric Crabill <eric.crabill@xilinx.com
Organization: Xilinx, Inc.
Newsgroups: comp.arch.fpga
Date: Thu, 21 Oct 2004 10:59:36 -0700
To: glen herrmannsfeldt <gah@ugcs.caltech.edu
Subject: Re: Async reset


Hi,

I hope someone will correct me if I'm wrong on this...

For Xilinx FPGAs, all SLICE flip flops (and some other
synchronous elements, too, like BlockRAM output registers,
IOB flops, etc...) are initialized to a known state at
the end of configuration by an internal, chip-wide async
reset called GSR, or "global set/reset". It also happens
to be the case that there's another signal, GTS, or "global
three-state" that forces all I/O to be three-stated during
configuration. These signals are not "visible" in the FPGA
Editor view of the part at any place other than the STARTUP
component.

If you instantiate specific primitives, like FDC or FDP,
you are also making a request on how you want these to be
initialized by GSR (regardless of your use of an additional,
async user reset). FDC initializes to 0. FDP initializes
to 1.

If you code stuff like:

reg [1:0] myflop;

always @(posedge clk or posedge init)
begin
if (init) myflop <= 2'b10;
else myflop <= two_bit_whatever;
end

You have just inferred an FDC and and FDP, both of which are
initialized by GSR at configuration, and both of which also
have an asynchronous user control called "init".

For a more detailed look, try implementing the code above,
and then make a back-annotated netlist using netgen and you
will see that the simulation model has the init signal
logically OR'ed with a signal called GSR, located in the
glbl.v file that you are supposed to use during simulation
of back-annotated designs.

If you code stuff like:

reg [1:0] myotherflop;

always @(posedge clk) myotherflop <= two_bit_whatever;

You have just inferred two generic D flip flops, probably
FD components, and even though you don't have an asynchronous
user control on this, it will get initialized once at the
end of configuration, by the GSR signal. I believe FD will
default to 0, unless you specify otherwise.

If you repeat the exercise using netgen, you will see that
GSR is still used as an async reset, but there's no other
signal OR'ed with it.

The synthesis often moves inverters around, and many signals,
including ones through FF's, are actually the inverse of the
expected signal.

I would hope anyone doing this transformation would also change
the "initialization state" of the flip flop when they also change
it's sense -- otherwise the transformation is not really
transparent... (I would argue it's wrong)

Eric

 

[Jim Granville]

Peter Alfke wrote:

While we are on the subject of asynchronous clear or initialization at the
end of configuration:
The problem is the non-synchronous and non-simultaneous timing of the
release of this reset/preset signal, while the user clock is already
running. (Sorry for the convoluted sentence).
That's where state machines can get screwed up: the asynchronous (p)reset
might linger a little longer on one flip-flop than on the other, and the
user clock might occur during this timing difference. Bad luck!
That's why smart designers identify such state machines and give them an
additional, longer and synchronous reset input. An SRL16 is a convenient
tool to control this delay.
This subject has been covered here many times, but it bears repeatung...

Perhaps the tools need a [AsyncReset with SyncRelease] option/tickbox,
that novice users (and others) can enable ?
For years in our uC products, we have used a tiny (6 byte) library that
clears all user memory at power on.
Saves a ton of grey hairs, and chasing erratic startup phantoms, plus
eliminates chunks of InitVar code overhead.

-jg

 

[rickman]

Peter Alfke wrote:

Another tidbit:
When Xilinx says reset or preset, we really mean that we force the flip-flop
into one state or the other. None of that trickery with virtual preset,
implemented by reset plus inverting D and Q (which would affect timing).

But that does not mean that the tools won't invert the sense of a FF
when they move inverters around.

--

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

 

[Peter Alfke]

From: Jim Granville <no.spam@designtools.co.nz
Organization: TelstraClear
Newsgroups: comp.arch.fpga
Date: Fri, 22 Oct 2004 10:40:19 +1300
Subject: Re: Async reset

Perhaps the tools need a [AsyncReset with SyncRelease] option/tickbox,
that novice users (and others) can enable ?
For years in our uC products, we have used a tiny (6 byte) library that
clears all user memory at power on.
Saves a ton of grey hairs, and chasing erratic startup phantoms, plus
eliminates chunks of InitVar code overhead.

-jg

Nice idea, but you still have to define the physical area to be covered. If

you instantiate several independent such blocks, they might not be
macro-syncheronous ( I mean: synchronous to the clock, but not necessarily
to the same clock tick). And within the area covered, you cannot tolerate a
control-signal delay longer than one clock period.
All that makes it difficult to provide one universal library element that
covers all situations and all speeds...
Peter Alfke

 

[John Williams]

Hi Antti,

Antti Lukats wrote:

"Jon Beniston" <jon@beniston.com> wrote in message

"Antti Lukats" <antti@case2000.com> 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

 

[Jim Granville]

Peter Alfke wrote:

From: Jim Granville <no.spam@designtools.co.nz
Organization: TelstraClear
Newsgroups: comp.arch.fpga
Date: Fri, 22 Oct 2004 10:40:19 +1300
Subject: Re: Async reset

Perhaps the tools need a [AsyncReset with SyncRelease] option/tickbox,
that novice users (and others) can enable ?
For years in our uC products, we have used a tiny (6 byte) library that
clears all user memory at power on.
Saves a ton of grey hairs, and chasing erratic startup phantoms, plus
eliminates chunks of InitVar code overhead.

-jg


Nice idea, but you still have to define the physical area to be covered.

Understood, you clearly would need to specify the covered elements.
Tho the tools could allow "all for that clock domain", and then tell the
user the cost of that ?

If you instantiate several independent such blocks, they might not be
macro-syncheronous ( I mean: synchronous to the clock, but not necessarily
to the same clock tick). And within the area covered, you cannot tolerate a
control-signal delay longer than one clock period.

Understood, but at these extremes, the tools should/could catch and
warn on this ?

All that makes it difficult to provide one universal library element that
covers all situations and all speeds...

Can you give a feel, via real examples, for when the control signal
delay on a "Auto SyncRelease" reset, might end up longer than one clock
period ?


-jg

 

[Martin Schoeberl]

<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/

 

[owl eyes]

do they have small/sharp butts?

 

[Antti Lukats]

"John Williams" <jwilliams@itee.uq.edu.au> wrote in message
news:cl9cas$gf8$1@bunyip.cc.uq.edu.au...

Hi Antti,

Antti Lukats wrote:
"Jon Beniston" <jon@beniston.com> wrote in message

"Antti Lukats" <antti@case2000.com> 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

 

[Antti Lukats]

"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
news:fX5ed.30157$z77.27796@news.chello.at...

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

 

[David Brown]

"Antti Lukats" <antti@case2000.com> wrote in message
news:clb407$fuf$02$1@news.t-online.com...

"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
news:fX5ed.30157$z77.27796@news.chello.at...
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

 

[Antti Lukats]

"smu" <pas@d.adresse> wrote in message
news:clih72$b8f$1@s5.feed.news.oleane.net...

Hello,

I am developing a FPGAs (BGA case) board.

Is it possible to check the connections between two pins on two
different FPGAs with the Boundary scan?

If so, exists there a tool that is able to make this kind of test using
the board schematic?

Thank you in advance.

smu

yes, checking connections is defenetly possible. Also many other things,
like programming non JTAG memories and other non JTAG devices if those are
connected to FPGAs or devices with JTAG boundary scan.

check out
www.jtag,com

I guess pretty much expensive tools.

if you dont mind some programming yourself I have an windows application
that uses 2 PLDs in JTAG chain to program an FPGA (not on boundary scan!)
and then via that FPGA an parallel Flash memory. This application could be
modified to test your custom board. The schematics extraction would be
manual, or if you can import netlist from sch a netlist reader could be
added to provide the link to your schematics.

Antti

 

[Antti Lukats]

"David Brown" <david@no.westcontrol.spam.com> wrote in message
news:clia4n$pd1$1@news.netpower.no...

[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

 

[Eric Smith]

"David Brown" <david@no.westcontrol.spam.com> 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?

 

[David Brown]

"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qh3c01co68.fsf@ruckus.brouhaha.com...

"David Brown" <david@no.westcontrol.spam.com> 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.

 

[Toby Thain]

"Antti Lukats" <antti@case2000.com> wrote in message news:<clb407$fuf$02$1@news.t-online.com>...

...
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

 

[Tom Seim]

smu <pas@d.adresse> wrote in message news:<clih72$b8f$1@s5.feed.news.oleane.net>...

Hello,

I am developing a FPGAs (BGA case) board.

Is it possible to check the connections between two pins on two
different FPGAs with the Boundary scan?

If so, exists there a tool that is able to make this kind of test using
the board schematic?

Thank you in advance.

smu

Intel has an apnote on using jtag scanning with the 386ex. Includes a
dos driver and schematic - hw attaches to parallel printer port.