From: Andy Peters on
Hal Murray wrote:
> >A second is a simple logic analyzer. Of course, the hard part here is
> >writing a Windows (or Mac OS X or Linux) host program.
>
> USB seems like the obvious choice, but I don't think any of the low cost
> demo boards support that.

Getting data from the analyzer hardware to the host computer isn't a
problem. It's cooking up a nice display on said host computer that's
the problem, at least for me. I plead "Hardware guy, your Honor."

I will say that it was easier to get my HID stuff working on Mac OS X
than it was on Windows.

-a

From: Phil Tomson on
In article <dqflq9$sfp$01$1(a)news.t-online.com>,
Antti Lukats <antti(a)openchip.org> wrote:
>"Phil Tomson" <ptkwt(a)aracnet.com> schrieb im Newsbeitrag
>news:dqefe401nol(a)enews4.newsguy.com...
>> In article <slrndsgqr4.i5.weingart(a)irricana.cs.ualberta.ca>,
>> Tobias Weingartner <weingart(a)cs.ualberta.ca> wrote:
>>>Kevin Morris wrote:
>>>>
>>>> Any takers?
>>>
>>>Real/Complete programming information would be a very good start to a new
>>>hobby phase. But I think that all the FPGA vendors are too scared to give
>>>out this information. Come on, xilinx, altera, etc, etc. What could
>>>there
>>>possibly be so secret in the format for how to program your parts? :)
>>>
>>
>> Indeed. I don't get it either. How much can be reverse engineered from a
>> bitstream format? This closedness is a real hindrance to the development
>> of
>> an open source eco-system around FPGAs.
>>
>> Any university open FPGA architectures being developed out there? While
>> it's
>> probably too late in the game for a new FPGA company to enter the race,
>> it's
>> possible that one of the smaller, hungier players might be able to
>> differentiate themselves by opening up their bitstream formats.
>>
>> Phil
>
>Phil, Atmel AT40K/AT94K bitstream format is almost open
>eg it is available under NDA from Atmel, and open source reverse engineered
>documentation is also available - no NDA :)

NDA's don't count as open. Is the Atmel part 'capable'?

>
>As of BIG FPGA companies making their bitstream format public - do not hope!
>
>because the bitstream holds not only the 'known' bits like routing and LUT,
>but
>also factory stuff
>
>bits that compensate against technology changes, those are 'figured out' by
>actual measurement by the FPGA companies AFTER wafers are manufactured
>that is the FPGA companies makes their chips to have a little 'fine tuning'
>to
>be done, this fixing is done by bitgen and is totally invisible for the
>normal user.
>
>second there are factory test bits and settings, again something that the
>end
>user should not mess up
>
>there are some hidden FPGA primitives that are partially visible for the
>end user but not useable by end user, like PMV primitive in V4 and S3
>
>there are probably hidden features and primitives that are totally invisble
>for the end user as well.
>
>so there are reasons for keeping the bitstream non public.
>
>for Xilinx and Lattice the main bitstream info is in NeoCad "BFD" files,
>those are simple ordered lists of bit names, bitgen uses that
> info to convert an NCD to bitstream
>
>NCD file is almost 1:1 the same as the XDL file would be so actually
>pretty much of the bit info is visible for those who want to see
>

Where can one find more info on NCD and XDL file formats (and what the
acronymns stand for)? Are you implying that if one has this NCD file that one
can figure out the bitstream format?

Phil
From: Phil Tomson on
In article <43ccb0e2$0$21031$9b4e6d93(a)newsread2.arcor-online.net>,
Kolja Sulimma <news(a)sulimma.de> wrote:
>Tobias Weingartner schrieb:
>
>>>so there are reasons for keeping the bitstream non public.
>
>> I happen to disagree. We are all entitled to our opinions of course.
>> If the vendors would have a well defined format to "compile" to, and
>> a good library/port for a program to be able to take this format and
>> then generate a bitstream, that would be a start. Note, I'd want to
>> have the source available to be so that I could port this last bit of
>> "technology" to my favourite OS (by choice or necessity).
>>
>> I can't believe that these things are anything but simple portable ANSI
>> C (or some derivative)...
>
>JBits is a solution to all this. Maybe not a particulary good one, but
>you can read, modify, write bitstreams in a platform independant way.
>There is no source code available, but java bytecode that you can
>essentially call by any language you want on any platform you want.

It looks like JBits is a University-developed tool. why wouldn't the source
code be available?

>
>There are even people at xilinx working on a virtual file system to
>mount and modify the configuration of a virtex-4 by the embedded PowerPC.
>

interesting.

Phil
From: Phil Tomson on
In article <QFTyf.3436$bF.2359(a)dukeread07>,
Ray Andraka <ray(a)andraka.com> wrote:
>Tobias Weingartner wrote:
>
>>
>> I happen to disagree. We are all entitled to our opinions of course.
>> If the vendors would have a well defined format to "compile" to, and
>> a good library/port for a program to be able to take this format and
>> then generate a bitstream, that would be a start. Note, I'd want to
>> have the source available to be so that I could port this last bit of
>> "technology" to my favourite OS (by choice or necessity).
>>
>> I can't believe that these things are anything but simple portable ANSI
>> C (or some derivative)...
>>
>
>The problem is the bitstream is very tightly tied to the architecture of
>the FPGA cell. Having a well defined format tightly constrains the FPGA
>architecture to the one the bitstream format is published for. What
>that means is that either the format has to change for every fpga
>variant out there, now and in the future, or the FPGA has to be frozen
>in order to comply with the bitstream format.
>
>There is far more coupling between the bitstream in an FPGA and its
>hardware than there is between an instruction set and a processor
>architecture because of the fine granularity of the configuration of the
>FPGA. In other words, an instruction set in a microprocessor controls
>relatively few connections between some very complex blocks. The FPGA
>bit stream controls many many connections between lots of small simple
>blocks, so if the bitstream format is predefined by a standard there is
>very little lattitude for evolving the FPGA's structure.

Sure it might change with each new FPGA (or it might even change more often
than that). Still the information is somewhere. Right now I'm sure there are
internal docs at Xilinx/Altera which document the formats for their tool
developers. What would be so bad if they also put those on the web (with a
caveat of course that says, "you're on your own: we don't support you playing
with the bitstream directly, but if you want to have at it")

>
>I'm not sure I see what the big push for having bitstream access is.
>I've yet to see a compelling need for it that is not addressed by the
>existing tools (there is always XDL if you really want to bit bang).

I guess I'll have to look into this XDL to see what it is. Is it a higher
level description of the bitsteam format?

>The only reason that seems to surface is to allow outside parties to
>develop their own place and route tools. Frankly, I don't think the
>complexity of modern FPGAs is such that this type of undertaking can
>improve on or even compete with the free place and route tools already
>offered by the FPGA vendors in the timeframe between device introduction
>and obsolescence.

You're probably right, but people want to be able to tinker. There's the push
for open source tools as well as academic research into P&R algorithms, etc.
People have lots of reasons for wanting to try these sorts of things.

> Anyway, for those hadry enough to try, as I said, the
>XDL tools do give you enough access to every step of the design flow to
>allow you to play with any step you feel compelled to play with.

I'll have to google for XDL.

Phil


From: Phil Tomson on
In article <9p7ns1pch437c81ln9dunkk34bo5p2k3ab(a)4ax.com>,
Brian Drummond <brian(a)shapes.demon.co.uk> wrote:
>On 15 Jan 2006 21:39:16 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote:
>
>>In article <slrndsgqr4.i5.weingart(a)irricana.cs.ualberta.ca>,
>>Tobias Weingartner <weingart(a)cs.ualberta.ca> wrote:
>>>Kevin Morris wrote:
>>>>
>>>> Any takers?
>>>
>>>Real/Complete programming information would be a very good start to a new
>>>hobby phase. But I think that all the FPGA vendors are too scared to give
>>>out this information. Come on, xilinx, altera, etc, etc. What could there
>>>possibly be so secret in the format for how to program your parts? :)
>>>
>>
>>Indeed. I don't get it either. How much can be reverse engineered from a
>>bitstream format? This closedness is a real hindrance to the development of
>>an open source eco-system around FPGAs.
>
>Last really open system was the XC6200. But it failed commercially, at
>least in part, because it was a finer grained architecture.
>
>FPGA capacities should now be big enough to support a "virtual FPGA"
>layer on top of a real FPGA, using only the "public" parts of the
>bitstream (e.g BRAM and SRL16 contents, possibly a subset of the
>routing) to give a completely open format. Possibly a virtual XC6200,
>but probably a coarser grained architecture (mini-Spartan perhaps).
>I wonder what size Spartan-3 you would need for a virtual XC6264?
>
>This would lose a lot of capacity and performance (you may need several
>LUTs dedicated to routing for every one you can use for logic) but the
>result is likely to be at least competitive with the sort of technology
>a startup or small player has on offer.
>
>I think it would be big enough to exercise open source development tools
>until something better came along...
>

Interesting idea. Are you saying that a XC6200 model would be developed in
HDL and then run through synt, p&r, etc. and that could then be used for
downloading the bitstream to?

....but like you say, you would be taking a big performance/area hit.

If you were going to do that, then why not just create some sort of
higher level Virtual FGPA device (kind of like what a Virtual Machine is to the
software world) that would have lots of nice high-level features (high-level
macros available, etc.) and also be tunable for the underlying architecture
(depending on whether the target was Xilinx, Altera, or Lattice. Just as VMs
allow for easier porting, greater genericity, etc. maybe something like a VFPGA
could have similar advantages? Also, just like the Java VM doesn't care what
underlying architecture it's running on, this sort of thing could potentially
make it easier to port designs between FPGA families... I wonder if it could be
done such that there is a minimal impact on performance and area?

Phil