The Musical CPU
Click here to load reader
-
Upload
gunjan-gupta -
Category
Technology
-
view
126 -
download
1
description
Transcript of The Musical CPU
The Musical CPU
Gunjan Gupta
10BEC112
Electronics and Communication Dept.
Institute of Technology, Nirma University
Abstract - A typical project in a digital system
design or a computer organization course is the
design of a CPU for a small, simplified
instruction set. However, it can be a challenge to
devise such projects in a way that simultaneously
reinforces effective logic design principles, is
hands-on, can be completed using inexpensive
and standard laboratory equipment, and (most
importantly) inspires, as part of the design
process, both imagination and creativity. This
paper describes such a project where the target
instruction set is designed to implement (i.e.
“program”) music and play songs on commonly
available FPGA hardware. The “musical CPU”
uses three carefully designed instruction formats
to literally describe the sounds and flow of music
by mapping various constructs of music (notes,
tempo, etc.) into corresponding specially
designed assembly language instructions that
encode the desired musical effect; hence, the
emphasis is on the creative nature of the design
process. The details of this project necessitate
consideration of many cross-cutting issues in
computer science and engineering including
instruction set design, finite state machine
control design, programming logic, and user
interaction issues.
Index Terms – Creative Projects, Digital Logic,
Digital System Design, Music
INTRODUCTION
The project ties together concepts from digital
system design with computer architecture and some
basic theory of computation, and that also results in
interesting, dynamic I/O behavior is a “musical
CPU” – a CPU that uses various instruction types to
literally describe the sounds and flow of music. The
details of this project are especially well-suited for
implementation on standard educational logic
design equipment, such as the UP2 development
board from Altera [1].
At present, the two most common approaches to
including hands-on projects in a digital logic course
are (a) to implement a variety of primitive devices
(adders, multiplexors, a simple ALU, etc.) on a
breadboard using commonly available TTL
components, and (b) to implement a very simplified
computer design either via software simulation or on
an FPGA (Field Programmable Gate Array) using a
hardware development language (e.g. Verilog or
VHDL) and associated software development
environment (such as Xilinx ISE Webpack [2] or
Quartus II [3]). This paper describes the design of
the “musical CPU” digital system which is a project
intended for implementation on an FPGA. In the
sections that follow, an explanation of the basic
musical concepts necessary to complete the design
is provided, followed by one approach to designing
the device including a discussion of the more
interesting aspects of its implementation (including
the instruction set design) on the Altera UP2 board.
MUSIC AND COMPUTER SCIENCE
There are many striking similarities between the
concepts developed in music and those that are
applied in computer science. For example, the way
in which a musician reads and interprets sheet music
is analogous to the way in which a CPU reads and
interprets assembly language instructions. This
relationship is key to the design of the musical CPU.
Designing a musical CPU requires mapping various
constructs of music into corresponding specially
designed assembly language instructions that
encode the desired musical effect. Using such a
mapping, a carefully constructed assembly language
program can be used to play a song on the musical
CPU.
BACKGROUND ON MUSIC
In order to design a musical CPU, a basic
understanding of the structure of music is required.
A piece of music is comprised of many structural
elements, and depending on the desired complexity
of the music to implement (or of the digital device
to design!), different aspects of these structures will
need to be modelled for an implementation in a
CPU.
a. Notes and Tones:
b. Note Duration, Tempo, and Control
Flow
I. Notes and Tones:
The most basic (and necessary) construct of music
is the note – an assertion of audible sound at a
specific frequency (or pitch), for a specific duration
of time. We define the tone of a note to be one of
twelve “primitives” – pitches with evenly spaced
frequencies. Enumerated by name, these are: “A”,
“A#” or “Bb”, “B”, “C”, “C#” or “Db”, “D”, “D#”
or “Eb”, “E”, “F”, “F#” or “Gb”, “G”, and “G#” or
“Ab.”
These twelve tones cyclically repeat, and
each set of twelve forms an octave. A tone in one
octave has exactly half the frequency of the same
tone in the next higher octave. For instance, if an “F”
in one octave has a frequency of 174.62 Hz, the “F”
in the next higher octave has a frequency of 349.24
Hz [4]. Thus, the frequency of a note is determined
by two factors: its octave, and its position (tone)
within that octave. Finally, a special type of note,
called a rest, provides a period silence.
II. Note Duration, Tempo, and Control Flow:
The duration of a note is specified by a fraction of
some predefined period of time. Convenient to
binary representation, most note lengths are defined
by inverse powers of two. For instance, if the
duration of a “whole” note is equal to the predefined
period of time (e.g. one second), a “quarter” note
lasts ¼ the time of a whole note (e.g. 0.25 seconds).
Similarly, a “sixteenth” note lasts 1/16th the time of
a whole note, and so on.
The tempo denotes the overall speed at
which a song is played; that is, the tempo is assumed
to define the length of a whole note (in reality it is
more complicated, but this assumption is sufficient
to implement the musical CPU). While there are
many possible ways to describe the tempo, one
simple way is by specifying the number of whole
notes per minute. When combined with the duration
of a note, the tempo defines the exact span of time
for which an individual note is played. For instance,
if the tempo is 30 whole notes per minute, a half
note would last for one second. One additional
construct useful both in terms of interpreting music
and designing an instruction set is the ability to jump
from one point in the flow of notes, or instructions,
to another. Just as good software design encourages
code reuse, musical notation allows a musician to
“repeat” the same portion of music under different
circumstances (for instance, even though the words
in a song may change, the main repeated refrain or
theme stays the same). In CPU design, this requires
an addressing scheme, a counter, and some sort of
jump mechanism. The same is true of the design of
the musical CPU.
INSTRUCTION SET DESIGN
The musical CPU is designed to implement only a
small subset of the possible constructs of music. To
implement the three music constructs Play Note, Set
Tempo, and Jump requires only a 2 bit opcode as
part of the instruction set design. For each such
opcode, a small number of fields are necessary to
properly describe the properties of the
corresponding musical construct. For instance, a Set
Tempo instruction needs only one additional field:
the value of the tempo specified in some units (such
as whole notes per minute). Similarly, a Play Note
instruction needs three additional fields: the note’s
tone, the duration, and the octave.
Of course, the Jump instruction needs, at a
minimum, a field used to determine the destination
address. But, since pieces of music often consist of
a common, reused sequence of notes followed by
multiple distinct “endings,” the Jump instruction
format should be designed to accommodate this as
well. For example, consider the following sequence
of notes:
Note A, Note B, Note C, Note D, Note B
Note A, Note B, Note C, Note D, Note B
Note A, Note B, Note C, Note A, Note B, Note B
This consists of a three note sequence in
common (Note A, Note B, Note C) followed by two
distinct endings, one of which is played twice (Note
D, Note B). One possible technique for describing
this flow of control is to implement this as follows:
:BEGIN
Play Note A
Play Note B
Play Note C
Jump to ENDING2 after a count of 2
(maxCnt=2, count=2)
Play Note D
Play Note B
Jump to BEGIN after a count of 0
(maxCnt=0, count=0)
:ENDING2
Play Note A
Play Note B
Play Note B
In this example, the first version of the
jump instruction is a conditional jump to ENDING2
that “falls through” twice prior to executing the
jump on the third pass. The second version of the
jump is an unconditional jump to BEGINNING,
since the count starts at 0. This approach can be
implemented in a single common instruction format
by using absolute addressing with a destination
address field, a mutable count field, and a maxCnt
field. The count field is initialized to the number of
times to ignore the jump (i.e. falling through is the
default), and subsequently decrements each time the
instruction is tested. The maxCnt field specifies the
value that the count field should be reset to once it
reaches zero (i.e. the jump is taken). That is, on each
test of the Jump instruction conditions, the musical
CPU checks the count field to determine whether or
not to jump: if the count is not yet 0, the count field
is decremented and the jump is ignored. When the
count field reaches 0, the jump is taken, and count
field is reset to maxCnt. Multiple chained or nested
jump instructions using this technique allows for
significant flow control flexibility using only one
opcode and jump instruction format, although the
instruction is obviously mutated during execution.
This is a creative design approach, favoring a single
instruction format that can be used to implement
both conditional and unconditional jumps.
Another important concern in instruction
set design is the size (in bits) of each instruction.
This is especially important on resource-constrained
devices such as the FLEX10K FPGA (a common
form of reprogrammable chip) on the Altera UP2
development board. While the FLEX10K chip can
simulate RAM using large numbers of multiplexed
flip-flops, with a limited number of logic cells
available on the chip, such a memory would likely
be limited to a relatively small number of
instructions.
For the musical CPU, a sixteen bit
instruction format is sufficient to implement the
music constructs required in this project, without
requiring overly complex encodings of each field
value. Figure 1 illustrates the specific format for
each of the three instruction types. For each of these
formats (Play Note, Set Tempo, and Jump), the
combined size of all subfields must be designed to
fit within sixteen bits. For instance, in the Play Note
instruction format, the thirteen tones (twelve tones
plus rests) require a four bit tone field. Another eight
bits in the Play Note instruction format are used to
determine the note duration. In our case, these eight
bits specify this note duration in terms of fractions
of a whole note. For example, in our representation
00000001 denotes a whole note, 00000100 denotes
a quarter note, and 00010100 denotes 1/20th of a
whole note. In this way, the eight bits of precision
set aside for the note duration provides a range of 1
to 1/255th of a whole note. While music with notes
shorter than 64th notes is rare, musicians often insert
stylistic pauses, called breaths, of shorter length.
Thus, eight bits of precision also allows the musical
CPU to emulate breaths and other stylistic qualities
of music.
Given these two design choices (to store
tone and note duration), there are only two bits
remaining to represent the octave, thereby
providing a four octave range. While the human ear
can detect pitches across many octaves, it is rare to
find music that uses more than four octaves for a
single voice – a single “thread” or flow of music.
Similar to how a thread in software can only execute
one command at a time, a voice can only play one
audible tone at a time. While simple songs may only
require one voice, most complex music requires
multiple voices. For instance, a jazz band might
have four trumpet players, each playing a separate
set of notes, and each counting as a separate voice.
Likewise, the piano will likely play three or four
notes at a time, constituting three or four voices.Our
musical CPU is designed to play only one voice, so
it can only play one note at a time, in sequence.
However, one possible (and relatively simple)
extension of our musical CPU would be to use two
Altera UP2 boards sharing the same clock and user
input controls but playing a melody and harmony at
the same time; thus, we could have two voices.
In the Set Tempo instruction format, eight
bits specify the tempo relative to the number of
whole notes per minute. For example, a tempo value
of 00011110 denotes a tempo of thirty whole notes
per minute, or a whole note duration of two seconds.
The remaining six bits are unused since the
instruction size is fixed.
Play Note (opcode 00)
op duration tone octave
2
bits
8 bits 4 bits 2 bits
Set Te mpo (opcode 01)
op tempo unu sed
2
bits
8 bits 6 b its
Jump ( opcode 10)
op absolute destination
address
maxCnt count
2
bits
8 bits 3 bits 3 bits
FIGURE 1
INSTRUCTION SET ARCHITECTURE OF THE MUSICAL CPU
Like the Play Note instruction, the Jump instruction
format also requires three fields. A three bit field is
reasonable for the count and maxCnt fields since
this provides up to seven repetitions of the same
sequence of music using a single Jump instruction.
Note, however, that this is not a limitation since
Jump instructions can be chained in sequence,
thereby permitting additional repetitions. The final
eight bits provides up to 256 note destinations using
absolute addressing.
SUMMARY
Designing a specialized CPU that plays
music written via a customized assembly language
instruction set requires creativity and the use of
numerous design principles from digital logic,
theory of computation, computer organization, and
structured programming. While it requires some
modest knowledge from a variety of areas present in
standard computing curricula, the Musical CPU
project provides a level of novelty and dynamic I/O
usually not expected with limited laboratory
resources. Building the musical CPU presents many
challenges in the design and implementation of
instruction set architecture, finite-state machine
control mechanisms, and digital logic designs. It
also encourages the exploration of how concepts in
music can and do relate to computer science.
Dealing with the many details related to designing
and implementing a device such as the musical CPU
represents issues not only from digital logic design,
but also from computer science as a whole, and from
the fine arts discipline of music.
REFERENCES
[1] Altera, University Program UP2 Education Kit, available online at
http://www.altera.com/literature/univ/upds.pdf
[2] Xilinx ISE Webpack, available online at http://www.xilinx.com/ise/logic_design_prod/webpack.htm
[3] Quartus II, available online at http://www.altera.com/products/software/products/qu
artus2/qtsindex.html
[4] Wenzel, C, “Musical Notes”, available online at http://www.techlib.com/reference/musical_note_frequencies.htm