You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

11 KiB

title date attendees draft
Meeting Minutes 2021-06-09 2021-06-09
paullecocq,ibm
toshaanbharvani,vantosh
timansell,google
billflynn,ibm
toddrosedahl,ibm
paulmackerras,ibm
false

Call to Order

Anti-trust Reminder

This is a reminder that all OpenPOWER Foundation activities are subject to strict compliance with the OpenPOWER Foundations Antitrust Guidelines. Each individual participant and attendee at this meeting is responsible for knowing the contents of the Antitrust Guidelines, and for complying with the Antitrust Guidelines. Copies of the Antitrust Guidelines are available at: Antitrust Guidelines in Google Drive or Antitrust Guidelines OPF in OpenPOWER Foundation member area

Workgroup Housekeeping

Minutes

Reminder of workgroup collaboration tools

Last Meeting Follow-up

  • New Business

  • Git Repository Structure

  • Maintainers

    • Tim Ansel (Google)
    • Tim Pearson (Raptor)
    • Karol Gugala (Antmicro)
    • Toshaan Bharvani (VanTosh)
  • Options for hardware

  • AC922 Interposer Update https://git.openpower.foundation/librebmc/ac922interposer

  • First milestones and actions

    • Need to start getting content into git
    • License file : Apache V2 with hardware
    • Readme
  • BoxArty FPGA image into Github as a starting point

    • Blocking issue is license compatibility
    • BoxArty is built from
    • Microwatt which is CCx4 (moving to Apache V2 + patent rights)
    • LPC code from Kestrel which is GPL v3
    • This is not compatible with non-viral ApacheV2
    • Intel LPC (low pin count) is a bi-directional bus, transfers host firmware to HPM, legacy bmc to host interface
    • Options to fix:
      1. find a different LPC source
      2. Raptor relicense LPC under non-viral license
    • First work item once microwatt is linked to LibreBMC
    • Optimize microwatt for size and performance needed for BMC
    • Build time for quad core vexRiscV reported to be around 5 mins, current microwatt is ~10 mins. Can improve through tooling or RTL design. Single core size with peripherals is ~50% of Arty 100T
    • Most users have Arty 35C
    • VexRISC-V vs BoxArty Microwatt
  • Work Items “Create microwatt equivalent of https://github.com/litex-hub/linux-on-litex-vexriscv repo” https://github.com/litex-hub/linux-on-litex-microwatt https://github.com/litex-hub/pythondata-cpu-microwatt/blob/master/pythondata_cpu_microwatt/init.py

  • LPC controller (RTL)

  • PowerPC core optimization (RTL)

  • Symbiflow toolchain optimizations for build times EDA software

Open Discussion

As we are targeting Artix7, are we planning to focus on open tools, Symbiflow Answer is yes, use open source tools first Only allow upstream of designs that do not break open source tooling until the open sourcing tools Need CICD pipeline that is common and accessible Need to figure out where to host this, what resources Raptor could volunteer some OpenPOWER will host front end OSU open source lab Action Items Need lower resource core to replace microwatt in the future Need to be FPGA optimized Work streams Core optimization for FPGA

Start document of links to tools and hardware for others to replicate work.

http://j.mp/openfpga-diagram

https://symbiflow.readthedocs.io/en/latest/toolchain-desc/design-flow.html

https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html#linux-litex-demo

https://hdl.github.io/containers/#_graphs

Diagram of all open tools, how they fit together, what is missing, what needs significant improvement - FuseSoc, OpenLane, Symbiflow, Yosys, openroads, etc https://github.com/hdl EDA Tooling - Containers - https://github.com/hdl/containers Make sure these support Power. I believe that Rob Taylor added Power support. EDA Tooling - Conda - https://hdl.github.io/containers/

EDA Tooling - if you are a Bazel fan; https://github.com/hdl/bazel_rules_hdl Used by Googles XLS team -> http://github.com/google/xls

Add current projects that you are working on that relate to LibreBMC or opentools. Plan would be to schedule presentations on them to stir conversation and collaboration. This will highlight areas where technical issues can be worked across projects.

Next Meeting Agenda Items

Future topics

  • Arjun to present
  • Tim Pearson to give update on where Raptor is going with Kestrel

WEBEX CHAT HISTORY

from Toshaan Bharvani (External) to Everyone: 10:03 AM Anybody coming in late, please not that this meeting is being recordered from Lance Albertson (External) to Everyone: 10:07 AM Are you able to hear me? from Timothy Pearson (External) to Everyone: 10:07 AM No from Lance Albertson (External) to Everyone: 10:07 AM Let me reconnect my audio from Tim 'mithro' Ansell (External) to Everyone: 10:09 AM Paul: Can you put a link to do doc here? from Paul Lecocq (IBM) to Everyone: 10:09 AM https://docs.google.com/document/d/15wC51JWJl5HOjijP8mmfvUtvws5RQaVZDgI8TvTqr9c/edit# from Paul Lecocq (IBM) to Everyone: 10:16 AM Slack / IRC https://openpowerfoundation.slack.com/archives/C01UVKFKUQY #librebmc on libera / freenode (namespace) https://chat.openpower.foundation/opf/channels/librebmc Google Drive https://drive.google.com/drive/u/1/folders/1p7YL3urCf4NtYbJTRxXDluytmMotUwty OPF Discuss https://discuss.openpower.foundation/c/sig/librebmc/11 GIT repository https://git.openpower.foundation/librebmc/librebmc Larger shared storage area to save meeting recordings Files.openpower.foundation

Chat History

from Alexey Stepanov YADRO (External) to Everyone: 10:19 AM kind of welcome thread, good idea! from Alexander Amelkin [YADRO] (External) to Everyone: 10:19 AM OpenBMC has moved from FreeNode to Discord. Did you consider moving there as well? from Toshaan Bharvani (External) to Everyone: 10:22 AM No, I did not, I will need to look into Discord, I did consider OFTC and we do have a channel there, but not official from Timothy Pearson (External) to Everyone: 10:23 AM Discord requires people either run a binary on their machine (no open source client) or keep a Web browser open. On this side, it has the same issues as Slack without significant advantages from Timothy Pearson (External) to Everyone: 10:24 AM In our experience, there's a lot of the dev community prefers IRC or mailing list, and if not then Github or similar where the Web tooling is designed for asynchronous work from Alexander Amelkin [YADRO] (External) to Everyone: 10:27 AM I understand this point. However, I personally think IRC is completely obsolete in 2021, and the only way to more or less efficiently use it is connecting to it via Matrix / Riot, which also imlies running a binary. :) from Timothy Pearson (External) to Everyone: 10:28 AM If it's a matter of functionality, there's also open source options for the more centralized model. :) from Timothy Pearson (External) to Everyone: 10:29 AM e.g. Mattermost from Toshaan Bharvani (External) to Everyone: 10:29 AM We want to maintain an IRC solution and we have mattermost also on chat.openpower.foundation from Timothy Pearson (External) to Everyone: 10:30 AM yes, agreed from Timothy Pearson (External) to Everyone: 10:30 AM just saying I don't want things to move in a direction that requires proprietary clients for effective collaboration. from Timothy Pearson (External) to Everyone: 10:31 AM appreciate all the integration work toshaan! from Toshaan Bharvani (External) to Everyone: 10:32 AM I do not know Discord, I will look at it just for informational purposes from Alexander Amelkin [YADRO] (External) to Everyone: 10:32 AM Why do we need that scratch space for OpenBMC ? OpenBMC uses Gerrit Review, which can (and does) effectively serve as a scratch space. from Toshaan Bharvani (External) to Everyone: 10:33 AM for staging new functions and checking compatibility from Alexander Amelkin [YADRO] (External) to Everyone: 10:34 AM I'm just worried that we could end up like Intel with their Intel-BMC that diverges quite significantly from OpenBMC and is rarely merged back. from Timothy Pearson (External) to Everyone: 10:35 AM That's always a concern if a primary goal isn't to upstream the work on a regular basis. It's something we've had to struggle with as well; the only solution to it is resources that are available and ready / willing to quickly rewrite any of the new code to upstream's expectations or desires. from Timothy Pearson (External) to Everyone: 10:36 AM Basically, we can either move fast and break things (add functionality rapidly) or move at the speed of upstream merges. from Timothy Pearson (External) to Everyone: 10:36 AM So which one is the primary goal? :) from Toshaan Bharvani (External) to Everyone: 10:37 AM No, we will monitor that from Alexander Amelkin [YADRO] (External) to Everyone: 10:38 AM I guess, unless we set up a policy for upstreaming our changes from "the scratch" on a regular basis, we will inevitably diverge. from Timothy Pearson (External) to Everyone: 10:39 AM In our experience yes, and that would have to basically include a stop work until the merges are complete. Maybe something like the Linux merge windows -- devs can keep additional changes local / out of staging, but no further changes / enhancements accepted that aren't directly related to upstreaming accepted until upstream merges? from Toshaan Bharvani (External) to Everyone: 10:40 AM Ok, we will document some policy around that from Alexander Amelkin [YADRO] (External) to Everyone: 10:41 AM Sounds good from Alexander Amelkin [YADRO] (External) to Everyone: 10:50 AM You're discussing some diagram, but I can't see any media shared. Is it just me? from Toshaan Bharvani (External) to Everyone: 10:51 AM That is in the google docs for the moment from Alexander Amelkin [YADRO] (External) to Everyone: 10:52 AM Oh, ok from Karol Gugala (External) to Everyone: 11:00 AM I have to switch to another meeting from Karol Gugala (External) to Everyone: 11:00 AM bye from Michael (External) to Everyone: 11:01 AM Need to run too...