• View
• Edit
• History
• Print

20141205Notes

• Update on current design
  • statically scheduled dreamer + few extra instructions
  • parametrizable network arch.
  • workloads: radio astronomy ones (correlator, spectrometer)
• mixed-precision vector unit seems perfect match for correlator and spectrometer
• look at PERFECT DSP kernels - already have some benchmarks written and data for Rocket
• interesting programming perspective (Actor Model): producer/consumer use and network architecture/programming
  • consume producers on the fly, which GPUs have only recently added (and are not available to the CUDA programmer?)
• communication: blocks of data faster than bits
  • know communication and data overhead beforehand, so double buffer to hide memory latency
• compare efficiency with that of GPUs, but also general rocket chips with accelerators
• justification
  • why this is not just a RISC-V Tilera, etc.
  • spatial computing model we use is different
• current memory management idea:
  • memory-mapped queues
• suggestion: use Henry’s cache coherency system, extended to 16 or 32 tiles, to keep data caches coherent
• improve standard multicore coherency system: directly communicate across tiles instead of going through L2 coherent cache
• next thing to add: VLS (DMA on each tile, mem copy from L2 to L1 but actually change physical address), also VLS between tiles, can use snoopy for first iteration
• benefit of this system: works with standard multicore programming (OpenMP)
• IO: use little RISC-V to handle IO, which just looks like another Tile
• actor model: see slides from Krste’s presentation
• use virtual data addressing
• retreat presentation:
  • story: top-down, space-time computing in general, with a specific proposal (Hurricane)
  • discuss apps, actor networks (and how poorly they map to both FPGAs and GPUs), simple programming model
  • discuss how we’re different from typical multicores (Xeon Phi)
• network:
  • add multiple physical networks to promote coherency and communication
  • full crossbar
  • less focus on network, more on local computing and programming/compiling (communication avoiding)