# ucr-eecs168-lab is a VLSI course delivered as a schedule in a repository > The EECS168 lab repository at UC Riverside is the working surface for an introductory VLSI design course, with one directory per lab covering schematic capture, layout, parasitic extraction, hierarchical design and RTL synthesis, and a README that carries the schedule, the points and the policies. It is a course artefact rather than a software project, and the README says so. **sheldonucr/ucr-eecs168-lab** — The lab schedules for EECS168 at UC Riverside - Repository: https://github.com/sheldonucr/ucr-eecs168-lab - Stars: 594 · Forks: 33 - Language: Verilog - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/sheldonucr-ucr-eecs168-lab ## A course schedule that happens to live on GitHub The ucr-eecs168-lab repository is described as the lab schedules for EECS168 at UC Riverside, and the course it belongs to is an introduction to VLSI design. The repository is the front door to the course rather than a project with an end user, and the README says that every discussion and question and answer happens on the repository page itself, with students asked to use GitHub rather than email for questions to the teaching assistants, the exception being matters of a confidential nature such as grading. That is a deliberate choice, and it has a consequence for anyone reading the repository later: the questions that students asked, and the answers, are part of the historical record, which makes it a better archive than a course website would be. The structure is a directory per lab, from lab0 through lab4, and the README carries the schedule that maps those directories onto the term. There is no code to install, no package to consume and no licence to check for redistribution, and the repository is a good example of GitHub being used as a course platform rather than as a code host. ## The schedule runs ten weeks and four reports The lab schedule table runs from week one to the final week, with a gap in week seven when there is no new assignment and a lab work week instead, and no lab in week ten and the final week. The first entry is a pre-lab, an engineering account checkup and a Linux system basics session, which is a good indicator of the level the course assumes. Four lab reports are required, and the total score is one hundred, with the reports worth twenty, twenty five, thirty and twenty five points, so the weights are front loaded towards the later, more substantial work. The delivery rules are strict in a way worth reading closely. Labs must be finished at the given time, each lab report is due on the student's own lab day, with the exception of the fourth, and a report is due at the beginning of the lab, so the work has to be finished before the session in which it is handed in. The student has one week after the lab to produce the report. The README is emphatic that all required deliverables must be included in the report, which is the kind of sentence that only appears in a document read by students who have lost marks for exactly that. ## The toolchain is the actual syllabus What makes this course interesting to read from outside is the sequence of commercial tools it teaches, because that sequence is the standard flow for a physical design course. Week two introduces Synopsys schematic design with the Galaxy Custom Designer and a pre-simulation step with HSPICE. Week three moves to layout design with the same schematic tool, then a design rule check and a layout versus schematic verification, which are the two checks that catch a mismatch between what you drew and what you built. Week four adds post-simulation with parasitic extraction using HSPICE, and the first hierarchical integrated circuit design, with a ring oscillator as the target. Week five and six take the hierarchy further with a one bit full adder without hierarchy and then a four bit full adder using it, and week eight and nine move to RTL synthesis with Design Compiler, IC Compiler and PrimeTime, ending with Euclid's algorithm for greatest common divisor as the target circuit. The progression from transistor level to hierarchical schematic to register transfer level synthesis in one term is the whole point, and the targets are chosen so that each stage has a verifiable output. ## Attendance, lateness and the integrity board Three policies sit alongside the schedule, and they are short enough to quote without distorting them. Attendance is not mandatory if the lab was finished before the lab session, which is a sensible rule for a lab that runs to a fixed schedule. Late submission of a lab report carries a fifty percent penalty, which is steep enough to make the one week reporting window meaningful. The cheating policy is the most serious, because it goes beyond the classroom. Each lab report should be individual even where students are allowed to pair on the design and the programming work, and the instructor states that if cheating on the report is found, no credit is given for that lab and the case is forwarded to the academic integrity board at the university. That separation between pairing and individual reporting is the detail most courses state and few enforce explicitly, and putting it in the repository rather than in a syllabus means it travels with the course. ## What the repository tree actually contains The top level listing is sparse, with the README and the five lab directories and nothing else of note, which is what a course repository looks like when the labs are the assignments themselves rather than shared code. The directories are named lab0 through lab4, and the schedule table links into them, so each one holds the tutorial or lab material for the stage it covers, with the week three and week four rows pointing at the same lab3 directory and the week eight and nine rows at lab4, because those weeks continue the same design rather than starting something new. The primary language of the repository is recorded as Verilog, which fits a course that ends in RTL synthesis and a final target of a greatest common divisor algorithm, since that is the kind of circuit a student would write in hardware description and then synthesise. There are no GitHub releases, no licence file, and the changelog discipline is the commit log, which for a course means the history of the term. ## Maintenance is a term by term affair The repository listing reports no licence identifier, which is consistent with a course handout rather than a distributed package, and there are no GitHub releases, so there is nothing to version beyond the branch. The last push was on 2026-10-06, so the schedule is current with the term in progress, and the schedule it carries includes a pre-lab on engineering account checkup and Linux system basics, the kind of administrative entry that changes every year. For anyone outside the class, the useful question is how to use this material honestly. The tools it references are commercial and licensed, so reproducing the labs means either having access through a university or not reproducing them at all, and the README makes no attempt to work around that. The repository is therefore best read as a curriculum document, a description of the order in which an introductory VLSI course teaches a specific commercial toolchain, with the policies that surround it. For an instructor setting up a similar course it is a useful reference, and for a student it is the authoritative statement of what is due and when. ## Conclusion ucr-eecs168-lab is worth reading as a worked example of how a hardware design course is sequenced, since the schedule shows the order in which a student meets the toolchain, from schematic capture through layout and extraction to synthesis, and it names the commercial tools the assignments assume. It is not a tool you can adopt, and it will not help anyone outside the class, since the contents are the exercises and the schedule rather than reusable code, though the repository tree does show a Verilog oriented course given the primary language. Verify three things before you rely on it for anything: that the schedule still matches the course as it is being taught, since the last push was on 2026-10-06 and the repository tracks term by term, that the commercial tool licences are available to the students who need them, and that the point weights and due dates in the README match what the instructor has said, since the README is the only statement of them. The licence is not stated in the repository listing and there are no GitHub releases, so this is course documentation rather than a distributed package. ## FAQ ### What is the ucr-eecs168-lab repository? It holds the lab schedules and materials for EECS168, an introduction to VLSI design course at UC Riverside, with one directory per lab from lab0 to lab4 and a README carrying the schedule, the point weights and the course policies. ### Which tools does the EECS168 lab course teach? The schedule moves through Synopsys Galaxy Custom Designer for schematic and layout design, HSPICE for simulation and parasitic extraction, design rule check and layout versus schematic verification, and then Design Compiler, IC Compiler and PrimeTime for RTL synthesis, with designs including a ring oscillator, one bit and four bit full adders and Euclid's GCD algorithm. ### How are the EECS168 labs graded? Four lab reports are required and the total score is one hundred, with the reports worth twenty, twenty five, thirty and twenty five points. Labs must be finished at the scheduled time, a report is due at the beginning of the lab, and a late report carries a fifty percent penalty. ### What is the policy on pairing and on cheating in EECS168? Each lab report must be individual even when the design and programming work is done in pairs, and if the instructor finds students cheating on a report, no credit is given for that lab and the case goes to the academic integrity board at UCR. Lab attendance is not mandatory if the lab was finished before the session. ## Sources - [Issues](https://github.com/sheldonucr/ucr-eecs168-lab/issues) - [README](https://github.com/sheldonucr/ucr-eecs168-lab/blob/master/README.md) - [sheldonucr/ucr-eecs168-lab on GitHub](https://github.com/sheldonucr/ucr-eecs168-lab) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sheldonucr-ucr-eecs168-lab