Prototyping development platform allows IP to be tested in advance of silicon
4 mins read
Infineon has recently announced a multicore architecture which will be the foundation for its next generation mcu families for automotive powertrain and safety applications. The architecture features up to three processor cores, lockstep cores and enhanced safety mechanisms to support applications designed to ISO 26262 ASIL-D.
A major challenge for the company has been to prove as much of the design as possible before silicon became available. This has been accomplished with the help of Hitex, which developed an fpga based real time simulation platform called Meridian. This development allowed Infineon to test its multicore IP months ahead of silicon tape out, enabling processor and toolchain to be brought up well in advance of normal timelines.
Hitex' challenge was to design a board around a Virtex-6 550T fpga, which has nearly 550,000 configurable gates. The board needed to add peripherals to the fpga to allow the 'soft' microprocessor to be evaluated. These included an lcd, CAN transceivers, FlexRay interfacing, Ethernet and a/d converters. The board also needed a system manager – an Infineon TC1797 TriCore – to manage bring up of the fpga image. The system would then be used for the development of debuggers and flash programmers.
From the software side, the system manager needed to access multiple fpga images stored locally on an SD card and to upload an image directly using the fpga's Jtag connection. It also had to offer the opportunity to select the fpga image before uploading and to set configuration options, such as processor speed, that should be emulated.
The system manager also needed to emulate an Infineon CIC61508 safety monitor – an intelligent watchdog that forms part of Infineon's PRO-SIL SafeTcore system.
While much of the design was fairly standard – such as interfacing for communications peripherals and multiple power supplies of varying voltages and outputs – the more interesting aspects centred around choosing the correct fpga I/O banks to allow high speed signals and clocks to be routed correctly, together with handling multiple reset signals from multiple sources. This is always a headache for multiprocessor systems, let alone one where one device has two operation modes.
There was also the challenge of managing multiple signal voltage levels, at high speeds and sometimes bidirectional, for interfacing a 1V fpga to 2.5, 3.3 and 5V systems. Bus translator selection was therefore crucial.
A novel system was required to allow control of the fpga for more unusual tasks, such as introducing disturbances into the grid array and starting/stopping the simulation. This meant the system manager had to emulate the fpga's Jtag signals, as well as provide the clock to the simulated core. This enabled new features which aren't possible on normal target hardware, such as simulating drifting or jittery clocks and flash value changes. Essentially, it's possible to speed, slow or stop time.
One twist is that, before programming, the fpga must be handled in one way, with such considerations as isolating clocks and signals from the I/O pins. However, once programmed, the device effectively becomes a multicore microprocessor, so the board must be able to handle both 'personas' transparently.
The trickiest software element to implement was the fpga's programming and Jtag interface, 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 flexibility.
Like all clean sheet projects of this complexity, pinning down the specification was key: it would have been possible to 'just add this or that' to hardware and software, given the platform's high level of flexibility. One aspect of hardware design which is never given enough attention is the power supply; the fluctuating power requirements of multiple srams caused problems for the 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, but 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 to keep signals clean and separated where necessary.
Meridian has allowed Infineon to write software drivers and application benchmarks to evaluate the architectural building blocks of a microprocessor – which is normally not feasible due to the modelling required to simulate the external environment. While simulation of the internal IP has been possible for many years, it requires immense computing power with dedicated machines running for many hours to produce a result.
Using Meridian, it has been possible to supply multicore IP to key partners who would not normally have access to the requisite computing farms to simulate their specific use case. Early availability of IP in an electrically representative environment has allowed real external sensors, actuators and communication channels to be integrated. Since the fpga based simulation will run at up to 30MHz, this can be done in real time; sufficient to allow accurate evaluation of external bus interfaces, communications and signal generation peripherals.
Traditionally, it was only possible to develop a debugger once silicon was available, but without a debugger, it wasn't possible to test the debug interface. The Meridian microprocessor simulator platform has enabled the Hitex HiTOP debugger to be developed before arrival of silicon and to meet the challenge of debugging multiple processing cores on a single chip. In a single core system, there is normally only one entity to be debugged via one Jtag connection; Meridian, however, supports multicore configurations, so every Jtag command needs to specify the target core as well, implying some routing and arbitration. The debugger needs to be able to connect to the specific core under test and differentiate between them.
These first versions of multicore compilers and debuggers, targeted at multicore applications, are now available to selected partners for evaluation.
A vital part of Infineon's automotive mcu strategy is to incorporate the advanced features needed for safety critical systems, such as error checking and correction on internal buses and ram, together with IP blocks to monitor bus accesses and memory violations. The Meridian board can test these and includes a CIC61508 safety monitor intelligent watchdog, so dedicated safety IP can be proven and developed before silicon is available.
With something as valuable as an mcu's IP, it was necessary to protect the fpga image from being reverse engineered. This meant every image stored on an SD card is encrypted using an AES 128bit encryption key; a matching key is 'blown' into the fpga as a one time programmable operation. Losing the key is not an option – it would render the £8000 fpga useless for future images!
Hitex and Infineon are now exploring the benefits of the Meridian platform – it is already being used for EU funded research projects into safety critical architectures and power control systems. The approach is complementary to other software based simulation tools, so provides Infineon with a generic platform to tune and experiment with future architectures, all in pursuit of maximising performance and building architectures that are right first time.