Menu

State_Machine

Shane Saxon

[Home] - [Architecture] - [Control]


Rough Draft:

ANTz is implemented on the desktop as a pseudo state machine. Artificial neural pathways based on [IO_Channels] operate as routing for streaming state data and commands using [NPE] feedback concepts.

Minimize Latency - stream control commands and data directly between buffers and IO channels. allow direct access to buffers and do not make any un-needed copies of buffers. Keep state change logic to a minimum. Swamp the hardware, do everything the state requires every cycle, regardless of changes in the state. This reduces temporal jitter and system hiccups. Don't use compression as this takes time to process and wastes both time and processing power. An acceptable compromise is the JPEG2000(J2K) ultra-low-latency approach by companies such as intoPIX J2K FPGA core, which has sub-frame end-to-end latency... This is possible because it is NOT an MPEG like multi-frame compression algorithm... instead it is a sub-frame based wavelet based compression (http://en.wikipedia.org/wiki/Wavelet_transform). This allows for serial data coming in from a sources such as SDI(link) to begin compressing block when only a segment of the image is captured. These blocks are then shipped over a network (UDP is good) and start being decompressed and output via SDI before the entire frame is even input at the capture side... hence sub-frame latency in an end-to-end video stream over a traditional IP network.... see intoPIX for more detail.

Maximize Bandwidth - rather then take a IP shared approach to bandwidth... use an ATM or UDP approach... think in terms of guaranteed latency and bandwidth. It helps on IP networks to keep the pipe fully saturated. Favor uncompressed data, when extremely impracticable use Fixed Bit Rate(FBR) encoding and avoid Variable Bit Rate(VBR) such as used by MPEG. In general avoid all multi-frame encoding methods and favor frame based... unfortunately frame based methods are few; lossless Run Length Encoding (RLE) is fast (light on processing) and ultra-low-latency (if done right), wavelet based (such as J2K) gives much higher compression but generally require expensive dedicated hardware (FPGA core), however there are some hardware based J2K algorithms in development that use the much cheaper GPU... The 3rd category is Fractal Algorithms, encoding is extremely processor intensive(realtime requires non-existent hardware,) decoding is also fairly intensive. Note that the patents for fractal encoding are collecting dust on the shelf due to the hardware problem... A possible solution is to use ANN processors by TeraNex.com this would require a multi-million dollar effort... but is worth it, remember those DOS 1.4MB floppies with minutes of video... fractal compression is not only frame based, but is capable of 10,000 to 1 (lossy) compression!!

Maximize Processing Power - keep equations and methods simple, avoid any type of compression. Uncompressed equals more processing available for tasks.

pseudo state machine - not a realtime OS or better yet an instruction locked embedded system. However a common desktop OS can be used as a psuedo state machine in an realtime OS like way.


Related

Wiki: Architecture
Wiki: Ctrl
Wiki: Home
Wiki: IO_Channels
Wiki: NPE
Wiki: Performance
Wiki: Technical_Architecture