From: email@example.com (Peter)
Subject: A nice one-off project for a competent UK based FPGA designer :)
Date: Mon, 14 Oct 2002 13:09:50 +0100
Organization: (Posted via) GTS Netcom.
NNTP-Posting-Date: Mon, 14 Oct 2002 12:02:47 +0000 (UTC)
X-Newsreader: Forte Agent 1.8/32.548
In 1992 I designed a product which was a PC (ISA) card containing 32
(yes thirty two) XC3064 devices. It is basically a complicated pulse
generator. Each of the devices contains the same config data. There is
also an XC3030 which implemented the PC interface and some other
The FPGA config data, for all 33 devices, is loaded from a simple
program running under MS-DOS which reads in a Motorola S-record file
and loads it into the card.
The customer had a few of these, then came back in 1996 for some more.
By then, Xilinx had almost dropped these parts and I had to redesign
the card to use a TQFP version of the 3064, of a higher speed than the
original one. Fortunately it still worked!
I say "fortunately" because there have always been config loading
problems with Xilinx parts - if you had a lot of them on a board (I
last did FPGA design in 1997). They were very sensitive to the CCLK
edges, not too fast and not too slow. I had to play around with
different types of CMOS drivers to get the edges exactly right, and I
do have a 400MHz scope. There was no explanation for this behaviour,
other than the CCLK input having multi-GHz-speed and picking up
non-monotonic risetimes which a 400MHz scope did not show.
I never had this problem on any single-device FPGA products, which I
suspect is the vast majority of FPGA applications.
Also, as Xilinx parts got faster through the 1990s, the D-Q flip-flop
propagation time got faster a lot faster than the interconnect delays
got faster. This meant that designs which used long-lines (with some
short local interconnect) for clock distribution (a method freely
recommended by Xilinx in the early days) stopped working if
implemented in faster parts. Eventually, one really did have to use
just the global clock nets for any concurrently-clocked structures
(e.g. shift registers and counters), in conjunction with the CE
feature, to have any hope of reliability. An experienced Xilinx
engineer confirmed this was indeed the case.
The design I did has not been done "properly" as above, but once the
config loaded OK, it was always rock solid.
This customer now wants to buy some more of these cards. There is no
way I am going to risk building some more - unless I could get the
exact same parts, which I can't - because the cost of populating a
card with 33 expensive parts, and finding it doesn't work properly, is
just too high. I also don't have the time to do any major design work
like this, so I am offering this project to somebody interested.
Xilinx ran the XC3000 and XC4000 parts for a long time, but nowadays
things change too fast.
I will try to monitor this NG anyway but if anyone is interested in
actually doing this, taking on the risk, and paying me a small % when
it's all done. I would give him the original VL4 designs, which are
actually pretty simple, and whatever else I have. Please email me
direct on the address below. The value of the design, including a PCB
redesign if necessary, is likely to be of the order of GBP 20k. The
customer wants only two of the cards but last time he paid about GBP
One can either do this with a board containing 32 cheap little Atmel
AVRs (which, realistically, I think is a lot better than using FPGAs
if one at all can, because FPGAs keep changing, the tools keep
changing; I paid GBP 13,000 for Viewlogic 4 / XACT6.01, 2 useless
dongles, covering the XC3k and XC4k parts up to 1992 / 1996, etc). But
on a 2-off project an FPGA is probably the best way. Preferably a
common Xilinx part with a future upgrade route looking OK for another
10 years, which loads up the same way so the same PC loading program
can be used.
Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.