nlnet_2022_opf_isa_wg/discussion.mdwn

   1 # Questions
   2
   3 you applied to the 2022-08 open call from NLnet. We have some questions regarding your project proposal Libre-SOC OpenPOWER ISA WG
   4
   5 **
   6     You requested a neat round sum of 100000 euro.
   7     Can you provide some more detail on how you arrived at this amount?
   8     Could you provide a breakdown of the main tasks, and the
   9     associated effort? What rates did you use?
  10 **
  11
  12 last question first: we've learned (painfully, by losing opportunities
  13 and team members) that the prior rates which were around EUR 1500 per
  14 person are inadequate to attract the quality we need, and had to double
  15 it.  I (personally) used to be ok when working out of Taiwan for 3 years
  16 on EUR 1200-1500, and Jacob was in student-subsidised accommodation.
  17
  18 bottom line: 3 people, at EUR 3,000 (which is **1/5th** of the commercial
  19 rate for quality work of this type), is actually only 11 months duration.
  20 if we include binutils part-time as 0.25 people it's only 10 months.
  21
  22 these are the tasks:
  23
  24 * ongoing communication with OPF ISA WG: over 12-18 months,
  25   it takes appx 1-2 hours per day of communication time to
  26   prepare and answer questions.
  27 * preparation (and revision) of RFCs: although they are templatable
  28   and partial cut/paste from the wiki the revisions are not, needing
  29   ongoing feedback.  plus, we will need approximately 20-25 RFCs.
  30 * Compliance Test Suites: there are already thousands of unit tests,
  31   these need to be expanded for the 8/16/32-bit work (thousands, in
  32   each bit-width).  Again: several months of work
  33 * Example algorithms: strncpy, quicksort, insertionsort, UTF-8
  34   validation and conversion to UTF-16; more Audio/Video examples - all of
  35   these are critically important showcases. Each example chosen
  36   can average around 1-2 weeks work.  They all help with the
  37   critical "justification" which is already underway as part of
  38   https://libre-soc.org/openpower/sv/rfc/ls001/ which already has
  39   some of the examples from unit tests.
  40 * Developing and improving the Simulator itself, to confirm correct
  41   functionality: again, several months (this is always ongoing)
  42 * The Test API: this will be a simpler self-contained task to make
  43   it auto-generate Makefiles (and cover other systems), and
  44   also by this time we will have cavatools in the mix: approx 8 weeks
  45 * binutils needs ongoing updates, an estimated budget covering
  46   10-14 weeks would be good.
  47
  48 **
  49     Is there meanwhile news on the requirements of IBM and the ISA WG?
  50 **
  51
  52 somewhat.  the page is now open - https://openpower.foundation/isarfc/ -
  53 and they have prepared a process/procedure document (legally required
  54 to be followed, under the OPF's ByLaws), which is adapting as we're
  55 literally the first people to use it.
  56
  57 **
  58     A request for 100k is very large, and the timelines are
  59     pretty long too.
  60 **
  61
  62 yes and no. if we assume 3 people (one junior editor, two and a half
  63 programmers: simulator, unit tests, binutils) it actually doesn't go far.
  64
  65 **
  66    Can we not take it step by step?
  67 **
  68
  69 EUR 50,000 assuming 3.5 people at EUR 3,000 is actually only 5 months.
  70 realistically that would mean we would actually need to begin the
  71 submission process on the very next cycle! (2022-10E - 2022-12E would
  72 be more likely but cutting it fine)
  73
  74 **
  75    It would be better for us to achieve this incrementally, as in:
  76    start with a smaller amount for meeting submission criteria for
  77    the block of instructions, deliver initial code, tests,
  78    documentation - and when more budget is needed, a new chunk is added.
  79 **
  80
  81 I don't have a problem with that, if you are fine with the extra admin
  82 work :)  i appreciate it does mean not needing a special EU Auditor,
  83 and also an opportunity to review, half-way through.
  84
  85 **
  86     What would work on the legal compliance for the development look
  87     like? Who would be doing that?
  88 **
  89
  90 The OpenPOWER Foundation - probably using IBM or LinuxFoundation
  91 Legal Counsel - requesting that all contributors sign an
  92 "Inbound Patent License Agreement".  in our
  93 case there *aren't* any patents, but we still have to sign an
  94 agreement that there aren't any, and, also, that if we *do* create
  95 any patents that those will be assigned to the OPF immediately.
  96 There is also a Copyright Assignment requirement (which IBM also had
  97 to agree to, now that the Power ISA is owned by the OpenPOWER Foundation)
  98 Perhaps a budget for some legal assistance in reviewing that agreement
  99 might be a good idea?  NLnet has funded this work under its
 100 "Works for the Public Good" mandate: we don't want to be caught out
 101 here.
 102
 103 **
 104     How would you manage such a large amount of RFCs, which must
 105     be perceived as a denial of service at the WG?
 106 **
 107
 108 carefully!  we have been warning them consistently and persistently
 109 for 24 months.  each RFC when it gets to the "Presentation as
 110 actual Changes" stage, will be passed through to compiler and
 111 hardware experts for their consideration.  IBM has had many many
 112 RFCs in-house over the years: this isn't something that's new to
 113 them.
 114
 115 ultimately, though, by comparison with RISC-V having *seventy*
 116 unique Technical Working Groups, realistically it is simply
 117 the Power ISA that has a lot of catching up to do.  we will be
 118 the catalyst that drives that... carefully :)
 119
 120 **
 121     Is there infrastructure in place to manage the lifecycle of each RFC?
 122 **
 123
 124 yes.  the bugtracker, wiki, and mailing list, and the RFCs themselves
 125 are in the git repository that's behind the wiki.  full cross-referencing
 126 in each has been found over a 4 year period of managing this project.
 127
 128 then there is also the "main" page tracking *all* RFCs (which will
 129 get its own bugreport at some point)
 130
 131 * https://libre-soc.org/openpower/sv/rfc/
 132
 133 Example of the cross-referencing and history so far:
 134
 135 * https://libre-soc.org/openpower/sv/rfc/ls001/
 136 * https://git.libre-soc.org/?p=libreriscv.git;a=history;f=openpower/sv/rfc/ls001.mdwn
 137 * https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-October/005344.html
 138 * https://bugs.libre-soc.org/show_bug.cgi?id=924, note the discussion
 139 * https://libre-soc.org/openpower/sv/rfc/ls001/discussion/
 140
 141 **
 142     How are discussions going to be linked to each RFC?
 143 **
 144
 145 As above example: by a cross-referenced URL in each one, and the
 146 standard practice of adding a "discussion" page in the wiki if
 147 necessary, although this is often subsumed by the bugtracker.
 148
 149 **
 150     What are the timelines?
 151 **
 152
 153 based on 3.5 people? realistically only around 10 months.
 154 (EUR 50,000 cuts that by half).
 155
 156