EDK : FSL macros defined by Xilinx are wrong

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.
 
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.
 
"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
 
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.
 
Now if only there was an include statement as well to let the shared
definitions reside in a seperate file...
cpp works fine on non-c text files. Shouldn't take too much
hacking if you use make rather than a gui.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
 
That was an error in my design. I hope to run it at 3.3V in the next
revision. That would have made things much easier.

Yaju
 
Austin Lesea <austin@xilinx.com> writes:
There is nothing "open source" about any of Xilinx's software.
Then why did the installer made me agree to the GPL and LGPL? I thought
it was because Xilinx's software (ISE Foundation) included some open
source software.
 
On Tue, 31 Jan 2006 15:59:23 +0000 (UTC),
christopher.saunter@durham.ac.uk (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.
to which the obvious answer would be to compare the synthesizable subset
of VHDL with the synthesisable subset of C ;-)

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

There's nothing fundamentally not-synthesisable about them, though tool
support may be spotty.

They aren't quite as useful as I would like, because (AFAIK) all
elements in a record must share some characteristics like port
directions;
e.g. address and strobe can share a record (they are both outputs from
my module), but data (bidirectional) and ack (input) cannot.

But port directions would pass over the head of something C-like anyway.

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'm a long way from convinced it's _as_ high.

If you need a sequential oriented language - it's right there in VHDL;
just don't leave the current process.

If you need to support concurrency, I wouldn't choose C.

If you need to cleanly separate interfaces and implementations, I
wouldn't choose C.

If you want to perform arithmetic on access types (aka pointers), I
grant you, that's another matter...

All that being said, I wouldn't like to write a word processor in VHDL.
But even that could be argued that's a compiler and library issue,
rather than a language issue.

- Brian
 
On Tue, 31 Jan 2006 20:14:42 +0000 (UTC),
christopher.saunter@durham.ac.uk (c d saunter) wrote:

Mike Treseler (mike_treseler@comcast.net) wrote:

: 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


Hi Mike,
Once again I stand corrected and wiser - thanks for the example!

Now if only there was an include statement as well to let the shared
definitions reside in a seperate file...
sounds like a package! :)

- Brian
 
g14g2000cwa.googlegroups.com>, gallen wrote:
When I can get a 1 GHz FPAA for $10, then there may be a market.
Chances are because people tend to go ADC -> FPGA -> DAC and use
digital algorithms to massage things.

--
[100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
 
I think that you will find that Altium doesn't support 8.1 They will tell
you on the forum. They are usually a rev behind for some time.

Simon


"Mark McDougall" <markm@vl.com.au> wrote in message
news:43dffffe$0$32609$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
Nils wrote:

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?

Check out the DefaultScript_Xilinx_MAP.txt file in the System directory
of your Altium installation. I believe you can comment-out this option
with "#"... not that I've tried it myself.

Failing that, try the DXP forums at Altium.com.

Regards,
Mark
 
Actually.. yes.. if you look at the output files .. you will see it
detecting and replacing counters, comparators, state machines, ram etc.

Simon

"DJ Delorie" <dj@delorie.com> wrote in message
news:xn3bj4icdg.fsf@delorie.com...
[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.
 
<fpga_toys@yahoo.com> wrote in message
news:1138753558.833731.142700@g14g2000cwa.googlegroups.com...
So, back to the question of worst case designs for supporting RC.

What are the worst case VccInt currents that various packages will
handle?

Hi John,
OK, let's work through this. First I'll pick a package, say FG672. Now, I'll
choose a part, say FX20.
From UG075 ThetaC = 0.4 and ThetaB = 3.8. So, best case thermal resistance
from junction to case = 0.4 // 3.8 = 0.36 K/W

OK, say we've selected a commercial grade part. That means our junction
temperature can't exceed 85degC or 358K (from DS112). The minimum Vccint
voltage is 1.14V (from DS302).

Right, you asked for worst case Vccint current, which I assume means 'what's
the maximum current' the package can handle.

Assuming best case heatsinking, we can keep the case at c.0K with a perfect
liquid Helium cooled heatsink. Therefore we can dissapate 358/0.36 = 1000W.
Vccint can be 1.14V, so that's a maximum current of about 870A.

Now do you see why you're asking the wrong question? ;-) Of course my
example is a ridululous exaggeration, but your posting provided little to go
on. You need to do a proper analysis with thermal simulation tools to get a
meaningful answer, and even when you get that answer it'll be wrong!

Try this bloke's book:-
http://tkordyban.coolingzone.com/
There's a brief review of the book by an FPGA expert on Cambrian Design's
website
http://www.sonic.net/~bobperl/blogger/2006/01/book-of-month-hot-air-rises-and-heat.html

HTH, Syms.

p.s. I hereby release the copyright on this post to avoid any legal
ramifications. ;-)
 
Dear Tom,
Are you using Picoblaze to do the MAC ?
Few times ago I designed the back end of a "Small C" compiler for
Picoblaze, it may be usefull for you you can download from
www.poderico.co.uk

At moment (at work) I'm doing some reserch to see what is the cheapest
way to implement a tri mode ethernet MAC
What I found is:
1) if you go on www.opencores.org and you download the tv80 then one of
the application is a simple GMII Interface.
Now MII is half/full duplex and GMII is full duplex only, but iff you
can set up your PHY to be full duplex, then it should be easy to go
from GMII to MII.
2) on www.opencores.org you can download a free 10/100 MAC, why you
don't use this core? (also tri mode MAC and 10 G not tested yet)

3) here http://www.sics.se/~adam/uip/index.html you can download the
smallest TCP/IP stack it has been ported on... (Xilinx Ultracontroller)
AVR, PIC etc. is very good, and I reccomend it...

good luck,
Francesco
 
"Symon" <symon_brewer@hotmail.com> wrote in message
news:43e07882$0$15785$14726298@news.sunsite.dk...
Now do you see why you're asking the wrong question? ;-) Of course my
example is a ridululous exaggeration, but your posting provided little to
go
I sound like Donna Chang out of Seinfeld. Of course it should be
'ridicurous'. I need coffee.
Cheers, Syms.
 
Hi!

I have already set the option you mentioned. Using the FPGA editor I could figure out one register that was not placed in an IOB but correcting this does not solve my problems.

Best regards, S. Hagenkoetter.
 
DJ Delorie wrote:
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.
That is not quite entirely true - binaries build with gcc *are* affected
by gcc's licenses. In particular, patterns of assembly code generated
by gcc are generated verbatim from gcc's source code (or in some cases,
gcc's low-level libraries' source code), and these sections are
therefore directly affected by gcc's licenses and copyrights. There
main license for gcc's source code is GPL, but there are explicitly
stated exceptions to remove all restrictions and copyright assignments
from the generated code, precisely so that you can do as you will with
gcc-generated binaries.

If Xilinx' tools also have such verbatim copying through to the
generated bitstreams, and they do not have such stated exceptions, then
they are in a position (in my interpretation - IANAL) to claim joint
copyright ownership of the bitstream.

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.
 
Antti,
As you guys are really on this group/ community everyday and
mutually helping each others, I was over expecting /hoping to get the
suggestion fast . I really Sorry, If I had annoyed you much.

We where to looking for Unix free drivers easy and fast , or such
things are available. As our complete college network is of Unix and
we have no Windows /Linux systems at all.

Hope you get back to me with the solution on this.

regards
 
Don't know (I am a VHDL programmer :), the point I was trying to make is
that from a job prospective having SystemC on your CV might be slightly
better than having a propriety language like Handel-C. I have no idea which
one is better just that I hear more noises on SystemC than on Handel-C.

Regards,
Hans.
www.ht-lab.com



"Robin Bruce" <robin.bruce@gmail.com> wrote in message
news:1138612793.879088.282550@g49g2000cwa.googlegroups.com...
Hans wrote:
If you have to choose a C language I would recommend you check out
SystemC
which might be better on your CV than Handel-C :)

What's so good about SystemC? :)
 
: Hans wrote:
: > If you have to choose a C language I would recommend you check out
SystemC
: > which might be better on your CV than Handel-C :)

: What's so good about SystemC? :)

What's so good about AnythingC?

I have quite strong feelings that whilst a high level language than
Verilog/VHDL could be a real boon to FPGA development, C is far from a
good prototype form for such a language....

uh, in what way is C a higher level language than VHDL anyway?
C is probably not but don't forget that SystemC has all the goodies(?) of an
object oriented language and support deterministic concurrency like VHDL. I
like VHDL but I do recognise that for high level modelling you need to
resort to these kinds of languages. Perhaps one day we get "SystemVHDL"
although it seems accellera and the EDA industry have given up :-(

Hans
www.ht-lab.com
 

Welcome to EDABoard.com

Sponsor

Back
Top