Tampere University System-on-Chip Design Master's Thesis Guide: 30 ECTS, STEM-JPY, Tapeout and Trepo

Quick answer: what governs the System-on-Chip Design thesis?

Tampere University’s System-on-Chip Design option is a 120 ECTS, two-year Master of Science (Technology) specialisation in Computing Sciences and Electrical Engineering. The thesis therefore follows Tampere’s Technology thesis framework: the thesis itself is 30 ECTS and uses the 0–5 grading scale.

The programme-specific curriculum object needs careful reading. Current STEM-JPY System-on-Chip Design is an advanced-studies module labelled at least 120 ECTS. That label must not be read as “120 ECTS coursework plus another 30 ECTS thesis.” The governing degree itself is 120 ECTS, while the institutional Technology thesis is 30 ECTS. The public STEM-JPY page does not expose how every credit is structurally nested, so use your current Sisu plan for exact placement rather than doing arithmetic from the module label.

STEM-JPY is exceptionally useful as an academic scope statement: it covers the SoC flow from architecture specification through EDA, hardware/software integration, verification, tapeout and testing a manufactured sample chip. Current courses such as COMP.CE.250 System-on-Chip Design, COMP.CE.400 System Design and COMP.CE.510 Chip Implementation further document present SoC, FPGA, ASIC, PPA, DFT and timing-closure content. They are evidence of the current academic environment, not automatically proof that each course is compulsory in every student’s plan.

Current ITC.CEE.800 Tools for theses is 5 ECTS and pass/fail, but STEM-JPY does not establish it as compulsory inside every SoC plan. Verify its placement and the current seminar implementation in Sisu/Moodle.

Quick answer: what governs the System-on-Chip Design thesis?

Tampere University’s System-on-Chip Design option is a 120 ECTS, two-year Master of Science (Technology) specialisation in Computing Sciences and Electrical Engineering. The thesis therefore follows Tampere’s Technology thesis framework: the thesis itself is 30 ECTS and uses the 0–5 grading scale.

The programme-specific curriculum object needs careful reading. Current STEM-JPY System-on-Chip Design is an advanced-studies module labelled at least 120 ECTS. That label must not be read as “120 ECTS coursework plus another 30 ECTS thesis.” The governing degree itself is 120 ECTS, while the institutional Technology thesis is 30 ECTS. The public STEM-JPY page does not expose how every credit is structurally nested, so use your current Sisu plan for exact placement rather than doing arithmetic from the module label.

STEM-JPY is exceptionally useful as an academic scope statement: it covers the SoC flow from architecture specification through EDA, hardware/software integration, verification, tapeout and testing a manufactured sample chip. Current courses such as COMP.CE.250 System-on-Chip Design, COMP.CE.400 System Design and COMP.CE.510 Chip Implementation further document present SoC, FPGA, ASIC, PPA, DFT and timing-closure content. They are evidence of the current academic environment, not automatically proof that each course is compulsory in every student’s plan.

Current ITC.CEE.800 Tools for theses is 5 ECTS and pass/fail, but STEM-JPY does not establish it as compulsory inside every SoC plan. Verify its placement and the current seminar implementation in Sisu/Moodle.

1. Start from the SoC lifecycle, not from a generic chip idea

A strong SoC thesis starts by identifying which part of the lifecycle carries the research question. STEM-JPY covers architecture specification, reusable hardware/software blocks, EDA, verification, HW/SW integration, tapeout and post-manufacturing testing. A single thesis rarely has enough time to make every stage equally novel.

Define the boundary explicitly. An architecture thesis may compare accelerator or interconnect choices. An RTL thesis may study microarchitecture, low-power logic or reusable IP. A verification thesis may evaluate coverage or bug-detection efficiency. A physical-design thesis may study timing, congestion, power or area. A post-silicon thesis may focus on bring-up, measurement or model-to-silicon correlation.

The thesis becomes clearer when supporting stages are treated as controlled infrastructure rather than additional research questions.

2. The 30 ECTS thesis is not the same thing as the STEM-JPY credit label

The institutional thesis itself is 30 ECTS because this is an MSc (Technology) route. STEM-JPY’s “at least 120 credits” label is a curriculum-module label and must not be mechanically added to that thesis. The full degree is 120 ECTS.

For planning, trust the three facts that are independently established: the degree is 120 ECTS, the Technology thesis is 30 ECTS, and STEM-JPY is a broad current SoC study package. For the exact nesting of courses, thesis and other studies, follow the structure attached to your current Sisu study right.

This prevents a common catalogue-reading error and keeps the guide valid even where the Student’s Guide module interface exposes a broad package rather than a simple 60/80-credit major.

3. Turn a chip-development task into a research question

“Design an SoC”, “implement an accelerator” or “tape out a chip” are engineering objectives. A thesis needs a bounded question that can be answered with evidence. Ask what design decision is being tested, what alternative or baseline exists, what workload represents the intended use and what metric determines whether the claim is supported.

For an accelerator, the question might concern latency, throughput, energy efficiency or area under a defined workload. For an interconnect study, it might concern contention, scalability or implementation cost. For low-power work, define whether the target is average power, energy per operation, leakage or a power-state transition.

Avoid selecting metrics after seeing the result. Fix primary outcomes and comparison logic before the final experiment where practical.

4. Architecture and HW/SW partitioning are part of the method

SoC research often depends on where functionality is placed: CPU software, accelerator, programmable logic, dedicated IP, memory system or peripheral. Record the partition and the interface assumptions because these choices can dominate latency, bandwidth, power and flexibility.

When two architectures are compared, keep the workload and correctness criteria equivalent. A faster accelerator is not a fair comparison if it changes numerical precision, algorithm quality or input size without disclosure. Likewise, a software baseline should not be deliberately left untuned while the proposed hardware design receives extensive optimisation.

Use architecture diagrams and interface tables to make the controlled boundary explicit. Readers should be able to identify what is proposed, what is reused and what is merely infrastructure.

5. RTL, IP integration and configuration control

Current COMP.CE.250 documents SystemVerilog, SoC interconnects/interfaces and IP-XACT as part of the current SoC curriculum. In an RTL or IP-integration thesis, preserve exact versions of RTL, generated IP, scripts, parameter sets and interface descriptions. A synthesis or simulation result without a traceable configuration is difficult to reproduce.

Generated IP can change when tool versions or parameters change. Record these dependencies rather than treating generated files as timeless. If proprietary vendor IP cannot be shared, document its role, configuration and interface sufficiently for the academic argument while respecting licence restrictions.

For reset, clock, voltage and power domains, describe assumptions explicitly. Cross-domain behaviour, power-state sequencing or reset release can cause failures that nominal functional simulation does not expose.

6. Verification: define what would count as sufficient evidence

Verification is not “the simulation passed.” Define the property being checked and the evidence required. Directed tests, constrained-random simulation, assertions, formal checks, reference models and coverage can answer different questions. Use only the techniques justified by the research problem.

Record simulator and verification-framework versions, random seeds, testbench revision and coverage definitions when they materially affect results. If bug-detection effectiveness is compared, define the fault/bug population or benchmark and avoid tuning the proposed method on the final evaluation set.

Coverage percentage is not a universal proof of correctness. Explain what the metric covers and what it leaves out. A high structural coverage number can coexist with untested protocol or architectural behaviour.

7. FPGA prototyping and virtual platforms are intermediate evidence

STEM-JPY and COMP.CE.250 include virtual prototyping and FPGA prototyping/emulation in the current academic environment. These are powerful ways to validate integration and run realistic workloads before silicon exists.

But FPGA evidence is not automatically ASIC evidence. FPGA memories, routing, clocking, DSP blocks and power behaviour differ from a standard-cell ASIC. If an FPGA prototype is used to support an ASIC claim, state which conclusions transfer and which remain implementation-specific.

Record FPGA device, tool version, constraints, clock frequency and resource mapping. If a virtual platform or emulator is used, state its abstraction level and whether timing is functional, approximate or cycle-accurate.

8. ASIC synthesis, physical design and sign-off

Current COMP.CE.510 Chip Implementation documents synthesis, physical design, standard-cell technologies/libraries, sign-off tools, IO planning, DFT, PPA analysis, physical-aware synthesis and multi-mode multi-corner timing closure. These are strong current anchors for implementation-oriented thesis methodology.

Report the technology/library context, synthesis and place-and-route tool versions, key constraints, clock definitions and PVT/MMMC assumptions when they affect the result. Distinguish pre-layout, post-synthesis and post-route numbers. Timing, area and power can change materially as physical information becomes more accurate.

If a result is called “sign-off”, specify which checks were actually completed. Timing closure, DRC/LVS, power integrity or other sign-off stages are distinct; do not imply a full sign-off flow from one passing report.

9. PPA comparisons need a fair experimental design

Power, performance and area are central SoC trade-offs, but a single PPA table can be misleading. Compare designs using the same technology context, libraries, constraints, workload assumptions and tool-flow stage where possible.

State whether power is estimated from vectorless activity, simulation-derived switching, gate-level activity or measured silicon. State whether performance means maximum clock, latency, throughput or application-level completion time. State whether area means synthesis cell area, placed core area or final die/core footprint.

When one design improves one metric by sacrificing another, report the trade-off rather than declaring a universal winner. Pareto-style reasoning can be more informative than collapsing everything into one score.

10. Tapeout is a milestone, not a guaranteed thesis dependency

STEM-JPY explicitly includes hands-on SoC tapeout, which makes Tampere’s environment unusually relevant to silicon-oriented research. However, every thesis should be schedulable even when fabrication or shared tapeout dates are outside the student’s control.

If silicon is required for the main research claim, map submission, fabrication, packaging, board availability and lab bring-up dates against the thesis deadline. Agree a fallback with the supervisor: post-route sign-off evidence, FPGA evidence, prior silicon or a reduced question may be defensible depending on the topic.

Do not promise measured-silicon conclusions before silicon exists. A thesis can explicitly separate pre-silicon claims from post-silicon validation.

11. Post-silicon bring-up and measurement

Testing a manufactured sample chip is part of STEM-JPY’s documented scope. Post-silicon work should separate bring-up from research evaluation. Confirming power rails, clocks, JTAG/debug access, memory or basic functionality establishes a usable platform; it does not automatically prove performance, reliability or power claims.

Record chip revision, package/board revision, firmware/test software, lab instruments, calibration and environmental conditions where relevant. If measured silicon is compared with pre-silicon models, define what mismatch is acceptable and investigate systematic differences rather than reporting only the best run.

For repeated measurements, control temperature, supply, clock and workload. Where manufacturing variation matters, be explicit about whether the evidence comes from one sample or multiple devices.

12. ITC.CEE.800 and the seminar boundary

Current ITC.CEE.800 Tools for theses is 5 ECTS, pass/fail. Its four current components are research methods, research ethics, information searching skills and career planning, and Tampere recommends completing the course before thesis work.

However, the current public STEM-JPY module does not establish ITC.CEE.800 as a compulsory System-on-Chip Design component. Do not infer compulsory placement solely because earlier CSEE programmes used it. Check your current Sisu study plan and programme instructions.

Similarly, Tampere’s Technology thesis rules require seminar participation, an oral presentation and opposition-related thesis activity, but the current public System-on-Chip Design module does not expose a separate Embedded-specific seminar course code. Follow the current programme-specific Sisu/Moodle implementation rather than resurrecting an old seminar code.

13. Topic, supervisor and industrial SoC environment

The applicant-facing programme explicitly describes collaboration with companies that offer mentoring, trainee opportunities and Master Thesis positions, and it highlights Tampere’s SoC ecosystem. That makes industry-commissioned work realistic, but company relevance does not replace the academic question.

Match the supervisor to the centre of gravity: architecture, verification, digital design, physical implementation, HW/SW integration or post-silicon measurement. Cross-layer projects may need secondary technical support, but one primary research question should remain visible.

If the topic depends on proprietary PDKs, standard-cell libraries, EDA licences or company IP, confirm access and publication boundaries before committing to the scope.

14. Thesis Supervision Plan and SoC project controls

The Technology thesis process requires a Thesis Supervision Plan. For SoC work, add technical dependencies to the normal scope, meetings, feedback and schedule: EDA licences, compute queues, PDK/library access, IP blocks, FPGA boards, tapeout slots, packaging, test boards and laboratory equipment.

Configuration control is essential. Tie each reported result to a source-code/RTL commit, tool-flow version, constraint set and technology/library configuration. Archive scripts and logs where permitted. If proprietary files cannot be archived, preserve hashes, version identifiers or configuration summaries that allow the experiment to be traced.

Agree which results must exist before the thesis can be submitted and which are optional stretch goals. Tapeout and silicon bring-up should not silently become an uncontrolled single point of failure.

15. Research plan: map each claim to an evidence stage

Write the research question, baseline, metrics and evidence stage before implementation expands. For each claim, state whether evidence will come from behavioural simulation, RTL simulation, FPGA, synthesis, post-route sign-off or measured silicon.

This evidence ladder prevents accidental overclaiming. A latency result from RTL simulation may support an architectural comparison but not a final silicon-frequency claim. A post-route timing report is stronger physical evidence but still not measured silicon.

Plan repetitions and uncertainty where tool randomness, workload variation or physical measurement can change results. Keep exploratory optimisation separate from the final evaluation so the test condition is not repeatedly tuned until it looks favourable.

16. Confidential PDKs, EDA tools, IP and public-thesis rules

SoC work often uses assets that cannot be published: foundry PDKs, standard-cell libraries, EDA licences, commercial IP, company RTL, timing models or confidential specifications. Tampere’s thesis is nevertheless a public academic document.

Design the research so the public manuscript can explain the method and support the conclusions without exposing restricted assets. Use abstracted block diagrams, public parameter summaries and non-confidential result tables where appropriate. Do not copy licence-controlled library data or proprietary source into the thesis.

If a company wants additional confidential engineering detail, keep that material outside the evaluated public thesis and agree the boundary early with the supervisor.

17. AI use in System-on-Chip Design work

Tampere permits AI use within its current study guidance, but the student remains responsible for the work. AI-assisted code, HDL, debugging suggestions, literature summaries or language editing must be treated as assistance, not verified engineering truth.

Test generated code and check hardware assumptions against datasheets and actual measurements. Do not trust invented register names, protocol requirements or citations. Follow acknowledgement requirements when AI materially contributes.

Never paste company code, credentials, unpublished hardware details, personal data or restricted datasets into an AI service unless the applicable rules permit it.

18. Writing the thesis while engineering continues

Start writing before the prototype is finished. Maintain a design-decision log, version table, experiment plan and results index. Record failed approaches when they affect the final method or reveal limitations.

Separate requirements, implementation and evaluation chapters conceptually. Readers should be able to tell what the system was supposed to do, what was actually built, how it was tested and what the evidence supports.

Use figures strategically: architecture diagrams, timing diagrams, state machines, measurement setups and experiment flows can communicate SoC behaviour more clearly than long prose, but every figure should support the argument.

19. Maturity test, Turnitin and final submission

The master’s degree requires the maturity test under Tampere’s current rules. For international master’s students, the thesis abstract normally serves as the maturity test at MSc stage under the current Technology guidance, while individual language-history situations can affect the route.

After supervisor permission, the final thesis goes through Turnitin originality checking. Similarity is not an automatic plagiarism verdict; it requires academic interpretation. Resolve citations, reused text and source attribution before final submission.

The final thesis is then deposited through Tampere’s process in Trepo. Protect time for administrative completion as well as technical work.

20. PDF/A, publicity and company confidentiality

Permanent electronic archiving requires a valid PDF/A file. Test conversion early enough to catch font, equation, figure or embedded-object problems.

The approved thesis is public. A company cannot make the evaluated thesis confidential simply because the project is commercially sensitive. Keep confidential details outside the public thesis and write the public document so that the academic reasoning and evidence remain assessable.

21. Assessment, examiner response and finality

System-on-Chip Design uses the Technology thesis 0–5 grading scale, not Architecture’s pass/fail exception. ITC.CEE.800, if included in your own plan, is a separate pass/fail course and does not determine the thesis grade.

Tampere uses formal examiners and the university assessment criteria. The examiners normally have 21 days after the Trepo/submission process, extended to 28 days where the applicable maturity-test route requires it. Students can respond to the proposed assessment under the current process, and an approved thesis is final rather than freely resubmittable.

22. Graduation planning

A technically finished device is not the same as an approved degree. Work backwards from the desired graduation date through supervisor review, final tests, writing, Turnitin, PDF/A, Trepo, examiner time and the separate graduation application.

Leave margin for hardware failures and component delays. The final weeks should not depend on receiving a new PCB revision or fixing a fundamental firmware architecture issue.

23. Final System-on-Chip Design checklist

Before starting, verify the current STEM-JPY placement in Sisu, the 30 ECTS Technology thesis, supervisor, thesis topic and current seminar/course registration. Do not convert the STEM-JPY “at least 120 ECTS” label into an invented 150-credit degree, and do not assume ITC.CEE.800 is compulsory without your current study-plan evidence.

Freeze the research question, baseline, workload, metrics and evidence stage. Track RTL/software commits, EDA/tool versions, PDK/library context and constraints. Distinguish simulation, FPGA, synthesis, post-route sign-off and measured-silicon evidence. Build tapeout and lab contingencies before they threaten graduation.

Before submission, remove confidential material, verify every technical claim against the exact configuration that produced it, complete the maturity requirement, follow Turnitin, create valid PDF/A, submit through Trepo and complete the separate graduation steps.

The strongest SoC thesis is not the one that touches every design stage. It is the one where a bounded chip-design question, a controlled implementation flow and an appropriate evidence level support conclusions without overstating what simulation, sign-off or silicon actually demonstrates.