When the home computer revolution arrived, it filled my childhood with fascination and inspired me to study computer engineering. I wanted to design a microcomputer to my own specifications. But at school I was never taught how a complete computer system was put together. Instead we studied various subsystems and the theory of things like digital signal processing and so on. Somebody, somewhere else, would always be responsible for assembling the whole system and making everything work together.
This was unfortunate and unjustified: Putting a complete working computer together isn’t difficult, and it can give students critical early confidence in their ability to live up to the label “computer engineer.” So, having recently retired from the high-tech industry, I decided to design a didactical but fully functional computer that could serve as a platform for learning and experimenting with system-level design issues—the Cerberus 2100.
I didn’t want to commit Cerberus to a particular CPU, as doing so would conflate system-level architecture concepts with the specific timings and control signals of that CPU. Much as a software-engineering course focuses on the structure of an algorithm rather than the syntax of its implementation in a particular language, I wanted Cerberus to focus on the system-level structure. Cerberus is thus a multi-CPU system, featuring both a Z80 and a W65C02S (6502), two well-known workhorse 8-bit processors that featured prominently in the home-microcomputer era. There is a wealth of resources available for learning how to program these processors, which are powerful enough to be useful and entertaining, yet simple enough to master.
The problem, of course, is that these two CPUs operate with very different interfaces to other parts of the computer, such as memory or input/output devices. For instance, the 6502 uses a single control line to indicate whether it is reading or writing to the data bus, while the Z80 uses two lines. This means the 6502’s signal needs to be combined with the signal from the system clock, via an AND gate, to prevent memory miswrites, while the Z80 has no such issue. Also, the Z80 has an output line to signal that the value on the address bus is stable, a function absent in the 6502. And so on.
These differences mean that I couldn’t use a standard control bus in the Cerberus. Instead, I used a large complex programmable logic device (CPLD) chip I dubbed “Fat-Spacer” to translate the control signals of each CPU into an abstraction layer. This layer defines the system architecture. Fat-Spacer then translates the output of the abstraction layer into the appropriate input signals for each component in the system. These two steps of translation entail both Boolean logic and timing control through flip-flops. I used a CPLD instead of an FPGA (field-programmable gate array) because, unlike FPGAs, CPLDs have a fixed propagation delay regardless of the Boolean logic implemented in them. This is critical because it allows users to make changes to the system architecture—by reprogramming the CPLD—without having to worry that the complexity of their changes will take too long to pass through a chain of logic gates, and so miss the timing windows imposed by the system clock.
Because of its internal abstraction layer, Cerberus is uniquely suitable for expansion: A direct memory access (DMA) expansion port is also connected to Fat-Spacer. By directly allowing access to system memory, I let the user add even more CPUs and microcontrollers to the system via the expansion port.
Another critical design challenge was to decouple the logic of the computer from the timings of the video circuitry
Another critical design challenge I faced was to decouple the system-level logic of the computer from the timings of the video circuitry. Traditionally, these two are tightly tied together so as to coordinate access to video and character memories by the CPU and display circuitry without causing conflicts or artifacts. But with two CPUs and the DMA expansion port, this wasn’t an option.
Instead, Cerberus uses two dual-ported static RAMs (SRAMS) as video and character memories. Each port allows asynchronous access to the memory’s contents. One port of each SRAM is connected to the computer proper, while the other is exclusive to the video circuitry.
The Z80 and 6502 processors use different control signals to interface with memory and interface chips. A reprogrammable logic chip, dubbed Fat-Spacer translates these signals as required. Another reprogrammable logic chip handles storage and the keyboard interface, while a third generates video signals. James Provost
Despite the dual-ported memories, onscreen glitches could still happen if the video circuitry was to read from a given address as the computer wrote to that same address. Fortunately, dual-ported SRAMs provide a “BUSY” signal to indicate a conflict. This signal is used by Fat-Spacer to pause the CPUs for the duration of the conflict. The control abstraction layer comes very handy here too, as it already has the appropriate translation logic for pausing the CPUs.
Fat-Spacer isn’t the only CPLD in Cerberus: Three of them constitute the system’s core chipset. Fat-Cavia continuously scans the video and character memories, and sends bitmaps to Fat-Scunk, which then generates the appropriate RGB signals and synchs pulses to create a 320-by-240-pixel VGA output. Meanwhile, as we’ve seen, Fat-Spacer provides the glue logic. Finally, there’s an additional chip: Fat-Cat, which is actually an ATmega328PB microcontroller. This is used to handle I/O: The microcontroller manages a keyboard, buzzer, the expansion protocol, and a microSD card for storage. The I/O firmware is held in the ATmega’s memory, meaning it leaves no memory footprint in the 64 kilobytes of RAM accessible to the Z80 and 6502.
The Cerberus 2100 is an open hardware design available to all and complete details are available on my website. But for those who don’t want to build their own machine from scratch, I am working with European electronics company Olimex for the sale of a fully assembled version shortly. I hope it helps students and hobbyists to understand—and faculty to teach—how a complete, fully functional computer can be put together, regardless of the target CPU.
This article appears in the November 2023 print issue as “Software-Defined Architecture.”
Reference: https://ift.tt/SCl0X9s
No comments:
Post a Comment