11.07.2015 Views

Open Core Protocol International Partnership Governing ... - OCP-IP

Open Core Protocol International Partnership Governing ... - OCP-IP

Open Core Protocol International Partnership Governing ... - OCP-IP

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

said that he did not think this was keeping anyone from doing their work. Drew told the group thathe had heard that in Power.org and ARM, the fact that <strong>OCP</strong> did not have cache coherence wasbeing used against them. Drew said that this active marketing work was saying <strong>OCP</strong> was lessrelevant because the work was not complete. Ian said that an ARM processor went out with acoherency solution on it. Drew said that it had been going on for some time, but it was not anopen solution. Drew explained that from an external interface it was entirely AXI, but cachecoherency was inside a black box. Drew said that there was lot of work that still needed to bedone on the coherency solution. Drew went on to say that there was a possibility that theschedule would slip.Drew said that in the SWG they were looking at three questions: when to release the spec, howto document and release the profiles, and how to resolve proposed write model changes. Drewsaid he wanted GSC input, and that a decision could not be made within just the SWG. Drewsaid there were two choices in regards to the Specification release. One choice was to push outall of the coherence extensions without publishing them. The other choice was to make a smallrelease called 2.3 to cover these two extensions and the profile work. Drew said that he wouldprefer delaying the release until 3.0, because there were many people who did not want to seethree releases in two and a half years. Drew said that this did not mean they would need to waiton the consensus profiles. Drew went on to say that in the past they had separated documentrevisions from specification revisions. Ian said a version 2.2A could be released. Drew said thathis proposal was to do this. Ian clarified that a 2.2A could be released now with just two of thethree profiles, with the third profile in the next Specification revision if a specification modificationis required.Drew said that the second issue was how to publish the new profiles. Drew said that thespecification document was broken into three sections: the specification, developer guidelines,and compliance. Drew said that sections two and three were not specifications, but just reiteratedthings already in the Specification. Drew explained that the profiles were guidelines and were notsupposed to introduce new features. Drew said he felt comfortable publishing profiles as 2.2Ainstead of revving the Specification number. Drew then explained that currently the profiles werein a parameter table, which was a cheap but not a very valuable format. Drew said that thesecond approach was to build a separate document that discussed features that were beingused. Drew said this would trim the Specification down and would be easy to understand, butwould be a maintenance nightmare. Drew asked if they needed to build three documents sincethere were three profiles. Drew then asked how the overlap between documents and conditionaltext would be dealt with. Drew then said that the technical writer had come from Sonics, butSonics would not be able to provide a resource to manage these documents. Drew explained itwas not obvious what text for the main document would be included in a separate document.Drew said that the third approach would be a solution somewhere in the middle of the other two.Drew said this solution could be a new chapter that would be formatted as an appendix butneeded to have enough description of the features that a new user could just use that text,independent of the Specification. Ian asked where in the document it would be placed. Ian saidthat they needed to have existing profiles connected to new profiles and the text should havedescriptions of old profiles and new profiles. Drew said he was not sure who would do all thework necessary to document the old profiles in a new chapter or appendix. James suggestedthey could be left as is.Drew said he thought that Vesa’s idea was the best one to go forward with, and that they shouldpublish it as an appendix. Ian asked if anyone was opposed this. James said if they wereworried about the page count, it would be easy to give people the option of downloading theSpecification and/or the Specification guidelines. Drew said if you compare the page count of the<strong>OCP</strong> Specification to the full AMBA 3 Specification, <strong>OCP</strong> had twice the page count. Ian said thiswas because it was a complete Specification. Drew said that the perception was that there was aproblem. Vesa said he did not think the page count was a problem, but acknowledged that it maybe difficult for a new user. Vesa said the profiles would help that. Drew said that the <strong>OCP</strong> bookdiscussed at the previous night’s dinner could help ease the learning curve.<strong>OCP</strong>-<strong>IP</strong> CONFIDENTIAL<strong>Governing</strong> Steering Committee Meeting Minutes 11/8/2007Page 15 of 22

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!