systemes_libre/Systemes_Libres_Amazon_Alexa_IOT_Pitch_10-JUN-2020.mdwn

   1 # Systèmes Libres Amazon Alexa IOT Pitch 10-JUN-2020
   2
   3 This is Cole's first draft of the script for Systèmes Libres' Wednesday, 10 June 2020 pitch meeting with Amazon Alexa's IOT division, which will be presented by Yehowshua. Please edit, rearrange, and add relevant points as you see fit. I will be taking this script and turning it into a pretty 'business-deck' on Monday, 8 June 2020, so please help today (Sunday 7 June 2020) if you can.
   4
   5 Questions that I think need to be answered by people with the relevant technical expertise are bolded. Thanks everyone for helping if you can!
   6
   7 # Title Page
   8
   9 Systèmes Libres
  10
  11 Delivering robust low power, high-performance hardware for IOT and Edge Compute
  12
  13
  14 # Part 1 - Current GPU IOT Device Shortcomings
  15
  16 1. GPU is in ADDITION to CPU (2 processors, 2 ISAs, 2 compilers)
  17
  18   a. Hardware backdoors: In the industrial IOT and RTOS market, significant harm can be done by malevolent actors and competitors by hacking hardware and causing it to do damage, or hacking the hardware to steal proprietary company secrets
  19
  20   b. Power: 2 separate cores (CPU, GPU) leads to much higher
  21      power consumption
  22
  23   c. Capability: In RTOS devices, can't make effective use of the GPU
  24
  25   d. the drivers involve an inter-core RPC mechanism: which is unacceptably high latency and complexity
  26
  27   e. Furthermore, current RTOS microcontrollers have much lower mathematical numerically intensive computational performance at the same power and silicon area compared to our chip.
  28
  29 2. Time/Ease of Use/Development: Proprietary development tools and documentation result in an often difficult and long development cycle, especially when rebuilding and optimizing arithmetically intensive algorithms for embedded systems.
  30
  31 3. Amazon's Sagemaker and Intel's ngraph are steps in the right direction, but ultimately will never be able to provide comparable ease-of-use and insight into every level of the product.
  32
  33 4. Proprietary GPU inner workings are not available for inspection, neither during active development nor during a critical evaluation phase for their suitability.
  34
  35
  36 # Part 2 – How is Libre-SOC different? Or What Makes Libre-SOC better?
  37
  38 * (*Addresses #1*) Systèmes Libres is developing an SOC with a fused CPU-GPU architecture
  39
  40 * This hybrid CPU-GPU will have a lower power budget (**what and how?**) (*addresses a.*), and higher computational performance than to competing SOCs (*addresses c.*) like the Broadcom BCM2836 (**what are their power, and performance specs? Why are using specifically BCM2836 as a comparison?**)
  41
  42 * Systèmes Libres is developing RTOS drivers using Systèmes Libres' Simple-V dynamically partitionable vector algorithm (**what is it? what makes it different? what are its relative benefits and short comings?**) that automatically handles algorithmic optimization and reconfiguration.
  43
  44 * Systèmes Libres is developing graphics and compute drivers in conformance with the open standards Vulkan and OpenCL (**should we remove opencl until we have had a proper discussion of ROCM on bugzilla?**).  Using open standards makes rebuilding or using existing algorithms a simple and easy process.
  45
  46 * Systèmes Libres’ completely libre hardware-software stack enables an unprecedented level of insight into the entire system.
  47
  48  a. Developers can begin their investigations at the top analyzing high-level software, then down into firmware.
  49
  50  b. at the lowest level, they can examine detailed schematic diagrams.
  51
  52  c. The developer can easily see the function of individual components as well as all of the relationships in the system.
  53
  54 # Part 3 - Security and Privacy in RTOS and Industrial IOT
  55
  56 * Companies try to security-harden their software by writing it in special languages like Ada, or using c++ with static code analyzers and special 'Safety-critical' c++ coding guidelines. However, all of this time and money is wasted if the hardware running underneath this software is hopelessly insecure (**picture intel meltdown, spectre ahhhh!!**)
  57
  58 (jacob: note that our processor is most likely still vulnerable to some variants of spectre unless we make a special effort in the instruction scheduling HW, load/store unit, caches, branch predictor, etc. see <https://bugs.libre-soc.org/show_bug.cgi?id=209>
  59 additional good example bugs would include intel's ME vulnerabilities)
  60
  61 * For example, in the self-driving car domain, the concern about GPU-capable RTOS devices being insecure at the hardware level causes significant barriers to self-driving car adoption because the public is scared that someone will 'hack' their car and crash it
  62
  63 * Almost every credit card and banking transaction is dependent on transaction processing servers, if these are hacked $M to $B of economic damage can be done
  64
  65 Financial hardware such as cryptocurrency hardware wallets, and traditonal banking hardware from ATMs to stock terminals and transaction processing servers containing can be trusted with a much greater degree of confidence if the hardware crypto chips which they rely on are formally verified, with the entire HDL available for a full independent audit.
  66
  67
  68 # Part 4 - Low Power Requirements of RTOS and Industrial IOT Devices
  69
  70 * At the level of individual sensors, power draw must be minimized as these are often running off very small batteries
  71
  72 * At the level of millions of sensors, power draw must be minimized to lower the overall power bill
  73
  74 * Our hybrid CPU-GPU chip uses less energy that existing microcontrollers that use a cpu with a tacked-on gpu (**numbers??**)
  75
  76
  77 # Part 5 – Conclusion
  78
  79 1. Better security
  80 2. Lower cost
  81 3. Lower power
  82 4. Higher computation at same power
  83 5. Ease of use and development
  84 6. Flexibility for customisation