These are all secret. If you will use FPGAs you have to accept that
you will be able to work only with the high-level programming tools
available for the respective silicon.
Same is valid for the CPLDs - although at least there you
can - under NDA - get the fusemap translation JEDEC -> JTAG
sequence, at least this is valid for the Coolrunner CPLD.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
i was planning to implement a programer that would work with any fpga
regards
cherin
Why do you assume they would have bothered with giving it a name in the
first place?
> i was planning to implement a programer that would work with any fpga
The fact that you're asking here pretty much guarantees that the chip
vendors won't give you the necessary information.
I would not know. How they call their secret internal data is beyond
the scope of my interest.
> or is it the mapping of the fusebits to the different bits in the file
> format?
That's definitely secret. I know of no alternative source of FPGA and
of
only one for CPLD programming software. The latter is my lc for DPS
for the original (Philips) coolrunners - and I had to do some
significant
reverse engineering back then to get to all the data I needed to do
it.
> i was planning to implement a programer that would work with any fpga
You are unlikely to get much beyond good luck wishes from anyone;
you have mine.
Other than that you will be on your own.
I would be curious to see your results if any in a years time.
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/8d6f9ce3d33b3ed3?dmode=source
Still, not a totally unpleasant outcome for the 3rd party - especially
if they paid a reasonable amount for it.
Cth
> i was planning to implement a programer that would work with any fpga
You have to differentiate between a 'compiler' type of function and a
'downloader' type of one.
The information to write a compiler is closely held - NDA, or worse.
The information needed to download bitstream files produced by
official tools is quite a bit more accessible,
usually published by the manufacturer for some formats (possibly even
with example source code), or often
already reverse engineered by someone.
In addition to a variety of HDL source file formats, configuration
files, and output file options, there are also a metric ton of
proprietary, partially understood, and fully specified intermediate
files unique to each tool flow. Listing them all would be a lengthy
exercise!
In my experience it has always been "worse", and I have been
asking.
Around 2000 I even thought I had all the info I needed from Philips
on their Coolrunners and designed some in - only to discover I
was missing an important piece of data (the multiplexor addressing
scheme). It took writing a specific software to reverse engineer that,
a few weeks of serious work.
> The information needed to download bitstream files produced by
> official tools is quite a bit more accessible,
Yep, that's what Philips had given me back then without an NDA.
Until recently Xilinx would not give even that even under NDA, but
this changed for the better since my latest thread on that in
comp.arch.fpga .
Didi
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/9468d398d151b792?dmode=source
>> Afaik, FPGAs were only reverse-engineered once: NeoCad put out a
>> 3rd-party CAD suite for some of the Xilinx parts. Their tools were
>> better than Xilinx, so Xilinx bought them, & everything went back
>> under wraps again.
> Still, not a totally unpleasant outcome for the 3rd party - especially
> if they paid a reasonable amount for it.
Well, "thanks" to the DMCA and similar legislation, these days they most
likely wouldn't receive a single dime. They'd just get their pants
sued right off 'em. They might have to consider themselves lucky if
they can avoid a jail sentence.