Part 15 answers: How do we know it is correct?
A protocol is only as good as its specification and the evidence that implementations follow it. This part treats both: how to write an interface contract others can build to, and how to check one with assertions, monitors, scoreboards, coverage and formal tools.
This part covers writing an interface contract, safety and liveness, protocol assertions, monitors, ordering-aware scoreboards, protocol coverage, formal methods, compliance and VIP, observability and a waveform debug method.
Write a reusable set of handshake and credit assertions.
Score responses that return out of order.
Plan coverage that would convince a reviewer an interface is done.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 14: Security and Isolation first.
At the target or in a firewall in the fabric, using attributes carried with each transaction; never by trusting the requester alone.
So a device can only reach the memory it was given, through translations software controls, rather than any physical address.
Regulators (rate limits) and QoS arbitration at the shared points, which cap its share.
# | Lesson | Level | Status |
|---|---|---|---|
15.1 | P · Principal | Ready | |
15.2 | W · Working | Ready | |
15.3 | W · Working | Ready | |
15.4 | W · Working | Ready | |
15.5 | S · Senior | Ready | |
15.6 | S · Senior | Ready | |
15.7 | S · Senior | Ready | |
15.8 | S · Senior | Ready | |
15.9 | P · Principal | Ready | |
15.10 | W · Working | Ready | |
— | all levels | Ready |
Every lesson in this part is ready. Work through them in order: each one sets up the problem the next one solves.
This course teaches why protocols are designed the way they are. These lessons show how to build or sign off the same ideas, so this part links to them instead of repeating them.