My CPU Design in an FPGA Via Collaboration with Dr. Kevin Walsh & His Improvements to Logisim

My CPU Design in an FPGA Via Collaboration with Dr. Kevin Walsh & His Improvements to Logisim


I would imagine that every CPU designer dreams
of the day when their design finally ends up in actual hardware. Thanks to a collaboration with Dr. Kevin
Walsh, that dream has come true for me. For those who don’t know, Kevin wrote
the various extra Logisim components in the Cornell version of Logisim and
created his own version of Logisim Evolution now that he’s at Holy Cross. I hope this development doesn’t upset the
couple of people who requested my circuit and I said no. Kevin not only asked first, but he asked before
I decided not to distribute my circuit. But this collaboration will help
everyone, since Kevin tells me he used my circuit to make his version of
Logisim even faster. So everyone ultimately wins. I’ll cover the speed-ups
later. I’ll start by showing what I gave Kevin. It was the latest version of my
design at the time he requested it, but I’ve added a lot since then though
some additions wouldn’t likely be able to be put in an FPGA or at least not a
relatively inexpensive one. I’m also showing it using the version of Kevin’s
Logisim that was available around that time. Now, here’s my design modified by Kevin. Most of the changes are cosmetic. And most of the non-cosmetic changes involve
the removal of gated clocks. Gated clock means that a component is clocked
by other components such as gates rather than a clock. If you saw one of my previous videos, you’ll
know I said I got rid of pretty much all gated clocks. So you might wonder what gated
clocks did Kevin remove. Well, I only got rid of the gated clocks that
would be synthesized into an FPGA since the removals
were done because the synthesization process indicated there might
be timing problems due to gated clocks. Kevin got rid of all gated clocks even those
parts of the circuit that wouldn’t be in the FPGA implementation. I’ll try to quickly run through the changes. The NOT gates on the value displays were removed,
so now the displays default to off. The pull down resistors on the value displays
were also removed meaning the displays won’t indicate zeros
if the input is floating. The
controlled buffers on the displays were changed to ControlledDrivers, allowing
them to be synthesized. The 7 input OR gate on the MIDI device which
turned off the device if the volume was zero was
changed to a comparator. The pull
down resistor on the keyboard was removed. The AND gate used with the device
select decoder was removed. A DeMUX is used instead which also removes
the AND gate for the Store to RAM and the pull
down resistor. Changes to the
Fetch/Execute cycle circuitry, which I’ll show later, changes the colors and
behavior of the CPU state LED. And finally, the “clk” clock line is used
to clock the RAM, RTC clock register, LED matrix,
keyboard, frequency and volume registers, xy coordinate register, and video
display which removes all gated clocks from this part of the design. Now the ALU changes. Byte and Word swappers were added for some
reason, but they are not used by the Control ROM. A few unused components that I wasn’t
sure I wanted to add were disconnected. I removed those from newer versions of
my design anyway. Now for the changes to the CPU. Cosmetically, this was changed a lot. As for the non-cosmetic changes, the
JK flip-flop in the Fetch/Execute cycle circuitry was changed to an SR flip-flop
which removes the gated clock and also removes the need for the AND. The
consequence of this change is that the Start button now requires the clock to
be running when pressed, otherwise it has no effect. The MUX on the
instruction register was removed. That MUX really didn’t do anything, but for
some reason I can’t remember, I put it there in my original on paper homework
assignment. The priority encoders on the MUXes on the
address bus and the Y register were removed because the MUXes were
changed to priority MUXes. And
the priority encoder on the MUX on the A register that I had to put in to make
it work in GHDL, was removed. There is a mistake in the redesign here, but
it’s probably due to my imprecise labeling of one of the
lines. The M_to_A control line
shouldn’t be connected to the A register. I probably should have labeled it
M_to_AB, for address bus, since it’s used to select the value going to the address bus,
but I figure I was thinking that it was a line necessary
to send a value from memory to the A register, so I was describing reason
rather than function if you know what I mean. Kevin later fixed that on his own. For the Control ROM, instead of a MUX or pull
down resistor, a ControlledDriver is used instead. Here’s the priority MUX. A PLA is used to implement the priority logic. No changes to the Compare circuitry. Here’s the LED matrix circuitry. An AND gate was added to allow software
resets only when device is enabled. Here’s the ControlledDriver I mentioned before. That covers all the changes I noticed. In order to put the circuit into an FPGA,
the non-synthesizable components have to be removed. Here’s one version of the removal. Also the RAM size is
reduced. Here’s another version meant to be put in
a Terasic DE0 Nano FPGA board, and it also has a smaller RAM. More importantly, it uses a trimmed
down ALU. I don’t know why the multiplication and division
components were removed. Maybe at that time, Kevin’s Logisim couldn’t
synthesize these components or maybe they were removed so that
the design would fit into the Nano. I don’t know, but this change to the ALU means
that a new version of the CPU that uses the trimmed down ALU is
required. These various versions can now all be simulated
independently by using the Simulate tab I’ll show later. Here’s a new feature of Kevin’s version of
Logisim. It allows the RAM to
load files of many different formats and it will make an initial guess as to the
format of the file. This is what I was referring to when I said
Kevin made his version a lot faster. It now has many clock speeds above the previous
4 KHz maximum. I haven’t looked at the source code, but I
would imagine that he achieves these speeds by doing the same thing video players
do when the hardware or internet connection can’t keep up with the speed of
the video. In that case frames are
dropped. Due to the nature of most compression algorithms,
the dropped frames are still processed, just not displayed. So likewise, in this Logisim, I
believe that the logic state changes of the components are still being processed
just not always shown. If you need to know precisely how the logic
states change, you would need to select a lower clock
speed. But, Kevin’s speed-ups
go beyond this – he apparently used a code profiler to find out where the code
was slowing things down. Another new feature of Kevin’s Logisim is
the State list. It lists the
current values of various components. Here’s the Simulate tab I mentioned before. You can select which circuit
simulations you want to run and also see which subcircuits each simulation
uses. I’ll try synthesizing the nano circuit to
a Terasic DE0 Nano. I’ll select
VHDL, and show that I already inputted the various paths. The components need
to be mapped to the FPGA board being used. I don’t know if this board can
do everything needed, so I’ll select Disconnected for some of these components. Every component has to be assigned to something
in order to continue, so if you don’t know what to assign to, select Disconnected. I’ll speed this up so it
won’t be boring. I don’t have an FPGA board, so I’ll stop here. These are the
options you can select. By the way, for some things, you would have
to select the slower speed. One example is the KITT or Cylon effect in
my program. You may have noticed that the text displayed
in the TTY screen now goes beyond the borders of the TTY screen. This is because the font doesn’t scale
along with the zoom level. Zooming to 100% solves this problem. Now, I’ll show some footage that Kevin shot,
but with overlays added by me. Here, I assume since Kevin is using a Terasic
DE0 instead of a Nano, he chose to synthesize more of the design. However, many of the components had to be
removed because they couldn’t be synthesized or didn’t have equivalents
on the DE0. The FPGA is starting up. There’s even a KITT effect for free! And now the
design is transferred to the FPGA board. The CPU is ready to run the program,
so the Start button is pressed. It’s the simple program shown earlier in
Logisim. It behaves correctly in responding to keyboard
input. Now, the CPU
is reset, and then the CPU is started again just to show that everything works. By the way, the 7 segment displays are showing
the lower 16 bits of the instruction being executed. They are showing 8808 because the CPU is running
at 25Mhz which is too fast to see the individual values. Most just blend
together in an 8. Also, the CPU cycle state LED appears constantly
lit rather than blinking. Here’s how the board would behave if the design
was downloaded again. So, in order to show the 7 segment displays
better, Kevin added the ability to select the speed of the CPU on the fly. This was achieved by using the
Dynamic Clock Control component that’s under the “BFH mega functions” component
list category. By the way, the previously synthesized design
is easier to see now. Note, this version has a different RAM size. It is also clear that this
version of the CPU is a little different than the one shown
earlier. The M_to_A line was removed from the A register
as I talked about before. The Control ROM was reduced in size and the
control lines were reorganized which means the values in the
ROM had to be recomputed. The M_to_A line was renamed to M_to_AB to
better reflect it’s function. And
the MUX on the Y register appears to now be back to being a normal MUX, rather
than a priority MUX, but without the priority encoder. By the way, it appears
that the full ALU is being used rather than the trimmed down one, but I’m not
sure. The dynamic clock control divides the main
clock by the value selected. Here’s a table of the values and their meanings. Dynamic Speed must be selected here to use
the dynamic clock control with the FPGA board. Here, Kevin shows how he assigned some of
the various components to the FPGA board. For the DipSwitch, the component had to be
switched from DIPSwitch to Expanded in order to assign the individual
switches. The down arrow allows
you to change the setting. Likewise, the speed control had to be switched
from Ribbon to Expanded in order to assign the
individual pins. And the RGBLED had
to be switched to Expanded from RGBLED since the DE0 doesn’t have RGB LEDs. Now, the new speed control will be tested. The 3 rightmost switches set the
speed. The instructions can now clearly be seen,
and the CPU cycle state LED blinks. The leftmost switch turns the instruction
display on and off, and by off I mean all zeros. Here’s another run of it. Setting it to 100Hz now shows the
8808 again, but it’s clear the 8808 isn’t constant. And faster speeds show a
solid 8808. Well, it’s been quite a journey from my on
paper CPU design homework assignment to actual hardware. I would like to thank Kevin for his work
on improving Logisim and also his work putting my design in hardware. Kevin
tells me he would like to implement the video screen, but due to the limited
size of the DE0’s internal RAM, the screen would have to be low res VGA with
reduced color resolution, but it should be doable. Off-chip memory could be
used which would allow a better display, but would require driver code to be
written. We’ll see how this progresses. If you haven’t done so yet, please subscribe,
like, share, comment, etc. And if you click subscribe, click the bell
to receive notifications of future videos. Even if you click the bell, still check back
from time to time since YouTube doesn’t always notify subscribers.

2 thoughts to “My CPU Design in an FPGA Via Collaboration with Dr. Kevin Walsh & His Improvements to Logisim”

Leave a Reply

Your email address will not be published. Required fields are marked *