Part 15 answers: What changes for safety, security, processors and AI hardware?
The principles stay the same, but some domains change the questions. Safety standards ask how faults are detected, not just whether the design is correct; security asks what must never happen; processors and AI accelerators have enormous input spaces and their own oracles.
This part covers functional-safety verification, security verification, low-power and CDC in the plan, processors, AI accelerators and highly configurable IP.
Explain how functional safety changes verification goals.
Plan verification for a security property.
Choose an oracle and strategy for a processor or an AI accelerator.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 14: Sign-Off first.
A decision to accept the remaining risk, based on stated evidence; not a certificate that there are no bugs.
When the gap is understood, its risk is assessed and accepted by the right people, and it is recorded.
What was not verified or only partly verified, why, the likely impact, and any mitigation.
# | Lesson | Level | Status |
|---|---|---|---|
15.1 | P · Principal | Ready | |
15.2 | P · Principal | Ready | |
15.3 | S · Senior | Ready | |
15.4 | S · Senior | Ready | |
15.5 | P · Principal | Ready | |
15.6 | P · Principal | Ready | |
15.7 | P · Principal | 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 the decisions behind verification. These lessons teach the tools and syntax that carry them out, so this part links to them instead of repeating them.