From SeedWiki

Revision as of 01:53, 12 December 2009 (view source) Hayden Gomes (Talk | contribs) (→Diary) ← Older edit		Latest revision as of 20:59, 14 January 2010 (view source) Hayden Gomes (Talk | contribs) (→Diary)
Line 83:		Line 83:
	=Diary=		=Diary=
		+
		+	====Scaling Window====
		+	I have finished making the subwindow scaling submodule and now am in the process of adjusting the test code to determine if it is functioning properly.
		+
		+	--[[User:Hayden Gomes|Hayden Gomes]] 20:59, 14 January 2010 (UTC)
	====One to One Scaling====		====One to One Scaling====

---

Latest revision as of 20:59, 14 January 2010

Contents 1 Tracker 1.1 Schematic 2 VGA Subwindow with downscaling resolution 2.1 Schematic 2.1.1 One To One 2.2 Requirements 2.3 Scaling Factors 2.4 Memory Usage 3 Project Repository 3.1 Getting files 3.2 Pushing back changes 3.3 Pulling changes 4 Diary 4.1 Scaling Window 4.2 One to One Scaling 4.3 BRAM conflict management 4.4 Transferring a sub-window to WS 4.5 Memory usage 4.6 Possible technique for averaging resolution

Tracker

Schematic

High Level	Xilinx synthesis

• source in ODG

VGA Subwindow with downscaling resolution

Schematic

This is a rough schematic of the Subwindow module. VGA, X, Y, and VGA_CLK will all be arriving asynchronously to the main clock and must therefore be passed through a synchronizer constructed from two back-to-back flip-flops triggering on the rising edge of the fast clock. The subwindow logic block will likely be broken into two parts: one for the special case of no scaling between input and output window pixels and one for windowing with scaling. The output window will be stored in BRAM so that the next module in the tracking process can load the entire window.

One To One

This is a schematic of the first version of the subwindow module which only implements one to one scaling. All signals based on the VGA_clk will pass through synchronizers. The BRAM Access Controller submodule determines where in the frame the current pixel is and controls the enables for reading parameters and writing pixels accordingly. The Load Window Parameters module will be enabled at the end of a frame. It will read the first entry in BRAM to determine the next frame's subwindow dimensions and location. In Window uses the current pixel's X and Y coordinates to determine if the pixel is within the subwindow. It triggers the One to One submodule which, when enabled, will write the VGA pixel value to the corresponding address in BRAM.

Requirements

• Implement in hardware a module that will sample a windowed area of VGA input and return at desired resolution averaging pixels.
• Line inputs: VGA, X, Y, VGA_CLK
• Inputs through BRAM: window_X, window_Y, scale_dimension*
• Outputs through BRAM: window of summed pixels
• Module Configuration parameters: output_height, output_width, N_buffer

* The scale_dimension will be the same for both horizontal and vertical scaling of the input to output window

Scaling Factors

The Subwindow will need to be able to handle the following scaling factors:

• 1x1 (Special case)
• 2x2 (Most time critical case)
• 3x3
• 4x4

Note: all scales are assumed to map down to a 1x1 pixel in the output

Memory Usage

We have decided to limit the size of a particle window to 20x20 pixels. This means that the tracking region containing all of the particles need not be larger than 40x40 pixels as all particles should overlap. Therefore we need to be able to store 40*40*3 color summations in BRAM, or 4800 summed color values. Because the greatest scaling factor is 4x4, this means that up to 16 colors will be summed to produce the output color value. The maximum size of this sum will therefore be 12 bits. Given the 12 bits per color and 4800 summed color values to be stored in BRAM, the BRAM will need to be at least 57.6 kbits. Each pixel will be represented by 36 bits which is the default maximum read/write size for BRAM (wider BRAM and LUTs can be made if needed).

57.6 kbits of BRAM, 36 bits read/write

Project Repository

We will mainly use Biospike for our work.

Getting files

• ssh into biospike.ucsd.edu
• under your home directory, do this

hg clone /data/fpga/vga_subwindow

hg clone /data/fpga/tracker

Pushing back changes

• once you're done, you need to "hg commit" and "hg push"

Pulling changes

• under your working copy, you use "hg pull" to pull the changes and "hg update"/"hg merge" to actually integrate changes into your code.

Diary

Scaling Window

I have finished making the subwindow scaling submodule and now am in the process of adjusting the test code to determine if it is functioning properly.

--Hayden Gomes 20:59, 14 January 2010 (UTC)

One to One Scaling

I have confirmed the subwindow one to one scaling is working using a test module. Next week I'll try to wrap this module up by implementing scaling and retesting it.

--Hayden Gomes 01:53, 12 December 2009 (UTC)

The subwindow module has been reworked to use a MUX instead of Z values. I have cleaned up the warning and am now working on a test module.

--Hayden Gomes 23:27, 30 November 2009 (UTC)

The subwindow module for one to one scaling is complete and ready for testing. There may have been some issues pushing it out to the mercurial repository which I will work out with Sunsern as soon as possible.

--Hayden Gomes 22:45, 23 November 2009 (UTC)

BRAM conflict management

For this module I've generated a dual port BRAM so that the module itself can utilize port A for reading and writing to the BRAM block and an outside module can use port B to read/write to the same BRAM. One issue is managing the uses of port A so as to avoid conflict. The main uses of this port will be:

• Read window parameters (window_x,window_y,scale_dimension)
• Interact with window data
  • Read stored sum
  • Write new sum
  • Reset sum value

While the timing of these various events will likely be such that there shouldn't be conflict, I will probably be implementing some sort of BRAM interaction manager submodule to avoid conflicts between BRAM interactions. The window parameters are read after the first VGA_CLK cycle of a new frame. This call should take priority to the windowing read/write calls as the last frame's window should already be stored and the new window has yet to be determined.

--Hayden Gomes 23:40, 9 November 2009 (UTC)

Transferring a sub-window to WS

The new approach of making one subwindow for a tracking point and then working with particles within that window will help eliminate this issue and then it's just a question of how many points do we want to be tracking? Given our current configuration of 57.6kbits per color, we should nave no problems sending each window at 60fps.

--Hayden Gomes 21:20, 9 November 2009 (UTC)

But if we need to do 50 sub-windows per point being tracked then this isn't fast enough right? Or do you plan to only send the "best fit" sub-window for the tracked image?

--Hayden Gomes 20:30, 26 October 2009 (UTC)

If we assume 2.32 MB/s throughput from Evan's experiment, we can transfer a sub-window of size up to 113 x 113 @ 60fps from BRAM to WS. If this is true, we should be able to display the sub-window on WS in real-time.

--SunsernCheamanunkul 09:00, 22 October 2009 (UTC)

Memory usage

Let's assume the following:

• maximum output sub-window size = 128 x 128
• maximum scaling ratio is 16 (i.e. if the size of output window is 10x10, the size of input window is at most 160x160)

We need to keep 2 things in memory:

• Sum of pixel values: we only need to keep only 1 row of output window, which has at most 128 entries. For each entry in the row, we need at most 3*log(16*16*256) = 3*16 = 48 bits. So we need total of 128*48 = 6 Kbits.
• Counter for each entry in the row: This basically tells us how many pixels in the input window are mapped onto an output pixel. These counters require at most 128*log(16*16) = 1 Kbits.

--Yoavfreund 13:43, 22 October 2009 (UTC)

If you use only integers as the size ratio between the input and the output then this number is a constant that you can pre-compute, you don't need to maintain counters. Only one counter is needed for counting the pixels rows and deciding when to generate an output row and zero the memory (or registers) use to compute the sums.

Total memory required = 7 Kbits

--SunsernCheamanunkul 08:40, 22 October 2009 (UTC)

Possible technique for averaging resolution

Instead of averaging on the FPGA where division by non powers of 2 isn't trivial, the pixels of the subwindow output will be a sum of the input pixels that were scaled into that pixel. The tracking module will then simply need to be informed as to how many pixels were scaled into one so that correct comparisons can be made.

--Hayden Gomes 21:20, 9 November 2009 (UTC)

In basic testing this equation has produced the correct values, but I will continue to work on verifying it. As for determining floor and ceiling, we can get floor as everything rounds down automatically and we should be able to get ceiling by calculating floor and then checking to see if the modulus is greater than 0. However if r is not a power of 2 then we may have issues doing the division.

--Hayden Gomes 20:54, 26 October 2009 (UTC)

A possible equation for predicting the scaling counts for each output pixel is as follows:

1 + Floor[(R*i+R-1)/r] - Ceiling[R*i/r]

where all of the variables are the same as defined below and Floor means to round down while Ceiling means to round up. I'm not sure yet how easy this would be to implement with the varied rounding techniques.

--Hayden Gomes 23:24, 22 October 2009 (UTC)

We hope to use the following equation for one-dimensional down scaling with should allow any window size to downscale to any output resolution:

i = r * (I/R),

where R is the window resolution, r is the output resolution, I is the index of a given pixel in the window, and i is the index where that pixel will map to in the output. If we can predict for each i in r how many pixels from R will map to it, then we can average the VGA inputs as they are passed in and only keep one row of pixels in memory.

--Hayden Gomes 22:21, 21 October 2009 (UTC)