EDK : FSL macros defined by Xilinx are wrong

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.

 

[Austin Lesea]

Rick,

email me.

Austin

 

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

 

[rickman]

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?

 

[Phil Tomson]

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

 

[Jim Granville]

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

 

[Peter Alfke]

So here we have an anonymous poster challenge a fairly big corporation
in an open forum to make a "definative" (sic!) legal statement about a
complex issue.
How naive can anybody be?
If he really wants to achieve any change, he definitely goes about it
the wrong way.
This open-loop bitching is unproductive and wasteful, not even
entertaining.
Mr Anonymous Toy just enjoys ranting, and will never stop. (See other
threads)
Let's ignore him, his position is at the far-out fringe.
Enough said.
Peter Alfke, speaking for himself.

 

[Peter Alfke]

So here we have an anonymous poster challenge a fairly big corporation
in an open forum to make a "definative" (sic!) legal statement about a
complex issue.
How naive can anybody be?
If he really wants to achieve any change, he definitely goes about it
the wrong way.
This open-loop bitching is unproductive and wasteful, not even
entertaining.
Mr Anonymous Toy just enjoys ranting, and will never stop. (See other
threads)
Let's ignore him, his position is at the far-out fringe.
Enough said.
Peter Alfke, speaking for himself.

 

[Austin Lesea]

Rick,

Afraid not. Spartan folks are just not into reconfiguring, unless it is
the whole bitstream. Seems they polled their customers, and even though
they have shipped 10 million S3's to date, they see no need...

So for S3, no.

Don't know about Spartan 3E.

Now in V4, partial is supported, and even partial while running is
supported (sort of, but most would say that you have to be a pretty
expert user to do it right now).

The SDR developers are way ahead in this, and they pretty much have to
have it working, so since V4 is the choice for SDR platforms, we are
busy busy busy with the tools and support.

Austin

 

[Eric Smith]

Kevin Morris wrote:

I'm finishing up an FPGA Journal article called "Stop. Go. Yield. -
Dude! Where's my Chip?"

I'm looking for people that have had delivery problems with FPGAs -

Good! I was worried that you might be a student looking for a Verilog
design for a traffic light controller.

 

[Phil Tomson]

In article <1138316309.314750.42980@o13g2000cwo.googlegroups.com>,
<fpga_toys@yahoo.com> wrote:

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.

Actually, I think it would be difficult to get Ruby and it's libraries mixed up
with the project code. The only way I can imagine that would happen is if we
decided to embed Ruby into C code - I really don't forsee that. The scenario
you describe is not only easy to avoid, it would be difficult to create.

There's the Ruby interpreter (yes, it's GPL, but it's also dual licensed with a
much more liberal license from Matz which says "do what ye will with it", but I
digress) and libraries (mostly GPL, maybe some BSD depending on which you use).
There's our project code which would happen to be written in Ruby (though,
that's not written in stone at this point, maybe it would be C or Haskell...).
The Ruby interpreter merely runs our Ruby code. There is no inclusion of the
Ruby interpreter code (written in C) with our project code _unless_ we were to
embed Ruby (and again, I really don't forsee doing that). The Ruby
interpretter is a totally seperate entity that would just happen to run our
code.

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.

The worst case scenario as I see it is that Xilinx changes their mind on XDL
and decides they don't want 3rd party tools built around it. They send a C&D
and the code is pulled. Yes, people would be upset, however, It doesn't seem
to be something that would lead to a monetary judgement if the C&D is complied
with. I don't believe that any of the JHDLBits people had legal judgements
against them; have you heard differently?

Phil

 

[Ed McGettigan]

Phil Tomson wrote:

The worst case scenario as I see it is that Xilinx changes their mind on XDL
and decides they don't want 3rd party tools built around it. They send a C&D
and the code is pulled. Yes, people would be upset, however, It doesn't seem
to be something that would lead to a monetary judgement if the C&D is complied
with. I don't believe that any of the JHDLBits people had legal judgements
against them; have you heard differently?

As I stated earlier I don't think that the XDL format has any
protectable elements under US copyright law, but I am not a Lawyer.
I also don't believe that Xilinx has any interest in keeping the
format "closed" especially since the format is specific to Xilinx
devices and it uses our naming conventions which would be very
awkward to use for any non-Xilinx device.

My earlier statement about "use for Xilinx only devices" was intended to
reference the use of the NCD2XDL and XDL2NCD software that is included
in ISE 8.1i which would be covered under the EULA. I believe that one
of the other threads mentioned using our synthesizer (XST) to generate LUTs
and then to take the output of this through XDL and then to a non-Xilinx
device through some translator. This would be excluded by our EULA. However
using FpgaC or Ruby (??) to generate an XDL netlist and then somehow getting
this into a non-Xilinx device without using any ISE 8.1i software should be
fine.

If you are planning to use this in your project and want an official
confirmation that we wouldn't pull the rug out from under you at
a future date you should contact our legal department and ask them
for a permission to do so. We'll probably want the usual "NO WARRANTY"
stuff, but I highly doubt that it will be a problem and it should be
taken care of in a short amount of time.

Ed McGettigan
--
Xilinx Inc.

 

[Bob]

"Peter Alfke" <peter@xilinx.com> wrote in message
news:1138303332.041604.64010@z14g2000cwz.googlegroups.com...

Yaju Nagaonkar wrote:
...> Anyways, the problem I am having is that I am not able to pull PROG_B
low to reset the FPGA. The miroprocessor pin goes low but it is not
able to pull the PROG_B low at all?

What do you really mean?
The output pin goes Low, but the PROG pin does not? What is between
these pins, more than a strip of copper?
Pewter Alfke, Xilinx

Pewter? Time to lay off the beer, Peter.

Bob

 

[Adam Megacz]

Austin Lesea <austin@xilinx.com> writes:

Afraid not. Spartan folks are just not into reconfiguring, unless it
is the whole bitstream. Seems they polled their customers, and even
though they have shipped 10 million S3's to date, they see no need...

So for S3, no.
Don't know about Spartan 3E.

Well, the SNOWPLOW register is still there in S3E, right?

I mean, it's not a walk in the park, but after Atmel and Virtex it's
the next best thing (are you listening, Actel?)

- a

--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380

 

[Adam Megacz]

Austin Lesea <austin@xilinx.com> writes:

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

Ugh, after this messy thread I think I'm going to be afraid to utter
the phrase "open source" in the presence of Xilinx people at FPGA'06.
Please understand that fpga_toy's attitude is very, very far from
being typical of the people who actually make the big open source
projects work.

Richard Stallman was on campus a few months ago, and I spoke to him
about the possibility of a "GNU Gateware Compiler" under the GCC
umbrella. His response was quite positive, although after explaining
the current bitstream situation it dimmed considerably. Even so, he
remained eminently calm and never hostile or even indignant. I was
quite impressed.

My opinion is that it's just a matter of time before one of the
vendors opens the bitstream format of one of their low-end devices (or
Atmel comes out with a bigger device -- same effect). Personally, I'd
much rather see it be Xilinx -- that would be convenient for me in a
number of ways. But ultimately I'll be jumping on whichever boat
leaves the pier first, likely taking a lot of impressionable young
undergrads with me...

Cheers,

- a

--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380

 

[Antonio Pasini]

The accesses on the xcl bus is only read cachemiss cacheline fills and
write through address/data. It's not a general bus for doing a fetch of a
whole matrix.

Göran,

I also have the same need: using multiport OPB sdram controller (better yet,
the mch-ddr-opb, if it works) to connect OPB and two high bandwidth
peripheral (ccd and vga controller).

Can you give some pointer to relevant docs about XCL protocol ?
Documentation is _very_ scarce on this subject.

An example with MB for S3/S3E would really jumpstart my design. I would also
pay some support fee for that!

 

[Symon]

"Pete Hudson" <pete.hudson@baesystems.com> wrote in message
news:1138358605.349842.85640@z14g2000cwz.googlegroups.com...

I have been presented with a c program to implement on an fpga.
I am investigating the possible processes/tools I could employ rather
than a straight rewrite in VHDL.

Current candidates are:

Impulse C
Handel-C
Xilinx System Generator

The algorithm is littered with sin cos sqrt & divides. So I expect that
I require some of the xilinx IP cores that come with my ISE tool.
(That's why XSG is getting a look in)

Q. How do I implement this algorithm's cos functions (for example) in
Impulse C so that it is represented in the resultant HW?

Hi Pete,

There's a guy here on CAF who's something to do with FpgaC.
http://fpgac.sourceforge.net/
Perhaps you could ask him to help implement the COS function, he seems to be
at a loose end! ;-)

Back in the real world, I think you're gonna have to code this in an HDL. I
suggest doing some research on CORDIC algorithms.
Alternatively, For SIN/COS you might consider the Sunderland algorithm and
the sine-phase difference algorithm.
For square roots, I like this:-
http://lib.tkk.fi/Diss/2005/isbn9512275279/article3.pdf
HTH.
Cheers, Syms.

 

[John_H]

Dominik Froehlich wrote:

hi,

for some devices xilinx ise offers an option to convert internal
tristate buffers to equivalent logic. however, i cannot find any
information how this works in detail.

i understand that all tristate buffers driving one signal can be
replaced by a multiplexer or equivalent logic. the problem is how the
selector logic is derived from the original enable signals. if multiple
enables are active concurrently, is there a sort of prioritization?

why is the conversion restricted to specific devices?

any hint, or even conference papers, manuals, etc. are very welcome.

thank you in advance.

dominik

The data sheet for the tristate emulators in the earliest families that
got rid of tristates described the situation beautifully; I would expect
the synthesis to do the same but I can't guarantee 100%:

When no enables are active, result is logic 1.
When a single enable is active, the result is the signal controlled by
that enable.
When more than one enable is active, the result is logic zero if *any*
of the inputs are a zero, otherwise 1.... Effectively it becomes an AND
function of the enabled inputs.

But it's never good design practice to have tristates with multiple
sources; that was a good way to put a crach in the old XC4000 parts if I
recall those days long gone correctly. I've done multiple enabled
sources myself with good results where the hardware emulation was
described in the datasheet so very well but wouldn't have done it
without that backup info.

 

[Dominik Froehlich]

John_H wrote:

Dominik Froehlich wrote:
hi,

for some devices xilinx ise offers an option to convert internal
tristate buffers to equivalent logic. however, i cannot find any
information how this works in detail.

i understand that all tristate buffers driving one signal can be
replaced by a multiplexer or equivalent logic. the problem is how the
selector logic is derived from the original enable signals. if
multiple enables are active concurrently, is there a sort of
prioritization?

why is the conversion restricted to specific devices?

any hint, or even conference papers, manuals, etc. are very welcome.

thank you in advance.

dominik

The data sheet for the tristate emulators in the earliest families that
got rid of tristates described the situation beautifully; I would expect
the synthesis to do the same but I can't guarantee 100%:

When no enables are active, result is logic 1.
When a single enable is active, the result is the signal controlled by
that enable.
When more than one enable is active, the result is logic zero if *any*
of the inputs are a zero, otherwise 1.... Effectively it becomes an AND
function of the enabled inputs.

But it's never good design practice to have tristates with multiple
sources; that was a good way to put a crach in the old XC4000 parts if I
recall those days long gone correctly. I've done multiple enabled
sources myself with good results where the hardware emulation was
described in the datasheet so very well but wouldn't have done it
without that backup info.

Dear John,

thank you for this information. The background of my question is academic,
hopefully I do not crash any devices ;-). Since there are many ways the
conversion can be done, I was interested in the particular approach that used
used by Xilinx. Unfortunately there is a lack of information here.

If you saying this was documented for the earliest device families to which
family do you refer in particular? I was seeking the data-sheets to XC2000
family but didn't find any hint :-(.

Is anybody aware of according documentation for modern Xilinx devices or even
devices of other vendors?

Thank you and have a nice weekend.

Dominik

 

[Peter Ryser]

Hi Shane,

I assume this is on a custom board, correct?

You will need to use the debugger to download the code to the SDRAM and
then single-step through your code to see what is happening. Pay
attention to the address where your code is downloaded to.

Make sure that your linker script is properly set up to run code out of
SDRAM instead from another location.

In general it's always good to start with a design from BSB (Base System
Builder) and adapt this to your custom board. BSB will also give you a
choice where to run the code from.

- Peter


munch wrote:

Hi I was wondering if I could get some help with a project I'm trying
to get started,

I'm trying to embed some C code in the PPC core of the Virtex II pro
board, while I can get small application deployed i.e. all data and
instructions reside in BRAM. The other code that I'm tying to embed
is much larger and will not all reside here so I have added extra SDRAM
the application builds correctly and downloads to the board however
when I do so I get no output off the UART which is set as STDIN/STDOUT.

Is there anyway to configure the memory of the board so that I will get
some output so I can verify that it's working?

I have tried using a different terminal program to read from the serial
port and still no joy.The Baud rate and flow control all work for the
smaller apps.

If anybody could point me in the direction of a working example I would
greatly appreciate it.

I'm using XPS 7.1 along with ISE 7.1

Thanks
Shane Lynch