Creating high performance SoCs with NoC IP
Third party IP is well known for standard features such as processor and communication cores Ethernet, USB, I2C, SPI and peripherals that are not worth the time and effort to develop yourself. Compared to its competitors, MLA is the 'killer app' for this SoC, delivering 50 trillion operations per second (TOPS) while consuming as little as 5 watts.
Not so long ago, system-on-chips (SoCs) containing a million transistors were considered large devices. Today, however, SoCs containing up to one billion transistors are commonplace, as exemplified by SiMa.ai's latest case study and its new machine learning (ML) chip, the MLSoC, which provides easy machine learning at the embedded edge.
The MLSoC was created on a 16nm technology node and consists of billions of transistors. As is almost invariably the case in today's SoC designs, the MLSoC composition uses a complex combination of multiple off-the-shelf third-party intellectual property (IP) blocks plus its own developed machine learning accelerator (MLA) IP.
Third party IP is well known for standard features such as processor and communication core Ethernet, USB, I2C, SPI and peripherals that are not worth the time and effort to develop yourself. Compared to its competitors, MLA is the 'killer app' for this SoC, delivering 50 trillion operations per second (TOPS) and consuming as little as 5 watts.
However, one problem with combining hundreds of IPs from different vendors is that the SoC industry has defined and adopted multiple interconnect protocols, including OCP, APB, AHB, AXI, STBus and DTL, each of which may use a different protocol. In addition, each IP may support a different data width and use a separate clock frequency. As can be imagined, getting these IPs to interact with each other can be daunting.
Enter NoC
The best solution for connecting hundreds of different IPs is to use a network-on-chip (NoC). Using buffering and switching, NoC passes packets between the originating IP and the target IP block. Each packet contains a header, which includes an ID with the source and destination addresses, and a body containing the data. A large number of packets may be delivered concurrently.
Each IP has one or more interfaces called "sockets". The Network Interface Unit (NIU) connects the IP 'sockets' to the NoC and serialises and packages the data, while meeting the data width and clock frequency requirements of each IP.
Developers often envisage the IP as having a square or rectangular footprint on the surface of the silicon chip. Although the NoC spans the entire chip, many developers do not realise that it is still an IP.
Should I develop it myself or go for an off-the-shelf NOC?
SoC developers must decide whether it is better to implement NoC on their own or to get it from a third party supplier. For many teams, this may simply not be worth considering, as they completely lack the time, resources and skills needed to develop a full-featured NoC from scratch.
领英推荐
Creating a NoC for a modern SoC requires at least six engineers working at full capacity for two years. Then there is the simultaneous debugging of the NoC and a number of other design issues. The only realistic solution to reduce risk and speed time to market (which equates to time to monetisation) is to go with a proven off-the-shelf NoC from a trusted supplier.
Technical advantages of implementing NoC
It is not only necessary to connect the NIU to the IP "socket", but also to determine the location of any switch and the size and location of any buffer. As NoC spans the entire chip, it is necessary to introduce multi-level pipelines (registers) for the physical layout team and tools to meet the performance and timing specifications of the SoC.
The design also includes iterations. It is much faster to perform iterations in the front-end design part of the flow than to include front-end and back-end physical layouts. If the front-end design engineer manually inserts all levels of the pipeline and fails to use enough resources in the right places, the back-end physical implementation team will fail to achieve its goals, resulting in the project being returned for rework.
Unfortunately, architects often solve this problem by over-developing and inserting too many levels of pipeline. While this will help the physical design team meet their timelines, any more pipeline stages than required will consume more core area, increase power consumption and increase latency.
One correct approach to solving this problem is to use physically aware NoC. This means that once the physical layout team has provided suggested locations for individual IP blocks, this data can be used to automatically determine the optimal number and location of pipe stages. By speeding up the physical layout process, the number of time-consuming back-end to front-end iterations required to achieve timing convergence is significantly reduced.
FlexNoc 5 is one such NoC, with physical awareness and a number of other feature options. For top of the range designs with hundreds of IPs and 1024+ bit wide connections, the FlexNoc XL option offers a high capacity mesh NoC generator feature. the FlexNoC 5 advanced memory option is suitable for architectures with complex memory interleaving schemes and non-contiguous address bits. This option uses multi-channel buffer reordering to avoid sequencing rule blocks and response serialisation bottlenecks, while supporting concurrent memory channel reads.
Some designs are safety-critical, which means that a failure or malfunction has the potential to cause serious injury or even death to personnel, or loss or even serious damage to equipment and property, or harm to the environment. In these types of designs, FlexNoc 5 IP can be complemented by the FlexNoc Quick Restore capability option. The package helps designers to implement the safety features required for compliance with automotive ISO 26262 and IEC 61508 standards. It also provides the hardware reliability required for enhanced enterprise SSD endurance.
Why choose off-the-shelf NoC IP
The only way to manage complex SoC designs is to use NoCs. instead of spending years and consuming significant engineering resources to develop them yourself, choose a reliable off-the-shelf NoC to save development time, reduce risk and speed time to market.