head 1.1; access; symbols; locks; strict; comment @# @; 1.1 date 2005.01.30.20.41.39; author mikej; state Exp; branches; next ; desc @@ 1.1 log @*** empty log message *** @ text @-- -- Risc5x -- www.OpenCores.Org - November 2001 -- -- -- This library is free software; you can distribute it and/or modify it -- under the terms of the GNU Lesser General Public License as published -- by the Free Software Foundation; either version 2.1 of the License, or -- (at your option) any later version. -- -- This library 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 Lesser General Public License for more details. -- -- A RISC CPU core. -- -- (c) Mike Johnson 2001. All Rights Reserved. -- mikej@@opencores.org for support or any other issues. -- -- Revision list -- -- version 1.1 bug fix: Used wrong bank select bits in direct addressing mode -- INDF register returns 0 when indirectly read -- FSR bit 8 always set -- (cpu.vhd file changed) -- -- version 1.0 initial opencores release -- Risc5x is a small RISC CPU written in VHDL that is compatible with the 12 bit opcode PIC family. Single cycle operation normally, two cycles when the program counter is modified. Clock speeds of over 40Mhz are possible when using the Xilinx Virtex optimisations. Legal Stuff This core 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. You are responsible for any legal issues arising from the use of this core. The source files may be used and distributed without restriction provided that all copyright statements are not removed from the files and that any derivative work contains the original copyright notices and the associated disclaimer. PIC is a trademark of Microchip Technology Inc. Features The core has a single pipeline stage and is run from a single clock, so (ignoring program counter changes) a 40Mhz clock will give 40 MIPS processing speed. Any instruction which modifies the program counter, for example a branch or skip, will result in a pipeline stall and this will only cost one additional clock cycle. The CPU architecture chosen is not particularly FPGA friendly, for example multiplexers are generally quite expensive. The maximum combinatorial path delay is also long, so to ease the place and route tool's job the core is written at a low level. It instantiates a number of library macros, for example a 4:1 mux. Two versions of these are given, one is generic VHDL and the second is optimised for Xilinx Virtex series (including sparten2's etc). A constraints file locates the data path macros within the device and ensures an easy fit and high clock speed. Performance & Size The core builds to around 110 Virtex CLBS (depending on synthesis). >33 Mhz in a Virtex e - 6 >40 Mhz in a Virtex e - 8 There's some good free tools out there including a compiler, simulator and assembler (gusim & guasm for example). Synthesis & File description : Read the files in the following order. ** PACKAGES ** pkg_xilinx_prims.vhd (package containing low level Virtex blocks) only required if using Virtex optimised macros) pkg_prims.vhd (package containing macro components) pkg_risc5x.vhd (package containing some useful functions) ** MACROS / RTL MODELS ** mux8.vhd (8 to 1 muxer) mux4.vhd (4 to 1 muxer) mux2.vhd (2 to 1 muxer) mux2_add_reg.vhd (load or +1, used for program counter) alubit.vhd (ALU bit functions) add_sub.vhd (add or subtract) IMPORTANT : Each of the macros has TWO ARCHITECTURES, the first (VIRTEX) is for Virtex series devices ONLY, including Virtex, Virtexe, Sparten2, Sparten2e etc. The second (RTL) is generic VHDL, and is surrounded by synthesis directives : --pragma translate_off --pragma translate_on This makes the synthesis tool ignores the second architecture, but the simulator does not, resulting in optimal synthesis and fast simulation. If you do not wish to target Virtex series devices, YOU MUST remove the --pragma directives, and (optionally) delete the VIRTEX architecture. A PROBLEM : Some of the macros have generic attributes passed to them to define bus width etc. Unfortunately when the same macro is used twice with different generics some synthesis tools do not build a second copy of the macro. The easiest way round this is to generate EDIF's for each macro that is required, and then save it with the 'expected name'. For example if the Xilinx tools say they cannot find a mux4_9_0_FALSE then you would edit the default generics in mux4.vhd to entity MUX4 is generic ( WIDTH : in natural := 9; SLICE : in natural := 0; -- 1 left, 0 right OP_REG : in boolean := FALSE ); port ( and build it to mux4_9_0_false.edf. You may need to build the files with *'s below : MUX2_8_1_FALSE.edf default so ok MUX2_7_1_FALSE.edf * MUX4_8_1_FALSE.edf default so ok MUX4_8_0_FALSE.edf * MUX4_9_0_FALSE.edf * MUX4_11_0_FALSE.edf * MUX8_8_FALSE.edf default so ok ADD_SUB_8.edf default so ok ALUBIT_8.edf default so ok MUX2_ADD_REG_11.edf default so ok If you are using Exemplar then you can analyze the whole lot and it gets it correct. The following works fine : analyze mux2_add_reg.vhd analyze mux2.vhd analyze mux4.vhd analyze mux8.vhd analyze add_sub.vhd analyze alubit.vhd analyze idec.vhd analyze alu.vhd analyze regs.vhd analyze cpu.vhd analyze risc5x_xil.vhd elaborate risc5x_xil ** CORE ** alu.vhd (ALU block) idec.vhd (instruction decode) regs.vhd (register file) cpu.vhd (CPU top level) regs.vhd also has two architectures, one optimised for Virtex and a generic one as well. The generic version has a simulation model of a dual port ram, which should be replaced be a synthesizable block. ** TOP LEVELS ** risc5x_xil.vhd (xilinx chip complete with program ram) OR cpu_tb.vhd (simulation model which loads a .hex program file) ** OTHER ** risc5x_xil.ucf (xilinx constraints file) jumptest.asm (sanity test program) jumptest.hex (sanity test binary) risc5x_xil.VHD is a synthesizable top level that instantiates some Xilinx block rams. For simulation replace risc5x_xil.vhd with cpu_tb.vhd which has extra debug. Signal inst_string in cpu_tb shows the current instruction being executed, and pc_t1 the address it came from. (t1 signifies one clock later than the PC, due to the delay through the program memory) Any questions or interest in customisation /locked / other cores (16x8x?) etc feel free to mail. mikej@@opencores.org Cheers Mike. @