博文

How V&V is typically approached for ARM-based SoCs?

图片
When dealing with an ARM-based SoC , verification and validation follow the general SoC V&V flow, but with some ARM-specific considerations and best practices due to the licensed cores, standardized IP blocks (e.g., Cortex-A/R/M cores, Mali GPUs, AMBA bus), and the ecosystem. Here's how V&V is typically approached for ARM-based SoCs: Verification Methods for ARM-Based SoCs  1. IP-Level Verification (Cortex Core, Peripherals) ARM provides golden reference models (e.g., Cortex-M3, A72) and assertion checkers . Use ARM-supplied test suites and assertions to verify: Correct instruction execution Exception/interrupt handling MMU/Cache behavior (for Cortex-A) AMBA AXI/AHB/APB protocol compliance is critical — verified with: UVM testbenches ARM AMBA protocol checkers Tools: Synopsys VC Formal, Cadence JasperGold, UVM testbenches  2. Subsystem Verification As ARM SoCs integrate IP like Cortex cores + GPU + DMA + interconnects , subsyst...
发表评论
阅读全文

How to optimize MCU interrupt response time?

图片
 Optimizing MCU interrupt response time is crucial for real-time performance and accurate signal processing. Below are practical, layered strategies to reduce latency and improve the efficiency of your interrupt handling:  1. Minimize Interrupt Latency (Time Until ISR Starts)  What causes latency? Instruction execution delay Stack saving (context switch) Nested interrupts disabled Peripheral delay (e.g., slow flag clearing)  Optimization Techniques: Tip Description Enable fast interrupt mode (if supported) Some MCUs (e.g. ARM Cortex-M3+) support tail-chaining or fast ISR entry Use high-priority interrupts Assign highest priority to critical ISRs Avoid global interrupt disable ( __disable_irq() ) Keep interrupts globally enabled as much as possible Use vectorized interrupt handling Avoid shared interrupt vectors; direct vector → faster Place ISR in RAM (if allowed) Running code from RAM can be faster than Flash on some MCUs  2. Write Ef...
发表评论
阅读全文

What is High-Level Synthesis (HLS), and how does it differ from traditional HDL design?

图片
High-Level Synthesis (HLS) is an advanced design methodology in digital hardware development that allows you to describe hardware functionality using high-level programming languages like C, C++ , or SystemC , instead of traditional hardware description languages (HDLs) like Verilog or VHDL . Definition of High-Level Synthesis (HLS) HLS tools automatically generate synthesizable RTL (Register Transfer Level) code (usually in Verilog or VHDL) from high-level algorithmic descriptions. These tools optimize the design for area, speed, power, and throughput, just like a human RTL designer would. Difference Between HLS and Traditional HDL Aspect Traditional HDL (Verilog/VHDL) HLS (C/C++/SystemC) Design Level Low-level (cycle-accurate RTL) High-level (algorithmic/functional) Language Verilog, VHDL C, C++, SystemC Control Over Timing Full control over clock cycles and FSM Abstracted; compiler decides timing Development Speed Slower; manual state machine design Faster; uses software-style c...
发表评论
阅读全文

Why is my MCU resetting unexpectedly?

图片
 If your MCU ( Microcontroller Unit) is resetting unexpectedly , it's likely due to faults, environmental issues, or software bugs . Here's a structured breakdown of the most common causes and how to troubleshoot them:  1. Power Supply Issues Low voltage or unstable power can trigger brown-out detection or watchdog resets. Check for: Power dips or noise Insufficient current supply Poor decoupling (add capacitors close to Vcc/GND)  Fix: Use a regulated power supply, add capacitors (e.g. 0.1 µF + 10 µF), verify with oscilloscope if possible.  2. Watchdog Timer (WDT) Reset If the watchdog( What is a Watchdog? ) timer is enabled but not reset ("fed") properly , the MCU will reset.  Fix: Ensure wdt_reset() (or equivalent) is called regularly, or disable WDT in code if not needed.  3. Brown-Out Reset (BOR) Happens when supply voltage drops below a safe level . Some MCUs reset to protect memory or ensure stable operation....
发表评论
阅读全文

How to use PWM on the STM32F407 microcontroller?

图片
 Here's a complete guide to using PWM on the STM32F407 microcontroller using TIM4 and GPIO pin PD12 (which maps to TIM4_CH1 ) — commonly used on STM32F4 Discovery boards.  Goal Generate PWM signal on PD12 (TIM4 Channel 1) using STM32F407 and HAL drivers via STM32CubeMX + STM32CubeIDE .  Required Tools STM32F407 MCU or Discovery board STM32CubeMX STM32CubeIDE USB cable, LED, or oscilloscope (to observe PWM)  Step-by-Step Instructions 1. STM32CubeMX Configuration a. Select Device Open CubeMX and choose STM32F407VGTx (or your variant). b. Configure Pin Click on pin PD12 , set as TIM4_CH1 → PWM Generation CH1 . c. Configure Timer 4 Go to Timers → TIM4 → Mode → PWM Generation Channel 1 . Set: Prescaler : 83 → 84 MHz / (83+1) = 1 MHz timer frequency Counter Period (ARR) : 999 → PWM frequency = 1 MHz / 1000 = 1 kHz Pulse : 500 → 50% duty cycle d. Clock Configuration Ensure the system clock is at 84 MHz (fr...
发表评论
阅读全文

Operating Systems for Automotive SoCs

图片
  The automotive industry relies on   real-time, safety-critical, and high-performance computing   for applications like   advanced driver-assistance systems (ADAS), infotainment, and autonomous driving . Here are the most common   OS choices for automotive SoCs , categorized by use case: 1. Real-Time & Safety-Critical Systems (ADAS, ECUs) For  low-latency, deterministic control  (braking, engine control, sensor fusion): A. QNX Neutrino (BlackBerry QNX) Why? Certified for ISO 26262 (ASIL-D)  – highest automotive safety standard. Microkernel architecture  (fault isolation, high reliability). Used in  Tesla, BMW, Ford, and Audi  infotainment/ADAS. Example SoCs: Qualcomm Snapdragon Ride (SA8155P) NXP S32G (ARM Cortex-A/M) B. AUTOSAR OS (Classic & Adaptive) Why? Industry-standard OS  for Electronic Control Units (ECUs). Supports  hard real-time  requirements (ASIL-B to ASIL-D). Used in  powertrain, body c...
发表评论
阅读全文