The importance of verifying the architecture of an SoC prototyping system

4 mins read

Despite the apparent trend towards using other platforms, asics remain a popular method of integrating functionality into a single device and achieving cost and performance benefits.

Like many other aspects of the electronics world, developing an asic is becoming a more complex business. Whether the device is being targeted at a leading edge process or is integrating more functionality, verifying the design is correct before sending it to manufacture is critical. Not doing the job properly means respins, additional cost and the potential for the company to miss a lucrative market window. Recent market studies suggest that software will be responsible for more than 70% of the cost of developing a 22nm asic and that 63% of all asic respins are the result of failing to capture a bug in the logic. Many engineers have turned to fpgas as a means of prototyping their asic designs and, according to Synopsys, 70% of all asics are currently prototyped on fpga based systems. But such is the size and complexity of an asic that multiple fpgas can often be needed to accommodate the design. Managing these multiple devices brings its own complexity. The company believes there are four key challenges when designing such systems: ease of use, allowing rtl code to be loaded into an fpga as quickly as possible; debug visibility; allowing designers to see what's happening; prototype performance, allowing the design to run as near to real time as possible; and capacity, supporting a range of design and the ability to expand them. System can handle 144m asic gate designs Synopsys has been developing fpga prototyping systems for more than a decade under the HAPS brand, with each iteration of the technology based on Xilinx fpgas. The latest addition to its portfolio is HAPS-70 which, in its largest configuration, can handle designs featuring up to 144million asic gates. HAPS-70 is based on the Virtex-7 2000T – the largest device in Xilinx' fpga portfolio. Neil Songcuan, a product marketing manager with Synopsys, said using the largest devices possible was the best way to meet the user's design requirements. Dealing with such complexity is a system architecture challenge on its own. Songcuan claimed HAPS-70 is the most comprehensive asic prototyping system yet developed. "It offers a threefold increase in performance and is supported by time domain multiplexing technology and the HapsTrak3 interconnect. And because it is scalable to 144m asic gates, it can accommodate everything from IP blocks to a complete SoC." From the asic designer's point of view, concerns focus on such issues as the increase in the volume of software which needs to be developed. "This software needs to work seamlessly with the hardware," said Songcuan, "which might include a processor, interface IP and so on. These can be very complex devices." Other important issues for asic developers include debug visibility, prototype performance and prototype capacity. In order to provide the performance which design engineers need, HAPS-70 has been designed as an integrated system. The system is housed in a frame which has been optimised for stacking boards and for coping with thermal management issues. Designers also need access to as many I/O on the Virtex-7 2000T fpga as possible. To enable this, Synopsys has developed the HapsTrak 3 connector in conjunction with Samtec and each HAPS-70 board features 23 connector blocks. When mounted in the frame, the fpga is underneath the board and the connectors are on the top, providing easy access to signals. HAPS-Aware software also helps to ensure the system is ready for action. "This is a hardware query system," Songcuan pointed out, "that makes sure everything is connected correctly, that the clocks are correct and that the interfaces between the HAPS modules and the database are OK. It's another level of utility: when you start the system, you know that it's set up correctly." Synopsys has also addressed memory issues with the release of HAPS-70. Songcuan explained: "When the design is loaded and running, engineers will stimulate it with data and find problems and want to debug them. Traditionally, this has been done by using the memory resources of the fpgas to store data. The problem is that, once the design has been loaded into the fpga, it takes up most of the memory and there is only a small amount left for debug data. "With HAPS-70, we have offloaded debug data to an external daughter board featuring srams. This increases the storage capacity by more than 100 times and allows the user to access a longer time window for debug." Problems start to increase when a design needs to be split between several fpgas. "How do you divide the design," Songcuan asked, "and how do you connect the various blocks?" That brings particular I/O requirements which may have not been catered for sufficiently in previous approaches. "When that happened, engineers tended to use pin multiplexing. The problem here is that, when you start pin multiplexing, system performance starts to slow." Looking to meet this challenge, HAPS-70 uses HapsTrak 3, an automated high speed time domain multiplexing methodology which, says Synopsys, allows data to be transmitted at rates in excess of 1Gbit/s between fpgas. It supports high speed I/O interfaces such as DDR3-1333 and brings 'finer granularity' to the number of I/Os per connector, bringing it into line with the I/O bank architecture on the Virtex-7 fpgas. Synopsys says this I/O arrangement provides flexibility in the movement of cables or daughter boards if a design changes and uses I/O connections where they are needed most, minimising the number of unused pins. "Overall," Songcuan claimed, "HapsTrak 3 brings a threefold increase in performance." Access to the hardware prototype from workstations is enabled by the Universal Multi Resource Bus (UMRBus). This connectivity option has been enhanced to support bandwidths of up to 400Mbyte/s between HAPS-70 systems and virtual prototypes. This is said to create an integrated hybrid prototyping environment that allows hardware/software integration, as well as an earlier start to software development. The UMRBus also provides remote access, a generic C++/TCL programming interface and cosimulation with Synopsys' VCS functional verification solution. "Performance is an important parameter," Songcuan noted. "Software developers want to work on a system which runs as close to the intended asic clock rate as possible. It may not be the same with HAPS-70, but if you can support the design running at 30MHz, software developers can get the system booted and started writing drivers and so on." For larger designs, the system's modularity provides further benefits. "While development teams can validate parts of the design in parallel," Songcuan pointed out, "at some point, these need to come together. While they need a larger system, they can use the same scripts to reduce the effort involved in bringing the SoC up." As SoC designers become more complex, engineers are looking for prototyping systems which are as easy to use as possible. "They want to take their rtl to hardware as quickly as possible," Songcuan concluded, "and then be able to hand that over to the software team." And getting the architecture of the prototyping system right is just as important.