OpenCores

OpenCores

Architecture revisions

no use

no use

1/1

no use

no use

Architecture revisions by julius on Aug 7, 2011			julius Posts: 363 Joined: Jul 1, 2008 Last seen: May 17, 2021
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 (OpenCores one is broken at the moment? my posts didn't come through and I'm definitely registered? Oh well): http://lists.opencores.org/listinfo/openrisc http://lists.openrisc.net/listinfo/openrisc I think it's time we start tracking the revision of the architecture. I have done some work to implement the version register (VR) changes that I posted about previously, and I'm sure we're going to see modifications to the architecture come about in the future. To help things progress, I think it's a good idea to keep track of the modifications made. After any changes to the spec, no matter how small, it's important that we be sure we're clear about which revision is supported by an implementation. I will post more later about my additions to help version tracking of the implementations, but for now I want to outline how I propose we keep track of revisions simply in the architecture spec document. Basically, in the architecture spec ODT file that is in the repository (Yann's draft which I'm sure we all want to continue working from) now has a value called "Architecture revision" which is also now stated on the front page. A new section has been added, section 2.3, outlining the following: [q] 2.3 Architecture Revision Information It is anticipated that revisions of the OR1K architecture will come about as architectural modifications are made over time. This document shall be valid for the revision stated in it. Previous revisions of this document should be archived on www.opencores.org. The following table contains a summary of the changes made in each architecture revision. This should be used to keep track of the changes. Each implementation's specification must state which revision it supports.[/q] I hope that's straight forward. I expect the architecture revision that each implementation is according to will be kept in the implementation's specification. Although, maybe we should add a register with the architecture revision information? I've uploaded a PDF of the spec I've worked on (this also has some other modifications Im going to discuss in another post.) http://www.mediafire.com/?ua0dt1i33lxl53a What do we think? Simple, yet powerful enough to help us go forward? Thanks, Julius 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 (OpenCores one is broken at the moment? my posts didn't come through and I'm definitely registered? Oh well): http://lists.opencores.org/listinfo/openrisc http://lists.openrisc.net/listinfo/openrisc I think it's time we start tracking the revision of the architecture. I have done some work to implement the version register (VR) changes that I posted about previously, and I'm sure we're going to see modifications to the architecture come about in the future. To help things progress, I think it's a good idea to keep track of the modifications made. After any changes to the spec, no matter how small, it's important that we be sure we're clear about which revision is supported by an implementation. I will post more later about my additions to help version tracking of the implementations, but for now I want to outline how I propose we keep track of revisions simply in the architecture spec document. Basically, in the architecture spec ODT file that is in the repository (Yann's draft which I'm sure we all want to continue working from) now has a value called "Architecture revision" which is also now stated on the front page. A new section has been added, section 2.3, outlining the following: 2.3 Architecture Revision Information It is anticipated that revisions of the OR1K architecture will come about as architectural modifications are made over time. This document shall be valid for the revision stated in it. Previous revisions of this document should be archived on www.opencores.org. The following table contains a summary of the changes made in each architecture revision. This should be used to keep track of the changes. Each implementation's specification must state which revision it supports. I hope that's straight forward. I expect the architecture revision that each implementation is according to will be kept in the implementation's specification. Although, maybe we should add a register with the architecture revision information? I've uploaded a PDF of the spec I've worked on (this also has some other modifications Im going to discuss in another post.) http://www.mediafire.com/?ua0dt1i33lxl53a What do we think? Simple, yet powerful enough to help us go forward? Thanks, Julius

RE: Architecture revisions by firefalcon on Aug 7, 2011			firefalcon Posts: 99 Joined: Jan 10, 2011 Last seen: Mar 26, 2024
I think it is more important and relevant to track the revision of the HDL code, not the specification. I think it is more important and relevant to track the revision of the HDL code, not the specification.

RE: Architecture revisions by julius on Aug 8, 2011			julius Posts: 363 Joined: Jul 1, 2008 Last seen: May 17, 2021
[q]I think it is more important and relevant to track the revision of the HDL code, not the specification.[/q] I think they're both important and required. Don't confuse these two issues. They're very separate. I think it is more important and relevant to track the revision of the HDL code, not the specification. I think they're both important and required. Don't confuse these two issues. They're very separate.

RE: Architecture revisions by firefalcon on Aug 9, 2011			firefalcon Posts: 99 Joined: Jan 10, 2011 Last seen: Mar 26, 2024
[q][q]I think it is more important and relevant to track the revision of the HDL code, not the specification.[/q] I think they're both important and required. Don't confuse these two issues. They're very separate.[/q] By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions. I think it is more important and relevant to track the revision of the HDL code, not the specification. I think they're both important and required. Don't confuse these two issues. They're very separate. By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions.

RE: Architecture revisions by pekon on Aug 9, 2011			pekon Posts: 29 Joined: Mar 6, 2009 Last seen: Dec 14, 2020
Its good to track both architecture and HDL versions, and any configuration-management system like SVN is good at that .. 1) Also, all documents and HDL files should maintain a Revision History in their first-page for user-reference 2) Is it possible to open PDF or ODT spec document, for review and comments from all open-core users. So, that each one of us can give their inputs based on different experiences, and someone like you may collate them and then merge them in document if required.. If PDF/ODT is shared on a document-server for review, then all reader can put their comments using sticky notes (visible to all, after syncing with server).. And later one person can reply or review those comments and feedbacks, and make necessary updates to document. [pekon] Its good to track both architecture and HDL versions, and any configuration-management system like SVN is good at that .. 1) Also, all documents and HDL files should maintain a Revision History in their first-page for user-reference 2) Is it possible to open PDF or ODT spec document, for review and comments from all open-core users. So, that each one of us can give their inputs based on different experiences, and someone like you may collate them and then merge them in document if required.. If PDF/ODT is shared on a document-server for review, then all reader can put their comments using sticky notes (visible to all, after syncing with server).. And later one person can reply or review those comments and feedbacks, and make necessary updates to document. [pekon]

RE: Architecture revisions by stekern on Aug 10, 2011			stekern Posts: 84 Joined: Apr 28, 2009 Last seen: Nov 10, 2016
[q][q][q]I think it is more important and relevant to track the revision of the HDL code, not the specification.[/q] I think they're both important and required. Don't confuse these two issues. They're very separate.[/q] By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions.[/q] Yes, execept for the case when you are using the current HDL version, you don't know where that range will end. I think it is more important and relevant to track the revision of the HDL code, not the specification. I think they're both important and required. Don't confuse these two issues. They're very separate. By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions. Yes, execept for the case when you are using the current HDL version, you don't know where that range will end.

RE: Architecture revisions by stekern on Aug 10, 2011			stekern Posts: 84 Joined: Apr 28, 2009 Last seen: Nov 10, 2016
[q]1) Also, all documents and HDL files should maintain a Revision History in their first-page for user-reference [/q] For documents I might agree, for HDL files I strongly disagree. Keeping revision history is the job of the version control system, having revision history in source files is just plain ugly and clutters up diffs. 1) Also, all documents and HDL files should maintain a Revision History in their first-page for user-reference For documents I might agree, for HDL files I strongly disagree. Keeping revision history is the job of the version control system, having revision history in source files is just plain ugly and clutters up diffs.

RE: Architecture revisions by firefalcon on Aug 10, 2011			firefalcon Posts: 99 Joined: Jan 10, 2011 Last seen: Mar 26, 2024
[q][q][q][q]I think it is more important and relevant to track the revision of the HDL code, not the specification.[/q] I think they're both important and required. Don't confuse these two issues. They're very separate.[/q] By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions.[/q] Yes, execept for the case when you are using the current HDL version, you don't know where that range will end.[/q] How is when the current range will end important? I think it is more important and relevant to track the revision of the HDL code, not the specification. I think they're both important and required. Don't confuse these two issues. They're very separate. By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions. Yes, execept for the case when you are using the current HDL version, you don't know where that range will end. How is when the current range will end important?

RE: Architecture revisions by julius on Aug 14, 2011			julius Posts: 363 Joined: Jul 1, 2008 Last seen: May 17, 2021
[q]By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions.[/q] By this I assume you mean the HDL's revision should track the architecture spec? This might end up being the case, but we shouldn't require it according to the specification. Again, please ignore anything about any _implementation_ version and revision tracking with this proposal. I'm just looking at keeping better track of the architecture specification itself (be it in this document format or any other) and to be sure this is sorted out before when we start modifying things. The .odt document I worked on can be found here: http://www.mediafire.com/file/mwhxk8387u6l1ck/openrisc_arch_draft.odt The changes can be highlighted by going to edit->changes->show changes in the menu. They are showing up as blue for me, and Yann's are in yellow (mouse-over them to have the change information show up.) My proposed changes to the VR are included in that document too, but they are not exactly what I'm talking about here, although they are an example of how changes would be made and recorded. What is important is to get feedback on whether people are happy with what I'm proposing here. Some sort of system like this must be in place before changes can be tracked as they occur. If people are happy I can remove the proposed VR changes, and just upload the document to the SVN's docs/ directory as revision 1 (with exported PDF and .doc versions) and we can go from there. By tracking the revision of the HDL code, you track the specification for free. When you have a monotonically increasing processor version number, you can link ranges of HDL versions to certain specification revisions. By this I assume you mean the HDL's revision should track the architecture spec? This might end up being the case, but we shouldn't require it according to the specification. Again, please ignore anything about any _implementation_ version and revision tracking with this proposal. I'm just looking at keeping better track of the architecture specification itself (be it in this document format or any other) and to be sure this is sorted out before when we start modifying things. The .odt document I worked on can be found here: http://www.mediafire.com/file/mwhxk8387u6l1ck/openrisc_arch_draft.odt The changes can be highlighted by going to edit->changes->show changes in the menu. They are showing up as blue for me, and Yann's are in yellow (mouse-over them to have the change information show up.) My proposed changes to the VR are included in that document too, but they are not exactly what I'm talking about here, although they are an example of how changes would be made and recorded. What is important is to get feedback on whether people are happy with what I'm proposing here. Some sort of system like this must be in place before changes can be tracked as they occur. If people are happy I can remove the proposed VR changes, and just upload the document to the SVN's docs/ directory as revision 1 (with exported PDF and .doc versions) and we can go from there.

no use

no use

1/1

no use

no use

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.