Session01

Environment Setup¶

Session 1: Accessing the Microelectronics Tools¶

I started by accessing the Fab Futures platform and launching the microelectronics container.

The platform provides the connection details required to access the environment, including IP address, port, and password.

Connecting via VNC¶

To enter the environment, I used the browser-based VNC viewer by opening the provided IP and port.

After entering the password, the system granted access to the remote desktop.

Linux Environment¶

Once connected, a Linux desktop environment appeared with all the required tools pre-installed.

This environment is where all simulations and development tasks are executed.

Exploring the Workspace¶

I navigated to the /foss/examples directory, which contains sample projects and documentation for getting started.

I also opened the QUICKSTART.md file to understand the workflow and available commands.

Key Insight¶

This step confirms that the development environment is correctly configured and ready for running simulations and hardware design tasks.

Running Simulations¶

Opening the Terminal¶

From the /foss/examples directory, I opened a terminal to execute the simulation commands.

This allows direct interaction with the simulation environment.

Running the Fortune Simulation¶

I first executed the fortune teller simulation:

bash
make sim-fortune

The simulation compiled and executed correctly, generating output messages and confirming that the testbench ran successfully.

Viewing Waveforms with GTKWave

To analyze the signals generated during the simulation, I opened the waveform file:

gtkwave fortune_teller_tb.vcd

Signal Analysis

After selecting relevant signals from the left panel, I was able to visualize the system behavior over time.

This includes signals such as:

clock (clk) reset (rst_n) input/output data

These waveforms are essential for understanding how the digital system evolves over time.

Data Representation

GTKWave allows different data formats for better interpretation of signals.

Changing between binary, decimal, or signed representations helps analyze data more clearly.

Running Additional Simulation (Synth Example)

I also ran another simulation example:

make sim-synth

This simulation produces frequency outputs, confirming that the design behaves as expected under different conditions.

Dice Simulation

Finally, I tested another example:

make sim-dice

Key Insight

These simulations confirm that the toolchain is working correctly and demonstrate how digital systems can be tested and verified before hardware implementation.

Editing and Customizing a Design¶

Exploring the Verilog Code¶

I opened the fortune_teller.v file to understand how the system works internally.

The code defines a digital system that: - receives inputs (button, clock, reset) - processes data using internal logic - sends output through UART

Understanding ROM-Based Data¶

Inside the module, I analyzed how messages are stored using ROM.

The system stores characters as ASCII values inside a memory array:

reg [7:0] rom [0:159];

Modifying the Design

I created a copy of the original project to safely modify it:

cp -r fortune_teller /foss/designs/my_fortune_teller cd /foss/designs/my_fortune_teller

Then I edited the file using:

gedit fortune_teller.v

This allowed me to customize the stored messages and experiment with the design.


Running the Modified Design
After editing, I compiled and executed the design:

iverilog -Wall -g2012 -I/foss/examples/lib -o test.vvp fortune_teller.v fortune_teller_tb.v vvp test.vvp ```

Conclusion¶

In this session, I successfully set up the development environment, executed simulations, analyzed signals, and modified a Verilog-based design.

This provided a solid foundation for understanding how digital systems are described, simulated, and verified before hardware implementation.