ASIC Point Explore

← Design Verification Interviews

Interview Question · Concept

Analysis FIFOs vs Write Functions

L1 JuniorL2 Mid-LevelL3 Senioruvmtlmscoreboard

The interviewer asks

A scoreboard takes inputs from one monitor and outputs from another. Compare two uvm_analysis_imp_decl write functions with two uvm_tlm_analysis_fifos.

Reveal the Model Answer

With imps, write_in() and write_out() each run inside the monitor's call, in zero time. The scoreboard must store and match items inside those functions. With analysis FIFOs, writes are queued. The scoreboard pulls them with get() in its own run_phase, so it can wait for the other side. Imps suit simple immediate checks. FIFOs suit checks that wait or match in order across streams.

One Write, Three ListenersArrows leaving in_mon are calls of write, numbered in the order this library makes them. The FIFO's arrow to the checker is a returned handle.
call: who calls whomdata: where the transaction goes
One write, three listenersArrows leaving `in_mon` are calls of `write`, numbered in the order this library makes them. The FIFO's arrow to the checker is a returned handle. publisher in_mon ap.write(t) at 10 and20 ns queue chk.fifo Analysis FIFO,unbounded subscriber cov uvm_subscriber:write(t) subscriber sb write_in(t) andwrite_out(r) component chk run_phase fifo.get(t), then 25ns of work publisher out_mon ap.write(r) at 15 and25 ns 1: write(t)2: write(t)3: write_in(t)t returns to get(t)write_out(r)
  1. Publish10 ns (illustrative)

    At 10 ns in_mon calls ap.write(#1) once. The port calls write on each of its three resolved imps, in turn, inside that one call.

    Follow the calls, values and waits
    1. call write(#1): in_mon → chk.fifo
    2. call write(#1): in_mon → cov
    3. call write(#1): in_mon → sb
  2. Return10 ns (illustrative)

    Every write is a function, so all three finish at 10 ns and in_mon goes on at once. The FIFO stored the handle; cov and sb did their work.

  3. Consume later10 ns (illustrative)

    The checker's own thread takes #1 from the FIFO at 10 ns and works on it for 25 ns. The monitor never waited for it.

    Follow the calls, values and waits
    1. return #1: chk.fifo → chk run_phase
    2. Waiting: chk run_phase — working on #1 until 35 ns
  4. Second input15 ns (illustrative)

    At 15 ns out_mon writes the result to the scoreboard's second imp, which calls write_out.

    Follow the calls, values and waits
    1. call write_out(#1): out_mon → sb
  5. Publish #2 into a busy checker20 ns (illustrative)

    At 20 ns in_mon writes #2. The FIFO stores it although the checker is still busy with #1.

    Follow the calls, values and waits
    1. call write(#2): in_mon → chk.fifo
    2. call write(#2): in_mon → cov
    3. call write(#2): in_mon → sb
  6. Take #235 ns (illustrative)

    At 35 ns the checker finishes #1 and takes #2, which has waited in the FIFO since 20 ns.

    Follow the calls, values and waits
    1. return #2: chk.fifo → chk run_phase
    2. Waiting: chk run_phase — working on #2 until 60 ns
    3. Released: chk run_phase
  7. Finish60 ns (illustrative)

    The checker finishes #2 at 60 ns: it took 2 and finished 2.

    Follow the calls, values and waits
    1. Released: chk run_phase
Read the diagram as text
  • in_mon: ap.write(t) at 10 and 20 ns
  • chk.fifo: Analysis FIFO, unbounded
  • cov: uvm_subscriber: write(t)
  • sb: write_in(t) and write_out(r)
  • chk run_phase: fifo.get(t), then 25 ns of work
  • out_mon: ap.write(r) at 15 and 25 ns
  • in_mon → chk.fifo: 1: write(t)
  • in_mon → cov: 2: write(t)
  • in_mon → sb: 3: write_in(t)
  • chk.fifo → chk run_phase: t returns to get(t)
  • out_mon → sb: write_out(r)

The publisher's code does not change with the number of listeners, zero included.

Two write functions

`uvm_analysis_imp_decl(_in)
`uvm_analysis_imp_decl(_out)
function void write_in(item t);  exp.push_back(model(t)); endfunction
function void write_out(item t); compare(exp.pop_front(), t); endfunction

Zero time, inside the monitor's call

Two analysis FIFOs

uvm_tlm_analysis_fifo #(item) in_f, out_f;
task run_phase(uvm_phase phase);
  forever begin
    in_f.get(i); out_f.get(o);
    compare(model(i), o);
  end
endtask

Own thread, can wait for the other stream

Self-Check

Tick each key point you covered in your answer.

What Interviewers Listen For (Junior)

A good junior answer explains why one class cannot have two write() methods. It says what the uvm_analysis_imp_decl macro generates.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItCompareScale It

  1. Analysis FIFOs vs Write Functions
  2. WhyWhat the Imp Decl Macro GeneratesL1 Junior

    Why does a scoreboard with two analysis inputs need uvm_analysis_imp_decl?

    Reveal the Model Answer

    A uvm_analysis_imp calls a method named exactly write in its parent. Two inputs would both call that one method, and the scoreboard could not tell them apart. The macro declares a new imp class, such as uvm_analysis_imp_in, that calls write_in() instead.

    Self-Check

    Tick each key point you covered in your answer.

    Half-Truth

    "Use one write and check the item type to see where it came from."

    Both monitors often send the same item type, so the type says nothing about the source.

    Source Verification Academy, UVM Cookbook, Analysis Components (PDF p160)

  3. What IfTwo Scoreboard Inputs in the Same Time StepL2 Mid-Level

    What if both inputs arrive in the same time step, and the scoreboard compares inside write_out()?

    Reveal the Model Answer

    The two calls come from separate monitor processes, so their order in one time step is not fixed. If write_out() runs first, the expected item is not there yet and the compare fails falsely. Store both sides and compare when both are present. Or use analysis FIFOs and get from both in run_phase.

    Self-Check

    Tick each key point you covered in your answer.

    Misconception

    "Inputs are processed in connect order, so the input side comes first."

    The calls come from separate monitor processes. Their order in one time step is not defined.

    Source IEEE 1800-2017 §4.7

  4. CompareAnalysis FIFO vs a Queue in the ScoreboardL2 Mid-Level

    Compare an analysis FIFO with a plain queue that write_in() pushes into.

    Reveal the Model Answer

    Both store items until their partner arrives. A plain queue is lighter, and it is enough when write_out() does the matching. It has no blocking read, though, so a thread that wants to wait for an item must poll. The FIFO gives a blocking get(), plus peek() and used(), so a matching thread can simply wait.

    Self-Check

    Tick each key point you covered in your answer.

    Buzzword Without Mechanism

    "A queue inside the scoreboard is not proper UVM."

    UVM does not require FIFOs. The choice depends on whether a thread must wait for items.

  5. What IfItems Left in a FIFO at the EndL2 Mid-Level

    What if one FIFO still holds items when the test ends?

    Reveal the Model Answer

    Those items never met a partner, so something is wrong: the DUT lost a response, or the test ended too early. In check_phase, report used() for each FIFO as an error, with the first leftover item printed. Then a lost response fails the test instead of vanishing.

    Self-Check

    Tick each key point you covered in your answer.

    Misconception

    "Leftovers are normal noise at the end of a test."

    Each leftover is an input with no output or the reverse. Hiding them hides dropped transactions.

    Source Verification Academy, UVM Cookbook, Analysis Components: comparator checks (PDF p170-173)

  6. Scale ItMemory Growth in a Long TestL3 Senior

    A ten-million-transaction test slowly runs out of memory. The bench uses analysis FIFOs. Where do you look first?

    Reveal the Model Answer

    Print used() for each analysis FIFO during the run. If one keeps growing while its partner stays empty, nothing is consuming it. Perhaps the matching thread died or waits on the wrong FIFO. An unbounded FIFO hides that for millions of items. Fail the test when used() passes the most transactions that can legally be in flight.

    Self-Check

    Tick each key point you covered in your answer.

    Tool as Truth

    "The simulator leaks memory; give the job more RAM."

    An unbounded FIFO that nobody reads keeps every item it was given. Check the bench's own queues before blaming the tool.

    Source uvm-core 2020.3.1 (IEEE 1800.2 library) source, tlm1/uvm_tlm_fifos.svh, uvm_tlm_analysis_fifo is unbounded

  7. Prove ItSolve U3.4.1: The Trace Window That Never Drops QuietlySimulator-graded

    Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

    Open Problem U3.4.1

What People Get Wrong

Common wrong answers and why they fail.

Misconception

"An analysis FIFO can fill up and stall the monitor."

An analysis FIFO is unbounded, so write() never blocks. The risk is the opposite: it grows without limit.

Source uvm-core 2020.3.1 (IEEE 1800.2 library) source, tlm1/uvm_tlm_fifos.svh, uvm_tlm_analysis_fifo::new: super.new(name, parent, 0), "must be unbounded"

Misconception

"Just declare write() twice with different argument names."

A class can have only one method called write. The macro makes a new imp class that calls write_in or write_out instead.

Source Verification Academy, UVM Cookbook, Analysis Components: uvm_analysis_imp_decl (PDF p160)

Missed Corner

Never checks the FIFOs at the end of the test.

Items left in a FIFO were never compared. Without an end check, lost responses pass silently.

Source Verification Academy, UVM Cookbook, Analysis Components: comparator end-of-test checks (PDF p170-173)

Learn It, Then Prove It