FPGA Multicore Emulation

Our brief was to design a board around the high-performance Virtex6 550T FPGA device, which has nearly 550,000 configurable gates and a 1760-ball BGA package. The board needed to add peripherals to the FPGA to extend its usefulness for evaluating the “soft” microprocessor, including an LCD screen, CAN transceivers, FlexRay interfacing, Ethernet and ADCs. The board also needed a “System Manager”, which would in itself be a powerful Infineon TC1797 TriCore device – a predecessor of the FPGA “soft” micro – to manage bring-up of the FPGA image. The system would then be used for development of the debuggers and flash programmers themselves.

From the software side, the System Manager would need to access multiple FPGA images stored locally on an SD card and upload an image directly using the FPGA’s JTAG connection. It also has to offer the user the opportunity to select the FPGA image (before uploading) and set configuration options such as the processor speed that should be emulated.

If all that weren’t enough, the System Manager should also emulate an Infineon CIC61508 Safety Monitor device – an intelligent watchdog that forms part of the Infineon PRO-SIL SafeTcore systemin
conjunction with existing TriCores. So not much then!

Much of the design was fairly standard – interfacing for communications peripherals, multiple power supplies of varying voltages and outputs etc. The more interesting parts centred aroundchoosing the  correct FPGA banks of inputs/outputs (i/os) to allow high-speed signals and clocks to be routed correctly, together with handling multiple reset signals from multiple sources – always a headache for multiprocessor systems, let alone one where one device (the FPGA) has two operation modes, i.e. programming and running the emulation.

There was also the challenge of managing multiple signal voltage levels, at high speeds and sometimes bi-directional, for interfacing a 1.0V FPGA to 2.5V, 3.3V and 5V systems. Selection of bus translators was therefore crucial to the design.

An interesting and novel system was required to allow control of the FPGA for more unusual tasks, such as introducing disturbances into the grid array, starting/stopping the simulation etc. This meant the System Manager had to emulate the FPGA’s JTAG signals as well as providing the clock to the simulated core. This allows all manner of new possibilities which aren’t possible on normal target hardware, such as simulating drifting or jittery clocks, “flash” value changes etc. Essentially, it’s possible to speed up, slow down or stop time!

One twist to the system is that it is somewhat of a schizophrenic – before programming, the FPGA must be handled in one way, with considerations of isolating clocks and signals from the i/o pins while in this state. However, once programmed, the device effectively becomes a multicore microprocessor, which means the board itself must be able to handle both “personas” transparently.

Hardware is nothing without software – all the more so in this case where there is virtual hardware. The System Manager software could be developed separately on a standard Infineon TC1797 TriBoard development kit, which allowed us to implement and test the SD card file system, CIC61508 Safety Monitor emulation and Virtex FPGA JTAG connection using a low-end FPGA system that was compatible.

The trickiest software to implement was the programming and JTAG interface to the FPGA, as this is normally handled in a debug/programming tool, or CPLD. Thanks to the processing power and real-time performance of the TC1797, relatively high clock rates could be achieved while retaining a good measure of flexibility.

The multicore device’s software was, of course, impossible to write before the Meridian board was ready, since that is the very reason for its existence – to develop the software and test the hardware before the real silicon comes along. It was also only planned that basic drivers be developed at this stage, as the board was to be initially only used by Infineon for proving the silicon IP, and so higher level drivers could be developed later.

All of the above makes good design sense... but what actually happened on the project? What would we have done differently? Well, like all clean-sheet projects of this complexity, pinning down the specification was key, as it would have been possible to “just add this or that” to both hardware and software, given the very high level of flexibility the platform offers. One aspect of hardware design which is never given enough attention is the power supply, and the highly-fluctuating power requirements of the multitude of on-board SRAMs caused problems for our power budget, resulting in a minor change for later boards. A golden rule – never scrimp on the power budget!

Minimising PCB layers is always sensible practice where applicable, but here the key was everything working and with such a high-value board, it was prudent to use multiple grounding layers. Likewise, matching track lengths and impedances was vital for the memory connections in particular. This kept the signals clean and separated where necessary.

The Meridian platform has allowed Infineon to write software drivers and application benchmarks to evaluate the architecturalbuilding blocks of a microprocessor  – which is normally not feasible due to the modelling required to simulate the external environment. Simulation of the internal IP has been around for many years but requires immense computing power, with entire clusters of dedicated machines running for many hours to produce a result.

Using the Meridian board, it has been possible to supply the multicore IP to key partners who would not normally have the access to the requisite computing farms to simulate their specific usecase. The early availability of the IP in an electrically representative environment has allowed real external sensors, actuators and communication channels to be integrated, thus reducing the simulation runtime from hours to real time, since the FPGA-based simulation will run at up to 30MHz. This is sufficient to allow accurate evaluation of external bus interfaces, communications and signal generation peripherals in a real environment. Multicore code is driving CAN networks, motors, LEDs and TFT screens before production silicon is available!