FPGA implementation of camera colour model conversion

FPGA implementation of camera colour model conversion
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Automatyki i Informatyki Stosowanej
Academic year 2007/2008
Master diploma thesis
Fernando Ubiría
FPGA implementation of
camera colour model conversion
Tutor:
prof. nzw. dr hab. Cezary Zieliński
Grade
.................................
.........................................
Signature of person responsible
for exam committee
Specjalnosc: Electrical and Computer Engineering
– Computer Systems and Networks
Data urodzenia: 19 pazdziernika 1958 r.
Data rozpoczecia studiów: 1 pazdziernika 2006 r.
Źyciorys
Fernando Ubiría
.....................................
podpis studenta
Egzamin dyplomowy
Złozył egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ogólny wynik studiów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
......................................................................................
Summary
Tytuł: FPGA implementation of camera colour model conversion.
Słowa kluczowe: FPGA, Bayer, camera.
Abstract
Title: FPGA implementation of camera colour model conversion.
Most colour CCD cameras used in industrial vision systems have a mosaicked
mask of colour filters on the sensors, being the most popular the Bayer matrix.
The data must be interpolated to recover all the scene information. To achieve
a high frame rate, the interpolation must be performed trough a wired logic
circuitry. The interpolation methods suitable to be implemented as a hardware
device are investigated. The FPGA technology, its development environment
and the VHDL language are presented. Finally, a debayering device based in
a FPGA is developed, implemented and tested.
Key words: FPGA, Bayer, camera.
Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Digital colour cameras and the Bayer array . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 CCD sensors for cameras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Basics of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Device structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Digital colour cameras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Three CCD colour cameras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Single CCD colour cameras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Demosaicking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Nearest Neighbour Replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Bilinear Interpolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Smooth Hue Transition Interpolation. . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Other Interpolation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.5 The RGB and HSV colour models . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. FPGA colour model conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Possible physical placements for the device. . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 FPGA Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Altera Cyclone Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Hardware implementation of the debayering algorithm . . . . . . . . . . . . . . . . .
3.3.1 Description of the fundaments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 The implemented solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 The camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 The CameraLink interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 The FPGA development system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 The Frame Grabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 The development environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 The VHDL language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 The software implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Testing the prototype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A – VHDL listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix B – Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3
3
3
4
6
6
6
8
8
9
11
12
13
15
15
18
18
22
22
24
27
27
27
28
30
33
34
34
38
42
46
51
A
B
1. Introduction
There is a fast colour camera, capable of operating at up to 94 frames/sec. It has
a Bayer matrix and gives its output in this format.
The camera is connected trough a CameraLink interface to a commercial frame
grabber board, installed in a PC. This frame grabber has an FPGA and a RISC
processor on board, being a complete video processor.
Although the board is very capable, it performs heavy buffering of the video
information. As a result of
that, the computer receives each frame with
considerable delay, making it unsuitable for a robotics vision system.
This thesis should investigate the possibility of converting “on the fly” the Bayer
matrix information to a usable format, such as HSV or RGB.
This conversion should be done in hardware using an FPGA with as little
buffering as possible, to have a delay as short as possible.
2. Digital colour cameras and the Bayer array
2.1
CCD sensors for cameras
The charge-coupled device (CCD) was invented in 1969, as part of the research
efforts to develop a “semiconductor bubble memory”. It is an analog shift register,
enabling analog signals (electric charges) to be transported through successive
stages (capacitors), controlled by a clock signal. Under the control of an external
circuit, each capacitor can transfer its electric charge to one or other of its
neighbours.
Today, they are most widely used for serializing parallel analog signals, namely in
arrays of photoelectric light sensors.
2.1.1 Basics of operation
In a CCD for capturing images, there is a photoactive region (an epitaxial layer of
silicon), and a transmission region made out of a shift register (the CCD, properly
speaking).
An image is projected by a lens on the capacitor array (the photoactive region),
causing each capacitor to accumulate an electric charge proportional to the light
intensity at that location. A two-dimensional array, used in video and still
cameras, captures the whole image or a rectangular portion of it. Once the array
has been exposed to ligth, a control circuit causes each capacitor to transfer its
contents to its neighbour. The last capacitor in the array dumps its charge into a
charge amplifier, which converts the charge into a voltage. By repeating this
process, the controlling circuit converts the entire content of the array to a
sequence of voltages, which it samples, digitizes and stores in some form of
memory. These stored images can then be transferred to a video display or other
device. The CCD image sensors are inherently monochromatic.
2. Digital colour cameras and the Bayer array
4
2.1.2 Device structure
The CCD image sensors can be implemented in several different architectures.
The most common ones are full-frame, frame-transfer and interline transfer. The
distinguishing characteristic of each of these architectures is their approach to
the problem of shuttering.
a) Full-frame CCD
All of the image area is active and there is no electronic shutter. A mechanical
shutter must be added to this type of sensor or the image will smear as the
device is clocked or read out.
b) Frame transfer CCD
Half of the silicon area is covered by an opaque mask (typically aluminium). The
image can be quickly transferred from the image area to the opaque area or
storage region with acceptable smear of a few percent. That image can then be
read out slowly from the storage region while a new image is integrating or
exposing in the active area. Frame-transfer devices typically do not require a
mechanical shutter and were a common architecture for early solid-state
broadcast cameras. The downside to the frame-transfer architecture is that it
requires twice the silicon real estate of an equivalent full-frame device; hence, it
costs roughly twice as much.
c) Interline transfer CCD
This
diagram
illustrates
the
general
layout of the Interline Transfer CCD. This
kind of CCD is composed of precisely
positioned light sensitive semiconductor
elements, arranged as rows and columns.
Each row in the array represents a single
line in the resulting image. When light
falls onto the sensor elements, photons
are converted to electrons, being the
Interline transfer CCD
2. Digital colour cameras and the Bayer array
5
charge accumulated by each element proportional to the light intensity and
exposure time. This is known as the integration phase. After a pre determined
period of time, the accumulated charge is transferred to the vertical shift
registers. There are two methods to perform that:
a) Progressive scan CCDs - The charges in all rows are transferred to the
vertical shift register. Next, the charges in the vertical registers are shifted into
the horizontal shift register and clocked to the CCD output. All the lines of each
frame are then drawn in sequence
b) Interlaced scan CCDs - The charge transfer to the vertical shift registers is
accomplished in two stages. Initially the charge in the odd numbered rows is
transferred, followed by the even rows. Next the charges in the vertical registers
are shifted into the horizontal shift register and clocked to the CCD output.
Consequently all the odd rows are clocked out first (odd field) followed by all the
even rows (even field).
The rate at which the charge from the horizontal shift registers is clocked out is
governed by the number of elements (pixels) per row and the video standard the
camera complies with.
An inherent problem associated with the
interline transfer CCD lies in the fact that
the vertical shift registers running across
the array are insensitive areas, and as
such act as blind spots. One way of
overcoming this is to fabricate micro
lenses
over
each
element,
thereby
increasing the effective area of the cell.
The lenses also help with the smaller
format CCD. Because of the electrical
characteristics of the semiconductor substrate on which the CCD is formed, each
cell has an absolute minimum separation from adjacent cells. Therefore smaller
CCDs require smaller cells. Reducing cell size reduces the amount of
accumulated charge, using lenses increases the incident light.
2. Digital colour cameras and the Bayer array
2.2
6
Digital colour cameras
To obtain a colour image, we must measure light at three different wavelength
ranges known as colour – red, green, and blue. The information from these three
measurements can be combined to simulate the colour we see with our eyes.
There are two basic methods of colour imaging using CCD arrays:
2.2.1 Three CCD colour cameras
In this kind of cameras, an
optical prism assembly is
used to separate an image
into
three
colour
components. Each spectral
image is captured with a
CCD. Using this technique,
virtually all of the light for a
colour channel arrives at
the CCD array.
Each colour channel CCD utilizes all of it’s pixels, so the channels are captured
at the full array resolution. Trim filters mounted in front of each array accurately
control the spectral band so the camera can provide very accurate colour
representation. This technology produces the best results, but it is quite
expensive.
2.2.2 Single CCD colour cameras
This kind of cameras sample the spectrum of visible light using three or more
filters. Each location on the CCD (photo-site) captures one sample of the colour
spectrum. This gives us a “mosaic” of samples.
The raw data coming from the chip looks like a black and white picture with a
speckle pattern. The pattern is due to the different colour filters; each pixel is
2. Digital colour cameras and the Bayer array
7
seeing only a particular colour. To convert this to a colour image, each pixel must
have a red, green, and blue value. That means, that the missing colour values
should be somehow interpolated.
To reconstruct a colour image, we need to sample luminance and chrominance
information. Since the Human Visual System (HVS) is less sensitive to
degradation in the chrominance information than those in the luminance
information, the chrominance channels may be sampled at a rate much lower
than the luminance channel.
It has been found, that the spectral sensitivity of the HVS to luminance is similar
to the spectral power distribution of the green channel. Hence, green sensors
replace the luminance channel. Red and blue sensors replace the chrominance
channels.
We can now construct a colour filter to perform the sampling of the colour
spectrum.
- Colour Filter Arrays
The Bayer Array is one of the many possible
realizations of colour filter arrays.
It has a mosaic of red, green and blue optical
filters, like the one showed in the figure. The
arrangement describes the upper left corner of
the sensor array. The rest of the sensor array
can be determined by repeating this pattern
both horizontally and vertically in both spatial
dimensions.
Typical Bayer Matrix
2. Digital colour cameras and the Bayer array
2.3
8
Demosaicking
In order to obtain full colour reproduction of the scene information, the “mosaic”
of colours needs to be “undone” to recover three colour planes. This process is
referred to as “demosaicking”, "debayer" or "colour conversion" .
This conversion is performed by looking at adjacent pixels, and estimating what
the two missing colours should be. Many different algorithms have been
proposed for doing this, but all of them are compromises.
2.3.1 Nearest Neighbour Replication
This is a fast and crude method, fairly simplistic in its results, producing
artefacts around the edges of bright stars.
In this interpolation method, each interpolated output pixel is assigned the value
of the nearest pixel in the input image. The nearest neighbour can be any one of
the upper, lower, left and right pixels.
An example is illustrated below in the figure for a 3x3 block in the green plane.
Here we assume, that the left neighbouring pixel value is used to fill the missing
ones.
G12
G21
G14
G23
G32
G41
G16
G25
G34
G43
G52
G36
G45
G54
G23
G23
G25
G32
G34
G34
G43
G43
G45
G56
After interpolation
G61
G63
G65
Before interpolation
There are several well known alternative algorithms, that produce better results.
2. Digital colour cameras and the Bayer array
9
2.3.2 Bilinear Interpolation
Consider the array of pixels as shown in
R11 G12 R13 G14 R15 G16
the figure.
At a blue centre, we need to estimate the
G21 B22 G23 B24 G25 B26
green and red components.
R31 G32 R33 G34 R35 G36
Consider pixel 44 at which only B44 is
G41 B42 G43 B44 G45 B46
measured; we need to determine G44.
R51 G52 R53 G54 R55 G56
Given G34, G43, G45 and G54, one estimate
G61 B62 G63 B64 G65 B66
for G44 is given by the equation:
G44 = G34 + G43 + G45 + G54
4
To determine R44, given R33, R35, R53, R55, the estimate for R44 is given by
R44 = R33 + R35 + R53 + R55
4
and at a red centre, we would estimate the blue and green accordingly.
At a green pixel like the 43, we will calculate:
R43 = R33 + R53
2
B43 = B42 + B44
2
Performing this process at each pixel, we can obtain three colour planes for the
scene which would give us one possible demosaicked form of the scene.
This type of interpolation is a low pass filter process. The band-limiting nature of
this interpolator smoothens edges, which show up in colour images as “fringes”.
2. Digital colour cameras and the Bayer array
10
In the following diagrams, the intersections of the dotted lines represent one pixel
of the image. Each pixel can have components of red, green and blue color. A
grey pixel will have the three components with the same intensity value, a black
pixel none of them. A white pixel will have the three components with intensity
value 1.
1
1
2
2
3
3
4
4
5
5
1
2
3
4
5
6
7
8
9
10 11
12
(a)
1
2
3
4
5
6
7
8
9
10 11
12
(b)
(a) Original image
1
2
(b) Bayer subsampled image
3
4
(c) Result of bilinear interpolation
5
1
2
3
4
5
6
7
8
9
10 11 12
(c)
The diagrams show a blue line in row 4 between two orange lines in rows 3 and
5. We assume, that all the components present in the original image have
intensity value 1. After the bilinear interpolation, the strongest artefact will be at
the pixel P(4,6), in the blue line. It will now also have a red component, with
intensity value:
R46 = R35 + R37 + R55 + R57 = 0 + 1 + 1 + 0 = 0,5
4
4
Of course, there will be also some weaker influence (lower intensity) from the
blue line over the orange ones and conversely in the other pixels. This was not
pictured for simplicity.
2. Digital colour cameras and the Bayer array
11
2.3.3 Smooth Hue Transition Interpolation
One of the key objections to the bilinear interpolation is that the hues of adjacent
pixels change abruptly and in an unnatural manner. There is a need to maintain
the hue of the colour such that there are no sudden jumps in hue.
The Bayer pattern, on the other hand, can be thought of as consisting of a
luminance channel (the relatively numerous green pixels) and a chrominance
channel (the relative sparse red and blue pixels). A scheme can be created to
interpolate these channels differently.
In this section, the term hue will not have the usual meaning. It will refer to a
number relating a value of a color sampled at lower resolution, to the value of a
color sampled at higher resolution.
The red and blue hue values are defined by:
R , B
G
G
In the event that G = 0, it will be necessary to redefine the value of the hue.
By first interpolating the hue value, and then deriving the interpolated
chrominance values (blue and red) from the interpolated hue values, hues are
allowed to change only gradually, thereby reducing the appearance of color
fringes which would have been obtained by interpolating only the chrominance
values.
Suppose that we have an image with constant hue. The values of the luminance
(G) and one chrominance component (say red, R) at one location (Rij, Gij) and
another sample at location (Rkl, Gkl) are related as:
Rij = Gij
Rkl
Gkl
if also
Bij = Gij
Bkl
Gkl
If Rkl is the unknown chrominance value, and Rij and Gij represent measured
values, and Gkl is the interpolated luminance value, the missing chrominance
value Rkl is given by:
Rkl = Gkl
Rij
Gij
Of course, a normal colour image doesn't have uniform hue, but smoothly
changing hues are assured by interpolating the hue values of neighboring pixels.
2. Digital colour cameras and the Bayer array
Interpolation of green pixels:
Same as in bilinear interpolation. Also
note, that the interpolation of green
pixels
has
to
be
done
before
interpolations of red/blue pixels. This
before
will make more difficult the
implementation
of
this
method
in
hardware.
12
R11
G12
R13
G14
R15
G16
G21
B22
G23
B24
G25
B26
R31
G32
R33
G34
R35
G36
G41
B42
G43
B44
G45
B46
R51
G52
R53
G54
R55
G56
G61
B62
G63
B64
G65
B66
Interpolation of red/blue pixels:
Considering the interpolation of blue pixel values, there are three different cases:
a) Estimating blue pixel value at the green position and the adjacent blue pixels
are on left and right:
B43 = G43 *
B42 + B44
G42 G44
2
b) Estimating blue pixel value at the green position and the adjacent blue pixels
are on top and bottom:
B34 = G34 *
B24 + B44
G24 G44
2
c) Estimating blue pixel value at the red position:
R33 = G33 *
B22 + B24 + B42 + B44
G22 G24 G42 G44
4
The interpolation of the red pixel values can be carried out analogously.
2.3.4 Other Interpolation methods
There are several other interpolation methods. The Median-based Interpolation is
a two-pass process, the Gradient Based Interpolation is a three-pass one and the
Adaptive Colour Plan Interpolation involves quite heavy calculations.
These three methods don't seem to be feasible for a hardware converter, they
would probably require a processor.
2. Digital colour cameras and the Bayer array
13
2.3.5 The RGB and HSV colour models
The RGB colour model is made of the
three additive primaries Red, Green,
and Blue. The colour model is shown
as a Cartesian cube, with usually
Red being the x axis, Green being the
y axis, and Blue being the z axis, as
in the diagram to the left. The
diagonal from black (0,0,0) to white
(1,1,1) is the grey scale.
The HSV colour model consists of the
parameters: h (hue), s (saturation)
and v (value). The coordinate system
is cylindrical, and the subset of the
space within which the model is
defined is a hexcone. The top of the
hexcone corresponds to V = 1, which
contains the relatively bright colours.
The colours of the plane V = 1 are
not
all
of
the
same
perceived
brightness, however.
The
top
of
the
HSV
hexcone
corresponds to the projection seen by
looking along the principal diagonal
of the RGB color cube from White
toward Black. The RGB cube has
subcubes.
Each
subcube,
when
viewed along its main diagonal, is
also a hexagon but smaller. Each
plane of constant V in HSV space
corresponds to such a view of a
subcube in RGB space.
2. Digital colour cameras and the Bayer array
14
The conversion from the RGB space
to the HSV
space is a non-linear
transformation.
Although
the
conversion algorithm is well known,
it
requires
to
perform
divisions
between numbers that are not a
power of 2. Considering the required
operating speed, to build an enough
fast divisor is not a minor obstacle
for its hardware implementation. The
following is the C version, based on
reference [13].
// Given:
r,g,b values in [0,1]
// Desired: h = [0,360], s = [0,1], v = [0,1],
//
except if s == 0, then h = -1 (undefined)
void RGBtoHSV( float r, float g, float b, float *h, float *s, float *v )
{
float min, max, delta;
min = MIN( r, g, b );
max = MAX( r, g, b );
*v = max;
// this is the value v
delta = max - min;
if( max != 0 )
*s = delta / max;
// s
else {
// r = g = b = 0
// s = 0, v is undefined
*s = 0;
*h = -1;
return;
}
if( r == max )
*h = ( g - b ) / delta;
// between yellow & magenta
else if( g == max )
*h = 2 + ( b - r ) / delta;
// between cyan & yellow
else
*h = 4 + ( r - g ) / delta;
// between magenta & cyan
*h *= 60;
// convert hue to degrees
if( *h < 0 )
*h += 360;
// make sure hue is nonnegative
}
3. FPGA colour model conversion
3.1 Possible physical placements for the device
Conceptually, there are three possible places where it is possible to install a
hardware device to perform the debayering:
a) The camera itself
We cannot modify the camera.
b) In the middle of the CameraLink connection
Frame grabber
CameraLink
CameraLink
CameraLink to LVTTL
FPGA board
LVTTL to CameraLink
3. FPGA colour model conversion
16
Advantages: Using the already available development board from Altium, with
an Altera Cyclone EP1C12F324C8 FPGA, it would be inexpensive. The
CameraLink to LVTTL (low voltage TTL) chips have a price as factory samples of
about 7 USD each in the USA. The interfacing will be discussed in the point 4.1.
Disadvantages: i) The memory available in the development board would be
enough only to store one frame with 5 bits per colour, the camera provides 10
bits resolution. The more capable boards are expensive.
ii) In the CameraLink interface, a port is defined as an 8-bit word.
It has three possible configurations:
Base – 3 ports, allows up to 24bits-RGB (8bit per colour).
Medium - 6 ports. Because of connector constraints, it requires 2 cables.
Full - 8 ports. Because of connector constraints, it requires 2 cables.
It is unlikely to find a development board that allows to implement a device
with one input cable and two output cables.
iii)If the current frame grabber and its drivers remain in use, there is no
warranty that it would not continue introducing a significant delay.
c) Inside the frame grabber
This is the current solution, but it introduces a delay that makes the set-up
unusable. The user has no control over how the debayering is performed, and the
conversion from RGB to HSV seems to be done in software.
The answer to this problem is to use a frame grabber whose FPGA is Userprogrammable.
Advantages: Mechanically stable set-up, without external boxes, the Base
Configuration should be enough to get the 10 bit resolution. Having direct access
to the FPGA allows to select the fastest algorithm. It is possible to graphically
programme using a standard library, import VHDL or a C++ like tool.
Disadvantages: The cost.
3. FPGA colour model conversion
17
Comparison
I can recommend the implementation b) only for an inexpensive “proof of
concept” device, just to show how to use an FPGA. It is not adequate for a robust
and reliable implementation that integrates the camera into the production line
of the laboratory. The development boards with enough RAM and I/O pins to get
the full resolution are in a price range of 500 to 4000 USD.
The implementation c) is reliable. There are models already capable of executing
debayering and colour space conversion, so the hardware can do the task. It is
necessary to put together the best algorithm, using the graphical environment, or
VHDL if necessary. The whole set-up must be then integrated into the application
software. The drawback of this solution is the cost, about 5500 EUR for the
board plus the programming environment. There are PCI and PCIe versions.
There is also a PCI development board from Altera. This board could probably be
used to implement a frame grabber with a User-programmable FPGA. The device
must be programmed using VHDL, and a device driver must be written for the
board. The cost would be a fraction of the commercial product, about 1000 USD.
Howewer, when compared with a powerful stand-alone development board, that
can be obtained for 500 USD, the PCI board is an expensive solution.
Conclusions
The alternative b) will be implemented as a “proof of concept” device. This is
inexpensive and would allow to gain knowledge about the use of a FPGA for this
task.
3. FPGA colour model conversion
3.2
18
FPGA Technology
Field Programmable Gate Arrays (FPGAs) are integrated circuits whose internal
functional operation is defined by the user, through internal programmable
interconnect circuitry. Conversely, custom designed ASICs
require a final
customized manufacturing step for the user-defined functions.
Internally, FPGAs typically contain multiple copies of a basic programmable logic
element (LE) or cell. The logic element can implement a network of several logic
gates, that then feed into 1 or 2 flip-flops. Logic elements are arranged in a
column or matrix on the chip. To perform more complex operations, logic
elements can be automatically connected to other logic elements on the chip,
through a programmable interconnection network also contained in the FPGA.
The interconnection network used to connect the logic elements contains row
and/or column chip-wide interconnects. In addition, it often contains shorter
and faster programmable interconnects limited only to neighbouring logic
elements.
In large FPGAs, the clock signals normally use special low-skew global clock
buffer lines. These are dedicated pins connected to an internal high speed bus.
This special bus is used to distribute the clock signal to all flip-flops in the device
at the same time, to minimize clock skew.
3.2.1 Altera Cyclone Architecture
The Cyclone device is configured by loading internal static random access
memory (SRAM). Because of that, the configuration will be lost whenever the
power is removed. A small external serial flash memory is normally used to
automatically load the FPGA's programming information when the device powers
up.
The Cyclone devices contain a two dimensional row- and column-based
architecture to implement user logic. Column and row interconnection networks of
varying speeds provide signal interconnects between Logic Array Blocks (LABs)
and embedded memory blocks.
The logic array consists of LABs, with 10 LEs in each LAB. An LE is a small unit
of logic providing efficient implementation of user logic functions. LABs are
3. FPGA colour model conversion
19
grouped into rows and columns across the device. Cyclone devices range between
2,910 to 20,060 LEs.
M4K RAM blocks are true dual-port memory blocks with 4K bits of memory plus
parity (4,608 bits). These blocks provide dedicated true dual-port, simple dualport, or single-port memory up to 36-bits wide at up to 250 MHz. These blocks
are grouped into columns across the device in between certain LABs. The device
EP1C12 used for this project contains 239 K bits of embedded RAM.
Each Cyclone device I/O pin is fed by an I/O element (IOE) located at the ends of
LAB rows and columns around the periphery of the device. I/O pins support
various single-ended and differential I/O standards. Each IOE contains a
bidirectional I/O buffer and three registers for registering input, output, and
output-enable signals. Dual-purpose DQS, DQ, and DM pins along with delay
chains (used to phase-align DDR signals) provide interface support with external
memory devices such as DDR SDRAM, and FCRAM devices at up to 133 MHz.
Cyclone devices provide a global clock network and up to two PLLs. The global
clock network consists of eight global clock lines that drive throughout the entire
device. The global clock network can provide clocks for all resources within the
device, such as IOEs, LEs, and memory blocks. The global clock lines can also be
used for control signals. Cyclone PLLs provide general-purpose clocking with
clock multiplication and phase shifting as well as external outputs for high-speed
differential I/O support.
Logic Array Blocks
A LAB is composed of 10 LEs, LE carry chains, LAB control signals, a local
interconnect, look-up table (LUT) chain, and register chain connection lines.
The local interconnect transfers signals between LEs in the same LAB.
LUT chain connections transfer the output of one LE's LUT to the adjacent LE
for fast sequential LUT connections within the same LAB.
Register chain connections transfer the output of one LE's register to the adjacent
LE's register within a LAB.
The LAB local interconnect can drive LEs within the same LAB, and it is driven
by column and row interconnects and LE outputs within the same LAB.
Neighbouring LABs, PLLs, and M4K RAM blocks from the left and right can also
drive the LAB's local interconnect through the direct link connection. This
3. FPGA colour model conversion
minimizes the
use
20
of row and column interconnects, providing higher
performance.
In the example, the top LE is driving lines in the row and column interconnects
trough two of its outputs. The third LE has input and output connections with
the local interconnect of its LAB, and with the local interconnect of its neighbour
LAB at the right.
Logic Elements
Each LE contains a four-input LUT, which is a function generator that can
implement any function of four variables. The LUT is a high speed 16 x 1 SRAM.
Four inputs are used to address the LUT's memory. The truth table for the
desired gate network is loaded into the LUT's SRAM during programming. A
single LUT can then model any network of gates with four inputs and one output.
In addition, each LE contains a programmable register and carry chain with
carry select capability. A single LE also supports dynamic single bit addition or
subtraction mode selectable by a LAB-wide control signal. Each LE drives all
types of interconnects: local, row, column, LUT chain, register chain, and direct
link interconnects. Each LE's programmable register can be configured for D, T,
JK, or SR operation. Global signals, general-purpose I/O pins, or any internal
logic can drive the register's clock and clear control signals. Either general-
3. FPGA colour model conversion
21
purpose I/O pins or internal logic can drive the clock enable, preset,
asynchronous load, and asynchronous data.
Each LE has three outputs that drive the local, row, and column routing
resources.
The
LUT or register output can drive these
three
outputs
independently. Two LE outputs drive column or row and direct link routing
connections and one drives local interconnect resources. This allows the LUT to
drive one output while the register drives another output.
3. FPGA colour model conversion
22
3.3 Hardware implementation of the debayering algorithm
3.3.1 Description of the fundaments
The different algorithms that perform the debayering, need to have access to a
3x3 pixel-block in order to perform the necessary calculations. A basic difference
between the software and the hardware implementations, is how these accesses
are performed.
When the debayering runs in software, usually the whole frame is stored in a
buffer memory. The program will access the different pixels as many times as
needed, doing that sequentially.
A debayering running in hardware should have access to all 9 pixels
simultaneously.
The approach of having the whole frame stored in a buffer is then not well suited.
A possible solution consists in having only some line buffers instead of a frame
buffer.
The CameraLink interface delivers one pixel at a time, its intensity is coded in 8
bits. The demultiplexer FSD (Front Side Demultiplexer) is used to direct the
captured video and write it into one of four line buffers. This four-line-buffer acts
as a circular buffer, each line is a RAM memory with separated Data input and
output. Three of the line buffers are available for reading, while the fourth one is
being updated. The line counter controls the demultiplexer FSD, directing the
video information to the appropriated line buffer.
The Data outputs of the line buffers are connected to the multiplexer BSM (Back
Side Multiplexer), also controlled by the line counter, the output of this
multiplexer are 24 bits, taken from the three line buffer that are available for
reading.
The Address inputs of the four line buffers are connected in parallel to the
outputs of the column counter, which determines the position in the line that
must be read or written.
The destination pixel to be processed p(x,y) is a function of the surrounding
pixels p(x-1,y), p(x+1,y) and the ones in the rows (y-1) and (y+1).
To have access to these nine pixels, we implemented a sort of shift register. The
first stage consists of the three line buffers that we are reading. The second and
third stages consist each of 3*8 D-Flip-Flops, their clock inputs are driven by the
3. FPGA colour model conversion
23
same clock as the column counter.
They are used as latches to hold the pixel values at positions:
(x-1, y-1) , (x, y-1)
(x-1, y)
, (x, y)
(x-1, y+1) , (x, y+1)
and by setting the read address on the line buffers to x+1, the data outputs
would then yield:
(x+1, y-1)
(x+1, y)
(x+1, y+1)
giving all the necessary data to compute the RGB values for the pixel. Each time
we increment the column counter, the shift register will hold the information
required to calculate the next pixel. Each pixel is processed with a delay equal to
the time of 2 scan-lines with respect to the moment it was captured by the
camera, this way the debayering process will run in “real time”.
x +1
line buffer 0
CameraLink
8 bit
F
S
D
line buffer 1
line buffer 2
line buffer 3
Line counter
x
D FF Q
x8
B
S
M
x-1
D FF Q
x8
D FF Q
D FF Q
x8
x8
D FF Q
D FF Q
x8
x8
y-1
y
y +1
Column counter
24 bit
24 bit
Debayering and
colour space
conversion logic
CameraLink
24 bit
24 bit
3. FPGA colour model conversion
24
The debayering and colour space conversion logic uses the least significant bit of
the line and column counters to determine the colour of the pixel being
processed.
The green pixels type 1 and 2
Line ctr. bit 0
Col. ctr. bit 0
Colour
0
0
red
are
0
1
green_1
between red pixels, type 2
1
0
green_2
between blue ones.
1
1
blue
will
require
calculations.
Type
different
1
The pixels in the borders of the frame also require special calculations. To
recognize them, the content of both counters are also be fed to the debayering
logic.
3.3.2 The implemented solution
To implement the basic circuitry, it was necessary to introduce some
modifications:
1) The line buffers were implemented using the M4K memory blocks of the FPGA.
Because of the access timing, the output of the line buffers is delayed two
pixels with respect to the pixel being written now. At the end of a line, when
the FSD should already select the new line buffer, the BSM still has to deliver
the last two pixels of the previous line. As a consequence, it was necessary to
use two separated line counters to drive them. The counter for the BSM is
delayed the time of two pixel clocks with respect to the counter for the FSD.
The pixel clock is the signal PVAL, coming from the input CameraLink
transceiver.
2) The groups of 8 D-Flip-Flops were implemented in the same VHDL source file
as the debayering logic (debayer.vhd).
The adders in the logic elements LE of the Cyclone FPGA have 4 inputs, but
when implementing several bit wide additions, the carry takes one of them.
Adding the 4 values required for the bilinear interpolation would imply some
cascading configuration. The simulations showed the associated delay. To
avoid that, the following was implemented: While interpolating the pixel n-1,
3. FPGA colour model conversion
25
two of the values required for the pixel n are being added and kept in a preaddition register: pre_green, and pre_bl_re for blue or red (as required).
The registers for the pixels (x-1, y-1) and (x-1, y+1) are not needed anymore,
except to perform the calculations for the pixels in the border of the frame. In
the border, the Nearest Neighbour Replication method is used.
In the example below, at the time n-1, when the red and blue components
for the green pixel P(x, y) are calculated, the partial additions for the green
and
blue components of
the
red
pixel
P(x+1, y)
are performed.
The
calculations will be completed in the next pulse of the clock, when the red
pixel will be shifted to the position (x, y). The procedure is similar for the blue
pixels.
Pixel
clock
time pixel n-1
x+1
Pixel values
for the
interpolation
x
time pixel n
x-1
x+1
y-1
y-1
y
y
y+1
y+1
pre_green = P(x+1, y-1) + P(x+1, y+1)
x
x-1
portB = P(x+1, y) + P(x-1, y) + pre_green
4
pre_bl_re = P(x, y-1) + P(x, y+1)
portA = P(x+1, y-1) + P(x+1, y+1) + pre_bl_re
4
portC = P(x, y)
3. FPGA colour model conversion
26
3) To properly sample the input pixel-information and store it in the buffer, the
column counter and the counters for the FSD and BSM must increment with
the falling edge of the pixel clock. The information in the output of the buffer
will be stable and be sampled by the D-registers at the rising edge. For the
debayering logic, the pixel period will be then determined by the rising edge of
the pixel clock. Because of that, a separated column counter that increments
with the rising edge of the clock was implemented for it.
4) Although the basic description considered for simplicity a camera which
delivers 8 bit per pixel, the camera object oft this work has an output of 10 bit
per pixel. To obtain the best possible results compatible with a 24-bit RGB
output, the buffer stores 10 bit per pixel and the calculations are performed
with 10 bit precision. Only at the end of the process, the two less significant
bit are discarded.
Block diagram of the implementation
x +1
line buffer 0
CameraLink
10 bit
F
S
D
line buffer 1
line buffer 2
line buffer 3
B
S
M
x
D FF Q
x10
y-1
D FF Q
x10
D FF Q
x10
y
D FF Q
x10
D FF Q
x10
y +1
30 bit
Column counter
Line cntr.FSD
x-1
D FF Q
x10
Pre-adder
green
30 bit
Pre-adder
red/blue
Line cntr.BSM
Debayering logic
CameraLink
24 bit RGB
30 bit
4. Implementation
4.1
Hardware
4.1.1 The Camera
The camera is a SVS084 from the
company SVS-Vistek GmbH. It is
from the progressive scan type, with
nominal resolution of 640 x 480 pixel
(307200 pixels), 10 bit per colour,
94 FPS and CameraLink interface.
The
camera
employs
a
CCD
progressive scan interline-sensor
SONY
ICX424AQ, the sensor has a diagonal of 6 mm. This chip features an
electronic shutter with variable charge-storage time which makes it possible to
realize full-frame images without a mechanical shutter. It includes in front of its
sensor elements an array of filters, arranged to form a Bayer matrix GB_RG.
The image is progressively scanned, and the readouts of the charges
accumulated in the sensor elements are digitized by a 10 bit analog to digital
converter. So, the pixels are transmitted in sequential order, through a 10 bit
parallel connection. A circuitry inside the camera converts the parallel
connection to the CameraLink interface.
The real number of pixels is 656 x 494. The pixel clock frequency is 43 MHz.
There are 13 leading dark lines, they are the Back Porch after the frame
synchonization pulse.
The camera provides a serial interface (integrated in the CameraLink cable), for
the configuration of such camera parameters as trigger mode and exposure
control.
4. Implementation
28
4.1.2 The CameraLink interface
CameraLink is a communications interface developed for use in vision
applications.
It
is
based
on
Channel
Link
technology
from
National
Semiconductor, that uses LVDS (Low Voltage Differential Signalling) technology
for transmitting digital data.
As shown in the figure, the
Channel Link Transmitter (in
yellow, at the left) converts 28
bits of CMOS/TTL data into
four LVDS data streams. A
phase-locked transmit clock
is transmitted in parallel with
the data streams over a fifth
LVDS link.
With each cycle of the transmit clock applied to STRB (left), 28 bits of input data
are sampled, multiplexed and transmitted over the four LVDS links X0 to X3. The
LVDS link CLKX carries the phase-locked transmit clock. The Channel Link
receiver converts the data streams back into 28 bits of CMOS/TTL data, plus a
receive clock RxCLK, present in the output STRB (right).
4. Implementation
29
The CameraLink uses in the Base Configuration 24 Data and 4 Enable signals.
There are also 4 control signals to the camera plus a serial communications
interface.
The four enable signals are defined as:
•
•
•
•
FVAL
LVAL
DVAL
Spare
-
Frame Valid (FVAL) is defined HIGH for valid lines.
Line Valid (LVAL) is defined HIGH for valid pixels.
Data Valid (DVAL) is defined HIGH when data is valid.
A spare has been defined for future use.
Time relationship between enable signals and pixel data
The 24 Data signals are divided between three 8 bit ports A, B and C.
The assignment of the ports depends on the configuration, it is in our case:
Camera to debayering device - 10 bit “grayscale” data: PortA 0-7 + PortB 0-1
Debayering device to frame grabber - 24 bit RGB: PortA 0-7, PortB 0-7, PortC 0-7
The assignments are usually PortA = Red, PortB = Green, PortC = Blue, but our
frame grabber expects PortA = Blue and PortC = Red.
The frame grabber will then receive three data streams, that will be used to build
in its buffer the three colour planes R, G and B.
4. Implementation
30
4.1.3 The FPGA development system
The available development board from Altium has two 20 pin expansion
connectors, totalling 36 signals available for user's I/O. The connection to the
CameraLink transceivers would require at least 11 signals for the input and 27
for the output, without counting the 4 camera control signals and the serial
communications interface. It became apparent that it would be better to look for
another development platform, preferably with standard connectors that allows
the use of standard I/O boards.
The Santa Cruz Connector
The Santa Cruz connector is an Altera
defined
interface
interface, that provides
to
an
the
expansion daughter
board. It comprises 40 general purpose
I/O signals, 2 control signals, 3 clocks,
ground, and regulated 3,3 V and 5 V
power. The interface is 5 V compatible.
Note: Cyclone devices can be 5.0 V tolerant with
the use of an external resistor and the internal
PCI clamp diode.
When VCCIO = 3,3 V, a Cyclone device can drive
a device with 5,0 V LVTTL inputs, but not 5.0 V
LVCMOS inputs.
The CameraLink input and output boards
The Cyclone FPGA used in the debayering device has inputs and outputs
compatible with low voltage TTL (LVTTL) levels. To make the conversion between
CameraLink and parallel LVTTL signals, it is necessary to use the chips from
National Semiconductors DS90CR286 and DS90CR285 specifically developed for
this interface. The standard CameraLink connectors are the MDR 26-pin ones
from 3M.
The company devboards (in Lohmar-Germany) manufactures CameraLink
expansion boards for the Santa Cruz connector. Two boards were acquired from
them:
4. Implementation
31
a) CameraLink input board DBCMLKIN: It decodes the four LVDS data streams
and delivers the 28 LVTTL signals to a Santa Cruz expansion connector. The
board employs the DS90CR286 receiver.
b) CameraLink output board DBCMLKOUT: It codes the 28 LVTTL signals from
a Santa Cruz connector into four LVDS data streams. The board employs the
DS90CR285 transmitter.
Both boards also handle the control signals to the camera plus the serial
communications interface. The schematics of the boards and basic information
about the transceivers can be found in Appendix B.
The FPGA development board
Then, it was necessary to select a
Cyclone
development
equipped with two Santa
board
Cruz
expansion sockets. The connection
to the host computer running the
development environment should
be through USB or RS-232.
A development system from the
Canadian
was
company
acquired.
This
Microtronix
system
is
composed of two boards:
a) The Firefly Module: It is originally intended to provide a drop-in uClinux
system for embedded systems. It provides a Cyclone EP1C12F324C8 FPGA (the
same as the Altium board) for a Nios II soft-core processor as well as 16MB
SDRAM and 1 MB Flash to run the uClinux operating system. An active serial
configuration device EPCS4 is also on board, it can be used after a Power-On to
load a design from the flash memory of the configuration device into the FPGA
SRAM cells. The module requires 3,3V and 1,5 V power supply. In this project,
4. Implementation
32
only the resources contained in the FPGA itself will be used. The Firefly module
can be order separately, to be plugged in a target system.
b) The PSK Base Carrier Board:
It provides a header to connect
the Firefly module, two Santa
Cruz expansion headers, built-in
USB Blaster cable functionality
and an RS-232 interface. The PSK
board also provides the necessary
power to the Firefly module. The
socket A is a full implementation,
and the socket B is a slightly
reduced one. The
CameraLink
output board will be mounted in
socket A, and the input board in
socket B.
The interconnection drawings between the modules can be found in Appendix B.
The completely mounted device
4. Implementation
33
4.1.4 The Frame Grabber
The frame grabber is a leonardo PCI64-CL-P from ARVOO. It operates as a PCI
2.2 bus master, allowing to transfer images directly to the system memory
without impacting the processor. It can operate in 32 bit and 64 bit buses at 33
MHz and 66 MHz, and is 3.3V or 5V I/O compatible. The board has a Xilinix
FPGA, and also incorporates a 64-bit MIPS-Microprocessor RM-7000C for general
purpose on board video processing. The camera interface is CameraLink.
It can operate in the following modes and maximum data rate (pixel clock):
- DUAL BASE (2x max. 24-bits), 16-bit/85 MHz, 24-bit/50MHz.
- MEDIUM (max. 48-bits), 32-bit/50MHz, 40-bit/40MHz, 48-bit/25MHz
The video modes are software controlled and accept area scan cameras.
The
developed device is connected to one of the two CameraLink inputs. The
capture software Lnrd_vc from Arvoo is used to test the operation. The frame
grabber is setup to capture 24-bit RGB, and the RISC processor is off. In this
way, the video-information follows the path marked by the red arrows. For each
frame, the board controller stores the incoming information in an on-board
buffer. At the same time, a preceding and already buffered frame is transferred to
the main memory of the computer. Although the information travels across the
on-board FPGA, it is not used for the video processing.
4. Implementation
4.2
34
Software
4.2.1 The development environment
The development environment is
the
Altera
Quartus
II
design
software. It provides a complete
development
environment
for
system-on-a-programmable-chip
(SOPC) design, including solutions
for all the phases of FPGA design.
For the
Web Edition used in this
thesis, it is necessary to ask for a
new free license every 150 days.
It is possible to use the Quartus II
graphical user interface, EDA tool
interface, or command-line interface for each phase of the design
flow.
The Quartus II software includes a modular Compiler. The Compiler includes the
following modules (depending on the settings, the modules marked with an
asterisk are optional during a full compilation):
■
■
■
■
■
■
■
■
Analysis & Synthesis
Partition Merge*
Fitter
Assembler*
Classic Timing Analyzer and TimeQuest Timing Analyzer*
Design Assistant*
EDA Netlist Writer*
HardCopy Netlist Writer*
It is possible to run a full compilation, or just to start the Compiler modules
individually. The Full Edition (paid) allows for incremental compilation, to speedup the development process.
4. Implementation
35
Design entry
The Block Editor allows to enter and edit graphic design information in the form
of schematics and block diagrams. Each Block Design File contains blocks and
symbols that represent logic in the design.
The Quartus II Text Editor is used to create a design in the AHDL, Verilog HDL, or
VHDL design languages. Nowadays, the preferred method is to create the design
using VHDL or Verilog. VHDL has been in the public domain longer than Verilog
and was selected for this project.
Altera megafunctions are complex or high-level building blocks that can be used
together with gate and flip-flop primitives in Quartus II design files. The
parameterizable megafunctions and the library of parameterized modules (LPM)
functions provided by Altera are optimized for Altera device architectures. It is
necessary to use megafunctions to access some Altera device-specific features,
such as memory, DSP blocks, LVDS drivers, PLLs, serializer/deserializers
(SERDES) and double-data rate input/output (DDIO) circuitry.
Synthesis
Analysis & Synthesis builds a single project database that integrates all the
design files in a design entity or project hierarchy, this database is used for the
remainder of project processing. Other Compiler modules update the database
until it contains the fully optimized project. In the beginning, the database
contains only the original netlists; at the end, it contains a fully optimized, fitted
project.
As it creates the database, the Analysis stage examines the logical completeness
and consistency of the project, and checks for boundary connectivity and syntax
and semantic errors. Analysis & Synthesis also synthesizes and performs
technology mapping on the logic in the design entity or project’s files. It infers
flipflops, latches, and state machines from VHDL.
4. Implementation
36
Place & Route
The Fitter places and routes the design. It matches the logic and timing
requirements of the project with the available resources of a device. It assigns
each logic function to the best logic cell location for routing and timing, and
selects appropriate interconnection paths and pin assignments. The Assembler
automatically converts the Fitter’s device, logic cell, and pin assignments into a
programming image for the device.
Timing Analysis
The Classic timing analyzer automatically performs timing analysis on the design
following a full compilation. The Classic Timing Requirements allow you to
specify the desired speed performance for the entire project, for specific design
entities, or for individual entities, nodes, and pins.
In this project, the desired maximum pixel clock frequency was entered as a
constraint.
Simulation
The Quartus II software allows to simulate an entire design, or to simulate any
part of a design. Any design entity in a project can be designated as the top-level
design entity, and then simulate the top-level entity and all of its subordinate
design entities.
You can specify the type of simulation (functional or timing simulation) that
should be performed, the time period covered by the simulation, the source of
vector stimuli.
The most common input stimulus for the Quartus II Simulator are Vector
Waveform Files, generated with the Waveform Editor
Programming & configuration
Quartus II can also download the configuration file created by the Assembler to
the FPGA, making use of the built-in USB Blaster cable functionality of the PSK
Base Carrier Board.
4. Implementation
37
Power Analysis
The PowerPlay Power Analysis Tools provide an interface that allows to estimate
static and dynamic power consumption throughout the design cycle. They
perform postfitting power analysis and produce a power report that highlights, by
block type and entity, the power consumed.
In this project, the FPGA is mounted in a development board already designed to
power it. These tools were not used.
Debugging
The SignalTap II Logic Analyzer is a second-generation system-level debugging
tool that captures and displays real-time signal behaviour, allowing to observe
interactions between hardware and software in system designs.
Quartus II allows to select the signals to capture, when signal capture starts, and
how many data samples to capture. You can also select whether the data is
routed from the device’s memory blocks to the SignalTap II Logic Analyzer via the
JTAG port, or to the I/O pins for use by an external logic analyzer or
oscilloscope.
The same communications cables used to download configuration data to the
device, are also used to upload captured signal data from the device’s RAM
resources to the Quartus II software. Quartus II then displays data acquired by
the SignalTap II Logic Analyzer as waveforms.
This tool was not used, the design was developed using only the Simulation tool.
Engineering Change Management
Quartus II allows to make small modifications, often referred to as engineering
change orders (ECO), to a design after a full compilation. These ECO changes can
be made directly to the design database, avoiding to run a full compilation in
order to implement the change. This tool was not used.
Timing closure
Quartus II offers a fully integrated timing closure flow that allows to meet the
timing goals by controlling the synthesis and place and route of a complex
design. This tool was not used.
4. Implementation
38
4.2.2 The VHDL language
VHDL is an acronym for Very High Speed Integrated Circuits Hardware
Description Language. It is a language used to model and design digital
hardware, and is the subject of the IEEE standards 1076 and 1164.
Conventional programming languages are based on a sequential operation model.
Digital hardware devices by their very nature operate in parallel. This means that
conventional programming languages cannot accurately describe or model the
operation of digital hardware. VHDL is designed to model parallel operations.
Data types: In addition to the normal data types, VHDL contains new types like
STD_LOGIC,
which
is
normally
used
to
model
a
logic
bit.
The
type
STD_LOGIC_VECTOR contains a one-dimensional array of STD_LOGIC bits.
Operators: They include several mathematical and logical operators like: +, -, &,
=, /=, <, <=, >, >=, NOT, AND, OR, NAND, NOR, XOR, XNOR. Other operators are
supported only by some tools or for some devices.
Processes: They allow to create a behavioural software-style VHDL. Instead of
instantiating a component in an architecture, we can instantiate a process.
Processes are only permitted inside an architecture. The statements within
processes execute sequentially, not concurrently. The IF and CASE constructs
must be used inside a process.
Synthesis of digital Hardware: It is usually performed at the register transfer
level (RTL). An RTL model of a circuit describes the input/output relationship in
terms of dataflow operations on signal and register values. If registers are
required, a synchronous clocking scheme is normally used.
A design is described in VHDL using the concept of a design entity. A design
entity is split into two parts, each of which is called a design unit in VHDL jargon.
The entity declaration represents the external interface to the design entity. The
architecture body represents the internal description of the design entity - its
behaviour, its structure, or a mixture of both.
4. Implementation
39
In this example, we will create a simple array of
gates. The name of the entity AOI is also normally the
file name. The name of the architecture V1 is also
arbitrary chosen by the user. The data type of a port
defines the set of values that may flow through the
port. The ports are of type STD_LOGIC.
-- VHDL code for AND-OR-INVERT gate
library IEEE;
-- Include Libraries for standard data types
use IEEE.STD_LOGIC_1164.all;
entity AOI is
port (
-- Ports: Declares module inputs and outputs
A, B, C, D: in STD_LOGIC;
F : out STD_LOGIC
);
end AOI;
architecture V1 of AOI is
-- Defines internal module architecture
begin
F <= not ((A and B) or (C and D));
end V1;
Now we have two internal signals AB and CD. A signal is declared before the
begin of an architecture. Technically, ports are signals, so signals and ports are
read and assigned in the same way. The assignments within the architecture are
concurrent signal assignments. Such assignments execute whenever a signal on
the right side of the assignment changes value. Each of the concurrent signal
assignments has a delay. The expression on the right side is evaluated whenever
a signal on the right side changes value, and the signal on the left side of the
assignment is updated with the new value after the given delay. Quartus II
already knows about the delays existent in the Altera FPGAs.
library IEEE;
use IEEE.STD_LOGIC_1164.all;
entity AOI is
port (A, B, C, D: in STD_LOGIC;
F : out STD_LOGIC);
end AOI;
architecture V2 of AOI is
signal AB, CD: STD_LOGIC;
begin
AB <= A and B after 2 NS;
CD <= C and D after 2 NS;
F <= AB nor CD after 3 NS;
end V2;
4. Implementation
40
In the next example, a positive edge triggered D flip-flop will be generated.
Instead of designing it gate by gate, we will use a process.
In VHDL, clk 'event is true whenever the clock signal changes, the positive edge
is selected by (clk 'event and clk='1').
Processes with a WAIT statement don't need a sensitivity list. If WAIT is not used,
a list with the used signals must follow the keyword PROCESS (sensitivity list).
In this case we have only one process, and the statements within a process
execute sequentially. If an architecture includes several processes, they execute
concurrently.
-- Positive triggered D FF with synchronous reset
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY dff_ck0 IS
PORT
(
d
: IN STD_LOGIC;
clk
: IN STD_LOGIC;
: IN STD_LOGIC;
reset
q
: OUT STD_LOGIC
);
END dff_ck0;
ARCHITECTURE estruct_dff_ck0 OF dff_ck0 IS
BEGIN
PROCESS
BEGIN
WAIT UNTIL (clk 'event and clk='1');
IF reset = '0' then
q
<= '0';
ELSE
q
<= d;
END IF;
END PROCESS;
END estruct_dff_ck0;
VHDL allows a hierarchical design. It is possible to use one design as a
component of another one. In the next example, the D flip-flop will be used as a
component of a two bit shift register. DFF_1 and DFF_2 will be instantiations of the
component dff_ck0.
4. Implementation
41
-- Two bit shift register
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY shft_rg IS
PORT
(
in_data
in_clk
in_reset
out_data
);
END shft_rg;
:
:
:
:
IN STD_LOGIC;
IN STD_LOGIC;
IN STD_LOGIC;
OUT STD_LOGIC
ARCHITECTURE estruct_R OF shft_rg IS
-- Declare internal signals needed to connect submodules
SIGNAL out_DFF_1 : STD_LOGIC;
component dff_ck0 port(
d, clk, reset: in std_logic;
q
: out std_logic);
end component;
BEGIN
DFF_1 : dff_ck0 PORT MAP (
d => in_data, q => out_DFF_1,
clk => in_clk, reset => in_reset
);
DFF_2 : dff_ck0 PORT MAP (
d => out_DFF_1, q => out_data,
clk => in_clk, reset => in_reset
);
END estruct_R;
Quartus II also allows to visualize the generated circuit.
4. Implementation
42
4.2.3 The software implementation
The design methodology is strictly hierarchical, being the VHDL source file
converter.vhd the top level in this hierarchy. Its building blocks are:
a) video_buffer.vhd – contains the four line buffers, together with the
multiplexers FSD, BSM and the associated line and column counters.
The corresponding files are:
line_buffer.vhd – Defines a buffer of 658 x 10-bit words, capable to hold one
scan line. This file was generated using the megafunction wizard of Quartus II.
fsd.vhd the functionality of the demultiplexer is really implemented as a decoder,
which activates the write_enable of the appropriate line buffer.
bsm.vhd implement the multiplexer
lin_cntr_fsd, lin_cntr_bsm and col_cntr.vhd implement the necessary counters
b) debayer.vhd – contains the D Registers where the pixels at (x-1, y-1),
(x, y-1), (x-1, y), (x, y), (x-1, y+1)and (x, y+1) are stored, together with the
debayering logic and the registers to store the pre-additions:
green_DFF
stores the pre-addition of the green values
bl_re_DFF stores the pre-addition of the blue or red component
The necessary divisions by 2 and 4 are performed by shifting respectively 1 or 2
bits to the right. This is performed in zero time, just by connecting the outputs to
the most significant 8 bits of the result. For example in:
db_out_portB <= conv_std_logic_vector(conv_integer(point_Xp1_Y)
+ conv_integer(point_Xm1_Y) + conv_integer(ou_pre_green),12) (11 downto 4);
The logic to determine the colour of the pixel was also slightly modified. There are
four different versions of the Bayer matrix: RG_GB, GB_RG, GR_BG, BG_GR.
i)
RG_GB – The first row is R, G, R....., the second one G, B, G..... and so on.
ii) GB_RG – The first row is G, B, G....., the second one R, G, R..... and so on.
The other two versions follow the same rule.
The table included in the point 3.3.1 is for a RG_GB camera, and the camera in
the robotics laboratory is a GB_RG one.
4. Implementation
43
This part of the code shows the basic interpolation process. Based on the value of
the line and column counters, the case construct determines the colour of the
pixel: red, green_1, green_2 or blue.
PROCESS (pix_line_Nr, pix_col_Nr, point_Xp1_Ym1, point_Xp1_Y, point_Xp1_Yp1,
point_X_Ym1, point_X_Y, point_X_Yp1,
point_Xm1_Ym1, point_Xm1_Y, point_Xm1_Yp1,
ou_pre_green, ou_pre_bl_re)
BEGIN
case pix_line_Nr(0 downto 0) & pix_col_Nr(0 downto 0) is
when "10" =>
ena_green <= '0';
ena_bl_re <= '0';
db_out_portC
db_out_portB
db_out_portA
<=
point_X_Y;
<= conv_std_logic_vector(conv_integer(point_Xp1_Y)
+ conv_integer(point_Xm1_Y) + conv_integer(ou_pre_green),12) (11 downto 4);
<= conv_std_logic_vector(conv_integer(point_Xp1_Ym1)
+ conv_integer(point_Xp1_Yp1) + conv_integer(ou_pre_bl_re),12) (11 downto 4);
when "11" =>
ena_green <= '1';
ena_bl_re <= '1';
db_out_portC
db_out_portB
db_out_portA
when "00" =>
ena_green <= '1';
ena_bl_re <= '1';
db_out_portC
db_out_portB
db_out_portA
-- red pixel - use 00 for RG_GB cameras
-- green 1 pixel - use 01 for RG_GB cameras
<= conv_std_logic_vector(conv_integer(point_Xm1_Y)
+ conv_integer(point_Xp1_Y), 11) (10 downto 3);
<=
point_X_Y;
<= conv_std_logic_vector(conv_integer(point_X_Ym1)
+ conv_integer(point_X_Yp1), 11) (10 downto 3);
-- green 2 pixel - use 10 for RG_GB cameras
<= conv_std_logic_vector(conv_integer(point_X_Ym1)
+ conv_integer(point_X_Yp1), 11) (10 downto 3);
<=
point_X_Y;
<= conv_std_logic_vector(conv_integer(point_Xm1_Y)
+ conv_integer(point_Xp1_Y), 11) (10 downto 3);
when "01" =>
-- blue pixel - use 11 for RG_GB cameras
ena_green <= '0';
ena_bl_re <= '0';
db_out_portC
<= conv_std_logic_vector(conv_integer(point_Xp1_Ym1)
+ conv_integer(point_Xp1_Yp1) + conv_integer(ou_pre_bl_re),12) (11 downto 4);
db_out_portB
<= conv_std_logic_vector(conv_integer(point_Xp1_Y)
+ conv_integer(point_Xm1_Y) + conv_integer(ou_pre_green),12) (11 downto 4);
db_out_portA
<=
point_X_Y;
end case;
end process;
It is not possible to apply the bilinear interpolation for the pixels in the border of
the frame, the Nearest Neighbour Replication will be used instead. Taking into
account, that the camera has a Bayer matrix of type GB_RG with an even
number of rows and columns, one pixel will be in the border of the frame if:
red
- is in the last row (493)
OR
is in the first column (0)
green_1
- is in the last row (493)
OR
is in the last column (655)
green_2
- is in the first row (0)
OR
is in the first column (0)
blue
- is in the first row (0)
OR
is in the last column (655)
4. Implementation
44
The basic interpolation process was modified to take this into account and use
the NNR for the border. It will be now:
when "10" =>
-- red pixel
ena_green
<= '0';
ena_bl_re
<= '0';
db_out_portC<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(493,9)
OR pix_col_Nr = conv_std_logic_vector(0,10) then
db_out_portB
<=
point_Xp1_Y (9 DOWNTO 2);
db_out_portA
<=
point_Xp1_Yp1 (9 DOWNTO 2);
else -- the general case
db_out_portB
<= conv_std_logic_vector(conv_integer(point_Xp1_Y)
+ conv_integer(point_Xm1_Y) + conv_integer(ou_pre_green), 12) (11 downto 4);
db_out_portA
<= conv_std_logic_vector(conv_integer(point_Xp1_Ym1)
+ conv_integer(point_Xp1_Yp1) + conv_integer(ou_pre_bl_re), 12) (11 downto 4);
end if;
when "11" =>
-- green 1 pixel
ena_green <= '1';
ena_bl_re <= '1';
db_out_portB<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(493,9)
OR pix_col_Nr = conv_std_logic_vector(655,10) then
db_out_portC
<=
point_Xm1_Y (9 DOWNTO 2);
db_out_portA
<=
point_Xm1_Yp1 (9 DOWNTO 2);
else -- the general case
db_out_portC
<= conv_std_logic_vector(conv_integer(point_Xm1_Y)
+ conv_integer(point_Xp1_Y), 11) (10 downto 3);
db_out_portA
<= conv_std_logic_vector(conv_integer(point_X_Ym1)
+ conv_integer(point_X_Yp1), 11) (10 downto 3);
end if;
when "00" =>
-- green 2 pixel
ena_green <= '1';
ena_bl_re <= '1';
db_out_portB<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(0,9)
OR pix_col_Nr = conv_std_logic_vector(0,10) then
db_out_portC
<=
point_X_Ym1 (9 DOWNTO 2);
db_out_portA
<=
point_Xm1_Y (9 DOWNTO 2);
else -- the general case
db_out_portC
<= conv_std_logic_vector(conv_integer(point_X_Ym1)
+ conv_integer(point_X_Yp1), 11) (10 downto 3);
db_out_portA
<= conv_std_logic_vector(conv_integer(point_Xm1_Y)
+ conv_integer(point_Xp1_Y), 11) (10 downto 3);
end if;
when "01" =>
-- blue pixel
ena_green <= '0';
ena_bl_re <= '0';
db_out_portA<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(0,9)
OR pix_col_Nr = conv_std_logic_vector(655,10) then
db_out_portC
<=
point_Xm1_Ym1 (9 DOWNTO 2);
db_out_portB
<=
point_Xm1_Y (9 DOWNTO 2);
else -- the general case
db_out_portC
<= conv_std_logic_vector(conv_integer(point_Xp1_Ym1)
+ conv_integer(point_Xp1_Yp1) + conv_integer(ou_pre_bl_re), 12) (11 downto 4);
db_out_portB
<= conv_std_logic_vector(conv_integer(point_Xp1_Y)
+ conv_integer(point_Xm1_Y) + conv_integer(ou_pre_green), 12) (11 downto 4);
end if;
c) retardo.vhd - provides the two pixel delay for LVAL and DVAL
d) retardo_FV.vhd - provides the two lines and two pixel delay for FVAL
The other files provide building blocks for the above mentioned VHDL files.
All the VHDL files can be found in the Appendix A.
CL_FG_CC1
CL_FG_CC2
CL_FG_CC3
CL_FG_CC4
CL_CM_SERTFG
CL_FG_SERTC
CL_in_data[9..0]
CL_RXCLK
CL_in_LVAL
CL_in_DVAL
CL_in_FVAL
Date: May 25, 2008
in_xVAL
in_rxclk
out_xVAL
retardo:ret_LVAL
buffer_in_data[9..0]
buffer_rxclk
buffer_in_LVAL_dlyd
buffer_in_LVAL
buffer_in_FVAL
pixel_line_ctr[8..0]
buffer_out_data_y_p1[9..0]
buffer_out_data_y[9..0]
buffer_out_data_y_m1[9..0]
Page 1 of 1
out_xVAL
pixel_line_ctr[8..0]
db_in_data_Y_p1[9..0]
db_in_data_Y[9..0]
debayer:debayer_1
out_xVAL
db_in_data_Y_m1[9..0]
db_rxclk
db_LVAL_dlyd
in_xVAL
in_rxclk
retardo:ret_CL_LVAL
in_xVAL
in_rxclk
retardo:ret_DVAL
in_RXCLK
in_LVAL
out_FVAL
retardo_FV:ret_FVAL
in_FVAL
Schematic of the top design entity
video_buffer:video_buffer_1
RTL Viewer
db_out_portC[7..0]
db_out_portB[7..0]
db_out_portA[7..0]
1
1
0
CL_out_TXCLK
CL_CM_CC1
CL_CM_CC2
CL_CM_CC3
CL_CM_CC4
CL_FG_SERTFG
CL_CM_SERTC
CL_out_portA[7..0]
CL_out_portB[7..0]
CL_out_portC[7..0]
CL_out_LVAL
CL_out_DVAL
CL_out_FVAL
CL_out_Spare
PW_dwn_A
PW_dwn_B
Revision: converter
Project: converter
4. Implementation
46
4.3 Testing of the prototype
The prototype was tested with the camera installed in the room 012, obtaining
the following pictures:
1) Raw image from the camera.
2) Image after the separation of the pixels by colour
3) Image after performing the colour bilinear interpolation.
4. Implementation
47
To obtain the test images, three different versions of the source file debayer.vhd
were created and used. They contain the following debayering logic:
1) This version just takes the values of the pixel coming from the buffer, and
delivers the information directly to the CameraLink output, without any
further processing. This is essentially the raw information coming from the
Bayer matrix. The capture program is set-up to receive information from a
grayscale camera, showing just the intensity of each pixel, disregarding the
fact that in the camera, the pixels have colour filters in front of them.
2) Knowing the value of the line and column counters, it is possible to know the
colour of the filter in front of the pixel being processed. This version uses this
knowledge to direct the stored value to the channel of the corresponding
colour in the CameraLink output. The other two channels are fed with value
“0”. This way, the pixels are “separated” by colour, as they are in the Bayer
matrix. The capture program is set-up to receive 24 bits RGB.
3) This is the complete version. When a pixel is processed, the stored value is
directed to the appropriate output channel, and the bilinear interpolation is
performed to calculate the values to feed the other two channels. The capture
program is set-up to receive 24 bits RGB.
Quality evaluation
To visually evaluate the quality of
the colour interpolation process,
several objects having different
colours
and
textures
were
disposed in front of the camera.
Although
the
band
limiting
nature
of
the
bilinear
interpolation process is prone to
produce artefacts, the observed
image quality is quite good.
4. Implementation
48
Also, as expressed in 2.3.3, the
fact
that
the
Smooth
Hue
Transition Interpolation requires
to
calculate
the
green values
before the red and blue ones,
makes the process difficult to
implement in hardware.
For this two reasons, it seems
reasonable to be satisfied with the
achieved quality.
The commercial frame grabbers that include the capability of performing the
debayering, usually also do it through the bilinear interpolation.
4. Implementation
49
Operating speed
The device operates at the normal pixel clock frequency of 43 MHz, and performs
the calculations with 10 bit precision. The capture software reports 94 frames/s.
The simulations performed with Quartus II allow to expect, that pixel clock
frequencies of up to 50 MHz should be possible. There where not performed
simulations
with
higher
frequencies.
The
transceivers
DS90CR285
and
DS90CR286 impose an absolute upper limit of 66 MHz.
4.4
Conclusions
This thesis has investigated the problem of interpolating the data coming from a
Bayer matrix camera at high frame rate. It has concluded that using hardwired
logic, it is possible to accomplish this task without loosing frames or introducing
a frame delay. The FPGA technology was selected for the implementation. While
the use of discrete logic would have produced a relatively big and expensive
device, a medium-sized FPGA includes almost all the necessary resources.
Instead of entering the design using the schematic capture tool available in the
development environment, the VHDL language was chosen. It was found that
VHDL allows a very efficient description of the hardware through a RTL model.
This allows a considerably faster development than the traditional methods.
As expressed in 3.1, the purpose of this work was not to produce a device
capable of being deployed in the factory floor. It is just to build a proof-of-concept
device, in order to investigate this technology.
Future work about this topic should include:
● Develop a PCIe frame grabber, using a PCIe FPGA development board or
building the board itself, but using a FPGA module like the Firefly. This
would make the mechanical construction easier.
● Investigate the possibility of also performing the conversion from RGB to
HSV, through heavy pipelining of the conversion algorithm. In machine
vision applications, the HSV colour space allows a better manipulation of
the information.
Bibliography
[1] The CameraLink committee. Camera Link Interface Standard for Digital Cameras and
Frame Grabbers. October 2000.
[2] SVS-Vistek GmbH. Digital Progressive Area Scan Camera SVCam User`s Manual v.1.6.
May 2003.
[3] ARVOO. Leonardo PCI 64-CL CameraLink interface User`s Manual rev. B 1.2. 2002.
[4] Microtronix. Cyclone Firefly PSK Dev. kit User`s Manual rev.1.1. July 2006.
[5] devboards GmbH. DBCMLKIN and DBCMLKOUT Santa Cruz add on boards Datasheet
v.2.0. June 2006.
[6] National Semiconductor. DS90CR85/DS90CR86 LVDS 28-Bit Channel Link Datasheet.
July 2004.
[7] ALTERA Corporation. Cyclone Device Handbook. January 2007.
[8] ALTERA Corporation. Quartus II Version 6.1 Handbook. November 2006.
[9] J.Hamblen, T.Hall, M.Furman. Rapid prototyping of digital systems, Quartus II Edition.
2006.
[10] SYNARIO Design Automation. VHDL Reference Manual. March 1997.
[11] Ramanath, Rajeev. Interpolation Methods for the Bayer Color Array. 2000.
[12] SONY. ICX424AQ - Pogressive Scan CCD Image Sensor - Data Sheet.
[13] J.Foley, A.van Dam, S.Feiner, J. Hughes – Computer Graphics. July 1997.
Pictures
[pag.
[pag.
[pag.
[pag.
[pag.
[pag.
[pag.
[pag.
4, 5]
6]
13]
20, 21]
27]
28]
31, 32]
34]
loop technology - www.looptechnology.com
Hi-Tech Electronics – www.hitech.com.sg
based on ref [13]
ref. [7]
SVS-Vistek GmbH - www.vistek.de
Monthly “Elektronik”, August 2002 (modified)
ref. [4], in pag. 32 only the block diagram
ref. [8]
Appendix A
VHDL listings
converter.vhd
video_buffer.vhd
debayer.vhd
retardo.vhd
retardo_FV.vhd
line_buffer.vhd
fsd.vhd
bsm.vhd
lin_cntr_fsd
lin_cntr_bsm
col_cntr.vhd
col_cntr_re.vhd
dff_8.vhd
dff_9en.vhd
dff_ck0.vhd
-- ============================================================
--- File Name: converter.vhd
--- ============================================================
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY converter IS
PORT
(
CL_RXCLK
: IN STD_LOGIC;
CL_out_TXCLK: OUT STD_LOGIC;
CL_in_data
CL_out_portA
CL_out_portB
CL_out_portC
:
:
:
:
CL_in_LVAL
CL_out_LVAL
: IN STD_LOGIC;
: OUT STD_LOGIC;
-- line valid
CL_in_FVAL
CL_out_FVAL
: IN STD_LOGIC;
: OUT STD_LOGIC;
-- field valid
CL_in_DVAL
CL_out_DVAL
: IN STD_LOGIC;
: OUT STD_LOGIC;
-- data valid
CL_out_Spare
: OUT STD_LOGIC;
-- the spare output signal must be tied to 0
CL_FG_CC1
CL_FG_CC2
CL_FG_CC3
CL_FG_CC4
CL_CM_CC1
CL_CM_CC2
CL_CM_CC3
CL_CM_CC4
:
:
:
:
:
:
:
:
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
IN STD_LOGIC;
IN STD_LOGIC;
IN STD_LOGIC;
IN STD_LOGIC;
OUT STD_LOGIC;
OUT STD_LOGIC;
OUT STD_LOGIC;
OUT STD_LOGIC;
-- The 3 out_data ports
-- the camera control signals
CL_FG_SERTFG: OUT STD_LOGIC;
CL_CM_SERTFG: IN STD_LOGIC;
CL_FG_SERTC : IN STD_LOGIC;
CL_CM_SERTC : OUT STD_LOGIC;
-- serial communication
PW_dwn_A
PW_dwn_B
-- power down for the santa cruz boards
: OUT STD_LOGIC;
: OUT STD_LOGIC
);
END converter;
ARCHITECTURE estructura OF converter IS
-- Declare internal signals needed to connect submodules
SIGNAL buf_dat_Y_m1
SIGNAL buf_dat_Y
SIGNAL buf_dat_Y_p1
: STD_LOGIC_VECTOR (9 DOWNTO 0);
: STD_LOGIC_VECTOR (9 DOWNTO 0);
: STD_LOGIC_VECTOR (9 DOWNTO 0);
SIGNAL RXCLK
SIGNAL LVAL_dlyd
: STD_LOGIC;
: STD_LOGIC;
SIGNAL pixel_line_Nr
SIGNAL pixel_col_Nr
: std_logic_vector(8 DOWNTO 0);
: std_logic_vector(9 DOWNTO 0);
SIGNAL
SIGNAL
SIGNAL
SIGNAL
:
:
:
:
CC1
CC2
CC3
CC4
SIGNAL SERTFG
SIGNAL SERTC
STD_LOGIC;
STD_LOGIC;
STD_LOGIC;
STD_LOGIC;
: STD_LOGIC;
: STD_LOGIC;
-- Use Components to define submodules and parameters
component video_buffer
PORT
(
buffer_rxclk
: IN STD_LOGIC;
buffer_in_data
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
buffer_out_data_y_m1
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
buffer_out_data_y
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
buffer_out_data_y_p1
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
buffer_in_LVAL
: IN STD_LOGIC;
buffer_in_LVAL_dlyd
: IN STD_LOGIC;
buffer_in_FVAL
: IN STD_LOGIC;
pixel_line_ctr
: OUT std_logic_vector(8 DOWNTO 0)
);
-- line
-- line
-- line
y - 1
y
y + 1
-- line of pixel being debayered
end component;
component debayer
PORT
(
db_rxclk
db_in_data_Y_m1
db_in_data_Y
db_in_data_Y_p1
db_out_portA
db_out_portB
db_out_portC
pixel_line_ctr
db_LVAL_dlyd
);
end component;
component retardo
PORT
(
in_rxclk
in_xVAL
out_xVAL
);
end component;
:
:
:
:
:
:
:
:
:
IN STD_LOGIC;
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
IN std_logic_vector(8 DOWNTO 0); -- line of pixel being debayered
IN STD_LOGIC
IS
: IN STD_LOGIC;
: IN STD_LOGIC;
: OUT STD_LOGIC
component retardo_FV IS
PORT
(
in_rxclk
: IN STD_LOGIC;
in_LVAL
: IN STD_LOGIC;
in_FVAL
: IN STD_LOGIC;
out_FVAL
: OUT STD_LOGIC
);
end component;
BEGIN
video_buffer_1 : video_buffer
buffer_rxclk
buffer_in_data
buffer_out_data_y_m1
buffer_out_data_y
buffer_out_data_y_p1
buffer_in_LVAL
buffer_in_LVAL_dlyd
buffer_in_FVAL
pixel_line_ctr
);
debayer_1 : debayer
db_rxclk
db_in_data_Y_m1
db_in_data_Y
db_in_data_Y_p1
db_out_portA
db_out_portB
db_out_portC
pixel_line_ctr
db_LVAL_dlyd
);
PORT
=>
=>
=>
=>
=>
=>
=>
=>
=>
MAP (
RXCLK,
CL_in_data,
buf_dat_Y_m1,
buf_dat_Y,
buf_dat_Y_p1,
CL_in_LVAL,
LVAL_dlyd,
CL_in_FVAL,
pixel_line_Nr
PORT MAP (
=>
RXCLK,
=>
buf_dat_Y_m1,
=>
buf_dat_Y,
=>
buf_dat_Y_p1,
=>
CL_out_portA,
=>
CL_out_portB,
=>
CL_out_portC,
=>
pixel_line_Nr,
=>
LVAL_dlyd
-- delayed LVAL
ret_LVAL : retardo PORT MAP (
in_rxclk => RXCLK,
in_xVAL => CL_in_LVAL, out_xVAL => LVAL_dlyd
);
-- delayed CL_out_LVAL
ret_CL_LVAL : retardo PORT MAP (
in_rxclk => RXCLK,
in_xVAL => CL_in_LVAL, out_xVAL => CL_out_LVAL
);
-- delayed DVAL
ret_DVAL : retardo PORT MAP (
in_rxclk => RXCLK,
in_xVAL => CL_in_DVAL, out_xVAL => CL_out_DVAL
);
-- delayed FVAL
ret_FVAL : retardo_FV PORT MAP (
in_rxclk => RXCLK, in_LVAL =>CL_in_LVAL,
in_FVAL => CL_in_FVAL, out_FVAL => CL_out_FVAL
);
-- output line Y-1
-- output line Y
-- output line Y+1
-- line of pixel being debayered
-- line of pixel being debayered
RXCLK <= CL_RXCLK;
CL_out_TXCLK <= RXCLK;
-- the camera control signals
CC1
<=
CL_FG_CC1;
CC2
<=
CL_FG_CC2;
CC3
<=
CL_FG_CC3;
CC4
<=
CL_FG_CC4;
CL_CM_CC1
<=
CC1;
CL_CM_CC2
<=
CC2;
CL_CM_CC3
<=
CC3;
CL_CM_CC4
<=
CC4;
CL_FG_SERTFG
SERTFG
SERTC
CL_CM_SERTC
PW_dwn_A
PW_dwn_B
<=
<=
<=
<=
SERTFG;
CL_CM_SERTFG;
CL_FG_SERTC;
SERTC;
<= '1';
<= '1';
-- serial communication
-- power down for the santa cruz boards
CL_out_Spare <= '0';
-- spare connected to 0, required by the transceiver DS90CR285
END estructura;
-- ============================================================
--- File Name: video_buffer.vhd
--- ============================================================
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
USE ieee.std_logic_arith.all;
ENTITY video_buffer IS
PORT
(
buffer_rxclk
buffer_in_data
buffer_out_data_y_m1
buffer_out_data_y
buffer_out_data_y_p1
buffer_in_LVAL
buffer_in_LVAL_dlyd
buffer_in_FVAL
pixel_line_ctr
);
END video_buffer;
:
:
:
:
:
IN STD_LOGIC;
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
: IN STD_LOGIC;
: IN STD_LOGIC;
: IN STD_LOGIC;
-- line
-- line
-- line
y - 1
y
y + 1
-- the delayed LVAL
: OUT std_logic_vector (8 DOWNTO 0)
-- line of pixel debayered
ARCHITECTURE struct_video OF video_buffer IS
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
col_count
line_count_fsd
line_count_bsm
wr_ena
buflin_0
buflin_1
buflin_2
buflin_3
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
(9
(1
(8
(3
(9
(9
(9
(9
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
0);
0);
0);
0);
0);
0);
0);
0);
component line_buffer
PORT
(
clock
: IN STD_LOGIC ;
data
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
rdaddress : IN STD_LOGIC_VECTOR (9 DOWNTO 0);
wraddress : IN STD_LOGIC_VECTOR (9 DOWNTO 0);
wren
: IN STD_LOGIC;
q
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0)
);
end component;
-- write enables for the line buffers
component coln_cntr
-- column counter
PORT
(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(9 DOWNTO 0)
);
end component;
component lin_cntr_fsd
-- line counter FSD
PORT
(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(1 DOWNTO 0)
);
end component;
component lin_cntr_bsm
-- line counter BSM
PORT
(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(8 DOWNTO 0)
);
end component;
component FSD
PORT
(
line_addr
wr_en
xVAL
);
end component;
-- Front Side Demultiplexer
component BSM
PORT
(
line_addr
buf_in_0
buf_in_1
buf_in_2
buf_in_3
row_y_m1
row_y
row_y_p1
);
end component;
-- Back Side Multiplexer
: IN STD_LOGIC_VECTOR (1 DOWNTO 0);
: OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
: IN STD_LOGIC
:
:
:
:
:
:
:
:
IN STD_LOGIC_VECTOR (1 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0)
BEGIN
line_buffer_0 : line_buffer PORT MAP (
clock
=> buffer_rxclk,
data
=> buffer_in_data,
rdaddress => col_count,
wraddress => col_count,
wren
=> wr_ena(0),
q
=> buflin_0
);
line_buffer_1 : line_buffer PORT MAP (
clock
=> buffer_rxclk,
data
=> buffer_in_data,
rdaddress => col_count,
wraddress => col_count,
wren
=> wr_ena(1),
q
=> buflin_1
);
line_buffer_2 : line_buffer PORT MAP (
clock
=> buffer_rxclk,
data
=> buffer_in_data,
rdaddress => col_count,
wraddress => col_count,
wren
=> wr_ena(2),
q
=> buflin_2
);
line_buffer_3 : line_buffer PORT MAP (
clock
=> buffer_rxclk,
data
=> buffer_in_data,
rdaddress => col_count,
wraddress => col_count,
wren
=> wr_ena(3),
q
=> buflin_3
--conv_std_logic_vector(0,10),
);
column_cntr : coln_cntr PORT MAP (
Clock
=> buffer_rxclk,
Reset
=> buffer_in_LVAL,
count
=> col_count
);
-- resets column counter when the line is not valid
line_cntr_fsd : lin_cntr_fsd PORT MAP (
Clock
=> buffer_in_LVAL,
Reset
=> buffer_in_FVAL,
count
=> line_count_fsd
);
-- resets line counter when the field is not valid
FSD_1 :
FSD
line_addr
wr_en
xVAL
);
PORT MAP (
=> line_count_fsd (1 DOWNTO 0),
=> wr_ena,
=> buffer_in_LVAL
line_cntr_bsm : lin_cntr_bsm PORT MAP (
Clock
=> buffer_in_LVAL_dlyd,
Reset
=> buffer_in_FVAL,
-- resets line counter when the field is not valid
count
=> line_count_bsm
);
BSM_1 :
BSM
line_addr
buf_in_0
buf_in_1
buf_in_2
buf_in_3
row_y_m1
row_y
row_y_p1
);
PORT MAP (
=> line_count_bsm (1 DOWNTO 0),
=>
buflin_0,
=>
buflin_1,
=>
buflin_2,
=>
buflin_3,
=>
buffer_out_data_y_m1,
=>
buffer_out_data_y,
=>
buffer_out_data_y_p1
pixel_line_ctr
<=
END struct_video;
line_count_bsm;
-- ============================================================
--- File Name: debayer.vhd
--- ============================================================
-- Performs the debayering and colour space conversion
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE IEEE.STD_LOGIC_ARITH.all;
USE IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debayer IS
PORT
(
db_rxclk
: IN STD_LOGIC;
db_in_data_Y_m1
db_in_data_Y
db_in_data_Y_p1
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
db_out_portA
db_out_portB
db_out_portC
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
pixel_line_ctr
: IN std_logic_vector(8 DOWNTO 0); -- line of pixel being debayered
db_LVAL_dlyd
);
END debayer;
: IN STD_LOGIC
ARCHITECTURE dbayer_struct OF debayer IS
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
SIGNAL
point_Xp1_Ym1
point_Xp1_Y
point_Xp1_Yp1
point_X_Ym1
point_X_Y
point_X_Yp1
point_Xm1_Ym1
point_Xm1_Y
point_Xm1_Yp1
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
:STD_LOGIC_VECTOR
(9
(9
(9
(9
(9
(9
(9
(9
(9
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
DOWNTO
0);
0);
0);
0);
0);
0);
0);
0);
0);
-- the points in the column X+1,
-comming from the video buffer
-- the points in the column X
-- the points in the column X-1
SIGNAL pix_line_Nr
SIGNAL pix_col_Nr
: std_logic_vector (8 DOWNTO 0);
: std_logic_vector (9 DOWNTO 0);
-- position of the pixel
-being debayered now
SIGNAL in_pre_green
SIGNAL ou_pre_green
SIGNAL ena_green
: std_logic_vector (10 DOWNTO 0);
: std_logic_vector (10 DOWNTO 0);
: std_logic;
-- signals for preaddition of
-- the green component
SIGNAL in_pre_bl_re
SIGNAL ou_pre_bl_re
SIGNAL ena_bl_re
: std_logic_vector (10 DOWNTO 0);
: std_logic_vector (10 DOWNTO 0);
: std_logic;
-- signals for preaddition of
-- the blue or red component
component dff_8
(
d
clk
q
);
end component;
port
component dff_9en
(
d
clk
enable
q
);
end component;
port
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
: in std_logic;
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0)
:
:
:
:
IN STD_LOGIC_VECTOR (10 DOWNTO 0);
in std_logic;
in std_logic;
OUT STD_LOGIC_VECTOR (10 DOWNTO 0)
component coln_cntr_re
-- column counter
PORT
(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(9 DOWNTO 0)
);
end component;
BEGIN
-- these are the registers that store the values of columns X and X-1
DFF_X_Y_m1 : DFF_8 PORT MAP (
d => point_Xp1_Ym1, q => point_X_Ym1,
clk => db_rxclk
);
-- point (X, Y-1) register
DFF_X_m1_Y_m1 : DFF_8 PORT MAP (
d => point_X_Ym1, q => point_Xm1_Ym1,
clk => db_rxclk
);
-- point (X-1, Y-1) register
DFF_X_Y : DFF_8 PORT MAP (
d => point_Xp1_Y, q => point_X_Y,
clk => db_rxclk
);
-- point (X, Y) register
DFF_X_m1_Y : DFF_8 PORT MAP (
d => point_X_Y, q => point_Xm1_Y,
clk => db_rxclk
);
-- point (X-1, Y) register
DFF_X_Y_p1 : DFF_8 PORT MAP (
d => point_Xp1_Yp1, q => point_X_Yp1,
clk => db_rxclk
);
-- point (X, Y+1) register
DFF_X_m1_Y_p1 : DFF_8 PORT MAP (
d => point_X_Yp1, q => point_Xm1_Yp1,
clk => db_rxclk
);
-- point (X-1, Y+1) register
column_cntr_dby : coln_cntr_re PORT MAP (
-- column counter for the debayering
Clock => db_rxclk,
Reset => db_LVAL_dlyd,
-- resets column counter when the line is not valid
count => pix_col_Nr
);
green_DFF : dff_9en PORT MAP (
-- stores the pre-addition of the green component
d => in_pre_green, q => ou_pre_green,
clk => db_rxclk, enable => ena_green
);
az_bl_re_DFF : dff_9en PORT MAP (
-- stores the pre-addition of the blue or red component
d => in_pre_bl_re, q => ou_pre_bl_re,
clk => db_rxclk, enable => ena_bl_re
);
PROCESS (pix_line_Nr, pix_col_Nr, point_Xp1_Ym1, point_Xp1_Y, point_Xp1_Yp1, point_X_Ym1, point_X_Y, point_X_Yp1,
point_Xm1_Ym1, point_Xm1_Y, point_Xm1_Yp1,
ou_pre_green, ou_pre_bl_re)
BEGIN
case pix_line_Nr(0 downto 0) & pix_col_Nr(0 downto 0) is
when "10" =>
-- red pixel
ena_green
<= '0';
ena_bl_re
<= '0';
db_out_portC
<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(493,9)
OR pix_col_Nr = conv_std_logic_vector(0,10) then
db_out_portB
<=
point_Xp1_Y (9 DOWNTO 2);
db_out_portA
<=
point_Xp1_Yp1 (9 DOWNTO 2);
else -- the general case
db_out_portB
<= conv_std_logic_vector(conv_integer(point_Xp1_Y)
+ conv_integer(point_Xm1_Y) + conv_integer(ou_pre_green), 12) (11 downto 4);
db_out_portA
<= conv_std_logic_vector(conv_integer(point_Xp1_Ym1)
+ conv_integer(point_Xp1_Yp1) + conv_integer(ou_pre_bl_re), 12) (11 downto 4);
end if;
when "11" =>
-- green 1 pixel
ena_green <= '1';
ena_bl_re <= '1';
db_out_portB
<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(493,9)
OR pix_col_Nr = conv_std_logic_vector(655,10) then
db_out_portC
<=
point_Xm1_Y (9 DOWNTO 2);
db_out_portA
<=
point_Xm1_Yp1 (9 DOWNTO 2);
else -- the general case
db_out_portC
<= conv_std_logic_vector(conv_integer(point_Xm1_Y)
+ conv_integer(point_Xp1_Y), 11) (10 downto 3);
db_out_portA
<= conv_std_logic_vector(conv_integer(point_X_Ym1)
+ conv_integer(point_X_Yp1), 11) (10 downto 3);
end if;
when "00" =>
-- green 2 pixel
ena_green <= '1';
ena_bl_re <= '1';
db_out_portB
<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(0,9)
OR pix_col_Nr = conv_std_logic_vector(0,10) then
db_out_portC
<=
point_X_Ym1 (9 DOWNTO 2);
db_out_portA
<=
point_Xm1_Y (9 DOWNTO 2);
else -- the general case
db_out_portC
<= conv_std_logic_vector(conv_integer(point_X_Ym1)
+ conv_integer(point_X_Yp1), 11) (10 downto 3);
db_out_portA
<= conv_std_logic_vector(conv_integer(point_Xm1_Y)
+ conv_integer(point_Xp1_Y), 11) (10 downto 3);
end if;
when "01" =>
-- blue pixel
ena_green <= '0';
ena_bl_re <= '0';
db_out_portA
<=
point_X_Y (9 DOWNTO 2);
-- check for the edge of image condition
if pix_line_Nr = conv_std_logic_vector(0,9)
OR pix_col_Nr = conv_std_logic_vector(655,10) then
db_out_portC
<=
point_Xm1_Ym1 (9 DOWNTO 2);
db_out_portB
<=
point_Xm1_Y (9 DOWNTO 2);
else -- the general case
db_out_portC
<= conv_std_logic_vector(conv_integer(point_Xp1_Ym1)
+ conv_integer(point_Xp1_Yp1) + conv_integer(ou_pre_bl_re), 12) (11 downto 4);
db_out_portB
<= conv_std_logic_vector(conv_integer(point_Xp1_Y)
+ conv_integer(point_Xm1_Y) + conv_integer(ou_pre_green), 12) (11 downto 4);
end if;
end case;
end process;
-- pre-addition of the components
in_pre_green <= conv_std_logic_vector(conv_integer(point_Xp1_Ym1) + conv_integer(point_Xp1_Yp1), 11) (10 downto 0);
in_pre_bl_re <= conv_std_logic_vector(conv_integer(point_X_Ym1) + conv_integer(point_X_Yp1), 11) (10 downto 0);
-- Interconnections
point_Xp1_Ym1
point_Xp1_Y
point_Xp1_Yp1
<=
<=
<=
db_in_data_Y_m1;
db_in_data_Y;
db_in_data_Y_p1;
-- input signals from video buffer
pix_line_Nr
<=
pixel_line_ctr;
-- line of pixel being debayered now
END dbayer_struct;
-- ============================================================
--- File Name: retardo.vhd
--- ============================================================
-- delays the xVAL two pixel
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY retardo IS
PORT
(
in_rxclk
in_xVAL
out_xVAL
);
END retardo;
: IN STD_LOGIC;
: IN STD_LOGIC;
: OUT STD_LOGIC
ARCHITECTURE estruct_R OF retardo IS
-- Declare internal signals needed to connect submodules
SIGNAL out_DFF_1 : STD_LOGIC;
SIGNAL out_DFF_2 : STD_LOGIC;
component dff_ck0 port(
d, clk : in std_logic;
q
: out std_logic);
end component;
component dff
port(
d, clk, clrn, prn :
q
:
end component;
in std_logic;
out std_logic);
BEGIN
DFF_1_xVAL : dff PORT MAP (
d => in_xVAL, q => out_DFF_1,
clk => in_rxclk, clrn => '1', prn => '1'
);
DFF_2_xVAL : dff_ck0 PORT MAP (
d => out_DFF_1, q => out_DFF_2,
clk => in_rxclk
);
DFF_3_xVAL : dff_ck0 PORT MAP (
d => out_DFF_2, q => out_xVAL,
clk => in_rxclk
);
END estruct_R;
-- ============================================================
--- File Name: retardo_FV.vhd
--- ============================================================
-- delays the FVAL two lines and two pixel
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY retardo_FV IS
PORT
(
in_RXCLK
in_LVAL
in_FVAL
out_FVAL
);
END retardo_FV;
:
:
:
:
IN STD_LOGIC;
IN STD_LOGIC;
IN STD_LOGIC;
OUT STD_LOGIC
ARCHITECTURE estruct_R OF retardo_FV IS
-- Declare internal signals needed to connect submodules
SIGNAL out_DFF_1 : STD_LOGIC;
SIGNAL out_DFF_2 : STD_LOGIC;
SIGNAL out_DFF_3 : STD_LOGIC;
component dff_ck0 port(
d, clk
: in std_logic;
q
: out std_logic);
end component;
component dff
port(
d, clk, clrn, prn :
q
:
end component;
component retardo
PORT
(
in_rxclk
in_xVAL
in_clrn
out_xVAL
);
end component;
in std_logic;
out std_logic);
IS
:
:
:
:
IN STD_LOGIC;
IN STD_LOGIC;
IN STD_LOGIC;
OUT STD_LOGIC
BEGIN
DFF_1_xVAL : dff_ck0 PORT MAP (
d => in_FVAL, q => out_DFF_1,
clk => in_LVAL
);
DFF_2_xVAL : dff PORT MAP (
d => out_DFF_1, q => out_DFF_2,
clk => in_LVAL, clrn => '1', prn => '1'
);
DFF_3_xVAL : dff PORT MAP (
d => out_DFF_2, q => out_FVAL, --out_DFF_3,
clk => in_LVAL, clrn => '1', prn => '1'
);
-- two clock cycles delay for FVAL -use if necessary
--ret_FVAL : retardo PORT MAP (
-in_rxclk => in_RXCLK,
-in_xVAL => out_DFF_3, in_clrn => '1', out_xVAL => out_FVAL
--);
END estruct_R;
-----
megafunction wizard: %RAM: 2-PORT%
GENERATION: STANDARD
VERSION: WM1.0
MODULE: altsyncram
--------------
============================================================
File Name: line_buffer.vhd
Megafunction Name(s):
altsyncram
Simulation Library Files(s):
altera_mf
============================================================
************************************************************
THIS IS A WIZARD-GENERATED FILE. DO NOT EDIT THIS FILE!
6.1 Build 201 11/27/2006 SJ Web Edition
************************************************************
LIBRARY ieee;
USE ieee.std_logic_1164.all;
LIBRARY altera_mf;
USE altera_mf.all;
ENTITY line_buffer IS
PORT
(
clock
data
rdaddress
wraddress
wren
q
);
END line_buffer;
: IN STD_LOGIC ;
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
: IN STD_LOGIC := '1';
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0)
ARCHITECTURE SYN OF line_buffer IS
SIGNAL sub_wire0
: STD_LOGIC_VECTOR (9 DOWNTO 0);
COMPONENT altsyncram
GENERIC (
address_aclr_a
: STRING;
address_aclr_b
: STRING;
address_reg_b
: STRING;
indata_aclr_a
: STRING;
intended_device_family : STRING;
lpm_type
: STRING;
numwords_a
: NATURAL;
numwords_b
: NATURAL;
operation_mode
: STRING;
outdata_aclr_b
: STRING;
outdata_reg_b
: STRING;
power_up_uninitialized
: STRING;
read_during_write_mode_mixed_ports
: STRING;
widthad_a
: NATURAL;
widthad_b
: NATURAL;
width_a
: NATURAL;
width_b
: NATURAL;
width_byteena_a
: NATURAL;
wrcontrol_aclr_a
: STRING
);
PORT (
wren_a
: IN STD_LOGIC ;
clock0
: IN STD_LOGIC ;
address_a
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
address_b
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
q_b
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
data_a
: IN STD_LOGIC_VECTOR (9 DOWNTO 0)
);
END COMPONENT;
BEGIN
q
<= sub_wire0(9 DOWNTO 0);
altsyncram_component : altsyncram
GENERIC MAP (
address_aclr_a => "NONE",
address_aclr_b => "NONE",
address_reg_b => "CLOCK0",
indata_aclr_a => "NONE",
intended_device_family => "Cyclone",
lpm_type => "altsyncram",
numwords_a => 658,
numwords_b => 658,
operation_mode => "DUAL_PORT",
outdata_aclr_b => "NONE",
outdata_reg_b => "UNREGISTERED",
power_up_uninitialized => "FALSE",
read_during_write_mode_mixed_ports => "DONT_CARE",
widthad_a => 10,
widthad_b => 10,
width_a => 10,
width_b => 10,
width_byteena_a => 1,
wrcontrol_aclr_a => "NONE"
)
PORT MAP (
wren_a => wren,
clock0 => clock,
address_a => wraddress,
address_b => rdaddress,
data_a => data,
q_b => sub_wire0
);
END SYN;
-- ============================================================
--- File Name: fsd.vhd
--- ============================================================
-- This decoder implements the functionality of the Front Side Demultiplexer FSD
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY FSD IS
PORT
(
line_addr
wr_en
xVAL
);
END FSD;
: IN STD_LOGIC_VECTOR (1 DOWNTO 0);
: OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
: IN STD_LOGIC
ARCHITECTURE struct_fsd OF FSD IS
BEGIN
PROCESS (line_addr, xVAL)
BEGIN
if xVAL = '1' then
case line_addr is
when "00" => wr_en <= "0001";
when "01" => wr_en <= "0010";
when "10" => wr_en <= "0100";
when "11" => wr_en <= "1000";
end case;
else
wr_en <= "0000";
end if;
end process;
END struct_fsd;
-- none of the line buffers is enabled for write
-- ============================================================
--- File Name: bsm.vhd
--- ============================================================
-- This file implements the functionality of the Back Side Multiplexer BSM
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY BSM IS
PORT
(
line_addr
buf_in_0
buf_in_1
buf_in_2
buf_in_3
row_y_m1
row_y
row_y_p1
);
END BSM;
:
:
:
:
:
:
:
:
IN STD_LOGIC_VECTOR (1 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
IN STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0);
OUT STD_LOGIC_VECTOR (9 DOWNTO 0)
ARCHITECTURE struct_bsm OF BSM IS
BEGIN
PROCESS (line_addr, buf_in_0,
BEGIN
case line_addr is
when "00" =>
row_y_m1
row_y
row_y_p1
END struct_bsm;
<= buf_in_1;
<= buf_in_2;
<= buf_in_3;
when "01" =>
row_y_m1
row_y
row_y_p1
<= buf_in_2;
<= buf_in_3;
<= buf_in_0;
when "10" =>
row_y_m1
row_y
row_y_p1
<= buf_in_3;
<= buf_in_0;
<= buf_in_1;
when "11" =>
row_y_m1
row_y
row_y_p1
<= buf_in_0;
<= buf_in_1;
<= buf_in_2;
end case;
end process;
buf_in_1, buf_in_2, buf_in_3)
-- ============================================================
--- File Name: lin_cntr_fsd.vhd
--- ============================================================
-- line counter for the FSD
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.all;
USE IEEE.STD_LOGIC_ARITH.all;
USE IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY lin_cntr_fsd IS
PORT(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(1 DOWNTO 0));
END lin_cntr_fsd;
ARCHITECTURE behavior OF lin_cntr_fsd IS
-- declare signal internal to module here
SIGNAL internal_count: std_logic_vector(1 DOWNTO 0);
BEGIN
count <= internal_count;
PROCESS (Reset,Clock)
BEGIN
-- reset counter
IF reset = '0' THEN
internal_Count <= "00";
ELSIF (clock'EVENT and clock='0') THEN
-- Check for maximum count = 3,
-- we are only interested for the line in the buffer
IF internal_count < conv_std_logic_vector(3,2) THEN
-- Increment Counter
internal_count <= internal_count + 1;
-- Count >= Max_Count so reset Counter
ELSE
internal_Count <= "00";
END IF;
END IF;
END PROCESS;
END behavior;
-- ============================================================
--- File Name: lin_cntr_bsm.vhd
--- ============================================================
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.all;
USE IEEE.STD_LOGIC_ARITH.all;
USE IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY lin_cntr_bsm IS
PORT(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(8 DOWNTO 0));
END lin_cntr_bsm;
ARCHITECTURE behavior OF lin_cntr_bsm IS
-- declare signal internal to module here
SIGNAL internal_count: std_logic_vector(8 DOWNTO 0);
BEGIN
count <= internal_count;
PROCESS (Reset,Clock)
BEGIN
-- reset counter
IF reset = '0' THEN
internal_Count <= "000000000";
ELSIF (clock'EVENT and clock='0') THEN
-- Check for maximum count = 494 lines
IF internal_count < conv_std_logic_vector(493,9) THEN
-- Increment Counter
internal_count <= internal_count + 1;
-- Count >= Max_Count so reset Counter
ELSE
internal_Count <= "000000000";
END IF;
END IF;
END PROCESS;
END behavior;
-- ============================================================
--- File Name: col_cntr.vhd
--- ============================================================
-- Implements a column counter that increments with the falling edge of the clock
-- and after being asynchronous reseted, the reset can finish only syncrhonously
-- with the rising edge of the clock
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.all;
USE IEEE.STD_LOGIC_ARITH.all;
USE IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY coln_cntr IS
PORT(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(9 DOWNTO 0));
END coln_cntr;
ARCHITECTURE behavior OF coln_cntr IS
-- declare signal internal to module here
SIGNAL internal_count : std_logic_vector(9 DOWNTO 0);
SIGNAL reset_inter : STD_LOGIC;
component dff
port(
d, clk, clrn, prn :
q
:
end component;
in std_logic;
out std_logic);
BEGIN
count <= internal_count;
-- this FF makes sure, that the reseted column counter remains in '0',
-even if 'Reset' goes to '1' a little earlier than the falling edge of 'Clock'
DFF_Reset : dff PORT MAP (
d => Reset, q => reset_inter,
clk => Clock, clrn => Reset, prn => '1'
);
PROCESS (reset_inter,Clock)
BEGIN
-- reset counter
IF reset_inter = '0' THEN
internal_Count <= "0000000000";
ELSIF (clock'EVENT and clock='0') THEN
-- Check for maximum count = 656 columns
IF internal_count < conv_std_logic_vector(655,10) THEN
-- Increment Counter
internal_count <= internal_count + 1;
-- Count >= Max_Count so reset Counter
ELSE
internal_Count <= "0000000000";
END IF;
END IF;
END PROCESS;
END behavior;
-- ============================================================
--- File Name: col_cntr_re.vhd
--- ============================================================
-- Implements a column counter that increments with the rising edge of the clock
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.all;
USE IEEE.STD_LOGIC_ARITH.all;
USE IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY coln_cntr_re IS
PORT(
-- Input Signals
Clock, Reset
: IN std_logic;
-- Output Signals
count
: OUT std_logic_vector(9 DOWNTO 0));
END coln_cntr_re;
ARCHITECTURE behavior OF coln_cntr_re IS
-- declare signal internal to module here
SIGNAL internal_count: std_logic_vector(9 DOWNTO 0);
BEGIN
count <= internal_count;
PROCESS (Reset,Clock)
BEGIN
-- reset counter
IF reset = '0' THEN
internal_Count <= "0000000000";
ELSIF (clock'EVENT and clock='1') THEN
-- Check for maximum count = 656 columns
IF internal_count < conv_std_logic_vector(655,10) THEN
-- Increment Counter
internal_count <= internal_count + 1;
-- Count >= Max_Count so reset Counter
ELSE
internal_Count <= "0000000000";
END IF;
END IF;
END PROCESS;
END behavior;
-- ============================================================
--- File Name: dff_8.vhd
--- ============================================================
-- implements a 10-bit D-register
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY dff_8 IS
PORT
(
d
clk
q
);
END dff_8;
: IN STD_LOGIC_VECTOR (9 DOWNTO 0);
: in std_logic;
: OUT STD_LOGIC_VECTOR (9 DOWNTO 0)
ARCHITECTURE estruct_dff_8 OF dff_8 IS
BEGIN
PROCESS
BEGIN
WAIT UNTIL (clk 'event and clk='1');
q
<= d;
END PROCESS;
END estruct_dff_8;
-- ============================================================
--- File Name: dff_9en.vhd
--- ============================================================
-- implements a 11-bit D-register with enable
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY dff_9en IS
PORT
(
d
clk
enable
q
);
END dff_9en;
:
:
:
:
IN STD_LOGIC_VECTOR (10 DOWNTO 0);
in std_logic;
in std_logic;
OUT STD_LOGIC_VECTOR (10 DOWNTO 0)
ARCHITECTURE estruct_dff_9 OF dff_9en IS
BEGIN
PROCESS
BEGIN
WAIT UNTIL (clk 'event and clk='1');
IF enable = '1' then
q
<= d;
END IF;
END PROCESS;
END estruct_dff_9;
-- ============================================================
--- File Name: dff_ck0.vhd
--- ============================================================
-- implements a D FF loaded with the falling edge of clock
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY dff_ck0 IS
PORT
(
d
: IN STD_LOGIC;
clk
: in std_logic;
q
: OUT STD_LOGIC
);
END dff_ck0;
ARCHITECTURE estruct_dff_ck0 OF dff_ck0 IS
BEGIN
PROCESS
BEGIN
WAIT UNTIL (clk 'event and clk='0');
q
<= d;
END PROCESS;
END estruct_dff_ck0;
Appendix B
Schematics
DBCMLKIN
CameraLink input board
DBCMLKOUT
CameraLink output board
Firefly Starter Kit
Cyclone FPGA development board
DS90CR285/DS90CR286
28 bit Channel Link transceivers
D
DB
BC
CM
MLLK
KIIN
NC
Caam
meerraa LLiinnkk IInnppuutt
Schematics
w
ww
ww
w..ddeevvbbooaarrddss..ddee
page 9 of 11
08.05.2006
Version 2.00
D
DB
BC
CM
MLLK
KO
OU
UTT C
Caam
meerraa LLiinnkk IInnppuutt
Schematics
w
ww
ww
w..ddeevvbbooaarrddss..ddee
page 9 of 11
08.09.2006
Version 2.00
A
B
C
5
SC_B_CLKout1
SC_B_CLKin
SC_B_IO[38:0]
SC_B_RSTn
SC_B_SELn
SC_SOCKET_B
SC_A_CLKout1
SC_A_CLKout2
SC_A_CLKin
SC_A_IO[40:0]
SC_A_RSTn
SC_A_SELn
SC_SOCKET_A
4
SC_B_IO[38:0]
SC_A_IO[40:0]
4
SC_B_CLKout1
SC_B_CLKin
SC_B_IO[38:0]
SC_B_RSTn
SC_B_SELn
SC_A_CLKout1
SC_A_CLKout2
SC_A_CLKin
SC_A_IO[40:0]
SC_A_RSTn
SC_A_SELn
EPM_CONNECTOR
POWER
3
epm_JTAG_TDO
epm_JTAG_TCK
epm_JTAG_TMS
epm_JTAG_TDI
3
RS232_TXD
RS232_CTS
RS232_RTS
RS232_RXD
Date:
Size
A
Title
BRD_CLK
CPU_RESETn
cfg_DATA0
cfg_DCLK
cfg_CONF_DONE
cfg_ASDIO
cfg_CSOn
cfg_CEn
cfg_RECONFIGn
USB_BLASTER_CCT
epm_JTAG_TDO
epm_JTAG_TCK
epm_JTAG_TMS
epm_JTAG_TDI
D
5
BRD_CLK_24MHz
BOARD_CONTROLS
BRD_CLK_24MHz
BRD_CLK
CPU_RESETn
cfg_DATA0
cfg_DCLK
cfg_CONF_DONE
cfg_ASDIO
cfg_CSOn
cfg_CEn
cfg_RECONFIGn
BOARD_CONTROLS
RS232_TXD
RS232_CTS
RS232_RTS
RS232_RXD
SERIAL
2
Wednesday, March 30, 2005
Document Number
S6222
Product Starter Kit - Main
2
Sheet
1
1
1
of
9
Rev
B
A
B
C
D
A
B
5
SC_A_IO0
SC_A_IO4
SC_A_SELn
SC_A_IO2
SC_A_IO12
SC_A_IO10
SC_A_IO3
SC_A_IO8
SC_A_IO6
SC_A_IO1
SC_A_IO17
SC_A_IO16
SC_A_IO14
SC_A_IO5
SC_A_IO21
SC_A_IO9
SC_A_IO19
SC_A_IO7
SC_A_IO18
+3.3V
IO {F18}
IO {G18}
IO {D18}
IO {F17}
IO {C17}
GND
IO {D16}
IO {D17}
IO {D15}
IO {E17}
GND
IO {F15}
IO {E15}
IO {F16}
IO {E16}
IO {H17}
VCC
GND
IO {G17}
IO {H16}
IO {E14}
IO {G15}
GND
IO {F14}
IO {G14}
IO {H15}
IO {G13}
IO {H14}
IO {F12}
GND
VCC
IO {G16}
IO {G12}
IO {H13}
GND
IO {J13}
epm_JTAG_TDI
CPU_RESETn
SC_A_IO24
SC_A_IO13
SC_A_IO22
SC_A_IO11
C1
C2
D1
D2
E1
E2
F1
F2
G1
G2
H1
H2
K1
K2
L1
L2
M1
M2
N1
N2
P1
P2
R1
R2
T1
T2
U1
U2
V1
V2
W1
W2
X1
X2
Y1
Y2
epm_JTAG_TCK
SC_A_IO28
SC_A_IO26
epm_JTAG_TMS
epm_JTAG_TDO
SC_B_CLKin
3
FPGA Bank 3 I/Os
FPGA Bank 2 I/Os
Label : pin# IO {Cyclone FPGA Pin# connected to this IO}
4
SC_B_RSTn
SC_B_IO28
SC_B_IO27
SC_B_SELn
SC_B_IO25
SC_B_IO26
SC_A_IO23
SC_A_IO27
SC_A_IO20
SC_A_IO25
SC_A_IO15
BRD_CLK
SC_B_CLKout1
SC_B_IO24
SC_B_IO22
SC_B_IO23
SC_B_IO21
C
+3.3V
SC_A_RSTn
SC_A_CLKin
SC_A_CLKout2
SC_A_CLKout1
SC_A_IO38
SC_B_IO19
SC_B_IO20
SC_B_IO18
SC_B_IO17
SC_B_IO16
J1
SC_A_IO39
SC_A_IO36
SC_A_IO37
SC_A_IO34
SC_B_IO14
SC_B_IO15
SC_B_IO12
SC_B_IO13
+3.3V
4
SC_A_IO35
SC_A_IO32
SC_A_IO33
SC_A_IO30
SC_A_IO31
SC_A_IO40
SC_B_IO10
RS232_RTS
RS232_TXD
RS232_CTS
RS232_RXD
D
5
SC_A_IO29
A1
B1
A2
B2
A3
B3
A4
B4
A5
B5
A6
B6
A7
B7
A8
B8
A9
B9
A10
B10
A11
B11
A12
B12
A13
B13
A14
B14
A15
B15
A16
B16
A17
B17
A18
B18
3
A19
A20
B19
B20
C19
C20
D19
D20
E19
E20
F19
F20
G19
G20
H19
H20
K19
K20
L19
L20
M19
M20
N19
N20
P19
P20
R19
R20
T19
T20
U19
U20
V19
V20
W19
W20
EPM_Female_Connector
IO {L15}
GND
IO {M15}
IO {N15}
IO {L14}
VCC
GND
IO {P15}
IO {N14}
IO {P14}
IO {L13}
IO {M13}
IO {N13}
GND
IO {D12}
IO {E13}
IO {D11}
IO {E11}
GND
VCC
IO {D10}
IO {D9}
IO {D8}
IO {E8}
IO {D7}
GND
Vcore_1V5
IO {E7}
Vcore_1V5
IO {E6}
GND
ASDI
nCSO
DATA0
nCE
RECONFIGn
TDI
GND
IO {M16}
IO {H18}
TMS
VCCIO_B3
TDO
VCCIO_B3
TCK
GND
PLL2_out+ {K15}
PLL2_out- {K16}
PLL2_in+ {J15}
PLL2_in- {J16}
GND
IO {L16}
IO {L17}
IO {L18}
IO {M18}
IO {M17}
VCCIO_B3
GND
IO {N17}
IO {N16}
IO {N18}
IO {P17}
GND
IO {P16}
IO {R16}
IO {R15}
IO {R18}
IO {R17}
IO {T16}
GND
VCC
IO {T17}
IO {C11}
VCC
GND
IO {B14}
IO {C10}
IO {B10}
IO {A9}
IO {A10}
IO {C9}
GND
IO {A8}
IO {B7}
IO {C7}
IO {B9}
GND
VCC
IO {A7}
IO {B6}
IO {B8}
IO {C6}
IO {C8}
GND
IO {A4}
IO {A6}
IO {C5}
IO {B4}
GND
IO {B5}
RS232_RTS
RS232_TXD
RS232_CTS
RS232_RXD
VCC
GND
CONF_DONE
DCLK
X3
Y3
X4
Y4
X5
Y5
X6
Y6
X7
Y7
X8
Y8
X9
Y9
X10
Y10
X11
Y11
X12
Y12
X13
Y13
X14
Y14
X15
Y15
X16
Y16
X17
Y17
X18
Y18
X19
Y19
X20
Y20
cfg_CONF_DONE
cfg_DCLK
cfg_ASDIO
cfg_CSOn
cfg_DATA0
cfg_CEn
cfg_RECONFIGn
SC_B_IO11
SC_B_IO0
SC_B_IO5
SC_B_IO4
SC_B_IO3
SC_B_IO2
SC_B_IO1
SC_B_IO9
SC_B_IO8
SC_B_IO7
SC_B_IO6
SC_B_IO36
SC_B_IO31
SC_B_IO34
SC_B_IO29
SC_B_IO32
SC_B_IO30
VCORE
2
Title
Date:
Size
B
cfg_ASDIO
SC_B_IO35
SC_B_IO38
SC_B_IO33
Wednesday, March 30, 2005
Document Number
S6222
Product Starter Kit - EPM Socket
BRD_CLK
CPU_RESETn
SC_B_IO[38:0]
SC_B_CLKout1
SC_B_CLKin
SC_B_SELn
SC_B_RSTn
SC_A_IO[40:0]
SC_A_CLKout2
SC_A_CLKout1
SC_A_CLKin
SC_A_SELn
SC_A_RSTn
epm_JTAG_TMS
epm_JTAG_TCK
1
1
Sheet
epm_JTAG_TDO
epm_JTAG_TDI
cfg_CEn
cfg_CSOn
cfg_DATA0
cfg_RECONFIGn
cfg_CONF_DONE
cfg_DCLK
RS232_RTS
RS232_CTS
RS232_RXD
RS232_TXD
SC_B_IO37
+3.3V
2
4
of
BRD_CLK
9
CPU_RESETn
SC_B_IO[38:0]
SC_B_CLKout1
SC_B_CLKin
SC_B_SELn
SC_B_RSTn
SC_A_IO[40:0]
SC_A_CLKout2
SC_A_CLKout1
SC_A_CLKin
SC_A_SELn
SC_A_RSTn
Rev
B
epm_JTAG_TMS
epm_JTAG_TCK
epm_JTAG_TDO
epm_JTAG_TDI
cfg_CEn
cfg_CSOn
cfg_ASDIO
cfg_DATA0
cfg_RECONFIGn
cfg_CONF_DONE
cfg_DCLK
RS232_RTS
RS232_CTS
RS232_RXD
RS232_TXD
A
B
C
D
DS90CR285/DS90CR286
+3.3V Rising Edge Data Strobe LVDS 28-Bit Channel
Link-66 MHz
General Description
The DS90CR285 transmitter converts 28 bits of LVCMOS/
LVTTL data into four LVDS (Low Voltage Differential Signaling) data streams. A phase-locked transmit clock is transmitted in parallel with the data streams over a fifth LVDS link.
Every cycle of the transmit clock 28 bits of input data are
sampled and transmitted. The DS90CR286 receiver converts the LVDS data streams back into 28 bits of LVCMOS/
LVTTL data. At a transmit clock frequency of 66 MHz, 28 bits
of TTL data are transmitted at a rate of 462 Mbps per LVDS
data channel. Using a 66 MHz clock, the data throughput is
1.848 Gbit/s (231 Mbytes/s).
The multiplexing of the data lines provides a substantial
cable reduction. Long distance parallel single-ended buses
typically require a ground wire per active signal (and have
very limited noise rejection capability). Thus, for a 28-bit wide
data and one clock, up to 58 conductors are required. With
the Channel Link chipset as few as 11 conductors (4 data
pairs, 1 clock pair and a minimum of one ground) are
needed. This provides a 80% reduction in required cable
width, which provides a system cost savings, reduces connector physical size and cost, and reduces shielding requirements due to the cables’ smaller form factor.
The 28 LVCMOS/LVTTL inputs can support a variety of
signal combinations. For example, seven 4-bit nibbles or
three 9-bit (byte + parity) and 1 control.
Features
n
n
n
n
n
n
n
n
n
n
n
n
n
n
Single +3.3V supply
Chipset (Tx + Rx) power consumption < 250 mW (typ)
Power-down mode ( < 0.5 mW total)
Up to 231 Megabytes/sec bandwidth
Up to 1.848 Gbps data throughput
Narrow bus reduces cable size
290 mV swing LVDS devices for low EMI
+1V common mode range (around +1.2V)
PLL requires no external components
Both devices are offered in a Low profile 56-lead
TSSOP package
Rising edge data strobe
Compatible with TIA/EIA-644 LVDS standard
ESD Rating > 7 kV
Operating Temperature: −40˚C to +85˚C
Block Diagrams
DS90CR285
DS90CR286
01291001
Order Number DS90CR285MTD
See NS Package Number MTD56
01291027
Order Number DS90CR286MTD
See NS Package Number MTD56
TRI-STATE ® is a registered trademark of National Semiconductor Corporation.
© 2004 National Semiconductor Corporation
DS012910
www.national.com
DS90CR285/DS90CR286 +3.3V Rising Edge Data Strobe LVDS 28-Bit Channel Link-66 MHz
July 2004
DS90CR285/DS90CR286
Pin Diagrams for TSSOP Packages
DS90CR285
DS90CR286
01291021
01291022
Typical Application
01291023
www.national.com
2
DS90CR285/DS90CR286
AC Timing Diagrams
(Continued)
01291009
FIGURE 6. DS90CR285 (Transmitter) Setup/Hold and High/Low Times
01291010
FIGURE 7. DS90CR286 (Receiver) Setup/Hold and High/Low Times
01291011
FIGURE 8. DS90CR285 (Transmitter) Clock In to Clock Out Delay
01291012
FIGURE 9. DS90CR286 (Receiver) Clock In to Clock Out Delay
www.national.com
8
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising