Recent changes to Project OpenSOC86

Home modified by Roy van Koten

2014-09-16T23:52:29.019000Z

--- v9
+++ v10
@@ -28,7 +28,9 @@
 Credits
 -------
 Most of the work, hardware and software, is (C) Copyright 2013-2014 Roy van Koten. All of these hardware and software source files are released under the GNU GPLv3 license. Read the LICENSE file included.
+
 For any other software or file not created by me check the corresponding license and copyright notices.
+
 Most test files are from the Zet processor project by Zeus Gomez Marmolejo. The Zet project is licensed under the GNU v3 license. See http://zet.aluzina.org/

 The MSDOS 6.22 floppy image is from the fake86 project by Mike Chambers. http://fake86.rubbermallet.org/
@@ -44,6 +46,7 @@
 This 'system on chip' (SOC) is free hardware: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. 

 This SOC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.
+
 You should have received a copy of the GNU General Public License along with this program.  If not, see <http: www.gnu.org="" licenses=""/>.

BuildSOC modified by Roy van Koten

2014-09-16T23:50:53.661000Z

--- v1
+++ v2
@@ -7,7 +7,7 @@

 Instead of running tests we will now boot the Bios and MSDOS. All the binary ROMs and disk images for this are contained in the bin directory. This directory should be used when referring to binary files from within source code.

-The Bios could be compiled from scratch. Bios source code and compiled images are stored in the bios directory. Currently it contains the source code of the pcxtbios25 by Miles (1987) and Petrosky. See the readme file within the subdirectory for license and more info. All necessary tools and the make file (make.bat) for compiling the bios are included. However these tools are 16bit and do not run on modern Windows systems. DOSBox can be used for running these tools. (See http://sourceforge.net/projects/dosbox/)
+The Bios could be compiled from scratch. Bios source code and compiled images are stored in the bios directory. Currently it contains the source code of the pcxtbios25 by Miles (1987) and Petrosky. See the readme file within the subdirectory for license and more info. All necessary tools and the make file (make.bat) for compiling the bios are included. However these tools are 16-bit and do not run on modern Windows systems. DOSBox can be used for running these tools. (See http://sourceforge.net/projects/dosbox/)

 The MSDOS 6.22 floppy image is also located in the bin directory. This floppy image is borrowed from the fake86 project. (http://fake86.rubbermallet.org/)

BuildCPU modified by Roy van Koten

2014-09-16T23:47:16.200000Z

--- v2
+++ v3
@@ -3,9 +3,9 @@

 Before compiling one of the projects in Quartus, multiple other files are needed or need to be build first.

-The CPU itself, and thus all the projects, will need the build microcode memory file. The microcode definition file is stored in the ucode directory. This file is in a custom format which can be read by the UCodeBuilder tool. This tool creates the microcode memory file and stores it in the ….TODO... directory. A precompiled microcode file should already be included with this package.
+The CPU itself, and thus all the projects, will need the build microcode memory file. The microcode definition file is stored in the ucode directory. This file is in a custom format which can be read by the UCodeBuilder tool. This tool creates the microcode memory file and stores it in the rt/cpu directory. A precompiled microcode file should already be included with this package.

-The CPU still needs something to run. There are several tests for checking the CPUs functional correctness located in the test directory. Most of these files come from the Zet processor project by Zeus Gomez Marmolejo. The Zet project is licensed under the GNU v3 license. See http://zet.aluzina.org/ for more info. The assembly source code of these tests is located in the test/src directory. The test/bin subdirectory contains the compiled binaries. The cpu needs these files in hex format, which will be located in the test/hex directory. The test programs can be compiled with the tools given in the previous section.
+The CPU still needs something to run. There are several tests, for checking the CPUs functional correctness, located in the test directory. Most of these files come from the Zet processor project by Zeus Gomez Marmolejo. The Zet project is licensed under the GNU v3 license. See http://zet.aluzina.org/ for more info. The assembly source code of these tests is located in the test/src directory. The test/bin subdirectory contains the compiled binaries. The cpu needs these files in hex format, which will be located in the test/hex directory. The test programs can be compiled with the tools given in the previous section.

 To compile and create the binary files run:

Description modified by Roy van Koten

2014-09-16T23:39:42.489000Z

--- v2
+++ v3
@@ -1,9 +1,9 @@
 Description
 -----------

-The complete design is split up in three projects: The cpu project for designing and testing the processor only. The soc project is used for simulating the cpu together with several peripherals like the timers, DMA controller and others. This is enough to boot the Bios and MSDOS in simulations. All the memory controllers (and cache) are not included in this project. The test bench loads all ROMS and provides a memory interface to the cores. The socmem project contains the complete system, including the memory controllers. This project is still in development and thus not yet included in this version. This project will result in the actual synthesized design which can be loaded into a FPGA. All the Quarts project files are located in the project directory.
+The complete design is split up in three projects: The cpu project for designing and testing the processor only. The soc project is used for simulating the cpu together with several peripherals like the timers, DMA controller and others. This is enough to boot the Bios and MSDOS in simulations. All the memory controllers (and cache) are not included in this project. The test bench loads all ROMS and provides a memory interface to the cores. The socmem project contains the complete system, including the memory controllers. This project is still in development and thus not yet included in this version. This project will result in the actual synthesized design which can be loaded into a FPGA. All the Quartus project files are located in the project directory.

-All Verilog hardware description file are stored in the rtl directory. Each project will use these source file when needed. The cpu subdirectory contains the complete source code for the processor. All peripheral source code is stored in the peri subdirectory.
+All Verilog hardware description files are stored in the rtl directory. Each project will use these source files when needed. The cpu subdirectory contains the complete source code for the processor. All peripheral source code is stored in the peri subdirectory.

 Technical Description
 ---------------------

Hazards modified by Roy van Koten

2014-09-16T23:37:26.368000Z

--- v3
+++ v4
@@ -1,7 +1,7 @@
 Hazards
 -------

-Hazard detection still needs to be added for segment registers and memory access. For register to register instructions hazards are resolved. Simultaneous reads and writes to the register file are resolved with bypassing. In other cases a two clock bubble is inserted regardless of the distance in clocks between the read and write cycles. This can be further improved. When reading from memory a stall signal can delay execution of all pipeline stages until cache or memory is ready. The tables below give a few examples of hazards and stalls that can occur.
+Hazard detection still needs to be added for segment registers and memory access. For register-to-register instructions hazards are resolved. Simultaneous reads and writes to the register file are resolved with bypassing. In other cases a two clock bubble is inserted regardless of the distance in clocks between the read and write cycles. This can be further improved. When reading from memory a stall signal can delay execution of all pipeline stages until cache or memory is ready. The tables below give a few examples of hazards and stalls that can occur.

 No hazards

Architecture modified by Roy van Koten

2014-09-16T23:36:10.917000Z

--- v4
+++ v5
@@ -1,7 +1,7 @@
 OpenSOC86 Pipeline
 ----

-The processor is design with a nine-stage pipeline. The main execution stage may be somewhat unusual. Because the x86 architecture has instructions that can do calculations and multiple memory accesses with a single instruction, it would take multiple cycles to execute these with a classic RISC pipeline. A dedicated unit for effective-address calculation can be added to improve the efficiency of a RISC pipeline. The current ‘RMXW’ pipeline is chosen in order to use this extra unit even more efficiently and execute much more instructions in a single pipeline cycle. The choice for this pipeline does result in extra hazards when instructions try to read memory before the same address is written to by a previous instruction. However these hazards can be resolved quite easily. A description of the pipeline is shown below.
+The processor is designed with a nine-stage pipeline. The main execution stage may be somewhat unusual. Because the x86 architecture has instructions that can do calculations and multiple memory accesses with a single instruction, it would take multiple cycles to execute these with a classic RISC pipeline. A dedicated unit for effective-address calculation can be added to improve the efficiency of a RISC pipeline. The current ‘RMXW’ pipeline is chosen in order to use this extra unit even more efficiently and execute much more instructions in a single pipeline cycle. The choice for this pipeline does result in extra hazards when instructions try to read memory before the same address is written to by a previous instruction. However these hazards can be resolved quite easily. A description of the pipeline is shown below.

 [[img src=pipeline.jpg]]

Features modified by Roy van Koten

2014-09-16T23:33:34.600000Z

--- v1
+++ v2
@@ -2,7 +2,7 @@
 --------
 * 8086 instruction set (with a few known bugs)
 * 100 MHz Fmax in Cyclone II speed grade -6
-* Pipelined execution of register to register instructions 
+* Pipelined execution of register-to-register instructions 
 * Single clock domain
 * Able to switch between pipelined and none-pipelined execution at runtime 
 * Boots IBM PCXT compatible bios and MSDOS 6.22

Status modified by Roy van Koten

2014-09-16T23:33:00.992000Z

--- v2
+++ v3
@@ -3,13 +3,13 @@

 The OpenSOC86 project is still in development. The current version can boot an IBM PCXT compatible bios and boot DOS from a floppy disk image in simulation. 

-This version only runs in simulation and is not yet hardware proven. However the complete SOC is written in 100% synthesizable Verilog code. In order to load the SOC into a FPGA, a SD Ram, S Ram, SD Card and Cache controller need to be added. Also there is an incompatibility issue with the instruction buffer and SD Ram behavior. The instruction buffer assumes 8 word bursts from SD Ram can start at any memory location without addresses wrapping around. These features are currently in development. 
+This version only runs in simulation and is not yet hardware proven. However the complete SOC is written in 100% synthesizable Verilog code. In order to load the SOC into a FPGA, a SDRAM, SRAM, SD-Card and Cache controller need to be added. Also there is an incompatibility issue with the instruction buffer and SDRAM behavior. The instruction buffer assumes that 8 word bursts from SDRAM can start at any memory location without addresses wrapping around. These features are currently in development. 

 There are several known bugs in the cpu core. These are reported by the test code. Even with these bugs the system is able to boot the PCXT bios and MSDOS. 

 Most peripherals are implemented minimally. These should be extended in the future. Peripherals like keyboard and mouse controllers are not yet developed. 

-The CPU is meant to be fully pipelined. Currently all register to register instructions execute in a pipelined matter. Data hazards are resolved by inserting a two clock bubble in all cases where a hazard occurs. Hazards due to simultaneous reads and writes to the register file are resolved with bypassing. Due to the pipeline length, the two clock bubble will either result in resolving the hazard or a new read/write hazard will occur which is again resolved with bypassing. 
+The CPU is meant to be fully pipelined. Currently all register-to-register instructions execute in a pipelined matter. Data hazards are resolved by inserting a two clock bubble in all cases where a hazard occurs. Hazards due to simultaneous reads and writes to the register file are resolved with bypassing. Due to the pipeline length, the two-clock bubble will either result in resolving the hazard or a new read/write hazard will occur which is again resolved with bypassing. 

 Instructions that access memory are executed in a none-pipelined manner. In order to pipeline these, hazard detection needs to be added for segment registers.

Status modified by Roy van Koten

2014-09-16T23:29:06.309000Z

--- v1
+++ v2
@@ -1,7 +1,7 @@
 Development Status
 ------------------

-The OpenSOC86 project is still in development. The current version can boot a IBM PCXT compatible bios and boot DOS from a floppy disk image in simulation. 
+The OpenSOC86 project is still in development. The current version can boot an IBM PCXT compatible bios and boot DOS from a floppy disk image in simulation. 

 This version only runs in simulation and is not yet hardware proven. However the complete SOC is written in 100% synthesizable Verilog code. In order to load the SOC into a FPGA, a SD Ram, S Ram, SD Card and Cache controller need to be added. Also there is an incompatibility issue with the instruction buffer and SD Ram behavior. The instruction buffer assumes 8 word bursts from SD Ram can start at any memory location without addresses wrapping around. These features are currently in development.

Home modified by Roy van Koten

2014-09-16T23:28:44.879000Z

--- v8
+++ v9
@@ -3,7 +3,7 @@

 OpenSOC86 is an open implementation of the x86 architecture in Verilog. The current version only implements the 16-bit part (real mode). The processor is a pipelined architecture clocked at 100 MHz in a Cyclone II speed grade -6. Therefore it can be seen as similar to a 486 in real mode.

-Several peripherals are also implemented in a somewhat minimalistic way, but enough to be able to boot an IBM PCXT compatible bios and MSDOS 6.22. The current implementation is only proven to boot the bios and DOS in simulation. The system is targeted to run on the DE2-70 board. In order to run the system in hardware a SD-ram and S-ram controller need to be added. These are currently in development.
+Several peripherals are also implemented in a somewhat minimalistic way, but enough to be able to boot an IBM PCXT compatible bios and MSDOS 6.22. The current implementation is only proven to boot the bios and DOS in simulation. The system is targeted to run on the DE2-70 board. In order to run the system in hardware a SDRAM and SRAM controller need to be added. These are currently in development.

 Current Release