Ten high-frequency questions on ports, exports and imps, connection rules, unconnected ports, analysis write order, analysis FIFOs, pass-by-handle and TLM 2.0, with weak and senior answers.
On this page
TLM questions look like vocabulary tests, which is why mid-level candidates relax. Then the follow-up arrives: "so what happens if nobody connects it?", or "in what order do the subscribers see the write?". Those have exact answers in the library, and the wrong ones cause the silent failures seniors are hired to prevent.
Answer in terms of control flow and ownership: who calls whom, who owns the object, what is checked at elaboration and what is never checked. Use the DMA bench's analysis network (three monitors feeding a scoreboard, a predictor, a comparator, coverage and a watchdog) as your example.
The questions
Port, export, imp: what is the difference?
Which way do hierarchical connections go?
A put port is never connected. When do you find out? And an analysis port?
A monitor's analysis port feeds the scoreboard and coverage. In what order do they see the write?
Your subscriber needs to wait for the matching expected item inside write(). Can it?
How do two analysis streams reach one scoreboard?
Every entry in your scoreboard queue shows the same data. What happened?
Blocking or nonblocking, get or peek: what do the TLM 1 methods promise?
TLM 2.0: when do you use b_transport and when nb_transport?
Why analysis ports instead of having the monitor call the scoreboard directly?
Rapid fire
Check yourselfA coverage collector named sb_cov reads the scoreboard's last verdict inside its write(). A refactor renames it cov, and it starts sampling the previous transaction's verdict. Why?
Analysis subscribers are called in alphabetical order of full name. env.sb sorted before env.sb_cov, so the scoreboard ran first; env.cov sorts before env.sb, so coverage now runs first and sees the old verdict. The real bug is depending on the order at all: the scoreboard should publish its verdict on its own analysis port.
Check yourselfA team connects the out agent's monitor port to the same scoreboard imp twice by accident. Is write() now called twice per transaction?
No. A port records its providers keyed by the provider's full name, so connecting the same imp again stores the same single entry, silently. Connecting a different subscriber adds to the list and never overwrites one. A connect made at or after end of elaboration is ignored with a Late Connection warning.