Many moderate-size PLD (programmable-logic-device) designs consist of a number of interfaces interconnected via an on-chip bus to a microprocessor that may be on- or off-chip. This is especially true for those PLDs used in control-plane applications, where dynamic updating or information exchange is required. Although each interface is often relatively simple, the task of building all the on-chip interconnections and debugging them can be both time-consuming and frustrating. To overcome these hurdles, an increasing number of designers are using development boards with pre-designed processor-based systems to accelerate the development process.
This approach has several benefits. First, it is not necessary to assemble a great deal of the IP—or build from the chosen IP—to the on-chip bus structure. It is also important to note that the on-chip bus structure does not need to be selected and created. Secondly, it is not necessary to manually connect the various IP to the on-chip bus. This can be particularly helpful and reduce development time considerably when you consider that even a relatively small design, which uses approximately 1000 look-up tables, requires approximately 300 lines of Verilog code for the top-level hook-up. Thirdly, the time to functioning hardware is rapidly reduced with this approach. It can take days to get the basic section of the hardware and the all-important debug interface to work. Adding or removing interfaces becomes much simpler once the design has been stabilised with the debug interface operating. In addition, if modifications result in the failure of the debug interface, using this methodology it is easy to return to the last know good version of the design.
Typical development board
An example of a development environment that allows designers to start with a pre-designed system and then modify it to build a prototype before transferring the design into their final system is the MachXO mini development board from Lattice Semiconductor. Although suitable for many applications, this board was tailored for the control-plane applications that often use small, non-volatile PLDs. Figure 1 illustrates update and information-exchange functions that are typically implemented in PLDs performing control-plane applications.
At the centre of the board is the MachXO 2280, a non-volatile, flash-based PLD that provides 2280 look-up tables for logic implementation. Figure 2 shows the MachXO board and the major interfaces with which it can be used. The board provides five major classes of functionality. These are GPIO and status indicators, provided through a bank of LEDs, headers, DIP switches and push-button switches. There are common serial interfaces, for example an SPI flash memory and an I2C temperature sensor. An SRAM provides additional scratch-pad memory, and the RS232-over-USB adds an interface for debug. Finally, the JTAG-over-USB serves as an interface for device programming.
The RS232-over-USB and JTAG-over-USB interfaces are critical for the development process. Both utilise mini B-type USB connectors and can be connected via cable to USB ports on any personal computer. Once the appropriate drivers have been loaded, the JTAG-over-USB interface allows the company's ispVM software to program the PLD as required with modified designs. With the appropriate drivers, the RS232-over-USB interface allows emulation of RS232-over-USB. Drivers are included in the latest version of Linux distributions and are available for Windows XP and later. The serial port simply appears as a COM port on the host PC. This interface provides a convenient method for the on-chip design to send status information and, with appropriate modifications, debug information to the host processor.
Pre-tested SoC design
The key to how the development board accelerates development is the pre-developed, pre-loaded SoC (System-on-Chip) design that can serve as the starting point for the development of a PLD that implements control-plane functions. A typical development flow—assuming that the appropriate software tools and drivers have been loaded onto the host PC—is to firstly verify that the hardware and interfaces operate as expected; this task typically takes 5 min. At this point, the designer has proven hardware. The engineer confirms that the FPGA configuration file can be reloaded into the MachXO using the ispVM programming software; this task also typically takes 5 min. Following this, the design is recompiled using a design software, for example ispLEVER, and the engineer confirms that the resulting configuration operates as expected, a task that typically takes 10 min. At this point the designer has a known good starting point. Then the first modifications to the design can be made: if and where necessary, the design is recompiled and the new configuration can be loaded. This process typically takes 60 min, although the time taken will depend on the number of modifications that have to be made.
By following this development flow, it has been demonstrated that weeks of initial development can be reduced to a matter of hours, yielding significant time savings in a project. An overview of the SoC design is shown in Figure 3, from which it can be seen that there are six interfaces and a microprocessor interconnected by an on-chip bus.
The centre of this illustrative design is the on-chip bus. In this example, the Wishbone standard is used. This is an open-source bus standard that provides an ideal infrastructure for SoC designs. It was chosen because one of the benefits of the standard is the fact that it can be used with a variety of FPGAs or ASICs. Additionally, there is a large number of open-source IPs available with the standard's interfaces. The standard also provides a simple but flexible definition, which allows designers to trade system complexity for system performance. As the performance demands of many control-plane PLDs are relatively low, the Wishbone bus is implemented as a shared bus with the microprocessor acting as the master. The structure is that the address bus is 24bits, with the top three bits reserved for generating the slave-select signals.
The LatticeMico8 (reference design RD1026) and the associated Wishbone adapter (RD1043) are used for the processor that forms the core of the design in this example. The reference design is also open-source. This is important because often a substantial amount of code is developed for embedded processors. The open-source nature is an advantage in this case as it means that it can be implemented in a variety of FPGA fabrics or ASICs, which can protect investments that a company has already made in embedded code. The Mico8 has an 8bit data path, 18bit-wide instructions and either 16 or 32 general-purpose registers. External memory is paged with the first 8bit of address included in the relevant operating codes. The other 16bit of the address bus are controllable with registers R15 and R16. Program memory can be set between 512 and 4096 deep. In this case, up to 1024 locations of 18bit are used. Program memory is stored within two embedded block RAMs. These can be initialised to the desired contents at device start-up. As each embedded block RAM supports up to 1024 words of 9bit each, the reference design uses approximately 300 look-up tables.
New code for the Mico8 can be generated by modifying the assembly listings that are provided as part of the project files. Modified code can then be passed through the tool chain, and the appropriate HEX files can be generated. These HEX files can be used by the design tool to appropriately initialise the embedded block RAMs, which are used for program storage. In this case, the tool chain is also open-source, with downloadable source code and executable forms. The other embedded block memory is connected to the Wisbone bus. This RAM is configured as 1024 8bit words. The space is used to share data for the various menus that are displayed by the Mico8 via the RS232 interface.
The SPI interface uses a modified version of the company's SPI Wishbone controller reference design (RD1044). The SPI interface connects an external 2Mbit SPI flash memory to the Wishbone bus. The controller can be used to control up to eight slaves if required. The length of receive and transmit resisters is configurable from 1 to 32bit, although in this case 8bit registers are used. Registers are double-buffered to allow data to be received or sent while the microprocessor is servicing the interrupt request to clear the other buffer. This reference design uses approximately 113 look-up tables. The I2C interface employs the company's I2C master with Wishbone bus interface reference design (RD1046). The design supports 7 or 10bit addressing modes and an 8bit receive/transmit buffer. The I2C reference design uses approximately 234 look-up tables.
The UART design uses the Wishbone UART reference design (RD1042.) This design implements a flexible UART with similar features to those found in the common stand-alone NS16450 UART. The design consumes around 291 look-up tables. The SRAM interface is relatively simple and was coded for this particular project. It is a good example of a simple Wishbone peripheral.
So, if a brief is given to overhaul the control PLD design used in a system, it is recommended that engineers take a look at some of the development systems and pre-tested designs that are currently available. Time spent considering these could take weeks off your next design cycle, and it could make the difference in delivering the time-to-market advantage that can prove critical in today's competitive environment.
Figure 1: Typical control-plane functions implemented in PLDs.
Figure 2: The MachXO mini development board.
Figure 3: The board's pre-loaded SoC design.
