Overview

Welcome! This is the site for the Computer Engineering class at Friedrich Schiller University Jena, taught by the Scalable lab. If you get stuck, spot errors, or have feedback, please let us know.

Communication

Our class has a separate Matrix room. Access information is shared on Moodle. Please use common sense when navigating the virtual space; for example:

  • You may use the room to ask questions.

  • You may use the room to discuss class-related topics with your peers.

  • Before the due dates, you may share lab solutions only with your direct teammates.

All files of the class, i.e. slides and recordings, are also available via a password-protected Nextcloud share. You can obtain the link and password via Moodle.

Artificial Intelligence

The use of artificial-intelligence (AI) assistants is allowed and encouraged. Use AI tools responsibly. Here are some good use cases:

  • Ask for help after attempting a task on your own and getting stuck for a while.

  • Discuss your solutions and ask for feedback on your code and answers.

  • Look up the meaning of errors and warnings (e.g., compiler errors).

Do not produce or submit “AI slop.” Do not paste entire tasks into a chatbot or submit the output as your solution.

Lab Rooms

_images/lab_room.jpg

Fig. 1 Lab room 3073, Campus Inselplatz.

Starting in the fourth week of the labs (11/03), all labs will take place in room 3073 at Campus Inselplatz. The room is equipped with workstations for hardware and software development. The machines run NixOS 25.05, and you’ll use the same login credentials as in the first weeks.

Note that you can only log in locally to the workstations. You cannot log in remotely via SSH. However, a single, dedicated machine, Kate, is reachable on the university-wide intranet. To transfer files from a workstation to your computer, follow two steps:

  1. Copy the data from the workstation to kate.inf-ra.uni-jena.de.

  2. Log in to Kate from your computer and download the data.

Keep in mind that there are strict rules in all lab rooms:

  • No food or drinks in the room. Keep bottles and snacks in your bag. Be careful not to drop your bottle if you take a sip outside the room (we’ve had incidents before).

  • Do not touch the monitors or the mini PCs: do not press any buttons or insert your USB sticks. If anything does not work, ask for assistance.

  • Handle all equipment with care, especially the keyboards and mice.

  • When leaving, roll your chair back under the table. The picture above shows you how this should look.

Sessions

Day

Time

Location

Type

Mon

12:15PM - 01:45PM

HS 250, FG 1

Lecture

Mon

04:00PM - 07:00PM

3073, CIP

Open Lab,

Q&A

Tue

12:15PM - 01:45PM

HS 250, FG 1

Lecture

Tue

04:00PM - 06:15PM

3073, CIP

Lab 1

Wed

04:00PM - 06:15PM

3073, CIP

Lab 2

Thu

04:00PM - 06:15PM

3073, CIP

Lab 3

Fri

08:30AM - 11:30AM

3073, CIP

Open Lab,

Q&A

Fri

12:00PM - 02:15PM

3073, CIP

Lab 4

Special Events

What?

Date

Comment

First day

Mon 10/13

No open lab

Reformationstag

Fri 10/31

No lab, no open lab

Dies Academicus

Tue 11/18

No lecture

Assignments

Week

Due Date

Mandatory Tasks

Optional Tasks

1

10/20

1.1, 1.2

–

2

10/27

2.2-2.5

2.1

3

11/03

3.1-3.3, 3.5

3.4

4

11/10

4.2, 4.3

–

5

11/17

5.1-5.3

5.4, 5.5

6

11/24

7

12/01

8

12/08

9

12/15

10

01/05

11

01/12

12

01/19

13

01/26

14

02/02

Literature

Submissions

Our class follows solid computer and software-engineering practices. In short: Pay close attention to the quality of your work.

Do the following:

  • Document your source code, especially modules and functions you introduce.

  • Write testbenches for SystemVerilog modules and unit tests for software. Introduce these alongside new features; this habit makes the requirement painless.

  • Take issues seriously (e.g., compiler warnings) and don’t take shortcuts: no hacks!

  • Test your code and user guides on the reference machine(s).

Deliverables:

  • Cover sheet with the full names of all group members!

  • Source code where required in the assignments. Respective source code documentation and tests are mandatory.

  • Project report (PDF) of at most one page addressing the respective submission. Briefly describe each group member’s contribution.

Use the following directory structure for every submission:

  • Name the root directory submission_<due_date>_<surname_1>_<surname_2>;

  • Save your cover sheet in file submission_<due_date>_<surname_1>_<surname_2>/cover.pdf;

  • Put all source code in the subdirectory submission_<due_date>_<surname_1>_<surname_2>/src; and

  • Save your report in file submission_<due_date>_<surname_1>_<surname_2>/report.pdf.

Now let’s go through an example. Assume that the due date for our submission is October 20 2025. The full names of the two team members are Johann Sebastian Bach and Friedrich Schiller. In this case we’d do the following:

  • Name the root directory submission_25_10_20_bach_schiller;

  • Save our cover sheet in file submission_25_10_20_bach_schiller/cover.pdf;

  • Put our source code in submission_25_10_20_bach_schiller/src; and

  • Save our report in file submission_25_10_20_bach_schiller/report.pdf.

Create an xz tarball from your root directory with the name submission_<due_date>_<surname_1>_<surname_2>.tar.xz. Once again, the two team members Bach and Schiller would name their file submission_25_10_20_bach_schiller.tar.xz.

Hint

The following command creates the tarball for our running example:

tar -cvJf submission_25_10_20_bach_schiller.tar.xz submission_25_10_20_bach_schiller

Upload your tarball to Moodle. Every team member must upload the file. In our example: Team Bach and Schiller is ready to submit submission_25_10_20_bach_schiller.tar.xz. Now, Bach logs in to Moodle and uploads the file. Further, Schiller logs in to Moodle and uploads the file as well.