What a Xilinx fpga could do in 1988

I'm writing up a project that ran from 1988 to 1991. It involved
building an ECL-based digital processor that ran at 25MHz, working
into a couple of ECL SRAMs. Debugging the hardware was tedious and
took more than a year.

There's evidence that there was an alternative proposal which would
have dropped the processing speed to 10MHz, and I suspect that
engineers involved might have planned on doing the digital processing
in a a re-programmable Xilinx fpga.

What I'd like to find out is whether the Xilinx parts that were
availlable back then could have supported what we needed to do.

We were sampling a sequential process, at 256 discrete points.

We had two 16-bit lists of data in SRAM. One list represented the data
we were collecting (Data), and the other was a 15-bit representation
of what we thought we were seeing (Results).

Every 100nsec we would have got a 7-bit A/D converter output and would
have had to add it to a 16-bit number pulled out of the Data S/RAM,
and write the sum back into the same SRAM address (though the first
version of what we built wrote the data into a second Data SRAM amd
ping-ponged between two Data SRAMs on successive passes).

After we'd done enough Accumulation passes through our 256 element
list of Data points, we'd make an Update pass, and up-shift the
accumulated data by eight or fewer bits (depending on how many
Accumulation passes we'd done - never more than 2^8 (256), and
subtract the 15-bit bit Result representation of what we thought we
had from the shifted accumulated data.

We could then down shift the difference by anything up to 15 bits
( depending on how reliable the Results we thought we had were) and
add it back onto to our 15-bit Result representation of what we
thought we had, to improve the reliability of that particular number,
and write this improved number back into the Result store

Obviously, we had to back-fill the most significant bits of the down-
shifted number with the sign bit of the difference (and of course that
got overlooked in the first version of the ECL-based system).

In practice, 15-bits was an over-kill, and the final version of the
ECL-based system settled for a maximum down-shift of 7 bits - with the
arithemtic for longer accumulations being handed off to the system
processor, which wasn't as fast, but didn't have to to the job often
enough for it to matter..

The Updata pass could run quite a bit slower than 10MHz, but we would
have liked to use a barrel-shifter, which could set up any shift from
+8 to -7 (or -15) as we did in the ECL system, rather than a shift-
register shifter.

Would this have been practical in Xilinx fpga's back in 1988?

--
Bill Sloman, Sydney

Bill Sloman <bill.sloman@gmail.com> wrote:

> I'm writing up a project that ran from 1988 to 1991. It involved
> building an ECL-based digital processor that ran at 25MHz, working
> into a couple of ECL SRAMs. Debugging the hardware was tedious and
> took more than a year.
 
> There's evidence that there was an alternative proposal which would
> have dropped the processing speed to 10MHz, and I suspect that
> engineers involved might have planned on doing the digital processing
> in a a re-programmable Xilinx fpga.
 
> What I'd like to find out is whether the Xilinx parts that were
> availlable back then could have supported what we needed to do.

I did some Xilinx designs (but never got to implement them) in
about 1995, I believe at 33MHz on an XC4013. It took some careful
pipelining and such to get that speed.

I beleive the XC4000 series goes back to 1991, though that might be
close to the beginning.

The problem with your question is that you didn't specify an
implementation. The FPGA might, for example, have two logic blocks
that run at 5MHz used alternately, for a 10MHz throughput.
(Or three, or four, or more, if needed.)

TTL easily runs at 10MHz, so some external TTL latches could get
the clock rate down, while keeping the 10MHz, or even 25MHz 
throughput.

-- glen

On Mar 27, 11:26=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> Bill Sloman <bill.slo...@gmail.com> wrote:
> > I'm writing up a project that ran from 1988 to 1991. It involved
> > building an ECL-based digital processor that ran at 25MHz, working
> > into a couple of ECL SRAMs. Debugging the hardware was tedious and
> > took more than a year.
> > There's evidence that there was an alternative proposal which would
> > have dropped the processing speed to 10MHz, and I suspect that
> > engineers involved might have planned on doing the digital processing
> > in a a re-programmable Xilinx fpga.
> > What I'd like to find out is whether the Xilinx parts that were
> > availlable back then could have supported what we needed to do.
>
> I did some Xilinx designs (but never got to implement them) in
> about 1995, I believe at 33MHz on an XC4013. It took some careful
> pipelining and such to get that speed.
>
> I beleive the XC4000 series goes back to 1991, though that might be
> close to the beginning.

Not that close. Cambridge Instruments used Xilinx parts to rework the
digital logic in their Quantimet Image Analysis gear around 1987. It
saved quite a lot of board space and money - the TTL msi logic that
had been doing the job before (since at least 1975 in various
manifestations) took up a lot of printed board space.

> The problem with your question is that you didn't specify an
> implementation. The FPGA might, for example, have two logic blocks
> that run at 5MHz used alternately, for a 10MHz throughput.
> (Or three, or four, or more, if needed.)

If that could have been made to work, I've got my answer.

> TTL easily runs at 10MHz, so some external TTL latches could get
> the clock rate down, while keeping the 10MHz, or even 25MHz
> throughput.

The data would have been held in TTL-compatible SRAM. We only needed a
couple of banks of  256 16-bit words. Extra latches for intermediate
results wouldn't have been a problem, but I'd expect that the
buffering on the periphery of the fpga to drive the relatively high
capacitance of external tracks would have added significant extra
propagation delay.

The ECL-based variant that we did build at the time - slowly, because
it was a pig to debug - used half a dozen 1024 x 8 ECL SRAMs because
they were the smallest parts I could buy that ran fast enough. Ten
years later, the smallest fast SRAMs were closer to 1M x8.

--
Bill Sloman, Sydney

Bill Sloman <bill.sloman@gmail.com> wrote:

(snip, I wrote)
>> I beleive the XC4000 series goes back to 1991, though that might be
>> close to the beginning.
 
> Not that close. Cambridge Instruments used Xilinx parts to rework the
> digital logic in their Quantimet Image Analysis gear around 1987. It
> saved quite a lot of board space and money - the TTL msi logic that
> had been doing the job before (since at least 1975 in various
> manifestations) took up a lot of printed board space.

I meant that, as well as I remember, the XC4000 series dates to
about 1991. Earlier series were earlier than that.

-- glen

On 3/27/2013 1:29 PM, glen herrmannsfeldt wrote:
> Bill Sloman<bill.sloman@gmail.com>  wrote:
>
> (snip, I wrote)
>>> I beleive the XC4000 series goes back to 1991, though that might be
>>> close to the beginning.
>
>> Not that close. Cambridge Instruments used Xilinx parts to rework the
>> digital logic in their Quantimet Image Analysis gear around 1987. It
>> saved quite a lot of board space and money - the TTL msi logic that
>> had been doing the job before (since at least 1975 in various
>> manifestations) took up a lot of printed board space.
>
> I meant that, as well as I remember, the XC4000 series dates to
> about 1991. Earlier series were earlier than that.

I think the 3000 series was the one that took off and made Xilinx a 
household name... well, if you lived in a household of rabid digital 
design guys.

Before that was the 2000 series which was a rather limited device I 
believe.  It was more than a CPLD, but not by tons.  I think it had 64 
or maybe 100 LUT/FFs.  I never knew the details of the architecture 
because it was already obsolete by the time I got a chance to work with 
FPGAs.  My understanding is that it was an ok device for a first 
product, but was not found in so many designs.  This is possibly because 
it was replaced fairly quickly by the 3000 or because the tools were so 
arcane that not just anyone could work with it.

I think my first FPGA design was with the then new 4000 series part 
which had some significant improvements over the 3000 series.  Just like 
now, there aren't too many product starts with the older series.  So 
while the 3000 series had lots of design wins and continued to be made 
for some 15 years I believe, the 4000 started the trend of each new 
generation being the marketing focus in order to continue getting design 
wins.

-- 

Rick

On 3/26/13 4:17 PM, Bill Sloman wrote:
> I'm writing up a project that ran from 1988 to 1991. It involved
> building an ECL-based digital processor that ran at 25MHz, working
> into a couple of ECL SRAMs. Debugging the hardware was tedious and
> took more than a year.
...

> 
> Would this have been practical in Xilinx fpga's back in 1988?
> 
> --
> Bill Sloman, Sydney
> 

While I wasn't using "Brand X" at the time, I was using "Brand A" and we
were delivering a product doing comparable level (actually somewhat more
so) level of processing at the time. I think we were using ping-ponging
of memory accesses (read memory A, write the results a few clocks later
into memory B, on next pass, read memory B, write results into memory
A). I am fairly sure that the Xilinx parts available at the time were
comparable.

I've got a 1989 Xilinx "Programmable Gate Array Data Book" in my hand. Befo=
re the Internet, kids, you had to get a data book from the chip maker's loc=
al rep. If you were a hardware engineer, your office had a prominent shelf =
(or shelves) with all your data books lined up. Depending on how many, how =
current and how cool your data books were, that's how cool you were.

It has the XC3000 series, including the (infamous) XC3090, with 320 CLBs, a=
llegedly good for 9000 gates(!). That part really got people's attention. T=
he Splash I reconfigurable supercomputer was an array of XC3090s. Even the =
XC3020 with 64 CLBs and 64 IOBs was pretty useful. The databook has an app =
note for a 100 MHz 8-digit frequency counter in 51 CLBs: timebase (8 CLBs),=
 BCD counter (16), five shift registers (20), 2 control CLBs and 1 CLB to s=
uppress leading zeros.

Looking at what you were doing, Bill, I'm confident a 3000-series FPGA with=
 an SRAM attached could have done the job. Maybe even an XC3020.

  --Mike

On Tuesday, March 26, 2013 1:17:42 PM UTC-7, Bill Sloman wrote:
> I'm writing up a project that ran from 1988 to 1991. It involved
>=20
> building an ECL-based digital processor that ran at 25MHz, working
>=20
> into a couple of ECL SRAMs. Debugging the hardware was tedious and
>=20
> took more than a year.
>=20
>=20
>=20
> There's evidence that there was an alternative proposal which would
>=20
> have dropped the processing speed to 10MHz, and I suspect that
>=20
> engineers involved might have planned on doing the digital processing
>=20
> in a a re-programmable Xilinx fpga.
>=20
>=20
>=20
> What I'd like to find out is whether the Xilinx parts that were
>=20
> availlable back then could have supported what we needed to do.
>=20
>=20
>=20
> We were sampling a sequential process, at 256 discrete points.
>=20
>=20
>=20
> We had two 16-bit lists of data in SRAM. One list represented the data
>=20
> we were collecting (Data), and the other was a 15-bit representation
>=20
> of what we thought we were seeing (Results).
>=20
>=20
>=20
> Every 100nsec we would have got a 7-bit A/D converter output and would
>=20
> have had to add it to a 16-bit number pulled out of the Data S/RAM,
>=20
> and write the sum back into the same SRAM address (though the first
>=20
> version of what we built wrote the data into a second Data SRAM amd
>=20
> ping-ponged between two Data SRAMs on successive passes).
>=20
>=20
>=20
> After we'd done enough Accumulation passes through our 256 element
>=20
> list of Data points, we'd make an Update pass, and up-shift the
>=20
> accumulated data by eight or fewer bits (depending on how many
>=20
> Accumulation passes we'd done - never more than 2^8 (256), and
>=20
> subtract the 15-bit bit Result representation of what we thought we
>=20
> had from the shifted accumulated data.
>=20
>=20
>=20
> We could then down shift the difference by anything up to 15 bits
>=20
> ( depending on how reliable the Results we thought we had were) and
>=20
> add it back onto to our 15-bit Result representation of what we
>=20
> thought we had, to improve the reliability of that particular number,
>=20
> and write this improved number back into the Result store
>=20
>=20
>=20
> Obviously, we had to back-fill the most significant bits of the down-
>=20
> shifted number with the sign bit of the difference (and of course that
>=20
> got overlooked in the first version of the ECL-based system).
>=20
>=20
>=20
> In practice, 15-bits was an over-kill, and the final version of the
>=20
> ECL-based system settled for a maximum down-shift of 7 bits - with the
>=20
> arithemtic for longer accumulations being handed off to the system
>=20
> processor, which wasn't as fast, but didn't have to to the job often
>=20
> enough for it to matter..
>=20
>=20
>=20
> The Updata pass could run quite a bit slower than 10MHz, but we would
>=20
> have liked to use a barrel-shifter, which could set up any shift from
>=20
> +8 to -7 (or -15) as we did in the ECL system, rather than a shift-
>=20
> register shifter.
>=20
>=20
>=20
> Would this have been practical in Xilinx fpga's back in 1988?
>=20
>=20
>=20
> --
>=20
> Bill Sloman, Sydney

On Mar 28, 5:05=A0pm, Mike Butts <mbutts...@gmail.com> wrote:
> I've got a 1989 Xilinx "Programmable Gate Array Data Book" in my hand. Be=
fore the Internet, kids, you had to get a data book >from the chip maker's =
local rep. If you were a hardware engineer, your office had a prominent she=
lf (or shelves) with all your >data books lined up. Depending on how many, =
how current and how cool your data books were, that's how cool you were.

Been there, done that. I've got a 1986 National Linear Applications
databook on my bookshelf at the moment - though the bulk of my
databooks  are still in a box in my wife's office, on the last leg of
the journey from Cambridge via the Netherlands to Sydney. Sadly the
1989 Xilinx databook isn't one of them

> It has the XC3000 series, including the (infamous) XC3090, with 320 CLBs,=
 allegedly good for 9000 gates(!). That part really >got people's attention=
. The Splash I reconfigurable supercomputer was an array of XC3090s. Even t=
he XC3020 with 64 CLBs >and 64 IOBs was pretty useful. The databook has an =
app note for a 100 MHz 8-digit frequency counter in 51 CLBs: timebase >(8 C=
LBs), BCD counter (16), five shift registers (20), 2 control CLBs and 1 CLB=
 to suppress leading zeros.

> Looking at what you were doing, Bill, I'm confident a 3000-series FPGA wi=
th an SRAM attached could have done the job. Maybe even an XC3020.

I've found a data sheet for the XC3000 series on the web dated 1988,
and thought that I'd downloaded it. What I can find now are all dated
1998, which isn't helpful.

The reference to the Splash 1 reconfigurable super-computer is more
helpful since it gives me a 1991 reference

Custom Integrated Circuits Conference, 1991., Proceedings of the IEEE
1991
Date of Conference: 12-15 May 1991
Author(s): Waugh, Thomas C. Xilinx Inc., San Jose, CA, USA

which suggests that the parts (as opposed to the datasheet) had been
available back when we glueing chunks of ECL together. Back in 1989 I
had a datasheet for a really fast Sony ECL counter, but my
unsuccessful attempts to buy a couple suggested that it was nothing
more than vapourware. Not the first time I'd run into market-research
by data-sheet publication, nor the last. Even the AMD Taxichip - which
we did use - wasn't quite the device that the early issue datasheets
described, but once AMD had worked out how to make it right, what they
did make was fine (if not quite what they'd initially had in mind).

--
Bill Sloman, Sydney

On 3/28/2013 6:33 AM, Bill Sloman wrote:
>
> The reference to the Splash 1 reconfigurable super-computer is more
> helpful since it gives me a 1991 reference
>
> Custom Integrated Circuits Conference, 1991., Proceedings of the IEEE
> 1991
> Date of Conference: 12-15 May 1991
> Author(s): Waugh, Thomas C. Xilinx Inc., San Jose, CA, USA
>
> which suggests that the parts (as opposed to the datasheet) had been
> available back when we glueing chunks of ECL together. Back in 1989 I
> had a datasheet for a really fast Sony ECL counter, but my
> unsuccessful attempts to buy a couple suggested that it was nothing
> more than vapourware. Not the first time I'd run into market-research
> by data-sheet publication, nor the last. Even the AMD Taxichip - which
> we did use - wasn't quite the device that the early issue datasheets
> described, but once AMD had worked out how to make it right, what they
> did make was fine (if not quite what they'd initially had in mind).

Can you tell us why this is being researched so many years after the 
project?

-- 

Rick

In article <df1103e8-6e9c-42ae-abef-942ea83ba23d@ve4g2000pbc.googlegroups.com>,
 Bill Sloman <bill.sloman@gmail.com> writes:

>I've found a data sheet for the XC3000 series on the web dated 1988,
>and thought that I'd downloaded it. What I can find now are all dated
>1998, which isn't helpful.

I've got a board in front of me with a 3020 on it.  Date code is 8845.
We had a 3090 is another part of that project.

-- 
These are my opinions.  I hate spam.