The market is trending towards integrating and stacking multiple chiplets into a single package to meet the growing demands of speed, connectivity, and intelligence.  However, designing and signing off chiplets and packages individually is time-...(read more)

PCI-SIG DevCon 2024 was a great success for Cadence. We posted the blog, Cadence Demonstrates Complete PCIe 7.0 Solution at PCI-SIG DevCon ‘24 a day before the event to advertise our IP solutions for PCIe 7.0, which resulted in a lot of extra traffic at our booth. All of the attendees were excited to see Cadence demonstrate the robustness of 128GT/s PCIe 7.0 IP's TX and RX capabilities over a real-world, low-latency, non-retimed, linear optics connector. We achieved and maintained a consistent, impressive pre-FEC BER of ~3E-8 (PCIe spec requires 1E-6) for the entire duration of the event, spanning over two full days with no breaks. This provides an ample margin for RS FEC. As seen in the picture below, the receiver Eye PAM4 histograms have good linearity and margin. This is the world’s first stable demonstration of 128 GT/s TX and RX over off-the-shelf optical connectors—by far the main attraction of DevCon this year.

Cadence 128 GT/s TX and RX capability over optics

Block diagram of Cadence PHY for PCIe 7.0 128 GT/s demo setup with linear pluggable optics

As a leader in PCIe, our PCIe controller architect Anish Mathew shared his valuable insights on an important topic: “Impact of UIO ECN on PCIe Controller Design and Performance,” highlighting the strides made by the Cadence design team in achieving this implementation.

Anish Mathew presenting “Impact of UIO ECN on PCIe Controller Design and Performance”

In summary, Cadence had a dominating presence on the demo floor with a record number of PCIe demos:

• PCIe 7.0 over optics
• PCIe 7.0 electrical
• PCIe 6.0 RP/EP interop back-to back
• PCIe 6.0 protocol in FLIT mode with Lecroy Exerciser (at Cadence booth)
• PCIe 6.0 protocol in FLIT mode (at the Lecroy booth)
• PCIe 6.0 JTOL with Anritsu and Tektronix equipment (at Tektronix booth)
• PCIe 6.0 protocol with Viavi Protocol Analyzer (at Viavi booth)
• PCIe 6.0 System Level Interop Demo with Gen5 platform (at SerialTek booth)

The Cadence team and its partners did a great job in coordinating and setting up the demos that worked flawlessly. This was the culmination of many weeks of hard work and dedication. Four different vendors featured our IP for PCIe 6.0. They attracted a lot of attention and drove traffic back to us.

Highlights of Cadence demos for PCIe 7.0 and 6.0

Cadence team at the PCI-SIG Developers Conference 2024

Thanks to everyone who attended the 32nd PCI-SIG DevCon. We really appreciate your interest in Cadence IP, and a big thanks to our partners and customers for all the positive feedback and for creating so much buzz for the Cadence brand.

In the rapidly evolving landscape of automotive electronics, traditional monolithic design approaches are giving way to something more flexible and powerful—chiplets. These modular microchips, which are themselves parts of a whole silicon system, offer unparalleled potential for improving system performance, reducing manufacturing costs, and accelerating time-to-market in the automotive sector. However, the transition to working with chiplets in automotive electronics is not without its challenges.

Designers must now grapple with a new set of considerations, such as die-to-die interconnect standards, complex processes, and the integration of diverse IPs. Advanced toolsets and standardized design approaches are required to meet these challenges head-on and elevate the potential of chiplets in automotive innovation. In the following discourse, we will explore in detail the significance of chiplets in the context of automotive electronics, the obstacles designers face when working with this paradigm, and how Cadence comprehensive suite of IPs, tools, and flows is pioneering solutions to streamline the chiplet design process.

Unveiling Chiplets in Automotive Electronics

For automotive electronics, chiplets offer a methodology to modularize complex functionalities, integrate different chiplets into a package, and significantly enhance scalability and manufacturability. By breaking down semiconductor designs into a collection of chiplets, each fulfilling specific functions, automotive manufacturers can mix and match chiplets to rapidly prototype new designs, update existing ones, and specialize for the myriad of use cases found in vehicles today.

The increasing significance of chiplets in automotive electronics comes as a response to several industry-impacting phenomena. The most obvious among these is the physical restriction of Moore's Law, as large die sizes lead to poor yields and escalating production costs. Chiplets with localized process specialization can offer superior functionality at a more digestible cost, maintaining a growth trajectory where monolithic designs cannot. Furthermore, chiplets support the assembly of disparate technologies onto a single subsystem, providing a comprehensive yet adaptive solution to the diverse demands present in modern vehicles, such as central computing units, advanced driver-assistance systems (ADAS), infotainment units, and in-vehicle networks. This chiplet-based approach to functional integration in automotive electronics necessitates intricate design, optimization, and validation strategies across multiple domains.

The Complexity Within Chiplets

Yet, with the promise of chiplets comes a series of intricate design challenges. Chiplets necessitate working across multiple substrates and technologies, rendering the once-familiar 2-dimensional design space into the complex reality of multi-layered, sometimes even three-dimensional domains. The intricacies embedded within this design modality mandate devoting considerable attention to partitioning trade-offs, signal integrity across multiple substrates, thermal behavior of stacked dies, and the emergence of new assembly design kits to complement process design kits (PDKs).

To effectively address these complexities, designers must wield sophisticated tools that facilitate co-design, co-analysis, and the creation of a robust virtual platform for architectural exploration. Standardizations like the Universal Chip Interconnect Express (UCIe) have been influential, providing a die-to-die interconnect foundation for chiplets that is both standardized and automotive-ready. The availability of UCIe PHY and controller IP from Cadence and other leading developers further eases the integration of chiplets in automotive designs.

The Role of Foundries and Packaging in Chiplets

Foundries have also pivoted their services to become a vital part of the chiplet process, providing specialized design kits that cater to the unique requirements of chiplets. In tandem, packaging has morphed from being a mere logistical afterthought to a value-added aspect of chiplets. Organizations now look to packaging to deliver enhanced performance, reduced power consumption, and the integrity required by the diverse range of technologies encompassed in a single chip or package. This shift requires advanced multiscale design and analysis strategies that resonate across a spectrum of design domains.

Tooling Up for Chiplets with Cadence

Cadence exemplifies the rise of comprehensive tooling and workflows to facilitate chiplet-based automotive electronics design. Their integrations address the challenges that chiplet-based SoCs present, ensuring a seamless design process from the initial concept to production. The Cadence suite of tools is tailored to work across design domains, ensuring coherence and efficiency at every step of the chiplet integration process.

For instance, Cadence Virtuoso RF subflows have become critical in navigating radio frequency (RF) challenges within the chiplets, while tools such as the Integrity 3D-IC Platform and the Allegro Advanced Multi-Die Package Design Solution have surfaced to enable comprehensive multi-die package designs. The Integrity Signal Planner extends its capabilities into the chiplet ecosystem, providing a centralized platform where system-wide signal integrity can be proactively managed. Sigrity and Celsius, on the other hand, offer universally applicable solutions that take on the challenges of chiplets in signal integrity and thermal considerations, irrespective of the design domain. Each of these integrated analysis solutions underscores the intricate symphony between technology, design, and packaging essential in unlocking the potential of chiplets for automotive electronics.

Cadence portfolio includes solutions for system analysis, optimization, and signoff to complement these domain-specific tools, ensuring that the challenges of chiplet designs don't halt progress toward innovative automotive electronics. Cadence enables designers to engage in power- and thermal-aware design practices through their toolset, a necessity as automotive systems become increasingly sophisticated and power-efficient.

A Standardized Approach to Success with Chiplets

Cadence’s support for UCIe underscores the criticality of standardized approaches for heterogeneous integration by conforming to UCIe standards, which numerous industry stakeholders back. By co-chairing the UCIe Automotive working group, Cadence ensures that automotive designs have a universal and standardized Die-to-Die (D2D) high-speed interface through which chiplets can intercommunicate, unleashing the true potential of modular design.

Furthermore, Cadence champions the utilization of virtual platforms by providing transaction-level models (TLMs) for their UCIe D2D IP to simulate the interaction between chiplets at a higher level of abstraction. Moreover, individual chiplets can be simulated within a chiplet-based SoC context leveraging virtual platforms. Utilizing UVM or SCE-MI methodologies, TLMs, and virtual platforms serve as first lines of defense in identifying and addressing issues early in the design process before physical silicon even enters the picture.

Navigating With the Right Tools

The road to chiplet-driven automotive electronics is one paved with complexity, but with a commitment to standards, it is a path that promises significant rewards. By leveraging Cadence UCIe Design and Verification IP, tools, and methodologies, automotive designers are empowered to chart a course toward chiplets and help to establish a chiplet ecosystem. With challenges ranging from die-to-die interconnect to standardization, heterogeneous integration, and advanced packaging, the need for a seamless integrated flow and highly automated design approaches has never been more apparent. Companies like Cadence are tackling these challenges, providing the key technology for automotive designers seeking to utilize chiplets for the next-generation E/E architecture of vehicular technology.

In summary, chiplets have the potential to revolutionize the automotive electronics industry, breathing new life into the way vehicles are designed, manufactured, and operated. By understanding the significance of chiplets and addressing the challenges they present, automotive electronics is poised for a paradigm shift—one that combines the art of human ingenuity with the power of modular and scalable microchips to shape a future that is not only efficient but truly intelligent.

Learn more about how Cadence can help to enable automakers and OEMs with various aspects of automotive design.

We live in a rapidly growing “digitalized world,” with an ever-increasing need for video/music streaming, gaming, AI/machine learning, etc. All of these propel demand on modern SoC design to quickly evolve the SoC by fitting more sophisti...(read more)

The automotive industry is currently on the cusp of a radical evolution, steering towards a future where cars are not just vehicles but sophisticated, software-defined vehicles (SDV). This shift is marked by an increased reliance on automation and a significant increase in the use of sensors to improve safety and reliability. However, the increasing number of sensors has led to higher compute demands and poses challenges in managing a wide variety of data. The traditional method of using separate processors to manage each sensor's data is becoming obsolete. The current trends necessitate a unified processing system that can deal with multimodal sensor data, utilizing traditional Digital Signal Processing (DSP) and AI-driven algorithms. This approach allows for more efficient and reliable sensor fusion, significantly enhancing vehicle perception. Developers often face difficulties adhering to stringent power, performance, area, and cost (PPAC) and timing constraints while designing automotive SoCs.

Cadence, with its groundbreaking products and AI-powered processors, is enabling designers and automotive manufacturers to meet the future sensor fusion demands within the automotive sector. At the recent CadenceLive Silicon Valley 2024, Amol Borkar, product marketing director at Cadence, showcased the company's dedication and forward-thinking solutions in a captivating presentation titled "Addressing Tomorrow’s Sensor Fusion Needs in Automotive Computing with Cadence." This blog aims to encapsulate the pivotal takeaways from the presentation. If you missed the chance to watch this presentation live, please click here to watch it.

Significant Trends in the Automotive Market – Industry Landscape

We are witnessing a revolution in automotive technology. Innovations like occupant and driver monitoring systems (OMS, DMS), 4D radar imaging, LiDAR technology, and 360-degree view are pushing the boundaries of what's possible, leading us into an era of remarkable autonomy levels—ranging from no feet or hands required to eventually no eyes needed on the road.

Sensor Fusion and Increasing Processing Demands—Sensor fusion effectively integrates data from different sensors to help vehicles understand their surroundings better. Its main benefit is in overcoming the limitations of individual sensors. For example, cameras provide detailed visual information but struggle in low-light or lousy weather. On the other hand, radar is excellent at detecting objects in these conditions but lacks the detail that cameras provide. By combining the data from multiple sensors, automotive computing can take advantage of their strengths while compensating for their weaknesses, resulting in a more reliable and robust system overall.

One thing to note is that the increased number of sensors produces various data types, leading to more pre-processing.

On-Device Processing—As the industry moves towards autonomy, there is an increasing need for on-device data processing instead of cloud computing to enable vehicles to make informed decisions. Embracing on-device processing is a significant advancement for facilitating real-time decisions and avoiding round-trip latency.

AI Adoption—AI has become integral to automotive applications, driving safety, efficiency, and user experience advancements. AI models offer superior performance and adaptability, making future-proofing a crucial consideration for automotive manufacturers. AI significantly enhances sensor fusion algorithms, offering scalability and adaptability beyond traditional rule-based approaches. Neural networks enable various fusion techniques, such as early fusion, late fusion, and mid-fusion, to optimize the integration and processing of sensor data.

Future Sensor Fusion Needs

Automotive architectures are continually evolving. With current trends and AI integration into radar and sensor fusion applications, SoCs should be modular, flexible, and programmable to meet market demands.

Heterogeneous Architecture- Today's vehicles are loaded with various sensors, each with a unique processing requirement. Running the application on the most suitable processor is essential to achieve the best PPA. To meet such requirements, modern automotive solutions require a heterogeneous compute approach, integrating domain-specific digital signal processors (DSPs), neural processing units (NPUs), central processing unit (CPU) clusters, graphics processing unit (GPU) clusters, and hardware accelerator blocks. A balanced heterogeneous architecture gives the best PPA solution.

Flexibility and Programmability- The industry has come a long way from using computer vision algorithms such as HOG (Histogram Oriented Gradient) to detect people and objects, HAR classifier to detect faces, etc., to CNN and LSTM-based AI to Transformer models and graphical neural networks (GNN). AI has evolved tremendously over the last ten years and continues to evolve. To keep up with the evolving rate of AI, SoC design must be flexible and programmable for updates if needed in the future.

Addressing the Sensor Fusion Needs with Cadence

Cadence offers a complete suite of hardware and software products to address the increasing compute requirements in automotive. The comprehensive portfolio of Tensilica products built on the robust 32-bit RISC architecture caters to various automotive CPU and AI needs. What makes them particularly appealing is their scalability, flexibility, and configurability, offering many options to meet diverse needs.

The Xtensa family of products offers high-quality, power-efficient CPUs. Tensilica family also includes AI processors like Neo NPUs for the best power, performance, and area (PPA) for AI inference on devices or more extensive applications. Cadence also offers domain-specific products for DSPs such as HIFI DSPs, specialized DSPs and accelerators for radar and vision-based processing, and a general-purpose family of products for floating point applications.

The ConnX family offers a wide range of DSPs, from compact and low-power to high-performance, optimized for radar, lidar, and communications applications in ADAS, autonomous driving, V2X, 5G/LTE/4G, wireless communications, drones, and robotics. Tensilica's ISO26262 certification ensures compliance with automotive safety standards, making it a trusted partner for advanced automotive solutions. The Cadence NeuroWeave Software Development Kit (SDK) provides customers with a uniform, scalable, and configurable ML interface and tooling that significantly improves time to market and better prepares them for a continuously evolving AI market. Cadence Tensilica offers an entire ecosystem of software frameworks and compilers for all programming styles.

Tensilica's comprehensive software stack supports programming for DSPs, NPUs, and accelerators using C++, OpenCL, Halide, and various neural network approaches. Middleware libraries facilitate applications such as SLAM, radar processing, and Eigen libraries, providing robust support for automotive software development.

Conclusion

Cadence’s Tensilica products offer a development toolchain and various IPs tailored for the automotive industry, covering audio, vision, radar, unified DSPs, and NPUs. With ISO certification and a robust partner ecosystem, Tensilica solutions are designed to meet the future needs of automotive computing, ensuring safety, efficiency, and innovation.

Learn More

• Cadence Automotive Solutions
• Cadence Automotive IP
• Sensor Fusion and ADAS in TSMC Automotive Processes
• Revolution on the Road: How Cadence is Driving the Future of Automotive Design!
• Taming Design Complexity in Chiplet-Based Automotive Electronics
• UCIe and Automotive Electronics: Pioneering the Chiplet Revolution

The rapid rise in size and sophistication of AI/ML training models requires increasingly powerful hardware deployed in the data center and at the network edge. This growth in complexity and data stresses the existing infrastructure, driving the need for new and innovative processor architectures and associated memory subsystems. For example, even GPT-3 at 175 billion parameters is stressing the bandwidth, capacity, training time, and power of the most advanced GPUs on the market.

To this end, Cadence has shown our HBM3E memory subsystem running at 12.4Gbps at nominal voltages, demonstrating the PHY’s robustness and performance margin. The production version of our latest HBM3E PHY supports DRAM speeds of up to 10.4Gbps or 1.33TB/s per DRAM device. This speed represents a >1.6X bandwidth increase over the previous generation, making it ideal for LLM training.

Cadence has been the HBM performance leader since 2021, when we announced our first 8.4Gbps HBM3E PHY supporting >1TB/s of memory bandwidth per HBM DRAM. Customers building advanced AI processors have used this speed while building margin into their systems. Recall that HBM3E is a 3D stacked DRAM with 1024-bit wide data (16 64-bit channels). While this wide data bus enables high data transfer, routing these signals requires interposer technology (2.5D) capable of routing close to 2000 signals (data and control), including silicon, RDL, and silicon bridges.

The interposer design is critical for the system to operate at these data rates. Cadence provides 2.5D reference designs, including the interposer and package, as part of our standard IP package. As demonstrated in our test silicon, these designs give customers confidence they will meet their memory bandwidth requirements. The reference design is also a good starting point, helping to reduce development time and risk. Our expert SI/PI and system engineers work closely with customers to analyze their channels to ensure the best system performance.

Even as HBM3E delivers the highest memory bandwidth today, the industry keeps pushing forward. JEDEC recently announced that HBM4, the next version of the HBM DRAM standard, is nearing completion. JEDEC calls HBM4 an “evolutionary step beyond the currently published HBM3 standard.” They also claim HBM4 “enhancements are vital for applications that require efficient handling of large datasets and complex calculations.” HBM4 will support AI training applications, high-performance computing (HPC), and high-end graphics cards.

Cadence will continue to push the HBM performance boundaries to ensure designers of these data-intensive systems can take advantage of the highest memory bandwidth available.

Learn more about Cadence HBM PHY IP products.

The generative AI market is experiencing rapid growth, driven by the increasing parameter size of Large Language Models (LLMs). This growth is pushing the boundaries of performance requirements for training hardware within data centers. For an in-depth look at this, consider the insights provided in "HBM3E: All About Bandwidth". Once trained, these models are deployed across a diverse range of applications. They are transforming sectors such as finance, meteorology, image and voice recognition, healthcare, augmented reality, high-speed trading, and industrial, to name just a few.

The critical process that utilizes these trained models is called AI inference. Inference is the capability of processing real-time data through a trained model to swiftly and effectively generate predictions that yield actionable outcomes. While the AI market has primarily focused on the requirements of training infrastructure, there is an anticipated shift towards prioritizing inference as these models are deployed.

The computational power and memory bandwidth required for inference are significantly lower than those needed for training. Inference engines typically need between 300-700GB/s of memory bandwidth, compared to 1-3TB/s for training. Additionally, the cost of inference needs to be lower, as these systems will be widely deployed not only in data centers but also at the network's edge (e.g., 5G) and in end-user equipment like security cameras, cell phones, and automobiles.

When designing an AI inference engine, there are several memory options to consider, including DDR, LPDDR, GDDR, and HBM. The choice depends on the specific application, bandwidth, and cost requirements. DDR and LPDDR offer good memory density, HBM provides the highest bandwidth but requires 2.5D packaging, and GDDR offers high bandwidth using standard packaging and PCB technology.

The GDDR7 standard, announced by JEDEC in March of this year, features a data rate of up to 192GB/s per device, a chip density of 32Gb, and the latest data integrity features. The high data rate is achieved by using PAM3 (Pulse Amplitude Modulation) with 3 levels (+1, 0, -1) to transmit 3 bits over 2 cycles, whereas the current GDDR6 generation uses NRZ (non-return-to-zero) to transmit 2 bits over 2 cycles.

GDDR7 offers many advantages for AI Inference having the best balance of bandwidth and cost. For example, an AI Inference system requiring 500GB/s memory bandwidth will need only 4 GDDR7 DRAM running at 32Gbp/s (32 data bits x 32Gbp/s per pin = 1024Gb/s per DRAM). The same system would use 13 LPDDR5X PHYs running at 9.6Gbp/s, which is currently the highest data rate available (32 data bits x 9.6Gb/s = 307Gb/s per DRAM).

Cadence stands at the forefront of AI inference hardware support, being the first IP company to roll out GDDR7 PHYs capable of impressive speeds up to 36Gb/s across various process nodes. This milestone builds on Cadence's established leadership in GDDR6 PHY IP, which has been available since 2019. The company caters to a diverse client base spanning AI inference, graphics, automotive, and networking equipment.

While GDDR7 continues to utilize standard PCB board technology, the increased signal speeds seen in GDDR6 (20Gbp/s) and now GDDR7 (36Gb/s) calls for careful attention with the physical design to ensure optimized system performance. In addition to providing the PHY, Cadence also offers comprehensive PCB and package reference design, which are essential in helping customers achieve optimal signal and power integrity (SI/PI) for their systems.

Cadence is dedicated to ensuring customer success beyond just providing hardware. They provide expert support in SI/PI, collaborating closely with customers throughout the design process. This approach ensures that customers can benefit from Cadence's expertise in navigating the complexities of high-speed design and achieving optimal performance in their AI inference systems.

As the AI market continues to advance, Cadence remains at the forefront by offering a comprehensive memory IP portfolio tailored for every segment of this dynamic market. From DDR5 and HBM3E, which cater to the intensive demands of training in servers and high-performance computing (HPC), to LPDDR5X designed for low-end inference at the network edge and in consumer devices, Cadence's offerings cover a wide range of applications.

Looking to the future, Cadence is dedicated to innovating at the forefront of memory system performance, ensuring that the evolving needs of AI training and inference are met with the highest standards of excellence. Whether it's pushing the boundaries with GDDR7 or exploring new technologies, Cadence is dedicated to driving the AI revolution forward, one breakthrough at a time.

Learn more about Cadence GDDR7 PHY

Learn more about Cadence Simulation VIP for GDDR7.

The demand for higher-performance computing is greater than ever. Cutting-edge applications in artificial intelligence (AI), big data analytics, and databases require high-speed memory systems to handle the ever-increasing volumes and complexities of data. Advancements in cloud computing and machine virtualization are stretching the limits of current capabilities. AI applications hosted in the cloud rely on fast access and reduced latency in memory systems, which is amplified by an increasing number of CPU and GPU cores.

Introducing the DDR5 Multiplexed Rank DIMM (MRDIMM), the next-generation memory module technology designed to meet the needs of high-performance computing (HPC) and AI in cloud applications. By leveraging existing DDR5 DRAM memory devices, MRDIMM modules not only double the DRAM data rate but also maintain the RAS capabilities of the industry-proven RDIMM modules, setting a new precedent for memory module performance.

Let’s compare RDIMM and MRDIMM modules using the same DRAM parts. Today, high-speed production DDR5 RDIMM modules run at 5600Mbps. Those modules use DDR5 DRAM parts, which also run at 5600Mbps. An MRDIMM module using the same DDR5 5600Mbps DRAM parts will run at a blazing 11.2Gbps.

One key metric for best-in-class performance, low bit error rate (BER), and ease of adoption is the eye diagram. The eye diagram illustrates at-speed system margin and accurately represents DDR system quality when captured with a pseudo-random binary sequence (PRBS)-like pattern. The diagram below illustrates Cadence’s 3nm silicon write eye diagram for DDR5 MRDIMM IP running at 12.8Gbps.

Cadence 3nm DDR5 MRDIMM 12.8Gbps test chip write eye diagram, design kit is available today

The eye diagram is captured using a PRBS-like pattern, incorporating a package and system board representative of a typical MRDIMM channel. Using PRBS-like patterns is crucial for capturing accurate eye diagrams. Repetitive clock-like data patterns create deceptively “open eyes” that do not reflect the real system performance. Effects like intersymbol interference, simultaneous switching, reflections, and crosstalk are not accurately reflected in the eye diagrams for parallel interfaces like DDR using non-random data streams. Relying on improperly captured eye diagrams inevitably leads to a significantly worse real system BER than conveyed by that eye diagram.

Doubling the DDR5 RDIMM data rate is challenging. Achieving high performance while optimizing for area and power requires multiple design techniques. Feed-forward equalization (FFE), decision feedback equalization (DFE), continuous-time linear equalization (CTLE), and T-coils are required to reach 12.8Gbps MRDIMM data rates in multi-channel systems. Building a production-worthy 12.8Gbps DDR5 MRDIMM IP requires engineering expertise that comes from many generations of memory interface design and production experience. Cadence has developed this expertise through multiple DDR5/4, LPDDR5X/5, and GDDR6 designs in different technology nodes and foundries. For instance, Cadence’s GDDR6 IP is available in three foundries and ten process nodes, with mass production at speeds exceeding 22Gbps.

For your next project, consider DDR5 12.8Gbps MRDIMM, a technology that not only doubles the bandwidth of DDR5 RDIMM but also promises rapid proliferation into next-generation AI, data center, HPC, and enterprise applications. With its cutting-edge capabilities, the Cadence DDR5 12.8Gbps MRDIMM IP is ready to power the future of computing.

Today's high-performance computing systems often require the designer to instantiate multiple CPU or DSP cores in their subsystem. However, the performance gained by using multiple CPUs comes with additional programming complexity, especially when accessing shared memory data structures and hardware peripherals. CPU cores need to access shared data in an atomic fashion in a multi-core environment. Locking is the most basic requirement for data sharing. A core takes the lock, accesses the shared data structure, and releases the lock. While one core has the lock, other cores are disallowed from accessing the same data structure. Typically, locking is implemented using an atomic read-modify-write bus transaction on a variable allocated in an uncached memory.

This blog shares the AXI4 locking mechanism when implementing an Xtensa LX-based multi-core system on a Xilinx FPGA platform. It uses a dual-core design mapped to a KC705 platform as an example.

Exclusive Access to Accomplish Locking

The Xtensa AXI4 manager provides atomic access using the AXI4 atomic access mechanism. While Xtensa's AXI manager interface generates an exclusive transaction, the subordinate's interface is also expected to support exclusive access, i.e., AXI monitoring. Xilinx BRAM controller's AXI subordinate interface does not support exclusive access, i.e., AXI monitoring: AXI Feature Adoption in Xilinx FPGAs.

Leveraging Xtensa AXI4 Subordinate Exclusive Access

The Xtensa LX AXI subordinate interface supports exclusive access. One approach is to utilize this support and allocate locks in one of the core's local data memories. Ensure that the number of external exclusive managers is configured, typically to the number of cores (Figure 1).

Figure 1

Note that the Xtensa NX AXI subordinate interface does not support exclusive access. For an Xtensa NX design, shared memory with AXI monitoring is required.

In Figure 2, the AXI_crossbar#2 (block in green) routes core#0's manager AXI access (blue connection) to both core's local memories. Core#1's manager AXI (yellow connection) can also access both core's local memories. Locks can be allocated in either core's local data memory.

In-Bound Access on Subordinate Interface

On inbound access, the Xtensa AXI subordinate interface expects a local memory address, i.e., an external entity needs to present the same address as the core would use to access local memory in its 4GB address space. AXI address remap IP (block in pink) translates the AXI system address to each core's local address. For example, assuming locks are allocated in core#0's local memory, core#1 generates an AXI exclusive to access a lock allocated in core#0's local memory (yellow connection). AXI_crossbar#2 forwards transaction to M03_AXI port (green connection). AXI_address_remap#1 translates the AXI system address to the local memory address before presenting it to core#0's AXI subordinate interface (pink connection).

It is possible to configure cores with disjoint local data memory addresses and avoid the need for an address remap IP block. But then it will be a heterogeneous multi-core design with a multi-image build. An address remap IP is required to keep things simple, i.e., a homogeneous multi-core with a single image build. A single image uses a single memory map. Therefore, both cores must have the same view of a lock, i.e., the lock's AXI bus address must be the same for both.

Figure 2

AXI ID Width

Note Xtensa AXI manager interface ID width=4 bits. Xtensa's AXI subordinate interface ID width=12 bits. So, you must configure AXI crossbar#2 and AXI address remap AXI ID width higher than 4. AXI IDs on a manager port are not globally defined; thus, an AXI crossbar with multiple manager ports will internally prefix the manager port index to the ID and provide this concatenated ID to the subordinate device. On return of the transaction to its manager port of origin, this ID prefix will be used to locate the manager port, and the prefix will be truncated. Therefore, the subordinate port ID is wider in bits than the manager port ID. Figure 3 shows the Xilinx crossbar IP AXI ID width configuration.

Figure 3

Software Tools Support

Cadence tools provide a way to place locks at a specific location. For more details, please refer to Cadence's Linker Support Packages (LSP) Reference Manual for Xtensa SDK. .xtos.lock(green) resides in core#0's local memory and holds user-defined and C library locks. The lock segment memory attribute is defined as shared inner (cyan) so that L32EX and S32EX instructions generate an exclusive transaction on an AXI bus. See Figure 4. The stack and per-core Xtos and C library contexts are allocated in local data memory (yellow).

…………..LSP memory map………….
BEGIN dram0
0x40000000: dataRam : dram0 : 0x8000 : writable ;
dram0_0 : C : 0x40000400 - 0x40007fff : STACK : .dram0.rodata .clib.percpu.data .rtos.percpu.data .dram0.data .clib.percpu.bss .rtos.percpu.bss .dram0.bss;
END dram0
…………………
BEGIN sysViewDataRam0
0xA0100000: system : sysViewDataRam0 : 0x8000 : writable, uncached, shared_inner;
lockRam_0 : C : 0xA0100000 - 0xA01003ff : .xtos.lock;
END sysViewDataRam0
…………..

Figure 4

Please visit the Cadence support site for more information on emulating Xtensa cores on FPGAs.

Cadence tapes out 32G UCIe interface IP for high speed, highly efficient chiplet designs and demonstrate high data rate performance in TSMC's 3nm technology(read more)

As vehicles transition into interconnected ecosystems, artificial intelligence and advanced technologies become increasingly crucial. Infotainment systems have evolved beyond mere music players to become central hubs for connectivity, entertainment, and navigation. With global demand for comfort, convenience, and safety rising, the automotive infotainment market is experiencing significant growth. Valued at USD14.99 billion in 2023, it is projected to grow at a compound annual growth rate (CAGR) of 9.9% from 2024 to 2030.

To keep pace with this evolution, infotainment systems must accommodate a range of workloads, including audio, voice, AI, and vision technologies. This requires a flexible, scalable Digital Signal Processor (DSP) solution that acts as an offload engine for the main application processor. Integrating a single DSP for varied functions offers a cost-effective solution for high-performance, low-power processing, which aligns well with the needs of Electric Vehicles (EVs).

If you missed the detailed presentation by Casey Ng, Product Marketing Director at Cadence at CadenceLIVE 2024, register at the CadenceLIVE On-Demand site to access it and other insightful presentations. Stay ahead of the curve and explore the future of innovative electronics with us.

Cadence Infotainment Solution: Leading the Charge

Cadence Tensilica HiFi DSPs play a crucial role in enhancing audio capabilities in vehicle infotainment systems. They support applications like voice recognition, hands-free calling, and deliver immersive audio experiences. This technology is also paramount for features such as active noise control, which reduces road and cabin noise, and acoustic event detection for identifying unusual sounds like broken glass. One notable innovation is the "audio bubble," enabling personalized audio zones within the vehicle, ensuring passengers enjoy distinct audio settings.

Cadence HiFi DSP technology enriches the driving experience for electric vehicles by mimicking traditional engine sounds, while its advanced audio processing ensures optimal performance across various digital radio standards. It significantly contributes to noise reduction, hence improving the cabin experience. Integrating a Double Precision Floating Point Unit (FPU) stands out, as it upgrades audio performance and Signal-to-Noise Ratio (SNR) through efficient 64-bit processing, allowing control over numerous speakers without hitches.

These advancements distinguish the DSP as an essential tool in evolving infotainment systems, offering unmatched performance and adaptability. Tensilica HiFi processors, crucial to advanced infotainment SoCs, serve as efficient offload processors, augmenting real-time execution and energy efficiency. Cadence’s ecosystem, with over 200 codecs and software partnerships, propels the evolution of innovative infotainment systems. Introducing the HiFi 5s DSP marks a new era in connected car experiences, setting the stage for groundbreaking advancements.

Exploring Tomorrow with HiFi 5s DSP Technology

The HiFi 5s represents the apex of audio and AI digital signal processing performance. Built on the Xtensa LX8 platform, it introduces capabilities like auto-vectorization, which allows standard C code to be automatically optimized for performance. This synergy of hardware and software co-design marks a significant step forward in DSP technology. By leveraging its extended Single Instruction, Multiple Data (SIMD) capabilities alongside features like a double-precision floating-point unit (DP_FPU), the HiFi 5s delivers unparalleled precision and speed improvements in signal and audio processing tasks. Equally notable are its branch prediction and L2 cache enhancements, which optimize system performance by refining the control code execution and recognizing codec efficiency. The application of such enhancements are particularly beneficial in real-world scenarios.

AI-Powered Audio

Cadence's focus on AI integration with the HiFi 5s demonstrates significant improvements in audio clarity through AI-powered solutions.

• AI models learn from real-world data and adapt dynamically, while classic DSP algorithms rely on fixed rules.
• AI can be fine-tuned for specific scenarios, whereas classic DSP lacks flexibility.
• AI handles extreme and marginal noise patterns better, generalizes well across different environments, and is robust against varying noise characteristics.

Cadence's dedication to artificial intelligence marks a pivotal shift in audio processing. Traditional DSP algorithms, bound by rigid rules, are eclipsed by AI's ability to learn dynamically from real-world data. This adaptability equips AI models to tackle challenging noise patterns and offer unmatched clarity even in noisy environments, making them ideal for automotive and consumer audio applications.

Realtime AI-Optimized Speech Enhancements by OmniSpeech and ai|coustics

OmniSpeech

Our partner, OmniSpeech, has advanced AI-based audio processing that enhances the performance of audio software, specifically for omnidirectional and dipole microphones. Impressively, their technology operates with less than 32MHz and requires only 418kB of memory.

Test results show that background noise is significantly reduced when AI employs a single omnidirectional microphone, outperforming non-AI solutions. Additionally, when using a dipole microphone with AI, there is a 3.5X improvement in the weighted Signal-to-Noise Ratio (SNR) and more than a 28% increase in the Global Mean Opinion Score (GMOS) across various background noise.

ai|coustics

ai|coustics, a Cadence partner specializing in advanced audio technologies, utilizes real-time AI-optimized speech enhancement algorithms. They leverage an extensive speech-quality dataset containing thousands of hours and 100 languages to transform low-quality audio into studio-grade audio. Their process includes:

• De-reverb, which eliminates room resonances, echoes, and reflections

• Removing artifacts from downsampling and codec compression

• Dynamic and adaptive background noise removal

• Reviving audio materials with analog and digital distortions

• Providing support for all languages, accents, and a variety of speakers

Applications include:

• Automotive: Enhances clarity of navigation commands and communication for driver safety

• Consumer audio: Improves voice clarity for better dialogue understanding in TV programs. Optimizes speech intelligibility in communication for both uplink and downlink audio streams

• Smart IoT: Boosts voice command detection and response quality

Performance Enhancements

The advancements in branch prediction and L2 cache integration have significantly boosted performance metrics across various systems. With HiFi 5s, branch prediction increases codec efficiency by an average of 5%, reaching up to 16% in optimal conditions. L2 cache improvements have drastically enhanced system-level performance, evidenced by a 2.3X boost in EVS decoder efficiency. Adding MACs and imaging ISA in imaging use cases has led to substantial advancements. When comparing HiFi 5s to HiFi 5, imaging ISA performance improvements range with >60% average performance improvements.

The Crescendo of the Future

As Cadence continues to blaze trails in DSP technology, the HiFi 5s emerges as the quintessential solution for consumer and automotive audio use cases. With a robust framework for auto-vectorization, an unmatched double-precision FPU, AI-driven audio solutions, and comprehensive system enhancements, Cadence is orchestrating the next era of audio processing, where every note is clearer, every sound richer, and every experience more engaging. It is not just the future of audio—it's the future of how we experience the world around us.

 Discover how Cadence Automotive Solutions can transform your business today!

Staying ahead of the curve is essential to meeting customer needs. Cadence has consistently demonstrated its commitment to innovation, and its latest IP portfolio available on TSMC's 3nm (N3) process is no exception. Today, rapid advancements in AI/ML, hyperscale computing (HPC), and the automotive industry are driving significant changes in technology. Let's explore the impressive array of IP that Cadence offers on this advanced node.

Memory Solutions: High-Speed and Power-Efficient

Cadence's DDR5 12.8G MRDIMM IP supports the highest speed grade Gen2 MRDIMMs and features a fully hardened PHY optimized to the customer's floorplan. The LPDDR5X IP is silicon-proven at 9.6Gbps and is ideal for power-sensitive applications, offering a fully integrated memory subsystem.

GDDR7: Leading the Way in Graphics Memory

Cadence has achieved a significant milestone with the world's first silicon-proven GDDR7 IP, supporting data rates up to 32Gbps. This IP offers the best price/performance ratio for AI interfaces, making it a game-changer in the graphics memory domain.

PCIe and CXL Solutions: Robust and Reliable

Cadence's PCIe 3.0 IP is a mature and production-proven solution available across a wide range of process nodes from 28nm to 3nm. It offers a versatile multi-link architecture for optimum SoC configurability and flexible use cases. The PCIe 6.0 and CXL 3.x solutions are silicon-proven, power-optimized, and highly robust, with jitter-tolerant capabilities. These IP are the only subsystem proven with eight lanes of controller and PHY in silicon, ensuring interoperability with leading test vendors and OEMs.

UCIe PHY: Setting New Standards

The UCIe PHY IP from Cadence are set to be generally available after successful silicon characterization in both standard and advanced package options on the TSMC N3 (3nm) process. These IP demonstrate significantly better power, performance, and area (PPA) metrics than the specifications, with a bit error rate (BER) better than 1E-27 compared to the spec of 1E-15. The power consumption is also notably lower than the spec limit, ensuring a simpler integration with a best-in-class power profile.

112G PHY IP: Pushing the Boundaries of Performance

Cadence's 112G PHY IP are designed to meet the demands of high-speed data transmission. The 112G-ULR PHY IP, characterized in the 3nm process, showcases exceptional performance with support for insertion loss over 45dB at data rates ranging from 1.25Gbps to 112.5Gbps. This IP is optimized for both power and area, making it a versatile choice for various applications. The 112G-VSR/MR PHY IP also stands out with its excellent power and performance metrics, making it ideal for short-reach applications and optical interconnects. Additionally, the 112G PAM4 PHY solutions cater to hyperscale, AI, HPC, and optics applications, featuring a mature DSP-based SerDes architecture with advanced techniques such as reflection cancellation.

Cadence's IP portfolio on TSMC N3 shows innovation and expertise to solve today's design challenges. From high-speed PHY IP to robust PCIe and CXL solutions and advanced memory IP, Cadence continues to lead the way in semiconductor IP development. These solutions not only meet but exceed industry standards, ensuring that customers can confidently achieve their design goals. Stay tuned for more updates on Cadence's groundbreaking advancements in semiconductor technology.

Learn more about Cadence IP and other silicon solutions.

LEF allows the same port with multiple shape definitions. Does anybody know if innovus can create multiple duplicate shapes associated with the same port? Assume they are connected outside the block with perfect timing synchronization. Thank you!

I am working with innovus on a huge design. I found some cells are placed far away from both timing start points and timing end points. I suspect some other timing paths may be near-critical that results in this sub-optimal cell placement; or innovus has to place the cell far away due to congestion of placement or routing.

Is there a way to see why innovus places/moves the cell during place_opt_design or ccopt_design?

Also, is there a way to highlight all timing start points or timing end points that go through a cell? There may be thousands of timing paths through this cell. I tried using report_timing and timing debugger but it is very painful to click the highlight box and highlight the timing paths one by one.

Thank you for your help!

anyone know what is "cell with Zero maximum clock transition time"  ?

not zero transition, not maximum transtion, it is zero maximum clock transition time.

it means X0 cell? (drive-strength)

can you explain? 

thanks :-)

Hi,

Is there any way to instruct the tool to reduce the low metals effort and route more on top layers? 

Hi there, 

we've encountered some strange behavior when trying to run the "check_litho" command from within INNOVUS 22.14. We set the required files and configuration files according to our PDK documentation. The command, without the absolute file paths, is:

check_litho -sign_off -cpu 96 -run_mode fg -create_guides -map_file <map file path> -config <config file path> -techfile <tech file path> -dir <output dir path> -write_stream_options "-mode ALL -merge <list of gds files>" -apply squishHints

We are currently using PEGASUSDFM 23.20 for this command but tested previous PEGASUSDFM and MVS versions as-well. After we issued the previous command, we see INNOVUS launching the PEGASUSDFM/MVS and trying to run the command. After some time, the command crashes with the error "mdb_load_with_extra: failed to pre-open extra input file './preproc/INTERMEDIATE.oas' for read". We have tested a similar setup with INNOVUS 19.10 where we did not have this issues. Did something change with the new INNOVUS version? Does anyone have an idea what we are missing? 

Thanks in advance.

Best regards,

PS

Hi everyone,

I'm designing a digital chip that will be fabricated. I have a HDL top module that includes several submodules inside it. I want to define the position of some of the submodules during the PnR so that later I can specify there positions in the Micrograph photo after the IC fabrication. When I perform the PnR using Innovus, I always got a layout shape where the submodules seems to be flatted. I wonder if there is a way to specify the placement of each submodule in my top module  (maybe in the tcl file) during the PnR so later I can define there positions in the micrograph photo. 

Thanks in Advance!

Hi everyone,

I'm new to using Innovus and I'm encountering an issue while trying to perform the "init_design" command. My goal is to perform the place and route. Here are the commands I'm using:

``
set init_verilog ./test.v
set init_top_cell TEST
set init_pwr_net {VDD VDD_2 VDD_3}
set init_gnd_net {VSS VSSA}
set init_lef_file { /home/laumecha/uw_openroad_free45/pdk/Drexel-ECEC575/Encounter/NangateOpenCellLibrary/Back_End/lef/NangateOpenCellLibrary.lef}
set init_mmmc_file {./viewDefinition.tcl}
init_design
```

However, I receive the following error:

```
#% Begin Load netlist data ... (date=06/04 12:07:50, mem=1478.7M)
*** Begin netlist parsing (mem=1439.0M) ***
Created 0 new cells from 0 timing libraries.
Reading netlist ...
Backslashed names will retain backslash and a trailing blank character.
**ERROR: (IMPVL-209):   In Verilog file './test.v', check line 16 near the text # for the issue: 'syntax error'.  Update the text accordingly.
Type 'man IMPVL-209' for more detail.
Verilog file './test.v' has errors!  See above.

*** Memory Usage v#1 (Current mem = 1439.027M, initial mem = 634.098M) ***
#% End Load netlist data ... (date=06/04 12:07:50, total cpu=0:00:00.0, real=0:00:00.0, peak res=1478.7M, current mem=1478.7M)
**ERROR: (IMPVL-902):   Failed to read netlist ./test.v. See previous error messages for details.  Resolve the issues and reload the design.
```

However, the file works perfectly in Genus.

It seems there is a syntax error in my Verilog file at line 16, but I'm not sure how to resolve it. Any guidance or suggestions would be greatly appreciated.

Thanks in advance!

I am trying to remove the cdn_loop_breaker cells from the netlist. 
When I tried the below 2 things, genus synthesis tool removing the cdn_loop_breaker cells but while connecting the cdn_loop_breaker cell input to its proper connection, its somehow misleading the connections

Things i tried:
1.  remove_cdn_loop_breaker -instances *cdn_loop_breaker*
then i just ran remove_cdn_loop_breaker  comand without the -instances switch
2. remove_cdn_loop_breaker  
     
both of the above things are not providing the proper connections after removing the loop_breaker_cells

can anyone suggest the best possible workaround for this please?

Hi all,

I have been following the tutorial "Innovus Block Implementation with Stylus Common UI", version 23.1.

While I was doing the clock tree synthesis, the tutorial calls for a command

clock_opt_design

But my tool tells me this is a beta feature which needs to be enabled.

Warning: clock_opt_design requires beta feature innovusClockOptFlow enabled.

Can I ask how do I enable this beta feature?

My version of Innovus is v21.35-s114_1, is it because of the version incompatibility?

Many thanks

We are currently setting up the Tempus flow and have ran into some mismatched data regarding ECO and timing reports. I generated a timing report before running ECO and saw six total setup violations. When running opt_signoff -setup, the initial setup summary that was printed in the shell only showed one violation. I can see that violation from the initial setup summary in my pre-ECO timing report and it is not the worst path. Upon further investigation, I forced the tool to try to fix setup on one of the other five violations from the timing report using the opt_signoff_select_setup_endpoints attribute and the tool said that the endpoint had positive slack and would be ignored.

Has anyone experienced something like this before?

Hi, I'm using genus (Version 21.14-s082_1) to synthesis a VHDL-design with multiple power-domains. After reading the power intent file and calling 'apply_power_intent',  I get the following warning:

Warning : Potential problem while applying power intent of 1801 file. [1801-99]
: Cannot find any instance for scope '/:CHIP_TOP'. Rest of commands in this scope will be skipped (set_scope:../../upf/CHIP_TOP.upf:2).
: Check the power intent. If the scenario is expected, this message can be ignored.

The fist two lines of CHIP_TOP.upf:

upf_version 3.1
set_scope :CHIP_TOP

I simulated the same  UPF and VHDL files with Xeclium and was able to verify all the IEEE1801/UPF aspects I need without any problems. I don't know, why genus is having a problem with the 'scope'.
In genus, after getting the warning, running 'set_db power_domain:CHIP_TOP/BLOCK_A/PD_CORE_D .library_domain PD0V5' returns the following error:

Error : <Start> word is not recognized. [TUI-182] [set_db]
: 'power_domain:CHIP_TOP/BLOCK/PD_CORE_D' is not a recognized object/attribute. Type 'help root:' to get a list of all supported objects and attributes.
: Check if the given <Start> word is a valid object_type, object or attribute.

Running 'commit_power_intent' gives me:

Started inserting low power cells...
====================================
Info : Command 'commit_power_intent' cannot proceed as there are no power domains present. [CPI-507]
: Design with no power domains is 'design:CHIP_TOP'.
Completed inserting low power cells (runtime 0.00).
====================================================

I'm suspecting that the problem lies in 'set_scope' and VHDL. I never had such problems with Verilog. I tried every way to reference the hierarchy in the code and now I'm at my wit's end and I need your help o/
How to set the scope with 'set_scope' in UPD 3.1 to the toplevel in VHDL, so that genus accepts it? Or is the problem caused by something else?

Best,

Iqbal

Hi all,

I have off grid violations on M2 layer. I have tried ecoRoute -fix_drc and deleting violations and rerouting. But the tool is still placing these routes off grid. The on grid option in nanoroute is turned on. Since there is a fat metal closer to these routes, the tool is honouring the drc and not placing the metals on track. How do I ignore drc while routing? Also if there is any other way I can fix it, please let me know 

Hi all, while saving design, there is an error saying a net has tid problem. However the design is saved. Does anybody know how to resolve the Tid problem?

I am getting the cut_spacing violation in the power plan, my design has two power rails, and the via is not formed for two rails, only one rail getting via, I used edit power via and modified the cut_space violation.

how to solve this problem.

I have a standard cell library containing LEF, GDS, and spice models but no OA views. I'm unable to import these files into Virtuoso without a LayerMap file. How can I obtain or generate this required LayerMap file?

Hi all,

I'm trying to model the clock of a clock doubler. The doubler consists of a delay cell and an XOR gate, which generates a pulse on both the rising and falling edge of the input clock. I've created a simple module to evaluate this. In this case, DEL1 and XOR2 are standard library cells. There is a don_touch constraint on both library cells as well as on clk_d.

module top (
input wire clk,
output reg Q);

//Doubler
wire clk_d;
wire clk_2x;
DEL1 u_delay (.I(clk),.Z(clk_d));
XOR2 u_xor (.A1(clk),.A2(clk_d),.Z(clk_2x));

//FF for connecting the clock to some leaf:
always @(posedge clk_2x) Q<=~Q;

endmodule

My SDC looks like this:

create_clock [get_ports {clk}] -name clk_i -period 100
set_clock_latency -rise 0.1 [get_pins u_xor/Z]
set_clock_latency -fall 0.4 [get_pins u_xor/Z]
create_generated_clock -name clk_2x -edges {1 1 2 2 3} -source clk [get_pins u_xor/Z]

The generated clock is correctly generated but the pulse width is zero. I would be expecting that the pulse width is the difference between fall and rise latency but is not applied:

report_clocks:

report_clocks -generated:

clk_2x is disconnected from the FF after syn_generic. What can I do to model some minimum pulse width? Will innovus later on model this correctly with the delay of DEL1?

With digital implementation rapidly advancing, how do you think iOS and Android platforms will continue to evolve in industries like healthcare or education? The integration of mobile technology is already revolutionizing these fields, and it would be interesting to discuss where this could lead and what new opportunities might emerge.

for debug I use suspend in my tcl script to debug，here is the code

after that the innovus command screen become 

how to quit the SUSPEND status？ thanks

Hi all, 

I have made a custom cell in Innovus that I will be instantiating into a bigger block, which I will also be using Innovus to do the Place & Route. 

I understand that I can generate a *.lef file and a *.lib file using Innovus. However, I need to also create a *.db file (these format of files are often used in DC Compiler synthesis tool). 

Is there a way to create the *.db file from Innovus? Or, is there a tool that I can use to create this *.db file? 

Thank you for your time. 

I'm trying to write a generic piece of code that will return the layermap file location, with file name, for a variety of projects (which could potential have different layermap file naming conventions. The below code is what I've used to date, but this assumes the file name is xxxx.layermap. I can obviously do some string matching to find it, assuming the various files all contain some common characters. I thought I'd ask if there is a simpler way to find it, I know that this information is automatically loaded into the Xstream out gui, so maybe I can use the same approach to find it.

techLibName=techGetTechFile(cv)~>libName

techLibLayerMap=strcat(ddGetObj(techLibName)~>readPath "/" techLibName ".layermap")

Hi everyone. 

I'm very a new cadence user. I'm not good at using it and quite lost in finding a way to get the results. With the topic, I would like to ask you for some suggestions to improve my cadence skills.

I have some digital decision logic. Some are combinational logic, some are sequential logic that I would like to import or generate random input combination to the inputs of my decision logic to get the maximum, minimum, and average delay power dissipation and area when feeding the different input combination.

My logic has 8-bit, 16-bit, and 32-bit input. The imported data tends to be decimal numbers.

I would like to ask you:

- which tool(s) are the most appropriate to import and feed the different combination to my decision logic?

- which tool is the most appropriate to synthesis with different number of input? - I have used Genus Synthesis Solution so far. However with my skill right now I can only let Genus synthesize my Verilog code one setup at a time. I'm not sure if I there is anyway I can feed a lot of input at a time and get those results (min, max, average of delay, power dissipation and area)

- which language or scripts I should pick up to use and achieve these results?

-where can I find information to solve my problem? which information shall I look for?

Thank you so much for your time!!

Best Regards

IR criteria:

Static IR (STD) ~2%

Static IR (MEM) ~1%

Dynamic IR (STD) ~10%

Dynamic IR (MEM) ~5%

Anyone knows the reason behind this criteria? >.<

I have a 2-dimensional input in my design - input [2:0] data_in [15:0]. After synthesis with genus, I got a netlist where the inputs are like data[15], data[14],...,data[0]. And furthermore it has definitions like input [2:0] data[15], .... So how can I define the pin locations of each of the bits for this input? Can I define data[15]'s inner bits like data[15][0]? Is it possible to define this with def files?

Hello All,

How do we control the Always on buffering for a power domain called B in Power domain A.

here B-power domain nets going through A , hence tool is inserting Always on buffers.

How do we avoid this specific power domain ?

Thanks,
Bshaik

Hi! I've made some 1-point waveform "markers" that I want to overlay in my plots to aid visualization (with the added advantage, w.r.t. normal Viva markers, that they update location automatically upon refreshing simulation data).

For example, the plot below shows an spectrum along with two of these markers, which I create with the function "singlePointWave", and the Assembler output definitions also as shown below.

The problem is: as currently created and defined, Assembler is unable to plot these elements. I can send their expressions to the calculator and plotting works from there, BUT ONLY after first enabling the "Allow Any Units" in the target Viva subwindow.

Thus, I suspect Assembler is failing to plot my markers because they "lack" other information like axes units and so on. How could I add whatever is missing, so that these markers can plot automatically from Assembler?

Thanks in advance for any help!

Jorge.

P.S. I also don't know why, but nothing works without those "ymax()" in the output definitions--I suspect they are somehow converting the arguments to the right data type expected by singlePointWave(). Ideas how to fix that are also welcome! ^^

procedure( singlePointWave(xVal yVal)
    let( (xVect yVect wave)
        xVect = drCreateVec('double list(xVal));
        yVect = drCreateVec('double list(yVal));
        wave = drCreateWaveform(xVect yVect);
    );
);

I am trying to install IC231 on RHEL 8 using installscape, however configuring keeps failing.

I tried to run the configuration file manually as suggested in one of the previous posts and it gives me following errors:

sh batch_configure.sh
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: ncvhdl23.03-d103lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'ncvhdl23.03-d103lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: ncvhdl64b23.03-d103lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'ncvhdl64b23.03-d103lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: oaRedist22.61-p003lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'oaRedist22.61-p003lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: amsEnv64b23.10-p043lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'amsEnv64b23.10-p043lnx86_101124125631.stat': No such file or directory
/home/rs/cadence/installs/IC231/install/tmp/slconfig.sh: line 165: xterm: command not found
cat: ihdl64b23.10-p043lnx86_101124125631.stat: No such file or directory
rm: cannot remove 'ihdl64b23.10-p043lnx86_101124125631.stat': No such file or directory

I am not very well versed with Linux at the moment but trying. Could any one suggest something or point to what is missing?

Hi! 

I am attempting to create a very simple test pcell that contains a single Nmos 4 terminal device (Gate, Source, Drain, Backgate). However, unlike other devices I have used in the past, the backgate terminal of the device I wish to include within the pcell is an inherited connection, and the other 3 are physical terminals. Note that for the pcell master, I do not want any inherited connections, just physical pins. Hence I need to drive this inherited connection with a pin within my pcell. I started implementing the symbol and schematic first, ensuring I could obtain the correct connectivity, extract netlist, etc. I thought I had it hooked up correctly, but alas I am failing to export the CDL. Let me explain my current approach.

Schematic:

Create the 4 physical pins using a combination of dbCreateInst (for the pin isnt), dbMakeNet, dbCreateTerm and dbCreatePin.

Create the device instance using dbCreateInstByMasterName and setting the desired cdf parameters + callbacks.

For the physical terminals of the device, I'm using dbCreateConnByName to make the connection to the appropriate net that was created above.

For the inherited connection, I am creating a netSet property like so: dbCreateProp(newinst deviceTermName "netSet" netName)

Symbol:

Create the 4 physical pins using a combination of dbCreateRect, dbMakeNet, dbCreateTerm, dbCreatePin.

And then create whatever symbol design I wish using the likes of dbCreateRect, dbCreateLine, etc. 

Everything works fine when using a device without an inherited connection, so I'm guessing I'm missing something along this line... Also, if I copy the contents of the pcell schematic to a regular schematic view, do a check and save, the view extracts just fine. So I wonder if the check and save it fixing the connectivity that I may not have. 

Thanks for any possibly engagement or suggestions 🙂

Keelan

Hi,

I am looking to perform a net trace in a CDL file.

There is a net at a lower level and would like to know the net it is connected to at the top level.

Please let me know if there is a way to analyze the CDL file to perform this net trace.

Thanks,

Mallikarjun.

I want to create sub tree of sub trees how can i do that?

I want to create another tree for the Sub parameter also.

I'm trying to do what I believe should be a very simple and straightforward thing but after much reading appears to be quite complicated.

I'm test-benching the digital portion of a mixed-signal circuit that's instantiated a few hundred times. Each instance has some digital controls, and an analog portion. To greatly speed up the simulation, I'd like to hide the analog portion, which is neatly contained in one or two cell views deep down the hierarchy, and then unhide it after simulation has ended so it doesn't mess up other peoples' sims

Just as an example, say there's an op-amp that from the top level is contained in instance "I<0:511>/I3/I15/I0". First off, I don't know how to iterate through the 512 instantiations of the top level cell, but let's say we're just working with the I0 instance. I thought it would just be

schIgnore(?objectId "I<0:511>/I3/I15/I0" ?setIgnore t)

Of course this doesn't work. I can get the top level cell dbId with

cv = dbOpenCellViewByType("library" "cell" "schematic" "" "a")

And then I can grab the instance ID with

inst = dbFindAnyInstByName(cv "I0")

This gives me something, but then I'm lost from here. If I use the ~>master to get an Id from inst, I cannot recursively use dbFindAnyInstByName to traverse down the hierarchy. Also the value this returned seems to be meaningless, it can't be used by the schIgnore command. I'm not sure what the schIgnore command is actually even looking for.

So I guess I'm trying to loop through two things, one is to traverse down the hierarchy and grab the ID of a child instance so I can schIgnore it, and another is to iterate through all the top level instances to hide the child instance within each of them.

Is there a skill command for "Assign Layout Instance terminals", this form appears when i click on define device correspondence and Bind the devices.

Also,

Problem Statement : i have a schematic with a couple of transistor symbols and and i alos have a corresponding layout view with respective layout transistors but they all are inside a pCell(created by me) i.e layout transistor called inside a custom Pcell. Now i have multiple symbols in schematic view and a single instance(pCell) in layout view. 
Is there a way how i can bind these schematic symbols with layout symbols inside the pCell(custom)? Even if i have to use cph commands i'm fine with it. need help here.

The idea here is to establish XL connectivity between the schematic symbols and corresponding layout transistors(inside the pCell).

Thanks,

Shankar

Hello Community,

Is there any simple way how i can get the coordinates of all the shapes in a layout view?

Currently i'm flattening the layout, getting all the lpps from CV and using setof to get all the shapes of a layer and looping through them to get the coordinates.

Is there a way to do it without having to flatten the layout view and shapes merged or any other elegant way to do it if we flatten it?

Also, dbWriteSkill doesn't give output how i desired

Thanks,

Shankar

Hi,

I hope you are doing well.

I have designed and simulated a PA system in Cadence using high-level blocks, which include both ideal components and some defined with Verilog-A. My goal is to calculate the Bit Error Rate (BER) and Error Vector Magnitude (EVM) in the system. I am using an LTE source from RFLib, and everything functions correctly in the transient simulation.

To calculate these parameters, I intended to use envelope simulation. However, when I attempt to run the envelope simulation, I encounter convergence errors, which prevent it from working as expected.

Given this issue, I believe I need to work with transient data instead. Could you please advise on how to approach this in Cadence without exporting the data to MATLAB?

Thank you for your assistance.

What is the variable to define via selection/type for vias

I want to be able to load via cut type in the via option when I use the leHiCreateVia() function

I want to select/load to the Via Option menu on which via I want to use

Cadence version IC23.1.64b.ISR7.27

Paul

Hi to all,

I am trying to write an SKILL code to create a schematic. In my code I use "instTerms" to obtain the terminals of an instantiated cell (Let's imagine it is a simple NMOS which is given as a predesigned cell), and then I will connect a wire to each of the terminals. When I run the whole code by command line, the returned terminals by "instTerms" are empty(nil) but when I try to debug it line by line it works properly. As more information, I call it for the instantiated cell, and I should say the cell is instantiated without any problem. This is just the problem of finding its terminals. 

Does anybody have any idea?

Thank you very much in advance.

Amir

I am attempting to use dbGetNeighbor() function inside the dynamic display HUD so that the distance to the next metal on that layer could be viewed. Think of another line in this dynamic table here... 

My SKILL code is essentially the following:

procedure(getNearestNeighborOnMetal(cv)
let((direction tmpBoundingBox)
direction = internal_function()
tmpBoundingBox = dbCreateRect(geGetEditCellView() "tmp" list(hiGetCommandPoint() hiGetCommandPoint()))
car(dbGetNeighbor(geGetEditCellView() tmpBoundingBox direction))
)
)

this returns the distance to the closest metal based on some tests.

Next, I try to register this function to work in the Dynamic Display / Info Balloon world by executing odcRegisterCustomFunc() for each and every object type (I know, absurd, but trying to debug)

In the dynamic display menu, I toggle the "Custom SKILL Function" check in layoutXL, then hit apply, then OK.

After this I find I am unable to view the changes reflected in any info balloons or in the drawing HUD (above) for this wire. I have tried replacing my function with the sample "customFunc" from the odcRegisterCustomFunc() documentation and was still unable to produce any new output.

Any help diagnosing the use of this feature would be very much appreciated

Hello,

When I draw a Fluid Guard Ring in Virtuoso, the layout is not visible, and instead, "do_something=nil" appears.

When I check the details with Q, it shows the same information as a regular NFGR guard ring, and Ctrl+F also displays the instance name, just like with a regular NFGR. 

Additionally, the Pcells of Fluid Guard Rings from previous projects appear broken. 

The version I’m currently using is not different from the one used in the past. Even when I access the same version as the one used during the project, the Pcells still appear broken.

These two issues are occurring, and I’m not sure what to check. I would greatly appreciate it if you could assist me in resolving this issue.

//