Due to its flexibility, the rapid-prototyping system covers the entire development cycle of a controller device. The ES1325.1 complements the ES1000 system by 16 digital I/Os and two trigger inputs each (Figure 1). The inputs support voltages between 0 and 36V, offering programmable thresholds for high and low levels (including hysteresis). The inputs are individually configurable, and support several capture modes (including PWM signals). The outputs are TTL-compatible, protected against voltages up to ±60V and galvanically isolated in groups of eight channels each. They are also individually configurable and support several modes of signal generation (including PWM signals). The TTL-compatible trigger inputs are protected against voltages up to ±80V and are galvanically isolated in groups of eight channels each. They support several trigger modes, including an angle-based signal-capture function.The channels' logical functionality has been implemented in an FPGA. A device from the Xilinx Spartan-3 family was chosen because of its attractive price/performance ratio. The XC3S1500 offers 29,952 logic cells, 32 block RAMs of 18kbits each (resulting in a total of 576kbits), 32 multipliers, 4 DLLs and up to 487 I/O cells. Due to the design's complexity, much emphasis was put on the efficiency of the development process right from the beginning. First, the FPGA's functionality was partitioned into eight functional units (cores) in order to keep the complexity of each core as low as possible. The cores are all interconnected using the OPB bus (On-chip Peripheral Bus) from IBM's CoreConnect bus family. Valuable development time could be saved using a standardised bus architecture. In addition, the Xilinx Embedded Development Kit (EDK) provided the necessary infrastructure for using the CoreConnect Busses in Xilinx FPGAs. Although the EDK was originally conceived for SoC development based on Microblaze and PowerPC processors, it can also be used for SoC development as l long as the cores are interconnected by CoreConnect buses. The same is true for the tools in the Altera environment, i. e. for the SOPC Builder and the Avalon bus.
Successfull two-pronger design approach
In order to ensure flawless functionality of the cores and the system as a whole, a two-pronged approach was used. The unit-test approach originally conceived for software-development purposes was chosen for developing the different cores. Along with the development of the VHDL source code, a test environment was devised for each component in order to execute an automated test for the component in question. ModelSim SE was used as a simulator in this context. Although the creation of a test environment may entail more overhead than the development of the component itself, this approach has proven successful because bugs can already be detected and corrected during the development phase. Concurrent with the HW/SW development tasks, another team implemented comprehensive tests for the entire system. This team had already been consulted during the definition of the system requirements in order to arrive at a common view of the ES1325.1's functionality and to ensure that testability was considered straight from the beginning. Figure 2 shows a detailed view of the design flow used for the Xilinx FPGAs. During the development of the VHDL source code, the functionality is regularly verified using the test environment and the ModelSim SE simulator. The cores themselves are synthesised using Synplify Pro. Apart from the source code (.vhd), a constraint file (.sdc) and the netlists (.edf) are required for each standard core. These files are generated using Xilinx CoreGen. Following synthesis, one or more EDIF netlists are available for each core. These netlists must then be submitted to the Platform Generator in the EDK. Two configuration files (.bbd, .mpd) must be generated for each core. While the .mpd file includes a list of all the netlists belonging to the respective core, the .mpd file is a description of the interface to the core. It is necessary to arrange the netlists and configuration files in a specific directory structure so they can be found by the EDK. TThe structure of the entire design, including the instantiation and the connectivity structure of the cores, is described in another configuration file (.mhs). It is good practice to start by creating a coarse structure using the EDK's graphical user interface. Any corrections can then be made at the textual level. The PlatGen tool (also included in the EDK) generates a VHDL file of the entire design using the .mhs file and the configuration files for the different cores. Based on this VHDL file and a constraint file of the entire design (.ucf), the full Xilinx back-end flow is executed within the Integrated Software Environment (ISE), yielding the bitstream for the FPGA after a total of five steps. For the ES1325.1, the described flow was fully automated by calling the different steps from a batch file. The XFlow tool has proven successful for automating the back-end flow. Note that the required batch mode is only available with a network license of Synplify Pro.
Troubleshooting is time-consuming
It must be expected that there will be bugs in the prototype even if painstaking tests were performed in advance. Traditional tools including oscilloscopes, logic analysers, etc. can soon reach their limits when it comes to detecting bugs in complex FPGA designs. The problem is centred around making the device's internal states visible from the outside. This problem was addressed in the ES1325.1 project by using the Identify tool. With Identify, bugs in an FPGA can be detected at a high level supporting VHDL and Verilog. As can be seen from Figure 2, Identify consists of two parts: an instrumentor used for instrumenting the source code and a debugger for the debugging process itself. In order to instrument one of the eight cores, an Identify project must first be created. This is a relatively straightforward task due to the tool's ability to import existing Synplify projects. The instrumentor then analyses the source code with the compilers already used by Synplify Pro. Therefore, no compatibility problems will occur. In order to pinpoint bugs at a later date, the IICE, which is a kind of logic analyser, is integrated into the source code. There are three variants of the IICE which differ primarily in their level of complexity. The simplest version only supports ordinary event triggers, while the medium variant supports more complex triggers by means of a counter. The third version supports state triggers with multiple states. The features of the IICE variants can be flexibly configured. In addition, it is possible to use more than one IICE. Apart from the complexity of the IICE, it is necessary to configure the signals that can be instrumented and used for capturing and/or triggering purposes. Furthermore, breakpoints can be set on certain VHDL constructs (case instructions), which is particularly helpful for detecting bugs in state machines. Once the instrumentation is complete, the regular design flow is started using the copy instrumented by Identifyfy instead of the original source code. Bug detection itself is performed using the debugger which communicates with the hardware via the JTAG interface. The connection is made with a conventional download cable (i. e. Xilinx Parallel Cable IV oder Altera ByteBlaster). Once the different devices in the JTAG chain are identified, the desired FPGA can be selected. The debugger will automatically verify the coherence between the FPGA code and the Identify project. Once the desired trigger conditions have been specified, the IICE is configured accordingly and activated. As soon as the trigger conditions are met, the recorded data is transferred to the debugger via the JTAG interface. Visualisation of this data can be done either directly in the source code or using a VCD-compatible viewer. While the trigger conditions can be modified directly in the debugger, an iteration of the entire design flow is required if a modification is made on the instrumented signals in general. Therefore, the different signals should be instrumented very carefully. Incremental instrumentation is a solution for this problem, although it is currently available only for Xilinx FPGAs. Using the development process described above, ETAS managed to deliver a complex product such as the ES1325.1 on time, meeting the customer's functionality and quality goals.
