I recently talked with Mr Takizawa of TDSC about their use of Cadence's Interconnect Workbench (IWB). You may not recognize those initials. Toshiba split itself into three companies last year and one of them is TDSC, or Toshiba Electronic Devices & Storage Corporation (yes, "electronics" doesn't make it into the acroynm for some reason), IWB has been deployed on 6 completed ASIC projects, and a seventh that is still ongoing. The experience related here is all using Incisive for simulation, but everything is being migrated to the Xcelium simulator. The designs are for a variety of applications, as reflects TDSC involvement in many product areas: two are for industrial applications, such as controlling factory automation, three are for consumer electronics, such as mobile, and two are for enterprise data centers. In the past, Takizawa-san's group had to do a lot of verification of the complex buses inside these chips by hand, requiring some of their most talented engineers. However, they switched to using Cadence's nterconnect Workbench (IWB), with two big benefits: no errors getting missed, and no longer requiring the most skilled engineers. Interconnect Workbench Many SoCs now employ sophisticated interconnect fabric IP to link multiple processor cores, caches, memories, and dozens of other IP blocks. These interconnect fabrics are the foundation of new generations of low-power servers and high-performance mobile devices. One challenge is making sure everything is hooked up correctly, and that the register map is correct. But there are also performance bottlenecks to analyze, such as ensuring that latency-critical blocks are getting through on time. Cadence's IWB is a tool that collects cycle-accurate traffic from multiple simulation or emulation runs and displays latency and bandwidth measurements in an easy-to-use performance cockpit. TDSC's Use of IWB As does any SoC design group, they have to verify the consistency and the correctness of the configuration of generated buses. This can be a challenge because each bus has a different configuration. Their previous approach was that experts connected up verification IP (VIP), prepared control scenarios, and verified them. This is very time-consuming. Worse, it is error-prone, and address mapping errors can slip through the cracks. In these designs the buses are mainly AXI, AHB, APB and the NIC-400. The largest design contains 10 masters and 50 slaves, although all the projects are close to that in complexity. One big advantage of IWB is that it does not require experts, which means that this verification can be outsourced, instead of tying up expert engineers who have high value doing other things. It also reduced the man-hours for checking bus configurations by 90%. Prior to adopting IWB, TDSC would spend 1½ months on bus configuration verification, now with IWB it is just a few days. The reason that they can reduce the effort so much is that they no longer need to build a complicated verification environment, then generate lots of test vectors to ensure correctness. This is a tough task when there are multiple masters and lots of slaves. The fact that address map decode tests are automatically generated is one crucial feature for Takizawa-san, since it was one of the sources of errors even when experts were performing all the test manually. They are operating on a short time scale since once the protocol is decided and defined, they have to make a prototype FPGA implementation within a week. IWB makes it easy to complete a sanity check on things like mapping errors, and so deliver a prototype by the required date. Another aspect is when bus verification gets done. It is best if it is completed early in development, because verification of the sub-modules requires the bus. So improvements in bus verification impacts the overall project schedule more than just the direct time saved in bus verification itself. As to performance verification, the IWB Performance Characterization test suite is always used. This has found performance bugs caused by buffer depths and/or incorrect definition of upsize/downsize. The tests could not really be done during the module test phase, but only later once expert designers connected up the actual masters and slaves. The experts could then assess whether a result was a performance error or not. Using IWB and IPC means that this performance bug hunting can be started about a month earlier. There is still a need to carefully check circuits which are performance critical, but IPC enumerates which those paths are, and so nothing gets missed. Early in the project, these techniques can be used for architectural exploration, such as setting buffer minimum depth, checking the performance, and extending the depth if required. Even novices can accomplish some of this. Previously, they would run into these sorts of problems much later in the design cycle, that would then require re-working of parts of the design. This sort of problem has become very rare. Video This video explains how IWB helps you with SoC interconnect verification and performance analysis by auto-generating your UVM environment, and also provides functional coverage and performance metrics like bandwidth and latency. https://youtu.be/FeaCSCsU8g4 Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧