EECS151 Tapeout Decal Website

EECS151 Tapeout is a Decal (student-run course) giving a hands-on, end-to-end experience in SoC design and implementation culminating in a tapeout.

Students with a background in the fundamentals of digital design and VLSI CAD tools (EECS151 + ASIC lab) will learn how to use the Chisel hardware description language and Chipyard (an agile hardware design framework) to integrate their EECS151 ASIC core or a custom IP block of their own design into a full-scale System-on-Chip (SoC). While covering the basics of agile SoC design concepts and methodology, the course is primarily a hands-on experience. One (or more, depending on student interest) class SoCs are planned to be taped out in the open-source Skywater 130nm process at the end of the semester. Extra chip area is available for motivated students with unique, large-scale projects.

The course aims to give all students hands-on experience in every step of the SoC design process from system-level design (interfaces, modular decoupling), to toplevel integration and physical design with commercial CAD tools though Berkeley’s Hammer tool. Students will participate in a class project consisting of one or more physically realized and fabricated SoCs in the open-source Skywater 130nm process node. Student contributions to the designs may range from a chipyard-integrated version of their EECS 151 ASIC core to custom accelerators or off-chip peripheral interfaces. It is emphasized that while multiple students may collaborate on a single SoC (or even within a module), every student will receive hands-on experience with the full tapeout process, from system architecture to GDSII signoff.

This course spans 13 weeks. Class meets for two hours once a week. Each class will generally consist of a short mini lecture, overview of project status, and check-ins with each team on milestones and obstacles. Students are expected to spend a bit more time each week outside of class time working on their project. The semester will culminate in chip tapeout through Efabless’ chipIgnite, student presentations, and a class poster.

This website was made with the CS 161 Template Website: ![The Latest Version]

*Create new calendar*

• Name: [CS188 SP25] Website or similar
• Description: blank is fine
• Time zone: GMT-07:00 Pacific Time - Los Angeles
• Click Create calendar

Now go to _data/calendar.yml:

• Follow the steps in that file to fill out the four Google Calendar fields.
• Follow the steps in that file to update remove_prefix.
• You probably do not need to touch categories.

Populate some Google Calendar events to check that it works (using lecture below as an example):

• Back to https://calendar.google.com
• Uncheck everything except [CS188 SP25] Website in the sidebar
• Create the lecture calendar event
• Title: [CS188 SP25] Lecture
• Location: Dwinelle 155 or whatever the room on https://classes.berkeley.edu is
• Note: You want Location filled in, but Room can be blank
• Click More options
• Replace Does not repeat with Custom
• Fill in your lecture times, e.g. every Tu/Th, ending on May 5, 2025
• Save, and see if the event appears on the website (if not, you did something wrong, so go back and fix it)

Once the calendar is set up, you can populate Google Calendar with events throughout the semester, and they'll sync on the website.

Staff

Updating the staff page happens in the _staffers folder. Make one .md file per member of course staff, following the template provided.

The documentation (and some extra configuration) lives in _data/staff.yml.

Compressing staff images: Please don't put enormous 4096x4096 staff images in the website repo and force staff/students to load those every time.

Warning

Skipping this step may lead to substantially longer load times, and a much larger Git repository.

Our recommended way to compress images is with the script below, which relies on ImageMagick, a command-line image manipulation program which supports Windows, MacOS, and Linux. It automatically resizes each image, and saves them as a .webp. If you do not wish to use ImageMagick, the same thing can be accomplished manually using GIMP, Photoshop, or any other image editor.

There is a different script for each common shell. If you do not know which shell you are using, you can type echo $0 into your terminal to find out.

Do this before committing them into the repo (otherwise the large image just ends up in the Git history and defeats the point). Make sure to remove the old files, since the command does not do this for you.

BASH Script

shopt -s nullglob
for i in *.{png,PNG,gif,GIF,heic,HEIC,jpg,JPG,jpeg,JPEG,jfif,JFIF}; do magick "$i" "${i%.*}.webp"; done
for i in *.{WEBP}; do mv "$i" "${i%.*}.webp"; done
mogrify -resize '512x512^>' -gravity center -crop '512x512+0+0' -strip *.webp
shopt -u nullglob

ZSH Script

setopt CSH_NULL_GLOB
for i in *.{png,PNG,gif,GIF,heic,HEIC,jpg,JPG,jpeg,JPEG,jfif,JFIF}; do convert "$i" "${i%.*}.webp"; done
for i in *.{WEBP}; do mv "$i" "${i%.*}.webp"; done
mogrify -resize '512x512^>' -gravity center -crop '512x512+0+0' -strip *.webp
setopt NOMATCH

Other

If you are using a shell like fish which does not support complicated globbing, your best bet is just to break into bash temporarily.

bash -O nullglob -c "for i in *.{png,PNG,gif,GIF,heic,HEIC,jpg,JPG,jpeg,JPEG,jfif,JFIF}; do convert '$i' '${i%.*}.webp'; done"
bash -O nullglob -c "for i in *.{WEBP}; do mv '$i' '${i%.*}.webp'; done"
mogrify -resize '512x512^>' -gravity center -crop '512x512+0+0' -strip *.webp

Updates Throughout Semester

Syllabus

To edit the syllabus (the big table on the homepage), follow the instructions in the relevant file. No other files should need to be edited.

• _data/lectures.yml
• _data/readings.yml
• _data/homeworks.yml
• _data/projects.yml
• _data/labs.yml

Weekly Announcements

To add a new weekly announcement, just add a new Markdown file in _announcements. See the sample files in that folder for examples.

The homepage defaults to showing the most recent announcement.

New Pages

When making a new Markdown page (e.g. a new project spec), you can use Jekyll front matter to configure the page.

We suggest using layout: page for all your pages. We currently don't support other layouts.

Just the Docs has many built-in front matter features you can use:

• Ordering Pages
• Excluding Pages
• Page Levels
• Toggling a list of child pages at the bottom of the page

Note that we are on Just the Docs v0.10.1, so those "New (v0.10.0)" tags are relevant to this repo.

Additions on top of JTD

Instead of the JTD Built-in Callouts, we have provided the Alerts implementation from SensEdu with some additional configuration options. By default, you have access to the following Alerts: NOTE, TIP, IMPORTANT, WARNING, CAUTION, and an unlabeled alert (ALERT).

To use Alerts, append {: .NAME } to the line above the message you'd like to place into an Alert. For example, to make a Tip Alert:

{: .TIP }
This is a Tip Alert!

If you need a multi-line Alert, you can wrap your content in a blockquote:

{: .TIP }
> This
> 
> is a multi-line Tip Alert!

If you are fine with the default colors (blue, green, purple, yellow, or red) but require a custom message, you can define a custom callout in _sass/custom/custom.scss by using a mixin. The mixins available are color-alert($name, $title) (where color is replaced with a color from the list above).

For example, if you want a blue alert titled "Story", put this in _sass/custom/custom.scss:

@include blue-alert(STORY, "Story");

And do this to display an alert titled "Story":

{: .STORY }
This is a custom blue alert!

Not recommended unless you know what you're doing: We also provide an alert($name, $foreground-color, $background-color, $title) if you require a custom color for any reason. To use this mixin, you should edit wider.scss and dark-wider.scss in order to make sure the colors are accessible in both light and dark mode.

If you want to have an alert with a customizable title, you can leave the $title argument as null. This is done by default for the pre-defined ALERT option. In this case, the following syntax will allow you to set whatever title you want on a per-alert basis:

{: ALERT }
> Alert Title
>
> Alert Body

We also have some custom front matter variables in this template:

hide_right_toc:

• By default, we render a table of contents on the right side of the page which is automatically generated based on the headings in the markdown file, and has scrollspy enabled.
• When hide_right_toc: true, we skip rendering that right table of contents.
• When hide_right_toc is any other value (e.g. blank or not in the front matter), then we render the right table of contents.
• The Right TOC does not look good with too many headings. The third-party scrollspy that we use doesn't work well if your Right TOC is too long. If you have too many headings, consider decreasing toc_max_heading to hide some of them from the right TOC (see below).

hide_content:

• When hide_content: true is set on the current page or ANY of the current page's ancestors, we render the message "This page has not been released yet" and we do not render the contents of the page.
• When hide_content is a non-true value (anything but true) on the current page and ALL of the current page's ancestors, we render the page's content as usual.
• In other words, hide_content values are inherited from parent to child. If a parent has hide_content: true, all of its children, grandchildren, etc. will also not be rendered, regardless of their hide_content values. The only way for a page to render is if the page itself and all ancestors do not have hide_content: true.
• See "Page Levels" above for what we mean by a page's ancestors.
• This can be useful if, for example, you have a project spec that exists in your repo, but you don't want students to find the spec on the website yet. Also, if your projects are organized into parent/child pages, then hiding the parent page will also hide all children page.
• Edit _layouts/page.html if you want to change what the message says, or if you want to change this behavior.
• Disclaimer: This feature involves some cursed code in _includes/check_ancestors.html, and may not always work as intended.

unreleased_warning:

• Basically the same as hide_content above, but instead of replacing the contents with a message, this feature simply adds a warning "This page is in an unreleased state." to the top of the page.
• When unreleased_warning: true is set on the current page or ANY of the current page's ancestors, we render the warning.
• When unreleased_warning is a non-true value (anything but true) on the current page and ALL of the current page's ancestors, we don't render the warning.
• In other words, unreleased_warning values are inherited from parent to child. If a parent has unreleased_warning: true, all of its children, grandchildren, etc. will get the warning rendered, regardless of their unreleased_warning values. The only way to make the warning go away is if the page itself and all ancestors do not have unreleased_warning: true.
• Edit _layouts/page.html if you want to change what the message says, or if you want to change this behavior.
• Disclaimer: This feature also involves some cursed code in _includes/check_ancestors.html, and may not always work as intended.
• Note: hide_content and unreleased_warning are implemented independently (see _layouts/page.html) and it is possible to mix-and-match them. Some pages could have the warning and others could be totally hidden. You could even have a page with both set to true, so that the contents are hidden and both the hidden message and unreleased warning are rendered.

toc_min_heading:

• An optional parameter that determines the minimum depth heading to capture in the right TOC for that page
• Does nothing when hide_right_toc: true
• When unset, defaults to the value of toc_min_heading in _config.yml

toc_max_heading:

• An optional parameter that determines the maximum depth heading to capture in the right TOC for that page
• Does nothing when hide_right_toc: true
• When unset, defaults to the value of toc_max_heading in _config.yml

toc_collapse_depth:

• An optional parameter that determines the collapse depth of the right TOC for that page
  • All headings below the collapse depth do not appear on the TOC by default, but when they are scroolled into view on the page, they uncollapse in the sidebar.
• Does nothing when hide_right_toc: true
• When unset, defaults to the value of toc_collapse_depth in _config.yml
• Note: toc_collapse_depth: 1 (showing only h1 headers) doesn't work and leads to the same behavior as toc_collapse_depth: 2 (showing h1 and h2 headers).

When writing pages, we recommend a single h1 header with the page title, and then h2-h6 headers for your content. Also, headers should be continuous, e.g. below h2, you should use h3, not h4 (then under h3, you can use h4). Using other header structures can lead to undefined TOC behavior.

# Title of your page

The h1 title of your page should be identical to the title in the front matter.
Some minor abbreviation (e.g. "proj" vs "Project") might be okay.

## Setup

### Windows

Blah blah blah.

### Mac/Linux

Blah blah blah.

## Your Task

Blah blah blah.

#### Don't do this

The header below h2 should be h3.

### Do this instead

And if you want more headers under the h3, then you can use h4.

#### A sub-sub section

Nesting too deeply may cause long TOCs (which render badly), so we discourage it.

## Submission

Blah blah blah.

# Don't do this

The only h1 header should be the title at the top of your page.

Templating

Jekyll allows you to write Markdown pages that reference variables defined in _data files.

For example, in proj1_assignment.yml we listed assignment-specific attributes, and used them in proj1/index.md. This allows you to re-use project specs across semesters, without worrying that you're forgetting to update a submission link or due date.

Another example of data is in _data/exams.yml, which lists exam dates that get used in exam.md.

Another example of data is in _data/faqs.yml, which lists next-semester dates that get used in resources/faqs.md.

Customization

Warning

Some competency in Jekyll and HTML required for this step. We don't recommend attempting this unless you know what you're doing.

If you want to change the layout of the syllabus (the big table on the homepage), you will need to manually edit some more obscure files.

Syllabus Files

Files used to build the syllabus (each file has more documentation):

• _includes/lecture.html has the code for rendering a single box in the "Lectures" column, using a single entry from _data/lectures.yml.
• _includes/readings.html has the code for rendering a single box in the "Readings" column, using a single entry from _data/lectures.yml (lectures and readings share a data file).
• _includes/discussion.html has the code for rendering a single box in the "Discussion" column, using a single entry from _data/discussions.yml.
• There is just a single piece of code for rendering assignments, used in _includes/homework.html, _includes/lab.html, and _includes/project.html. For simplicity, we suggest keeping these files all identical. Each assignment box is rendered using a single entry from _data/homeworks.yml, _data/labs.html, and _data/projects.html, respectively. The usage of these data files is identical (since the code for rendering all three is the same).
• _includes/syllabus.html actually builds the table by using all of the other _includes files to build individual boxes, and then putting those boxes together. It also accepts data from _data/week_extra.yml (see that file for more documentation).

Customizing Syllabus

This section some possible changes you might want to perform, and how to implement them.

Add a separate readings column? (by default, readings appear in the Lectures column)

• In _includes/syllabus.html, uncomment the Readings header and the code for rendering the column (Ctrl+F the word "uncomment" for the two places you need to edit).
• Edit _data/syllabus.yml to configure your new Readings column. The config variables are already there, they just go unused by default (when there's no Readings column).

Add a new assignments column? (e.g. for labs or vitamins)

• In _includes/syllabus.html, uncomment the Labs header and the code for rendering the column (Ctrl+F the word "uncomment" for the two places you need to edit).
• In _includes/syllabus.html, you can rename the header you just uncommented - right now it's Labs but it can be whatever else. The other variables can still be called lab, e.g. "lab_element", and they won't show up on the website, so it's probably easiest to leave them unchanged.

Add a new column for something else? (easier) (e.g. a second readings column)

Caution

If you're using extra in every cell, you should make sure that the text in each cell is distinct, for accessibility reasons. (e.g. don't make every link say "Slides")

• If you aren't already using the Labs column, the easiest way to add a new column is to repurpose the Labs column for your purposes.
• First, follow the two steps above (in the "Add a new assignments column") section. This enables the Labs column and renames the column header.
• Now, in labs.yml (which also doesn't need to be renamed), you can add data to feed into your new column, even if that data isn't an assignment.
• For example, you can use extra to put arbitrary Markdown in each cell, use nonumber to disable auto-numbering the cells, and use rowspan to control the size of each cell. See example below.

labs:
  - nonumber: true
    extra: |
      [How to make pancakes](https://www.example1.com)

      [How to make syrup](https://www.example3.com)
    rowspan: 1
  - nonumber: true
    extra: |
      [How to make waffles](https://www.example2.com)
    rowspan: 2
  - nonumber: true
    extra: |
      [How to brownies](https://www.example4.com)
    rowspan: 1

Add a new column for something else? (harder) (e.g. adding both a Labs and a Vitamins column)

Caution

You should be manually validating WCAG AA accessibility of your new code. If you're not sure how to do these steps, try the easier approach above.

Warning

Adding too many columns will make the table hard to read, especially on smaller screens (e.g. mobile).

• In _includes/syllabus.html, add a new header near the top of the file.
• In _includes/syllabus.html, below the headers, initialize new counters, e.g. vitamin_index, vitamin_rowspan, vitamin_number, default_vitamin_number.
• In _includes/syllabus.html, the second half of the file has mostly-identical codeblocks for rendering each column (e.g. look for "Render the homework column."). Copy-paste this codeblock for the new column in the appropriate place (e.g. if your column is between Homework and Project, then your new codeblock should be between the homework-rendering and project-rendering codeblocks).
• Don't customize the codeblock in _includes/syllabus.html. Instead, make a new includes file, e.g. _includes/vitamin.html, and write your custom code for rendering a single box here. Look at other files like _includes/homework.yml for inspiration.
• Make a new data file, e.g. _data/vitamins.yml, for feeding data into your new includes file. Look at other files like _data/homeworks.yml for inspiration.

Rearrange columns?

• In _includes/syllabus.html, reorder the headers near the top of the file.
• In _includes/syllabus.html, the second half of the file has mostly-identical codeblocks for rendering each column (e.g. look for "Render the homework column."). Reorder these codeblocks to match your desired order.

Change the discussion types? (e.g. add a third type of discussion)

• By default, we support up to 3 types of discussions. Each type can link to worksheet, solutions, videos, and slides, and there's no inherent difference between the types (they share the same rendering code).
• In _data/discussions.yml, update discussion_filename_bases with the names of your discussion types.
• It's okay if the variables don't match, e.g. bridge_name: Mega-Discussion is fine. The variables don't render onto the website. If the variable names really bother you, carefully change the variable names in both _data/discussions.yml and _includes/discussion.html.
• See _data/discussions.yml for instructions on how to render each type of discussion.
• If you want more than 3 types, or you want to change what gets rendered (e.g. make it say "Recording" instead of "Video"), see the question below this.

Change the way lectures/discussions are rendered?

• All the code for rendering a single lecture box and a single discussion box are in _includes/lecture.html and _includes/discussion.html, so you should only need to modify those two files.

Change the way assignments are rendered?

• All the code for rendering a single assignment is in _includes/homework.html. For simplicity, the other assignment files (_includes/project.html and _includes/lab.html) are identical. You should only need to edit these files.
• These files are already made to be fairly extensible (e.g. parts for rendering any list of links, and extra for any arbitrary Markdown), so you may be able to achieve the desired behavior without changing these HTML files.

Render multiple lectures/discussions/assignments on a single day?

• If you only need this once (e.g. there's only one day all semester with two lectures), the easiest solution is probably to use extra_days in syllabus.yml. The day will render twice in the "Date" column. This is much easier than the day_rowspan alternative below.
• If you only need this once, a solution is to use the extra field in lectures.yml. If the extra lecture has the same formatting (e.g. linking to Slides/Recording) as all the others, this is less recommended (see the note about aria-labels in the Accessibility section of this documentation). But if you want custom Markdown on your extra lecture, this could be a good option. This is also easier than the day_rowspan alternative below.
• If you need this repeatedly (e.g. there's two lectures on every day), then change day_rowspan in syllabus.yml. Note that all the other rowspans must now be calculated relative to your updated day_rowspan.
• Example of day_rowspan usage: Suppose you have two lectures on each of MWF, and two discussions per week. Then you want day_rowspan: 2 and default_lecture_rowspan: 1 so that two lectures get rendered per day. Since a week now spans 6 rows, you want discussion_default_rowspan: 3 so that two discussions are rendered per week.
• More generally, if you change day_rowspan to n, then you want to multiply every other default_rowspan by n to get the original table unchanged. But now you can get multiple rows per day by setting some rowspans to be less than n.
• The day_rowspan feature can be confusing so we don't recommend using it unless you know what you're doing. -->