One of the greatest challenges – and opportunities – that engineers and developers face is the blind-alley – testing out that great idea to see whether or not it cuts it, and is used or abandoned. Chasing down blind-alleys is not something to be avoided. In fact, it’s something to be embraced, as part of the excitement and challenge of design. It’s more about finding those blind-alleys that really are blind quickly, and then moving on to evaluate alternate solutions.
The traditional approach to assembling a design, to test that great idea, usually means weeks or even months of hard work. That’s time that most design teams simply do not have. Consequently, they must carefully evaluate their ideas on the whiteboard and around the coffee machine, forced to take a more cautious and conservative path toward a working solution. What’s needed is an easier way to quickly assemble and test ideas, a way of reducing those weeks and months down to days.
Now more often than not, idea evaluation requires a complete system – one that includes a processor, some working code, connected IO, perhaps some signal conditioning hardware, and even some programmable logic. With this many pieces in the puzzle it’s no surprise that most engineers and designers are still stuck around the whiteboard, thinking, considering and evaluating, evaluating the risks as much as the design idea. If you’re interested in a better way of assembling and testing your ideas, well, read on.
As I mentioned, more often than not, before you can even start evaluating an idea, you need a complete system. Altium Designer, coupled to a NanoBoard, lets you build that complete system, with access to soft and hard processors with matching software development tool chains, programmable logic, all sorts of IO, and a bunch of cool test instruments that can be embedded in the design.
Rather than trying to unravel all of those pieces in this article I’ll focus on just one of them, the one that lets you assemble the processor based hardware system with alarming ease, called OpenBus. It’s so easy in fact that you’re probably not going to believe it – until you’ve tried it for yourself, that is.
Out with the old, in with the new
The traditional approach to assembling a processor based system is to create a schematic, or for a design that is destined for an FPGA, you might even code it in HDL. Tried and proven, the schematic, or circuit diagram, completely details how the entire system connects. It also spatially shows the relationships between the various elements of the system, invaluable for interpreting and understanding a complex design.
As good as it is, there is a major catch to using the schematic approach, namely, the level of detail required. Nothing is inferred in a schematic, it is a completely detailed specification of every component, pin, net and bus in the entire design. Great for a design that is destined for PCB layout, where that level of detail is essential, not so great for a design that is destined to be implemented in an FPGA, where a lot of that information can be inferred.
By working with a standard signal bus architecture, such as Wishbone, it is possible to abstract away the detailed connection information in an FPGA design. Now it’s not that the information has been forgotten, and it’s all still there. Rather, the system is automatically managing all of the lower level net and bus level connections. Altium call this capture mode OpenBus.
The image below shows before and after. In the original schematic shown at the top of the image, each component has some 20 to 50 pins that must be wired, requiring over 100 wire and bus lines in this design. Moving to OpenBus, the entire set of orange-colored FPGA components in the schematic are replaced in the OpenBus sheet shown on the lower left, by 8 simple components connected by 8 lines.
A complex schematic with a large number of interconnects is reduced to a simple OpenBus sheet, plus a top schematic sheet to connect the design to the device pins.
Like schematic capture, OpenBus design is a graphical place and connect process. Components are placed into an OpenBus document from the OpenBus Palette. Interconnect style components are placed to allow multiple components to be connected to the processor’s IO or memory bus, and the various component ports are then linked together. Each link connects the full Wishbone bus between the components, including resets, clocks and interrupts.
Components, including embedded processors, are placed from the OpenBus Palette
To connect signals from the OpenBus sheet, such as the peripheral IO and the memory buses, out to the FPGA device pins, you’ll need a top level schematic. Once a new schematic sheet has been added to the FPGA project, the Create Sheet Symbol from Sheet or HDL file command is used to create a sheet symbol referencing the OpenBus sheet, complete with the requisite sheet entries. From there the nets can be connected out to device pins in the usual way, via ports or port plug-in components and suitable constraint files.
If the OpenBus Palette does not include all the elements you need, custom design is supported on a number of levels. For example, if you’re using Altium Designer’s C-to-Hardware capabilities to compile a processor-intensive function down into FPGA logic, then you’ll place and link in an ASP (Application Specific Processor) on the OpenBus sheet. On the other hand, if you need to craft a stand-alone C module, such as a state machine, then you can wire it in (along with other extra hardware destined for FPGA logic) via the top-level schematic.
Seeming almost too good to be true, you’re first reaction is probably disbelief. Sure, you say, that deals with the wiring, what about mapping the devices in the memory space, and what about configuring their clocks, resets and interrupts? That’s all easily managed too; non-graphical information like that is configured in dialogs, as shown in the image below.
Non graphical detail, including mapping peripherals in the memory space and configuring interrupts, are configured in dialogs.
There’s much more to learn about OpenBus than can be covered in this short article, if you’re interested you can delve deeper in the Altium wiki (wiki.altium.com).
Still not convinced? Well, you wouldn’t be a great engineer if you didn’t take a lot of convincing. Take a look at the interview with Peter Stephens, the Technical Director of Gryphon Systems Engineering (www.gryphonsystems.com.au) in this issue of Envision.
A multi-storage format, multi-image format media player, designed using OpenBus.
OpenBus delivers a neat and efficient way to quickly assemble the processor and IO system hardware for a design destined for FPGA implementation. The NanoBoard then provides a physical hardware platform where you can rapidly implement the design, and get on with testing and debugging.
But the heart of any smart electronics product today is the embedded software, so being able to quickly build the application is also an essential part of efficiently testing that great idea. Meshing beautifully with OpenBus is Altium Designer’s Software Platform Builder. Delivering an equally elegant and simple solution that OpenBus brings to building the hardware system, the Software Platform Builder allows the designer to visually assemble all of the low-level driver code needed for the various peripherals used in the design, automatically bringing together driver code supplied with Altium Designer.
But that’s another story in itself, so stay tuned to hear more about it.
The entire I/O subsystem for a complex, multi-storage, multi-format media player is implemented through the Software Platform Builder, freeing the developer to focus on the high-level application code
