Overview

Hi! This is the homepage of the Experimental Hardware Projects class taught at FSU Jena by the Scalable Data- and Compute-intensive Analyses lab and the Advanced Computing group. The class is still new: Let us know if you get stuck, stumble over errors or have any other feedback: ehp22@uni-jena.de

Lab

Due Date

Combinational Logic Design

04/17 (1.1 - 1.4)

Bubble Pushing and K-Maps

04/24 (2.3, 2.4, 2.6, 2.7)

Sequential Logic Design

05/01 (3.1 - 3.3)

Finite State Machines

05/08 (4.2, 4.3)

SystemVerilog

05/15 (5.2, 5.3)

Field Programmable Gate Arrays

05/22 (6.1), 05/29 (6.2)

Arithmetic Logic Unit

06/05 (7.1, 7.2), 06/12 (7.3), 06/19 (7.4, 7.5)

Stopwatch

06/26 (8.1, 8.2), 07/03 (8.3)

AArch64

07/10 (9.1, 9.2)

Single Cycle Processor

07/17 (10.1, 10.2)

Sessions

Day

Time

Location

Type

Mon

04:00PM - 06:15PM

3220, EAP2

Regular

Thu

10:00AM - 12:15PM

3220, EAP2

Regular

Fri

08:45AM - 11:00AM

3220, EAP2

Regular

Fri

12:00PM - 02:15PM

3228, EAP2

Open Lab,

Q&A

Public Holidays

Holiday

Date

Alternative

Karfreitag

Fri 04/15

Mon 04/11

Ostern

Mon 04/18

Fri 04/22, 08:45AM - 11:00AM

Himmelfahrt

Thu 05/26

Mon 05/23 or Fri 05/27 (both sessions)

Pfingsten

Mon 06/06

Fri 06/10, 08:45AM - 11:00AM

Literature

Submissions

Our class follows good software engineering practices. In short: Have a keen eye on the quality of your software!

Do the following:

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

  • Write testbenches for SystemVerilog modules and unit tests for software. Make it a habit to introduce these together with new features, this makes this requirement painless.

  • Take “issues” seriously, e.g., compiler warnings, and don’t take short-cuts: no hacks!

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

If not stated otherwise, the following deliverables have to be handed in for every submission:

  • 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 as PDF with no more than a single page addressing the respective submission. Briefly address individual contributions of each group member.

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 sub directory 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 May 15 2022. 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_22_05_15_bach_schiller;

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

  • Put our source code in submission_22_05_15_bach_schiller/src; and

  • Save our report in file submission_22_05_15_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_22_05_15_bach_schiller.tar.xz.

Hint

The following command creates the tarball for our running example:

tar -cvJf submission_22_05_15_bach_schiller.tar.xz submission_22_05_15_bach_schiller

Upload your tarball to Moodle. Every team member has to do this! In our example: Team Bach and Schiller is ready to submit submission_22_05_15_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.