In the context of building hardware, a summative project in 2nd/3rd-year digital system design is the implementation of some complex hardware system. These can take the form of video games (think Atari clones), implementation of simple algorithms (DES encryption, numerical methods, hash functions), or building a simple computer architecture. In that process, a student takes a large step in that they need to understand how an algorithm works at the step-by-step level. Most of us read pseudo-code for algorithms and might grasp what the idea is, but to be able to translate that algorithm into interacting hardware components from the granularity of low-level logic gates, to Finite State Machines (FSMs), to functional blocks that control/work with external peripherals and their respective chips (think a Video chip or Audio chip), designers need a deep understanding of the algorithms and system interactions.
To understand an algorithm's computational steps one can implement the steps on paper, run a code-based version of that algorithm with output or in a debugger. These all come with a time cost, a skill cost, and a question if a learner can grasp the algorithm(s). This card suggests an alternative way to have students grasp the execution of an algorithm by having students come up with creative ways of "Making" the algorithm. The hope is that the alternative approach may provide students with a lower bar to entry in understanding an algorithm.
The hypothesis we have is that to build the hardware version of an algorithm, the deeper the designers' understanding of the algorithm within their heads.
The learning objective and the troublesome knowledge that this activity is based on:
Learning Objective- Explain the steps of an algorithm that executes a portion of your design (Bloom verb is 5-Evaluate)
The troublesome knowledge in this space is the algorithm and being able to understand it to the point of simulating it in your head.
See the assessment section below.
I use two mental models to describe algorithms:
1) Select an algorithm.
a) Pick an existing algorithm:
i) Greatest Common Denominator (see example and pseudocode pdf)
ii) Run Length Encoding - String or Binary String(see example and pseudocode pdf)
b) Choose your own algorithm:
i) Given your algorithm write the pseudo-code for it and include a worked-out example (see worksheet pdf)
ii) MORE CLOSELY RELATED TO HARDWARE SUMMATIVE PROJECTS Take your algorithm write the pseudo-code for it and include a worked-out example. As the complexity of this might be greater, don't worry about some of the details, but try to be as detailed as possible.
2) Given a basic understanding of your chosen algorithm, "tell the story" of that algorithm in an hour or less with materials such as cardboard, paper, markers, clay, popsicle sticks, etc.
From the instructor's perspective, in prototyping my version of this maker activity I naturally felt that the three ways of expressing an algorithm in a more 3D form:
- Board game version of the algorithm (this is the prototype that I created on my first iteration of this card)
- Puppet show of what is visualized from an algorithm that manipulates graphics (simulation/game)
- A factory-like setting that transforms objects at each step of the algorithm
My kind tester of this activity interpreted the prompt differently than I thought:
- Created a fictional story of an algorithm he was familiar with
This leads to the wonderful potential of going into spaces of:
- Create a film or audio story that illustrates the "story of an algorithm"
This activity is specked at around 1 hour which is a significant amount of time to help achieve this LO when there are many ways to achieve this understanding. The benefit of the student grappling with an algorithm in a different form is currently unproven as beneficial as the hypothesis that "grappling with an algorithm will help students understand and simulate pieces of the algorithm in their heads".