While I was driving like a maniac in the crazy DC traffic, I got to thinking that any project worth doing -- like our single bit processor -- deserves a top secret codename so that nobody will know what it's about but us. Besides, we give everything a name here in the South.
It didn’t take long before I came up with "Little Bit," for reasons that should be obvious. Also, based on your comments to my previous column, this won't be the first time the old 14500 has sparked interest enough for someone to work up a new version. However, our goal should be to only use the official "MC14500B Data Sheet" as our reference -- sort of a "clean room" approach. Everything is there for us to dig out. So, let's get started!
A brief project overview
Since we're going to resurrect Little Bit in a modern PLD (programmable logic device) -- in the form of a CPLD or FPGA -- we have a few things to consider. For example, it's really not possible to create a direct replacement for the original 4000-series CMOS in a PLD due to big timing and electrical differences. Therefore, we'll focus on honoring the architecture and functionality of the 14500B by creating a soft core that can be used as a system building block.
Another consideration is the fact that the 14500B had a bidirectional -- and hence tri-stateable -- data bus. But tri-state signals within an PLD are troublesome and not even necessary, so instead we will put the 1-bit data "bus" into separate "datai" (Data In) and "datao" (Data Out) signals.
Yet another point to consider is the fact that the 14500B operated from an external crystal or oscillator, and it could be run from DC to 1MHz. By comparison, most PLDs have elaborate internal clock resources that we don't need to use. So, we'll assume a fixed clock of 1MHz is coming into our core, although we could run much faster, should we need to or just want to.
Refer to the MC14500B data sheet
If you missed Part 1, you can get your very own MC14500B Data Sheet from the Data Sheet Archive. You'll need to be looking at this to follow along with what I'm talking about.
Defining the MC14500B ICU pins in HDL
Remember that the 14500B was officially referred to as an Industrial Control Unit (ICU). In VHDL, we can define the Little Bit (ICU) pins and their types as follows:
Of course, someone's probably going to start yelling about how you can reduce the amount of typing you have to do as follows:
I know you can, but I'm not doing so because I want all of this to be as understandable as possible for newcomers to HDLs (hardware description languages) in general and VHDL in particular.
The ICU's architecture
Studying the 14500B's block diagram from the data sheet reveals a lot about the processor's architecture. In our port declaration above, you'll see that we have replaced the "X1" and "X2" crystal oscillator signals with "clk"; also we have split the bi-directional "DATA" pin into separate "datai" and "datao" signals.
MC14500B block diagram.
Note that it's unclear what the RST (reset) signal does from the block diagram. If you look at the timing waveform diagrams in the data sheet, however, you'll see that this signal affects the IEN (input enable) register, the OEN (output enable) register, and the RR (result register).
@Paul: I am also interested in computer architecture and am working on a design that runs if/else, for, while, do, assign.
Since the FPGA cannot run at the clock speed of an ASIC, the memory blocks and big LUTS allow parallel accesses and ALU speed that reduces the number of cycles compared to the typical compile to ISA approach. Data width and address widths are whatever is appropriate and the memories do the register function.
It simply does more per cycle to make up for clock speed.
Karl wrote: "Of all the ISAs, only a few are available on an FPGA. One of the key optimizations is register management so how many can use a wider word to increase the number of registers? Instead, I think the wider word is used mainly for memory address modes."
If OpenRISC 2K ever gets developed, it will use VLE for code density and shorter instructions will have access to fewer registers. (The SPARC example--certainly not FPGA-appropriate--was also used to increase the count of addressible registers.) Immediates (for addressing memory--code or data--and for constants used in computation) are probably the most significant use of larger and variable length instructions, but opcodes can also eat encoding space.
Karl also wrote: "The ICU is the discussion topic and its intended use is control logicimplementation. It is not a CPU by any stretch. It does not drive the memory, rather it is driven by the memory.
If we get distracted trying to study every ISA then there will be absolutely no progress."
I agree and did not mean to cause excessive distraction (the comment on non-existence of VLE ISAs just seemed wrong enough--in a general context not specifically VLEs used in FPGAs to increase register count--to warrant correction). (This is a danger for me because I am a computer architecture enthusiast, so your warning is, alas, likely appropriate.)
'Little Bit' may provide an interesting introduction into some concepts useful for more involved designs, though I do wonder if it is too simple--perhaps particularly in requiring decisions about characteristics outside of the ICU that allow the system to function--, making such in a design more difficult to use in later projects. Providing simplicity (ease of understanding), utility (ease of producing useful results that reward effort), and extendability (ease of slightly adjusting or adding to the existing base to address new goals) can be difficult.
@Paul: Of all the ISAs, only a few are available on an FPGA. One of the key optimizations is register management so how many can use a wider word to increase the number of registers? Instead, I think the wider word is used mainly for memory address modes.
To take S360 as an example:
RR format 8 bit opcode, 2 x 4 bit register select fields
RX and RS 8 bit opcode, 3 x 4 bit register select fields, 12 bit address
SI 8 bit opcode, 8 bit operand, 1 x 4 bit reg select, 12 bit address
SS 8 bit opcode, 2 x 4 length, 2 x 4 reg sel, 2 x 12 bit address
In reality, some regs were dedicated and not usable for processing and there was the typical movement of data in and out of memory to get the operands into registers for processing.
The instruction lengths depended on the addressing modes
The ICU is the discussion topic and its intended use is control logicimplementation. It is not a CPU by any stretch. It does not drive the memory, rather it is driven by the memory.
If we get distracted trying to study every ISA then there will be absolutely no progress.
@hamster: Great start - and written in C instead of BASIC! Are we free to give it a go? Also, I think it's good that you targeted 16-bit wide output. We can write simple parsers to re-organize the output to meet any memory organization. Little Bit uses an inerleaved 8-bit-wide external ROM: Even address: A7..A0; Odd: i3..i0,A11..A8.
b16-small is licensed under GPL (according to the paper "b16-small—Less is More") which is not the same as public domain--it requires the providing of source code under the same license for any "linked" content that is distributed with the GPLed content.
(It is not clear what "linked" content is in the context of a processor, especially for an FPGA design. I would tend to use the interpretation used by the Linux community where components using a standard interface (syscalls for Linux, memory and I/O interfaces for the stack processor) are not considered "linked". One could ask Bernd Paysan to clarify if the documentation provided with the source code is not sufficiently clear.)
Karl wrote: "All the bits to select registers, ALU functions, and transfer data in and out of memory must fit in a fixed length instruction word."
A lot of ISAs use variable length instruction encodings (x86, IBM S/360, Renesas RX), even ARM and MIPS have been extended with VLE versions/modes (Thumb2 and microMIPS, respectively). (The Power specification also supports VLE and one variation of SPARC has an instruction that adds 15 bits to each of the next two instructions.)
An FPGA allows greater flexibility, but the width of block RAMs (and hard memory interfaces) tends to constrain variability of "parcel" size (the granularity of variability in instruction length).
Somewhat off-topic: I have read that Bernd Paysan's b16 has a very small implementation that might be of interest to people here. http://bernd-paysan.de/b16.html
Ken Boyette has worked around machines all his life, but he's having trouble with the idea of interacting with them the way one would interact with another person.
In this column, KenwickVS (a.k.a. Ken Boyette) walks us through the VHDL code for his interpretation of the famous Motorola MC14500B single-bit processor.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
