UMPSA STEM Lab – Raspberry Pi IoT 2026

UMPSA STEM Lab has engineered a comprehensive, self-paced Internet of Things (IoT) curriculum centered around the Raspberry Pi Pico and MicroPython. Designed to transition beginners into capable hardware developers, this 11-activity framework bridges fundamental programming concepts with real-world wireless cloud telemetry and long-range hardware interaction.

Core Pedagogy: Self-Paced Mastery & True Digital Literacy

The UMPSA STEM Lab curriculum operates on two foundational principles: individual pacing and absolute code ownership.

The learning pathway systematically introduces hardware control, bus protocols, analog processing, and wireless telemetry.

 

1. Fundamentals & Digital Outputs

Students begin by interacting with basic General Purpose Input/Output (GPIO) pins.

      1. GPIO Control Defining output pins to control red, yellow, and green LEDs using MicroPython’s machine.Pin library.
      2. Timing & Iteration Implementing time.sleep(), for loops, and while True infinite execution loops to construct traffic light state machines.

 

2. Actuation & Input Logic

Moving beyond static outputs, the curriculum introduces dynamic control and user interaction.

      1. Pulse Width Modulation (PWM) Driving SG90 servo motors at 50 Hz, translating duty cycles (duty_u16) into precise physical horn positions and smooth sweep animations.
      2. Digital Inputs Configuring tactile push buttons and slide switches with internal pull-up resistors (Pin.PULL_UP).
      3. Conditional Logic Utilizing if/else structures to make real-time operational decisions based on pin states.

3. Display Integration & Shared Bus Architecture

As output demands grow beyond simple LEDs, multi-device communication channels are introduced.

      1. I2C Protocol Interfacing 0.96-inch OLED displays using the ssd1306 library over shared SDA (GP2) and SCL (GP3) bus lines.
      2. Sensory Data & Motion Connecting MPU6050 motion sensors on the same I2C bus using custom libraries (imu.py), formatting floating-point readings with round() and abs() to create tilt alert systems.

4. Analog Processing & Sensor Calibration

To measure continuous physical phenomena, students transition from binary digital signals to analog processing.

      1. Analog-to-Digital Conversion (ADC) Reading soil moisture levels using 16-bit resolution (read_u16()) on ADC-capable pins (GP26).
      2. Empirical Calibration Testing probes in dry air and saturated soil to establish customized numerical thresholds, converting raw voltages into accurate 0–100% moisture percentages.

5. Cloud Telemetry & Peer-to-Peer Wireless Protocols

The advanced modules transform standalone microcontrollers into connected IoT endpoints.

      1. Wi-Fi & Cloud Telemetry (Pico W) Connecting to 2.4 GHz Wi-Fi networks and establishing lightweight MQTT messaging with Adafruit IO. Students construct cloud dashboards with interactive toggle blocks to control physical board LEDs globally via sub/pub callbacks (set_callback, check_msg).
      2. Hardware UART & Long-Range Radio Configuring physical radio transceiver modules (Ebyte E70) via UART at 9600 baud. Students set mode pins (M0, M1, M2), reconfigure operating frequencies/channels across 410–441 MHz, and send encoded byte payloads over airwaves without requiring cloud infrastructure.

UMPSA STEM Lab – ESP32 MicroController IoT Programming 2026

The UMPSA STEM Lab 2026 ESP32 MicroController IoT Programming Module delivers a progressive, hands-on learning pathway that transforms beginners into proficient IoT developers using the ESP32 / ESP32-S3 microcontroller and the Wokwi online simulator. Designed around a project-driven curriculum, the module transitions systematically from basic circuit dynamics to cloud-integrated smart systems.

The Learning Journey: From Single Bits to Cloud Integration

Phase 1: Fundamental Electronics & Sensing – LED Output Control (GPIO, Digital High/Low, Delay Timing) | | – Analog Sensing (LDR Photoresistors, 12-bit ADC, Thresholds)

Phase 2: Visual Displays, Proximity & Motion | | – I2C Visual Output (Adafruit SSD1306 OLED Display) | | – Acoustic Ranging (HC-SR04 Ultrasonic Sensor & pulseIn) | | – Human Input & Motion (Potentiometers, Buttons & Servos)

Phase 3: Connected IoT & Cloud Data Systems | | – Cloud Telemetry (Blynk IoT Dashboard & Virtual Pins) | | – Automated Data Logging (Google Sheets via Apps Script) |

Phase 1: Digital Fundamentals and Environmental Sensing

Learners begin by building digital output foundations using the ESP32 DevKit. The lesson introduces GPIO pin initialization, constant declaration (const int), setting output modes with pinMode(), and delivering 3.3V logic signals using digitalWrite(pin, HIGH). Current-limiting 220 Ω resistors ensure component protection.

Building on basic outputs, Activity 2 introduces time-domain control. Students learn to toggle states using digitalWrite(pin, LOW) paired with delay() calls in milliseconds. The core concept highlights how loop() endlessly executes sequence steps to form repeatable hardware timing patterns.

Transitioning from binary outputs to continuous input monitoring, learners connect a 4-pin LDR (Light Dependent Resistor) module to ADC1 pin GPIO34.

      1. 12-bit Resolution Unlike 10-bit Arduino boards (0–1023), the ESP32 processes analog values across a 0–4095 scale.
      2. Serial Communication Data is transmitted back to the host via Serial.begin(115200) and monitored in real time using Serial.println().
      3. Decision Boundaries Activity 4 establishes conditional logic (if / else), using threshold values to trigger automated hardware responses based on ambient light changes.

Phase 2: User Interfaces, Acoustic Distance, and Precision Motion

Moving beyond simple LEDs, learners integrate a 0.96-inch SSD1306 OLED screen.

      1. I2C Protocol Communicates via two dedicated lines—SDA (GPIO21) and SCL (GPIO22)—at I2C address 0x3C.
      2. Graphics Libraries Implements Adafruit_SSD1306 and Wire.h to manage buffer clearing (display.clearDisplay()), cursor positioning (display.setCursor()), and screen updates (display.display()).

Activity 6 introduces the HC-SR04 Ultrasonic Sensor for spatial awareness:

        1. Trigger and Echo High-frequency sonic bursts are initiated via a 10 µs pulse on the TRIG pin (GPIO12) and timed via the ECHO pin (GPIO14) using pulseIn().
        2. Kinematic Conversion Distance in centimeters is calculated using sound velocity:
          • $$\text{Distance (cm)} = \frac{\text{duration} \times 0.034}{2}$$
        3. Proximity Triggers Threshold logic compares measured distances against target limits (< 40 cm or < 100 cm) to activate visual warning indicators.

Activities 7 and 8 unite analog and digital inputs to command physical motion:

      1. Dual Inputs: Combines an analog potentiometer knob (GPIO34) with a digital push button operating in INPUT_PULLUP mode (active LOW logic on GPIO25).
      2. Range Re-mapping: Uses map(potValue, 0, 4095, 0, 180) to translate 12-bit raw readings into servo rotation angles.
      3. Commanded Actuation: Incorporates the ESP32Servo library (servo.write(angle)) to trigger precise motor positioning upon button press events.

Phase 3: Cloud Telemetry, IoT Dashboards, and Data Logging

Activity 9 elevates physical projects to connected Internet of Things (IoT) applications. Leveraging Wokwi’s simulated Wi-Fi (Wokwi-GUEST), sensor data is streamed off-site:

      1. Blynk IoT Setup Configures Cloud Templates, Virtual Pins, and authentication tokens to display live readings on interactive web and mobile dashboards.
      2. Google Apps Script Bridge An HTTPS doGet(e) web app script intercepts incoming URL parameters and appends time-stamped entries to a live Google Sheet spreadsheet:
        function doGet(e) {
          var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("Sheet1");
          if (!e || !e.parameter.distance) return ContentService.createTextOutput("No distance received");
          var distance = parseFloat(e.parameter.distance);
          sheet.appendRow([new Date(), distance]);
          return ContentService.createTextOutput("OK");
        }

The final module activity completes the IoT feedback loop by demonstrating bi-directional communication. Instead of just sending data to the cloud, learners use Blynk Dashboard widgets to transmit control signals back to the ESP32 hardware, toggling actuators and indicators over the internet from anywhere in the world.

Core Competencies Developed

Curriculum Area Concepts & Key Technologies
Microcontroller Basics ESP32/ESP32-S3 pinouts, GPIO modes, internal pull-up resistors (INPUT_PULLUP)
Signal Types Binary digital I/O, 12-bit Analog-to-Digital Conversion (ADC, 0–4095)
Communication Standards Serial UART (115200 baud), I2C protocol (SDA/SCL)

Sensors & Actuators LDR Photoresistors, HC-SR04 Ultrasonic Sonar, Potentiometers, Servo Motors, SSD1306 OLEDs
Cloud & IoT Technologies Wi-Fi simulation (Wokwi-GUEST), Blynk Cloud Dashboards, Google Apps Script REST APIs

UMPSA STEM Lab – Edge Intelligence (Image Processing) on ESP32 2026

Deploying artificial intelligence directly on compact microcontrollers—often termed Edge Intelligence—represents a major leap in embedded engineering. This UMPSA STEM Lab module provides a hands-on roadmap for transitioning from basic software-based computer vision to standalone, hardware-integrated AI models capable of performing real-time image processing, feature extraction, and object classification on low-power ESP microcontroller hardware.

The Shift to Edge Intelligence

Traditional computer vision solutions rely on cloud servers or heavy laptop GPUs to process video streams. Edge Intelligence moves processing power directly to the physical sensor level. In this module, participants move beyond pre-packaged datasets to create, train, and deploy bespoke computer vision pipelines designed specifically for embedded micro-processors.

Image Processing & Data Engineering Discipline

A fundamental lesson of embedded machine learning is that an AI model is only as effective as the data used to train it.

Figure 1: The compact ESP32 camera board featuring an integrated 2 megapixel camera sensor and Wi-Fi capability.

The Thumbnail Test & Image Resolution

      1. Pixel Reduction Raw images captured by the sensor are downscaled to 96 x 96 pixel grayscale or RGB arrays.
      2. Visual Clarity Before training, images are evaluated via the “thumbnail test” to ensure visual features remain recognizable when shrunk to stamp-sized dimensions.

Essential Rules for Dataset Quality

        1. Single Variable Changes Change only one condition (angle, lighting, position) between consecutive photo captures to maximize information density.
        2. Background Separation Avoid shooting all target objects on identical surfaces. Otherwise, the model learns background cues rather than object features.
        3. Consistent Label Formatting Labels must follow strict naming rules (lower case, no spaces, e.g., red_chili) to prevent duplicate target classes.

3. Feature Extraction & Impulse Pipeline Design

Once images are collected and labeled, raw pixel values are mapped into numerical feature vectors inside Edge Impulse.

Figure 2: The four-block impulse design connecting input image data to digital signal processing (DSP) and neural network classifiers.

      1. Raw Image Preprocessing Images are normalized and structured into uniform dimensions.
      2. DSP Feature Generation Spatial characteristics (edges, textures, color distributions) are extracted, generating distinct visual clusters in 3D feature space.
      3. Classifier Training Neural networks process the extracted features to assign probabilities across classes.
      4. Inference Speed Real-time classification executes in approximately 1 ms per frame, enabling fluid live monitoring.

4. Bounding Boxes, Confidence Thresholds, and the “Nothing” Class

A key challenge in real-world vision deployment is handling unexpected inputs—a scenario highlighted by the “chili problem“.

Challenge Cause Embedded Solution
False Positives The model forces unseen objects into known classes. Add an explicit background or “nothing” class.
Fluctuating Predictions Minor shifts in lighting or tilt alter confidence scores. Apply confidence thresholds (e.g., ignore results below 0.80).
Spatial Localization Image classification lacks coordinate location. Implement bounding box object detection for region tracking.

5. Microcontroller Integration on ESP32 Hardware

The culmination of the module is flashing the trained impulse directly onto an ESP microcontroller processor.

Figure 3: Real-time classification outputs streamed over the Arduino Serial Monitor at 115200 baud.

Hardware Deployment Steps

      1. Firmware Setup Configure the Arduino IDE with necessary ESP32 board definitions and upload the custom collection sketch (ESP32_datacollection.ino).
      2. Port Selection & Cabling Ensure high-speed data cables are used, as charge-only cables will fail to establish COM communication.
      3. Network Configurations Connect via self-generated Wi-Fi access points (Route A) or local network infrastructure (Routes B/C).
      4. Serial Verification Initialize the Serial Monitor at 115200 baud and press the hardware reset (RST) button to verify initialization and monitor live inference logs.

6. Key Takeaways

Through this module, participants develop end-to-end expertise in embedded machine learning:

    1. Moving from cloud-dependent AI to standalone micro-processor execution.
    2. Mastering raw image preprocessing, feature extraction, and dataset hygiene.
    3. Deploying real-time computer vision models on low-cost hardware platforms.

Reconfigurable Electronics – Why BHE3233/BEL4553/ BTS4433 Are Your Tickets to the Semiconductor Design Industry

Hey everyone, and welcome to the blog!

If you’ve stumbled upon this page, chances are you’re trying to sort out your upcoming electives, or maybe you’re just looking for that elective subject that will make your engineering resume instantly stand out to recruiters.

Either way, here you are.

Today, let’s talk about why we named this space Reconfigurable Electronics and why three specific courses at the faculty—BHE3233, BEL4553, and BTS4433—are going to completely flip the way you think about hardware design.

What on Earth is “Reconfigurable Electronics”?

Back in the day, if you designed a digital chip and manufactured it, that was it. If you found a bug or wanted to add a new feature, you had to throw the physical chip away and spend millions of dollars building a new one from scratch. Static. Permanent. Expensive.

Enter reconfigurable electronics.

Imagine hardware that behaves like software. Instead of hardwiring circuits, you write code in a Hardware Description Language (HDL)—like Verilog—and flash it onto a piece of silicon called an FPGA (Field Programmable Gate Array). If you make a mistake, you don’t scrap the chip. You just tweak your code, re-compile, and reconfigure the chip in seconds. One minute the silicon is acting as a video processor, and the next minute it’s running an AI accelerator or an industrial CPU core.

How These Courses Bring Reconfigurability to Life

If you join us in BHE3233, BEL4553, or BTS4433, you aren’t just sitting in a lecture hall listening to theory. We have officially shifted these courses toward Project-Based Learning (PjBL), dropping the stressful written final exams completely.

Instead, you spend your semester directly interacting with reconfigurable hardware using the Altera DE10-Lite FPGA board. Here is the exact pipeline you’ll master:

      1. Code & Simulate (RTL Design): You’ll learn to describe complex digital logic using Verilog HDL.

      2. Optimize: You’ll run synthesis and handle Static Timing Analysis (STA) to make sure your designs run at blazing industry-standard speeds.

      3. Deploy on Silicon: You actually download your architecture right onto physical FPGA silicon and watch your code control real hardware.

 

Instead of building simple basic gates, you’ll get the opportunity to design advanced systems—like RISC-V processors, custom CPU architectures, cryptographic hardware accelerators, or digital communication nodes. You change the code, and the chip instantly reconfigures to match your imagination.

Why “Reconfigurable Electronics” Belongs on Your CV

Let’s be real for a second: the semiconductor and chip design industry is absolutely booming right now, and competition for top graduate jobs is fierce.

When a recruiter from a top chip design company scans a stack of resumes, they see a lot of the same things: standard project reports, high GPAs, and generic programming languages.

But when your resume says

      1. Proficient in Verilog HDL & Register Transfer Level (RTL) Design

      2. Experienced in Logic Synthesis & Static Timing Analysis (STA)

      3. Successfully deployed a custom RISC-V/CPU architecture on an Altera DE10-Lite FPGA platform

Taa daa… You immediately jump to the top of the pile.

Having reconfigurable electronics on your CV proves to employers that you don’t just understand digital logic on a whiteboard; it proves you know how to build, debug, and validate actual working hardware using the exact tools the industry relies on every single day.

Ready to Jump In?

If you want an elective that moves away from text-heavy cramming and gives you an authentic, hands-on engineering portfolio to show off in interviews, pick your track:

      • Engineering Programs: Register for BHE3233 or BEL4553.

      • Engineering Technology Programs: Lock in BTS4433 as your elective track.

Take a look around the rest of the blog to see project roadmaps, code snippets, and some of the incredible digital systems our senior students have built.

Have questions about the syllabus or how the FPGA labs work? Drop a comment below or swing by my office for a chat.

Let’s stop just studying engineering, let’s start building it  =)  !

Nurul – July 14th

BHE3233 BTE4433 – Week 14 Lab Submission

BHE3233

Group 1 – AES

Group 2 – FIR Filter

Group 3 – FIR Filter

BTS4433

https://www.youtube.com/shorts/xrJ00I3LIlE

Group 2

Group 5

Group 8

Group 5

https://www.youtube.com/shorts/royQgfZswWc

https://www.youtube.com/shorts/QMlo0IBENTA

Group 1

https://www.youtube.com/shorts/e9hTOs6n7F8?si=F-tFTJrBuzMDtV41

Group 2

https://www.youtube.com/shorts/wrp0cACEB4k

Group 7

BHE3233 BTE4433 – Week 13 Project Presentation

What an incredible journey it has been! This week is the presentations week for the BHE3233 and BTS4433 cohorts. After weeks of development through our tiered scaffolding approach—moving from Stage 1 (Workout Programming) to Stage 4 (Comparative Optimization)—every student successfully presented their hardware architectures.

Watching everyone dissect, design, and compare four distinct digital systems was a proud moment for the UMPSA STEM Lab. But how exactly do these projects tie into our overall syllabus, and how have they built the critical Verilog coding criteria our students will take into the industry?

Let’s break it down.

The Projects: Four Pillars of Digital System Design
The course syllabus was intentionally structured to expose students to four highly distinct industry domains. By encouragung students to design and then optimize each of these systems, the syllabus ensured a comprehensive grasp of real-world hardware challenges:

  1. Project 1: Cryptography (Security-Focused): Students dove into hardware encryption by designing an 8-bit AES S-Box. By Stage 4, they compared a memory-heavy Look-Up Table (LUT) approach against an area-efficient Logic-based (Boolean/Galois Field) approach, learning how to select architectures based on whether they are building a high-speed processor or a low-area IoT device.
  2. Project 2: CPU / ALU Design (Arithmetic-Focused): Escalating a basic multiplier to 16-bit logic, students had to evaluate complex mathematical trees. They compared Behavioral, Sequential (Shift-and-Add), and Pipelined multipliers. This taught them the delicate balance between saving Logic Elements (LEs) for handheld devices versus maximizing throughput for heavy computation.
  3. Project 3: DSP & Sensor Processing: Students built a 4-tap FIR filter, calculating precise bit-widths to prevent arithmetic overflow. The final optimization challenged them to shift from a Direct Form to a Transposed Form architecture, proving that mathematically identical Verilog code can yield vastly different Max Frequencies (fMAX) simply by shortening the critical path.
  4. Project 4: Communication Protocols (Interfacing): Focusing on high-reliability data transmission, students built a UART Controller with an integrated Baud Rate Generator and Parity checking. By comparing Binary-Encoded FSMs against One-Hot Encoded FSMs, they learned how Verilog state machine encoding directly impacts flip-flop utilization and setup slack.

Building Verilog Criteria: Beyond Syntax
The most valuable outcome of this class is how it transformed the students’ Verilog coding criteria. The tiered scaffolding intentionally guided them through a specific evolutionary process:

  1. Code Comprehension & Hardware Inference (Stage 1): Students learned that Verilog isn’t just software code; it is a description of physical hardware. They learned how a simple * operator is interpreted by the Quartus synthesis engine.
  2. Debugging Hardware Logic (Stage 2): They learned to identify hardware-specific malfunctions, such as standard compliance errors (“Output port has no driver”) and catastrophic “Race Conditions” caused by using blocking assignments (=) instead of non-blocking assignments (<=) in sequential logic.
  3. Architectural Integration (Stage 3): They learned how to connect verified sub-modules into complex top-level architectures, carefully calculating bit-growth across the data path.
  4. Scientific Optimization (Stage 4): This is where they built their highest-level Verilog criteria. They learned to rely on the Quartus TimeQuest Timing Analyzer and Resource Utilization reports to justify their designs, comparing Total Logic Elements, Registers, Max Frequency (fMAX), and Latency.

Preparing for the Engineering Tasks
As noted in the course materials, escalating designs to handle complex optimizations moves a student from simply “making things work” to “optimizing things for performance,” which is the hallmark of a true Digital Design Engineer.

Congratulations to all the BHE3233 and BTS4433 students! You didn’t just write Verilog this semester; you intelligently traded Area for Speed, evaluated critical paths, and solved complex timing puzzles. You are now fully equipped to tackle modern FPGA and ASIC design challenges in the industry!

 

BHE3233 BTS4433 – Week 11 Project Design Optimisation

Hello everyone,
After weeks of writing, debugging, and integrating Verilog code, we have finally reached the pinnacle of digital system design: Stage 4 (Comparative Optimization)
In this phase, we move beyond simply asking “Does the code work?” to asking “Which architecture is mathematically and structurally superior?”
In FPGA design, there is rarely one perfect answer. Every design choice is a delicate balancing act between Area (Logic Elements and Flip-Flops), Speed (), and Latency.
This week, our students put competing architectures head-to-head across four different projects to see how they perform under the rigorous scrutiny of Quartus’ Static Timing Analysis (STA) and Resource Utilization reports.
Here is a breakdown of the design comparisons for each project:
Project 1: AES Cryptography (LUT vs. Logic-Based S-Box)
For the AES S-Box, students integrated two completely different structural approaches onto the DE10-Lite FPGA and used a toggle switch to compare their performance.
    1. Table-Based (ROM/LUT) Approach: This method acts like a cheat sheet, pre-calculating every possible answer and storing it in memory
      1. While extremely fast (constant time), it consumes significant memory resources and scales poorly. It is highly suited for high-speed cryptographic processor.
    2. Logic-Based (Boolean) Approach: This method acts like a math formula, calculating Galois Field arithmetic in real-time using layers of logic gates
      1. It uses very little memory and is highly area-efficient, making it the perfect choice for low-area IoT devices, though it suffers from a longer propagation delay due to the deep logic tree.

 

Project 2: CPU Arithmetic (Sequential vs. Pipelined 16-bit Multipliers)
For the ALU design project, students escalated their 4-bit multipliers to 16-bit and compared architectures to see how digital systems handle complex arithmetic
    1. Sequential (Shift-and-Add) Multiplier: By mimicking manual long multiplication, this architecture reuses a single adder over multiple clock cycles
      1. It dramatically saves on Logic Elements (LEs), but the cost is high latency, making it ideal for space-constrained, battery-powered handheld devices
    2. Pipelined Multiplier: To maximize performance, students inserted registers into the combinational logic “fences” to break up the deep mathematical tree 
      1. Like an assembly line, this allows a new multiplication operation to begin every single clock cycle.
      2. It costs far more registers, but drastically increases throughput and , which is mandatory for applications executing millions of operations per second.

Project 3: DSP and Sensors (Direct vs. Transposed FIR Filters)

In digital signal processing, the physical layout of your adders and multipliers can make or break your frequency limits. Students evaluated a 4-tap FIR filter using two mathematically identical, but structurally different, forms.
    1. Direct Form: The standard approach where all multiplications happen in parallel, and the results are summed up in a large “Adder Tree”. Its major flaw is a massive Critical Path—the signal must traverse a multiplier and the entire chain of adders before the clock cycle ends, severely limiting the maximum frequency.
    2. Transposed Form: By strategically placing delay registers between the adders, students shortened the critical path so the signal only propagates through one multiplier and one adder per cycle. While this slightly increases Total Registers (FFs), it yields a substantially higher (often a 25% improvement), making it the superior architecture for high-speed 100MHz digital audio processors
Project 4: UART Controller (Binary vs. One-Hot FSM Encoding)
In the final project, students escalated their UART transmitter to handle 16-bit data frames with Even Parity and evaluated how Quartus encodes Finite State Machines (FSMs)
    1. Binary Encoding: This style uses the absolute minimum number of Flip-Flops (e.g., 2 FFs for 4 states). While it saves physical area on the silicon, it requires heavier combinational logic to decode the states
    2. One-Hot Encoding: This style assigns exactly one Flip-Flop per state (e.g., 4 FFs for 4 states)
      1. Despite consuming more physical area, the decoding logic becomes incredibly simple. This translates to better Setup Slack and a much faster , proving that sometimes using more hardware actually makes your system perform better
The Takeaway Stage 4 proves that mastering digital system design isn’t just about writing Verilog that compiles. A true hardware engineer knows how to interpret the Fitter and Timing Analyzer reports to intelligently trade Area for Speed based on the exact needs of the industry application!

 

I look forward to your creativity in executing these projects. Please complete your submissions in KALAM =)

BHE3233 BTS4433 – Week 10 Project Semi Completed Programming

Hi everyone,

After successfully navigating code comprehension and hardware debugging in Stages 1 and 2, our journey through digital system design enters its most advanced phases. This week, we focused on Stage 3: Semi-Completed Programming and Stage 4: New Programming Task (Comparative Optimization).

These stages push us beyond merely “making it work” to actually architecting complete systems and evaluating trade-offs like true digital design engineers. Here is a breakdown of our milestones and the core learning outcomes for each project.

Stage 3: Semi-Completed Programming (Architectural Completion)

In Stage 3, we took foundational components and integrated them into complete, functioning architectures.

Project 1: AES Cryptography (The Logic-Optimized S-Box)

    • The Challenge: Transitioning away from a memory-heavy Look-Up Table (LUT) to a logic-optimized approach using Galois Field (GF(2)) composite arithmetic. We had to complete the missing Boolean equations for multiplicative inversion.
    • Learning Outcome: Mastering Mathematical Hardware. We learned how complex cryptography math (like Galois Fields) is synthesized into pure Boolean logic (XOR, AND, OR gates), demonstrating how a “calculation” approach saves memory at the cost of logic depth.

Project 2: The Multiplier (Pipelining for Speed)

    • The Challenge: We upgraded a combinational multiplier by inserting registers into the middle of the logic “fences” to create a Pipelined Multiplier.
    • Learning Outcome: Increasing Throughput. By breaking a long combinational path into smaller stages, we learned how pipelining allows a new multiplication to start every clock cycle, drastically increasing the system’s Max Frequency (fmax)

Project 3: FIR Filter (Structural Integration)

    • The Challenge: We integrated our verified Multiply-Accumulate (MAC) units and Delay Lines to build a complete Direct Form FIR Filter.
    • Learning Outcome: Preventing Arithmetic Overflow. The crucial lesson here was calculating exact bit-widths for signal growth. We learned that multiplying two 4-bit inputs yields an 8-bit output, and accumulating three of these 8-bit partial products requires a 10-bit final output to prevent overflow.

Project 4: UART Controller (The Transmitter FSM)

    • The Challenge: Wrapping raw serial data into a standardized UART frame by building a Finite State Machine (FSM) that transitions through IDLE, START, DATA, and STOP states based on precise “ticks” from our Baud Rate Generator.
    • Learning Outcome: Protocol Synchronization. We learned how to reliably sequence hardware operations using FSMs, ensuring that communication lines are held HIGH during idle and strictly synchronized to a predetermined baud rate for data integrity.

 

Moving on

Stage 4: Comparative Optimization (New Programming Tasks)

Stage 4 is where engineering design trade-offs shine. We escalated our designs and used Quartus tools (like the Timing Analyzer and Resource utilization reports) to scientifically compare competing architectures.

Project 1: AES Cryptography (LUT vs. Logic Trade-offs)

    • The Challenge: We integrated both the Stage 1 (Table-based) and Stage 3 (Logic-based) architectures onto the DE10-Lite FPGA, using a hardware switch to “toggle” between them.
    • Learning Outcome: Resource vs. Speed Optimization. By running a Static Timing Analysis (STA), we learned to scientifically deduce which architecture to use depending on the application—evaluating why a LUT is better for a high-speed cryptographic processor while Boolean logic is superior for a low-area IoT device.

Project 2: The Multiplier (16-bit Escalation)

    • The Challenge: We escalated our multiplier from 4-bit to 16-bit and compared all three architectures: Behavioral, Sequential, and Pipelined.
    • Learning Outcome: Evaluating Complex Architectural Trade-offs. We learned how expanding bit-widths exponentially deepens the logic tree. The outcome was understanding how to choose an architecture based on strict constraints (e.g., choosing sequential for space-constrained handhelds vs. pipelined for high-performance CPU ALUs).

Project 3: FIR Filter (Direct vs. Transposed Form)

    • The Challenge: We redesigned our filter into the Transposed Form, a mathematically identical structure that places delay registers between the adders rather than at the input.
    • Learning Outcome: Shortening the Critical Path. We learned a major DSP optimization technique: by separating combinational adders with registers, we shortened the critical path delay. Even though this uses slightly more Logic Elements, it dramatically boosts the f max making it ideal for high-speed audio/sensor processing.

Project 4: UART Controller (FSM Encoding & Parity)

    • The Challenge: We expanded the UART to 16-bit with Even Parity error checking and compared two FSM architectures: Binary Encoding versus One-Hot Encoding.
    • Learning Outcome: FSM Encoding Trade-offs. We gained hands-on experience in how the Quartus compiler assigns flip-flops. We discovered that Binary Encoding saves area (fewer flip-flops) but requires heavier decoding logic, whereas One-Hot Encoding uses more flip-flops but simplifies decoding, resulting in better setup slack and a faster maximum frequency.

BHE3233 BTS4433 – Week 9 Project Workout Simulation

This week in the lab, we move forward in our hardware design journey by executing Stage 1: Workout Programming and Stage 2: Debugging Specific Malfunctions across four highly distinct FPGA projects. These stages forced us to transition from merely reading code to actively troubleshooting real-world hardware logic errors.

Here is a breakdown of what we accomplished:
Project 1: Cryptography on Silicon (AES S-Box) We kicked things off by diving into the Advanced Encryption Standard (AES). In Stage 1, we analyzed a Memory-based (ROM) Look-Up Table (LUT) approach for an 8-bit AES S-Box. We used ModelSim to perform functional verification, proving that the hardware correctly maps inputs to standardized AES cipher outputs (like mapping 8'h00 to 8'h63).
The real challenge came in Stage 2 with the Inverse S-Box (used for decryption). We were handed a buggy Verilog script containing three intentional errors related to syntax, logic, and standard compliance. By deciphering Quartus compilation warnings like “Output port has no driver,” we successfully repaired the code to prove that feeding a cipher output back into the Inverse S-Box restores the original “plain” input byte.
Project 2: CPU Arithmetic (The Multiplier) Our second project focused on resource-efficient ALU design. Stage 1 introduced a Behavioral Multiplier, where we let the Quartus synthesis engine decide whether to map the multiplication logic to 9-bit DSP blocks or Logic Elements (LUTs).
Stage 2 brought us down to the sequential level with a Shift-and-Add Multiplier, which mimics manual long multiplication to save area. However, the provided design failed for maximum 4-bit inputs (like 4'hF * 4'hF). We had to debug a logical flaw in the module’s bit-counter; it was only counting up to 3 instead of 4. By correcting the count limit and adjusting the counter’s bit-width, we enabled the hardware to successfully process all 4 bits.
Project 3: DSP and IoT Sensors (4-Tap FIR Filter) For our digital signal processing project, we explored how to clean up sensor data using a Finite Impulse Response (FIR) filter. In Stage 1, we verified the core building block: the Multiply-Accumulate (MAC) unit. A key takeaway was learning how to prevent arithmetic overflow by understanding bit-growth (e.g., multiplying two 4-bit inputs requires an 8-bit output).
Stage 2 tackled a classic hardware pitfall: the Race Condition. In our shift register (Delay Line), which holds the crucial “historical” samples (, ), the buggy code used blocking assignments (=) inside a clocked block. This caused the input to immediately leak through all registers in a single cycle. We fixed this by rewriting the block with non-blocking assignments (<=), ensuring the signal properly shifts stage-by-stage with each clock pulse.
Project 4: Communication Protocols (UART Controller) Our final project of the week centered on hardware interfacing. We started Stage 1 by executing Parallel-to-Serial Conversion, learning how a shift register takes a 4-bit wide parallel bus and sends it out bit-by-bit over a single serial wire.
In Stage 2, things got precise. Because UART transmitters and receivers don’t share a common clock, they rely on a precise Baud Rate. We had to debug a Baud Rate Generator designed to divide a 50MHz FPGA clock down to 9600 bits per second.
The buggy counter was missing a reset condition and had a threshold comparison error (counting to 5208 actually takes 5209 cycles). After fixing the logic, we used ModelSim to verify that our baud_tick pulses were exactly ~104.16 microseconds apart, ensuring perfect synchronization.
Moving from code comprehension in Stage 1 to active logic correction in Stage 2 has completely changed how we look at Verilog and Quartus. Next week, we will move on to Stage 3: Semi-Completed Programming, where we will integrate these components into larger, more complex architectures!

Completion of Stage 1 & 2 activities

BHE3233 BTS4433 – Week 7 – Sequential RTL – Lab 4

Welcome to Week 7! This week, we took a massive leap in our digital design journey by exploring Register Transfer Level (RTL) sequential circuits. Unlike combinational circuits, sequential circuits have memory, meaning their outputs depend not only on current inputs but also on previous input
history. At the heart of these sequential designs is the Finite State Machine (FSM).
In digital design, FSMs are used to control system behavior by transitioning between a finite number of states based on inputs and clock cycles.
When we build FSMs in Verilog, we generally divide the architecture into three main blocks:
        1. The State Register: This is a synchronous block (using always @(posedge clk)) that updates the current state to the next state at every clock edge, or resets it when a reset signal is triggered.
        2. The Next-State Logic: A combinational block that evaluates the current state and external inputs to determine what the next state should be.
        3. The Output Logic: A combinational block that generates the output signals based on the current state (Moore machine) or both the current state and inputs (Mealy machine).
In class, we looked at a practical example: a sequence detector acting as a lock that opens whenever the serial bit pattern “1011” is achieved.
Before writing any Verilog code, it is incredibly important to derive your state machine on pen and paper first. Drawing an abstract state diagram ensures your states and transition logic actually make sense.
For the “1011” detector, our state diagram tracks how much of the pattern we have seen so far:
        1. S0: Nothing matched yet.
        2. S1: Matched “1”.
        3. S2: Matched “10”
        4. S3: Matched “101”
        5. S4: Matched the full “1011” sequence (this is where the output goes high).
By mapping out the transition arrows—such as moving from S1 to S2 if the input is 0, or dropping back to S0 if the sequence is broken—you establish the exact mathematical behavior your next-state logic block needs to model.
Hands-On: Lab 4 and the Satellite Communication System
Once we nailed down the state diagrams on paper, we moved into the hardware phase with Lab 4: Finite State Machine for Satellite Communication Link
In real picosatellite systems, communication links require a strict, multi-stage initialization and termination process . You simulated this exact scenario using a four-state FSM:
      1. IDLE: Waiting for the start command.
      2. LINK_ESTABLISH: Attempting the communication handshake.
      3. DATA_TRANSFER: The active data transmission session
      4. LINK_TERMINATE: Securely closing the session 
During the lab, you mapped your DE10-Lite board’s switches to act as the transition triggers (e.g., SW0 to start communication, SW1 to signify link established) and used the LEDs to track which state the FSM was currently in.
By verifying the state transitions in a ModelSim simulation and testing it directly on the physical board, you successfully built a control system identical to those used in real-time embedded space missions !
Keep practicing drawing those state diagrams on paper before jumping into Quartus. See you next week!