- Pick this if you are ready for deeper system scope, stronger validation demands, and more moving parts to manage responsibly.
- This level works best when you already know how to finish and document smaller projects, not when you are still trying to get your first win.
This matters because strong projects do not just fill space on a profile. They help you build depth in one or two strategic tracks that can later connect to research, internships, and hiring.
WHY THIS IDEA IS STRONG
Shows RTL design plus the discipline to verify what you built instead of only simulating a happy path.
WHAT TO BUILD
- Design a protocol controller in RTL
- Create assertions and self-checking tests
- Log transactions to a host dashboard
- Compare throughput, latency, and resource trade-offs
- Build the core protocol or packet-processing block
- Create a self-checking testbench and assertions
- Add host-side logging or a dashboard view
- Summarize timing, resources, and debug findings
EVIDENCE TO SHOW
- RTL repo
- simulation waveforms
- coverage or test summaries
- timing/resource reports
HOW TO DOCUMENT THIS ON SYQNAL
Use these prompts when you write the STORY step in the guided project builder. They help keep the page factual, specific, and evidence-backed.
- What protocol or traffic problem were you targeting?
- What timing or resource constraints shaped the design?
- What architectural trade-off did you accept in RTL or verification scope?
- What test or coverage results best prove the design behaves correctly?
AI-ASSISTED BUILDING STANDARD
It is fine to use AI to help scope, scaffold, review, and debug this idea. But the final project should still reflect your own understanding, validation, trade-offs, and documentation. If you cannot explain the design or reproduce the build, the project is not ready yet.
