The Problem

The simulation of an ARM 7 based Bluetooth enabled handheld device is modelled entirely in Cadences Virtual Component Co-design. The device will consist of an 8bpp palletised touch sensitive 240*320 screen. The Stratego2go project intends to implement a multiplayer game (namely Stratego) for this imaginary device. Input to the game consists of mouse events and output a series of screen buffers.

VCC doesn't run in real-time, instead it simulates and analyses a systems behaviour on various platforms. The mismatch between real and simulated time will need special consideration.

There is no means of implementing true hardware devices such as buttons, screens, speakers etc. in VCC. These essentially mechanical devices will therefore be simulated outside of VCC i.e. as a Windows application. In order to accomplish this some form of inter-process communication is necessary. I doubt that communication between the VCC simulation and a 3rd party thread was ever intended.

As embedded devices become more sophisticated, it will become necessary for Cadence to reconsider the I/O problem.

Requirements Overview

The client application is required to send mouse events to the VCC model and render the contents of the screen buffer to screen. Therefore, we have: -

• Real time mouse events must injected into the VCC model
• The contents of the simulated Screen Buffer must be extracted from VCC and converted to a form that Windows can display
  

The first problem is one of inter-process communication. Windows offers a few mechanisms for this, the most appropriate of these being pipes. See msdn.microsoft.com for information about Win32 pipes.
Once a communication channel exists between the simulation process and the client applications process, mouse messages can be sent to VCC and screen buffers received.

The co-ordinates of mouse events will have to be converted so they are relative to the virtual screen of the device. The co-ordinate system was defined by Andrew as having the origin at the bottom left of the screen (bottom-up). Windows co-ordinate system is top-down.

The contents of the screen buffer was defined in collaboration with Alex as a 256 entry array of triple byte RGB structures followed by a 76800 (240*320) entry byte array of indexes into the palette. Windows 8bpp Device Independent Bitmaps consist of up to 256 palette entry of RGBA quad byte structures followed by indexes into the palette.

The only problem remaining is one of synchronisation, VCC runs in simulation time and the client in real time. If the VCC simulation runs too slowly mouse event could be lost or the user simply confused by the lag between action and reaction (the change on screen), causing them to issue more mouse events swamping the simulation.
The solution is to queue mouse events (limiting the queue size). There should be no such problem with screen buffers as these are simply pushed from VCC as the simulation dictates. It is unlikely that VCC will be able to generate enough screen buffers to overwhelm the application.

next