Franken-Systems and Electronic Design

At Nuvation Engineering we began using the term “Franken-systems” many years ago (maybe back in the late 90’s?); nobody recalls the exact moment in time. Somebody probably blurted it out on seeing a lab setup with wires running all over between development boards and perfboard circuit prototypes. We’ve certainly seen the term other places as well, so we don’t know if we came up with it first. Doubtful we did, but we do like the term, it’s a concept that customers, vendors, and new colleagues all seem to understand when it comes to electronic design.

A Franken-system refers to a collection of development boards for processors, FPGAs, sensors, and the like wired together to create a very non-form-factor early prototype in order to facilitate software and logic development. Sometimes we’ll make lab prototypes for certain circuits, sometimes we’ll have custom cables made, and sometimes we’ll go so far as to fabricate interposer cards to connect boards that have complicated interfaces, lots of connections or high-speed considerations.

Assembling Franken-Systems

Some Franken-systems are “quick and dirty” while others can look quite well put together – the latter usually being mounted on a surface of some kind and often covered with polycarbonate to avoid inadvertent hands. There’s certainly a range to these setups, but they all have a common theme – enabling on-device software and logic testing before first full prototypes are available.

A Franken-system can be assembled and put into a developer’s hands in mere days, compared with weeks or months it may take before the full prototype is available, providing a setup on which to begin testing code and logic before actual hardware is developed. Simulators and virtualization can do great things and be very helpful, but ultimately until you’re working on the actual target chip, you’re always at the mercy of how well the simulator emulated it. This is particularly important for processors and hardened IP blocks in FPGAs. When you’re running on that development board you’re learning a lot about the processor – how the programming flow works, how the debugger interface works, how the boot loader works, how the I/O multiplexing works, and so on. Chip flaws will be exposed. Library limitations will be found earlier, and in general you’re efficiently de-risking your project.

Looking beyond the processor itself is where you get into even more important results. On a good Franken-system your development board will now be interfaced to as many of the other target chips, devices and software as the hardware and software team can put together. Image sensors, ADCs, DACs, sensors, memories, transceivers, etc. – the more of these things that you can get into your Franken-system the better. The upside rapidly outstrips the time and effort required to create even an elaborate Franken-system. Timing issues, driver problems, datasheet errors, register problems, subtle limitations – these things all can come up much earlier in the project process.

Discovered Problems

While the software/logic team works with the Franken-system, they need to be ever-vigilant for the “discovered problems” that will impact the actual hardware design taking place in parallel. This is where one of the most profound upsides comes in; even a single somewhat-serious issue found through testing on the Franken-system, which allows for that issue to be resolved before the hardware prototype design is complete, pays for this activity. For example, imagine a chip-bug found in a transceiver that if unresolved would have required a prototype re-spin. And it doesn’t have to be a bug in the chip – a more common scenario is finding a subtle limitation in how a new device can be used that often only shows up in actual testing – on the Franken-system. Avoiding that re-spin saves you days or weeks of effort, and likely weeks of schedule, on top of the expense of a re-spin. That’s why Franken-systems are a key part of Nuvation Engineering’s First-Time-Right hardware design methodology.

Of course there are limits to the Franken-system approach. For example, you won’t be able to create a setup for some parts of the hardware design. For some parts you can’t get access to a development board (that issue can even apply to the main processor or FPGA, which should encourage you to look for a different processor), for some parts the wiring is impractical or too high-speed, and sometimes the processor/FPGA variant you’re using might not even have a development board in existence. These limits are drastically outweighed by the benefits, however, and are not sufficient reasons to forego the advantages.