Tallinna Tehnikaülikool

Arvutitehnika Instituut

Laboratoorne töö 4.

HW/SW solution space case study

aines IAY0070Riist- ja tarkvara koosdisain

Õppejõud: prof. K. Tammemäe

Üliõpilane: Maksim Gorev(020281)

Vadim Pesonen(020613)

Tallinn

2009

Lab 4. HW/SW solution space case study

  • Find a complex task, requiring intensive data processing capabilities
  • Write a specification
  • Generate 3 solutions with different HW/SW rate
  • Synthesize and run - compare solutions in terms of complexity, flexibility and speed or throughput) factors
  • Write a report

Implementation components

In order to create different designs with different hardware and software rate it was needed to develop some components both in hardware and software implementations. Components created are the following:

  • SW game controller
  • HW game controller
  • SW keyboard controller
  • HW keyboard controller
  • VGA controller

VGA controller wasn't implemented in software because we didn't find any way to use limited PicoBlaze resources to be able to manage fast VGA control tasks.

The HW keyboard controller

The keyboard controller supports the standard PS/2 interface and utilized a uni-directional data transmission only – from the keyboard to the host device. At the moment of writing the controller does not support extended key codes.

When any key is pressed, the keyboard sends in the 3 packets of data of 11 bits each. The fist packet represents the pressed key. Then, when key is released, the keyboard send the special brake code, and then repeats the pressed key code. The designed keyboard controller reacts to the last packet i.e. to when the key is released rather than pressed.

The incoming data from keyboard is pushed into a 33-bit shift register, and, as mentioned above, the last packet is analysed.

The keyboard controller supports 5 keys – W (UP), D (right), A (left), S (down) and R (reset). To simplify the game logic the controller sends not the code of the key, but a shift on the game map. For example, moving up means decreasing the current map RAM address by 10, the controller will generate a value minus ten. This value will then be registered. After the value has been registered, the controller will generate a short pulse to signal keyboard activity.

The HW game controller.

The game controller is comprised of an FSM with 22 states. Each state denotes an action and the next state. State transition is synchronous. The game controller was tested to work at 10MHz, but working at higher frequencies may possible prove to be stable.

The game FSM is a sequence of steps needed to carry out the game logic. The steps consist of memory reads, necessary to make decisions, and memory writes i.e. modifying the map RAM.

Memory can be read and the fetched data can be analysed within the same state to make a decision on the next state. This is due to the fact, that the memory and the game logic are clocked with inverted a phase-inverted signal.

The current position of the main figure (man) on the map is registered every clock cycle. Upon keyboard activity the keyboard controller first registers the shift value, and in a short time signals a hit key with an interrupt. The delay with which the interrupt arrives is enough to calculate the man’s “next” and “after next” positions, so by the time the FSM is transitioned into the interrupt response state, all the required information regarding the man’s movement is already gathered. This is a very useful feature which simplifies the FSM and reduces the number of states.

In each state the logic can read from map RAM, write to map RAM, make decisions on the next state and set the current man’s position. The 22 FSM states are described below:

  1. INI: this is the initial state, it is required to prepare the map address i.e. to set it zero. Next state is always 1.
  2. FIND: the game begins with finding the man’s current location. The map RAM is read and the state is repeated until the data from the memory is equal to the man’s code. As soon as the man is found the FSM goes to the HALT state, where it does nothing and from where it can be transitioned only with an interrupt.
  3. KEY: when in HALT state and an interrupt occurs, the FSM is automatically forced to this state. This is the interrupt response state. By this time the man’s position is already calculated, and since the data from arrives in the same clock cycle, the next state decision is made in this state. The decision is made according to the data from map RAM. The man’s next position can contain one the following: be EMPTY, contain a DIAMAND, a CIRCLE, a DIAMAND_ON_A_CIRCLE or a WALL. The next state is selected accordingly.
  4. WALL: the FSM is transitioned here if the next position is a wall. Nothing is performed in this state, but the next state is always a HALT.
  5. EMPTY: the FSM is transitioned here if the next position is an empty space. In this state the map is modified to place the man in the next position. During this state the man appears twice on the map, but since the FSM is next transitioned into the CLEAR_CELL state, the eye does not notice it.
  6. CIRCLE: this is identical the previous state, except for that the man appears not on an empty space, but on a circle. The next state is CLEAR_CELL.
  7. DIAMAND: if the next position contains a diamond, the FSM has to look in one position further to decide where the diamond can be moved or not. For this the “after next” position is queried and one of three outcomes is possible – the “after next” position is empty, it contains a circle, or anything else. In the latter case the diamond cannot be moved. The next state is selected accordingly to the data from memory.
  8. DIAMAND_0: the FSM is transitioned here if the position after the diamond is an empty space. A diamond is placed instead of empty space and the next state is DIAMAND_2.
  9. DIAMAND_1: the FSM is transitioned here if the position after the diamond is a circle. A diamond on a circle is placed instead of empty space and the next state is DIAMAND_2.
  10. DIAMAND_2: a man is placed instead of a diamond in this state. The next state is CLEAR_CELL
  11. DIAMAND_CIRCLE: the FSM is transitioned here if the position after the diamond is a circle. This and the following 3 states are identical to the previous 4 states, except for that a figure on diamond is placed instead of just a figure.
  12. DIAMAND_CIRCLE_0
  13. DIAMAND_CIRCLE_1
  14. DIAMAND_CIRCLE_2
  15. CLEAR_CELL: the FSM is transitioned here after any movement of the man figure. Here, the FSM decides where the man’s old position should be replaced with an empty space of with a circle. The next state is selected accordingly to the data from map RAM
  16. WR_EMPTY: the FSM is transitioned here if the man’s old position must be an empty space. The corresponding value is written to memory and the FSM goes to the HALT state.
  17. WR_CIRLCE: the FSM is transitioned here if the man’s old position must be a circle. The corresponding value is written to memory and the FSM goes to the HALT state.
  18. HALT: the FSM remains in this state until an interrupt will force it out to to the KEY state
  19. RESET_INI: the FSM moves to this state if the R (reset) key has been hit. The FSM is preparing to copy the map from the reserve memory location. The next state is RESET_WR
  20. RESET_RD: the FSM is reading the reserve memory and buffering the result
  21. RESET_WR: the FSM is actually restoring the map from the buffer. The next state is RESET_AA.
  22. RESET_AA: the reset-adjust-address state. The map memory address is corrected for the next read. The next state is either RESET_RD, or INI, if the map has been fully restored

The described FSM fully implements the game logic and provides a restart function.

SW Keyboard controller.

In order to play the game – the keyboard is used. There are 6 buttons wich can be used during this game. Their functions are the following:

  • left arrow – move man left
  • right arrow – move man right
  • up arrow – move man up
  • down arrow – move man down
  • backspace – undo the last step

  • Escape – restart the game

Keyboard is using two lines to send data. These are DATA line and CLOCK line. It doesn't require initialization, so it is only needed to read from DATA line on appropriate CLOCK signal. The clock signal was connected to PicoBlaze'i interrupt input with invertor. So that every time the clock line contains „0“ value, interrupt is generated. It gives software a possibility to read every bit of the button code bitstream and decode the message from the keyboard.

Keyboard button code is represented by 8 bit binary value. In case of extended keys the value of the code is 16 bit and the highest 8 bit contains extended button code E0. When key pressed keyboard sends one time the code of the button. In case of extended button it sends code with E0 before button code. When key is depressed the keyboard sends button code again, but this time it puts code F0 before the button code. So if extended key was depressed the 24 bit bitstream will be sent from the keyborad: F0 E0 XX(button code) .

The keys used in game have the following codes:

  • UP - E0 75
  • DOWN – E0 72
  • LEFT – E0 6B
  • RIGHT – E0 74
  • ESC – 76
  • BACKSPACE – 66

The workflow of keyboard controller is shown on the Figure 1. Bits are read sequentially until byte is read. Program understands it from the bitcounter value. Byte value is decoded and depend on the value of this byte the E0 or F0 status are set or cleared in the status register, the specific button function is called or the code is rejected and other bits of the message are rejected as well.

In other words, the program read the first byte of the message.

  • If it is E0 it sets the corresponding flag and reads the second byte. If E0 and second byte represent the code wich is neede byte the game, procidure to inform the game of this code is started.
  • If the first byte is not E0, but the code of Esc or Backspace, the inform procedure is started as well.
  • If the first byte is F0, then second byte is rejected, and if the second byte was E0, then the third byte of the message is read by the program, but is rejected.
  • If none of above then message is rejected.

The procedure wich informs game of the key pressed simply writes the specific code from 0 to 5 into register, where game reads from during main loop.

The SW game controller

The main algorithm of the game is displayed on figure 2.


At the very beginning of the game the program copy map from upper block RAM (addresses 100 – 199) to lower blockRam(addresses 0 to 99). This is needed to give a possibility to a program to reset the map in the future and doesn't store it somewhere else.

When map is copied man position and circle positiona are searched through the map and saved inside the processor. Man coordinate saved into specific register and circle coordinates are saved into internal RAM of PicoBlaze processor. Circle coordinates are needed for program to detect the „end of game“ condition, when all rubins are on circles. After that program goes to main loop where it reades keyboard code register until it is not zero.

When interrupt occurs and keyboard controller writes a code into coderegister and exits ISR , the main program reads the code and writes zero into keyboard register instead. If this code was direction code it calculates sequantially 3 coordinates next to man coordinate, depending on the direction. Program reads current picture codes on this coordinates from external memory. After that it stores all of them in internal memory. This is done to provide the ability to undo last step of the game later.When this is done them man is „moved“ or not, dependidng what is located in the coordinates next to the man. When movements are done, all circle coordinates are read from the internal memory and after that external memory checked for “rubin on circle“ block on this coordinates to detect the „end of game condition“. If condition is not detected program goes to the main loop. If condition is detected – all circle coordinates have block type „rubin on cirle“ the program flashes rubins on circles 3 times and restarts the game, jumping to the very beginning.

When backspace code is detected the internal memory is read for 3 last coordinates and block types. After that external memory is rewritten with these old values and internal registers with man position and block type is rewritten as well.

When esc code is detected the program jumps to the very beginning of the code and starts from scratch rewriting game map from upper blockRam addresses.

To write the program pBlazIDE36 software were used to enter code, test and compile a code into VHDL instruction ROM.

Diffrent implementations analysis.

We divided our game system into 3 general part and defined percentage ratio to them dependidng on thier size and importance. These are the following:

  • Keyboard controller – 25%
  • VGA controller – 25%
  • Game controller – 50 %

The hardware/software ratio 100% / 0%

In this implementation the whole system is pure hardware. The VGA engine is the same, the keyboard controller is hardware, and so is the game logic.

The hardware/software ratio 50% / 50%

In this impelementation VGA engine and keyboard controller are both made in hardware, but game controller is the program running on PicoBlaze processor.

The hardware/software ratio 75% / 25%

Here we have VGA engine and game controller made in hardware, and keyboard controller is the program running on PicoBlaze processor.

Time consumed on different implementations

Time cunsumtion on different module developments are approximately stated in table below:

Module / Time(hours, approximately)
SW game controller / 16
HW game controller / 8
SW keyboard controller / 3
HW keyboard controller / 1
VGA controller / 32

This time includes specification, development and test stages of these modules. The implementations development times are then the following:

  • HW/SW 100/0 total time is 41 hours
  • HW/SW 50/50 total time is 49 hours
  • HW/SW 75/25 total time is 43 hours

Software longer development times are explained by little PicoBlaze programming experience and longer specification phase. VGA controller time consumtion is explained by usage of complex picture graphics extracted from *.bmp files of original game for PC and long test and debug period. Results show, that hardware implementation is less time consuming. It could be because of bigger experience in hardware programming and use of hardware advatages, such as parallel process ing. We can suppose, that in case of much bigger project these time characteristics will change to advantage of software implementation.

FPGA area consumtion of different implementations

We decided to measure area consumption in number of SLICEs cunsumed by design. These numers are the following:

  • HW/SW 100/0 total slices are 277
  • HW/SW 50/50 total slices are 260
  • HW/SW 75/25 total slices are 359

As we can see the area consumtion is almost completely opposite to the time spent on development. These numbers show us as well, that game controller implemetation in software is slightly less area consuming, than one made in hardware. By the way, the hardware game controller area will only increase, with increasing of system functionality, but Picoblaze has constant size. The size of the last implementation is absolutely predictable, because in addition to area consuming hardware game controller the PicoBlaze processor is synthesized as well.

Design speed of different implementations

We measured design speed in maximum frequency, wich ISE sythesize tool provided at the end of synthesis process. These are the following:

  • HW/SW 100/0 Maximum Frequency: 44.595MHz
  • HW/SW 50/50 Maximum Frequency: 37.767MHz
  • HW/SW 75/25 Maximum Frequency: 50.490MHz

Numbers show us, that software keyboard controller performs faster, than one made in hardware. However game controller part is oppositely faster in hardware implementation.

Power consumtion of different implementations

Power consumtion have been computed using ISE utility XPower Analyser. Results are the following:

Design / Total quiescent (static) power, Watt / Total dynamic power, Watt / Total power consumtion, Watt
HW/SW 100/0 / 0.09853 / 0.00226 / 0.10079
HW/SW 50/50 / 0.09854 / 0.00275 / 0.10129
HW/SW 75/25 / 0.09853 / 0.00234 / 0.10087

We can see, that static power is always the same for all implementations and tha only parameter which is changing is dynamic power charateristics. Hardware is less power hungry than both implementations using software. It can be explaind by sequantial nature of program execution inside of Picoblaze processor. Therefore it takes more transistor switching times to get the results for software, than for hardware, using parallel data processing.

Summary

Results of the lab shows us, that this task development is better to carry out completely in hardware. However it should be taken to consideration, that little experience in Picoblaze programming, small size of the project and bugger experience in hardware are key components of full hardware implementation success. There is no doubt, that increasing of project complexity and size – co-design will be preferable. We can also see, that in some cases hardware implementation is not as fast as co-design version. So that dependently on system constraints it is neede to take co-design implementations in account. In personal oninion it is much better to write a software in some cases, because there are better tools for development and testing process, and it consumes less time, to test and search for an error in the code.