EDK : FSL macros defined by Xilinx are wrong

rickman wrote:
You have posted your concerns and have gotten some responses. The
resonse from X seems to be a lot like the way they responded to the
data sheet LC count issue in the past. You are not likely to get
anything further out of them at this point. As you post more you just
feed the trolls (or become one).
Click to expand...
yep ... the several threads have been useful to discuss difficult
problems
that Reconfigurable Computing faces with regards to strict IP
limitations
these folks require, and effectively prohibt open source development
with.

Calling them to task for heavily using open source in their products,
while
agressively prohibting open source development for their product line
will
no doubt hit nearves that may over time lead all the FPGA companies to
actually open up to a reasonable degree and reap the rewards of
extensive
open source development which supports their all sales and greatly
enhances
their product offerings.

Those that leach off open source, while completely blocking open source
development for their products, need to be called on the carpet for
that,
and probably regularly till they get the hint that open source is a TWO
way
relationship -- they need to give as much IP as they take.
 
"hutzelbutz" <joachim.becker@imtek.uni-freiburg.de> writes:

I don't know enough about multi-processor load distribution in Linux,
but this behavior is reproducable. Could it be that those 4 minutes
come from the time, the OS needs to find out that one process should be
switched to the other CPU???
Click to expand...
No, at least process migration should not matter. Maybe they have a race
condition which doesn't appear in the sequential single-CPU case.

I would be curious to hear the experts about this topic!
Click to expand...
Simply do a "strace -p <pid>" and you will see what is going on at the
syscall-level. Most of the time it is also possible to start the program directly
with "strace -f <program>", but it can have problems with catching forked threads.


BTW: Haven't yet used 8.1 myself, but I suspect an issue either with thread
handling (mutexes, etc.) or some name resolution (for whatever cause they need
it).

--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
 
On Thu, 26 Jan 2006 10:04:40 -0000, "Symon" <symon_brewer@hotmail.com>
wrote:

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:43d897a9$1@clear.net.nz...
Kevin Morris wrote:
I'm finishing up an FPGA Journal article called "Stop. Go. Yield. -
Dude! Where's my Chip?"

Hmm.. Not a title that travels internationally very well...
-jg

Hi Jim,
Not sure it even travels out of CA! But I like it. I can see Jeff Bridges
out of "The Big Lebowski" waiting for FPGAs.
Maude Lebowski: What do you do for recreation?
The Dude: Oh, the usual. I bowl. Drive around. Wait for V4 MGTs. The
occasional acid flashback.
Click to expand...
Or maybe John Goodman?

Walter: I can get you a V4 by 3 o'clock this afternoon... with MGTs.

Bob Perlman
Cambrian Design Works
 
Bob Perlman wrote:
On Thu, 26 Jan 2006 10:04:40 -0000, "Symon" <symon_brewer@hotmail.com
wrote:

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:43d897a9$1@clear.net.nz...
Kevin Morris wrote:
I'm finishing up an FPGA Journal article called "Stop. Go. Yield. -
Dude! Where's my Chip?"

Hmm.. Not a title that travels internationally very well...
-jg

Hi Jim,
Not sure it even travels out of CA! But I like it. I can see Jeff Bridges
out of "The Big Lebowski" waiting for FPGAs.
Maude Lebowski: What do you do for recreation?
The Dude: Oh, the usual. I bowl. Drive around. Wait for V4 MGTs. The
occasional acid flashback.

Or maybe John Goodman?

Walter: I can get you a V4 by 3 o'clock this afternoon... with MGTs.

Bob Perlman
Cambrian Design Works
Click to expand...
This thread does not abide.

-a
 
All,

It is unfair to the university(ies) or school(s) involved, and also
unfair to the company(ies) involved to continue with these allegations.

You may be harming the student(s), professor(s) and potentially the
company(ies) involved.

We sponsor research, and we have many interns. We contribute to many
schools and universities a substantial amount of products and software.

We do not sponsor research that gives away our intellectual property.

We expect our licenses, IP, and rights to be respected.

Thank you,

Austin
 
Manuel Bessler wrote:
A colleague and I have adapted the pci32tlite_oc core from
opencores.org to run on raggedstone1.
I've also written a Linux driver for it.
Both available here:
http://projects.varxec.net/doku.php/raggedstone1
Click to expand...
Outstanding!
 
Austin Lesea wrote:
We do not sponsor research that gives away our intellectual property.

We expect our licenses, IP, and rights to be respected.
Click to expand...
I agree, more than you might realize. Letting open source projects
proceed which
violate your IP is very poor management, both on the Xilinx side, and
on the
educational side. You might have noticed that I've also very clearly
stated that
open source should not violate Xilinx IP either.

It's more than obvious from these discussion that a very large portion
of your
user community in this forum clearly does not understand the extent
that
Xilinx wishes to protect it's IP, and what is, and is not acceptable
disclosure
outside the very restrictive NDA that is part of the ISE (and all
Xilinx) software.

I believe it's quiet fair to critize Xilinx for it's heavy use of open
source software,
while locking all access to it's ISE tool chain with strict NDA. That
violates the
vary rationale behind the creation of GPL software that you benefit
from.

But that aside, the question remains, just what, if any, legal
interfaces may open
source software use to augment the IDE tool chain? The strictest
reading of the
license and NDA is clear ... NONE. Since Xilinx stopped that JHDLBits
project
from releasing, after many very public months of work, it's only fair
to ask that
Xilinx reconsider it's NDA boundries and consider that open source
development
may well greatly enhance the Xilinx product offerings over the next
several years
in ways that are difficult to fully describe today.

If the official answer in absolutely none, as the terms of the current
license require,
that is fine ... and I will clearly state so in the FpgaC project and
remove all Xilinx
interfaces so Xilinx IP rights are not violated.
 
There was a 242 ohm resistor to limit the current into PROG_B since,
the microcontroller is at 5V and PROG_B has to be at VCCAUX(2.5V).

I tried to remove the resistor and connected the PROG_B to the
microncontroller I/O. The FPGA still would not reset when the
Microcontroller I/O was held low. The FPGA resets only when I connect a
wire from the PROG_B pin to GND directly.
 
Measure the current in that wire with a milliampere-meter. That gives
you a feel for the strength of the pull-up transistor or resistor that
you must overcome. Also, there is no need for 242 Ohm. You want to
limit the current between 5 V and 2.5V + one diode drop. 100 Ohm would
limit it to max 18 mA, which is fine.
Peter Alfke
 
Measure the current in that wire with a milliampere-meter. That gives
you a feel for the strength of the pull-up transistor or resistor that
you must overcome. Also, there is no need for 242 Ohm. You want to
limit the current between 5 V and 2.5V + one diode drop. 100 Ohm would
limit it to max 18 mA, which is fine.
Peter Alfke
 
Measure the current in that wire with a milliampere-meter. That gives
you a feel for the strength of the pull-up transistor or resistor that
you must overcome. Also, there is no need for 242 Ohm. You want to
limit the current between 5 V and 2.5V + one diode drop. 100 Ohm would
limit it to max 18 mA, which is fine.
Peter Alfke
 
"Yaju Nagaonkar" <yaj_n@hotmail.com> schrieb im Newsbeitrag
news:1138303895.360065.315910@g43g2000cwa.googlegroups.com...
There was a 242 ohm resistor to limit the current into PROG_B since,
the microcontroller is at 5V and PROG_B has to be at VCCAUX(2.5V).

I tried to remove the resistor and connected the PROG_B to the
microncontroller I/O. The FPGA still would not reset when the
Microcontroller I/O was held low. The FPGA resets only when I connect a
wire from the PROG_B pin to GND directly.
Click to expand...
PROG_B is input only on FPGA with virtually no current, so if you nee strong
pulldown
to get it to low level there must be something else pulling it up, not FPGA

Antti
 
Antti Lukats wrote:

and you mr fpga_toys are still an ..... ......
(everyone please fill in the blanks)

Antti

PS I self-censored my previous response to mr fpga_toys.
Click to expand...
Antti,

Time to stop feeding the troll. We've given Mr. FPGA_toys the
information about the hooks he needs to work within the framework of the
xilinx tools. He's obviously not going to be happy unless they decide
to make the entire tool chain open source. I'm not sure I understand
why he is on this crusade.

One doesn't need open source in order to read and write to the XDL
chain. Xilinx encourages third party tools using XDL, as evidenced by
the text at the beginning of an XDL file as well as the statement here
on the news group by Ed McGettigan.

I've come to the conclusion that MrFPGA is not looking for a solution,
rather he is simply trolling. We've offered a solution, but he
continues to use misdirection to try and poke holes in it because it
doesn't meet his desire for totally open source.

He also claims any XDL tools he creates cannot be distributed, which is
bunk. He can't distribute Xilinx tools or IP, but he can certainly
distribute a tool that talks to the xilinx tools through a published
ascii interface that has the permission to use it printed right in every
file generated by it.

I think XDL is a very reasonable approach by Xilinx to offer hooks into
its tools without having to give away the farm. JHDLbits, as I
understand it (not sure where MrFPGA is getting his info, I think he's
making a lot of it up), used information directly supplied by Xilinx
under NDA, and included some of that information in the distribution,
which was a violation of the NDA. XDL is provided under an end user
license agreement, not an NDA. Making a tool to interface to it, from
what I can see does not violate any terms of the EULA, provided you
don't include the xilinx tools with any distributions of your XDL tool.
 
Austin Lesea wrote:
But it seems clear to me, when I read it: the answer is "none."

To imply otherwise is clearly misleading, and could be interpreted as
intentionally causing harm (to Xilinx, or its partners, or its customers).
Click to expand...
Agreed. The Xilinx license prohibits open source development using
any internal ISE documentation or interfaces. I hope this discussion
has been pretty clear to those claiming that XDL and the associated
libraries are fair game for open source development.

A retraction on your part would be completely acceptable, and your
statement that you will immediately cease and desist the use of our
tools against the agreement you signed is most welcome.
Click to expand...
Retract what? You have only confirmed my most damming statements,
that Xilinx freely takes a windfal profit from open source IP while
completely
locking out open source development for FPGA tool chains. Exactly the
corporate behavior that many cry as foul in the open source movement,
and directly counter the founding principles in the Free Software
Foundation.
But that is your right.

My statement was that we would not introduce XDL or other Xilinx
proprietary IP into FpgaC. I will continue to use my Xilinx IP for my
own use, as I suspect most of our developers and users will.

That Xilinx wishes to continue locking open source development out of
ISE and other Xilinx software is your right. I think everyone here is
clear
about that now, and will react accordingly. The big problem is that if
this
many knowledgable people in this forum are clueless about your IP and
the obvious restrictions against open source, then you really need to
work
on getting the word out to avoid another JHDLBits meltdown that will
really
sour Xilinx's reputation in the open source community.
 
Ray Andraka wrote:
One doesn't need open source in order to read and write to the XDL
chain. Xilinx encourages third party tools using XDL, as evidenced by
the text at the beginning of an XDL file as well as the statement here
on the news group by Ed McGettigan.
Click to expand...
The point Ray, is that no one can use XDL in open source tools. The
XIlinx
license restricts all use to Xilinx only product, which specificaly
prevents
including it in a tool that supports multiple vendors. It indirectly
prevents
any public distribution of an XDL tool since you can not enforce the
license provisions.

The FpgaC team CAN NOT INCLUDE XDL in it's open source project.

The request was not to have Xilinx release sources to it's tools. The
request
is for Xilinx to relax this crippling restriction which prohibits open
source
use of XDL and the related library object documentation.
 
John,

I am glad to hear you will comply with our licensing agreement.

As for your other comments, I am silent. It is your right to rant (and
rave).

But not to say anything damaging.

Austin
 
In article <1138308852.296889.243550@g14g2000cwa.googlegroups.com>,
<fpga_toys@yahoo.com> wrote:
Ray Andraka wrote:
One doesn't need open source in order to read and write to the XDL
chain. Xilinx encourages third party tools using XDL, as evidenced by
the text at the beginning of an XDL file as well as the statement here
on the news group by Ed McGettigan.

The point Ray, is that no one can use XDL in open source tools. The
XIlinx
license restricts all use to Xilinx only product, which specificaly
prevents
including it in a tool that supports multiple vendors. It indirectly
prevents
any public distribution of an XDL tool since you can not enforce the
license provisions.

The FpgaC team CAN NOT INCLUDE XDL in it's open source project.

The request was not to have Xilinx release sources to it's tools. The
request
is for Xilinx to relax this crippling restriction which prohibits open
source
use of XDL and the related library object documentation.
Click to expand...
Practically speaking, would anyone really want to use XDL to go to/from other
vendor's FPGAs? I suppose it's possible, but wouldn't it make more sense to
target to another vendor higher up the chain (either at the HDL or EDIF level)
than to try to shoehorn XDL into another vendor's tool flow? Since XDL is
structural and contains placement info which is very
device/architecture-specific it seems like you'd have a heck of a time using it
to target other vendor's architectures.

Phil
 
fpga_toys@yahoo.com wrote:
The big problem is that if
this
many knowledgable people in this forum are clueless about your IP and
the obvious restrictions against open source, then you really need to
work
on getting the word out to avoid another JHDLBits meltdown that will
really
sour Xilinx's reputation in the open source community.
Click to expand...
I have to say that I am pretty clueless about this JHDLBits issue. I
am aware that Xilinx does not support any open source development, but
are you saying they took legal action to shut down an open source
project? Can you provide any details? Was it making use of some of
their software or was the complaint just that it was reverse
engineering the parts?

Can Xilinx stop you from reverse engineering the parts?
 
Antti Lukats wrote:

[... snip ...]
but if you can wait then the Spartan3e kit $149 USD includes also on board
Platform USB Cable (sold standalone for $149!) as free bonus :)
Click to expand...
I just wanted to provide a little more information on this to make it
completely clear about the USB cable supplied with the board.

First, some backround. The Xilinx Platform USB Cable is a
self-contained USB-based programming cable that provides in-system
programming for a variety of Xilinx devices.
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-USB

The Spartan-3E Starter Kit Board includes a standard A-B USB cable.
The cable connects your computer's USB port to the USB slave port on
the board to program the Spartan-3E FPGA, the Platform Flash PROM, or
the on-board CPLDs. Think of it as an "embedded", single-target
version of the Xilinx USB download cable. It is not designed to
program devices that are not already on the board.

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.
 
rickman wrote:
I have to say that I am pretty clueless about this JHDLBits issue.
Click to expand...
see the second post in "So what happened to JHDLBits?"

Can Xilinx stop you from reverse engineering the parts?

From reverse engineering a die, no. From reverse engineering
data contained in an ISE release, Yes ... breach of contract.
Click to expand...

But, I'm not a lawyer as should be assumed, and you should
see your own counsel.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top