From: "Christopher R. Carlen"
Subject: Re: Need advice wiring up a CPLD
Date: Thu, 03 Oct 2002 08:12:46 -0700
Organization: Sandia National Laboratories, Albuquerque, NM USA
NNTP-Posting-Date: Thu, 3 Oct 2002 15:11:48 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
Hal Murray wrote:
> [snip description of magic-box gizmo]
> Sounds like a fun project.
> I'd suggest that you look at your current collection of circuits your
> users are using and try implementing them with various proposed IO
I have to get the thing installed ASAP, because a few people are
clamoring to fix crosstalk, and to get more n-input gates. So I want to
avoid trying to route all the things I might want to try. Especially
considering that some of the other functions involve one-shots. Some of
those might work out Ok in the CPLD with digital delays, but will
require some thought to convert from the mixed signal to the strictly
Thus, my plan has been to use a CPLD that is far in excess of the
typical logical complexity that is needed, and as long as the thing lets
me route in a mostly unconstrained manner, then I anticipate it being
very rare that anything would be needed that exceeds the capabability of
Note the context here: most of the circuits currently implemented are
just n-input AND and OR gates, with a few cases of combined boolean
product and sum functions. Thus, this thing is highly overkill. But
the point is that it is 2002, so what should I put in there? To put in
a CPLD vs. discrete logic packages doesn't change the cost equation at
all, since for something like this the labor far exceeds the hardware
cost. Thus, the best thing to do is to implement the most flexible
thing that is within reason. An FPGA is overkill, but a mid-range CPLD
seems just right. The CPLD seems better than an FPGA anyway, because
this is a combinatorial heavy, as opposed to register heavy application.
If you can call a handful of ANDs and ORs heavy at all!
> How are you going to program the CPLD? Perhaps another small
> connector on your daughter card so you can plug in a PC/laptop.
Indeed, I will put a female DB9 on the front panel, to make it easy to
plug in a programmer at any time and change the config.
> Are you expecting to do a lot of programming on the fly, or mostly
> use a handful or normal/popular boxes? How are you going to test
Infrequent reprogramming. The boxes will be delivered with a "default"
configuration of a basic assortment of AND, OR, NAND, NOR, looking
similar to the existing magic boxen. Later I can modify the progamming
to suit the specializations that are in place in the various labs, as
well as start implementing some of the "more complicated" functions that
I would otherwise have implemented in a custom peice of hard-wired
hardware. Some of those special functions will ultimately become
dedicated custom hardware pieces anyway in the future. But in the short
term, if I can do it on the nice looking CPLD panel, it will be much
better that what I do now, which is to install a breadboard with a
debugged prototype circuit, sitting on a table where people can bump
into it and accidentally yank the wires out. It will sit there for
about a year typically before I have a chance to come back and convert
it into a PCB in a permanent chassis.
Thus, I hope to avoid the crudeness factor of the temporary prototype
hardware that I have sitting around in various labs waiting to be made
permanent. Of course, the CPLD doesn't help me much for analog
problems, but usually I have very similar overall circuits: a few
analog inputs get conditioned, fed to comparators, and logic-ed with
some other digital signals, then spit out some digital results. So
perhaps the next step will be to build some general purpose analog
> Are you going to program them all or will you setup a system so your
> users can program their own boxes?
Both. They will have a front panel JTAG port as I mentioned. I may
construct a little computer cart to wheel around and program the things
when needed. Or I may just install the Xilinx software on one of small
army of PCs that typically populate the labs, and do the programming
from their. Whether the users learn to program them I am not sure if
that will happen. Unlikely, I suspect. That's why they hired me, and
they are all mechanical engineers anyway, though exceptionally bright ones.
> Are you going to leave enough room on the front to attach a drawing
> of the circuit diagram? Maybe the drawing should slip over the BNC
> connectors so it's really obvious which gate is connected to which
Ah, this is a good question. I am leaning toward a "Battleship"
appearance right now, with silk screened row and column labels on the
panel. When the programming is done, the schematic can be printed, and
that will serve as a map.
Though it would be nice to have something more specific on the panel. I
had envisioned slipping a chart over the BNCs as you mentioned. Not
sure about this.
> Are the in/out LEDs really necessary of you have a good drawing?
The LEDs aren't absolutely necessary, but not that much trouble to
include. They will benefit those situations where one might wonder if a
signal is present or not, without having to connect a scope. Most of
our signals are slow. We are controlling big diesel engines. But there
are some time critical laser and camera sync pulses going around. Not
high frequency, just relative timing.
> How many are you going to make? Would it be simpler/cheaper to dump
> the LEDs, switches, and unused IO gear and always put the output
> connectors on the top (or someplace distinctive)?
I had first considered making the allocation of inputs and outputs
fixed. But my considerations of the cost of putting in the added
flexibility led to the conclusion that it was worth it to have the
selectable IOs, and the LEDs. I will make between 3 and perhaps 10 of
these things. The added hardware might increase the total assembly time
of each one by 10-20%. This is reasonable.
> If you have more IO pins than connectors, can you parallel several of
> them and get rid of your 74ACTQ14 output buffer chips? (Might be
> ugly to program.)
I like having the buffer chips in between the CPLD and the user. That
way it is likely that if they break something, it will only be an
individual channel. Also, I want to be sure that if they connect say,
16 of the outputs to actual 50 ohm loads, which my design is capable of
handling, that it won't break. Thus, I paid careful attention to things
like the maximum allowable DC current per IC package, etc. If the CPLD
drives the outputs directly, I suspect it won't be happy with having
many 100 ohm loads attached (the 50ohm cable terminations, in series
with the 50ohm back terminations).
As it stands, I can drive unterminated as well as terminated 50ohm
cables, as many as 32 terminated cables if I really want to, for a total
output of 1.6A without any risk to the CPLD. And there will be little
ringing of edges with or without terminations, due to the back
terminations. The nice thing about ACTQ or similar AC drivers, is that
by paralleling several of them, you lower the non-linearity of the
output impedance, so that you can concentrate most of the output
impedance in the purely resistive series resistor. And the ACTQs can
handle a direct short circuit on the output, with the series resistor,
indefinitely. Plus there is enough current capacity left over to drive
the LED associated with each BNC.
Oh, one other important thing! The CPLD runs at 3.3V, so I need level
Thanks for your interest.
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA