1 / 16

HW/SW Codesign for Reconfigurable System-on-Chip using a Process Model

HW/SW Codesign for Reconfigurable System-on-Chip using a Process Model. Neil Bergmann. University of Queensland, Brisbane Australia. Topics. Reconfigurable System-on-Chip Egret – our experimental platform HW/SW co-design with processes Processes in Linux, IPC HW/SW Processes An Example.

josephine-gilbert
Download Presentation

HW/SW Codesign for Reconfigurable System-on-Chip using a Process Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HW/SW Codesign for Reconfigurable System-on-Chip using a Process Model Neil Bergmann University of Queensland, Brisbane Australia

  2. Topics • Reconfigurable System-on-Chip • Egret – our experimental platform • HW/SW co-design with processes • Processes in Linux, IPC • HW/SW Processes • An Example

  3. Reconfigurable System-on-Chip RAM MAC PHY MAC PHY MAC PHY Memory Control FLASH Hardware Accelerator CPU RAM Hardware Accelerator Hardware Accelerator RAM FPGA

  4. Egret – our experimental platform A standard platform allows targetted tool support, design re-use, and better time-to-market • Xilinx FPGAs (Spartan 3, V2, V2Pro, V4) • Microblaze or PowerPC CPUs • Dev Boards – Memec, Suzaku, Xilinx ML, Xilinx XUP, NASA RSC • Linux OS (uCLinux 2.4) • Ethernet networking • Xilinx ISE/EDK design flow ++

  5. Platform details available free on UQ website • petalogix is a small consulting company that does services work around platform use – improves the impact of our research.

  6. HW/SW co-design Modules Partitioning Requirements HW Design SW Design HW Test SW Test System Integration System Test

  7. HW/SW co-design with processes SW Design SW Test on PC Processes Requirements SW Test on ES Port to ES System Test Partitioning HW Design HW Test System Integration

  8. HW/SW Processes • Standard Linux processes used as modules for hw/sw system specification. • Use standard Linux IPC mechanisms • Prototype on desktop Linux – good debugging tools to test functional correctness • Can port directly to embedded Linux (perhaps 50 times slower)

  9. HW/SW Processes • Clean abstraction – all communication is via formal IPC mechanisms, no side effects • Easy for Linux to build systems corresponding to communicating processes • Good formalisms (CSP, CCS) • Implied parallelism • Start, run, suspend, resume, end

  10. Linux IPC • Pipes • FIFOs (named pipes) • Shared memory • Semaphores • Signals • Sockets • Messages

  11. Hardware IPC Pipes FIFOs FSL FIFOs Shared Memory Dual Port BRAMs Semaphores Signals Interrupts Sockets Messages ??????????

  12. Shared Memory/Synchronisation IN MEM OUT MEM Repeat{ P(InFull) P(OutEmpty) {ReadIn Process Data Write Out} V(OutFull) V(In Empty) } Repeat{ P(InEmpty) Write block to In V(InFull) } Repeat{ P(OutFull) ReadOut V(OutEmpty) } Problem ! – no parallelism between adjacent tasks Solution! – Double Buffers

  13. Ghost Processes • A SW proxy associated with HW process • Linux starts SW process conventionally which sets up HW process, comms, etc. • Can convert HW signals to system calls and vice versa • Should avoid all comms going through ghost process - inefficient

  14. System Overheads • Significant problem, but no worse than conventional software. • For example, semaphore cost is approximately 100 memory accesses – need large (1Kword) blocks to make transfers efficient • Real parallelism takes some effort to harness

  15. Dynamic Partial Reconfiguration Static Part Microblaze ICAP Networking LED DISPLAY ROM LED DRIVER ROM Reader UART UART DRIVER 9600 baud UART DRIVER 56000 baud ROM ROM Reader Configuration Store Device Driver Device Driver

  16. Conclusions • HW/SW co-design flow easy to use • System overheads still require attention • Also looking at other IPC mechanisms: • FIFOs (FSL) • Function calls • OCF (Open Crypto Framework) • MPI for multi-CPUs • Haven’t found a convincing DPR scenario

More Related