6 Jul
2000
6 Jul
'00
9:02 a.m.
Well, I'm not sure I buy the economic justification for the higher cost of
the PLCC-84 vs the PLCC-44. I'll allow, however, that your supposition
applies. However, in the case of the PGA vs PLCC is just the raw cost of
the package. If you follow the history of prices in the various packages
through the market cycle, the price offset for the PGA vs PLCC stays pretty
constant though the base price of the device moves up and down. The TQFP
and PQFP packages tend to be the cheapest but they're a pain to prototype.
Xilinx wants over $1k in onesies for their PGA packages these days. I doubt
they sell many.
I remember when the Intel folks were first selling their 80186 in PLCC.
They also had it in PGA and CLCC. At the time the PLCC went under $10, the
PGA was still over $40. Likewise, the '286 was at $6 for the PLCC when the
PGA was still over $35. I always liked the PGA for prototypes, but quickly
built a board with a PLCC socket on it so I could use the PLCC in a PGA
environment.
Dick
----- Original Message -----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: <classiccmp(a)classiccmp.org>
Sent: Thursday, July 06, 2000 12:03 PM
Subject: Re: Tim's own version of the Catweasel/Compaticard/whatever
>
> How, true! It's a good thing we're looking at a CPLD rather than an
FPGA.
Yes, this part of the discussion has moved away from talking about
designing a disk controller and become a more general discussion of FPGAs.
<big snip>
> understand why the same die in a different
package costs so much more.
(the
> PLCC84 is just under $30 while the PLCC44 is at
$5.50) Fortunately,
there's
Popularity, and the cost of making the package AFAIK. The silicon die is
cheap. PGA packages, in particular, are expensive (in one case with one
of the chips I was using, the 132 pin PGA was more expensive than a
package with a higher pin count that was less suitable for prototyping
(PQFP, maybe). A lot more expensive.
> > I can assure you that bringing out signals _carefully_, noting how the
> > timing differed from internal signals when it mattered, was a _lot_
> > easier and more reliable. It actually meant that physical circuits
> > started working and working reliably!
> >
> That requires more effort, (painstaking manual layout and floorplanning)
> than I've ever wanted to use up on an FPGA. Nowadays, when there are
over
a
million gates
in one of these babies, you either have to trust your
simulator or go nuts trying to figure out how to do otherwise.
I have come to realise that software has bugs. Often serious bugs. And
the fact that a simulator says something is no reason to necessarily
believe that the real circuit will do the same. I 'went nuts' trying to
get the simulator to do something even remotely sensible (it managed to
put a 20 ns glitch on the output of _one_ output of a synchronous counter
for no apparent reason!). Designing so that rerouting wouldn't cause
problems, then bringing out test signals most certainly 'worked for me'.
-tony