Read value from peripheral register - Microblaze simulation

5.4 Microblaze simulation

5.4.3 Read value from peripheral register

This section was the last to be tested as it requires both the interrupt mechanism and the read and write methods for the cf card to function correctly in addition to adding functions to write data to a peripheral register and to read data from the register. A hexadecimal value of A2 (162 in decimal value) is written to register 3 in the peripheral unit before the init() function sets up the interrupts. The isr is altered so that it reads the value of register 3 from the peripheral unit and stores it in a variable before writing it to the predetermined le on the cf card. Having the le contain the same value as the one written to the card will be evidence that interaction with the peripheral is working.

Figure 5.19 shows the le produced by the isr and stored on the card. The output le contains values that are coded in ascii so that it will not show A216 or 16210 but rather

the ascii symbol with the decimal value of 162. The resulting le produced by the isr, in gure 5.19, shows the ascii symbol of the values it read from the register. Using the ascii table at [3] reveals that the symbol written is at the 162nd position and thus conrming that reading from the register and writing to the register works correctly.

Chapter 6 Synthesis

6.1 VHDL Synthesis

The vhdl les that do the processing part of this project cannot be synthesized in the vhdl hierarchy they are built as the Xilinx ise synthetization tool eventually runs out of memory without giving any error message. In accordance with the supervisor at the university, the vhdl les will not be synthesized as part of this project. The vhdl les created by the wizard for the custom ip will, however, be synthesized as part of running synthesis on microblaze. The area report will thus only be for the vhdl les created by the wizard.

6.2 Microblaze Syntethization

The embedded system created in platform studio are synthesized by the "generate netlist" command and the synthesis report is stored in the report folder in the project directory. The synthesis report for the design can be found in section .3. The maximum delay through the system is 6.18 ns which gives a clock frequency of the system of 161.34 MHz. The clock frequency and variable related to the clock are found in gure 6.2.

Figure 6.1: Synthesis delay

Figure 6.1 shows a part from the synthesis report regarding the resources utilized for the system. The design utilizes 9% of the available registers and 10% of the available LUTs. These numbers shows that the design only utilizes a small amount of resources on

the chip as can be expected for a such a small system. Many systems of this kind will have area limitations so that utilizing a small percentage of the resources is always great news. The I/O utilization is at 7% and with 66% of ram/fo utilized. The reason for having such a large percentage of ram/fo utilization is a combination of the requirement of storing values within the peripheral that can be read by the cpu, in addition to only having 64 kb of memory to begin with.

Chapter 7 Tools

This project has required a handful of tools in order to deal with the dierent aspects of the design from converting an image in software to adding peripheral, to the cpu to synthesizing the complete design. The computer used in this project has a 32 bit Windows Vista Home Basic operating system with Service pack 2, dual processor where each processor has a frequency of 2.26GHz, and the computer has 3.0 GB ram. Matlab was the tool used to convert an image from a le to an array in the vhdl package le and to convert values from the simulation to an image. The hardware programming and simulation were done in Active HDL software, and when the simulation showed correct behavior it was synthesized in ISE project navigator, which is part of the Xilinx web pack. The creation of the embedded design took place in platform studio which also did the synthezation of the embedded design. The design could then be implemented to the fpga with the Impact tool which is a part of the webpack from Xilinx. The various software and version number type can be seen from table 7.1.

Development board Xilinx ML501

Platform studio Xilinx Platform Studio 11.5, Copyright (c) 1995-2009 Xilinx, Inc Platform studio Xilinx Platform Studio 12.1, Copyright (c) 1995-2009 Xilinx, Inc Impact ISE impact4 version 11.5, copyright (c) 1995-2009, Inc

Chapter 8 Discussion

The discussion of the results from the hardware and software part of this project are given separately in order to put the results into context.

8.1 Vhdl

The vhdl le median.vhd is the only le that will synthesize in the project navigator tool because it is at the lowest level in the vhdl hierarchy. The other vhdl les cannot be synthesized so the simulation of the les in conjunction with the textIO package and Matlab scripts will serve as the bases for determining this design's ability to operate in a real time system. It is clearly not desirable not to be able to synthesize the vhdl les as it introduces uncertainties as to whether the system will have the same behavior in hardware as it exhibited in the simulation in software. It also introduces no evidence as to the physical size of the vhdl les that will inevitably require a higher utilization of resources as the majority of all the processing is done there. The only area values that are given is the area of the two vhdl wrapper les created by the import custom ip wizard in order to set up communication between the custom ip and the plb bus. It is also assumed that adding the other vhdl les will introduce a longer delay path in the design, which will lead to a lower clock frequency.

8.2 Microblaze

The embedded system was created and synthesized in the platform studio. The design shows that it has a high clock frequency and a low resource utilization except for ram usage. This can be explained by the fact that the system really does very little processing. The other peripherals show higher clock frequencies than the processor so the cpu is the weakest link when calculating the maximum clock frequency. The code written to interact with the cf card, set up interrupts and reading from a register and writing to a register are shown to work as desired. Testing the system by writing values to a le on a cf card would prove to be a better way of testing the system if the output data were written in

decimal number as opposed to ascii code as the data could be written into matlab with a simple script.

8.3 Simulation

The graphs based on the data from the simulations data shows that a high peak signal to noise ratio leads to a low mean square error and mean absolute error. This is also obvious from looking at equations (3.4), (3.3), (3.5) that optimizing for one of the variables will result in an optimization for all the variables.Simulating the images with dierent thresholds introduced the concept of being able to optimize an image in order to achieve higher peak signal to noise ratio and lower mean square error and mean absolute error on an image-by-image basis. As an illustration, the peak signal to noise ratio for 0.02 noise level with the threshold at 10 is 34.59dB. The simulation of the dierent thresholds revealed that the optimum threshold for the highest peak signal to noise ratio was 20−30. The peak signal to noise ratio for the threshold of 26 with 0.02 nose level is 36.04dB. Those numbers show that there is something to gain by optimizing the threshold, but that is at the expense of higher simulation times as the optimum threshold level has to be determined based on simulations on dierent threshold levels. The simulation for correcting the defective pixels can only be run after the threshold level has been found. Having the threshold value at 10 seems to be a good general purpose value as the peak signal to noise ratio is close to the peak signal to noise ratio at the optimized threshold level.

In document Defective Pixel Correction (Page 73-79)