Hi all OpenRISC gurus: I've been thinking about forking the or1200 core. I find the current Verilog code difficult to understand, and every time I've looked inside in order to try and fix some minor glitch, I ended up frustrated.
I'm tinkering with an FPGA evaluation board and, when I looked at OpenRISC for the first time, I just wanted some simple microcontroller for my experiments. I am familiar with 8-bit AVRs, but I'm tired of porting standard C code to run on AVR's dual memory address space (with the usual PROGMEM tricks). I wanted a small, standard 32-bit CPU with a single memory address space like the C language expects. And I wanted full C++ support. CPU speed is irrelevant for me, a 12 MHz AVR would do. If I need speed for a certain I/O task, that's what the rest of the FPGA is there for. I don't need a CPU cache, MMU, power saving or anything fancy. Linux is too big, slow and complicated for my current experiments anyway. However, I do need a tried-and-true CPU that passes its own test suite. JTAG debugging must work well, reliable breakpoints are a must. I don't want to debug the old fashion way with printf and a serial console. I want to use a cheap, generic, off-the-shelf USB JTAG cable (can anyone recommend one?). I would like to have a CPU core that's simple and easy to understand. It shouldn't need much FPGA area. I just need the most basic instruction set. I don't need a supervisor mode. I would like a short pipeline, without jump delay slots, as I don't want to deal with any unnecessary complications like data coherency issues. I'm not sure having separate instruction and data buses is worth the effort of worrying about conflicts when both buses access the same memory regions (self-modifying code). I'm not convinced I wish to pay of price in terms of cache and pipeline flush instructions and the like. I also don't see the need of having an external CPU monitor module, everything I need should be integrated in the core. I also don't want to maintain so many types of memories in the core's source code, each one optimised for a different ASIC or FPGA manufacturer, and often very similar by virtue of copy-paste, without proper comments about why they are subtly different to their siblings. I will never build an ASIC, so I don't need any ASIC stuff cluttering the source code at all. As the first step, I would like to clean up the existing or1200 Verilog code. After seeing the code and learning about so many long-standing issues (many of them still coming up), I don't trust it any more. I'd like to use the Verilog standard as of 2005. There is no need for so many separate "always @(xxx)" statements, Verilog has had functions and tasks for a long time. The code should lint without warnings. Variable names should't be abbreviated for gury-only consumption. The CPU configuration shouldn't be implemented with `define symbols, but with Verilog parameters. I would get rid of all timescale and delay statements, they should only be present in test benches for simulators that do support them. The reset handling should be synchronous all over the place, as mandated by the Wishbone specification. At the very minimum, there should be asserts like this at many places: if ( some_assert_condition ) begin $display( "My assert failed." ); $finish; end; The goal is that, if something is not quite right, the core shouldn't just blindly run further in the simulation, it should stop as soon as possible in order to help debug the core, like I'm used to with C/C++ software. However, I would also consider some other assert syntax, as long as it's easy to understand and available on most platforms. I would like to simulate the resulting SoC with Verilator, as Icarus Verilog is extremely slow. I don't want the extra complication of installing the System C libraries though, as I don't want to write and maintain any SystemC-style C++ in order to simulate simple peripherals like an UART or an ethernet interface, which have already been implemented in Verilog. Some parts can just be replaced with a few DPI calls, written in standard C/C++, and that's all I need. I don't see the need of supporting any commercial simulator in the core Verilog, especially if it requires proprietary syntax or pragma statements. Does anybody have any thoughts on this? Thanks, rdiez _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
