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