PDP era and a question - test-drb@ccmp.vtda.org

28 Aug 1999

please see my embedded comments below.

Dick
-----Original Message-----
From: Tony Duell &lt;ard(a)p850ug1.demon.co.uk&gt;
To: Discussion re-collecting of classic computers
&lt;classiccmp(a)u.washington.edu&gt;
Date: Saturday, August 28, 1999 11:27 AM
Subject: Re: PDP era and a question

...
 > >Please note, I am not saying that the FPGA
manufacturers should support
> >all the possible choices of machine and OS. Just that I wish that _one_
> >of them would provide enough information for me to support them myself.
> >
> The reality of the matter is that these device vendors, of whom I would
> assume it could be said they're in a good position to make such a
> determination, have decided that it's worth their effort to invest the
> effort and money in creating support tools for the PC running Windows 9x and
...
   not the PDP-8S
or whatever, running something else.  This is not my
 preference either, since I like and trust DOS much more than the WINDOWS
 varieties, but then, they no longer put out tools for the MAC either, not
 that I'd use one even if they were free.
 >> 
You are missing the point. I am not asking that the FPGA companies
produce/support tools that run on <whatever>. I am simply asking that
they allow me to create said tools.
 Unfortunately, your desire to do that is in the toiled right along with the
manufacturers' competitors' wish to learn what changes were made in order to
field the last batch of "enhancements."  Their perception is that too much
detail about the parts' configuration details is too much detail about the
inner workings of their product.  It's their intellectual property, so if
they wish to be able to protect it in court when someone steals is by
whatever means, they have to show they've applied due dilligence throughout
their operation to protect that information.  If they don't, they run the
risk that a competitor's lawyer will say, in court, that this information
was not valuable enough to protect in the one instance, so why are they
upset that someone acquired it through other means.  It's a valid point.
That's why many vendors don't give "free" copies of software anymore. 
The
courts have found that if your product is valuable enough to prosecute
someone for "stealing" it, then it should be so valuable that it can't be
given away.  Now, I'm not sure I buy all that, but that's the direction
things seem to run.
...

Think of microcontrollers for the moment, particularly the Microchip PIC.
I use that chip a lot. Now, I can either use the (free) Microchip
assembler/simulator that runs on PCs, or I can take the databook off the
shelf and write my own assembler/simulator. The necessary information is
given to do that.

There is another reason I want this information. I want to create
self-modifying circuits, reconfigurable CPUs, etc. And I can't do that if
I am forced to use the manufacturers tools for every change in configuration.
...

 Not all vendors will give you all the necessary information to do that.
Most makers of microcontrollers will, though.
>Most (all?) of the existing work on such systems was done using the
>now-discontinued Xilinx XC6200 series. Those were fully documented (I
>have the data sheets).
...

 >[...]
>
>> >There was a _supplied_ program that would take a configuration bitstream
>> >and turn it back into a CLB + interconnect map - essentially a
>> >disassembler. Of course turning that map into a schematic was a lot of
>> >work, but the 'secret' part was there.
>> >
>> >But no way would they tell us what any of the bits in the configuration
>> >file actually meant.
>> >
>> >I am told they might have supplied some documentation under an NDA, but
>> >that's no use for open-source software, of course.
>> >
>> Well, it's not likely that you'll encounter much cooperation in your
effort
...
 > to convince the world to share its secrets.  These
days, when patents are of
...

Hmm... Since the architecture of the FPGA is already pretty well
described in the databook, releasing exactly how the bitstream configures
the chips is not giving that much more away.

[...]

> I'm surprised that there was a commonly available scf2xnf (or whatever it
> was called) translator, since that essentially reverse engineered your
> product for your competitor, but it would surprise me even more for the
> vendor to provide you the ability to see how they've enhanced their parts
if
...
   that's
reflected in their configuration files. 
The Xilinx tools I used (admittedly a few years old now) had a program
that let you edit the CLB/interconnect map yourself. And a program to
turn a bitmap into whatever file (xnf?) that this program would work with.

Of course reverse-engineering a schematic from the CLB map is at least as
hard as reverse-engineering a large board of TTL chips. So it's not that
much help in copying a competitor's design.

Back in the early '80's I found that dirt simple.  I can remember many a
trade-show where my partner would, after we had examined a new product, buy
me a cup of coffee and hand me a couple of extra napkins so I could draw a
schematic of what I perceived the "new" product to be.  Knowing how things
worked and what the various TTL parts did made that into child's play.  As a
result, our products were almost always "better" than theirs.
>
>Any changes in the internals of the part (as it appears to the user - say
>extra interconnect resources) were clearly visible using these tools and
>were (IIRC) documented in the data sheets. As I said above, the data
>sheets I have are reasonably details on what the chip contains and how it
>works, but don't give the information to actually use it.
...

 >> Nevertheless, perhaps you need to back away from your devotion to the
>> absolute notion of fully open source in favor of a really efficient,
>> particularly cost-efficient, PDP whatever you want to build.  If you need
to
...

I don't particularly want to make a PDP-anything. And if I did, I
certainly wouldn't use an FPGA...
 You'd only do that if you intended to make your version better, faster, and
less costly, along with less trouble to repair.
...

If I use FPGAs (myself, for one of my own designs), I would want to
exploit the fact that they are reconfigurable parts. In other words, to
change bits of the circuit as the machine is running. Not just use them
as a replacement for a lot of TTL.

> have sources in order to fix what you consider to be an annoying bug in the
...
 > software tools with which the FPGA is to be
devised, I'd point out that 
...

Hmmm... I've spent far too many long nights as a result of bugs in FPGA
tools. I'd much rather be able to see what they're doing to my circuit.
 Well, if you're getting paid on time and materials, then it's someone
else's
worry, isn't it, if they specify a device with buggy software support.  If
you have your way, you specify a product which doesn't have those problems.
...

> noone else is able to fix it either.  Sometimes it's necessary to live
with
...
   those
"bugs" which annoy you most. 
Ah... But I have this ingrained objection to 'living with bugs'. If I
have a product (hardware, software, whatever) that doesn't work as I want
it to (or doesn't work correctly), I modify it. Period.
 Perhaps that has more than anything else to do with your inability to find
work.  If you're so prone to get caught up in "fixing" what others
don't
even perceive to be broken, that you can't work with those tools, perhaps
it's your outlook that needs fixing.  In any case, perhaps a look in your
own closet is warranted.  I know I wouldn't hire someone who was not at all
concerned about protecting intellectual property I had bought and paid for
and who felt that it was more important to make a board easy to clone that
it was to make it lower in cost and more reliable.  Don't you think your
outlook has some questionable perspective issues?

If you're an engineer, your job is to solve the problems which confront you
today with the resources at your disposal today, and not to lament the fact
that someone built the XYZ round instead of square so it would stack neatly,
and not to dream up technology which isn't yet commercially viable.  Today's
software isn't bug free, nor is it "open" enough to suit you.  That is
what's on the table, though.  Refusing to use current hardware/software
because it's not "open" enough isn't going to put a roast on the dinner
table next Sunday, either.

Maybe your talents would be better spent figuring out a better way to do
what "the boss" wants, rather than trying to figure out a better thing to
do.  It's pretty apparent you have a good understanding of how the things
work.  It's also apparent you're capable of making the necessary leap.

If you figure out a better way to do something on one of those computers you
don't want with that OS you dislike, and sell it to .001% of all the users
out there, you'll be wealthy beyond your wildest dreams.  (You'll also
develop different priorities where intellectual property is concerned!)
OTOH, if you make an improvement to all the PDP-anythings still in use out
there and sell it for 10x what it's worth, you'll still be as poor as ever.
(well . . . maybe not poor . . .  but the tax collector still won't remember
you by name.)

I haven't seen an FPGA (yet) which has "soft" configuration which can be
changed on the fly.  I think Triscend (www.triscend.com) may be heading in
that direction, together with their 805x core.  I've read a little about it,
but as far as I know, the way to change it is to reset and reload the part,
perhaps from a different configuration file.

One thing I find shameful about the FPGA makers is that they have all this
secrecy about one aspect or another of THEIR intellectual property as
pertains to their parts, yet they do absolutely nothing to protect YOUR IP
as it sits in a completely visible medium.  If they would at least provide a
feature to allow you to flash in a persistent encryption circuit not
detectable from the outside but permanently associated with a given design .
. .

...
 -tony