merge master

cores/MeetingMinutes/Feb.10.2020.md

@@ -0,0 +1,123 @@
+Date: February 10, 2020
+
+Attendees:
+
+Mike Thompson : (OpenHW)       : [email protected]
+
+Davide Schiavonne (OpenHW)     : [email protected]
+
+Silicon Labs
+Thales
+BlueSpec
+
+
+Meeting about:
+
+1. awarnesess about what the opensource world expects from an maintained IP;
+2. how to contribute to the Core-V IP of OHW
+3. discussions about tasks assigned to FTEs (coretile, documentation, hwloop parameters and new specs, parameters
+
+## Replying to emails and GitHub issues questions
+
+Needs to be done to help core users (open source needs support), everyone should contribute.  Label issues, provide information, etc.
+Example: Ibex https://github.com/lowrisc/ibex/
+
+## Way of contributing to RTL:
+
+Make your own fork on your github account. Make modifications, then make pull requests to the original repository (openHW one)
+
+a. we should have a CI suite that runs Mike’s verification tools to be sure that the tests are still passing. 
+This will run automatically on PRs.
+
+b. At least 2 people should have a look at the PR’s code (assigned to PRs). 
+This makes easier to understand what is changed and find potential issues the CI may not catch.
+This will be made automatic, 2 people accept PRs before merging to master.
+
+CI: https://github.com/openhwgroup/core-v-verif
+
+
+TODO: add in a .md file CONTRIBUTION guide
+
+## FTEs and Active Contributions:
+
+### Documentation/Specification as a must
+
+While everyone should get familiar with the RTL of the CORE 
+(currently Davide Schiavone is the only the expert, we should become a team of experts), 
+we need to write Documentation.
+Most of the documentation today is the RTL per se, there is no person that knows everything on the core (not even Davide!). 
+So, what happens if xyz? the answer is probably in the RTL.
+Specifications are not industry level, so we need also to make them that way. 
+We can start from the Ibex documentation and then extend it with all of our features.
+https://github.com/lowRISC/ibex/tree/master/doc
+
+
+### Who does what? 
+
+There may be overlapping tasks. We should avoid this to keep productivity high. 
+We can discuss it as a team. For instance the core tile. We can discuss this now.
+Verification will also test interrupts and debug requests. Is the DUT the Tile or the Core?
+Mike: both. we start with the core but we will have a tile level testbench as well.
+Tile discussion on going.
+
+## HWloop parametrizable and new spec. 
+
+A draft of new spec is in the current document, 
+still we want to extend to support a sort of reaction if those specs are not supported. 
+
+See on mattermost:
+
+```
+@agrasset
+
+12:04 PM
+Hi all @channel,
+My name is Arnaud Grasset (from Thales). I am working on the verification plan of the HWloop extension of the core CV32E40P. This extension comes with a set of rules that the programmer has to follow:
+** HWloop begin address must be ALIGNED
+** No compressed instructions allowed in the HWLoop body
+** [Minimum 3 instructions]
+If these rules are not followed, behavior is undefined. And the verification will ignore this scenario (assuming that it cannot happens).
+But it is unreasonable to assume that the software will be free of any bugs.
+We have discussed of this point with Davide and Mike, and we think that the specification should evolve.
+We see two approaches to handle this issue:
+Ignore the stimulus (e.g. does not jump back if counter is 0, hardwire the LSBs of some registers to 0s to actually force the alignment)
+Invoke an error response (e.g. rise an exception).
+We would like to have the feedbacks from the design team as it will impact the design of the core.
+```
+
+SiLabs: we should also extend the core with more debug features (as HW breakpoint)
+They will provide what is missing to create a task on it.
+
+### Bugs fixing:
+
+There are open issues on GitHub that PULP did not close due to lack of resources(menpower). 
+We should do it. In addition, Mike’s team will find documentation, specs, and RTL bugs. 
+We should address them quickly to make the verification proceed. This goes into the bug fixing group.
+
+Use GitHub for Milestones, current activities, issues, actions, etc
+We will grow using GitHub properly to make things automatic (like 2 people to accept the PRs, etc)
+
+https://github.com/lowrisc/ibex/blob/master/CONTRIBUTING.md
+https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md
+
+
+### To be discuss next: 
+
+We should also add in the CI suite a synthesis script that checks that RTL changes are synthesizable, no comb. loops are created,
+and no strange paths appear. Linting, Code Style (based on Ibex)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

cores/MeetingMinutes/Jan.07.2020.md

@@ -0,0 +1,73 @@
+Date: January 07, 2020
+
+Attendees:
+
+Mike Thompson : (OpenHW)       : [email protected]
+
+Davide Schiavonne (OpenHW)     : [email protected]
+
+Arjan Bink (Silicon Labs)      : [email protected]
+
+Sebastian Ahmed (Silicon Labs) : [email protected]
+
+Steve Richmond (Silicon Labs)  : [email protected]
+
+
+## CV32E40P Features:
+
+WE DO NOT REMOVE FROM RTL THE MODULEs THAT IMPLEMENT THOSE FEATUREs
+(WE MAY MOVE PARAMETERS FROM GLOBAL TO LOCAL) → “NO” col
+
+RELEVANT COMBINATION OF GLOBAL PARAMETERs WILL BE ALL VERIFIED IN A LONG TERM PLAN
+
+IN THIS MEETING WE FIX THE GLOBAL PARAMETERs (so the ones that will be on Silicon) AND THE CORE WILL BE VERIFIED FOR BHAG2020
+
+## BHAG2020:
+
+WHAT WE MOVE FROM GLOBAL TO LOCAL
+
+“NO” col for existing global parameters
+
+HWLoop should be a GLOBAL PARAMETER, OPTIONAL
+
+RVF AND Zfinx GLOBAL BUT NOT ON SILICON, change name of Zfinx to OHW_Zfinx
+TENTATIVE, after BHAG2020 to OPTIONAL
+
+LOCAL PARAMETERS ARE NOT AND WILL NOT BE VERIFIED (SHORT AND LONG TERMS) WE LEAVE THEM ONLY FOR RTL REUSE FOR THE FUTURE
+
+We want to fix it to INCLUDED for the BHAG2020 (so on silicon)
+
+We should move INSTR_RDATA_WIDTH from GLOBAL to LOCAL and fix it to 32
+We should move N_EXT_PERF_COUNTERS  from GLOBAL to LOCAL
+We should move PULP_SECURE    from GLOBAL to LOCAL 
+We should move N_PMP_ENTRIES  from GLOBAL to LOCAL
+We should move USE_PMP  from GLOBAL to LOCAL 
+
+Check with PULP team if they use these parameters in the CLUSTER
+and then         
+We should move  parameter FP_DIVSQRT  from GLOBAL to LOCAL      
+We should move parameter SHARED_FP      from GLOBAL to LOCAL    
+We should move  parameter SHARED_DSP_MULT  from GLOBAL to LOCAL 
+We should move  parameter SHARED_INT_MULT    from GLOBAL to LOCAL 
+We should move  parameter SHARED_INT_DIV     from GLOBAL to LOCAL  
+We should move  parameter SHARED_FP_DIVSQRT  from GLOBAL to LOCAL 
+We should move  parameter WAPUTYPE            from GLOBAL to LOCAL 
+We should move  parameter APU_NARGS_CPU     from GLOBAL to LOCAL 
+We should move  parameter APU_WOP_CPU       from GLOBAL to LOCAL   
+We should move  parameter APU_NDSFLAGS_CPU   from GLOBAL to LOCAL 
+We should move parameter APU_NUSFLAGS_CPU    from GLOBAL to LOCAL 
+
+
+
+**OPTIONAL:**
+GLOBAL PARAMETER, VERIFIED (all OPTIONS) and we implement ON SILICON a fixed value of the parameter
+
+**TENTATIVE:**
+    GLOBAL PARAMETER, NOT VERIFIED for BHAG2020, NOT ON SILICON
+
+PULP_CLUSTER parameter is used by ETH, so move it to TENTATIVE
+
+CLINT EXTENSION YES without any parameter
+
+ACTION: debug link and lowRISC interrupt controller
+

cores/MeetingMinutes/May.14.2020.md

@@ -0,0 +1,85 @@
+Cores TG Meeting
+----------------
+
+Date: May 14, 2020
+
+Attendees:
+
+  Davide Schiavonne (OpenHW)     : [email protected]
+  Rick O'Connor (OpenHW)         : [email protected]
+  Mike Thompson (OpenHW)         : [email protected]
+  Jérôme Quevremont (Thales)     : [email protected]
+  Sebastien Jacq (Thales)        : [email protected]
+  Zbigniew Chamski (Thales)
+  Kevin (Thales)
+  Marco 
+  Massimiliano 
+  Arjan Bink (Silicon Labs)      : [email protected]
+  Steve Richmond (Silicon Labs)  : [email protected]
+  Paul Zavalney (Silicon Labs)   : [email protected]
+  Yunhai Shang
+  Jeremy Bennett (Embecosm)      : [email protected]
+
+- Introductions
+
+  As it was a relatively long time since the previous Cores TG meeting we went through an introduction round in which
+  everybody introduced himself. Davide is the director of engineering for the Cores TG; Arjan Bink is the chair of the Cores TG;
+  Jérôme Quevremont is the vice-chair of the Cores TG.
+
+- Scope / charter
+
+  The charter of the Cores TG was proposed/discussed. Compared to the previous charter the significant change is that the
+  actual roadmap definition and core donation acceptance is now defined to be performed at TWG level.  The Cores TG and the
+  other TGs will provide technical support to aid the TWG to perform that task.
+
+  Mike asksed for a documented process for core adoption (this process will need to be defined in the TWG).
+
+- Cores
+
+  Arjan presented the high-level overview of the CV32E40P and CV32E40 cores. Jérôme did the same for CV64A and CV32A. CV32A is
+  a new core proposal by Thales and can basically be thought of as a 32-bit Ariane. Within Thales this CV32A is intended
+  for two types of projects: ASIC-based, FPGA-based. The CV32A has not yet been officially offered to or accepted by OpenHW.
+  Jérôme indicated that he expects this core to be in a shareable state in a couple of months.
+
+  Rick indicated that it is rarely early enough to share cores (in order to increase collaboration, feedback, buy in).
+
+  Rick polled for interest in a M0-class RISC-V core. Both Silicon Labs and Thales (3 teams as users for FPGA) showed interest.
+
+- Status of CV32E40P
+
+  The (design) status of CV32E40P was presented. We are nearly feature complete, but many (i.e. > 100) tickets are still open
+  on https://github.com/openhwgroup/cv32e40p/issues/ (documentation, bugs, questions, etc.). Not all of these tickets apply
+  to CV32E40P (and proper labels will be added).
+
+  Help is asked to the OpenHW members to drive these tickets to closure. Please inform Davide Schiavonne ([email protected])
+  if you can help out getting these tickets closed.
+
+- Call to action
+
+  Please let us (e.g. Davide Schiavonne ([email protected]) know if you can help out on any of the following topics:
+
+  - Help fixing issues from https://github.com/openhwgroup/cv32e40p/issues
+    - RTL fixes
+    - Documentation
+    - Questions
+    - Future improvements (e.g. PMP, User mode)
+
+  - Drive finalization of CV32E40 feature set discussion, drive adoption of Ariane from ETH Zurich PULP team, drive CV64A and 
+    CV32A feature set discussion.
+
+- Next meetings
+
+  Next meetings will be a bit earlier, 16:00 CEST (allowing participation from both the US/Canada and Asia). Meeting frequency
+  will be adaptable (every 2-4 weeks on to be announced days). 
+
+  Asked for partner presentations (please ask us for a slot) of about 15 minutes addressing with the following content: 
+  A) Introduction of partner B) How can you benefit from OpenHW? C) How can you contribute to OpenHW?
+
+  Paul proposed 'way of working in github' as topic. This will be considered (but might be more appropriate at the TWG level).
+
+- Actions
+
+  - Mike : Provide prioritized list of required CV32E40P documentation issues
+  - Team : Consider to volunteer for helping out on issues from https://github.com/openhwgroup/cv32e40p/issues
+  - Team : Consider to volunteer for the other tasks mentioned on slide 7
+  - Team : Consider to volunteer for 15 minute partner presentation

cores/MeetingMinutes/Nov.19.2019.md

@@ -0,0 +1,100 @@
+Date: November 19, 2019
+
+Attendees:
+
+Mike Thompson : (OpenHW)       : [email protected]
+
+Davide Schiavone (OpenHW)     : [email protected]
+
+Steve Richmond (Silicon Labs)  : [email protected]
+
+Paul Zavalney (Silicon Labs)   : [email protected]
+
+## Forking or moving the IPs?
+
+Forking the core IPs into the OpenHW GitHub account.
+The pulp ones would have explicitly declared “UNMAINTAINED” in the README file and a link and a description 
+would explain the users where to find the maintained core etc. 
+Differently from LowRISC, where zero-riscy has been moved to lbex with re-direction. 
+This implies that the zero-riscy page under the pulp-platform does not exist anymore.
+
+Moving the core IPs into the OpenHW GitHub account.
+A second chat with the PULP team actually made up few weak points of the forking option: although having an explicit 
+description of what happened makes sense to me and let the users understand what is going on, 
+it will probably happen that (unaware) users will still pull the core from the pulp platform, 
+raise issues, propose pull requests etc. 
+We must avoid at all costs duplication and thus, 
+we think the safest and cleanest option is to do like we have done with Ibex.
+
+**Participants agree in doing the lowRISC/Ibex way**
+
+Another concern from the PULP team is: is there a person/group of people that will actively work on 
+the cores (technically speaking) to solve bugs etc 100%?
+It happened to LowRISC, so the PULP team is very concerned of knowing this before proceeding with the GitHub transfer.
+
+
+Mike: 
+Is the PULP team looking for a commitment? Personally, I am completely committed to a complete verification 
+of the CV32 and CV64 cores. But who the heck is "Mike Thompson" and what does "complete verification" actually mean?
+These are legitement questions and we need to find a way to make the PULP team confident that OpenHW Group 
+can and will do what we say we will do.
+
+Davide:
+Well, Mike is doing verification :) yes, but one person alone is probably not enough 
+(at least that is what I have seen looking at LowRISC). Plus, once Mike finds the bug, who is going to fix it?
+
+Rick O'Connor:
+we now have 20+ members in OpenHW Group with FTE commitments (some as many as 3 FTEs) - 
+this is where the resources come from. No change here, this has been the model all along.
+
+
+Davide suggests to set a technical team as soon as possible. 
+Mike will report it to Rick this afternoon. Sebastian (SiLabs) is in charge for allocating 
+people in this team for SiLabs. We do not know about the others members. 
+Rule of thumb estimation of RI5CY complexity is 3x Ibex and Ariane is 4x Ibex.
+Ibex needed 3.5FTE working 9 months on codestyle, compliance, verification, bug fixes, 
+system integration and documentation. 
+
+**Top priority ACTION: set a technical team as soon as possible to start working on the cores to meet the BHAG2020 deadline.**
+
+
+
+## Credits, Authors
+
+The PULP team would require that the list of authors/contributors that work on the cores remains in the 
+HEADER files together with the licence. 
+In addition, papers written about those cores should appear for citations in the README file (as for Ibex)
+
+
+Paul suggests to do like Ibex with contributors listed in an .md file.
+So far we are not aware of any HEADER from OpenHW. Currently the PULP IPs have the Solderpad (Apache 2 HW version) licence. 
+
+**TODO: Find HEADER from OpenHW and make the contribution file.**
+
+## Marketing name
+
+It is fine to refer to the 2 cores with the name proposed (CV*) and to have the repositories called accordingly but, 
+shouldn’t we leverage the “marketing”/”visibility” that the names RI5CY and Ariane gained along these years? 
+After all, people know about them with those 2 names. 
+Do we agree to have another name next to the technical ones ? (as for instance Android does with its releases). 
+If so, how ? just in README?
+
+Paul, Rick and Davide agree on renaming the database of those 2 IPs to CV* but to reference RI5CY and Ariane on README, 
+slides, etc, for Marketing reasons.
+Credits and Reference should be like in Ibex (with page of contributors and references to papers)
+
+## Other topics:
+
+Adding extra MIE,MPI,MTVEC for extending the fast interrupt pins on the CLINT.
+
+Paul likes the idea of extending the CLINT to have an extra 32bits FAST INTERRUPTS. 
+**ACTION:** Let’s discuss it again but the idea looks good as long as we are compatible and verify them. 
+
+**PAUL Question:** having a meeting on Debug SPEC and integration on this IP into the CV* IPs.
+DAVIDE ACTION: ask LowRISC if they are using the same debug IP. → LowRISC replied: yes, we use it!
+
+
+
+
+
+