Separate building the behavior from checking it
For a digital hardware exercise, the design task is to implement behavior under stated constraints. Verification asks whether that implementation meets the specification across relevant conditions. Synopsys describes functional verification in terms of checking intended behavior before production. This is distinct from claiming that a passing test proves a physical chip is ready to manufacture.
An internship may combine design, verification, scripting and debugging. Read the deliverables in the exact role rather than treating the title as a fixed boundary. A student can enjoy both tasks, but showing one does not automatically demonstrate the other. A block that works in a favorite demonstration may still fail reset, boundary or error cases.
Sources[1]
Compare the work samples, not just the tool names
The following are original preparation suggestions. They are not employer requirements or a claim that every applicant must know a particular commercial tool. Use a simulator or teaching environment you are authorized to use; a paid license is not necessary just to demonstrate a well-defined small exercise.
| Question | Design evidence | Verification evidence |
|---|---|---|
| What must happen? | Written push/pop/reset behavior and state representation | Independent expected outcomes from the specification |
| What did you build? | Implementation with readable interfaces | Test plan, checks and reproducible stimulus |
| What did you inspect? | Boundary transitions and stated implementation constraints | Empty/full/reset/simultaneous-operation cases |
| What should the reviewer receive? | Source, assumptions and reproducible run instructions | Failing case, expected/actual result and regression test |
Build a four-entry FIFO with an explicit contract
Use a fictional four-entry queue as a bounded project. Specify what happens when a push is requested while full, a pop while empty, both operations in the same cycle, or reset during activity. There is not one universal answer to every boundary choice; your implementation and tests must agree with the contract you actually wrote.
Start with a reference model independent of the implementation. Run a short deterministic sequence by hand, then add generated sequences with a recorded seed. Keep a log containing input actions, expected queue contents and observed outputs. When a mismatch appears, minimize the sequence until another person can reproduce it without reading a thousand-line waveform.
A useful finding is not just a screenshot labelled bug. State the precondition, stimulus, expected result, actual result and the change that fixed it. Preserve the failing example as a regression. This is how a small project becomes inspectable evidence of reasoning.
Do not confuse coverage with correctness
List which requirements you tested and which remain untested. A counter saying that every line executed does not demonstrate that every relevant sequence or timing condition was checked. Likewise, a functional simulation does not establish physical timing, power, manufacturing yield or silicon reliability. Keep those boundaries visible in your write-up.
Arm's education resources provide learning material in chip design and related subjects. Use them to understand concepts, but follow their access and reuse terms. Completing a course is different from independently producing and explaining a project. When a tool generates code, inspect it and be ready to explain the decisions instead of presenting unfamiliar output as your own expertise.
Sources[2]
Turn the exercise into a precise application story
For a design-oriented application, explain the specification and one implementation trade-off. For a verification-oriented application, explain how you derived tests, found a boundary failure and prevented it from returning. Mention tools only where you actually used them. Do not call the exercise a tape-out or a production chip.
Next, compare actual internship descriptions for degree stage, expected coursework and mandatory versus preferred skills. General early-career pages can suggest an entry point, but they do not establish the requirements of a specific team. Save the exact role link and a short match between its work and your evidence.