Altera's Excaliber announcement last month has brought an old set of questions back into the limelight. There are questions about processes and product management: how to combine logic and PLD processes, how to choose the right CPU core and PLD.

But there is a more-interesting issue as well: architecture. It might seem that this is pretty straightforward. You put the CPU on one side of the die, and you put the PLD on the other. Unfortunately, it's what you put in between that ends up characterizing the product, more than even the choice of PLD architecture or, for many applications, the choice of CPU.

There are basically two approaches. One is to route an on-chip version of the CPU bus over to the edge of the PLD, hooking it up so that the PLD becomes, in effect, a configurable peripheral on the CPU bus. This protects the user from having to deal with CPU timing issues. It meets the requirements of most designs, which need only to add a custom peripheral, not to alter the CPU timing or its instruction set. And it makes it less likely that something the customer puts in the PLD will break the CPU.

But putting the PLD on the bus also has implications for the PLD array. A bus interface has to have fast, wide address decoders and some very quick narrow paths as well. And if it is not to block the CPU, a peripheral on the internal bus must have very precise timing. None of these are strong points of most PLD architectures. And having an entire 32-bit CPU bus physically connected to one side of the PLD array may put some interesting constraints on layout of the rest of the array. These clearly are solvable problems, but worth asking about in the context of realistic designs.

Another approach would be to give the PLD array direct access to the CPU data paths, register files and instruction decoder. While fraught with dangers for vendor and user, that approach can take the clever designer all the way to architect Nick Tredennick's vision of configurable processing. The user could add instructions, build closely coupled coprocessors or alter the operation of the data paths, putting new tasks within the reach of a modest CPU, or even adapting the CPU to the task mix on the fly.

But don't pick up that phone: From a vendor's view, the risks of supporting such a chip may not be worth it.

Ron Wilson is Publisher of Integrated System Design Magazine (San Mateo, Calif.), a sister publication of EE Times.