The following was posted to the OpenRISC mailing lists. I'd prefer discussion to occur there, but if it occurs here too I don't mind.

But the lists are here:
http://lists.opencores.org/listinfo/openrisc
http://lists.openrisc.net/listinfo/openrisc

I have implemented some changes to the version register (VR) and added
some SPRs to the system group (0) to help us track version and
revision of implementations.

This involves changes in a lot of places, but they're largely done and
ready to be checked in, pending people's approval of the idea.

First, a summary of what I propose is that the VR instead have an
8-bit field for a CPU ID (implementation ID) and then a 24-bit version
field that is implementation specific, but generally a higher number
means a newer version. I argue this is a sensible thing to do.

Next I propose 5 read-only SPRs are added (there is a nice 5-register
gap in the SPR address space at addresses 11-15) allowing up to
160-bits of local revision information to be embedded. Coincidentally,
git SHA1 values are 160-bits long. The meaning of these registers,
which I propose are named the Revision Information Registers
(REVIR0-REVIR4), is up to the local implementer. I forsee them being
used as a way of tracking the precise state of the source the thing
was compiled from. The easiest way to do this would be by using a git
repository and doing a local commit of all changes being hitting the
synthesize button. It's then a trivial matter for scripts to get the
git SHA1 value of that commit and embed it into the RTL at
synthesis-time. Although, anything could be stored there and it's left
to the local implementer to decide what it is.

The following are the modifications to the spec I've made.

The PDF of my proposed spec (with architecture revision stuff, too) is
here: http://www.mediafire.com/?ua0dt1i33lxl53a (apologies, I don't
have any hosting yet and didn't want to email around a binary.)

The following is the core of the OR1K draft spec changes:

5 SPRs added to group 0 (system group):
11-15 REVIR0-REVIR4 - Revision Information registers

Section 15.1
Implementations of the OpenRISC 1000 architecture come in
different configurations and version releases.
Version and unit present registers both identify the model,
version and its configuration. Detailed onfiguration for some units
is available in configuration registers.
An operating system can read VR, UPR and the configuration
registers, and adjust its own operation if required. Operating systems
ported on a particular OpenRISC version should run on different
configurations of this version without modifications.


Pending people's approval, I have patches for or1ksim, ORPSoC (or1200
RTL, software stuffs), and most things which use the spr-defs.h file
(which will have changes to the SPR_VR definitions and addition of the
REVI registers) in the OpenCores SVN repo such as newlib, ucos and
orpmon.

I anticipate this will not break anything, and the VR isn't being used
properly at the moment, anyway.

In large part, I want the VR to have improved meaning so we can better
keep track of the OR1200 RTL that's floating around. The actual
meaning of the version field in the OR1200 I'll outline in another
post with the RTL patches, but I argue we should move to a major and
minor release number system, which is maintained in the OR1200's
specification and represented in that register. With these in place,
I'll then do an update of the OR1200 RTL in the OpenCores SVN repo so
there's less confusion about what is what. The dual-location of the
RTL is also a well-known problem and something we should discuss in
another thread.

The 8-bit CPUID field of the VR can be used to determine the
implementation. A list of know implementations and unique IDs can
probably be maintained in a document kept alongside the architecture
spec. I think the OR1200 should have its ID as 0x12 and or1ksim as
0x01 (but this is configurable in or1ksim via a new "id" field ...
patches to come.) Any sufficiently different branch of any
implementation, that is not likely to be re-merged, should get its own
unique ID.

I think the addition of the REVI registers helps us use that neat
trick with git, but is mostly designed to help keep track of local
modifications to the project before synthesis is performed. If people
aren't using git locally there's many other ways to store local
modifications there.

What do we think?

Thanks,

Julius

I think reusing the already-present version register is a more appropriate approach. 32-bits provide more than enough space to create a monotonically increasing processor version counter.

Here are some reasons why adding extra SPRs is a bad idea:
1. The version register already exists and is sufficient
2. It is a management hassle to update the HDL code of the processor every time a minor change to the repository is made
3. Using a hash makes it difficult for humans to compare processor versions, i.e., processor versions > 10 have bug X
4. The version register should track only the version of the processor not the entire system-on-chip
5. When orpsocv2 changes are properly back-propagated to the peripheral's home directories, will using this git hash model even work?

I've already posted here on the forum and in mailing lists about this (http://lists.opencores.org/pipermail/openrisc/2011-June/000003.html) previously. I got 1 comment of feedback so presumed people didn't mind.

I, too, think that the implementation version should be an increasing number, but it's not the architecture spec's job to indicate how that number should be formatted. It's up to the implementation. I also think an ID for each implementation helps.

Also, to clear up any confusion, I intend on reusing the current VR, just reformatting it.

But here's more about why I think we can't keep the current VR format:
1. As any future architectures will quite likely NOT be binary backward compatible, so the VER field, as it is, is pretty useless. It is allegedly supposed to "indicate the architecture and the capabilities of the processor" as it stands. This is clearly not the appropriate thing to be doing here. We should be identifying the implementation, and indicating its version - not the capabilities of the processor.
2. Why should there be configuration information in this register? There should be enough bits in config and UPR registers elsewhere to indicate the processor's capabilities in relation to the spec, so that we're not relying on some bespoke encoding of that information here. Something that is far more useful is a unique implementation ID, allowing us to know precisely what core we're dealing with, and based on that we can track down all the information relating to that implementation in its spec, along with the provided version information.
3. 6-bits of revision information is hardly enough. Why shouldn't we use the rest of that register? I've suggested the OR1200 should adopt a major.minor.point release version numbering system that would fit nicely as 3 8-bit numbers in that 24-bit field.


I disagree for the reasons mentioned above.


This has already been done by me, but I agree - it is a hassle, but I'm not doing this for fun. I think we need a better versioning system for implementations, and I don't like the current system for the reasons mentioned above. I hope people agree.


The hash is not intended to indicate version, rather local revision. You can store whatever you want in those 160-bits, not necessarily a hash, but I think that would be a useful thing to have.


I agree. I never intended it to keep track the entire system-on-chip revision.


If you're using SVN to manage it locally, no (but again, it doesn't need to be a hash in the REVI registers.) If you're using git, then yes. One thing I'm looking at working on is re-organising ORPSoC so that there's some kind-of system for both, but ideally it'd be set-up with git submodules and pulling in specific revisions of cores. But you'll still want to configure them and their defines files, and you'll want to keep track of their configuration at synthesis time. Most things should be tracked by information in registers (cache sizes, enabled modules, instructions etc.) but there's many implementation-specific things that aren't tracked by bits in registers according to the arch spec such as particular multiplier, ALU logic, bus-interface, etc. Some system to keep track of what your configuration of those is at synthesis time is very useful. Again, it needn't necessarily be git, but I've put in a system that would accommodate that.

One thing I left out of my initial posting, was that if people like the idea of keeping track of architecture revisions, we could either somehow indicate the implementations' supported architecture revision in a register, or make that determinable by looking up the spec for the implementation, where it should be clearly stated.

Will these ID registers (like 8 bit CPUID) also determine the JTAG-ID of the TAP connected to openrisc ?

Fine, then reserve the 3 SPRs in group 0. But, I think that OR1200 would be better served using some other source to fill these three registers than a simple source hash. At the very minimum, OR1200 should use a two-way function to create these values, preferably a function that is a bijection (one-to-one and onto).

I would think this is completely separate, so no. You're not strictly limited to a JTAG debug interface for accessing the CPU. You can hook up anything that does the job over the debug interface on a CPU implementation.

Again, the contents of these _5_ registers is not specified by the architecture spec, and maybe not even by the implementation spec. It's largely up to the implementer, and the project it's being used in, as to what you want to put in there. I just made it big enough to support a popular revision control system's version/revision/commit ID information.

If there is no specification of how the registers are to be populated in either spec, then there is no point in reserving the registers in the spec. If a user wants to create such a versioning register, they can just use whatever free SPRs that are available. I did something simlar with the performance counter SPRs.

Of course there is! Having them in a defined location means software can be kept simple and standard across all libraries (provide a function like or1k_get_revision() in the baremetal libraries which can be the same across all platforms). How the returned value is interpreted is largely application-specific, and I intend to use it to track the precise state of the source the processor was synthesised from.

Anyone can come along and hack on their own bespoke solution to revision tracking. I'm not going to the effort to put this into the architecture spec for the fun of all of these forum posts. I think that this is a useful system to be used by implementations.

If you think you have a good change tot he PCU then please submit that (I think there's some useless things in there too that we can address.)

I'm just proposing a system here that will allow flexibility for the variety of implementations and the various ways they are used. I don't see that as a reason for not putting it into the spec.