Verifying fpga based systems using Altium Designer and OpenCores

Such a test system can be created using Altium Designer and the NanoBoard3000 prototype platform. The test setup is fully transferable to any target hardware and is suitable for the test phase, as well as deployment. The approach is based on the idea that any design under test (DUT) will be expanded with an embedded system that includes a soft cpu, along with the required memory and interfaces. Next comes the generation of all necessary software plus the creation of suitable and customised virtual measurement instruments. After place and route (P&R), the DUT, the embedded system and the virtual instruments are implemented in an fpga within the NanoBoard. Time critical functions written in C (such as sequence trigger events) can also be implemented in the fpga using the C to hardware functionality within Altium Designer (see fig 1). The main advantage of this approach is that signals can now be measured and triggered in real time instead of via simulation. The embedded system features a soft cpu implemented within the NanoBoard's fpga. At system boot, the soft cpu will fetch and execute a .elf file from the NanoBoard's memory. The stimulus inside the executable can be changed without changing the soft cpu by recompiling the C code and downloading it to the NanoBoard's memory. This allows simulation to run in hardware in more or less real time. Because the behaviour doesn't have to be simulated, you measure in 'real time' to find functional errors. Imagine the DUT as a black box. Inputs are fed with arbitrary test sequences and signals; outputs are measured and compared with the expected result. Complex trigger events can be defined using 'C' and changed without reprogramming hardware. The disadvantage is that test pattern speed is limited by the processor. While a stimulus generator can be developed in HDL, the trade off is higher development costs. This approach is also less flexible, since any change requires an fpga redesign. In these cases, Altium Designer provides a compromise for hardware acceleration: an integrated C to hardware compiler allows C and C++ sources as input and translates the sequential structures for parallel processing in an fpga. By default, Altium Designer uses fpga vendor tools in batch mode for P&R of the synthesised logic in the target fpga. These tools have to be installed alongside Altium Designer, whereas vendor independent synthesis comes preintegrated with an Aldec HDL simulation engine. There is the option to use the manufacturers' synthesis and simulation tools and – for post P&R timing simulation – full licenses of established simulation tools. The TCL scripts used by Altium Designer to integrate the vendors' tools can be modified. Assuming standard strict synchronous design rules and design methods have been followed and that external signals have been synchronised, the static timing analysis delivered by vendor tools should be accurate. Otherwise, problems may be hard to find because of varying clock domains or setup and hold time violations. An example is using an OpenCores 8B10B encoder and decoder for dc free signal transmission. The first thing needed – as in every fpga project in Altium – is a top level schematic. The DUT is instantiated as a block, including any necessary constraints, and wired schematically. The entire project comprises a top level schematic with two OpenCores IPs, an embedded system with tft and memory and a customisable virtual measurement instrument for connection of all I/Os. The form and function of these virtual instruments can be modified at will, while all connected I/Os can be measured, displayed or changed without having to reprogram the fpga. In addition to configurable libraries, there is an integrated library of virtual instruments that can be used effectively in the target hardware. When designing the embedded system and soft cpu, it is also necessary to create a graphical top down document. This so called OpenBus document is later instantiated as the source of the project. The embedded system and soft cpu design also requires a graphical top down document. This example (see fig 2) uses a 32bit soft processor, including sdram and GPIO, plus a configurable Wishbone interface, tft and an additional virtual instrument. Individual blocks can be selected from the OpenBus pallet and interconnected, including correct pin configuration and specifications for the NanoBoard. Adjustments may be needed for different target hardware. Since OpenBus is based on the Wishbone standard, any OpenCores IP can be used without a bus converter, in addition to native or Altium Designer IPs. For all other cases (in this example, an 8bit interface with control pin), a configurable Wishbone interface is provided. In addition to hardware mapping, Altium Designer creates the required software for drivers, applications and services using Software Platform Builder (SPB). An operating system is not always required, keeping the executables later generated by the integrated compiler slim. The SPB automatically starts a Posix service when, for example, a tft is used. When the tft has been defined as the default output, any value can be displayed using 'printf' in the source. The necessary headers (font and screen size, line width and typeface) are predefined in the SPB. The SPB generates all source code in 'C', providing it to developers for further use and modification on any cpu platform. An integrated debugger based on Tasking technology is also available to further develop and optimise the test sequence. All types of measurement instruments and their functions can be combined graphically by dragging and dropping. The instrument's appearance can be modified while the application is running without the need to recompile the fpga. The parallel scripting engine supports flexible signal data acquisition options which don't interfere with the signal path. Once the fpga has been programmed via the hard Jtag interface, interaction with the embedded system in the fpga and Altium Designer is handled by a second Jtag interface. The required IP is also implemented in the fpga logic. When using target hardware other than the NanoBoard3000, four additional free I/Os in the fpga are required. The embedded system with soft cpu implementation allows the design of complex test sequences in C and can react to appropriate specifications. Certain trigger pulses can, for example, initiate a new action. Every developer faces the task of verifying function blocks or entire systems. This invariably requires setting addresses, going through long sequences, responding to values and displaying results. The approach described here represents a holistic approach for the generation of a complex test environment. The effort required is surprisingly low, while the range of options is extensive when using Altium Designer's full functionality. Jörg Kaleita is Altium's technical account manager EMEA. The full version of this edited article can be downloaded by following the link below.