Virtual vs Hardware Frame Grabbers
The Neon
NEO-1-10
BitFlow, Inc.
Version G.5
1.6 Virtual vs Hardware Frame Grabbers
It’s important to understand how this manual works. Some chapters of this manual dis-
cuss the NEO-PCE-CLD and NEO-PCE-CLQ as a hardware platforms (this chapter is a
good example). While other chapters discuss the details of the Virtual Frame Grab-
bers (VFG) that this hardware platform supports. The concept of the virtual frame
grabber is described below, but basically the idea is that one hardware platform can
support more than one device. In the case of the Karbon-CL, these devices are frame
grabbers.
Note that we are not using the word virtual here in the sense of “a software virtualiza-
tion of a hardware device”, these VFGs are real hardware. The reason we using “vir-
tual” is because the term “frame grabber” has more than one meaning. It can mean
the piece of hardware that you put in your computer, or it can mean the device that
the your software application is controlling and getting images from. For the pur-
poses of this manual, “virtual frame grabber” means the device that your application
is interfacing to. While this might sound complicated, the implementation is simple.
Plug a NEO-PCE-CLD or NEO-PCE-CLQ frame grabber into your PC, and your appli-
cation interacts with one or more VFGs available. Everything else is taken care of by
the BitFlow drivers.
1.6.1 The Virtual Frame Grabber (VFG)
The Karbon family was the first board from BitFlow that supports the concept of the
virtual frame grabber (VFG). The NEO-PCE-CLD and NEO-PCE-CLQ also use this con-
cept. The idea behind the VFG is to separate the hardware platform (connectors, lam-
inate, FPGAs, etc.) from the frame grabbing functionality that software applications
work with. The primary reason behind this separation is that the turn around time for
hardware is much longer than the turn around time for modifying virtual frame grab-
bers. To create a brand new virtual frame grabber, or to modify an existing one, sim-
ply requires writing new firmware or updating existing firmware.
The idea of modifying a frame grabber by making changes to its firmware is not new.
BitFlow has been doing this since its very first product. However, what is new about
the Karbon family, is the fact the entire frame grabber is written in firmware. The only
fixed hardware components are the interfaces to the outside world (e.g. the CL chips
on the front end). Everything else that makes up the board, camera control, data buff-
ering, DMA engine, etc. is written in firmware. This gives the Karbon platform incredi-
ble levels of flexibility and opens the door to unlimited customization.
1.6.2 Configuration Spaces
The NEO-PCE-CLD supports two VFGs, the NEO-PCE-CLQ supports four VFGs. Each
VFG has its own configuration space (PCI interface) and will look like a separate
device to the operating system. Each VFG has its own CL interface chip. Figure 1-2
shows the block diagram of the entire board, while Figure 1-1 shows the block dia-
gram of the individual VFG. In this case, each VFG looks like a separate instance of the
single base Neon.
Summary of Contents for NEO-PCE-CLB
Page 8: ... TOC 6 BitFlow Inc Version ...
Page 22: ...Virtual vs Hardware Frame Grabbers The Neon NEO 1 12 BitFlow Inc Version G 5 ...
Page 64: ...NTG Control Registers The Neon NEO 3 6 BitFlow Inc Version G 5 ...
Page 90: ...PoCL Control Registers The Neon NEO 6 6 BitFlow Inc Version G 5 ...
Page 266: ...Power Consumption The Neon NEO 12 6 BitFlow Inc Version G 5 ...
Page 294: ...NEO PCE DIF I O Connector Pinout P3 The Neon NEO 13 28 BitFlow Inc Version G 5 ...
Page 300: ...Index BitFlow Inc ...