Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 95875

Article: 95875
Subject: Re: open source fpga programmer programs
From: "dp" <dp@tgi-sci.com>
Date: 26 Jan 2006 12:44:32 -0800
Links: << >>  << T >>  << A >>
Jerry Coffin wrote:
> Andy Peters wrote:
>
> [ ... ]
>
> > If your software doesn't work, you tell the customer, "download a patch
> > from our web site."
> >
> > If your hardware doesn't work, you tell the customer, "here's your RMA
> > number.  Send the unit back (at your expense) and if it's under
> > warrantee we'll fix it for free; otherwise, it'll cost $$$."
>
> Hmmm...did I somehow end up in the wrong newsgroup? I thought this was
> comp.arch.fpga, where if your hardware doesn't work, you tell the
> customer "download a patch from our web site" -- thus the name _field
> programmable_ gate array. Granted, it's entirely possible to use an
> FPGA in a design that doesn't allow its associated Flash to be updated
> -- but it's certainly a long ways from a given.
>
> --
>     Later,
>     Jerry.

Jerry,

that was right on.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


Article: 95876
Subject: Re: Xilinx ....
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 12:46:43 -0800
Links: << >>  << T >>  << A >>

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

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.

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.


Article: 95877
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 12:54:12 -0800
Links: << >>  << T >>  << A >>

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.


Article: 95878
Subject: Re: So Xilinx, is XDL and related libraries an available open source
From: ptkwt@aracnet.com (Phil Tomson)
Date: 26 Jan 2006 21:06:46 GMT
Links: << >>  << T >>  << A >>
In article <drb64u$nga5@cliff.xsj.xilinx.com>,
Ed McGettigan  <ed.mcgettigan@xilinx.com> wrote:
>fpga_toys@yahoo.com wrote:
>> So the question to Xilinx is, will Xilinx release the NDA restrictions
>> on XDL, and the associated library interfaces so that open source tools
>> can legally target ISE supported FPGAs?
>> 
>> It's pretty clear that most of the regulars here, just assume that XDL
>> and the associated libraries, are an open interface, and think it's ok
>> to ignore the IP restrictions in the ISE license. The legaleze says
>> otherwise.
>> 
>> So how about a clear definative legal statement about what are legal
>> ISE interfaces for open source development.
>> 
>
>I believe that it is established copyright law that SW interface
>specs are not protectable elements although there appear to be
>some gray areas.  This seems to be a good write up from 1997
>http://www.fenwick.com/docstore/publications/IP/IP_Articles/Baystate_Holding.pdf
>
>In any case here is the output of the XDL tool in ISE 8.1i
>
>	unix> xdl -help
>	Release 8.1i - xdl I.24
>	Copyright (c) 1995-2005 Xilinx, Inc.  All rights reserved.
>
>	Xdl is a single tool with 3 fundamental modes:
>
>	  * Report Device Resource Information
>	  * Convert NCD to XDL (ncd2xdl)
>	  * Convert XDL to NCD (xdl2ncd)
>
>	Report generates a report of the physical resources
>	available for a specific part.
>
>	Ncd2xdl reads in an NCD file and generates an ASCII XDL file.
>
>	Xdl2ncd reads in an XDL file and generates an NCD file.
>
>	XDL is also a fully featured Physical Design language that
>	provides direct read and write access to Xilinx's proprietary
>	Native Circuit Description (NCD). This access enables all
>	users to write tools to address their individual FPGA
>	design needs.
>
>The XDL tool explicitly states that you are allowed to create tools
>that use the output of NCD2XDL or tools that create input for XDL2NCD.
>This use of course is restricted to use for Xilinx devices per the
>ISE 8.1i EULA.
>
>If you want to make a tool that writes XDL or a tool that does
>a read/modify/write using XDL for Xilinx devices open source
>go ahead.
>
>We have released application notes that explain how to use XDL to
>modify elements in a design. Some companies like Hier Design created
>and marketed their own tools using this interface.  We liked the
>Hier Design tool so much we bought the company.
>
>I don't know what you mean by "NDA restrictions on XDL".  I can't
>find any reference to a NDA documentation.

Thanks for this clarification.  Looks like we have a green light.

(and thanks for the OP for asking so directly, I was hoping someone from Xilinx 
was reading the other thread)

Phil

Article: 95879
Subject: Re: Xilinx ....
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 26 Jan 2006 13:17:11 -0800
Links: << >>  << T >>  << A >>
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


Article: 95880
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 26 Jan 2006 21:19:19 GMT
Links: << >>  << T >>  << A >>
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.
>

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


Article: 95881
Subject: Re: DDR2 SDRAM controller
From: Markus Meng <meng.engineering@bluewin.ch>
Date: Thu, 26 Jan 2006 22:31:50 +0100
Links: << >>  << T >>  << A >>
Antti Lukats schrieb:
> Anand" <thisisandu@gmail.com> schrieb im Newsbeitrag 
> news:1138288572.991824.321210@g44g2000cwa.googlegroups.com...
>> I am writing veerilog code for DDR2 SDRAM controller using the micron
>> memory module and I want to implement it on Virtex-4 FPGA.......but I
>> am a new comer to verilog and due to time constraints I am afraid that
>> i won't be able to write the complete code(complete all
>> modules)......so can any one provide me a synthesizable code......the
>> one i cud get from the xilinx web site( reference design) is not
>> synthesizable.....plz help
>>
> 
> just start Xilinx memory interface generator (MIG) click a few times and you 
> get synthesizeable and work code inclusive FGPA toplevel test fixture. then 
> assing pins in UCF and ready you are!
> 
Hi Antti,

are you really using this approach click-and-you-are-done for productive 
and mission critical industry DDR-II designs running at ~ 500 MBit data 
rate?

Markus

Article: 95882
Subject: Re: Xilinx ....
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 26 Jan 2006 13:32:10 -0800
Links: << >>  << T >>  << A >>
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.

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?


Article: 95883
Subject: Re: Are the Xilinx pcores files not searchable?
From: Duane Clark <dclark@junkmail.com>
Date: Thu, 26 Jan 2006 21:41:09 GMT
Links: << >>  << T >>  << A >>
agou wrote:
> Hi, all
> 
> I know some files in the folder:
> C:\EDK\hw\XilinxProcessorIPLib\pcores\proc_common_v2_00_a\hdl\vhdl. But
> when I used the XP search program to look for them, it can't find the
> files.
> 
> I wonder whether these lib files are encrypted to prevent us from
> finding?
> 
> BTW, what i am trying to find is: I am trying to find
> async_fifo_v4_0.vhd.

It is in $XILINX/vhdl/src/XilinxCoreLib.

Article: 95884
Subject: Re: Spartan-3 Starter Board
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 26 Jan 2006 13:45:41 -0800
Links: << >>  << T >>  << A >>
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 :)

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.


Article: 95885
Subject: Re: Xilinx ....
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 13:48:59 -0800
Links: << >>  << T >>  << A >>

rickman wrote:
> I have to say that I am pretty clueless about this JHDLBits issue.

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.

But, I'm not a lawyer as should be assumed, and you should
see your own counsel.


Article: 95886
Subject: Re: DDR2 SDRAM controller
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 26 Jan 2006 21:49:44 GMT
Links: << >>  << T >>  << A >>
"Markus Meng" <meng.engineering@bluewin.ch> wrote in message 
news:43D93FC6.4060009@bluewin.ch...
> Antti Lukats schrieb:
>> Anand" <thisisandu@gmail.com> schrieb im Newsbeitrag 
>> news:1138288572.991824.321210@g44g2000cwa.googlegroups.com...
<snip>
>>> .....but I am a new comer to verilog
<snip>

>> just start Xilinx memory interface generator (MIG) click a few times and 
>> you get synthesizeable and work code inclusive FGPA toplevel test 
>> fixture. then assing pins in UCF and ready you are!
>>
> Hi Antti,
>
> are you really using this approach click-and-you-are-done for productive 
> and mission critical industry DDR-II designs running at ~ 500 MBit data 
> rate?
>
> Markus

Does it matter to the original poster? 



Article: 95887
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 14:01:30 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> 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.

Actually, NO.

suggesting such nonsense is only going to get more kids into hot water
and create another JHDLBits public relations melt down.

There are three reasons in the EULA that would get you into trouble for
including XDL interfaces in open source. First the provision for Xilinx
only. Second the provision about derived works. And third, the
violation
of trade secrets and proprietary interest. Xilinx has not waived any of
those for 3rd party developmen and distribution of open source tools.

Austin just confirmed that in another thread ... ANYONE that thinks
they can ignore this, should have a long talk with in IP lawyer first.


Article: 95888
Subject: Re: Reverse Engineering or Modification?
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 26 Jan 2006 22:02:00 GMT
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:1138311130.128465.164910@g44g2000cwa.googlegroups.com...
> 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.
>
> 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?


A couple of weeks ago I noticed an old pen on my desk from ClearLogic that 
made me wonder if they were still in business.  "Just Send the Bitstream" 
"Samples in 2 Weeks" "The FPGA Alternative."  This company took Altera 
bitstreams and generated masked logic.  When I went googling into the 
situation, I came across the legal papers that were written after the 
company shut down and was taking care of some of the details.

That legal opinion underscored that reverse engineering devices to 
understand the implementation is an acceptable practice.  Copying a section 
of a mask is not.  The software is a different issue.  The Altera licensing 
specifically declared the bitstream as proprietary and that using that 
bitstream directly to produce knockoffs was in violation of the agreement.

You can reverse engineer parts.  You don't necessarily have the right to 
manipulate files (or bitstreams) that are part of licensed software.  Or at 
least that's my interpretation of the Judges' opinions.

- John_H 



Article: 95889
Subject: Re: Xilinx ....
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 26 Jan 2006 14:05:46 -0800
Links: << >>  << T >>  << A >>
Rick,

email me.

Austin


Article: 95890
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 14:11:48 -0800
Links: << >>  << T >>  << A >>

Phil Tomson wrote:
> 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.

sure ... to gain the use of a "free" VHDL/Verilog when the other
vendors tools
either were poor, or expensive. Converting LUT/FF based netlists is not
that
difficult.

But as you note, it would probably be easier to do with EDIF conversion
earlier in the process.

There really isn't much reason to restrict an open source synthesis
tool like
FpgaC or your RubyHDL from using XDL output, other than policy to try
and
vendor lock this half breed form of restricted 3rd party development to
only
use Xilinx product.  Since the Xilinx license is restrictive to Xilinx
product, that
immediately prevents mixing ANY BSD, GPL, or other "approved" open
source code with it during development, as you can no longer honor the
requirements of the open source components with the restrictive Xilinx
code included, and you can not honor the Xilinx license if you
distribute it
as open source. There are some cases where library code can be linked
to restricted binaries, but that needs very careful attention on a
library by
library case.

I'm not sure about all the components of Ruby, but you should check the
licenses to see if the product can be vendor locked .... I suspect not,
as
that generally violates all open source licenses.

In the case of FpgaC, we started with the BSD license in the TMCC code,
which specifically prevents the project from vendor locking derived
works.

Xilinx will probably get into trouble with this as soon as people start
needing
to develop XDL tools on the Xilinx Linux port, as they will have to be
very
extra careful not to blend the licenses and violate the open source
license
for anything that is pure GPL, BSD or the like. Using any pure GPL or
BSD
source to produce XDL tools should immediately be a problem if those
tools are given to anyone. Keeping them inside your own company is
fine,
but as soon as distribution occures, so does the open source license,
including
just giving a copy to a friend.

I suspect that because of this, Xilinx will very likely be forced to
open up
the license for XDL and various libraries in the near future, if they
really
are going to promote this as a Xilinx only 3rd party interface. Trying
to
develop for it without violating GPL will be interesting :)


Article: 95891
Subject: Re: open source fpga programmer programs
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 26 Jan 2006 14:12:22 -0800
Links: << >>  << T >>  << A >>
Jerry Coffin wrote:
> Andy Peters wrote:
>
> [ ... ]
>
> > If your software doesn't work, you tell the customer, "download a patch
> > from our web site."
> >
> > If your hardware doesn't work, you tell the customer, "here's your RMA
> > number.  Send the unit back (at your expense) and if it's under
> > warrantee we'll fix it for free; otherwise, it'll cost $$$."
>
> Hmmm...did I somehow end up in the wrong newsgroup? I thought this was
> comp.arch.fpga, where if your hardware doesn't work, you tell the
> customer "download a patch from our web site" -- thus the name _field
> programmable_ gate array. Granted, it's entirely possible to use an
> FPGA in a design that doesn't allow its associated Flash to be updated
> -- but it's certainly a long ways from a given.

Sometimes the fix to the problem can't be done in the FPGA but rather
must be done in the "other stuff" on the board.  Or what if the FPGA
you chose is large enough for the original design but won't fit the
fixed design?

Or what if your design doesn't have a convenient external programming
interface?  How many customers have the JTAG tools?

-a


Article: 95892
Subject: Re: So Xilinx, is XDL and related libraries an available open source
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 27 Jan 2006 11:29:36 +1300
Links: << >>  << T >>  << A >>
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.

  I'm still not sure why you see this as a brick-wall. In ALL toolchains,
you MUST end up on some silicon, which is from a specific vendor.
  This silicon itself, is clearly NOT open source.
  So the OpenSource, HAS to cross a boundary, at some stage ?

  From what I understand of XDL, is it going to be close to the silicon, 
and so not really that portable anyway. Such lower level tools never are.

Ed.McGettigan@xilinx.com  wrote :
"The XDL tool explicitly states that you are allowed to create tools
that use the output of NCD2XDL or tools that create input for XDL2NCD.
This use of course is restricted to use for Xilinx devices per the
ISE 8.1i EULA."

  So, why not create a (for example) "ODL specification", and then backend
tools, that are ODL2XDL, and XDL2ODL.
  That gives you access into Xilinx flows, and should Altera have in the 
future a ADL tool, of approximately similar silicon-relative level, you 
can then do ODL2ADL, and ADL2ODL.
  Xilinx cannot prevent you doing that.

As Ray mentions, solutions are there, if you really want them.


-jg


Article: 95893
Subject: Re: Xilinx ....
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 26 Jan 2006 14:32:18 -0800
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Rick,
>
> email me.
>
> Austin

It's ok.  I don't have any real interest in reverse engineering FPGAs
or using Xilinx software for anything except designing parts.

If you really want to help me with a real issue, see what you can do to
get modular reconfiguration for the Spartan parts.  I guess this is not
used by many and is even less asked for on the Spartan parts.  But a
design I wanted to do pretty much required modular reconfiguration.  I
looked into it and found that the tools were pretty primitive and
likely buggy, but it might have worked out.  Then I found that support
for the Spartan 3 was not available.  When I inquired with some people
at the factory I was told that Xilinx was "committed" to making this
available for the S3 parts.  But it never happened.

At one point it seemed like the V4 parts might make this happen since
they also have the issue of no tbufs.  I have not checked in a long
time, but AFAIK modular reconfiguration is not supported for Spartan 3
parts.

BTW, what I mean by modular reconfiguration does not mean the part is
running, as in partial reconfiguration.  I believe there are some
limitations with the S3 hardware that prevent this.  I wanted to
partition a design into blocks and depending on what hardware is
attached to the FPGA, different interface blocks would be loaded into
the FPGA to mate with that hardware.  This would all be done at
configuration time, not after the part is running.  This way the FPGA
design can be managed in a modular fashion rather than needing dozens
if not hundreds of different downloads for the various permuations of
hardware.  

Any chance with the Spartan 3?


Article: 95894
Subject: Re: Are the Xilinx pcores files not searchable?
From: "agou" <agou.win@gmail.com>
Date: 26 Jan 2006 14:34:00 -0800
Links: << >>  << T >>  << A >>
I found where the file is by hand later. What I am curious is when I
used the SEARCH program to look for it, I could get it. Why is that?


Article: 95895
Subject: Re: So what happened to JHDLBits?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 27 Jan 2006 11:42:05 +1300
Links: << >>  << T >>  << A >>
Phil Tomson wrote:

> 
> Interesting that nobody from Xilinx has commented about what happened to 
> JHDLBits, nor has anyone from there commented about open source tools using 
> XDL.

See another thread,
Re: So Xilinx, is XDL and related libraries an available open source 
interface?

Ed.McGettigan@xilinx.com  wrote : [part quoted here]
"The XDL tool explicitly states that you are allowed to create tools
that use the output of NCD2XDL or tools that create input for XDL2NCD.
This use of course is restricted to use for Xilinx devices per the
ISE 8.1i EULA."

So the answer rather depends on your precise/pedantic definition of open 
source.

Yes, XDL is an open specification, and you can create tools.
No, you cannot target other silicon using XDL.

To many, that would be OK.

-jg


Article: 95896
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 26 Jan 2006 22:45:22 GMT
Links: << >>  << T >>  << A >>
In article <1138313508.001165.308500@g44g2000cwa.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>Phil Tomson wrote:
>> 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.
>
>sure ... to gain the use of a "free" VHDL/Verilog when the other
>vendors tools
>either were poor, or expensive. Converting LUT/FF based netlists is not
>that
>difficult.
>
>But as you note, it would probably be easier to do with EDIF conversion
>earlier in the process.
>

Right, so why would someone spend time trying to use XDL for retargetting?
You're saying that theoretically someone down the line might do this and that 
would result in a license violation.  But just because someone could do it 
doesn't mean that it would be done, practically speaking.

>There really isn't much reason to restrict an open source synthesis
>tool like
>FpgaC or your RubyHDL from using XDL output, other than policy to try
>and
>vendor lock this half breed form of restricted 3rd party development to
>only
>use Xilinx product.  Since the Xilinx license is restrictive to Xilinx
>product, that
>immediately prevents mixing ANY BSD, GPL, or other "approved" open
>source code with it during development, as you can no longer honor the
>requirements of the open source components with the restrictive Xilinx
>code included, 

But no Xilinx code would be included.

> and you can not honor the Xilinx license if you
>distribute it
>as open source. There are some cases where library code can be linked
>to restricted binaries, but that needs very careful attention on a
>library by
>library case.
>
>I'm not sure about all the components of Ruby, but you should check the
>licenses to see if the product can be vendor locked .... I suspect not,
>as
>that generally violates all open source licenses.
>

None of the Ruby sourcecode would be included.  The tool might be written in 
Ruby, but none of the Ruby source need be included, so there would be no 
license issues from the Ruby side.  

>In the case of FpgaC, we started with the BSD license in the TMCC code,
>which specifically prevents the project from vendor locking derived
>works.
>

Yes, FpgaC might have issues because it was already under BSD license.  

>
>I suspect that because of this, Xilinx will very likely be forced to
>open up
>the license for XDL and various libraries in the near future, if they
>really
>are going to promote this as a Xilinx only 3rd party interface. Trying
>to
>develop for it without violating GPL will be interesting :)
>

But again, if the code I am distributing under GPL or BSD (or whatever open 
source licnese) is only designed to deal with XDL, I really don't see the 
problem.  If someone else takes the code and creates an XDL -> Altera converter 
then it seems that they will need to deal with Xilinx.  I suspect, however, 
that if someone really, really wants to do that they would create another more 
generic format and convert XDL to that.  At that point the new format would be 
more generic (be necessity) in order to be able to target different FPGA 
families.  This just seems more practical from a software engineering 
standpoint.  IF that were to happen (and again, I think they'd be better off 
working at the EDIF level) then XDL is out of the picture; the generic format 
gets converted, not XDL.

Phil

Article: 95897
Subject: Re: open source fpga programmer programs
From: "Jerry Coffin" <jerry.coffin@gmail.com>
Date: 26 Jan 2006 14:47:29 -0800
Links: << >>  << T >>  << A >>
Andy Peters wrote:

> > Granted, it's entirely possible to use an
> > FPGA in a design that doesn't allow its associated Flash to be updated
> > -- but it's certainly a long ways from a given.
>
> Sometimes the fix to the problem can't be done in the FPGA but rather
> must be done in the "other stuff" on the board.
>
> Or what if the FPGA you chose is large enough for the original design but
> won't fit the fixed design?
>
> Or what if your design doesn't have a convenient external programming
> interface?  How many customers have the JTAG tools?

I didn't say that every possible hardware flaw could be fixed via a
patch. I objected to the claim that none of them could be.

In the end, however, you're right: a design certainly _can_ be screwed
up to the point that the only hope for it is to throw it away and start
over. OTOH, if you're creating a design that bad, software isn't going
to be enough different to notice -- a company run so badly that it
releases utterly hopeless messes to its customers isn't going to be
saved by software being more dependably patchable.

-- 
    Later,
    Jerry.


Article: 95898
Subject: Re: Spartan-3 Starter Board
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 27 Jan 2006 11:48:49 +1300
Links: << >>  << T >>  << A >>
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote:

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

  So there is no header that allows the few PGM wires, to be taken 
off-board, to another FPGA/CPLD ?
  Silly question then : why not ?

-jg


Article: 95899
Subject: Re: So Xilinx, is XDL and related libraries an available open source interface?
From: fpga_toys@yahoo.com
Date: 26 Jan 2006 14:58:29 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:
>   I'm still not sure why you see this as a brick-wall. In ALL toolchains,
> you MUST end up on some silicon, which is from a specific vendor.
>   This silicon itself, is clearly NOT open source.
>   So the OpenSource, HAS to cross a boundary, at some stage ?

It's partly an issue of morality. I don't think it's right to
purposefully
find a way to subvert Xilinx's license. Conspiring with two, or three,
or four parties to do so, is likely to be transparent in court anyway.

>   From what I understand of XDL, is it going to be close to the silicon,
> and so not really that portable anyway. Such lower level tools never are.

>From a moral position, is doesn't matter what level it is at. The fact
that
it's formats and use is vendor proprietary is all that matters, as that
prevents interfacting to it from the BSD licensed TMCC code we started
with. Xilinx does not want open source software with XDL interfaces
embedded in it. ... conspiring to interface to a third parties
intermediate
format is just that, a conspiracy to circumvent the Xilinx license.

Either Xilinx gives the FpgaC project written permission to interface
to XDL
with a specific list of library interfaces and the public documentation
for them
with a release that conforms to the BSD license, or we can not use it.

> Ed.McGettigan@xilinx.com  wrote :
> "The XDL tool explicitly states that you are allowed to create tools
> that use the output of NCD2XDL or tools that create input for XDL2NCD.
> This use of course is restricted to use for Xilinx devices per the
> ISE 8.1i EULA."

That "restricted to use for Xilinx devices" is the deal breaker which
violates
our BSD license from TMCC.

>   So, why not create a (for example) "ODL specification", and then backend
> tools, that are ODL2XDL, and XDL2ODL.

That is a conspiracy to violate either BSD or Xilinx, and would be
transparent
in court. We could not distribute either ODL2XDL, and XDL2ODL with
FpgaC,
nor could we conspire with a 3rd party to provide them for us.

>   That gives you access into Xilinx flows, and should Altera have in the
> future a ADL tool, of approximately similar silicon-relative level, you
> can then do ODL2ADL, and ADL2ODL.
>   Xilinx cannot prevent you doing that.
>
> As Ray mentions, solutions are there, if you really want them.

It's probably easier to wait and let others develop a number of
important
tools which are using open source components, and then just have a day
of disclosure with the FSF about license violations and see if Xilinx
is
ready yet to open the license.  Heck, it might even be Xilinx that
breaks
the open source license first, as I doubt they, or anybody, has
carefully
checked every proprietary object to make sure that they are only linked
with LGPL or similar licensed libraries. That has caught a large number
of companies :)

LGPL allows for linking open source libraries with proprietary code.
Not all
libraries are LGPL, some are pure GPL or other open source varient. Any
proprietary object found linked with GPL or other open source code is
in
violatation of their license.

Take Phil's project for example. The base license for Ruby is GPL,
which
means that he will have to be very careful to keep Ruby and Ruby
libraries
completely separate from anything that contains IP from XDL.  If he is
careful, he might even be able to do that. If he is not and ends up
with
a blended license derivative work, then one or both licenses are
violated.
What is certain, is that he could never distribute the XDL portions
publicly
as open source, and would have to have a very long talk with Xilinx
Legal
and his own lawyer to carefully spell out distribution rights of the
derived
work. A C&D order is the least of your worries if there is a miss-step.
The
real fear is that they file for damages and legal costs, that literally
could
ruin the rest of your life since a Chapter 7 these days is harder to
get
without paying some or all your liabilities in such a judgement.

I don't think it's personally worth the risk, expecially for an open
source
project.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search