Hardware Implementation of an RTOS Scheduler on Xilinx MicroBlaze Processor

Transcription

1 Hardware Implementation of an RTOS Scheduler on Xilinx MicroBlaze Processor MS Computer Engineering Project Presentation Project Advisor: Dr. Shahid Masud Shakeel Sultan Outline Introduction Objective RTOS Overview Overheads Why it introduces overheads? Scheduler Design & Implementation Scheduler parts Ready to Run (R2R) queue Priority Encoder Master FSM Synthesis results Performance evaluation Summary 2 1

2 Introduction A Real time operating system (RTOS) is a variant of OS that operates in constrained environment where computer memory and processing power is limited.. Moreover, it often needs to provide it s services in a definite amount of time. Hard RTOS, Soft RTOS Example RTOS: VxWorks,, Nucleus, RTLinux, µc/os-ii etc 3 Objectives To accelerate the RTOS performance by moving some part of RTOS into Hardware To identify different computational parts of the RTOS To implement the most computationally intensive part as an IP core Performance enhancement Improved Predictability 4 2

3 Services of RTOS Kernel RTOS Task Creation & Management Timers Memory Management Scheduling 5 System Layers Applications RTOS Board Support Package (BSP) Hardware 6 3

4 RTOS Overheads MiBENCH BenchMark Basic Math Standalone With OS # 0f cycles Overhead Cost = 1.8 Million Cycles 7 What Introduces Overhead? 8 4

5 Mirco C/OS-II Scalable Preemptive Multitasking Deterministic MicroC/OS /OS-II, The Real-Time Kernel, 2nd Edition 9 Task states A task can be in one of three states: executing on the CPU; ready to run; waiting for data. gets CPU ready executing preempted gets data needs data needs data gets data and CPU waiting 10 5

6 Hardware Scheduler 11 Scheduler Implementation R2R Queue Implemented as Partitioned BRAMs containing scheduler attributes. Priority Encoder to find out the highest priority task in the system Queuing operations (i.e. Enqueue/Dequeue) ) implemented in a Finite State Machine (FSM) 12 6

7 Ready to Run (R2R) Queue R2R Queue is implemented as partitioned BRAMs, where each priority level has a link list based FIFO PL- 0 Task -1 Task -2 Task - n PL- 1 Task -1 Task -2 Task - n PL- 2 Task -1 Task -2 Task - n 13 Scheduler Attribute Tables Thread Data BRAM (Indexed By TID) 0 Q 1-8 R2R Q next Pointer 9-15 Scheduling Priority level R2R Q Prev Pointer Unused Priority Data BRAM (Indexed by Priority) 0-7 Priority Queue Head Pointer 8-15 Priority Queue tail Pointer Unused 14 7

8 Scheduler Attribute table Manipulation Get_head_pointer (entry) Set_head_pointer (head_pointer,, entry) Get_tail_pointer(entry) Set_tail_pointer(tail_pointer,, entry) Get_priority(entry) Set_priority(priority,, entry) Get_next_pointer(entry) Set_next_pointer(next_pointer,, entry) Get_prev_pointer(entry) Set_prev_pointer(prev_pointer,, entry) 15 BRAMs CLK EN WE ADDR (8-Bit) DI (32-Bit) BRAM Dout (32 bit) 16 8

9 Priority Encoder CLK Reset Enable Input (128-Bit) Priority Encoder Output (7- Bit) 17 Priority Encoder (8- Bit Example) The Encoder finds the highest (i.e. Best) Priority level that has a 1 as its encoder input bit. Input (0 to 7) 1XXXXXXX 01XXXXXX 001XXXXX 0001XXXX 00001XXX XX X Output (0 to 2)

10 Scheduler CLK SCH_Reset SCH_Request Data (8-Bit) SCH_Opcode (6-Bit) Scheduler SCH_Busy Reset_done Preemption_INT 19 Scheduler Parts Controller/Decoder for Thread requests: If (SCH_request( SCH_request= 1 ) Case (SCH_opcode( SCH_opcode) ) is When => Enqueue_req<=1; When => Dequeue_req<=1; Request Enqueue Dequeue Isqueued Isempty Opcode

11 Enqueue Operation Start Find entry against TID from thread data BRAM PRI=t_entry.priority P_entry=Priority_data[PRI] Old_tail=P_entry.tail Flag=Encoder_input[PRI] Q=Empty Encoder_input[PRI]=1 P_entry.head=TID P_entry.tail=TID t_entry.prev=old_tail P_entry.tail=TID t_entry.next=tid Q=Non_empty If Prio(Cur_task)>(R2RQ_Highest_Prio) Then Raise Preemption Interrupt END 21 Enqueue Operation (Cont.) PL- 0 Task -1 Task -2 Task - n... Old_tail New_tail PL- 2 Task -1 Task -2 Task

12 Enqueue Operation Look up the tail pointer of priority queue corresponding to it s s priority level. Modify tail pointer s s next pointer to point to newly queued thread Modify newly enqueued thread s s previous pointer to the tail pointer Update tail pointer to newly enqueued thread 23 Dequeue operation The dequeue operation always removes the head of a given priority level s s queue (as indicated by priority encoder) It just moves the head pointer to the next pointer if a valid entry exists Run encoder Use priority level to look up head pointer Head pointer is the next pointer to run 24 12

13 Dequeue operation Start Find entry against TID from thread data BRAM PRI=t_entry.priority P_entry=Priority_data[PRI] TRUE If(P_entry.head ==P_entry.tail) FALSE Set Queue to Empty Update Queue Head pointer END 25 Scheduler: Data Flow Diagram 26 13

14 Technology Diagram 27 Synthesis Report Device utilization summary: Selected Device : 2vp30ff896-7 Maximum Frequency: MHz Number of Slices: 908 out of % Number of 4 input LUTs: : 1673 out of % Number used as logic: 1672 Number used as Shift registers: 1 Number of BRAMs: : 2 out of 136 1% Number of GCLKs: : 1 out of 16 6% 28 14

15 Performance Analysis Does not perform any sort of Priority sorting or search through R2R Queue Hence eliminates the jitter introduced in software schedulers 1 8 # Of Tasks Time Taken in Scheduling Decision 13 CC summary A RTOS scheduler is designed in hardware and is implemented on Xilinx Microbalze Processor as an Accelerator Performance results show that the hardware based scheduler performs the scheduling decision in const. time irrespective of no. of tasks in the R2R queue

16 Future work To tailor the Soft RTOS (i.e. µc/os-ii) To define an interface Between Scheduler IP and the soft RTOS, so that in could be used in Real time applications 31 THANK YOU 32 16