An Open-Source suggestion for Xilinx

An Open-Source suggestion for Xilinx

In generic the decision about to use Open-Source strategies
is very complex, but there is an easy and low risc way to
at least make the first step, the portion that could be
tried as Open-Source is related to programming cable support
as first step the firmware for USB Platform Cable or at least
the protocol information could be released to the public -
the development that follows (or doesnt) could be used as
indicator if there is change for success for larger parts
of the tools to go Open-Source.

The current programming support is bad, this both on the
PC side software (impact), the host drivers and and the
embedded firmaware in platform cable(s).

There is already some effort done, I list it here

1) Impact TCP protocol has been reverse engineered
 and there is open-source cable-server
2) I have tried to make software support for Cable IV high
 speed mode, even made special FPGA-PCI design that emulates
 LPT port + Cable IV. There is no final result on that yet.
3) I have written Coolrunner disassembler in order to reverse
 engineer the Cable IV code
4) There is 3rd party replacement firmware for USB platform cable
5) possible more projects that we dont know about.

ALL THOSE efforts have been done to improve the Support
for the programming hardware manufactured by Xilinx Inc.


Xilinx Cable IV - it very seldomly works in high speed mode
Xilinx has not been able fix the driver issues, and I guess never will

Xilinx USB Cable (and embedded USB Cable) is "kinda working" but
it is only useable as download cable and XMD debug, but it can not
be used as user communucation channel to user IP cores in Xilinx FPGA.

Those issues (bad support for Xilinx programming hardare) could be
done
by "Open-Source" initiative WITHOUT Xilinx support, as the reverse
engineering needed is not complicated at all. The thing is that there
is not enough interest, so everybody keeps using the existing
solutions
the way they work, not releasing the full potential.


There is lots of open-source software that supports Cable III, and
NONE
that would support Cable IV, or Platfrom USB Cable.


just me 2 eurocents.

Antti Lukats

On 8 May 2007 03:34:20 -0700, Antti <Antti.Lukats@xilant.com> wrote:

>An Open-Source suggestion for Xilinx
>
>In generic the decision about to use Open-Source strategies
>is very complex, but there is an easy and low risc way to
>at least make the first step, the portion that could be
>tried as Open-Source is related to programming cable support
>as first step the firmware for USB Platform Cable or at least
>the protocol information could be released to the public -
>the development that follows (or doesnt) could be used as
>indicator if there is change for success for larger parts
>of the tools to go Open-Source.

<...skip all the rest of these magnificient speech...>
>

Yes Antti, that would be the solution for *lots* of problems

I would enrol on such kind of efforts.

Best regards,

Zara

I have forwarded your comments to our configuration solutiuons
group. They are working on ideas to solve the issues you listed
below.

I'm going on vacation for a week, so won't be able to respond to
all of the interesting suggestions regarding open source. Here's
my take.

OpenOffice looks like a good eample of something that fits
well with the open-source model, but I don't see that good of
a fit with our tools.

There are a few programs that we could open-source, but they
only have a few engineers working on them, so it would not save
resources since we have to manage the open-source projects.

The bigger applications like ProjNav and XPS are much more
device/Xilinx specific than most of you are implying so I don't
see an easy solution there either. XST is very device specific and
this is one of the applications that starts their work over a year
ahead of a new device introduction.

Steve

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1178620460.648853.311240@o5g2000hsb.googlegroups.com...
> An Open-Source suggestion for Xilinx
>
> In generic the decision about to use Open-Source strategies
> is very complex, but there is an easy and low risc way to
> at least make the first step, the portion that could be
> tried as Open-Source is related to programming cable support
> as first step the firmware for USB Platform Cable or at least
> the protocol information could be released to the public -
> the development that follows (or doesnt) could be used as
> indicator if there is change for success for larger parts
> of the tools to go Open-Source.
>
> The current programming support is bad, this both on the
> PC side software (impact), the host drivers and and the
> embedded firmaware in platform cable(s).
>
> There is already some effort done, I list it here
>
> 1) Impact TCP protocol has been reverse engineered
> and there is open-source cable-server
> 2) I have tried to make software support for Cable IV high
> speed mode, even made special FPGA-PCI design that emulates
> LPT port + Cable IV. There is no final result on that yet.
> 3) I have written Coolrunner disassembler in order to reverse
> engineer the Cable IV code
> 4) There is 3rd party replacement firmware for USB platform cable
> 5) possible more projects that we dont know about.
>
> ALL THOSE efforts have been done to improve the Support
> for the programming hardware manufactured by Xilinx Inc.
>
>
> Xilinx Cable IV - it very seldomly works in high speed mode
> Xilinx has not been able fix the driver issues, and I guess never will
>
> Xilinx USB Cable (and embedded USB Cable) is "kinda working" but
> it is only useable as download cable and XMD debug, but it can not
> be used as user communucation channel to user IP cores in Xilinx FPGA.
>
> Those issues (bad support for Xilinx programming hardare) could be
> done
> by "Open-Source" initiative WITHOUT Xilinx support, as the reverse
> engineering needed is not complicated at all. The thing is that there
> is not enough interest, so everybody keeps using the existing
> solutions
> the way they work, not releasing the full potential.
>
>
> There is lots of open-source software that supports Cable III, and
> NONE
> that would support Cable IV, or Platfrom USB Cable.
>
>
> just me 2 eurocents.
>
> Antti Lukats
> 

<steve.lass@xilinx.com> wrote in message 
news:f1qp4e$omc2@cnn.xsj.xilinx.com...
> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.
That's usually not the point...it's that the overall quality of the result 
can go up.

> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.
>
> Steve

I think an excellent example of how open source is managed for "bigger 
applications" with some "device specific" issues is the Analog Devices 
Blackfin uCLinux project. ADI is basically getting away from their 
proprietary VisualDSP development environment and is getting excellent 
uptake of this quite impressive capability from such a small cheap 
processor. The DSP library is ported over, so I can get excellent FIR and 
FFT performance from this 500-600 MHz chip in a modern OS and language (C++) 
development environment. It's been a pleasure to develop in it. ADI appears 
to have a team of roughly 20 engineers supporting/managing the effort, 
dozens of active contributors, and thousands of users. Now, there isn't a 
big set of GUIs to manage, but a lot of application libraries exist.

Check out http://blackfin.uclinux.org

Marty Ryba 

Steve Lass wrote:
> I have forwarded your comments to our configuration solutiuons
> group. They are working on ideas to solve the issues you listed
> below.

I think what is fundamentally needed is a well-defined protocol
that the tools use to talk to the programming/configuration hardware.
This could be either an API, or an "on-the-wire" network protocol.
Ideally the same protocol or API would be supported by both Impact
and ChipScope, though having two separate protocols (as is apparently
true today) would be OK.

If such protocols/APIs existed and were documented, there would be even
more free software solutions for configuring/programming/debugging
Xilinx-based target systems.

At that point it would be less important for Xilinx to release
the source code of their own implementation of the cable side of
those protocols, but if they did, it would be useful as a
reference implementation.

From the outside, it is hard to see how this could have any
significant drawbacks for Xilinx.  Certainly not enough to
outweigh the benefits.

One justification that companies sometimes give for NOT documenting
their APIs and protocols is that they are subject to change.  However,
this is readily handled by versioning.  If Xilinx publishes version 1
of an API or protocol, and discovers that a change or addition is
necessary to support a new feature in the future, version 2 of the
API or protocol can be released.  Open Source and Free Software is
generally very quick to adapt to such changes.

Best regards,
Eric

On Tue, 8 May 2007 15:12:39 -0600, <steve.lass@xilinx.com> wrote:

>I have forwarded your comments to our configuration solutiuons
>group. They are working on ideas to solve the issues you listed
>below.
[...]
>There are a few programs that we could open-source, but they
>only have a few engineers working on them, so it would not save
>resources since we have to manage the open-source projects.
>
>The bigger applications like ProjNav and XPS are much more
>device/Xilinx specific than most of you are implying so I don't
>see an easy solution there either.

Another possible [candidate for open-source | starved orphan within the
Xilinx toolchain] is the floorplanner. 

(a) Unless it has GREATLY improved in 9.1, it has major shortcomings
that have not been fixed in several major toolchain releases.

(b) if it properly supported hierarchical RPMs it could be a very useful
tool for high performance design, and/or allow an entry point for Open
Source to add value to component placement.

(c) [conjecture] its interfaces and device specific "knowledge" are less
detailed than ISE or the back end, therefore easier to release to Open
Source than the full tool set. 

- Brian

steve.lass@xilinx.com wrote:
 
> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.
> 
> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.

Why can't Xilinx make available the complete specification of
the configuration bitstream for a single, already obsolete
device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip
together with the guarantee to deliver this chips for at least
20 years. Then the open source community had a basis to 
develop their own design tools at least for this FPGA. And I suppose 
there are many smaller projects for which such an old chip is more 
than sufficient.

What would you say, if a CPU manufacturer doesn't make available
the processor documentation (instruction set, instruction encoding).
He only gives you a C compiler to design your software and 
anything below is the secret of the company. Nobody would buy such
a processor, but that's exactly the situation with FPGA's.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I think you may be underestimating the importance of the ancillary
stuff that people use daily and are misinterpreting what people are
asking for...

steve.lass@xilinx.com wrote:
> OpenOffice looks like a good eample of something that fits
> well with the open-source model, but I don't see that good of
> a fit with our tools.

Certainly not all of them, but...

> There are a few programs that we could open-source, but they
> only have a few engineers working on them, so it would not save
> resources since we have to manage the open-source projects.

I hope one of those tools is the programming tool suite. There
are many complaints about impact, and there are many situations
where users would just *love* to be able to customize the programmer
for their hardware.

Where I work, we've pretty much given up on being able to use
impact for anything other then writing ACE files, and it does
a clunky job at that. I suspect that open-sourcing impact would
make a *lot* of folks very very happy.

> The bigger applications like ProjNav and XPS are much more
> device/Xilinx specific than most of you are implying so I don't
> see an easy solution there either. XST is very device specific and
> this is one of the applications that starts their work over a year
> ahead of a new device introduction.

I think no one (or almost no one) thinks it is practical, or even
desirable, for you to open-source xst, map, or par, or similar
tools. And quite frankly, those tools don't have the problems that
all the other fluff has with portability.

What people want is a more open-source friendly attitude with all
the other bits. The programmer is a blatant case where there are
already several open-source programmer projects trying to make your
programmer tools useful in various situations where impact breaks
down. Give these projects active help, or turn impact into an open-
source project, and many people will be happy.

Overall, people want Xilinx to be more cooperative with open-source
up front, instead of fighting it every step on the way. If you start
with an open-source friendly attitude, then you'll surely find many
ways to be more open that *help* your business. It shouldn't be a
battle. We're not out for blood. We want to use Xilinx (or Altera,
or etc.) parts!

For the record, I have generally encountered helpful people within
Xilinx for my own open source project (Icarus Verilog) so I suspect
that this missing the point of open source is not universal within
the sheltered caverns.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGQfPUrPt1Sc2b3ikRAjaoAJ903w6q0cxgtaf+8MtNOFZs9Y9MzwCgyDn5
4EDfChTwUjuVKNysVM1/eNc=
=n5Qr
-----END PGP SIGNATURE-----

Stephen Williams schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Where I work, we've pretty much given up on being able to use
> impact for anything other then writing ACE files, and it does
> a clunky job at that. I suspect that open-sourcing impact would
> make a *lot* of folks very very happy.
Hi Steve

I just recalled, I have reverse engineered the ACE file format
even written ACE compressor and player, so the work has begun
already :)

ah, yes I can open-source the ACE player.. please remind in a few days
should i forget..

Antti

Herbert Kleebauer wrote:
> steve.lass@xilinx.com wrote:
>  
> 
>>There are a few programs that we could open-source, but they
>>only have a few engineers working on them, so it would not save
>>resources since we have to manage the open-source projects.
>>
>>The bigger applications like ProjNav and XPS are much more
>>device/Xilinx specific than most of you are implying so I don't
>>see an easy solution there either. XST is very device specific and
>>this is one of the applications that starts their work over a year
>>ahead of a new device introduction.
> 
> 
> Why can't Xilinx make available the complete specification of
> the configuration bitstream for a single, already obsolete
> device, maybe the original 5/3.3V Spartan XCS40/XCS40XL chip
> together with the guarantee to deliver this chips for at least
> 20 years. Then the open source community had a basis to 
> develop their own design tools at least for this FPGA. And I suppose 
> there are many smaller projects for which such an old chip is more 
> than sufficient.

Couple of commercial counter-points:
Xilinx like to control the EOL process, and the ultimate 'brick wall'
in this EOL is usually the close of a FAB line. So too much activity
on very old devices is not a good thing.

Another risk, is if the Open Source direction gets smarter, and develops
customer demand for the features, on NEW FPGAs, that fragments Xilinx's 
efforts.


> What would you say, if a CPU manufacturer doesn't make available
> the processor documentation (instruction set, instruction encoding).
> He only gives you a C compiler to design your software and 
> anything below is the secret of the company. Nobody would buy such
> a processor, but that's exactly the situation with FPGA's.

A better analogy could be Microcontroller Programming and Debug.
It is now quite rare to find a closed-algorithm on the uC programming 
front, as the Vendors realise production programming is widely used.
Even Debug is trending to more open, as vendors realise there is
actually little real risk in this.

In many ways the FPGA market is sluggish - they were very slow to move
from proprietary config memory, to industry std parts.
They are only on the first steps of waking up to, and using,
multi die design flows.

Lattice do have OpenSource SoftCPU efforts, and they are being well
received.

-jg