Subversion Repositories zipcpu

Compare Revisions

  • This comparison shows the changes necessary to convert path
    from Rev 207 to Rev 208
    Reverse comparison

Rev 207 → Rev 208

0,0 → 1,17
# Welcome to the ZipCPU!
## Installation instructions
The ZipCPU repository contains a couple of very basic cabilities, some very necessary to any user, some only necessary to the hard core users, some not so much.
- It contains the [binutils](sw/binutils-2.27-zip) and [GCC compiler with ZipCPU backend](sw/gcc-6.2.0-zip) used by all implementations of the ZipCPU. *This is very necessary.*
- It contains a copy of [newlib](sw/newlib-2.5.0-zip). However, the [libgloss](sw/newlib-2.5.0-zip/libgloss/zip) directory within it is specific to the ZBasic architecture. Right now, the answer is to roll your own libgloss for any new architecture.
- It contains a [specification document](doc/spec.pdf), describing the CPU and its instruction set, together with the sources files to build that specification. This is different from a user's guide, or a specification document for your particular board implementation. (The ZipCPU is *very* generic, allowing you to build your bus and place items within it at any address of your choosing.)
- It contains a copy of the Verilog RTL describing the ZipCPU. This is useful should you ever wish to build your own project using the ZipCPU. However, if you are just trying to use an existing SoC implementation, you can safely ignore this directory.
- It contains two simulators: [one](sim/cpp) independent of the RTL, the [second](sim/verilator) based upon the RTL. Neither of these simulators is as good as a proper simulator of a SoC, but they remain here for ... whatever reasons.
- It contains my first attempt at building an Assembler. Well, it does until I eventually remove it from the repository as unnecessary ...
- It also contains the source code for an example assembly level [debugger](sw/zipdbg). This will probably be replaced in time with an implementation of gdb, but it remains for the time being.
Prior to building within the ZipCPU repository directory, you need to make certain you have a number of prerequisites. These include: texinfo gcc-dev g++-dev flex bison libbison-dev verilator libgmp10 libgmp-dev libmpfr-dev libmpc-dev libelf-dev and ncurses-dev.
To build all of the above, type _make_ in the main repository directory. This will build the tools and place them into a [local install directory](sw/install/cross-tools/bin). Sadly, this process will currently fail about halfway through. To get past this, add the [install directory](sw/install/cross-tools/bin) to your path and restart. _make_ will then pick up where it left off and finish the task.
The ZipCPU build process does not yet install anything into your local system. All of the tools generated (currently) will be left in the local [install directory](sw/install).
0,0 → 1,50
# The Zip CPU
The Zip CPU is a small, light-weight, RISC CPU. Specific design goals include:
- 32-bit. All registers, addresses, and instructions are 32-bits in length. While the byte-size itself was at one time 32-bits, the CPU now handles 8-bit bytes like all other CPUs
- A RISC CPU. The ZipCPU does not implement any microcode for executing instructions. Instructions nominally complete in one cycle each, with exceptions for multiplies, divides, memory accesses, and (sometime) floating point instructions.
- A load/store architecture. Only load and store instructions may access memory.
- Wishbone compliant. All memory and peripherals are accessed across a single wishbone bus.
- A Von-Neumann architecture, meaning that both instructions and data share a common bus.
- A pipelined architecture, having stages for prefetch, decode, read-operand(s), a combined stage containing the ALU, memory, divide, and floating point units, and then the final write-back stage.
- A two mode machine: supervisor and user, with each mode having a different access level.
- Completely open source, licensed under the GPL.
## Unique features and characteristics
- Only 29 instructions are currently implemented. Six additional instructions have been reserved for a floating point unit, but such a unit has yet to be implemented.
- (Almost) all instructions can be executed conditionally. Exceptions include load immediate, the debug break instruction, the bus lock and simulation instructions, and the no-operation instruction.
- Simplfied wishbone bus. While the ZipCPU conforms to the Wishbone B4 standard, some simplifications have been made. All tgx lines have been removed, although the select lines have been kept. All accesses are (or can be) pipelined. Finally, the ZipCPU project (and its daughter projects/[peripherals](rtl/peripherals) assumes that the strobe line is zero whenever the cycle is zero. This simplifies peripheral processing.
- The CPU makes heavy use of pipelined wishbone processing wherever and whenever it can. Hence, loading two vaues in a row may cost only one clock more than just loading the one value.
- The CPU has no interrupt vectors, but rather two register sets. On any interrupt, the CPU just switches from the user register set to the supervisor register set. This simplifies interrupt handling, since the CPU automatically saves, preserves, and restores the supervisor's context between enabling interrupts and receiving the next interrupt. An [interrupt peripheral](rtl/peripherals/icontrol.v) handles the combining of multiple interrupts into a single interrupt line.
## Current Status
20170309: The CPU has just been updated for 8-bit byte support. Several additional changes include:
- The CPU has been rebuilt to add four new instructions, LB (load byte), SB (store byte), LH (load half-word or short), and SH (store half-word or short).
- The LOD/STO instructions have been renamed LW (load word) and SW (store word) respectively.
- The CPU is now also, as a result, completely big--endian, which it only sort of was before.
- The maximum wishbone bus address width of the CPU is no longer 32-bits, where each address references a 32-bit number, but rather 30-bits. The final two bits are used to determine the values of the (new) select lines. This means that the ZipCPU now suffers from the same 4GB memory limit as all other 32-bit CPUs.
- The instruction set has been reordered--programs written for the 32-bit byte master branch will not work on this 8-bit byte branch.
- The greater than (GT) condition has been replaced by a not-carry (NC) condition, in order to simplify what the compiler needs to do for unsigned numbers.
- The machine ID in the ZipCPU ELF/object files has been changed from 0xdadd to 0xdad1, to reflect this change. (This is an unregistered ID, so ... there _may_ be other computers out there with this ELF ID ...)
- The ZipCPU supports several new simulation support or SIM instructions. These can be used to write messages to the simulator console if desired.
- There are now two simulators for the ZipCPU: A [C++ simulator](sim/cpp) that is independent of the Verilog, and a [Verilator]( based [simulator](sim/verilated) that exercises the CPUs core logic.
- The two simulators are designed to closely match the performance of a bare-bones [basic ZipCPU system]( Further, the newlib library as built is designed to support this minimum ZipCPU implementation.
- The Assembler now implements the Compressed Instruction Set (CIS) by default when it can. (This instruction set was formerly and inappropriately named the VLIW instruction set. It has since been redesigned.) Instruction words using this format can pack two instructions into a single instruction word.
Unlike the ZipCPU before these changes, newlib now compiles and appears to work with the ZipCPU (without floating point support).
Also, unlike before, the ZipCPU is now small enough to be able to include a divide unit, and a double-fetch (uses pipelined WB for one word) when build for the Spartan-6/LX4.
## Not yet integrated
- An [MMU](rtl/peripherals/zipmmu.v) has been written for the ZipCPU, but not yet integrated into it
- Likewise, a [data cache](../../tree/master/rtl/core/dcache.v) has been written for the ZipCPU, but not yet integrated into it
- I would also like to integrate [SDCard support]( into the newlib C-library to give the CPU file access
- The [ZipOS]( would greatly speed up and improve the bare bones newlib library.
## Commercial Opportunities
If the GPLv3 license is insufficient for your needs, other licenses (for all but
the tool-chain) can be purchased from Gisselquist Technology, LLC.
25,7 → 25,7
// for more details.
// You should have received a copy of the GNU General Public License along
// with this program. (It's in the $(ROOT)/doc directory, run make with no
// with this program. (It's in the $(ROOT)/doc directory. Run make with no
// target there if the PDF file isn't present.) If not, see
// <> for a copy.
50,6 → 50,8
TESTB(void) : m_trace(NULL), m_tickcount(0l) {
m_core = new VA;
m_core->i_clk = 0;
eval(); // Get our initial values set properly.
virtual ~TESTB(void) {
if (m_trace) m_trace->close();
58,9 → 60,11
virtual void opentrace(const char *vcdname) {
m_trace = new VerilatedVcdC;
m_core->trace(m_trace, 99);
if (!m_trace) {
m_trace = new VerilatedVcdC;
m_core->trace(m_trace, 99);
virtual void closetrace(void) {
77,9 → 81,13
virtual void tick(void) {
//if((m_trace)&&(m_tickcount)) m_trace->dump(10*m_tickcount-4);
// Make sure we have our evaluations straight before the top
// of the clock. This is necessary since some of the
// connection modules may have made changes, for which some
// logic depends. This forces that logic to be recalculated
// before the top of the clock.
if ((m_trace)&&(m_tickcount)) m_trace->dump(10*m_tickcount-2);
if (m_trace) m_trace->dump(10*m_tickcount-2);
m_core->i_clk = 1;
if (m_trace) m_trace->dump(10*m_tickcount);

powered by: WebSVN 2.1.0

© copyright 1999-2022, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.