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, but obviously we are incurring some delays due to the deluge of payment requests ;)
   4
   5     You requested a neat round sum of 100000 euro.
   6     Can you provide some more detail on how you arrived at this amount?
   7     Could you provide a breakdown of the main tasks, and the
   8     associated effort? What rates did you use?
   9
  10 last question first: we've learned (painfully, by losing opportunities
  11 and team members) that the prior rates which were around EUR 1500 per
  12 person are inadequate to attract the quality we need, and had to double
  13 it.  I (personally) used to be ok when working out of Taiwan for 3 years
  14 on EUR 1200-1500, and Jacob was in student-subsidised accommodation.
  15
  16 bottom line: 3 people, at EUR 3,000, is actually only 11 months duration.
  17 if we include binutils part-time as 0.25 people it's only 10 months.
  18
  19 these are the tasks:
  20
  21 * ongoing communication with OPF ISA WG: over 12-18 months,
  22   it takes appx 1-2 hours per day of communication time to
  23   prepare and answer questions.
  24 * preparation (and revision) of RFCs: although they are templatable
  25   and partial cut/paste from the wiki the revisions are not, needing
  26   ongoing feedback.  plus, we will need approximately 20-25 RFCs.
  27 * Compliance Test Suites: there are already thousands of unit tests,
  28   these need to be expanded for the 8/16/32-bit work (thousands, in
  29   each bit-width).  Again: several months of work
  30 * Developing and improving the Simulator itself, to confirm correct
  31   functionality: again, several months (this is always ongoing)
  32 * The Test API: this will be a simpler self-contained task to make
  33   it auto-generate Makefiles (and cover other systems), and
  34   also by this time we will have cavatools in the mix: approx 8 weeks
  35 * binutils needs ongoing updates, an estimated budget covering
  36   10-14 weeks would be good.
  37
  38     Is there meanwhile news on the requirements of IBM and the ISA WG?
  39
  40 somewhat.  the page is now open - https://openpower.foundation/isarfc/ -
  41 and they have prepared a process/procedure document (legally required
  42 to be followed, under the OPF's ByLaws), which is adapting as we're
  43 literally the first people to use it.
  44
  45
  46
  47     A request for 100k is very large, and the timelines are
  48     pretty long too.
  49
  50 yes and no. if we assume 3 people (one junior editor, two and a half
  51 programmers: simulator, unit tests, binutils) it actually doesn't go far.
  52
  53    Can we not take it step by step?
  54
  55 EUR 50,000 assuming 3.5 people at EUR 3,000 is actually only 5 months.
  56 realistically that would mean we would actually need to begin the
  57 submission process on the very next cycle! (2022-10E - 2022-12E would
  58 be more likely, but slightly pushing our luck)
  59
  60    It would be better for us to achieve this incrementally, as in:
  61    start with a smaller amount for meeting submission criteria for
  62    the block of instructions, deliver initial code, tests,
  63    documentation - and when more budget is needed, a new chunk is added.
  64
  65 I don't have a problem with that, if you are fine with the extra admin
  66 work :)
  67
  68     What would work on the legal compliance for the development look
  69     like? Who would be doing that?
  70
  71 IBM - or more to the point the OPF ISA WG - requesting that all
  72 contributors sign an "Inbound Patent License Agreement".  in our
  73 case there *aren't* any patents, but we still have to sign an
  74 agreement that there aren't any, and, also, that if we *do* create
  75 any patents that those will be assigned to the OPF immediately.
  76 Perhaps some legal assistance in reviewing that agreement might
  77 be a good idea?
  78
  79     How would you manage such a large amount of RFCs, which must
  80     be perceived as a denial of service at the WG?
  81
  82 carefully!  we have been warning them consistently and persistently
  83 for 24 months.  each RFC when it gets to the "Presentation as
  84 actual Changes" stage, will be passed through to compiler and
  85 hardware experts for their consideration.  IBM has had many many
  86 RFCs in-house over the years: this isn't something that's new to
  87 them.
  88
  89     Is there infrastructure in place to manage the lifecycle of each RFC?
  90
  91 yes.  the bugtracker, wiki, and mailing list, and the RFCs themselves
  92 are in the git repository that's behind the wiki.  full cross-referencing
  93 in each has been found over a 4 year period of managing this project.
  94 Example:
  95
  96 * https://libre-soc.org/openpower/sv/rfc/ls001/
  97 * https://git.libre-soc.org/?p=libreriscv.git;a=history;f=openpower/sv/rfc/ls001.mdwn
  98 * https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-October/005344.html
  99 * https://bugs.libre-soc.org/show_bug.cgi?id=924, note the discussion
 100 * https://libre-soc.org/openpower/sv/rfc/ls001/discussion/
 101
 102     How are discussions going to be linked to each RFC?
 103
 104 By a cross-referenced URL in each one, and the standard practice
 105 of adding a "discussion" page in the wiki if necessary, although
 106 this is often subsumed by the bugtracker.
 107
 108     What are the timelines?
 109
 110 based on 3.5 people, only around 10 months.
 111