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 96175

Article: 96175
Subject: Re: Xilinx Legal
From: cs_posting@hotmail.com
Date: 31 Jan 2006 06:01:21 -0800
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:

> Sorry Austin, that is complete nonsense. Xilinx can not own a file that
> contains IP both from me an third parties.
> A shared ownership might be possible but I really doubt that.

That seems to be the most logical basis for a claim.  Compare for
example, this partial passage from RedHat's default licensing of the
Cygwin compatability layer:

"The Cygwin API library found in the winsup subdirectory of the source
code is also covered by the GNU GPL (with exceptions; see below). By
default, all executables link against this library (and in the process
include GPL'd Cygwin glue code). This means that unless you modify the
tools so that compiled executables do not make use of the Cygwin
library, your compiled programs will also have to be free software
distributed under the GPL with source code available to all."

This seems to say that if you compile in a way that includes bits of
their library, RedHat has an ownership interest in your binary.  The
only difference is that they exercise that interest by extending the
GPL to the result, whereas Xilinx exercises its interest by extending
its restrictions on keeping the technology proprietary and only running
it on Xilinx silicon.  RedHat is also willing to sell you a license to
use the parts of the Cygwin stuff which they own under non-GPL terms,
and Xilinx may be willing to license a bit stream to you slightly
differently if you can make a convincing argument to why it would be in
their interest to do so.


Article: 96176
Subject: ERROR message when programming FPGA with Altium Designer 2004
From: "Nils" <nils.hannemann@email.de>
Date: 31 Jan 2006 06:07:14 -0800
Links: << >>  << T >>  << A >>
Hi @ll,

I'm new in FPGA Design.
For my student research project I try to start running the Altium
NanoBoard-NB1 with an Xilinx SPARTAN-IIE FPGA chip on it.
I'm working with the Altium Designer 2004. I have also installed the
XILINX ISE WebPack 8.1i, in order to be able to program the FPGA on the
daughterboard.
After translating the design an error message is displayed as follows:


ERROR:Portability:90 - Command line error: Switch "-quiet" is not
allowed

Do I have to change any setting for the NGDBuild Option?

Thanks for any help 

Nils


Article: 96177
Subject: Re: High-Level Languages for FPGAs
From: fpga_toys@yahoo.com
Date: 31 Jan 2006 06:11:35 -0800
Links: << >>  << T >>  << A >>

Robin Bruce wrote:
> A language is high-level with respect to another if it offers a greater
> degree of abstraction from the complexities of implementation.

And I might note that issues like pipelines and state machines flow
from the semantics of sequential C syntax depending how a C to FPGA
compiler implements that syntax. Pipelines occur naturally in
sequential
C on all platforms when the statement blocks are in an inverted order,
a
trick I have used for a few years and offered in C.A.F before. State
machines are a natural by product of IF-THEN-ELSE sequential statements
in any looping construct such as WHILE.

It is much more natural to implement pipelines and state machines in C
this way for people trained in sequential languages as the results are
visually obvious and timing free. You get the advantage of being able
to
move the same code, between a variety of execution targets, which
traditional HDL's limit.


Article: 96178
Subject: Re: ERROR message when programming FPGA with Altium Designer 2004
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 31 Jan 2006 15:14:10 +0100
Links: << >>  << T >>  << A >>
"Nils" <nils.hannemann@email.de> schrieb im Newsbeitrag 
news:1138716434.545030.98410@o13g2000cwo.googlegroups.com...
> Hi @ll,
>
> I'm new in FPGA Design.
> For my student research project I try to start running the Altium
> NanoBoard-NB1 with an Xilinx SPARTAN-IIE FPGA chip on it.
> I'm working with the Altium Designer 2004. I have also installed the
> XILINX ISE WebPack 8.1i, in order to be able to program the FPGA on the
> daughterboard.
> After translating the design an error message is displayed as follows:
>
>
> ERROR:Portability:90 - Command line error: Switch "-quiet" is not
> allowed
>
> Do I have to change any setting for the NGDBuild Option?
>
> Thanks for any help
>
> Nils
>

yes probably = DXP2004 uses switches not any more available in current 
releases of ISE so you need a workaround

Antti 



Article: 96179
Subject: Re: Xilinx Legal
From: Kolja Sulimma <news@sulimma.de>
Date: Tue, 31 Jan 2006 15:18:42 +0100
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com schrieb:
> Kolja Sulimma wrote:
> 
> 
>>Sorry Austin, that is complete nonsense. Xilinx can not own a file that
>>contains IP both from me an third parties.
>>A shared ownership might be possible but I really doubt that.
> 
> This seems to say that if you compile in a way that includes bits of
> their library, RedHat has an ownership interest in your binary.  The
> only difference is that they exercise that interest by extending the
> GPL to the result, whereas Xilinx exercises its interest by extending
> its restrictions on keeping the technology proprietary and only running
> it on Xilinx silicon.  RedHat is also willing to sell you a license to
> use the parts of the Cygwin stuff which they own under non-GPL terms,
> and Xilinx may be willing to license a bit stream to you slightly
> differently if you can make a convincing argument to why it would be in
> their interest to do so.

That would be shared ownership, which is possible.
But to claim that, Xilinx must argue that the bitstream contains
material that is protected by copyright. Is is not enough that it was
created with a tool that is protected by copyright.
(Using a compiler/text editor vs. linking to a library/using a letter
template)

Some bitstreams might contain Xilinx library elements but clearly not
all bitstreams do.

Kolja Sulimma

BTW:
The ISE toolflow uses TCL at some points. If the use of a tool alone
would impose the license of the tool on the result all bitstreams would
be GPL. So Xilinx needs to explain why the EULA of ISE does affect the
bitstream while the license of TCL does not.

Article: 96180
Subject: Re: Open source access to generate netlists into Altera tools? Others?
From: fpga_toys@yahoo.com
Date: 31 Jan 2006 06:19:44 -0800
Links: << >>  << T >>  << A >>
Since I don't use Altera product at this point, what I don't know, is
if there are open source friendly public disclosures by Altera which
open up access to their tools in a friendly way.


Article: 96181
Subject: Re: starting MacroBlaze development
From: "TigerSatish" <satishkmys@gmail.com>
Date: 31 Jan 2006 06:34:18 -0800
Links: << >>  << T >>  << A >>
Choose NIOS II it has 1,040,000  hits !!


Article: 96182
Subject: Re: URGENT: Need to get the USB Balster Driver for the UNIX machines which has FT245BM
From: "TigerSatish" <satishkmys@gmail.com>
Date: 31 Jan 2006 06:42:06 -0800
Links: << >>  << T >>  << A >>
Need Suggestion


Article: 96183
Subject: Re: ERROR message when programming FPGA with Altium Designer 2004
From: "Nils" <nils.hannemann@email.de>
Date: 31 Jan 2006 06:47:07 -0800
Links: << >>  << T >>  << A >>
it sounds good, but how could this workaround look like? i have no
ideas what i can do.
there are a few checkboxes in the option menu but i can't find a topic
which matches with my problem. :(
and even in the xilinx design environment i couldn't find a topic.


Article: 96184
Subject: Re: URGENT: Need to get the USB Balster Driver for the UNIX machines which has FT245BM
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 31 Jan 2006 15:56:29 +0100
Links: << >>  << T >>  << A >>
"TigerSatish" <satishkmys@gmail.com> schrieb im Newsbeitrag 
news:1138718526.705207.34950@g49g2000cwa.googlegroups.com...
> Need Suggestion
>
if you need it URGENT  then only solution is to purchase a windows or linux 
PC and forget usb blaster on unix

Antti 



Article: 96185
Subject: scrambling
From: "brian" <bhb22l@yahoo.fr>
Date: Tue, 31 Jan 2006 16:39:58 +0100
Links: << >>  << T >>  << A >>
Hi all,

I need a VHDL source code scrambler/descrambler.
Polyn : x ^ 7 +  x ^ 6 + 1

I found some information on web (LFSR xilinx, etc...), but I have some
problem with my example.

Thanks a lot for any reply about this subject (web, litteratur,vhdl
code...).
Brian





Article: 96186
Subject: Re: Xilinx Legal
From: cs_posting@hotmail.com
Date: 31 Jan 2006 07:44:36 -0800
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:

> The ISE toolflow uses TCL at some points. If the use of a tool alone
> would impose the license of the tool on the result all bitstreams would
> be GPL. So Xilinx needs to explain why the EULA of ISE does affect the
> bitstream while the license of TCL does not.

Does the license of TCL make claims about the output of TCL-using
tools?
My guess is it doesn't.  So that's a difference right there - it
doesn't really give us any clues about the potential validity of making
such a claim.


Article: 96187
Subject: Re: Xilinx Legal
From: fpga_toys@yahoo.com
Date: 31 Jan 2006 07:46:43 -0800
Links: << >>  << T >>  << A >>

Kolja Sulimma wrote:
> BTW:
> The ISE toolflow uses TCL at some points. If the use of a tool alone
> would impose the license of the tool on the result all bitstreams would
> be GPL. So Xilinx needs to explain why the EULA of ISE does affect the
> bitstream while the license of TCL does not.

Hey Guys, let's back off and let the open source advocates inside
Xilinx
to have time to work out how they want to be the good guys.

They clearly recieve a lot of value from free open source that they use
internally and put into their product. The backlash could clearly be
creating XGPL licenses, which allow use for all but those companies
that refuse to be equally open with their EULA's. That would a a lively
debate, but we see it already with the number of free software licenses
which specifically prohibt commercial use because of these abuses,
and the mindset that if someone is going to profit from their work,
they
want part of the pie in the form of royalties or license fees.

The reality is that all the information open source needs is out of
their
control anyway, it would just take a legal battle to secure it, that
maybe
even FSF would fund. I've already documented that fact.

So, let's just give Xilinx a chance to think about this more carefully,
and
have a chance to volunteer to be good open source citizens.


Article: 96188
Subject: Re: Digilent FPGA & Handel-C
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Tue, 31 Jan 2006 15:59:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
Brian Drummond (brian_drummond@btconnect.com) wrote:

: uh, in what way is C a higher level language than VHDL anyway?

I guess that's a bit like comparing apples and oranges if we are talking 
about the *synthesizable* part of VHDL.  Actually you've got me sat here 
scratching my head trying to decide now.

There are constructs that aren't present in VHDL / or don't synthesize 
that I consider a higher level - e.g. things like C structs allow many 
variables to be passed around between areas of C code, without everything 
area (function) having to be upadated if (for example) extra variables are 
added to the struct.  I don't think VHDL has such a neat, clean way of 
doing this.

As I said before 'Why AnythingC' - I don't think it's high enough 'above' 
VHDL to make the pain of using a sequential orientated language for 
programming FPGAs worth while.

It is good for hiding the truth about and FPGA implementation from a C 
programmer, but weather that is in anyones benefit...

cds

Article: 96189
Subject: Re: Xilinx Legal
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 31 Jan 2006 08:23:35 -0800
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:
> Ed McGettigan schrieb:
> 
>> The (A) company used these exact same EULA restrictions against Clear Logic
>> and won.
>>
>> More details here:
>> http://www.internetcases.com/archives/2005/09/ninth_circuit_a_1.html
> 
> There is no mentioning of the EULA. Apparently there is a special law in
> the US to protect semiconductor masks and the court treated the
> bitstream as a mask work.
> The EULA can still be completely invalid.
> 
> I just skimmed the law, and I still do not see how Altera could possibly
> have won.
> It says
> 
> "the “owner” of a mask work is the person who created the mask work"
> If I start bitgen, I am generating the mask work and not altera. I use a
> tool to do it, yes, but surely I am still the creator?
> 
> But even if Altera was the owner, it goes on:
> "the protection provided for a mask work under this chapter shall
> commence on the date on which the mask work is registered under section
> 908, or the date on which the mask work is first commercially exploited
> anywhere in the world"
> Surely Altera did not register my bitstream and did not exploit it
> comercially before I sent it to Clear Logic?
> 
> Then the law goes on, and explicitely allows to reverse engineer the
> mask (bitstream) to create your own bitstreams with the information
> obtained:
> 
> §906 (a) 1 and 2: "it is not an infringement [...] for [...] a person
> who performs the analysis or evaluation described in paragraph (1) to
> incorporate the results of such conduct in an original mask work which
> is made to be distributed."
> 
> 
> I conclude that §906 (a) of the Semiconductor Chip Protection Act of
> 1994 permits to reverse engineer bitstream information to create open
> source tools. But hey, IANAL.
> 
> Kolja Sulimma
> 
> 

The previous link that I cited only discussed a narrow issue that
was raised to an appellate court.  Try this one instead which has
notes on the on the  Software License Agreement.  Altera was not
claiming that they "owned" the bitstream only that use of the
bitstream was restricted to Altera only devices by the license of
the software that created it.

http://www.iplawobserver.com/2005/09/using-softwares-output-to-copy-chips.html

Ed

Article: 96190
Subject: Re: Xilinx Legal
From: DJ Delorie <dj@delorie.com>
Date: 31 Jan 2006 11:35:39 -0500
Links: << >>  << T >>  << A >>

[disclaimer: I'm a GCC developer and former Cygwin developer]

One key difference between Cygwin and Xilinx, is that apps built with
Cygwin also *include* part of cygwin (almost verbatim) in the
resulting binary.  Do bitstreams built by Xilinx tools *include*
portions of the Xilinx tools in the resulting bitstream?  Can Xilinx
point to a bitstream and say "these 1000 bits are copied from our
library" ?

A better comparison is comparing Xilinx to GCC.  The GCC license
explicitly states that binaries built *with* GCC are not affected in
any way by GCC's license.

Note that binaries built *from* GCC (derived works) are a different
story.  GCC's runtime libraries have a specific clause that covers
linking; if you build with GCC, linking doesn't incur the GPL.  If you
build with something else, linking does incur the GPL.

Article: 96191
Subject: Wanted Help on All Digital PLL
From: "Gopi" <neelagopi@gmail.com>
Date: 31 Jan 2006 08:38:23 -0800
Links: << >>  << T >>  << A >>
I need material wchich cover all about ADPLL, which contains about
operating principles and design (vlsi also). If there are any links
that have these information please let me know


Article: 96192
Subject: Re: Xilinx Legal
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 31 Jan 2006 08:57:47 -0800
Links: << >>  << T >>  << A >>
Ed McGettigan wrote:
> 
> The previous link that I cited only discussed a narrow issue that
> was raised to an appellate court.  Try this one instead which has
> notes on the on the  Software License Agreement.  Altera was not
> claiming that they "owned" the bitstream only that use of the
> bitstream was restricted to Altera only devices by the license of
> the software that created it.
> 
> http://www.iplawobserver.com/2005/09/using-softwares-output-to-copy-chips.html 
> 

One more link that which is the actual ruling made by the US Court of Appeals
for the 9th Circuit:

http://www.ca9.uscourts.gov/ca9/newopinions.nsf/01512427B6AF4BF88825707C0076B4A3/$file/0317323.pdf?openelement

The first half discusses the mask claims, the latter half discusses the SW License
claims on pages 17-23.  Specifically on the bottom of page 23 the court found:

     Altera customers cannot use the software, and
     therefore create the bitstreams, without agreeing to the licensing
     agreement, including the permitted use restriction. In
     essence, a valid contract is a prerequisite to the creation of a
     bitstream from Altera software, and the jury could logically
     conclude that valid contracts were formed via the Altera
     licensing agreements before customers sent bitstreams to
     Clear Logic. We therefore affirm the district court’s denial of
     judgment (sic) as a matter of law on the final claim.

Maybe we could now move any further legal oriented threads to comp.arch.fpga.legal :-)
and get back to technical issues and discussions.  I know at least that this will
be my last post on this thread and the XDL/Open Source License threads.

Ed
--
Xilinx Inc.

Article: 96193
Subject: Re: Xilinx Legal
From: Kolja Sulimma <news@sulimma.de>
Date: Tue, 31 Jan 2006 17:58:46 +0100
Links: << >>  << T >>  << A >>
Ed McGettigan schrieb:
> The previous link that I cited only discussed a narrow issue that
> was raised to an appellate court.  Try this one instead which has
> notes on the on the  Software License Agreement.  Altera was not
> claiming that they "owned" the bitstream only that use of the
> bitstream was restricted to Altera only devices by the license of
> the software that created it.
> 
> http://www.iplawobserver.com/2005/09/using-softwares-output-to-copy-chips.html

Interesting.
They invoke the Semiconductor Chip Protection Act by stating that the
bitstream format contains information on the structure of alteras FPGA
circuits and that it therefore something like a copy of alteras circuit
layout was created.

Clear Logic seems to believe that the jury was confused about what
exactly was copied. I think that is very likely.

You are allowed to reverse engineer if you incorporate the results in an
original work. As I understand it clear logics mask is very different
from alteras in that there is no configuration logic, sram cells, etc.
There should be less then 1/6 of the transistors. Of course the
structure will be similar, but what else should "incorporate the
results" mean, clearly similarities are allowed?


Still, that ruling does not apply to using an altera bitstream in a
Xilinx FPGA oder implementing an altera bitstream in an ASIC (that is
not similar to alteras FPGA structure)

Kolja Sulimma



Article: 96194
Subject: Re: Xilinx Legal
From: fpga_toys@yahoo.com
Date: 31 Jan 2006 09:32:55 -0800
Links: << >>  << T >>  << A >>

Ed McGettigan wrote:
>      Altera customers cannot use the software, and
>      therefore create the bitstreams, without agreeing to the licensing
>      agreement, including the permitted use restriction. In
>      essence, a valid contract is a prerequisite to the creation of a
>      bitstream from Altera software, and the jury could logically
>      conclude that valid contracts were formed via the Altera
>      licensing agreements before customers sent bitstreams to
>      Clear Logic. We therefore affirm the district court's denial of
>      judgment (sic) as a matter of law on the final claim.
>
> Maybe we could now move any further legal oriented threads to comp.arch.fpga.legal :-)
> and get back to technical issues and discussions.  I know at least that this will
> be my last post on this thread and the XDL/Open Source License threads.

Thanks for the clearification Ed, and the small dose of contract law is
good
for everyone to keep them out of the defendants chair and having to
learn
a whole lot more. This statement about the enforcability of an EULA
contract
terms should be a wake up call to those that haven't thought these
issues
thru.

In summary, the EULA contract NDA supercedes all other rights you might
have to similar information in other settings. The confusion this week
over the
concepts of copyright fair use while under NDA, over contridictory
statements
about the open nature of VDL, and other rights issues have all been
useful
to learn and think about so we can protect ourselves and the IP we
agree to
use.

Hopefully it's also been a learning exercise for Xilinx too. The real
economic
value for Xilinx is the sale of it's chips, and at some point open
source access
to the tool chain will greatly benefit the companies sales by expanding
uses
into new markets that the existing tool chain doesn't support.
Certainly easy
access to Xilinx product for personal research by students and
hobbiests is
a market builder that yields long term benefits as those individuals
influence
purchasing decisions for their employers and the companies they own.


Article: 96195
Subject: Xilinx owns the bitstream
From: "Paul Marciano" <pm940@yahoo.com>
Date: 31 Jan 2006 10:19:08 -0800
Links: << >>  << T >>  << A >>

Surely this is purely academic nitpicking going on here.  Xilinx's
ownership of your bitstream (which you agreed to when you installed
their software) simply provides them a legal recourse should you try to
retarget it to a different vendor's technology.

They're in the business of selling chips, and with development systems
like WebPack they make available free tools (which they invest massive
amounts of money in) to reduce the cost to you to develop.  They're not
going to try to assert ownership of your Whizbang5000 IP - get real.


I know people like to rant and rave about stuff like this.  But for all
practical purposes it's a no-op.

Paul.


Article: 96196
Subject: Re: Digilent FPGA & Handel-C
From: fpga_toys@yahoo.com
Date: 31 Jan 2006 10:44:45 -0800
Links: << >>  << T >>  << A >>

c d saunter wrote:
> Brian Drummond (brian_drummond@btconnect.com) wrote:
> > uh, in what way is C a higher level language than VHDL anyway?
> I guess that's a bit like comparing apples and oranges if we are talking
> about the *synthesizable* part of VHDL.  Actually you've got me sat here
> scratching my head trying to decide now.

The truth is that it isn't in most ways. Java, C++, and other object
oriented languages are. C started out it's origins a "The B programming
Language" (http://en.wikipedia.org/wiki/B_programming_language) which
was barely a step above assembly language on many of the small machines
it was implemented on. As B evolved into C, it also replaced thousands
of lines of assembly language, at little additional costs in size or
performance.

A good systems programmer codes C line for line with the accuracy of
programming in assembler. That skill will continue as people use C
syntax HLL's and HDL's to generate high performance circuits on FPGA's,
and for these people the efficiency arguments of VHDL/Verilog in
comparison to C subset languages will be moot. For a pure C syntax HDL
list Handel-C there is very little difference between the results that
a skilled engineer can get in comparison to VHDL/Verilog, and even that
will diminish over time as the C based HDL's get the synthesis hints
down pat that mature VHDL and Verilog tools implement today.

> As I said before 'Why AnythingC' - I don't think it's high enough 'above'
> VHDL to make the pain of using a sequential orientated language for
> programming FPGAs worth while.

That the language is sequential, doesn't mean that the resulting
netlists are. This is certainly clear in FpgaC as long forward
dependencies rapidly create deep combinatorial chains. In both
VHDL/Verilog and C subset systems, you have to manually intervine to
break the combinatorial chain into a pipeline. In C, we do this by
inverting blocks of statements, and in VHDL/Verilog we do that by
forcing the instantiation of FF's. Both are done by coding style hints.
In C the results are clearly natural, and less likely to be error prone
by accidentally inferring a FF which is a common error in VHDL/Verilog.

Otherwise, the netlists from boolean's and arithmetics are functionally
identical between all these languages as far as synthesis goes ... with
the only differences being maturity, not issues of syntax limiting the
synthesis. Ditto for data paths, and state machines.

The only real difference is the ability to directly influence I/O
specific features, which the C based tools MAY choose to defer to
things like UCF files.

> It is good for hiding the truth about and FPGA implementation from a C
> programmer, but weather that is in anyones benefit...

That is a good thing, as the size of the current FPGA market is stalled
by the number of engineers that can write VHDL/Verilog and their
productivity.

Increasing the size of the FPGA market, to drive costs down for all
types of projects, is significantly tied to using programming talent
for all kinds of FPGA projects, including the new market of
reconfigurable computing which VHDL/Verilog poorly addresses with the
lack of VHDL/Verilog trained engineers that also understand software
level system designs. This free's up EE design talent to design
hardware, by transfering the back end of the project to software
engineers with Computer Engineering or Computer Science degrees.

More and more, software engineers will be a major player in FPGA
product selection teams.  FPGA companies which violate the
sensibilities of software engineers by providing hardware only design
tools, or licenses which are not open source friendly, or overly
restrictive EULA's, will find that they may frequently loose design
wins without a clear understanding why. FPGA companies may have
established loyalties with the EE's, but that will not be enough to
ensure design wins when software developers are also part of the
product selection team. This single factor could change the entire face
of the market in as little as 5 years.

EE's may complain ... but the market is changing, and whining about it
will not stop it.


Article: 96197
Subject: Re: Digilent FPGA & Handel-C
From: cs_posting@hotmail.com
Date: 31 Jan 2006 11:12:44 -0800
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

> That is a good thing, as the size of the current FPGA market is stalled
> by the number of engineers that can write VHDL/Verilog and their
> productivity.

I don't think so - at least the job market for HDL engineers seems much
smaller today than it did in the late 90's.  I think the limitation on
the FPGA market is the cost of the things, compared to more
volume-appropriate ways of implementing the same functions.

> Increasing the size of the FPGA market, to drive costs down for all
> types of projects, is significantly tied to using programming talent
> for all kinds of FPGA projects

Seems to me like the real issue is that FPGA's are much bigger, and
hence more expensive to manufacture, than other ways of getting many
jobs done.  Process gains make the FPGA's cheaper, but they also make
other solutions cheaper too - and may make it logical to do something
in software that needed hardware previously.

> including the new market of
> reconfigurable computing which VHDL/Verilog poorly addresses with the
> lack of VHDL/Verilog trained engineers that also understand software
> level system designs. This free's up EE design talent to design
> hardware, by transfering the back end of the project to software
> engineers with Computer Engineering or Computer Science degrees.
>
> More and more, software engineers will be a major player in FPGA
> product selection teams.  FPGA companies which violate the
> sensibilities of software engineers by providing hardware only design
> tools, or licenses which are not open source friendly, or overly
> restrictive EULA's, will find that they may frequently loose design
> wins without a clear understanding why.

Yes, if you are going to market an FPGA as a general purpose
dynamically configreable processing element then it needs to have a
programming manual like that of a processor, or some other method of
supporting just-in-time compilation.  Right now most FPGA's are
marketed more for the "ASIC in hours or minutes" application.  To
really go after a new market, the whole structure of the
tool/silicon/IP matchup would have to be reconsidered.


Article: 96198
Subject: Re: XPower- Advanced power report
From: "priya" <priya.sundararajan@gmail.com>
Date: 31 Jan 2006 11:41:00 -0800
Links: << >>  << T >>  << A >>
Hi,
 When i changed the precision of power numbers to nW, the problem got
resolved. 

priya


Article: 96199
Subject: Re: Digilent FPGA & Handel-C
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 31 Jan 2006 12:01:19 -0800
Links: << >>  << T >>  << A >>
c d saunter wrote:

> I guess that's a bit like comparing apples and oranges if we are talking 
> about the *synthesizable* part of VHDL.  Actually you've got me sat here 
> scratching my head trying to decide now.
> 
> There are constructs that aren't present in VHDL / or don't synthesize 
> that I consider a higher level - e.g. things like C structs allow many 
> variables to be passed around between areas of C code, without everything 
> area (function) having to be upadated if (for example) extra variables are 
> added to the struct.  I don't think VHDL has such a neat, clean way of 
> doing this.

In vhdl, this is called a record, and records work fine for synthesis.
See type retime_t in the reference design below.

A vhdl single process design can also handle variables
"to be passed around between areas of code".
Note how the variable TxState_v
is accessed by the both of the
procedures cpu_regs and tx_state
in the reference design below.

http://home.comcast.net/~mike_treseler/uart.vhd

> As I said before 'Why AnythingC' - I don't think it's high enough 'above' 
> VHDL to make the pain of using a sequential orientated language for 
> programming FPGAs worth while.

I enjoy the pain, but you can already
do this with a plain-vanilla vhdl synchronous process.


       -- Mike Treseler




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