You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!
Dan is joined by Chouki Aktouf, founder & CEO of Defacto Technologies and co-founder of Innova Advanced Technologies. Prior to founding Defacto in 2003, Dr. Aktouf was an associate professor of Computer Science at the University of Grenoble – France and leader of a dependability research group. He holds a PhD in Electric Engineering from Grenoble University.
Dan explores the offerings of Chouki’s new company. Innova provides a flexible and customizable capability to manage design flows and EDA tool resources. This disruptive solution serves as a single portal to help reduce the complexity of using tools and dedicated design environments.
The views, thoughts, and opinions expressed in these podcasts belong solely to the speaker, and not to the speaker’s employer, organization, committee or any other group or individual.
The simple and best definition of Blockchain technology is to think about it as electricity , you only see it’s applications but you understand how important it’s and know there are many applications and products that can run on it . But like any other technology it went through stages and evolved as it progressed and matured. We started with Blockchain 1.0 and now we are at Blockchain 4.0.
In the following article we will explain each version of Blockchain:
Blockchain 1.0 – Cryptocurrencies
The Blockchain’s first-ever application was bitcoins. Blockchain has already established itself as the enabler of an ‘Decentralized Internet of Money’ by powering cryptocurrencies. By providing transparency, accountability, immutability and security, Blockchain very soon triggered the influx of more cryptocurrencies, and today we have more than 10,000 different cryptocurrencies in circulation.
Cryptocurrency Types
1. Central Bank Digital Coin
2. Stablecoins
3. Cryptocurrency (Bitcoin, Ethereum, Solana …)
4. Meme Coins (Elon Musk!)
*Maximum number Bitcoin is 21 million coins , we have ~19 millions in the market now
Blockchain 2.0 – Smart Contracts
With Blockchain 2.0 came the era of smart contracts that helped #blockchain to outgrow its original functionality of powering cryptocurrencies.
What is a smart contract?
· Smart contracts are essentially automated agreements between the contract creator and the recipient.
· Written in code, this agreement is baked into the blockchain, making it immutable as well as irreversible.
· They’re usually used to automate the execution of an agreement so that all parties can be sure of the conclusion right away, without the need for any intermediaries.
· They can also automate a workflow, starting when certain circumstances are satisfied.
One key benefit of a smart contract is the automation of tasks that traditionally require a third-party intermediary. For example, instead of needing a bank to approve a fund transfer from client to freelancer, the process can happen automatically, thanks to a smart contract. All that’s required is for two parties to agree on one concept.
Smart contracts have gained widespread appeal because they are tamperproof and lower the cost of verification, exception, arbitration, and fraud protection, in addition to permitting automated permission-less execution. Also, smart contracts allow transparent data recording, which is easily verifiable and provides the involved parties equal sovereignty over their deals.
The very popular Ethereum is a 2nd generation blockchain. For fueling the functionality of smart contracts, Ethereum is the go-to Blockchain for enterprises across industries, especially supply chain, logistics, cross border payments.
Although a second-gen Blockchain, Ethereum has been continuously at the forefront, scaling up its offerings to expand the blockchain functionalities across industries. Ethereum is leading the way in everything from smart contacts to dApps, asset tokenization to DAOs, DeFi to NFTs.
Blockchain 3.0 – DApps
Blockchain 3.0 has been all about Decentralized applications (Dapps).
Decentralized applications (Dapps) are applications that run on a P2P network of computers rather than a single computer. #dapps , have existed since the advent of P2P networks. They are a type of software program designed to exist on the Internet in a way that is not controlled by any single entity.
With a frontend user interface, calling to its backend smart contracts hosted on decentralized storage, DApps support various powerful blockchain use-cases like #defi platforms, Crypto loan platforms, #nft marketplaces, P2P lending and others.
Powered by new consensus mechanisms like Proof of Stake, Proof of History and others, 3rd gen blockchain protocols focused on areas like Speed, Security, Scalability, Interoperability and Environment friendliness.
For offering benefits like transparency, scalability, flexibility and reliability, the Global DApp market is expected to reach $368.25 billion by 2027. DApps have found applications across verticals like Gaming, Finance, social media, and Crypto transaction.
Blockchain 4.0
Blockchain 4.0 is focused on innovation. Speed, user experience and usability by larger and common mass will be the key focus areas for Blockchain 4.0. We can divide Blockchain 4.0 applications into two verticals:
• Web 3.0
• Metaverse
Web 3.0
The Internet is constantly transforming, and we are on our way to the third generation of internet services, which will be fueled by technological advances such as IoT, Blockchain, and Artificial Intelligence. Web 3.0, is focused at having decentralization at its core, therefore Blockchain plays a critical role in its development.
Web 2.0 has been revolutionary in terms of opening up new options for social engagement. But to take advantage of these opportunities, we as consumers have poured all of our data into centralized systems, giving up our privacy and exposing ourselves to cyber threats. Web 2.0 platforms are managed by centralized authorities that dictate transaction rules while also owning user data.
The 2008 global financial crisis exposed the cracks in centralized control, paving the way for decentralization. The world needs Web 3.0- a user-sovereign platform. Because Web 3.0 aims to create an autonomous, open, and intelligent internet, it will rely on decentralized protocols, which Blockchain can provide.
There are already some third-generation Blockchains that are designed to support web 3.0, but with the rise of Blockchain 4.0, we can expect the emergence of more web 3.0 focused blockchains that will feature cohesive interoperability, automation through smart contracts, seamless integration, and censorship-resistant storage of P2P data files.
Metaverse
The dream projects of tech giants like Facebook, Microsoft, Nvidia, and many more, Metaverses, are the next big thing for us to experience in the coming few years. We are connected to virtual worlds across different touchpoints like social engagement, gaming, working, networking and many more. Metaverse will make these experiences more vivid and natural.
Advanced AI, IoT, AR & VR, Cloud computing and Blockchain technologies will come into play to create the virtual-reality spaces of #metaverse , where users will interact with a computer-generated environment and other users through realistic experiences.
Centralized Metaverse entails more intense user engagements, deeper use of internet services and more uncovering of users’ personal data. All these almost likely means higher cybercrime exposure. Giving power to centralized bodies to regulate, control and distribute users’ data is not a sustainable set-up for the future of Metaverse. Therefore, much emphasis has been placed on developing decentralized Metaverse platforms that will provide user autonomy. Decentraland, Axie Infinity, and Starl, these are all decentralized Metaverses powered by Blockchain:
Also, Blockchain 4.0’s advanced solutions can help Metaverse users regulate their security and trust needs. Take the Metaverse gaming platform, for example, where users may purchase, possess, and trade in-game items with potentially enormous value. Proof of ownership through something as immutable and scarce as NFTs will be required to prevent forgery of these assets.
Blockchain 4.0 solutions can aid in the following Metaverse development requirements:
• Decentralization
• Decentralized data management
• Security
• Digital Proof of ownership
• Digital collectability of assets (such as NFTs)
• Governance
• Transfer of value through crypto
• Interoperability
At the end Blockchain 4.0 will enable businesses to move some or all of their current operations onto secure, self-recording applications based on decentralized, trustless, and encrypted ledgers. Businesses and institutions can easily enjoy the basic benefits of the Blockchain.
The advancements in deep submicron technology and adding multiple functionalities to reduce costs combined with scaling existing operations means that SoC designs become ever more complex. The biggest driving factors to go below the 16nm process node are the decrease in power and the increase in performance due to the higher transistor densities of these advanced nodes. However, doing so creates challenges to physical Implementation and timing/power closure. In particular, high speed IP such as SerDes, DDR, PCIE integration in a large SoC needs careful floor planning to reduce the project time as well as achieve timing/power signoff. In this article, we will look at the new challenges which have been introduced due to 5nm technology as well due to new additional functionality in SoC. We will show the approach to tackle the floor planning and timing issue to reduce the physical implementation iteration.
Methodology
The implementation of large, complex IP integration needs a methodology that efficiently closes the floorplan signoff criteria as well as preventing large timing violations at a later stage.
Figure 1: Custom Floorplan Methodology
Challenges of5nm physical design
A holistic approach is needed to concurrently address the planning, editing and optimization environment for the project along the path from SoC to advanced packaging techniques (like InFo/Feveros/X-Cube). As well as considering the impact backwards up the path of decisions. For example, by iterating the placement bumps, PADs and macros early in the process enables the turnaround time to be reduced.
Another thing to be considered and planned for early in the process are thermal effects long before place and route in order to improve yield and reliability by designing out hot spots that can lead to failures. For example, standard cells packed at high density can create hot spots. This is because, at 14/16 nm nodes, three to four fins are used to provide structural stability to each gate but, below 7nm, two are used. These are higher to compensate for the reduced number of fins and still give the reinforcement required. However, care should be taken with standard cell placement as fins surrounded by dielectric (gate oxide) have poor thermal conductivity and therefore do not dissipate heat as well as expected creating a hot spot. Therefore, doing an early stage of power analysis (Dynamic/Static) helps to prevent hot spot surprises at a later stage at power signoff.
Lastly, process and voltage variation intensity are higher at lower geometries. To combat this, PT-ECO signoff typically needs more than twelve iterations for large complex blocks due to noise and transition requirement.
Challenges of integrating high speed blocks
Partially hardened IP has higher state of flux because of continuous improvement of the hard IP from the analog team. This can be addressed by using models that were tailored for different design stages with increasing level of complexity and completeness as we approach tapeout. Having IP collateral and the list of IP deliverables as soon as possible in the process are vital to a swift and successful integration.
Lastly, design complexity at Floorplanning, DFT integration, Custom Clock tree and timing/power signoff all require scripting knowledge and basic IP understanding to tweak implementation.
Floorplan Challenges:
On a recent design, the foundry provided a multi-height library and, initially, it was difficult to pass the grid checks. The problem was that we were implementing our design using a power efficient library however the third-party IP was on high performance library. Hence, placement of both library types had to be on least common multiple (LCM) rows.
Things to look out for are:
Avoiding tap cells and boundary cell insertion on special areas where an analog signal is routing.
Power Grid (PG) connectivity is important for multiple power domain design along with Analog VDD as well as third party IP VDD.
Connecting PG nets/pins must be according to guideline defined by the Analog team/Third Party IP deliverables.
TCD/ESD IP to be connected according to the power clamp implementation rule defined by the foundry.
Legality checks need to take care of after spare cell insertion: grid check takes care of IP placement legality.
Integration checks which honor the top-level floorplan DRC (??) while integrating blocks at chip level.
Terminal/Port placement checks as this is an important check at the initial design integration.
PG Design Rule Checking (DRC) such as PG Via and power stripe routing, plus macro to macro and macro to boundary spacing rule checks to avoid DRC.
The Floorplanning Goal
This is to have a clean Design Rule Check (DRC) and Layout Versus Schematic (LVS) design that follows the design implementation guideline as well as the timing/congestion aware macro placement.
These are the stages of how to achieve this by improving a floorplan. NB a Synopsys Fusion compiler is used in this example.
I. Grid creation is required due to there being multiple vendors of third-party IP, so generating a grid provides uniformity for interconnection:
## Macro wrappers need to be snapped to 7.752um, 9.576um which is multiple of cell site 0.051 and cell row height 0.028 (1 track distance)
II. When you do a floorplan, you will need to do manual routing of the high-speed signals. You will need to avoid any placement or routing by creating blockages over the area using
Figure 2: Block and signal routing over high speed macro
III. Power Grid (PG) connectivity requires that the PG mesh routing follows the pre-connection command defined by implementation. Hence, we need to connect analog PG ports and BUMP connections along with digital power/ground connectivity.
IV. Extra signal and special connections as defined by the Analog team to connect at block level can be challenging when you have insufficient or incomplete Library Exchange Format (LEF) but must need to do to check Block level and Chip level Layout Versus Schematic (LVS).
Example:
Figure 3: Manual routing which connects Special analog signal
V. ESD cell and TCD (Test-key Critical Dimension) checks are needed. The electrostatic discharge macro is required to protect high speed analog macros. TCD cells are employed to monitor the critical dimension such as minimum line width, etc. Also check the critical dimension of cells to ensure layout uniformity during fabrication to improve the yield.
Note: We place ESD cells near to Hard IP and supplied the same voltage as that is required by the Hard IP for efficiency.
Figure 4 Schematic diagram
iii. Terminal/Port placement checks. These are the common and simple checks of floor planning to spot errors.
Example: violation to check.
Type of Violation
Count
Missing Pins
0
Pin Off Edge
276
Pins Off Track
145
Pin Short
0
Pin Size
3
Pin Spacing
3
Total Violations
427
iv. Power Grid Design Rule Checks: Write out PG DRC reports and compare Implementation tool PG DRC with floorplan signoff (rule deck aware) DRC of ICV/Calibre. If DRC violations such as Illegal overlap, insufficient width, minimum metal width min metal area, illegal shapes or min metal edges, try to debug the PG mesh scripts and manual PG via insertion scrips.
Note: Shorts and Opens on the PG should be clean before further executing the next step during the tentative signoff iteration.
In conclusion, Sondrel has been working on advanced nodes for decades and already has several 5nm designs under its belt which were used to create this list of checks and suggestions that can help master the challenges of 5nm design. Further articles can be found at https://www.sondrel.com/solutions/white-papers
Pavan Patel is ASIC enthusiastic physical design engineer. Having implementation and signoff experience of Modem, Camera chip, networking switch, Mobile SoC, Router SoC. Fascinated with VLSI history and impact of SoC on business as well as consumer.
Dan is joined by Jim Bridgewater, director of product marketing for NXP automotive edge product line.
Jim provides an overview of the various wireless interfaces in current automotive design. He also discusses a new product from NXP called OrangeBox, a device that combines many of these interfaces into one domain controller. Jim explores the benefits of this approach, including stronger security implementation and enhanced quality of service.
The views, thoughts, and opinions expressed in these podcasts belong solely to the speaker, and not to the speaker’s employer, organization, committee or any other group or individual.
I’ve written on and off about sensors, ML inference of the output of those sensors and the application of both in modern cars. Neither ADAS nor autonomous/semi-autonomous driving would be possible without these. But until now I have never covered the transport between sensors and the compute that safely turns what they produce into clear images and accurate object detection. Mixel and Rambus recently gave a talk on that transport, MIPI, at MIPI DevCon. Useful, since I had previously assumed that the data somehow magicked its way from the sensor to the compute. The example focused particularly on imaging subsystems, in this talk featuring the camera-serial interface (MIPI CSI-2) from Rambus and the physical interface (MIPI C-PHY and MIPI D-PHY) from Mixel.
MIPI CSI-2 and PHY transmit and receive blocks
MIPI CSI-2 is the function which defines a serial interface between a camera on one end and an ISP on the other end. Pixels stream in one side and eventually stream out the other side, so the interface needs a transmit function and a receive function. Because these functions must be able to connect any camera (or more than one camera) to any ISP, they need a lot of flexibility. One example is bandwidth matching between the sensor and the ultimate consumer, allowing for a continuous streaming flow for example.
Between the CSI-2 transmit and receive functions, D-PHY (or C-PHY) handle the physical communication. D-PHY uses differential signaling while C-PHY uses a clever differential technique looking pairwise at a trio of signals, together with encoding. Complex stuff but apparently supports a higher data rate than D-PHY.
Safety in the PHY
Back in more familiar territory for me, these IPs are designed for automotive applications, making safety a critical objective. Both the PHY and controller must meet the ISO 26262 FMEDA requirements for the appropriate ASIL level. In addition, safety critical automotive applications require in-system testability for the MIPI PHY. I’m seeing similar in-system testability requirements becoming more common at ASIL-C/D levels for other PHYs, so this is not a surprise. The Mixel MIPI PHY supports full-speed and in-system loopback testing for the universal configuration (Tx+Rx) as well as with their own implementations for area optimized transmit only and receive only configurations called TX+ and RX+.
Mixel also noted additional testing required for automotive IP: stress testing, HTOL and reliability tests (e.g. aging). These, together with meeting the ISO 26262 standard DFMEA and FMEDA. Ensuring the overall reliability of the IP, essential for car safety over a 15+ year service life.
Safety in the CSI-2 controller
To meet ASIL-B fault coverage requirements Rambus’s CSI-2 Controller Core with Built-In-Self-Test (BIST). BIST mechanisms are used here together with familiar safety mitigation techniques: ECC, CRC, parity. It is interesting to note that the BIST here is at the IP level, not at the system level. I have seen the same principle for in-system testing in the NoC. In both cases, the argument is that function level BIST is better than system level for multiple reasons. It can go deeper and provide more confidence in safety coverage. It is also available even if system-level BIST is not provided, offering central feedback if the system becomes non-operational.
In safety mitigation techniques, the CSI-2 controller provides parity protection on pixels and pixel buffers. Also ECC for the protocol header and CRC for packet data. These add redundancy for data formatting, packing logic, critical state machines and other critical blocks. Packet ordering is checked, and order errors are flagged. One other interesting check I have seen coming up more in safety critical applications is a watchdog timer. This is to detect frozen or excessively delayed operations. All emphasizing that at high ASIL levels, safety mitigation is no longer just about the basic methods. Designers are adding more active and complex tests and mitigations to rise to ASIL-C/D.
This talk can be found HERE and is a good introduction to the topic.
If you would like to learn more information about Mixel and their MIPI offering, visit their website here or learn about their MIPI D-PHY IP here.
Near the end of any large SoC design project, the RTL code is nearly finished, floorplanning has been done, place and route has a first-pass, static timing has started, but the timing and power goals aren’t met. So, iteration loops continue on blocks and full-chip for weeks or even months. It could take a design team 5-7 days per iteration – not knowing how much time per iteration, and not really knowing how many iterations will reach closure of their design goals. Clearly, not a fun process to be caught in.
Design Closure Challenges
The clever R&D engineers at Cadence have taken action to deliver some relief for reaching design closure by creating a full-chip closure flow, and it uses an automated approach that is massively distributed, delivering both optimization and signoff. I talked with Brandon Bautz, senior group director, product management in the Digital & Signoff Group at Cadence, to learn about their newest EDA announcement. The new offering is called the Cadence Certus Closure Solution, and it has a shared engine with the Cadence place and route tool, the Innovus Implementation System, and the Static Timing Analysis (STA) tool, the Tempus Timing Signoff Solution. Here’s how the Cadence Certus Closure Solution works with STA (Tempus), place & route (Innovus), fill (Pegasus Verfication System) and extraction (Quantus Extraction Solution):
Cadence Certus Closure Solution
Reaching block-level closure is accomplished through using Tempus for STA along with Tempus ECO, controlled by the Cadence Certus Closure Solution. For full-chip and sub-system level closure, the Cadence Certus Closure Solution controls Tempus Signoff using either STA or distributed STA (DSTA). SemiWiki has written about how Cadence applied ML to chip optimization steps with the introduction of the Cadence Cerebrus Intelligent Chip Explorer last year, and this also works with the Cadence Certus Closure Solution.
As your SoC design size increases you really want an EDA tool that scales, so with the Cadence Certus Closure Solution you get a design closure flow that is distributed, and supports hierarchical optimization, ready to run in the cloud or your own data center to get results more quickly. When a change is made within a block, then the incremental signoff only needs to restore and replace the changed area.
Designers of 3D ICs will also benefit from the Cadence Certus Closure Solution, as it works with the Integrity 3D-IC platform, closing the timing on inter-die paths.
Certus Results
Two customer designs were run through the Cadence Certus Closure Solution, showing some impressive timing optimization and closure times that were gained overnight – not taking weeks and months.
Timing optimization and closure – overnight results with
8X TAT improvement
9.7% power improvement for interface and 1.3% at a full-chip level
Even Renesas was quoted as seeing, “6X faster chip-level signoff closure turnaround times.”
If you have some STA and P&R experience, then learning the Cadence Certus Closure Solution will be quick, as you can read the user guide and run through the examples, becoming proficient within just one day. The Cadence Certus Closure Solution works well on the largest SoC designs, and also on IP blocks with millions of cells. The approach in the Cadence Certus Closure Solution applies to all silicon technology: Planar, FinFET, Gate-All-Around.
Summary
Grunt work like manually trying to iterate EDA tool flows in reaching design closure on timing and power is expensive in both engineering costs and lost time to market. Cadence now offers new automation and optimization in the Cadence Certus Closure Solution by using a massively distributed flow that handles unlimited capacity. Engineering teams can expect to get overnight, concurrent full-chip optimization and signoff results.
This new automation area for Cadence looks promising, as it has the potential to save so much time and manual engineering effort.
The resolution of EUV lithography is commonly expected to benefit from the shorter wavelengths (13.2-13.8 nm) but in actuality the printing process needs to include Pde the consideration of the lower energy electrons released by the absorption of EUV photons. The EUV photon energy itself has a nominal energy range of 90-94 eV, corresponding to 13.2-13.8 nm. Upon absorption, photoelectrons of ~80 eV are released through ionization. These very quickly scatter and lose energy, releasing more electrons (“secondary electrons”) in the process. The energy finally absorbed in the resist film is essentially deposited by these secondary electrons, even with energies as low as around 1 eV [1]. Therefore, the actual resolution of the EUV-printed image is ultimately determined by the spread of these secondary electrons.
The inelastic mean free path (IMFP) is a parameter commonly used to describe the distance traveled by electrons before scattering with energy loss, i.e., inelastic scattering. It is expected to be on the order of nanometers. Since scattering is itself a random or stochastic event, the IMFP itself would have a range of values. This leads to a range of possible values for the blur in the resist image. The IMFP will depend on the kinetic energy of the electron, characteristically taking a minimum value below around 100 eV [2, 3] (Figure 1).
Figure 1. IMFP vs electron kinetic energy, adapted from [2].
As the energy decreases, the electron is continually traveling through scattering, and potentially may encounter the interface of the resist with the vacuum above it. This top surface has an energy barrier that tends to prevent electrons from escaping. The barrier is equal to the sum of the Fermi energy and the work function, and is also the same as the ionization potential [4]. For one popular tin-based EUV resist material component, SnOH, the ionization potential is 6.6 eV [5]. That means electrons with energies less than this value will be prevented from escaping into the vacuum. They will be reflected back from the top surface. The physics behind this is the conservation of momentum parallel to the interface. The perpendicular component of the momentum is reduced due to the interface barrier [6]. The electron energy in the vacuum upon crossing the barrier is decreased from E to E-U, where U is the barrier energy. The corresponding total momentum magnitude goes from sqrt(2mE) to sqrt(2m(E-U)), where m is the electron mass. The component parallel to the interface is given by sqrt(2mE)sin(q) in the resist, and sqrt(2m(E-U))sin(s), in the vacuum above the resist (Figure 2). These are equal, leading to an equation similar to Snell’s Law of refraction. If E<U, or sin(q)>sqrt([E-U]/E), the presence of the electron in the vacuum is forbidden, and so the electron keeps its initial energy and momentum magnitude E by being reflected at the same energy and angle. This is analogous to the total internal reflection of light at waveguide walls. This tends to give the lowest energy electrons extra opportunity to scatter and spread laterally within the resist, thereby increasing the image blur.
Figure 2. Total internal reflection of electrons occurs at the top interface when the interface barrier energy U exceeds the initial electron kinetic energy E, or the vacuum refracted angle s has to exceed 90 degrees.
The bottom interface with the resist underlayer would similarly play a key role, as an energy barrier there would increase blur even further with an additional boundary for internal reflection. On the other hand, it may also be a negative energy barrier, allowing electrons to escape the resist film into the underlayer. Hence, we expect the resist underlayer to significantly affect the low-energy electron spread in EUV resists. There is the uncomfortable realization that the EUV-deposited dose, rather than being a certain number of photons absorbed in a square nanometer, is actually an indeterminate number of electrons of unknown trajectories finally resting in that square nanometer.
References
[1] I. Bespalov et al., ACS Appl. Mater. Interfaces 12, 8, 9881 (2020).
[2] M. P. Seah and W. A. Dench, Surf. and Interf. Anal. 1, 2 (1979).
[3] D-N. Le and H. T. Nguyen-Truong, J. Phys. Chem. C 125, 34, 18946 (2021).
[4] A. Klein et al., Materials 3, 4892 (2010).
[5] Y. Zhang et al., Appl. Phys. Lett. 118, 171903 (2021).
[6] O. Yu et al., J. Elec. Spec. and Rel. Phenom. 241, 146824 (2020).
While Truechip has established itself as a global provider of verification IP (VIP) solutions, they are always on the lookout for strategic IP needs from their customer base. Over the last several years, a solid market for Network-on-Chip (NoC) IP has grown, driven by the need to rapidly move data across a chip. Concurrently, the TileLink interface specification has also been gaining broad adoption in SoCs for implementing cache-coherent transactions. This created a need for a NoC IP to work with the TileLink protocol. Truechip seized this opportunity last year and introduced their NoC Silicon IP that leverages the TileLink interface specification. An earlier SemiWiki post discussed Truechip’s NoC Silicon IP. While the TileLink specification was originally developed to work with the RISC-V architecture, it actually supports other instruction set architectures (ISAs) too.
Truechip’s NoC Silicon IP provides chip architects and designers with an efficient way to connect multiple TileLink based master and slave devices for reduced latency, power, and area. It also helps reduce physical interconnect routing and use of resources inside an SoC. Yet another constant demand in the chip world is the need for faster and more efficient verification of designs and IP. The ever increasing design complexities directly expand the scope of verification challenges for achieving full coverage. New verification methodologies are needed to increase the efficiency and efficacy of testing highly complex designs. Any level of automation that can be brought into the life of a verification engineer will help ease the burden, leading to faster creation of testbenches. Truechip has seized this opportunity to introduce some automation products to their customer base. Earlier this year, the company announced their Automation Products addressing NoC Verification and NoC Performance for revolutionizing the verification process.
NoC Automation Products
The different IP blocks not only need to work as per their internal specifications, they also need to interact at the system level. Verification requires checking how the various blocks interact against the specifications at the system level. Performing this task may involve manual calculations for checking against various latency requirements. Many times, this may also call for manually viewing signal waveforms. Truechip’s automation products help ease the task of verification engineers by mitigating these manual tasks, thereby reducing the time and effort needed for optimization. IP teams can more efficiently optimize their IP for maximizing bus and bandwidth utilization. Chip verification engineers and chip architects alike benefit from this automation.
NoC Performance Product
Truechip’s NoC Performance is a robust performance analyzer for NoC IP/SoC and supports fully compliant standard Bus interface ports like AXI, AHB, APB, and TileLink. It comes with compliance and regression test suites along with exhaustive set of assertions and coverage points. The product offers consistency of interface, installation, operation and documentation across all of Truechip’s VIP solutions.
Some Salient Features
Per interface latency and NoC latency
Latency variation over transactions
Transaction Tracing
Per interface bandwidth
Master and Slave Interface comparisons (in terms of bandwidth and Latency)
Consolidated summary timeline for different performance numbers in single window
Statistics for different types of commands encountered on bus Bandwidth (GBps) and throughput
Actual Data transfer
Time window to select the duration for computing utilization
Integration Guide, User Manual, FAQ, and Release Notes
NoC Verification IP
Truechip’s NoC Verification IP provides an efficient way to verify the components interfacing with any type of NoC IP or SoC. It is a light weight VIP with an easy, plug-and-play interface that minimizes the hit on design cycle times. The solution comes with a GUI based testbench generator (TBG) and supports fully compliant standard Bus interface ports such as AXI, AHB, APB and TileLink. The VIP is available in native System Verilog UVM and Verilog.
Some Salient Features
Automated Testbench creation & Integration of DUT and VIP
Automated Test case generation for sanity tests / full verification
End to end data score boarding
NoC Monitor
Regression running and analysis
Multiple protocols and (theoretically) any number of nodes
Integration Guide, User Manual, FAQ, and Release Notes
About Truechip
Truechip, the Verification IP specialist, is a leading provider of Design and Verification solutions. It has been serving customers for more than a decade. Its solutions help accelerate the design cycle, lowers the cost of development and reduces the risks associated with the development of ASICs, FPGAs, and SoCs. The company has a global footprint with sales coverage across North America, Europe and Asia. Truechip provides the industry’s first 24×7 support model with specialization in VIP integration, customization and SoC Verification.
This Diakopto paper discusses for the first time, a new effect – a false electrical mismatch in post-layout simulations for perfectly symmetric nets. This effect is caused by the difference in distributions of parasitic coupling capacitors over the nodes of parasitic resistor networks, even for symmetric nets. This, in turn, is caused by artifacts of parasitic extraction and parasitic extraction tools. Practical recommendations are proposed for identifying these false mismatch conditions, to distinguish them from real mismatches due to layout differences. Parasitic extraction methodology needs to be improved to avoid these artifacts and to ensure the trustworthiness of post-layout simulations and IC design flow.
Device and net matching in IC design
Many analog and RF integrated circuits rely on the concept of device and net matching [1,2]. Examples of such circuits are: StrongARM latch, sense amplifier, differential pair, current mirror, multi-phase clocks, and many others. Matched nets and devices allow a circuit to be more tolerant and insensitive with respect to unavoidable process variations.
To enable perfect net matching, layouts are created symmetric (i.e. flipped around the X or Y axis), or by shifting or rotating a cell. An example of such symmetric nets is shown in Figure 1.
Figure 1. Layout of matched nets VIN and VIP. Input ports are VIN and VIP, and destination points are the gates of the MOSFETs. The nets and their environment are created symmetric, to ensure parasitic resistance, coupling capacitance, and RC delay matching.
A perfect symmetry and matching are rarely achievable, due to constraints of design rules, wire routability, and geometry. To verify matching, designers and layout engineers perform parasitic extraction, and then run post-layout circuit simulation – as a part of a standard post-layout design flow. If simulations show good and expected results, symmetry and matching have been achieved. If there are some offsets, mismatches, or differences in measured signals – it means the matching is not perfect, and the layout needs to be improved.
This methodology seems clear and straightforward, similar to a very basic, general concept of symmetry in physics. A symmetric system should possess a symmetry in its characteristics, and if its simulated or calculated characteristics are not symmetric – obviously, the solution is wrong.
Problem statement
However, very often post-layout simulations show difference(s) in electrical behavior even for perfectly symmetric, matched nets. A typical scenario is when two nets show a good matching for capacitance and for resistance, but a large mismatch for RC delay. At a first glance, it seems that the delays should match if capacitances and resistances are matched. So, the effect of delay mismatch, in such scenario, may seem counterintuitive.
Figure 2. (a) Visualization of parasitic elements – resistances and capacitances. Note the asymmetry, a difference in the distributions of coupling capacitances for nets VIN and VIP. (b) Visualization of RC delay over the net layout. Since coupling capacitances are concentrated at the far end (form the port VIN) of the net VIN, and at the near end of net VIP, the delay on VIN is larger than delay on VIP.
The root cause of the delay mismatch is related to how parasitic extraction tools distribute coupling capacitances over the nodes of the resistive networks. For some reason, the distribution of coupling capacitances is very asymmetric – different for symmetric (or for rotated) nets. This effect is illustrated in Figure 2. The most likely reason for such asymmetry is the anisotropy of computational geometry algorithms used by extraction tools, such as sweep (or scan) line, or polygon boundary traversing – which have a preferred direction, such as left-right, or top-bottom, or clockwise-counterclockwise. These algorithms are treating the layout as a flat system, losing the natural hierarchy and cell transformation characteristics, that, theoretically, can be used to transform the preferred directions according to cell transformations.
To prove (or disprove) this conjecture, we performed a series of experiments, by analyzing post-layout netlists and performing post-layout simulations for several GDS files. We used the original DSPF file (used as a reference), and compared with DSPF files obtained by various transformations – symmetry reflection with respect to the X and Y axes, and by rotations of 90, 180, and 270 degrees. The results for symmetry transformation are illustrated in Figure 3.
Figure 3. RC parasitic for the (a) original and (b) flipped GDS files. The distributions of coupling capacitances for nets VIN and VIP are reversed, for cases (a) and (b). The distributions of coupling capacitances are the same for the left net, and the same for the right net, for cases (a) and (b).
As one can see, the distribution of coupling capacitances is the same for the left net for the original and for flipped layout. This distribution is also the same for the right net. However, since nets VIN and VIP changed sides, for the flipped versus original layout, the distributions of coupling capacitance on net VIN (VIP) for case (a) now becomes the distribution of coupling capacitances for net VIP (VIN) for case (b).
This change in capacitance distributions correlated very well with the simulated RC delays on VIN and on VIP. RC delay is larger for net VIN than for VIP in case (a), but smaller than delay on VIP in case (b). Similarly, we observed a difference in post-layout circuit simulations, showing a significantly larger transition time for nets VIN in case (a), and smaller for case (b), than transition time on net VIP. This shows that the electrical mismatch between symmetric nets VIN and VIP is an artifact of parasitic extraction tools, as explained above.
Of course, if the difference in couplings and in RC delays for nets VIN and VIP does not change its sign after performing a transformation of the layout, such difference is caused by the real layout mismatch, and is a real effect, that needs to be fixed on the layout.
Coupling capacitors distribution over parasitic resistor network
To the best of our knowledge, this is the first paper discussing the artifacts of parasitic extraction related to anisotropic, asymmetric distribution of coupling capacitances for symmetric layout.
We observed these false mismatch effects for different designs, technologies, foundries, and for all three major parasitic extraction tools – StarRC, Quantus QRC, and Calibre PEX. The severity of false anisotropy is different for different extraction tools. This may be explained by a difference in the quality of coupling capacitors distributions, illustrated in Table 1 and Figure 4.
Table 1. Quality of coupling capacitance distribution for different parasitic extraction tools.
Every parasitic extraction tool tries to minimize the size of the parasitic RC network, to enable fast post-layout simulation times (for SPICE, EMIR, timing, and other tools). There is always a trade-off between the netlist size (simulation time) and accuracy. Different parasitic extraction tools do this with a different level of physics awareness, and with a different level of accuracy. Obviously, incorrect coupling capacitance distribution will lead not only to a mismatch between nets, but also to an inaccuracy in transient and AC simulations of such circuits.
Figure 4. Distribution of coupling capacitances over the nodes of parasitic resistor networks. Case (a) is the most accurate, case (b) is less accurate, and case (c) is very crude.
Advanced technology nodes (7nm, 5nm, 3nm, and beyond)
The false mismatch effect becomes much more severe in advanced technology nodes – such as 7nm, 5nm, and 3nm. Most likely, this trend is caused by a dramatic increase in parasitic resistances of interconnects for scaled technologies, which induces a bigger difference in RC delays for different RC distributions. Another reason is a relatively large contribution of parasitic capacitances to coupling capacitances and to RC delay (in addition to device intrinsic capacitances). A difference in distribution of parasitic coupling capacitances in advanced nodes may have a significantly bigger impact on RC delay mismatch for symmetric nets, than in older technologies (where device capacitance dominates). There may be other reasons, related to the behavior of parasitic extraction tools for advanced nodes, that is hidden from the users.
The algorithms adopted by parasitic extraction tools for coupling capacitance distributions are not discussed widely, and remain hidden from the users. There is not much control over this distribution in parasitic extractors commands and options.
Designs in advanced technology nodes are much more expensive than older nodes, in all aspects – engineering time, design, EDA tools, masks, manufacturing, wafer cost, time to tapeout, time to market, etc. That’s why false mismatches and their bigger impact in advanced nodes are much more critical and much riskier. People should start paying more attention to it – everyone, from designers and layout engineers to EDA tool vendors, to foundries, who qualify EDA tools and PDKs.
Simulation and analysis results
Post-layout SPICE simulation of a StrongARM latch [3] (see Figure 5) implemented in 5nm FinFET technology revealed a mismatch of transition times for devices M1 and M2 of ~500 fs, which was much higher than the upper limit spec for this mismatch (~30 fs). The layout was relatively small, and its visual inspection did not reveal any asymmetries. Designers and layout engineers did several iterations of the layout, trying to get rid of the mismatch in simulations – which took them over two weeks to do, without a success.
Flipping the layout around the Y axes resulted in a post-layout netlist that showed a mismatch with an opposite sign: –370 fs. This result is a clear, convincing argument that this mismatch of +500/-370 fs is caused by an artifact of the parasitic extraction tool.
Analysis of net mismatch using ParagonX™ EDA tool [4] confirmed a large RC delay difference of over 15% between nets in1 and in2 – with this difference changing its sign for the original and flipped layouts. Subsequent visualization of coupling capacitances using ParagonX further confirmed a strong asymmetry of their distributions. (These plots cannot be shown in this paper for third-party confidentiality reasons).
Figure 5. Schematic of StrongARM latch. Nets in1 and in2 should be matched for RC delay.
Interestingly, both resistances and net-to-net coupling capacitances for nets in1 and in2 were matched to a very high accuracy. Resistances were matched better than 0.05%, and coupling capacitances were matched better than 0.2%. This is a common effect we observed on many post-layout netlists – while capacitances and resistances on matched nets are very close, RC delays may be quite different, due to the effect discussed in this paper.
We believe that the 0.2% of capacitance difference is caused by the inaccuracy of rule-based (pattern-matching based) capacitance extraction. A much higher accuracy in capacitance extraction can be obtained using a random-walk based field solvers (FS), with a user-controlled accuracy goal settings. It is always recommended to use selected net FS extraction mode for nets whose capacitive matching (or binary or non-binary weighting – for capacitor array in SAR ADC) is critical for the circuit operation.
Discussion
Post-layout circuit simulation is considered a golden standard for analyzing and simulating custom, transistor-level IC designs. The observed false mismatch effect leads to an interesting question: how accurate is post-layout simulation? Obviously, post-layout simulation accuracy cannot be higher than the parasitic extraction tool accuracy. And while capacitance and resistance extraction is, in general, quite accurate, a crude distribution of coupling capacitances over the nodes of parasitic resistors network may lead to errors of ~500fs (or more) in transient and AC simulations. This finding may have important implications for the trustworthiness and accuracy of SPICE simulation for precision and high-speed analog designs, for timing analysis, and for other applications. As a minimum, the industry needs to establish a methodology for detecting, debugging, resolving, or getting around (see more on this in the next section).
Just as importantly, false mismatches, induced by extraction artifacts, may mask a real layout and electrical mismatch, caused by the differences in layouts and contexts of matched nets. Detecting a real mismatch becomes difficult or even impossible, in the presence of false mismatches. Also, a real mismatch may look like zero or small mismatch, if false and real mismatch coincidentally cancel each other – which is also a high-risk factor.
Practical recommendations
We can give the following recommendations:
1. For circuit designers and layout engineers:
a. Pay more attention to mismatches in general and to false mismatches caused by incorrect parasitic extraction in particular.
b. Increase the awareness of these effects. Request EDA tool vendors to improve the accuracy and get rid of such artifacts in parasitic extraction related to coupling capacitors distribution.
c. Use a field solver for accurate, controlled capacitance extraction of matched nets (if capacitance matching is critical).
d. Use ParagonX or scripts to proactively check and verify net and device matching in post-layout netlists, to debug such problems, and to improve the layout matching.
2. For EDA tool vendors: Improve the accuracy of parasitic extraction tools, and in particular, improve the quality of coupling capacitors distribution.
3. For foundries: Perform more thorough verification and qualification of parasitic extraction tools, related to net matching and to the quality of coupling capacitors distributions.
4. For EDA researchers: Come up with better algorithm and methodologies to improve the accuracy of post-layout netlists without exploding their size.
5. For all: Check for false mismatches in your design flow, introduced by parasitic extraction:
a. Create layouts by applying symmetry transformation to the original layout (see Figure 6), such as:
i. Flip around the X axis.
ii. Flip around the Y axis.
iii. Rotate by 180 degrees, and by 90 or 270 degrees (if DRC allows that).
b. Perform parasitic extraction.
c. Use ParagonX to compare post-layout netlists for original and transformed layout.
i. ParagonX detects / debugs mismatches much faster and easier than SPICE.
d. If ParagonX is not available, use post-layout SPICE simulation to compare two post-layout netlists; do STA analysis and comparison for custom digital.
e. In the case of significant differences, indicative of false mismatches:
i. Perform visual inspection of the layouts (if possible).
ii. Report findings to parasitic extraction tool vendors, and to foundries.
Figure 6. Layout transformations that can help identify a false net mismatch. Electrical characteristics are invariant with respect to these transformations, so parasitic capacitances, resistances, delays, devices, and SPICE simulations should be invariant as well.
Recommendations in section (5) above are based on a very basic, fundamental principle of symmetry in physics and mathematics – if a system possesses a certain symmetry, the characteristics of the system should display the same symmetry. The geometrical transformation symmetry of IC designs stems from the fact that circuit electrical characteristics are invariant with respect to these transformations.
Note that post-layout netlists for transformed layouts may have internal (non-port) nets, device instances, and instance pin names different from the original layout and netlist. Care must be taken when comparing transformed netlists, to make sure that the comparison is done on topologically identical objects (nets, instances, and instance pins).
It’s interesting, that to verify the accuracy of the parasitic extraction tool, we do not need another, more accurate, a golden reference tool – we can use the same tool, and see if it produces the same results for layouts that are rotated or flipped. Obviously, the RC delay should not depend on the orientation of the chip in space.
Feedback from the readers is welcome
Have you experienced or struggled with this or similar problems caused by IC layout parasitics? We welcome you to share your feedback, comments, suggestions, or frustration on parasitic effects, extraction tools, circuit implications, and layout debugging topics.
Maxim Ershovis a scientist, engineer, and entrepreneur. His expertise is in physics, mathematics, semiconductor devices, and EDA. Prior to co-founding Diakopto, Maxim was responsible for parasitic extraction at Apple’s Silicon Engineering Group. Before Apple, he was CTO of Silicon Frontline Technology, where he architected and successfully brought to market several industry-leading tools such as R3D and Rmap. Maxim also worked as device engineer at PDF Solutions, T-RAM Semiconductor and Foveon.
Prior to moving to the industry, he was a professor at Georgia State University and University of Aizu. Maxim graduated with a Ph.D. in Solid State Electronics from the Moscow Institute of Physics and Technology and won the first place in the Physics Olympiads (USSR) for high schools and for universities.
References
[1] “The art of analog layout”, 2nd ed., A. Hastings, Prentice Hall, 2005.
[2] “CMOS IC Layout: Concepts, Methodologies, and Tools”, D.Clein, Newnes, 1999.
[3] “The StrongARM Latch” (A Circuit for all seasons), B.Razavi, IEEE Solid-State Circuits Magazine, v. 7, no.2, p. 12-17, 2015.
The hand-wringing over Elon Musk’s takeover of Twitter began in earnest, Friday, as General Motors announced it would suspend advertising on the platform. Ford Motor Company, too, said it would take a step back.
The news of Musk’s completion of his Twitter acquisition completely eclipsed Mobileye’s hugely successful initial public offering and Ford and Volkswagen’s exit from their Argo.ai autonomous vehicle joint venture. But its relevance to both of those events is clear.
The concern across the automotive industry was that Musk will weaponize Twitter to advance Tesla’s electric vehicle market dominance – while downplaying competing voices and messages on Twitter. The pearl-clutching by GM seems pointless in a post-Truth world.
Musk, CEO of Tesla, has long been a liar of titanic dimensions. He’s lied about his personal and Tesla’s finances, lied about being a Tesla founder, lied about the current and future performance of Tesla vehicles, lied about selling Tesla, lied about taking Tesla private.
Lying is what Musk does best. And he is in good company.
Liars are extremely popular on social media – from Twitter and Meta/Facebook to Instagram, Tik Tok, Whatsapp, and Snapchat. The most popular posters are paid influencers for whom sponsored lying is their stock in trade.
Elsewhere, compromised commentary is driven by stock ownership with critics holding short positions and fans touting stocks they own – without disclosing that ownership. It’s impossible to get a straight story.
In the “news”-infused world we live truth is an orphan. This is one of the reasons I tend to eschew auto shows. Auto shows represent the pinnacle of paid messaging. The straight dope, the skinny, is not invited to the auto show – though the press is present in force.
In this context, it is utterly amusing that any marketing or communication executive in the automotive industry would be raising red flags over Musk potentially bending Twitter to his will. Marketers have been working diligently to bend all social media platforms to their marketing will. Musk has simply taken ownership of one of those platforms.
Make no mistake. We live in a post-Truth world.
Scanning the headlines across the full range of news and information sources available physically and online puts one in the position of Diogenes – holding a lantern to the faces of the citizens of Athens seeking an honest man. Is anyone honest anymore? Was anyone ever honest?
Whether in pursuit of political news or even movie reviews, nearly every source of information and insight has been co-opted and corrupted. Opinions are regularly bought and paid for. Influence is the coin of the realm and available for a price.
Musk is the master of the marketing masque. Tesla has been shipping cars with lousy build quality for years and charging for a Full Self Driving feature – that does no such thing – and getting away with it.
Regulators, politicians, consumers, competitors, law enforcement – no one has been able to stop Musk. Now, as CEO of Twitter, he is perched atop the social media demimonde in full-self-aggrandizing mode.
In this context, it is no surprise that Ford and Volkswagen chose to terminate their own self-driving venture Argo.ai. Argo.ai was headed by Bryan Salesky, a former Google executive who assiduously avoided the spotlight.
Salesky loathed the demands of marketing and messaging regarding the work of Argo.ai. He refused to be lured into the trap of spinning a Musk-like yarn regarding Argo.ai’s progress for the public or investors.
Salesky’s unwillingness to participate in the autonomous vehicle marketing moshpit sadly doomed Argo.ai. Diogenes might have approved of Salesky, but investors did not.
The message for us all in a fake-it-til-you-make-it world is the need to embrace the dissembling and exaggeration to spin up public enthusiasm and deceive investors in order to achieve success. No one seeks honesty on Twitter. No one ever did. The least we can do in a world where so many are seeking to deceive us is try hard not to deceive ourselves.
