EDK : FSL macros defined by Xilinx are wrong

[Hans]

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 You can download a free
event based simulator from OSCI. The userguide contains some examples for
VHDL/Verilog designers. I would also check out Opencores's sc2v SystemC to
Verilog converter,

http://www.systemc.org/web/sitedocs/library_2_1.html
http://www.opencores.org/projects.cgi/web/sc2v/overview

Hans.
www.ht-lab.com

"Roberto" <gioeroby@NOSPAMlibero.it> wrote in message
newsm2Df.150825$65.4246679@twister1.libero.it...

"Mahmoud" <mahmoud.kassem@gmail.com> ha scritto nel messaggio

What are you trying to do (design)?
Why did you choose Handel-C? why not VHDL or Verilog?

i yet studied VHDL and i would like to study a new language as Handel-C.
Do you counsil me VHDL? why?

 

Larry Doolittle wrote:

or just sit down and release the XDL formats and library
interfaces, along with the exposed chip architectures and
routing that all of the above listed projects have already
fully disclosed.

Whoa, where did "library interfaces" come from? Now you're talking
software, not just documentation. Drop that item from your wish
list. You'll raise fewer hackles.

The "exposed chip architectures" are very sensitive to Xilinx, but
I think they would listen to a reasoned argument that information
of that type can not be put back in the bottle. Too much of it is
already out there in the patent literature, for example.

I know it's a huge mouthfull for Xilinx to swallow. But let's face it,
that just publishing the file format for XDL isn't enough. An project
that then publishes an XDL output file which would instantiate a
design, is then releasing the library interfaces and chip geometry
information. Any project that posts a synthesis tool that generates
library calls with placement/routing information would be publishing
the library interfaces and chip geometry/routing details of the device.
While some of this is in the data sheets, most of it is not.

Just documenting the XDL file format would leave nearly all the
university projects listed in violation of the EULA because of the
IP inside the XDL files themselves, and the programs which
generate/manipulate them.

 

Simon Peacock wrote:

This is also true.. but that is NOT what a C programmer calls C code ;-)
If you are going to write Boolean equations in C then you might as well use
one of the "official" languages as others can help.
my two cents

Simon

P.S. I didn't see any sin functions

Sorry ... but the arithmetic functions in every synthesis tool are
reduced to
the boolean equations too ... FpgaC included. My point is that C based
HLL's, or even the HLL versions of them, can do just as good a job at
both
the boolean's and the arithmetics, as you will see in VHDL doing
arithmetics.

Nope .... but didn't you get the point that better arithmetics are on
the list
of development projects for FpgaC? And that working with someone to
implement them in a useful way would just add to the value of FpgaC?

 

For all of those that have asked me "can you make us one" here is your
chance to win one. The Raggedstone1 RS1-1500 special is only available under
certain circumstances and not normally sold as a one off product so we're
not selling it but giving it away it.

Competition details are here
http://www.enterpoint.co.uk/competition/comp1_7_3_2006.html . Entries by 5th
March 2006.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The $90 Spartan3 Development Board.
http://www.enterpoint.co.uk

 

Hi John,
"But it's never good design practice to have tristates with multiple
sources; "

I disagree with your opinion.

Tristate gates are used everywhere in an ASIC chip with no exception of
FPGA. BLOCK RAM in Xilinx chip has to use tristate to get the selected
data to output.

In my opinion, there are two types of tristate buses:
1. Passive. It works well for interrupt system. If one of sources is to
assert, it pulls down the bus. If it is to deassert, tristate the
output and leave the bus to return high state by a pullup. It cannot be
used for fast data transactions.

2. Active. It works well for any multiple mutually exclusive sources to
drive a data bus. The example is BLOCK RAM in Xilinx FPGA. In a normal
FPGA design, the tristate bus can be safely used for the last stage of
data output. This type of tristate buses is active because only one
source drives the data bus at each clock, either high or low, there is
no limit on its driving data.
In my many designs, tristate data bus for the last stage of data
outputs is much better than combinational logic.
I will do a comparison between a tristate bus and its logic equilance
for Xilinx chip to see if there is any impact on the performance. I
have been always using tristate bus for my last stage of data outputs.

By the way, there is an patent from Xilinx: 5,677,638 "High Speed
Tristate Bus with Multiplexers for Selecting Bus Driver". It deals with
what you want to know. One trick is you always can find the most secret
or core technology of Xilinx by reading their patents. All patents must
meet a requirement that can be implemented by people in the art. We
always belong to the people in the art.

In my opinion, there are many smart and brand new ideas imbedded in the
1100 patents of Xilinx that give you many lessons, teaching and
experiences that couldn't get from college or textbooks, but they also
expose many points that can be further improved.

Altela seems to adopt another type of strategies and tries to keep its
secrets as commercial ones. Recently Alterla has gotten few patents. I
don't know why.

Weng

 

[John_H]

wtxwtx@gmail.com wrote:

Hi John,
"But it's never good design practice to have tristates with multiple
sources; "

I disagree with your opinion.

If an unseasoned engineer is developing code or if the code can be
targeted by engineers months later into an architecture where the
tristates are no longer "equivalent" tristate functionality, problems
may arise. The tools will not exclude two drivers active at once. The
new architecture with the real internal tristate might go pfffft. To
Dominik's credit (the original poster) he's trying to find out about the
less-than-clear practice of synthesis providing tristate emulation.


Careless use of tristates is especially bad if a later retargeted
architecture is an ASIC.

If you know everything you're getting into, tristates with multiple
*simultaneous* sources is fine but the code can't be moved to an
architecture where the internal tristate bus contention will fry the
device (any implementation with one source active at a time is fine, but
multiple active drivers is not - perhaps this nuance wasn't communicated
well before).

As I stated in the original reply, I indeed designed a
multiple-simultaneous-source tristate bus in the FPGA architecture where
the behavior of the tristate emulation was very clear. It would not be
good design practice to do this willy-nilly but only to do it when it's
guaranteed there will be no disasterous side effects now or for other
engineers later.

And as you pointed out, it is just my opinion.

- John_H

 

[Phil Tomson]

In article <bihpt1t46dm7afskbo72gqe1qb9fi5j3c2@4ax.com>,
Brian Drummond <brian@shapes.demon.co.uk> wrote:

On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:


I've set up a wiki space for discussion of ideas for an open source XDL tool
suite. For those not familiar with wikis, they are collaborative web spaces
that can be edited by anyone (for now it is editable by anyone; if there are
problems we can restrict edit access to approved authors) or by a
select set of individuals. They're used quite commonly for software projects
now as they are great for discussion of features, todo lists, idea boards, etc.

If you had tools that could parse and programatically generate XDL how would
you use them? Some suggestions have been made in other recent threads here on
comp.arch.fpga, now let's collect those ideas in the wikispace that I've setup
here:
http://thoughtfiz.stikipad.com/XDL_Tools/

Thanks Phil...

ummm...

is there any way to access it?

it keeps asking me to login (which I don't mind, except that I don't
have an account, and there's no "register" button

It appears to be a bug at stikipad (it's a fairly new service). I keep tryinng
to edit the configuration so that the wiki is viewable by anyone, but it keeps
reverting back to 'viewable by authors only' mode. I sent an email to support.
In the meantime, you could become an author by getting an account at stikipad:
http://stikipad.com
Then you'd be able to log in. (BTW: it's a pretty cool service, if you sign up
you get one free wiki)

There is a Feature Request page you'll see on the home page. You can go to
that page and edit it or you can add comments to any page by clicking on the
'Discuss' link at the right hand side of the page.

well that's one "feature request" but you'll forgive me for not posting
it in the right place

- Brian
(who is almost sorry for "pushing" XDL having seen what the discussion
degenerated into)

No problem. Definitely looking forward to your input.

Phil

 

[Phil Tomson]

In article <drihtm$qg9$01$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:

"Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag
news:bihpt1t46dm7afskbo72gqe1qb9fi5j3c2@4ax.com...
On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:


I've set up a wiki space for discussion of ideas for an open source XDL
tool
suite. For those not familiar with wikis, they are collaborative web
spaces
that can be edited by anyone (for now it is editable by anyone; if there
are
problems we can restrict edit access to approved authors) or by a
select set of individuals. They're used quite commonly for software
projects
now as they are great for discussion of features, todo lists, idea boards,
etc.

If you had tools that could parse and programatically generate XDL how
would
you use them? Some suggestions have been made in other recent threads
here on
comp.arch.fpga, now let's collect those ideas in the wikispace that I've
setup
here:
http://thoughtfiz.stikipad.com/XDL_Tools/

Thanks Phil...

ummm...

is there any way to access it?

it keeps asking me to login (which I don't mind, except that I don't
have an account, and there's no "register" button

There is a Feature Request page you'll see on the home page. You can go
to
that page and edit it or you can add comments to any page by clicking on
the
'Discuss' link at the right hand side of the page.

well that's one "feature request" but you'll forgive me for not posting
it in the right place

- Brian
(who is almost sorry for "pushing" XDL having seen what the discussion
degenerated into)

Hi Brian,

agree 'degenerated' is a mild word for whats happened - XDL has been around
for pretty long time and if those interested in the use of XDL have not done
so far, well that is not the fault of Xilinx (and its license policy).

hum, as of the Phil's setup thing, it looked weird that someone is password
login authorization protecting websites about some Open-Source discussion.
At first I did not want to register at all, then did come back determined to
register, but failed to register completly as there seems to be no way to
access the pages at all


Antti Lukats
http://help.xilant.com/XDL:Tools

Antti,

As I mentioned in the post in reply to Brian, the wiki is hosted by
http://stikipad.com - they let you host one wiki for free. I think there is a
bug in their system that does not allow me to make the wiki viewable to
everyone. If you go to http://stikipad.com you can sign up for an account and
then you can view the wiki. Hopefully this problem will be addressed soon so
that you won't have to sign up.

Phil

 

[Phil Tomson]

In article <drihtm$qg9$01$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:

"Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag
news:bihpt1t46dm7afskbo72gqe1qb9fi5j3c2@4ax.com...
On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:


I've set up a wiki space for discussion of ideas for an open source XDL
tool
suite. For those not familiar with wikis, they are collaborative web
spaces
that can be edited by anyone (for now it is editable by anyone; if there
are
problems we can restrict edit access to approved authors) or by a
select set of individuals. They're used quite commonly for software
projects
now as they are great for discussion of features, todo lists, idea boards,
etc.

If you had tools that could parse and programatically generate XDL how
would
you use them? Some suggestions have been made in other recent threads
here on
comp.arch.fpga, now let's collect those ideas in the wikispace that I've
setup
here:
http://thoughtfiz.stikipad.com/XDL_Tools/

Thanks Phil...

ummm...

is there any way to access it?

it keeps asking me to login (which I don't mind, except that I don't
have an account, and there's no "register" button

There is a Feature Request page you'll see on the home page. You can go
to
that page and edit it or you can add comments to any page by clicking on
the
'Discuss' link at the right hand side of the page.

well that's one "feature request" but you'll forgive me for not posting
it in the right place

- Brian
(who is almost sorry for "pushing" XDL having seen what the discussion
degenerated into)

Hi Brian,

agree 'degenerated' is a mild word for whats happened - XDL has been around
for pretty long time and if those interested in the use of XDL have not done
so far, well that is not the fault of Xilinx (and its license policy).

hum, as of the Phil's setup thing, it looked weird that someone is password
login authorization protecting websites about some Open-Source discussion.
At first I did not want to register at all, then did come back determined to
register, but failed to register completly as there seems to be no way to
access the pages at all


Antti Lukats
http://help.xilant.com/XDL:Tools
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Antti,
It seems you already have a wiki with an entry for XDL tools, can we use it if
we can't get the stikipad wiki to be publicly viewable?

Phil

 

[Phil Tomson]

In article <drk7173uhr@enews3.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:

In article <drihtm$qg9$01$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:
"Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag
news:bihpt1t46dm7afskbo72gqe1qb9fi5j3c2@4ax.com...
On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:


I've set up a wiki space for discussion of ideas for an open source XDL
tool
suite. For those not familiar with wikis, they are collaborative web
spaces
that can be edited by anyone (for now it is editable by anyone; if there
are
problems we can restrict edit access to approved authors) or by a
select set of individuals. They're used quite commonly for software
projects
now as they are great for discussion of features, todo lists, idea boards,
etc.

If you had tools that could parse and programatically generate XDL how
would
you use them? Some suggestions have been made in other recent threads
here on
comp.arch.fpga, now let's collect those ideas in the wikispace that I've
setup
here:
http://thoughtfiz.stikipad.com/XDL_Tools/

Thanks Phil...

ummm...

is there any way to access it?

it keeps asking me to login (which I don't mind, except that I don't
have an account, and there's no "register" button

There is a Feature Request page you'll see on the home page. You can go
to
that page and edit it or you can add comments to any page by clicking on
the
'Discuss' link at the right hand side of the page.

well that's one "feature request" but you'll forgive me for not posting
it in the right place

- Brian
(who is almost sorry for "pushing" XDL having seen what the discussion
degenerated into)

Hi Brian,

agree 'degenerated' is a mild word for whats happened - XDL has been around
for pretty long time and if those interested in the use of XDL have not done
so far, well that is not the fault of Xilinx (and its license policy).

hum, as of the Phil's setup thing, it looked weird that someone is password
login authorization protecting websites about some Open-Source discussion.
At first I did not want to register at all, then did come back determined to
register, but failed to register completly as there seems to be no way to
access the pages at all


Antti Lukats
http://help.xilant.com/XDL:Tools


Antti,

As I mentioned in the post in reply to Brian, the wiki is hosted by
http://stikipad.com - they let you host one wiki for free. I think there is a
bug in their system that does not allow me to make the wiki viewable to
everyone. If you go to http://stikipad.com you can sign up for an account and
then you can view the wiki. Hopefully this problem will be addressed soon so
that you won't have to sign up.

OK, I just got the word from stikipad: it turns out that they weren't very
clear in the setup that you can only have a publicly available wiki if you pay
$4.95/month. Otherwise you can have other people sign up as authors at
stickipad.com. So, now I'm not sure if the stikipad wiki is going to be all
that useful... $4.95 isn't all that much, but I'd rather look into some
alternatives where I could host all my web projects (not just a wiki) for about
the same price.

Phil

 

[Mike Treseler]

wtxwtx@gmail.com wrote:

Tristate gates are used everywhere in an ASIC chip with no exception of
FPGA. BLOCK RAM in Xilinx chip has to use tristate to get the selected
data to output.

I can't think of a FPGA device new enough to have block RAM
yet old enough to have a real internal tri-state bus.

-- Mike Treseler

 

[Antti Lukats]

"Phil Tomson" <ptkwt@aracnet.com> schrieb im Newsbeitrag
news:drk77r4uhr@enews3.newsguy.com...

In article <drihtm$qg9$01$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:
"Brian Drummond" <brian_drummond@btconnect.com> schrieb im Newsbeitrag
news:bihpt1t46dm7afskbo72gqe1qb9fi5j3c2@4ax.com...
On 29 Jan 2006 03:37:49 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:


I've set up a wiki space for discussion of ideas for an open source XDL
tool
suite. For those not familiar with wikis, they are collaborative web
spaces
that can be edited by anyone (for now it is editable by anyone; if there
are
problems we can restrict edit access to approved authors) or by a
select set of individuals. They're used quite commonly for software
projects
now as they are great for discussion of features, todo lists, idea
boards,
etc.

If you had tools that could parse and programatically generate XDL how
would
you use them? Some suggestions have been made in other recent threads
here on
comp.arch.fpga, now let's collect those ideas in the wikispace that I've
setup
here:
http://thoughtfiz.stikipad.com/XDL_Tools/

Thanks Phil...

ummm...

is there any way to access it?

it keeps asking me to login (which I don't mind, except that I don't
have an account, and there's no "register" button

There is a Feature Request page you'll see on the home page. You can go
to
that page and edit it or you can add comments to any page by clicking on
the
'Discuss' link at the right hand side of the page.

well that's one "feature request" but you'll forgive me for not posting
it in the right place

- Brian
(who is almost sorry for "pushing" XDL having seen what the discussion
degenerated into)

Hi Brian,

agree 'degenerated' is a mild word for whats happened - XDL has been
around
for pretty long time and if those interested in the use of XDL have not
done
so far, well that is not the fault of Xilinx (and its license policy).

hum, as of the Phil's setup thing, it looked weird that someone is
password
login authorization protecting websites about some Open-Source discussion.
At first I did not want to register at all, then did come back determined
to
register, but failed to register completly as there seems to be no way to
access the pages at all


Antti Lukats
http://help.xilant.com/XDL:Tools
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Antti,
It seems you already have a wiki with an entry for XDL tools, can we use
it if
we can't get the stikipad wiki to be publicly viewable?

Phil

yes, of course.


--
Antti Lukats
http://www.xilant.com

 

[Sean Durkin]

Bob wrote:

Simply dividing the sample clock by 12 (using a DCM) doesn't give you the
boundary of the 12bit sample. You only have a one-in-twelve chance of
getting it right. There is no way to deduce the sample boundary by
inspecting the serial data stream.
I think we're getting confused here (I know I am) with the naming of our

clocks.

Now, assuming the ADC sends out, together with the data, a fast clock of
420MHz, and a slow clock of 70MHz. Now what Eric calls the "sample
clock" is the latter, which gives you the boundary of your 12bit sample.

Now as I understand it, what Eric is suggesting is to feed the FPGA with
this slow "sample clock", to have ADC and FPGA running synchonously. We
don't use the fast clock from the ADC as bit clock, but instead use a
DCM to multiply the sample clock, and use this perfectly edge-aligned
(the DCM takes care of that) clock to run the ISERDES.

Now assuming that you feed all ADCs with the same clock source and the
thermal conditions etc. are the same, all sample clocks returned from
the ADCs should be identical (maybe with a little skew because of
different trace lengths on the PCB, but the frequencies should match),
so you only need to do this once for all ADCs. As Eric said, one DCM and
two clock nets, regardless of how many channels you have.

cu,
Sean

 

[Sean Durkin]

Kolja Sulimma schrieb am 29.01.2006 15:32:

Sean Durkin schrieb:
And since the clocks you get
from the ADCs are perfectly edge-aligned,
They are not.
They are out of phase between 330ps and 860ps at the ADC (according to
the datasheet). They will be more out of phase once they arrive inside
your FPGA.
You will not get away without delay buffers at these data rates.
Yes, but as you stated earlier, THOSE are not the problem, since I have

possibilities to delay in every IOB. The calibration has to be done anyway.

What I'm trying to avoid is to introduce additional DCMs and clock nets.
Up to now, every suggestion I've heard uses at least the same amount of
DCMs and clock nets as the current solution (xapp774), which is
something I can't afford once I have 8 or even more of those ADCs hooked
up to one FPGA.

cu,
Sean

 

[Sean Durkin]

Brian Davis wrote:

I was trying to point out that that capability already exists in the
V2 derived parts, and most likely in V4 as well (esp. with the V4
differential clock tree, I'd expect one to get inverted clocks for free
with no local inversion skew penalty, but I haven't checked this yet).
Yes, you're right, inverted clocks should be easy to get. I'll check

that out sometime this week, once I find the time.

But, you were right about the IBUFDS_DIFF_OUT: Those still exist in V4,
and *tadaaa* I just found out you can actually feed the two ISERDES in
one IOB tile with those 2 inverted outputs. So all I need now is to
provide the ISERDES with 0/180 clocks. Not sure when I'll find the time
to check that out. Getting the clocks shouldn't be a problem, but maybe
driving the ISERDES in one IOB tile with different clocks is.

Clocking high speed A/D's with an FPGA generated clock is a very
bad idea, as the inherent DCM & SSO jitter will quickly render the
sub-ps RMS A/D aperture jitter specs useless, giving you maybe
a handful of effective bits worth of data at the rated A/D input
bandwidth.
You're absolutely right, which is why I'm looking for programmable

external clock sources at the moment. BTW, any recommendations?

Up to now the fastest I had these ADCs running was 40MHz (the fastest
speedgrades aren't available yet), and there it did still work reliably.

But in the future this has to work for 70MHz as well, so I'll be
transitioning to "proper" clock sources.

cu,
Sean

 

[Symon]

"CMOS" <manusha@millenniumit.com> wrote in message
news:1138614381.749921.137590@g44g2000cwa.googlegroups.com...

hi,
Im hoping to start developement using MacroBlaze softcore. currently i
got some experiance in using FPGA with vhdl implementations but never
tried soft core development. i need to know the requrements (from
hardware and software side) i should have to start this.

thanks

I did a quick Google, and Macroblaze appears to be a product which gets rid

of waste gas from sewage sludge. I hate to think what a 'softcore' was in
this context. As luck would have it, Google suggested I might've meant
Microblaze, which gave me 188000 hits! I chose this one, which has a wealth
of documentation on said softcore!
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=micro_blaze
HTH, Syms.

 

[c d saunter]

Robin Bruce (robin.bruce@gmail.com) wrote:

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

cds

 

[Bob]

"Sean Durkin" <smd@despammed.com> wrote in message
news:43ddc622$1@news.fhg.de...

Bob wrote:
Simply dividing the sample clock by 12 (using a DCM) doesn't give you the
boundary of the 12bit sample. You only have a one-in-twelve chance of
getting it right. There is no way to deduce the sample boundary by
inspecting the serial data stream.
I think we're getting confused here (I know I am) with the naming of our
clocks.

Now, assuming the ADC sends out, together with the data, a fast clock of
420MHz, and a slow clock of 70MHz. Now what Eric calls the "sample
clock" is the latter, which gives you the boundary of your 12bit sample.

Now as I understand it, what Eric is suggesting is to feed the FPGA with
this slow "sample clock", to have ADC and FPGA running synchonously. We
don't use the fast clock from the ADC as bit clock, but instead use a
DCM to multiply the sample clock, and use this perfectly edge-aligned
(the DCM takes care of that) clock to run the ISERDES.

Now assuming that you feed all ADCs with the same clock source and the
thermal conditions etc. are the same, all sample clocks returned from
the ADCs should be identical (maybe with a little skew because of
different trace lengths on the PCB, but the frequencies should match),
so you only need to do this once for all ADCs. As Eric said, one DCM and
two clock nets, regardless of how many channels you have.

cu,
Sean

Ahhhh. Ok. TI call the faster clock "SCLK", but it actually stands for
Serial Data Clock. The slower clock is "ADCLK". I think we're on the same
page, now.

Anywho, I think he's going to have a problem using the DCM to multiply by
twelve. This would require use of the FX output which can have terrible
jitter (depending on the m/n ratio used). I would be surprised if it could
capture data reliably at 480Mbps, doing it this way.

Bob

 

[Jan Panteltje]

On a sunny day (Mon, 30 Jan 2006 09:50:46 -0800) it happened Austin Lesea
<austin@xilinx.com> wrote in <drljlm$3ls1@xco-news.xilinx.com>:

All:

From our legal group-

Also, the bitstream created by using Xilinx software is owned
by Xilinx can only be used on Xilinx programmable products, for example,
FPGAs.

This looks like arather dangerous typo, I presume you wanted to write:

"the bitstream format as generated by Xilinx software "
You do not claim rights to the content of my bitstream I hope?


?

 

Phil Tomson wrote:

I've set up a wiki space for discussion of ideas for an open source XDL tool
suite. For those not familiar with wikis, they are collaborative web spaces
that can be edited by anyone (for now it is editable by anyone; if there are
problems we can restrict edit access to approved authors) or by a
select set of individuals. They're used quite commonly for software projects
now as they are great for discussion of features, todo lists, idea boards, etc.

Well Austin just clearified XDL's use:

"XDL and related info being a public use interface to ISE outside of
NDA
restrictions" is clearly prohibited.

Which basically includes any public discussion of XDL and open source
access
to XDL.