interview 4 Flashcards
(9 cards)
What was the purpose of your RTL controller?
It controlled read and write operations to an OTP macro over an I²C interface. It managed command decoding, timing control, and ensured protocol correctness during OTP access cycles.
OTP is typically accessed during boot or calibration. Timing and command integrity are critical since OTP is not rewriteable.
What types of operations did the controller support?
Basic commands included Read, Program, and optionally a Lock function. These were mapped to specific I²C instructions, decoded by the controller, and sequenced with respect to OTP timing constraints.
Program commands often require higher voltage or longer pulse timing. Lock disables future writes → irreversible → needs secure FSM logic.
What challenges did you face designing the FSM?
The main challenge was synchronizing I²C protocol stages (Start, Address, Data, Stop) with OTP timing – ensuring safe control even in presence of clock stretching or incomplete sequences.
Multi-stage FSM with clearly separated command and execution phases. State protection to avoid undefined write conditions.
Why was I²C chosen for the interface?
It was a simple, low-pin-count interface suitable for configuring OTP in system initialization. It allowed integration with MCU or testbench infrastructure.
I²C is slow (typically ≤ 400kHz), so timing margins to OTP must be respected. Pull-up resistor sizing affects rise time – not just logic!
How did you test and verify the RTL block?
I built Verilog testbenches simulating I²C master traffic, covering valid and invalid sequences. I also added assertions for timing windows and FSM state transitions.
Mention FSM state coverage, bus protocol edge cases. If possible, name tools (ModelSim, Questa, UVM-style env).
What physical effects were relevant in this design?
Timing violations in OTP programming (e.g., pulse width too short) could lead to incomplete bit activation. I used timing counters and checked edge hold requirements.
OTP = antifuse or e-fuse → requires precise pulse energy. I²C bus: RC delays affect edge detection in slower corners.
Would you do anything differently today?
I would modularize the FSM and I²C interface more strictly, and integrate assertion-based verification from the beginning. Also, consider fault injection tests for partial programming failures.
Propose enhancements like ECC, bus timeouts, or self-checking states.
Why is this project relevant to your current goals?
It was a complete block-level design experience where I had to understand both digital control logic and underlying physical programming behavior. That combination is what I want to build further in design-focused roles.
