Chetan Fegade

AHB, APB, AXI and ACE are well known AMBA protocols. But ATB (Advance Trace Bus) is also used in hardware verification especially for blocks like Debug Systems in a SOC. ATB is used to transfer debug and trace information from different blocks of SOC to a trace sink and it does this with the help of a Master (generates trace data) and Slave (receives trace data) However there are number of features that ATB supports which can be used for debugging: [1] ATB supports multiple data widths and error detection and correction mechanism to check data integrity. [2] Data Stalling (Master can send data but slave is unable to receive because it's busy handling other transaction) can be achieved with the help of valid and data reponses. Due to this more efficient data transfer occurred in the bus. [3] ATB supports multi master, multi slave configuration with the help of a shared bus. [4] ATB supports both synchronous and asynchronous data transfer and can be easily plugged in the existing designs supporting AXI or AHB interface. [5] ATB supports trace coresight and capture analysis which are useful in debugging and optimisation. This can be done with the components within ATB which are: Embedded Trace Buffer(ETB): On chip storage device which are useful tracing data. Embedded Trace Macrocell (ETM): Contains data trace information. [6] ATB supports features like timestamping and can be used to output the data through JTAG for debug analysis. [7] ATB supports flushing mechanism to discard all the data from the pipeline and thus avoiding any stale data. [8] ATB supports data compression reducing the amount of trace data transmitted and hence conserving the bandwidth. [9] ATB supports selective trace capture and hence helps in reducing the amount of data transmitted. [10] ATB supports buffering with rate matching control to operate at different speeds so that no data are lost. [11] ATB supports different data formats like: Single transfer Burst transfer Streaming transfer Split transfer Pipelined transfer #vlsi #asic #semiconductorindustry #electricalengineering

86

2 Comments

Why people should not get stuck in the CPU/GPU world. All protocols are well relevant in the networking world as well. Don’t be afraid to enter our World. Recently I was having a conversation with my Industry colleague about an exciting Networking Chip I was working on. I persuaded him to take up a project for this Particular Customer. He immediately denied the offer. Saying that He currently works on L2 Cache for an Advanced Graphic Chip. Transmitter and Receiver blocks are present in GPUs. I was kind of mesmerized by the type of protocols he was explaining like Serdes/PCIe/Ethernet/GPIO etc. Infrastructure companies usually use "Smart Pigeons" to send a message from Transmitter to Receiver and the Pigeons inside the Chip can automatically encrypt and decrypt the messages for the end user. Jokes apart. For Storing Large On-chip Cache Memory we use Huge Dolphins to store the memory tables and other Stuff. 😂 Ultimately What i wanted to say is, in case you work in a GPU company your next destination doesn't need to be another GPU company. Most of the protocols are common across CPU/GPU/NPU/Automotive Chips. Working on different types of applications and different kinds of people can enhance your success in the VLSI Industry. #oldpost #vlsi #skill#building#humour

144

2 Comments

Silicon Saturdays #3 – Reuse or Overload? Verification reuse—from IP to subsystem to SoC—always looks good on paper. But before jumping in, the real question is: why? SoC simulations are expensive. They consume time, compute, and people. Reusing everything blindly often adds overhead instead of reducing it. And let’s be honest—phrases like “trust but verify” don’t make it any smarter. A good engineer knows reuse should lighten the load, not add to it. Imagine a runner chasing a personal record while carrying a heavy backpack—every extra pound slows them down. That’s what happens when we drag unnecessary checks and flows forward. The lesson: reuse is powerful only when it’s purposeful. Start with why, be selective, and cut the carrying cost. That’s how we run faster and still cross the finish line strong. #SiliconSaturdays #SoC #Verification #Engineering

95

3 Comments

AHB, APB, AXI and ACE are well known AMBA protocols. But ATB (Advance Trace Bus) is also used in hardware verification especially for blocks like Debug Systems in a SOC. ATB is used to transfer debug and trace information from different blocks of SOC to a trace sink and it does this with the help of a Master (generates trace data) and Slave (receives trace data) However there are number of features that ATB supports which can be used for debugging: [1] ATB supports multiple data widths and error detection and correction mechanism to check data integrity. [2] Data Stalling (Master can send data but slave is unable to receive because it's busy handling other transaction) can be achieved with the help of valid and data reponses. Due to this more efficient data transfer occurred in the bus. [3] ATB supports multi master, multi slave configuration with the help of a shared bus. [4] ATB supports both synchronous and asynchronous data transfer and can be easily plugged in the existing designs supporting AXI or AHB interface. [5] ATB supports trace coresight and capture analysis which are useful in debugging and optimisation. This can be done with the components within ATB which are: Embedded Trace Buffer(ETB): On chip storage device which are useful tracing data. Embedded Trace Macrocell (ETM): Contains data trace information. [6] ATB supports features like timestamping and can be used to output the data through JTAG for debug analysis. [7] ATB supports flushing mechanism to discard all the data from the pipeline and thus avoiding any stale data. [8] ATB supports data compression reducing the amount of trace data transmitted and hence conserving the bandwidth. [9] ATB supports selective trace capture and hence helps in reducing the amount of data transmitted. [10] ATB supports buffering with rate matching control to operate at different speeds so that no data are lost. [11] ATB supports different data formats like: Single transfer Burst transfer Streaming transfer Split transfer Pipelined transfer A simple driver logic of ATB is below: seq_item_port.get_next_item(atb_trx); atb_trx.atbytes = atb_trx.atdata.size() - 1; atb_trx.atvalid = 1'b1; if (atb_trx.randomize) begin atb_trx.atready == 1'b1; end seq_item_port.item_done(); #vlsi #asic #electricalengineering

57

1 Comment

GPU scheduling threads across multiple cores: A GPU schedules threads across multiple cores using a SIMT (Single Instruction, Multiple Threads) execution model, where thousands of threads are grouped into warps and executed in parallel on Streaming Multiprocessors (SMs). 📈 GPU Thread Hierarchy Grid → Blocks → Warps → Threads Grid: A collection of thread blocks. Thread Block: A group of threads that execute together on the same SM. Warp: A fixed group of 32 threads (on NVIDIA GPUs). Threads: The smallest execution units inside warps. 🤔 How GPU Schedules Threads? 1️⃣ Warp-Based Scheduling Threads are executed in groups of 32 (warp size = 32 in NVIDIA GPUs). A warp scheduler assigns warps to Streaming Multiprocessors (SMs). Each SM has multiple CUDA cores, capable of executing multiple warps in parallel. Example (NVIDIA RTX 4090) 128 SMs, each with 128 CUDA cores. Can handle tens of thousands of threads at once. 2️⃣ Occupancy & Multi-Warp Scheduling Each SM can hold multiple warps in-flight to hide latency. If one warp is waiting (e.g., memory fetch), another warp immediately executes. Higher occupancy (more active warps per SM) → better utilization. ✅ How GPU Schedules Across Multiple Cores? 1️⃣ Kernel launch with a grid of threads 2️⃣ Blocks assigned to Streaming Multiprocessors (SMs) 3️⃣ Each SM assigns warps (32 threads) to CUDA cores 4️⃣ Warps are scheduled in round-robin or dynamic scheduling 5️⃣ If a warp is stalled (e.g., waiting for memory), another warp is executed immediately 6️⃣ Execution continues until all warps finish processing #gpu #cuda #systemdesign #kernel #embedded #learning

258

1 Comment

Not everyone owns expensive GPUs, but decoding-heavy LLM inference (chat and long-form reasoning) often hits GPU memory limits as the KV cache grows. Our APEX system is a profiling-informed scheduler that dynamically splits inference work between the CPU and GPU. It maximizes overlap during decoding, making hybrid inference more efficient on memory-constrained, low-cost GPUs. APEX enables practical deployments without expensive accelerators. Fantastic work by Jiakun Fan and Xiangchen Li of our PEARL - Performance Engineering for Emerging Architectures Laboratory. The paper will appear at the flagship 40th IEEE IPDPS (International Parallel and Distributed Processing Symposium) in iconic New Orleans! https://lnkd.in/eCKzb_n3 #VTCS #KVCache #LowCostAI #SustainableAI #EdgeAI #IPDPS

227

�� RTL Partitioning – Why Control Path Stays Hardcoded When partitioning RTL into Config, Control, and Data paths, we often preach scalability through parameterization. But here’s a counterintuitive truth: 👉 Control path is rarely parameterized. And that’s not bad practice — it’s deliberate design. 🧠 Let’s decode why: Debug Simplicity Wins A reg [1:0] is easier to trace than reg [(WIDTH*2)-1:0]. In Control logic, human readability often trumps abstraction. Control Evolves, Data Doesn’t While data paths (algorithms, packets) are fixed early and highly reusable, control logic (FSMs, IRQs, masks) changes frequently — sometimes up to tapeout. Time-to-Signoff Pressure Parameterized control adds debug friction. Teams favor hardcoded control to ensure faster closure on LEC, CDC, and simulations. Security & Compatibility Control tweaks may mask features for SW compatibility or silicon security. Parameterization here can risk exposing unintended behavior. 🔍 RTL Partitioning Heuristic: Config Path → SFRs, APB/AHB reg maps Control Path → FSMs, IRQs, bandwidth throttles Data Path → Processing logic, FIFO paths, algo pipes And while Data Paths are parameterized for reuse… Control Paths are fixed to stay flexible. 💡 Smart designers don’t over-engineer what needs to change. They make room for evolution — RTL partition with intent. 💬 Not sure how this connects to your work? Book a free 1:1 call and let’s discuss your exact RTL design situation: 👉 https://lnkd.in/gVs3JkQb 📣 Want deeper clarity on real-world RTL roles? I’m conducting a live webinar where we decode: 🔹 What your manager actually expects 🔹 Why tools and flows dominate early careers 🔹 How to align with industry reality and stand out 👉 Join here (100% proceeds go to charity): https://lnkd.in/g5DYhhNw #ASICDecoded #RTLDesign #RTLPartitioning #SoC #VLSI #Semiconductor #CareerClarity #FPGA #DesignMindset #TapeoutTales

31

6 Comments

𝐆𝐨𝐨𝐠𝐥𝐞 𝐭𝐨 𝐈𝐧𝐯𝐞𝐬𝐭 $𝟏𝟓 𝐁𝐧 𝐢𝐧 𝐀𝐈 𝐃𝐚𝐭𝐚 𝐂𝐞𝐧𝐭𝐫𝐞 𝐢𝐧 𝐕𝐢𝐳𝐚𝐠 Google Cloud CEO Thomas Kurian announced that the tech giant will invest $15 billion to build the world’s largest AI and data centre in Visakhapatnam, Andhra Pradesh. This hub will be Google’s biggest AI facility outside the US and will feature Tensor Processing Units (TPUs) for cutting-edge AI computing. “This gigawatt-scale AI hub represents a major step in supporting India’s digital infrastructure goals, and we’re grateful for the support of the Government of India and the state of Andhra Pradesh,” said Kurian. Google Cloud CEO Kurian made this announcement during Google’s event on “India’s AI-Powered Future and Advancing the Vision of Viksit Bharat 2047,” in the presence of Ashwini Vaishnaw, Minister of Electronics & IT; Nirmala Sitharaman, Finance Minister; and N. Chandrababu Naidu, Chief Minister of Andhra Pradesh. Google Cloud Thomas Kurian Ministry of Electronics and Information Technology Via: Outlook Business | Deepsekhar Choudhury (Story link in the comment)

21

1 Comment

Sachin Katti has been elevated to Chief Technology Officer and Head of AI at Intel Corporation, bringing decades of experience across Intel, Stanford University, Uhana, and Kumu Networks. In his new role, he will lead Intel’s AI roadmap, research, and product innovation through Intel Labs while enhancing collaboration with startups and developers. His elevation signals a major strategic shift in Intel’s efforts to unify and accelerate its AI agenda. Katti previously served as SVP & GM of Intel’s Network and Edge Group and earlier as CTO of the same division. He has also been a professor at Stanford University for over 15 years and co-founded both Uhana and Kumu Networks, where he led breakthroughs in wireless technology and network systems. With this leadership change, Intel is strengthening its focus on AI-driven innovation and integrated technical leadership. #IntelCorporation #SachinKatti #ArtificialIntelligence #AILeadership #TechInnovation #StanfordUniversity #KumuNetworks #Uhana #IntelLabs #CTO #NetworkAndEdge #AITransformation

372

76 Comments

Here are 5 companies in Hyderabad working in or adjacent to the semiconductor / wireless-connectivity / IoT domain (so you get a mix of large + niche), with a short summary of each: --- 1. Silicon Labs India Pvt. Ltd. (Hyderabad centre) US‐based company focused on wireless/IoT connectivity; in Hyderabad they opened a large engineering centre for “hardware and software platforms, wireless connectivity innovation”. Location: HITEC City / Knowledge City of Hyderabad. Why relevant: If you’re interested in wireless chip/IoT/embedded hardware work, this is very directly in that space. Tip: Monitor their “Wireless development centre” in Hyderabad for openings in analog/hardware/software embedded roles. --- 2. Omni Design Technologies (Hyderabad design centre) They opened a new design centre in Hyderabad focussing on high-performance low-power analog/mixed-signal IP (ADC, DAC, analog front ends) for applications including wireless, automotive, IoT. Why relevant: This is a more niche chip/IP design company (not full large‐chip manufacturing) but very much in the “semiconductor design services/IP” space. Tip: A good target if your interest lies in analog/mixed-signal design or IP work rather than full system‐on‐chip. --- 3. MosChip Technologies Ltd. Based in Hyderabad, this company is described as a semiconductor & embedded product design services + IoT solutions company (ASICs, IP, etc). They have been active for 18+ years in this domain. Why relevant: A local Hyderabad company deeply in the chip/IoT space; may represent different types of roles (ASIC design, system‐level, firmware, IoT solutions). Tip: Look for roles in ASIC design, mixed‐signal design, system bring-up or IoT product development. --- 4. Cyient Ltd. Hyderabad‐based engineering & technology solutions company; they have engaged in chip design work such as developing India’s first NB-IoT SoC with WiSig Networks and Indian Institute of Technology Hyderabad (IIT-H). Why relevant: Although broader than pure semiconductor, they have a footprint in chip design/ASIC and IoT connectivity work. Tip: If you’re flexible between electronics/hardware/firmware, this could be a strong option. --- 5. WiSig Networks Private Limited Startup/incubator at IIT-Hyderabad working on wireless SoCs (NB-IoT, 5G, etc). For example they launched an indigenously designed wireless SoC in 2024 for IoT/5G/ISAC applications. Why relevant: If you prefer startup/innovation environment and are interested in cutting‐edge wireless/IoT chip work with smaller teams. Tip: The roles might be more dynamic/multi‐discipline and require versatility; and startups may provide broader exposure.

6

The future of SoC verification is here... Calibre's 2nd-gen Verilog-to-LVS achieves up to 4X faster translation and 92% less memory use for SoC signoff. Get a look at the architecture powering advanced verification results in this paper available here

36

2 Comments

*** Interconnect Challenge in Chiplet-Based SoCs *** A well-designed Chiplet-Based SoC isn’t just about partitioning logic across multiple dies—it’s about how those dies communicate. Die-to-Die (D2D) interfaces such as UCIe, BoW, AIB, AMD Infinity Fabric, Intel EMIB, TSMC CoWoS—all these approaches tackle the same fundamental question: 👉 How do we maintain High bandwidth, Low latency, and Low power across chiplet boundaries? Unlike monolithic SoCs, where interconnects are internal, chiplet architectures require: o Standardized interfaces to mix and match chiplets from different vendors. o Efficient serialization to avoid unnecessary power consumption. o Latency-aware partitioning to ensure real-time workloads don’t suffer. The move to chiplets is a paradigm shift in interconnect design. The challenge is making it seamless. For those working with multi-die architectures, what’s been the hardest part of optimizing inter-chiplet communication?

67

2 Comments