The output of a task module is simply that task's priority, or bid for control of the CPU and associated resources. The information from the module is sent to the task control manager through a priority mediator, which identifies a task by the position of the connection containing the priority value (Fig. 4).
The task control manager has two main blocks—the priority mediator and a task controller. The mediator has access to each task's bid, which can be zero, as determined by an Active flag. The mediator also implements a scheme that performs pairwise comparisons in the form of a binary tree. A zero bit doesn't necessarily mean the task's priority is zero, but merely that the task is prevented from bidding due to other conditions, or simply that it's not yet activated.
The wining task's identification and priority (nonzero bid) are presented to the task controller, which keeps track of the executing task, the standby task, and the task winning the bid. With this information, the manager decides which task to run next, and whether or not it's a new task, or to enter an idle state if no tasks are to run next. This way, the controller can require that the standby register be loaded with the next task's state from the Task RAM, then demand a register switch.
These decisions are made in accordance with the relative priority levels among the three tasks of interest. All tasks are referenced by pointers to a block in the Task RAM, so carrying out any of these decisions is a straightforward control action.
Together, the task controller and priority mediator manage the bidding process. A running task is blocked from bidding if tasks of the same priority are requesting, but not if it's the only task of that priority. All tasks of priority lower than that of the running task participate in the bidding, ensuring possible access for all active tasks. If a resource like cache memory or a math unit isn't available to an executing task, that task is put to sleep. No CPU cycles are wasted on wait states, unless it's the only task.
When the resource becomes available and the task priority allows it, the task can run. Other aspects of the task manager handle semaphores in addition to priority levels, providing more software-transparent control over task activity.
The development board includes the Virtex II FPGA and the Xyronium processor IP. On-board are NTSC video inputs and outputs and a programmable XVGA output. For audio, the board also includes a 44-kHz, 16-bit stereo codec.
Software for application execution on the Xyronium processor will run just as it would on a standard MIPS processor. But the RTOS task management and interrupt functions should be redirected to the ZOTS hardware technology. This requires simple recompilation to target functions that were once included in the software RTOS, not a complete code rewrite as one might expect.
One way to ease into the ZOTS technology is to start with the existing code running as one task. If desired, multiple copies of an entire application or operation system can be run as separate tasks. The ZOTS-enabled processors will initially work with the GCC C and C++ compiler suite. Future software releases will include embedded Linux and commercial RTOS porting libraries for standard RTOS solutions.
Price & Availability
The Xyronium processor synthesizable core can be licensed for $5000 plus an additional prepaid royalty for a single-instance use in an FPGA. Licenses for the full-IP disclosure for use in a processor are negotiable. The development board sells for $1495. All options are immediately available.
Xyron Semiconductor Inc., 203 S.E. Park Plaza Drive, Suite 210, Vancouver, WA 98684; (360) 449-8822; www.xyronsemi.com.
The output of a task module is simply that task's priority, or bid for control of the CPU and associated resources. The information from the module is sent to the task control manager through a priority mediator, which identifies a task by the position of the connection containing the priority value (Fig. 4).
The task control manager has two main blocks—the priority mediator and a task controller. The mediator has access to each task's bid, which can be zero, as determined by an Active flag. The mediator also implements a scheme that performs pairwise comparisons in the form of a binary tree. A zero bit doesn't necessarily mean the task's priority is zero, but merely that the task is prevented from bidding due to other conditions, or simply that it's not yet activated.
The wining task's identification and priority (nonzero bid) are presented to the task controller, which keeps track of the executing task, the standby task, and the task winning the bid. With this information, the manager decides which task to run next, and whether or not it's a new task, or to enter an idle state if no tasks are to run next. This way, the controller can require that the standby register be loaded with the next task's state from the Task RAM, then demand a register switch.
These decisions are made in accordance with the relative priority levels among the three tasks of interest. All tasks are referenced by pointers to a block in the Task RAM, so carrying out any of these decisions is a straightforward control action.
Together, the task controller and priority mediator manage the bidding process. A running task is blocked from bidding if tasks of the same priority are requesting, but not if it's the only task of that priority. All tasks of priority lower than that of the running task participate in the bidding, ensuring possible access for all active tasks. If a resource like cache memory or a math unit isn't available to an executing task, that task is put to sleep. No CPU cycles are wasted on wait states, unless it's the only task.
When the resource becomes available and the task priority allows it, the task can run. Other aspects of the task manager handle semaphores in addition to priority levels, providing more software-transparent control over task activity.
The development board includes the Virtex II FPGA and the Xyronium processor IP. On-board are NTSC video inputs and outputs and a programmable XVGA output. For audio, the board also includes a 44-kHz, 16-bit stereo codec.
Software for application execution on the Xyronium processor will run just as it would on a standard MIPS processor. But the RTOS task management and interrupt functions should be redirected to the ZOTS hardware technology. This requires simple recompilation to target functions that were once included in the software RTOS, not a complete code rewrite as one might expect.
One way to ease into the ZOTS technology is to start with the existing code running as one task. If desired, multiple copies of an entire application or operation system can be run as separate tasks. The ZOTS-enabled processors will initially work with the GCC C and C++ compiler suite. Future software releases will include embedded Linux and commercial RTOS porting libraries for standard RTOS solutions.
Price & Availability
The Xyronium processor synthesizable core can be licensed for $5000 plus an additional prepaid royalty for a single-instance use in an FPGA. Licenses for the full-IP disclosure for use in a processor are negotiable. The development board sells for $1495. All options are immediately available.
Xyron Semiconductor Inc., 203 S.E. Park Plaza Drive, Suite 210, Vancouver, WA 98684; (360) 449-8822; www.xyronsemi.com.