raul ruiz

When you done RTL design so you can close 100 tabs in web browser... Because let’s be honest: FPGA design is never just about writing Verilog or VHDL. It’s also about: - Digging through IP documentation - Reading standards and reference manuals - Debugging strange forum posts from 2008 (is anybody there??) - Comparing synthesis vs. simulation quirks - Hunting down that one constraint example that makes timing finally close Closing those tabs feels almost like tapping out a chip: ✅ Clean desk ✅ Clean browser ✅ Clean mind Of course, the cycle starts again with the next design, and the tabs pile back up. But that’s part of the fun, isn’t it? 😉 What about you? How many tabs do you usually need open to get through an FPGA project? Share your number in the comments!

155

20 comentarios

To optimize the layout of an FPGA through semi-custom design flow, the quality of RTL and Gate-level netlists matters. Well-structured netlist can open many opportunities to optimize P.P.A. in physical design flow. Nowadays, the netlist generator of OpenFPGA is not a simple conversion on the FPGA architecture modeling to netlists. It actually carries netlist restructuring functionalities! Try the option ``--group_config_block`` when running command ``build_fabric``! It can group all the configuration memories, which were scattered around a tile, into a unified block. This can efficiently compress the area of configuration memory, and avoid large buffers to be inserted due to hold time violation during physical design. If used in a proper way, you may reduce the area by 11%! Refer to Ganesh Gore's paper for details! OpenFPGA Github: https://lnkd.in/gFnjFJuk OpenFPGA Documentation: https://lnkd.in/gP5cS4AC Ganesh's paper: https://lnkd.in/gZP3-bah

110

3 comentarios

EMIR Checks in VLSI : As process nodes scale to 7nm, 5nm, and beyond, power delivery challenges become critical. EMIR (Electro-Migration & IR drop) analysis isn’t just a signoff formality—it’s the difference between reliable silicon and expensive respins. 🔹 IR Drop Static IR drop: Caused by average current → impacts DC voltage levels, reducing noise margin. Dynamic IR drop: Caused by instantaneous switching activity → leads to timing failures & setup/hold violations. 🔹 Electro-Migration (EM) High current density displaces metal atoms. Leads to void formation (open circuits) or hillocks (shorts). Reliability degradation follows Black’s Equation → failure rate ~ J^n * exp(-Ea/kT), where J is current density. 🔹 Why EMIR Checks Matter ✅ Ensure power integrity across standard cells & macros ✅ Capture voltage droop under realistic switching scenarios ✅ Validate reliability margins of interconnects & vias ✅ Provide lifetime projections for SoCs under actual workloads 🔹 Best Practices Use vector-based dynamic analysis for realistic IR stress conditions. Perform early in-design EMIR closure (not just signoff). Apply localized decap insertion & grid reinforcement where droop hotspots appear. Correlate RTL activity → gate-level simulation → signoff IR analysis for accuracy. With billion-transistor SoCs, EMIR is no longer just a backend task—it’s a design co-pilot. #VLSI #SoC #Semiconductors #ChipDesign #Reliability #EMIR

64

🚀 Zephyr RTOS 4.1 is here – and with it, experimental Rust integration! Ever wondered how smart devices around you where running? Many of them have limited processing power, memory, and energy resources, making full-fledged operating systems like Windows or Linux impractical. Instead, they rely on Real-Time Operating Systems (RTOS) to efficiently manage tasks with strict timing constraints. Zephyr RTOS is one of them. Zephyr RTOS has always been a solid choice for embedded systems at Futurewave, and the addition of Rust support is an exciting step forward. The safety, memory management, and concurrency model of Rust make it an excellent fit for embedded development. But what excites me the most? The async/await model. Event-driven embedded systems often deal with complex state management and concurrency issues. Rust’s async model could be a game-changer here, reducing complexity while improving efficiency and reliability. That said, is Rust ready for full embedded applications? Not for me — yet. While Rust brings undeniable benefits, a hybrid approach with C/C++ still feels like the most practical solution. Leveraging Rust where it shines (e.g., memory safety, async handling) while keeping other parts in C/C++ seems like the best way forward at the moment. #ZephyrRTOS #RustLang #EmbeddedSystems #AsyncProgramming #RTOS

135

1 comentario

What is difference between ASIC and FPGA: Analogy and Applications 🧠 Simple Analogy Think of: FPGA as a LEGO set: You can rearrange the blocks any way you like, multiple times, to build different things. ASIC as a 3D-printed model: It's custom-made for one specific purpose, perfectly optimized, but you can't change it afterward. ⚙️ Key Differences FPGAs (Field-Programmable Gate Arrays) are semiconductor devices that can be programmed and reprogrammed even after manufacturing. They are like LEGO blocks—you can build whatever structure you want, and if your needs change, you can rearrange the blocks. This flexibility makes FPGAs ideal for prototyping, experimentation, or applications that require regular updates, such as defense systems, industrial controllers, and early-stage product development. On the other hand, ASICs (Application-Specific Integrated Circuits) are like a 3D-printed machine—custom-made for a specific task, perfectly optimized for performance, power consumption, and space. Once designed and fabricated, an ASIC cannot be modified. This makes ASICs the go-to choice for high-volume products like smartphone processors, AI accelerators, and networking chips, where speed, efficiency, and compactness matter more than flexibility. 📦 Applications FPGA Applications Prototyping of digital logic before ASIC manufacturing Aerospace & defense systems (where flexibility is crucial) Low-volume custom hardware Industrial automation and robotics Real-time video/image processing (customized pipelines) ASIC Applications Smartphones (SoCs like Apple A-series, Qualcomm Snapdragon) GPUs and AI accelerators (e.g., Google TPU, NVIDIA chips) Networking chips (e.g., routers, switches) Automotive safety systems (ADAS) Consumer electronics with mass production 🧩 Use Case Decision Use FPGA if: you need rapid prototyping, hardware flexibility, or deal with changing requirements. Use ASIC if: you need performance efficiency, lower power, and high-volume production. For all semiconductor and AI related content, follow TechoVedas If you are looking to invest in semiconductors and need expert advice, drop us a DM.

261

11 comentarios

A sense amplifier (SA) is one of the most critical circuits in memory design (like SRAM, DRAM, and Flash). Its main job is to detect and amplify small voltage or current differences that represent stored data (0 or 1) in memory cells — and convert them into full logic-level signals. ⸻ 1. What is a Sense Amplifier? A sense amplifier is a high-gain, low-offset comparator circuit that reads the small signal from the memory bitline and amplifies it to a valid logic level. • In memory arrays (SRAM, DRAM, Flash), each cell is tiny and can only drive a very small voltage difference (tens of millivolts) on long bitlines with large capacitance. • The sense amplifier detects which bitline (BL or BLB) is slightly higher and amplifies that difference to full rail voltage (0 or VDD). ⸻ 2. How It Works (Simplified Example for SRAM): • Each cell is connected to bitline pair (BL, BLB). • When a wordline is selected, a cell connects to these bitlines. • The voltage difference between BL and BLB may be only ~50–100 mV. • The sense amplifier detects which line is higher → outputs “1” or “0” by quickly driving BL/BLB to full swing (0 V or VDD). Think of it as an ultra-sensitive comparator that reads memory data very fast and with minimal disturbance. ⸻ 3. Types of Sense Amplifiers: 1. SRAM-Differential voltage SA—> Compares BL and BLB voltages 2. DRAM-Differential or single-ended voltage SA—>Reads small ΔV (~100 mV) from bitline 3. Flash / MRAM-Current-mode SA—> Detects current differences (cell current vs reference) 4. Key Specifications of a Sense Amplifier 1. Input Sensitivity-Minimum ΔV or ΔI it can detect reliably—> ~10–50 mV (voltage-mode), few µA (current-mode) 2. Offset Voltage-Input mismatch that can cause wrong decision—> < 10 mV desirable 3. Speed / Access Time-Time to resolve and amplify small signal—> Few nanoseconds or less 4. Power Consumption-Dynamic + static power; should be low—> Few µW–mW per read 5. Noise Margin-Tolerance to noise during sensing—>High margin required 6. Input Capacitance-Should be low to avoid loading bitline—> < 1 fF desirable 7. Matching / Variation Tolerance- Mismatch affects offset and yield—> Must be robust under PVT corners 5. Design Challenges 1. Small Signal Detection-The bitline voltage difference is very tiny (~tens of mV) — hard to sense under noise. 2. Offset Mismatch-Device mismatches (VT variations) cause offset → may flip data. 3. Speed vs. Power Trade-off- Higher speed needs higher bias currents → more power. 4. Capacitive Loading-Sense amplifier must not disturb the bitline during sensing. 5. PVT Variation Sensitivity-Must function correctly across Process, Voltage, Temperature corners. 6. Kickback Noise-During switching, the SA can inject noise back to bitlines, disturbing nearby cells. 7. Latch Stability- The latch (cross-coupled in SRAM SA) must settle reliably without metastability. Design sense amp for low (power, noise and offset ) and high ( speed and sensitivity )

174

6 comentarios

🧠 SystemVerilog Challenge for DV Engineers Two classes, one tricky problem: 🔹 Class A starts a thread that waits for a signal from the DUT 🔹 Class B needs to stop that thread if it takes too long (e.g., 100 ns) 🛠️ How would you implement this? Share your code or approach in the comments let’s learn from each other! class A;   task wait_for_ready();    @(posedge dut.ready);    $display("Ready received");   endtask   task start();    fork     wait_for_ready();    join_none   endtask endclass class B;   task monitor(A a);    #100ns;     // ❓ How would you stop the wait_for_ready thread here?   endtask endclass #Thankful #Inspire #Growth #SystemVerilog #UVM

96

11 comentarios

SIMPLIFYING SIGNAL INTEGRITY. Great goal, but can it be done? Is there a way to solve signal integrity (SI) with just enough complexity, but not too much? Yes, and the secret is data rate. Simplifying SI is non-optional. Layouts must be done, product must be shipped, volume must be ramped. The endless quest for faster, smaller, and more widely connected electronics marches on. And SI lies at the center of it. My quest has always been to simplify SI. Inelegant, overly complex solutions don’t get implemented, don’t scale. It’s imperative to find the appropriate solution for the data rate at hand. Key word: data rate. And herein lies the problem. Lack of knowledge and FUD (fear, uncertainty, and doubt) cause some to miss-apply solutions intended for higher data rates – adding complexity, cost, and schedule. Listening to industry buzz may paint the picture the whole world is busily implementing 224 Gbps, with all the next-generations tools, methodologies, and bug-a-boos that requires. Not true; there’s many new and important designs stepping into the 5 to 15 Gbps range. For the first time. To help you index into SI solutions appropriate for your present design, the following paragraphs pin solutions to data rate. In the Comment section further below I’ll offer additional resources for each speed bin. Follow the instructions, and you’ll win. 1-7 Gbps. Here’s where Gen2 SI began, and serial links became ubiquitous. Tons of change: new tools, models, methodologies, and standards happened all at once. But that was 20 years ago, so much of it is commonplace and wrung out now. Nevertheless, a few important things to know. 8-17 Gbps. Lower-loss PCB dielectrics and increasing equalization (EQ) arrived to extend operation into these data rates. New, smaller, and unexpected discontinuities became a leading cause of system failure as we learned to think about stubs, vias, and connectors in new ways. 18-37 Gbps. Further down the insertion loss (IL) curve requires still more EQ. Cables gave us the next 10x IL decrease and hence longer reach. Product ramps were the longest I’ve seen, as fundamental frequences and limits began to push back in ways we hadn’t seen for decades. Everything becomes a discontinuity. 38-67 Gbps. PAM4 arrives to increase data rate while leveraging the skills, materials, and design practices we learned for the frequencies of the previous paragraph. EQ complexity takes its biggest jump yet with the number of taps going double digits. Onward it goes, but I’ll stop here because more than 90% of you are grappling with data rates below those shown. Each speed bin requires new skills while leveraging those of the previous. To avoid making your project harder than it needs to be, visit the Comments section for resources appropriate for your data rate. Untangle SI's complexity in my LIVE class ‘Signal Integrity, in Practice’ coming soon to a location near you. #signalintegrity #siforees #gen2si

62

7 comentarios

✅ Simplify the concept of TLM Ports in UVM ✅ Latest demo session link - https://lnkd.in/gyUB_JFP 1️⃣ UVM TLM Analysis Port: Think of this as a broadcast channel – one producer sends data to multiple subscribers, perfect for tasks like scoreboarding and data analysis. 2️⃣ TLM Blocking Put Port: Used when an initiator sends transactions to a target. It’s like an APB generator communicating with a driver. 3️⃣ TLM Blocking Get Port: The reverse of the put port – a target sends data back to an initiator, like fetching data in an AHB interface. 4️⃣ TLM FIFO: A queue that buffers transactions between an initiator and target, ensuring smooth data flow while managing timing synchronization. 👉 👉 Please do follow & do share 👉 👉 For more information do contact ProV Logic or Prasanthi Chanda Please do Follow our Instagram page - https://lnkd.in/gYg6ggBH #mentor #guidance #training #workshop #vlsi #internships #design #verification #masters #interview #physicaldesign #vlsidesign #coaching #chip #manufacturing #digital #analog #semiconductor

179

'One FPGA to rule them all' All systems (almost all) - in a drone can be replaced with a single FPGA. Standalone, FPGA's are costly, hard to program and might seem counter-intuitive against using pre-built, programmable microcontrollers/ mini computes such as Raspberry Pi / Jetsons/ Arduinos or other IC's used in drones. But at scale, for application specific solutions and to achieve certifications, they are the perfect fit. Don't get me wrong, The pre-built microcontrollers are great for testing, for POC's but utilising these for large scale bloats up the costs and bloats up the software running within these controllers. That's where Iravan enters with is FPGA Systems, replacing a costly independant-multi-IC, power hungry systems currently being used across Power, Comms, Processing, Secondary flight control, ESC's, etc that bloat up the costs. Plus along with these benefits, the systems can be embedded with the open source/ closed Flight stacks currently in use! Other benefits: certifications become easier, cooling/ heating of certain components can be engineered as per application! Have questions? Get in touch! - [email protected] Drone Federation India (DFI) ideaForge Drone Helpline TropoGo Bharat Electronics Limited Paras Defence & Space Technologies Ltd. Zen Technologies Limited Hindustan Aeronautics Limited

136

7 comentarios

Open Source EDA used to build a IP company for ASIC and FPGA designs. By popular request about EDA tools we/Packet Architecs used to build our flow: - Python / myHDL for design & Verification (block & top testbenches) - We have made a couple of substancial changes to myHDL since its not great for a building large designs - cocotb (moving over from myHDL testbenches to cocotb) - Verilator (system verilog simulator, our major simulator for regressions!) - Yosys (synthesis) - gtkwave for waveform debugging - icarus verilog (another verilog simulator, but it has 4 state) - We also build a regression system over multiple servers (30+ servers) in Python - bash scripting - Latex ( for documentation) - Git - GCC first but then moved to llvm since it was faster to compile our design. - In myHDL we built a way to define register, tables which includes all the relevant documentation. Single source for all documtstion in the code. Off course a script generates the data sheets. - Look at our website for different designs ( https://www.packetarc.com/ ) We have also used Vivado (free version) since it does a pretty good job of synthesis!

99

26 comentarios