OpenCores
no use no use 1/1 no use no use
Future of OpenRisc
by jt_eaton on Sep 19, 2009
jt_eaton
Posts: 142
Joined: Aug 18, 2008
Last seen: Sep 29, 2018

I would like to know if anybody out there has any plans for future enhancements or fixes for the openrisc project. I know that there is the original or1200 cpu as well as a newer or1200_r2 but are there plans for more?

The reason that I am concerned is that the or1200 will be 10 years old next year and in this business that is not a good sign, There have been massive changes in IC's in the last decade and we need to ensure that we keep the design relevant to todays technologies. We need to get into a mode of continuous improvement and plan to release a updated design every couple of years.


I would like to start a discussion as to what changes could and should be made. My current list is:

1) change srams to use parameters instead of creating a new module for each different size.
It looks like the r2 as already done this. We need to purge the unused files

2) Add the ability to support future new processes without touching existing files.
You don't want to have to add `ifdef OR1200_NEW_FPGA to every sram file every time a new fpga is released. This can be split out into separate files and new processes can be supported by simply adding new files. You DO NOT want to have to edit existing files.

3) Change the wishbone cl_mode logic to support external clock enables instead of generating them.
All the wishbone masters should have a wb_clk_enable port. If tied high the the buss runs at the wb_clk rate. Drive it every other clock and it runs 1/2 wb_clk, every fourth clock and it runs 1/4 wb_clk rate. Ensure that outputs only change and inputs are sampled when this port is high. This will help with power compilers and could give us so more flexibility with arbitration.

4) Port the boot_adr_sel signal in from the top level.
This lets you have a "boot into test" mode that you can select from a pcb.

5) Create block level test suites.
It is not enough to have functional tests the run from the top level. You also need a test suite for every subblock. For example the multiplier should have a testbench that instantiates that block and hammers it with hundreds of well chosen multiplies. The cache controllers should have tests that hammer them with a wide variety of memory requests. You make sure that your lower level blocks are well covered

6) Remove the wishbone CAB signal.
When things become obsolete you have to clean house.

7) Identify critical, false and multi-cycle paths.
If you plan on running at any speed the you will need to give these to your synthesis tool in the timing constraints. It makes me nervous when I trace signals through the or1200 and see signals that pass though modules with no registers. Do that a few times and you can get so rather long timing paths. We need to identify the worst offenders and re-architect them.


Any more ?

John Eaton







RE: Future of OpenRisc
by nyawn on Sep 21, 2009
nyawn
Posts: 173
Joined: Dec 19, 2008
Last seen: May 31, 2023
I have two suggestions:

1. Separate "defines" from "options". Some values ("defines") will only be changed by hardcore openrisc developers - things like the width of the data bus. Other values ("options") will be changed by casual users - things like cache size. These "options" should be in a separate file (at least), to reduce confusion for casual users, and to make it possible to create automated / graphical configuration tools.

Really, it would probably be generally helpful if future OR1k developers accept that there will be 'casual' users...people who want to use the OR1200, but do not want to have to become experts on it first. This was not the philosophy of the earlier developers, and it's really a recurring problem among F/OSS projects in general...

2. As the author of the advanced debug system, I'd like to be able to support an OR1200 with cache. The easiest thing to do would be to provide a simple interface to allow the debug unit to flush the CPU's cache, and poll until the flush is complete. A pair of signals in the interface for 'flush' and 'flush complete' would work, or a register added to the CPU debug unit would work. A more complicated method would be to provide an interface to allow the external debug unit to read the WishBone by going through the CPU data cache, but that's probably too complicated to be worth the effort.
RE: Future of OpenRisc
by nyawn on Oct 1, 2009
nyawn
Posts: 173
Joined: Dec 19, 2008
Last seen: May 31, 2023
I've remembered another idea I had...

Multi-core is big right now, both as a mainstream CPU architecture and as an active area of research. If you wanted to make the OR1200 more appealing to the academic crowd, you may want to consider adding features targeted at multi-core systems. Cache coherency among multiple OR1200 CPUs is the first thing that comes to mind along those lines.

Also, a more advanced cache scheme could improve performance for larger/more complex applications on a single CPU.
RE: Future of OpenRisc
by moogyd on Oct 1, 2009
moogyd
Posts: 15
Joined: Nov 22, 2008
Last seen: Jun 26, 2019
Hi,

Obviously, the "future of OpenRisc" is a massive question, but my 2 cents worth...

One direction that could be considered is a small, low cost, low power version targeted at the embedded market. Specifically, people upgrading their embedded 8-bit core for higher performance, while not taking a bit hit on area/power.

For example, ARM are currently targeting the Cortex M0 at this market.

To be honest, I have not deeply investigated the current architecture, so I don't really know whether this target is realizable or practical.
(Looking at the architecture is currently on my to do list, and I'll try and share any thoughts I have).

Thanks,

Steven


RE: Future of OpenRisc
by narsiposham on Oct 8, 2013
narsiposham
Posts: 1
Joined: Jul 23, 2008
Last seen: Oct 8, 2013
Does anybody done any comparison between OpenRisc1200 vs Cortex M0 class
no use no use 1/1 no use no use
© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.