BitFlow NEO-PCE-CLB, NEO-PCE-CLD, NEO-PCE-CLQ, NEO-PCE-DIF Hardware Reference Manual

The Neon

Hardware Reference Manual

BitFlow, Inc. 400 West Cummings Park, Suite 5050 Woburn, MA 01801 USA Tel: 781-932-2900 Fax: 781-933-9965 Email: support@bitflow.com Web: www.bitflow.com Revision G.5

This document, in whole or in part, may not be copied, photocopied, reproduced, translated or reduced to any other electronic medium or machine readable form without the prior written consent of BitFlow, Inc.

BitFlow, Inc. makes no implicit warranty for the use of its products and assumes no responsibility for any errors that may appear in this document, nor does it make a commitment to update the information contained herein.

BitFlow, Inc. retains the right to make changes to these specifications at any time without notice.

All trademarks are properties of their respective holders.

Revision History:

Revision Date Comments

F.0 2007-02-01 First Revision

G.0 2008-04-25 Synchronized with SDK 5.00

G.1 2009-07-01 Synchronized with SDK 5.20

G.2 2009-09-10 Added NEO-PCE-CLD and NEO-PCE-CLB Revi-

sion 2

G.3 2010-11-18 Added NEO-PCE-CLQ

G.4 2016-04-18 Added NEO-PCE-DIF

G.5 2016-04-28 Minor corrections

P - Preface

Purpose NEO-P-1

Support Services NEO-P-1 Technical Support NEO-P-1 Sales Support NEO-P-1 Conventions NEO-P-2

1 - General Description and Architecture

The Neon NEO-1-1 NEO-PCE-CLB General Description NEO-1-2 NEO-PCE-CLD General Description NEO-1-4 NEO-PCE-CLQ General Description NEO-1-6 NEO-PCE-DIF General Description NEO-1-8 Virtual vs Hardware Frame Grabbers NEO-1-10

The Virtual Frame Grabber (VFG) NEO-1-10 Configuration Spaces NEO-1-10 Firmware, Camera Files and Downloads NEO-1-11

Table of Contents

2 - Acquisition and Camera Control

Introduction NEO-2-1 BitFlow’s Flow-Thru Architecture NEO-2-2 Camera Specific Firmware for Camera Link Models (CL Models Only) NEO-2-7 Generation of Acquisition Windows NEO-2-9

The Horizontal Active Window, HAW NEO-2-9 The Vertical Active Window, VAW NEO-2-10

The Control Tables (CTABs) NEO-2-12

Vertical Control Table NEO-2-12 The VCTAB Functions NEO-2-13 Vertical Control Table Size NEO-2-15 Horizontal Control Table NEO-2-15 The HCTAB Functions NEO-2-17 Horizontal Control Table Size NEO-2-20

Synchronizing Acquisition, Camera, CTABs and External Signals NEO-2-21

Vertical Operations and Events NEO-2-21 Horizontal Operations and Events NEO-2-25

Acquisition Command and Status NEO-2-29

The Acquisition Bitfields NEO-2-29 Trigger Processing (CL & Dif Models Only) NEO-2-34 Encoder Processing (CL & Dif Models Only) NEO-2-35 The On-Board Signal Generator NEO-2-36

BitFlow, Inc.

Table of Contents

3 - New Timing Generator

Introduction NEO-3-1 Components and Control NEO-3-2

Periods and Frequencies NEO-3-2 Waveform polarity NEO-3-3 Triggering NEO-3-3 Output Signals NEO-3-3

Master/Slave Control NEO-3-3 Timing NEO-3-4 NTG Control Registers NEO-3-5

4 - Quadrature Encoder

Introduction NEO-4-1

Simple Encoder Mode NEO-4-1

Positive or Negative Only Acquisition NEO-4-1

Interval Mode NEO-4-2

Re-Acquisition Prevention NEO-4-2

Scan Step Mode NEO-4-2

Combining Modes NEO-4-2

Control Registers NEO-4-2

Observability NEO-4-3

Electrical Connections NEO-4-3 Understanding Stage Movement vs. Quadrature Encoder Modes NEO-4-4 CON15 Register NEO-4-6 CON16 Register NEO-4-10 CON22 Register NEO-4-12 CON51 Register NEO-4-14

5 - Encoder Divider

Introduction NEO-5-1 Encoder Divider Details NEO-5-2

Formula NEO-5-2

Example NEO-5-2

Restrictions NEO-5-2

PLL Locking NEO-5-3

Handling Encoder Slow Down or Stopping NEO-5-3 Encoder Divider Control Registers NEO-5-4

6 - Power Over Camera Link (PoCL)

Introduction NEO-6-1 PoCL Compatibility NEO-6-2 PoCL Safe Power NEO-6-3 PoCL Control Registers NEO-6-5

BitFlow, Inc.

7 - System Status

Introduction NEO-7-1 FACTIVE, FCOUNT NEO-7-2 PCOUNT, LCOUNT, FENCOUNT NEO-7-3 RD_TRIG_DIFF/TTL/OPTO, RD_ENC_DIFF/TTL/OPTO NEO-7-4 TRIG_QUALIFIED NEO-7-5 VCOUNT, HCOUNT, LINES_TOGO NEO-7-6 FIFO_EQ NEO-7-7 DEST_ADD NEO-7-8

8 - Camera Control Registers

Introduction NEO-8-1 Bitfield definitions NEO-8-2

Example Bitfield Definition NEO-8-2

Bitfield Definition Explanation. NEO-8-2 CON0 Register NEO-8-4 CON1 Register NEO-8-8 CON2 Register NEO-8-15 CON3 Register NEO-8-21 CON4 Register NEO-8-24 CON5 Register NEO-8-31 CON6 Register NEO-8-37 CON7 Register NEO-8-39 CON8 Register NEO-8-42 CON9 Register NEO-8-48 CON10 Register NEO-8-52 CON11 Register NEO-8-56 CON12 Register NEO-8-58 CON13 Register NEO-8-60 CON14 Register NEO-8-62 CON15 Register NEO-8-66 CON16 Register NEO-8-70 CON17 Register NEO-8-73 CON18 Register NEO-8-75 CON19 Register NEO-8-77 CON20 Register NEO-8-79 CON21 Register (Bayer Version) NEO-8-82 CON22 Register NEO-8-85 CON23 Register NEO-8-87 CON24 Register NEO-8-89 CON25 Register NEO-8-93 CON26 Register NEO-8-95 CON27 Karbon Register NEO-8-97 CON27 Neon-DIF Register NEO-8-99 CON36 Register NEO-8-101 CON37 Register NEO-8-103 CON38 Register NEO-8-105

Table of Contents

BitFlow, Inc.

CON40 Register NEO-8-108 CON41 Register NEO-8-110 CON42 Register NEO-8-112 CON43 Register NEO-8-118 CON44 Register NEO-8-120 CON51 Register NEO-8-122

9 - Karbon/Neon/Alta DMA

Introduction NEO-9-1 CON28 Register NEO-9-2 CON29 Register NEO-9-4 CON30 Register NEO-9-6 CON31 Register NEO-9-8 CON32 Register NEO-9-10 CON33 Register NEO-9-12 CON34 Register NEO-9-14 CON35 Register NEO-9-17 Scatter Gather DMA Instructions NEO-9-19 Destination Address NEO-9-20 Size of Transfer NEO-9-21 Next Quad Address NEO-9-22

Table of Contents

10 - Register and Memory Mapping

Introduction NEO-10-1 Memory Types NEO-10-2

Registers NEO-10-2

UART NEO-10-2

DPM NEO-10-2

CTABs NEO-10-2 Memory Map NEO-10-3 Downloading Firmware NEO-10-5 PCI Configuration Space and Model/Revision Information NEO-10-6

11 - Electrical Interfacing

Introduction NEO-11-1 Trigger NEO-11-2

Trigger Input Types NEO-11-2

The Optocoupled Trigger NEO-11-2 Encoder NEO-11-4

Encoder Input Types NEO-11-4

The Optocoupled Encoder NEO-11-4 General Purpose Inputs (GPIN) NEO-11-6

Introduction NEO-11-6 General Purpose Outputs (GPOUT) NEO-11-7

BitFlow, Inc.

Table of Contents

Introduction NEO-11-7 GPOUT Open Collector Drivers NEO-11-7

Camera Link Controls (CCs) NEO-11-10

12 - Specifications

Introduction NEO-12-1 Maximum Pixels Per Line NEO-12-3 Maximum Lines Per Frame NEO-12-4 Power Consumption NEO-12-5

13 - Mechanical

Introduction NEO-13-1 The NEO-PCE-CLB Revision 1 NEO-13-2 The NEO-PCE-CLB Revision 2 NEO-13-3 The NEO-PCE-CLD NEO-13-4 The NEO-PCE-CLQ NEO-13-5 The NEO-PCE-DIF NEO-13-7 The Neon Connectors NEO-13-8

The CL Connectors NEO-13-8

The I/O Connectors NEO-13-8 The Jumpers NEO-13-10 Switches NEO-13-11

Switch S1, All Neon models NEO-13-11

Switch S2, NEO-PCE-CLB Revision 2 Only NEO-13-11

Switches S3 and S6, NEO-PCE-CLB Revision 2 Only NEO-13-11

Switches S4 and S7, NEO-PCE-CLB Revision 2 Only NEO-13-12

Switch S5, NEO-PCE-CLB Revision 2 Only NEO-13-12 The Camera Link Connector Pinouts (CL1 to CL4) NEO-13-13 NEO-PCE-CLB Revision 1 I/O Connector, Standard Configuration (P10) NEO-13-14 NEO-PCE-CLB Revision 1 I/O Connector, Alternate Configuration (P10) NEO-13-15 NEO-PCE-CLB Revision 2 I/O Connector (P10) NEO-13-16 NEO-PCE-CLD I/O Connector Pinout (P1) NEO-13-17 NEO-PCE-CLQ I/O Connector Pinout (P3) NEO-13-19 NEO-PCE-DIF Main Connector Pinout (P7) NEO-13-22 NEO-PCE-DIF Auxiliary Connector Pinout (P2) NEO-13-25 NEO-PCE-DIF I/O Connector Pinout (P3) NEO-13-27

BitFlow, Inc.

-TOC-6 BitFlow, Inc. Version

Preface Purpose

Preface

Chapter P

P. 1 P u r p o s e

This Hardware Reference Manual is intended for anyone using the Neon family of frame grabber. The purpose of this manual is two-fold. First, this manual completely describes how the board works. Second, it is a reference manual describing in detail the functionality of all of the board’s registers.

P.1.1 Support Services

BitFlow, Inc. provides both sales and technical support for the Neon family of products.

P.1.2 Technical Support

Our web site is www.bitflow.com.

Technical support is available at 781-932-2900 from 9:00 AM to 6:00 PM Eastern Standard Time, Monday through Friday.

For technical support by email (support@bitflow.com) or by FAX (781-933-9965), please include the following:

Product name Camera type and mode being used Software revision number Computer CPU type, PCI chipset, bus speed Operating system Example code (if applicable)

P.1.3 Sales Support

Contact your local BitFlow Sales Representative, Dealer, or Distributor for information about how BitFlow can help you solve your most demanding camera interfacing problems. Refer to the BitFlow, Inc. web site (www.bitflow.com) for a list of North American representatives and worldwide distributors.

Version G.5 BitFlow, Inc. NEO-P-1

Purpose The Neon

P.1.4 Conventions

Table P-1 shows the conventions that are used for numerical notation in this manual.

Table P-1 Base Abbreviations

Base Designator Example

Binary b 1010b

Decimal None 4223

Hexidecimal h 12fah

Table P-2 shows the numerical abbreviations that are used in this manual.

Table P-2 Numeric Abbreviations

Abbreviation Value Example

K 1024 256K

M 1048576 1M

NEO-P-2 BitFlow, Inc. Version G.5

General Description and Architecture The Neon

General Description and Architecture

Chapter 1

1.1 The Neon

The purpose of this chapter is to explain, at a block diagram level, how the Neon family works, and what different versions are available. There are a few models in the Neon family:

NEO-PCE-CLB, supports one base CL cameras (Revision 1 and Revision 2) NEO-PCE-CLD, supports two base CL cameras NEO-PCE-CLQ, supports four base CL cameras NEO-PCE-DIF, supports one differential camera

Version G.5 BitFlow, Inc. NEO-1-1

NEO-PCE-CLB General Description The Neon

24 64

Camera Link

Interface

MUX

Video Pipeline,

Data Packer

PCI Interface,

Scatter-Gather

DMA Engine

Camera Control,

CTABs

FIFO

I/O,

Triggers,

Encoders

UART

Serial

Interface

P10

Local Bus

PCI Express Bus

CL1

1.2 NEO-PCE-CLB General Description

Figure 1-1 illustrates the block diagram of the NEO-PCE-CLB.

Figure 1-1 NEO-PCE-CLB Block Diagram

The NEO-PCE-CLB implements the Camera Link base configuration, i.e. it can accept a single camera putting out up to 24 bits of data.

The NEO-PCE-CLB can accept input data at up to 85 Mhz.

The following paragraphs are a short description of each block.

The Camera Link Interface block implements the CL base configuration This block has the Channel Link IC, the Camera Control drivers and the serial communication transceivers.

The MUX block packs and assembles the data from the Camera Link block before it is pushed into the FIFO. This block re-arranges on-the-fly the data from the camera’s taps so that the data is written in raster scan format in the host memory.

NEO-1-2 BitFlow, Inc. Version G.5

General Description and Architecture NEO-PCE-CLB General Description

The FIFO block decouples the camera from the DMA engine. It is implemented with dual ported memories.

The Camera Control block handles both camera synchronization as well as external I/ O. The block contains the CTABs which are uses to synchronize acquisition with the camera, determine which pixels/lines get acquired and which do not, generate control signals to the camera and to external devices. This block also handles start/stopping acquisition based on triggers and encoders.

The PCI interface block handles host reads/writes to/from the board. These reads/ writes are used to program the board, and to control its modes. This block is also responsible for DMAing image data to the host memory (or other devices). The DMA engine uses chaining scatter-gather DMA, which can DMA a virtually unlimited amount of data to memory without using any CPU cycles.

There is an on-board UART, as required by the CL specification.

The IO connector block has transmitters/receivers to communicate with external industrial equipment (triggers, encoders, light strobes etc.).

Version G.5 BitFlow, Inc. NEO-1-3

NEO-PCE-CLD General Description The Neon

Connector

UART

PCI

Device

PCI

Device

Channel

Link

Chip

UART

Channel

Link

Chip

Acquisition

and

Control

Logic

Acquisition

and

Control

Logic

PCI Express Bus

CL2

Connector

CL1

1.3 NEO-PCE-CLD General Description

Figure 1-2 illustrates the block diagram of the NEO-PCE-CLD.

Figure 1-2 NEO-PCE-CLD Block Diagram

The NEO-PCE-CLD implements two completelys separate Camera Link base interfaces. Each interface is really a completely independent Virtual Frame Grabber (VFG). Put another way, the NEO-PCE-CLD has two complete copies of the NEO-PCE-CLB as shown in Figure 1-1. The main difference being that both VFGs share a common I/O connector (P1).

Each VFG can accept up to 24 bits at up to 85 Mhz pixel clock frequency.

The following paragraphs are a short description of each block.

NEO-1-4 BitFlow, Inc. Version G.5

General Description and Architecture NEO-PCE-CLD General Description

The Camera Link Interface block implements the CL base configuration This block has the Channel Link chip, the Camera Control drivers and the serial communication tranceivers. Note that each VFG has its own UART so that serial communications to both cameras can happen simultaneously.

The FIFO block decouples the camera from the DMA engine. It is implemented with dual ported memories.

There is an on-board UART, as required by the CL specification.

The IO connector block has transmitters/receivers to communicate with external industrial equipment (triggers, encoders, light strobes etc.).

Version G.5 BitFlow, Inc. NEO-1-5

NEO-PCE-CLQ General Description The Neon

PCI

Device

Acquisition

and

Control

Logic

Connector

UART

Channel

Link

Chip

CL1

PCI

Device

Acquisition

and

Control

Logic

Connector

UART

Channel

Link

Chip

CL2

PCI

Device

Acquisition

and

Control

Logic

Connector

UART

Channel

Link

Chip

CL3

PCI

Device

Acquisition

and

Control

Logic

Connector

UART

Channel

Link

Chip

CL4

PCI Express Bus

1.4 NEO-PCE-CLQ General Description

Figure 1-3 illustrates the block diagram of the NEO-PCE-CLQ.

Figure 1-3 NEO-PCE-CLQ Block Diagram

The NEO-PCE-CLQ implements four completelys separate Camera Link base interfaces. Each interface is really a completely independent Virtual Frame Grabber (VFG). Put another way, the NEO-PCE-CLQ has four complete copies of the NEO-PCE-CLB as shown in Figure 1-1. The main difference being that all VFGs share a common I/O connector (P1).

Each VFG can accept up to 24 bits at up to 85 Mhz pixel clock frequency.

NEO-1-6 BitFlow, Inc. Version G.5

General Description and Architecture NEO-PCE-CLQ General Description

The following paragraphs are a short description of each block.

The FIFO block decouples the camera from the DMA engine. It is implemented with dual ported memories.

There is an on-board UART, as required by the CL specification.

The IO connector block has transmitters/receivers to communicate with external industrial equipment (triggers, encoders, light strobes etc.).

Version G.5 BitFlow, Inc. NEO-1-7

NEO-PCE-DIF General Description The Neon

MUX

Video Pipeline,

Data Packer

PCI Interface,

Scatter-Gather

DMA Engine

Camera

Control,

CTABs

FIFO

UART

Serial

Interface

Local Bus

PCI Express Bus

Bits 16 to 31

Bits 0 to 15

1.5 NEO-PCE-DIF General Description

Figure 1-4 illustrates the block diagram of the NEO-PCE-DIF

The NEO-PCE-DIF supports one differential camera up to 32 bits.

Figure 1-4 NEO-PCE-DIF Block Diagram

The NEO-PCE-DIF can accept input data at up to 85 Mhz.

The following paragraphs are a short description of each block.

The FIFO block decouples the camera from the DMA engine. It is implemented with dual ported memories.

NEO-1-8 BitFlow, Inc. Version G.5

General Description and Architecture NEO-PCE-DIF General Description

There is an on-board UART which can be use with cameras that support serial communications.

The IO connector block has transmitters/receivers to communicate with external industrial equipment (triggers, encoders, light strobes etc.).

Version G.5 BitFlow, Inc. NEO-1-9

Virtual vs Hardware Frame Grabbers The Neon

1.6 Virtual vs Hardware Frame Grabbers

It’s important to understand how this manual works. Some chapters of this manual discuss 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 Grabbers (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 virtualization of a hardware device”, these VFGs are real hardware. The reason we using “virtual” 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 purposes 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 application 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 concept. The idea behind the VFG is to separate the hardware platform (connectors, laminate, 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 grabbers. To create a brand new virtual frame grabber, or to modify an existing one, simply 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 buffering, DMA engine, etc. is written in firmware. This gives the Karbon platform incredible 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 diagram of the individual VFG. In this case, each VFG looks like a separate instance of the single base Neon.

NEO-1-10 BitFlow, Inc. Version G.5

General Description and Architecture Virtual vs Hardware Frame Grabbers

1.6.3 Firmware, Camera Files and Downloads

Note that all the devices present on a NEO-PCE-CLD and NEO-PCE-CLQ will appear in SysReg as separate BitFlow Boards Found. The order that the VFGs appear in SysReg is determined by the operating system and is somewhat arbitrary. However, SysReg lists the connector(s) associated with each VFG, so that a connection can be made between VFG and physical connector on the board.

Recall that, even though NEO-PCE-CLD appears like two frame grabbers (the NEOPCE-CLQ as four), there is only one actual hardware platform. For this reason the firmware of the of the VFGs on one board is linked. The selection of the master VFG, determines the configurations of all of slave VFGs. For example, if you configure the master VFG with a two-tap odd/even pixel camera, then the slave VFG will also have to be configured for a two-tap odd/even pixel camera. In all other ways, however, the two configurations do not have to match. If you have a requirement where this rule must be broken, please contact BitFlow’s support department. Custom combinations of firmware are available.

If there is a mismatch between the firmware required by one VFG’s camera file and the firmware required by another VFG’s camera file, the master VFG’s firmware will get priority. In practice this means that if you change the camera file for the master VFG, and it requires different firmware than is already on the board, new firmware will be downloaded next time you start an application. However, in the case of a slave VFG, if different firmware is required than is on the board, an error message will pop up indicating the problem. Thus all the camera files for a all the VFGs on one NEOPCE-CLD or NEO-PCE-CLQ should all require the same firmware. That said, if you have a custom need for a particular arrangement of cameras, please let us know. We

can create custom firmware to solve almost any problem.

Version G.5 BitFlow, Inc. NEO-1-11

Virtual vs Hardware Frame Grabbers The Neon

NEO-1-12 BitFlow, Inc. Version G.5

Acquisition and Camera Control Introduction

Acquisition and Camera Control

Chapter 2

2.1 Introduction

This section covers acquisition and camera control for the R64-CL, Karbon-CL, NeonCL, Neon-Dif, Karbon-CXP and the Alta-AN families of frame grabbers.

Version G.5 BitFlow, Inc. NEO-2-1

BitFlow’s Flow-Thru Architecture The Neon

2.2 BitFlow’s Flow-Thru Architecture

The MUX component of the block diagrams for the Alta, Karbon, Neon and R64 is composed of a chain of sub-blocks that make up the Flow-Thru Architecture (FTA). Figure 2-1 shows the structure of the FTA for the Camera Link boards. Figure 2-2 shows the structure of the Alta family. All the data paths are 64-bit. The implementation of the individual blocks depends on the camera format, i.e. it is specific to the firmware downloaded for each sensor architecture. There is a bitfield, FORMAT, which indicates the currently downloaded firmware.

Below is a description of the individual blocks. For each block are shown the signals that are defined by the user.

Data from the Camera Link or AFE is synchronized and assigned to data lanes according to the camera format. The user has no control over these operations. From this block the data goes to a Barrel Shifter.

The Barrel Shifter is composed of four 16-bit barrel shifters. All shifters receive the same command, Left/Right and the amount of shift, up to 15 bits. The main purpose of the Barrel Shifter is for cameras that have more than 8 bits per pixel. The Barrel Shifter can down-shift the data to 8-bit suitable for display. Any camera with up to four taps can be accommodated.

There is a Video Delay Line (not shown) in the data path which can delay the video by up to 8 clocks. This is useful for accurate alignment of the video on the display.

The Video Selector selects the data source: the video from the camera or the onboard generated synthetic video. The various patterns of synthetic video are useful mainly for the on-board Built In Self Test (BIST).

The Mask is a 32-bit mask replicated over the upper and lower 32 bits of the 64-bit data path. The purpose of this mask is to be able to set to zero any bit in the data path (a one will pass the data as is, a zero will set that bit to zero).

The Clip is a clipping mechanism replicated on each one of the eight 8-bit data lanes. If enabled, it will clip the 256 gray levels in each lane according to the formula:

If video > 245 then video = 245 If video <10 then video = 10

This mechanism is useful for displaying gray level data on a VGA that is set in 256color mode. In this mode the upper and lower 10 gray levels are dedicated to the Windows graphics.

The Assembler will assemble and pack the video data before it is written in the FIFO. This block does the raster scan re-arranging of the data. The packing is dependent on the pixel depth, which is defined in the PIX_DEPTH bitfield in CON10. The DISPLAY bit will force this block to assemble the data as 8-bit pixels, suitable for display. When using this mode, the barrel shifters must be set to down-shift each pixel by the correct amount. A 10-bit camera, for example, would need a 2-bit right shift.

The SWAP bit will swap between odd-even data streams for cameras that supply oddeven pixels.

NEO-2-2 BitFlow, Inc. Version G.5

Acquisition and Camera Control BitFlow’s Flow-Thru Architecture

The amount of data written in the FIFOs is controlled by the Acquisition Window. The vertical and horizontal size of this window is programmed in the ALPF and the ACLP registers respectively (see Section 2.4). The timing of this window is determined by the camera and the acquisition state machine.

Version G.5 BitFlow, Inc. NEO-2-3

BitFlow’s Flow-Thru Architecture The Neon

24 24 16

16 16 16 16

32 32

8 8 8 8 8 8 8 8

8 8 8 8 8 8 8

Channel

Link Chip

Channel

Link Chip

Channel

Link Chip

Channel X

Equalizer

FIFO

Channel Y Equalizer

FIFO

Channel Z Equalizer

FIFO

Camera Link Pixel Data Descrambler

Synthetic

Video

VID_SOURCE

PIX_DEPTH

VIDEO_MASK

CLIP

FORMAT,DISPLAY, PIX_DEPTH

SHIFT_RAW, SHIFT_DSP, SHIFT_RAW_LEFT, SHIFT_DISP_LEFT, SHIFT_DISP_SELECT

Barrel

Shifter

Barrel

Shifter

Barrel

Shifter

Barrel

Shifter

2:1 MUX

32-Bit

Mask

32-Bit

Mask

Raster Scan Line

Reformatter

8-Bit

Clip

8-Bit

Clip

8-Bi

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

Figure 2-1 Flow Thru Architecture - R64, Karbon and Neon

NEO-2-4 BitFlow, Inc. Version G.5

Acquisition and Camera Control BitFlow’s Flow-Thru Architecture

8 8 8

16 16 16 16

32 32

8 8 8 8 8 8 8 8

8 8 8 8 8 8 8

A-to-D

Camera Link Pixel Data Descrambler

Synthetic

Video

VID_SOURCE

PIX_DEPTH

VIDEO_MASK

CLIP

FORMAT,DISPLAY, PIX_DEPTH

SHIFT_RAW, SHIFT_DSP, SHIFT_RAW_LEFT, SHIFT_DISP_LEFT, SHIFT_DISP_SELECT

Barrel

Shifter

Barrel Shifter

Barrel

Shifter

Barrel

Shifter

2:1 MUX

32-Bit

Mask

32-Bit

Mask

Raster Scan Line

Reformatter

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

A-to-D

Figure 2-2 Flow Thru Architecture - Alta

Version G.5 BitFlow, Inc. NEO-2-5

BitFlow’s Flow-Thru Architecture The Neon

16 16 16 16

32 32

8 8 8 8 8 8 8 8

8 8 8 8 8 8 8

Pixel Data Descrambler

CoaXPress Data Packet Router

Synthetic

Video

VID_SOURCE

PIX_DEPTH

VIDEO_MASK

CLIP

FORMAT,DISPLAY, PIX_DEPTH

SHIFT_RAW, SHIFT_DSP, SHIFT_RAW_LEFT, SHIFT_DISP_LEFT, SHIFT_DISP_SELECT

Barrel

Shifter

Barrel

Shifter

Barrel

Shifter

Barrel

Shifter

2:1 MUX

32-Bit

Mask

32-Bit

Mask

Raster Scan Line

Reformatter

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

8-Bit

Clip

Figure 2-3 Flow Thru Architecture - Karbon-CXP

NEO-2-6 BitFlow, Inc. Version G.5

Acquisition and Camera Control Camera Specific Firmware for Camera Link Models (CL Models Only)

2.3 Camera Specific Firmware for Camera Link Models (CL Models Only)

The Flow-Thru architecture is flexible and can be adapted to different cameras architectures. The main intelligence is in the firmware that gets downloaded into the onboard Field Programmable Gate Arrays (FPGAs). This firmware is different for every camera architecture. The firmware is called out in the camera file. On initialization, the driver will download into the FPGAs the firmware called-out in the camera file.

The type of the firmware is hard-coded in the FORMAT field in register CON10. The list of the formats is shown in Table 2-1

Note: Not all models support all formats. Only formats that are possible are supported. For example, the Neon, which is Base Camera Link only, will not support the MUX_8TS format as the is a Full Camera Link format.

Table 2-1 Firmware Options

FORMAT Firmware Name Format Description

0MUX 1 tap cameras

1 MUX_2TOEP 2 taps, odd-even pixels

2 MUX_2TOEL 2 taps, odd-even lines

3 MUX_2TS 2 taps, segmented

4 MUX_2TS1RI 2 taps, segmented, right inverted

5 MUX_4TS 4 taps, segmented

6 MUX_4T2S2RIOEP 4 taps, odd-even pixels, right taps inverted

7 MUX_4TQ2RI2BU 4 quads, right quads inverted, bottom

quads upside down

8 MUX_2CAM 2 cameras: 1 tap each

9 MUX_2CAM_2TOEP 2 cameras: 2 taps, odd-even pixels

10 MUX_2CAM_2TS1RI 2 cameras: 2 taps, segmented, right-

inverted

11 MUX_2CAM_2TS 2 cameras: 2 taps, segmented

12 MUX_2CAM_2TOEL 2 cameras: 2 taps, odd-even lines

13 MUX_8TS 8 taps, segmented

14 MUX_BAY Bayer decoder, 1 tap 8 bit

15 MUX_BAY_OE Bayer decoder, 2 taps, odd-even pixels

16 MUX_BAY_2TS Bayer decoder, 2 taps, segmented

17 MUX_4WI 4 taps, 4-way interleaved

18 MUX_2TOEPI 2 taps, odd-even pixels, both inverted

19 MUX_1TI 1 tap, inverted

Version G.5 BitFlow, Inc. NEO-2-7

Camera Specific Firmware for Camera Link Models (CL Models Only) The Neon

Table 2-1 Firmware Options

FORMAT Firmware Name Format Description

20 MUX_8WI 8 taps, 8-way interleaved

21 MUX_BAY_2TS_RI Bayer decoder, 2 taps, segmented, right

inverted

22 MUX_4TS2RI Four taps, segmented, right two taps

inverted

23 MUX_8TSOEP4RI Eight taps, segments, odd/even pixel, for

right taps inverted

24 MUX_10WI Ten taps, interleaved

NEO-2-8 BitFlow, Inc. Version G.5

Acquisition and Camera Control Generation of Acquisition Windows

2.4 Generation of Acquisition Windows

2.4.1 The Horizontal Active Window, HAW

The Horizontal Active Window (HAW) is a square wave that defines the portion of the line that will be acquired horizontally. HAW can span less than the whole camera line, if we want to acquire only a portion of that line. The size of the HAW is determined by a single number, the Active Clocks Per Line (ACPL). The ACPL is defined as the number of clocks during which the HAW is active. The ACPL field is programmed in CON10. The 17 bits define the maximum HAW as minimum 128K pixels.

The total number of pixels per line that will be acquired can be different than the ACPL. For a dual tap camera that supplies odd-even pixels for example, the total number of pixels acquired will be twice the ACPL, as for every clock the camera supplies two pixels. Note that the ACPL is not a function of the bits per pixel. The relationship between the number of pixels per line and the number of clocks per line is controlled by the firmware currently downloaded to the board. The FORMAT register will indicate which firmware is currently downloaded. Each tap configuration requires a different firmware file be downloaded. The correct firmware is automatically downloaded based on the information contained in the camera configuration file.

The size of the HAW is on an arbitrary boundary. The start in time of the HAW can come from two sources, depending on the setting of the HAW_START bit:

The HSTART bit in the HCTAB, if HAW_START = 1. The start of LEN, if HAW_START = 0.

In both modes, the start of the HAW can be delayed 0-7 clocks relative to the start function (HSTART or LEN). This is done by the TRIM bits in CON9.

In both modes, the start of the HAW can be advanced 0-7 clocks relative to the start function (HSTART or LEN). This is done by the DELAY bits in CON14.

The HCTAB is the Horizontal Control Table that generates the HSTART, see section on CTABs.

Figure 2-4 shows the controls that generate the HAW.

Version G.5 BitFlow, Inc. NEO-2-9

Generation of Acquisition Windows The Neon

Horizontal

CTAB

2:1

MUX

HAW

Generator

ACPL, TRIM

LEN

HAW_START

HSTART HAW

Figure 2-4 Generation of the Horizontal Active Window, HAW

2.4.2 The Vertical Active Window, VAW

The Vertical Active Window (VAW) is a square wave that defines the portion of the frame that will be acquired vertically. VAW can span less than the whole camera frame, if we want to acquire only a portion of that frame. The size of the VAW is determined by a single number, the Active Lines Per Frame (ALPF). The ALPF is defined as the number of HAW periods during which the VAW is active. The ALPF field is programmed in CON17. The 17 bits define the maximum VAW as minimum 128K lines.

The total number of lines per frame that will be acquired can be different than the ALPF. For a dual tap camera that supplies odd-even lines for example, the total number of lines acquired will be twice the ALPF as in the period of one HAW the camera supplies two lines.

The size of the VAW is on an arbitrary boundary. The start in time of the VAW can come from two sources, depending on the setting of the VAW_START bit:

The VSTART bit in the VCTAB, if VAW_START = 1. The start of FEN, if VAW_START = 0.

Data will be acquired in the window defined by the HAW and the VAW

Figure 2-5 shows the controls that generate the VAW.

NEO-2-10 BitFlow, Inc. Version G.5

Acquisition and Camera Control Generation of Acquisition Windows

Vertical

CTAB

2:1

MUX

VAW

Generator

ALPF

FEN

VAW_START

VSTART VAW

Figure 2-5 Generation of the Vertical Active Window, VAW

Version G.5 BitFlow, Inc. NEO-2-11

The Control Tables (CTABs) The Neon

INCREMENT

LOGIC

LOAD

LOGIC

RESET

LOGIC

RESET_V

LOAD_V

INC_V

ADDRESS

VCOUNT (COUNTER)

VCTAB (SRAM)

VCOUNT

CLOCK_V

VSTART

VRESET

ENVLOAD

IRQ

GPV0

GPV1

GPV2

GPV3

END_OF_LINE

2.5 The Control Tables (CTABs)

The CTABs are two memories that are programmed by the host computer and read by the board’s acquisition circuitry. The read-out is done in a sequential fashion, i.e. the memories’ addresses are scanned sequentially. There is a vertical memory (VCTAB) and a horizontal memory (HCTAB). The vertical and horizontal memory each has an associated counter which scans its addresses, VCOUNT and HCOUNT respectively. The concept here is similar to how a CPU runs a program. There is a PC which works it’s way through memory, processing each instruction in turn. Each bit in the CTAB corresponds to a different operation. For example, one bit might control the level of a signal going to the camera. In this case the CTABs can be thought of as programmable waveform generators. Another bit might cause an interrupt to occur on the PCI bus, yet another bit might force the HCOUNT to go to zero. The CTABs are fully programmable by software. The details of the CTABs are described in this section.

2.5.1 Vertical Control Table

Figure 2-6 depicts the structure of the Vertical Control Table (VCTAB). For clarity, the address and data path that allow the host to program the VCTAB are not shown.

NEO-2-12 BitFlow, Inc. Version G.5

Figure 2-6 Vertical Control Table

The Vertical Control Table is made up of the following blocks:

Acquisition and Camera Control The Control Tables (CTABs)

VCOUNT - a synchronous counter that can be incremented, loaded and reset. The

clock that drives VCOUNT is derived from the HCTAB, see below. VCOUNT is

17-bit wide and is connected to the address input of the VCTAB. Logic for generating INC_V - the increment control signal to the VCOUNT. Logic for generating LOAD_V - the load control signal to the VCOUNT. When

LOAD_V is asserted, VCOUNT is loaded with the value of 8000h (32,768 in

decimal). Logic for generating RESET_V - the reset control signal to the VCOUNT. When

RESET_V is asserted, VCOUNT is reset to 0. Logic for generating CLOCK_V - the clock to the VCOUNT. VCTAB - a static memory (SRAM) that outputs eight VCTAB control signals. The

address of this SRAM is driven by VCOUNT.

If RESET_V and LOAD_V are asserted simultaneously, RESET_V overrides.

As the VCOUNT increments, it scans the addresses of the VCTAB in ascending order. The output of the VCTAB depends on the data that has been written in the VCTAB by the host. If the VCOUNT is free running, it will cyclically scan all the VCTAB’s addresses. Any arbitrary cyclic waveform can be implemented by programming the VCTAB with the adequate data.

The LOAD_V and RESET_V will enable the synchronization between external events and the waveforms generated by the VCTAB. LOAD_V and RESET_V will force the VCOUNT to known values, 8000h and 0 respectively.

The INC_V signal will allow for stopping the counter from incrementing. In that case, the output of the VCTAB will be constant. While the VCOUNT is not incrementing, it can still be loaded or reset, see the logic below.

2.5.2 The VCTAB Functions

The functions assigned to the columns in the VCTAB are shown in Table 2-2.

Bit Name Function

0VSTARTStart of VAW

1 VRESET Vertical Reset

2 ENVLOAD FEN Mask, enable load

3 IRQ CTAB Interrupt

4 GPV0 General purpose vertical function 0

Table 2-2 The VCTAB Functions

5 GPV1 General purpose vertical function 1

6 GPV2 General purpose vertical function 2

7 GPV3 General purpose vertical function 3

Version G.5 BitFlow, Inc. NEO-2-13

The Control Tables (CTABs) The Neon

VSTART defines the start of the Vertical Acquisition Window (VAW), if the start is provided by the VCTAB, see previous section.

VRESET defines the reset of the VCOUNT, in case this function is programmed in the VCTAB.

ENVLOAD enables the FEN to load the VCOUNT. The rationale behind the ENVLOAD column from the VCTAB is that some cameras might not give a FEN, but only two pulses: the start and end of FEN. With the ENVLOAD, we can mask out the unwanted one.

IRQ provides an interrupt to the host, allowing an interrupt to occur at any point on the vertical axis.

GPV are general purpose vertical functions, see usage below.

Note: If a VRESET pulse happens coincident with a LOAD, the LOAD is overriding.

The CLOCK_V Control

CLOCK_V is the clocking of the VCOUNT is generated by the end of the line (horizontal reset).

The INC_V Control

INC_V is the logic for incrementing VCOUNT.

There are only two instances when we want to inhibit the incrementing of VCTAB. The first instance is when VCOUNT reaches 0000h, the “Stop at Zero” case. The other instance is when VCOUNT reaches 7FF0h, the “Vertical Stick” case.

Stop at Zero

Usually, VCOUNT will reach zero because of a RESET_V signal. After VCOUNT is reset, there are programmable options defined by VCNT_RLS_ZERO. Depending on this bitfield, VCOUNT can continue to count or wait at zero till some event occurs, usually the assertion of the TRIGGER.

This operating mode is especially useful for synchronizing cameras to external events. TRIGGER is usually the output of a part-in-place signal. Until this signal is asserted, the VCOUNT waits at address 0000h. After the TRIGGER is asserted, VCOUNT starts counting, i.e., scanning the VCTAB in ascending order. At some address we will program a sync signal to be sent to the camera, usually through GPV0. In response to this sync signal, the camera will give back a frame, and it will assert FEN. The FEN will load address 8000h into VCOUNT. In the VCTAB, we will program the vertical acquisition window to start after address 8000h. At the end of the vertical acquisition window the RESET_V will be asserted, which in turn will reset the VCOUNT. VCOUNT will wait at address 0000h until TRIGGER is asserted.

NEO-2-14 BitFlow, Inc. Version G.5

Acquisition and Camera Control The Control Tables (CTABs)

Vertical Stick

Using the previous example, assume that after we asserted the sync signal to the camera, we expect the camera to give us a frame, i.e., assert FEN. While we expect the camera to assert FEN, VCOUNT is still being incremented. If it takes too long for the camera to respond, VCOUNT will eventually reach and pass beyond 8000h. A vertical acquisition window will be asserted, even though the camera did not assert FEN. To avoid such a situation, just before address 8000h, when VCOUNT reaches 7FF0h, it will stop. It will stay at 7FF0h until FEN is asserted. Then, VCOUNT will be loaded with 8000h.

The Vertical Stick will occur according to the setting of VCNT_RLS_STK.

The LOAD_V Control

LOAD_V is the logic of loading VCOUNT. In other words, loading VCOUNT means it jump to a new address.

VCOUNT will be loaded with the value 8000h by the rising/falling edge of FEN, if ENVLOAD is asserted. FEN usually marks the start of a valid frame. The start of the vertical acquisition window can be placed starting at address 8000h.

ENVLOAD is a column in the VCTAB. There are cameras that do not assert FEN. Some other type of cameras assert only the start and stop of a frame. In this case, ENVLOAD can mask out the unwanted signals.

Operation on the rising/falling edge of FEN is selected by FENPOL, see CON14

The RESET_V Control

RESET_V is the logic of resetting VCOUNT.

VCOUNT can be reset from different sources, under different conditions. The resetting of the VCOUNT is controlled by the VCNT_RST bitfield.

2.5.3 Vertical Control Table Size

The Vertical Control Table has 20000h (131,972) entries.

2.5.4 Horizontal Control Table

The Horizontal Control Table (HCTAB) is 8 bits wide. The function of each bit is show in the following table.

Figure 2-7 depicts the structure of the HCTAB. For clarity, the address and data path that allow the host to program the HCTAB are not shown

Version G.5 BitFlow, Inc. NEO-2-15

The Control Tables (CTABs) The Neon

1:8

INCREMENT

LOGIC

LOAD

LOGIC

RESET LOGIC

RESET_H

LOAD_H

INC_H

ADDRESS

HCOUNT (COUNTER)

HCTAB (SRAM)

HCOUNT

CLOCK_H

HSTART

HRESET

ENHLOAD

Reserved

GPH0

GPH1

GPH2

GPH3

PCLK

Figure 2-7 Horizontal Control

The Horizontal Control Table is made up of the following blocks:

HCOUNT - a synchronous counter that can be incremented, loaded and reset.

The clock that drives HCOUNT is a free running clock, PCLK/8, i.e., the pixel clock divided by eight. HCOUNT is 15 bits wide and is connected to the address input of the HCTAB.

The 15 bit HCOUNT with the PCLK/8 can generate functions up to 256K PCLKs

long, on boundaries of 8 PCLKs.

The ACPL is 17 bit, and that can generate an HAW of up to 128K PCLKs. Logic for generating INC_H - the increment control signal to the HCOUNT. Logic for generating LOAD_H - the load control signal to the HCOUNT. When

LOAD_H is asserted, HCOUNT is loaded with the value of 2000h.

Logic for generating RESET_H - the reset control signal to the HCOUNT. When

RESET_H is asserted, HCOUNT is reset to 0.

HCTAB - a static memory (SRAM) that outputs eight HCTAB control signals. The

Note: If RESET_H and LOAD_H are asserted simultaneously, RESET_H overrides.

As the HCOUNT increments, it scans the address of the HCTAB in ascending order. The output of the HCTAB depends on the data that has been written in the HCTAB by the host. If the HCOUNT is free running, it will cyclically scan all the HCTAB’s addresses. Any arbitrary cyclic waveform can be implemented by programming the HCTAB with the adequate data.

address of this SRAM is driven by HCOUNT.

Logic for generating CLOCK_H - the clock to the HCOUNT. This is a frequency

divider. CLOCK_H is PCLK, the pixel clock divided by eight.

NEO-2-16 BitFlow, Inc. Version G.5

Acquisition and Camera Control The Control Tables (CTABs)

The LOAD_H and RESET_H will enable the synchronization between external events and the waveforms generated by the HCTAB. LOAD_H and RESET_H will force the HCOUNT to fixed values, 2000h and 0 respectively.

The INC_H signal will allow for stopping the counter from incrementing. In that case, the output of the HCTAB will be constant. While the HCOUNT is not incrementing, it can still be loaded or reset, see the logic below.

2.5.5 The HCTAB Functions

The functions assigned to the columns in the HCTAB are shown in Table 2-3.

Table 2-3 The HCTAB Functions

HCTAB Name Function

D0 HSTART Start of HAW

D1 HRESET Reset HCOUNT and increment the

VCOUNT

D2 ENHLOAD LEN Mask, enable horizontal load

D3 reserved

D4 GPH0 General purpose horizontal function 0

D5 GPH1 General purpose horizontal function 1

D6 GPH2 General purpose horizontal function 2

D7 GPH3 General purpose horizontal function 3

HSTART marks the start of the Horizontal Acquisition Window, HAW. Video will be acquired only while the HAW is active.

HRESET will reset the HCOUNT.

ENHLOAD will allow the loading of the HCOUNT. A location that has 1 will allow the loading of the HCOUNT. A 0 will inhibit the loading of the HCOUNT.

GPH are general purpose horizontal functions. See usage below.

The INC_H Control

INC_H is the logic for incrementing HCOUNT.

There are only two instances when we want to inhibit the incrementing of HCTAB. The first instance is when HCOUNT reaches 0000h, “Stop at Zero” case. The other instance is when HCOUNT reaches 1FF1h, the “Horizontal Stick” case.

Version G.5 BitFlow, Inc. NEO-2-17

The Control Tables (CTABs) The Neon

The “Stop at Zero” Case

Usually, HCOUNT will reach zero because of a RESET_H signal. After HCOUNT is reset, there are two programmable options:

HCOUNT keeps on counting. HCOUNT stays at zero until ENCODER is asserted.

The selection between the two options is done by the HCNT_RLS_ZERO bitfield, see next section on camera synchronization.

This operating mode is especially useful for synchronizing line scan cameras to external events. ENCODER is usually the output of an encoder or a tachometer signal. Until this signal is asserted, the HCOUNT waits at address 0000h. After the ENCODER is asserted, HCOUNT starts counting, i.e., scanning the HCTAB in ascending order. At some address we will program a sync signal to be sent to the scan camera, usually through GPH0. In response to this sync signal, the camera will give back a line, and it will assert LEN. The LEN will load address 2000h into HCOUNT. In the HCTAB, we will program the horizontal acquisition window after address 2000h. At the end of the horizontal acquisition window the RESET_H will be asserted, which in turn will reset the HCOUNT. HCOUNT will wait at address 0000h until ENCODER is asserted.

Horizontal Stick

Using the previous example, assume that after we asserted the sync signal to the camera, we expect the camera to give us a line, i.e., assert LEN. While we expect the camera to assert LEN, HCOUNT is still being incremented. If it takes too long for the camera to respond, HCOUNT will eventually reach and pass beyond 2000h. A horizontal acquisition window will be asserted even though the camera did not assert LEN. To avoid such a situation, just before address 2000h, when HCOUNT reaches 1FF0h, it will stop. It will stay at 1FF0h until LEN is asserted. Then, HCOUNT will be loaded with 2000h.

The LOAD_H Control

LOAD_H is the logic of loading HCOUNT.

HCOUNT will be loaded with the value 2000h by the rising/falling edge of LEN, if ENHLOAD is asserted. LEN usually marks the start of valid data in a line. The Horizontal Acquisition Window can be placed starting at address 2000h.

ENHLOAD is a column in the HCTAB that enables the LEN. There are cameras that do not assert LEN. In that case, the LEN input must be disabled, otherwise its behavior is unpredictable.

Operation on the rising/falling edge of LEN is selected by LENPOL, see CON14.

The RESET_H Control

RESET_H is the logic of reset HCOUNT.

HCOUNT can be reset from several sources, according to HCNT_RST bitfield, see next section on camera synchronization.

NEO-2-18 BitFlow, Inc. Version G.5

Acquisition and Camera Control The Control Tables (CTABs)

Example

Lets look at a simple example to clarify the concept of the HCTAB. Assume we want to program a free running horizontal window of 32 pixels active area. Just before the active area we want to fire a strobe using GPH0. D0 (HSTART) defines the start of the HAW. Bit D1 defines the reset of the HCOUNT. D4, GPH0, is the strobe pulse. The size of the HAW is programmed in ACLP register.

Taking into account that the address counter is clocked by 1/8 the pixel clock, the HCTAB memory map will be as shown in Table 2-4.

Table 2-4 HCTAB Example

HCTAB Address

0 0 0 0 You got here from address 9

1 0 0 0

2 0 0 0

3 0 0 1 Fire the strobe

4 0 1 0 Start Horizontal Acquisition

5 0 0 0 Acquire

6 0 0 0 Acquire

7 0 0 0 Acquire

8 0 0 0 Acquire

9 1 0 0 Assert RESET_H

10 0 0 0

The CT Functions

HRESET HSTART GPH0 Comments

Window

The CT’s are four functions derived from the HCTAB and the VCTAB. Those functions can define an arbitrary horizontal and/or vertical waveform. The definition of the CT’s is given below:

CT[0] = GPV[0] AND GPH[0] CT[1] = GPV[1] AND GPH[1] CT[2] = GPV[2] AND GPH[2] CT[3] = GPV[3] AND GPH[3]

Each CT has a vertical and a horizontal component. Both components are programmed in the CTABs. The minimum horizontal pulse is 8 PCLKs. The minimum vertical pulse is one line.

The CT’s can be steered to the Camera Controls (on the CL connectors) and to the GPOUTs, on the IO connector.

Version G.5 BitFlow, Inc. NEO-2-19

The Control Tables (CTABs) The Neon

2.5.6 Horizontal Control Table Size

The Horizontal Control Table has 8000h (32,768) entries.

NEO-2-20 BitFlow, Inc. Version G.5

Acquisition and Camera Control Synchronizing Acquisition, Camera, CTABs and External Signals

2.6 Synchronizing Acquisition, Camera, CTABs and External Signals

These boards have extremely flexible camera interfaces. They have been designed to acquire from almost any Camera Link camera and to synchronize with almost all industrial signals. There are two layers of synchronization. The first layer is to synchronize to signals coming from the industrial environment. For example triggers and encoders. The second layer is to synchronize to the camera. This requires both sending signals to the camera (e.g. exposure control) and receiving signals from the camera (e.g. Pixel Clock, Line Enable and Frame Enable). All of these synchronization problems are solved by the Control Tables (CTABs) and Vertical/Horizontal Operations. See previous section for detailed operation on the CTABs.

The Vertical and Horizontal Operations describe different state changes that the board goes through. For example one operation might be to begin acquiring pixels, another might be to reset the VCOUNT back to zero. Generally these state changes are caused by one or more events. There are a number of events, both horizontal and vertical, that the board can react to. These events are tied to operations by a set of programmable bitfields. The details of these events are outlined in this section.

2.6.1 Vertical Operations and Events

The vertical operations are related to the vertical axis of an image (in memory or on the display) or frame timing (of a camera). The operations are mainly commands to VCOUNT and acquisition commands. Each operation can be initiated by some event. The selection of the event that will initiate the specific operation is done by a set of three control bits related to each operation.

Table 2-5 is a list of the vertical operations and their related control bits.

Table 2-5 Vertical Operations

Vertical operation Control bits

VCOUNT frozen/released from 0000h VCNT_RLS_ZERO

VCOUNT reset to 0000h VCNT_RST

VCOUNT load with 8000h VCNT_LD

VCOUNT frozen/released from 7FF0h VCNT_RLS_STK

VCOUNT increment VCNT_INC

Acquire (SNAP, GRAB, CONTINUOUS) ACQ_CON

FREEZE acquisition FREEZE_CON

ABORT acquisition ABORT_CON

START vertical acquisition window VAW_START

Version G.5 BitFlow, Inc. NEO-2-21

Synchronizing Acquisition, Camera, CTABs and External Signals The Neon

Table 2-6 is a list of the events that initiate the vertical operations:

Table 2-6 Vertical Events

Event description Event Name

TRIGGER asserted TRIG_ASRT

TRIGGER de-asserted TRIG_DASRT

FEN asserted FEN_ASRT

FEN de-asserted FEN_DASRT

TRIGGER is HI TRIG_HI

TRIGGER is LO TRIG_LO

RESET from VCTAB RST_VCTAB

RESET from SW RST_SW

Host writes acquisition command HOST_WCMD_GRAB/SNAP

Acquisition frame counter reaches programmed value

What follows is a list of each operation and the corresponding events that can be used to cause the operation. Included is the bitfield settings for each operations. It is important to understand that each operation is independent and can be programmed without regard for how the other events are programmed. However, some combinations might not make sense.

VCOUNT Release From Zero

This operation controls the behavior of VCOUNT when it reached zero. See Table 2-7.

AQ_COUNT

Table 2-7 VCNT_RLS_ZERO

Initiator VCNT_RLS_ZERO Comments

None 0 Normal operation mode, no stop at

0000h

TRIG_ASRT 1 Edge Mode (aka Letter Mode), always stay

at 0000h, release on TRIG_ASRT

TRIG_HI 2 Level Mode (aka Luggage Mode), stay at

0000h if TRIG_LO, release on TRIG_ASRT

NEO-2-22 BitFlow, Inc. Version G.5

Acquisition and Camera Control Synchronizing Acquisition, Camera, CTABs and External Signals

VCOUNT Reset To Zero

This operation controls how VCOUNT is reset to zero. See Table 2-8.

Table 2-8 VCNT_RST

Initiator VCNT_RST Comments

End_of_VAW 0 Default operation, reset at end of VAW

TRIG_DASRT or End_ of_VAW

RST_VCTAB 2 Reset from VCTAB

FEN asserted or 3 Reset from start of FEN

TRIG_DASRT or RST_ VCTAB

TRIG_DASRT 5 Triggered termination

Note: The VCOUNT is always reset by the RST_SW (sofware reset ) and by the HOST_ WCMD_ABORT (host writes ABORT command).

VCOUNT Release From Stick Point (7FF0h)

This operation controls the behavior of VCOUNT when it hits the stick point. The purpose of the stick point is to allow for very long periods of time between frames. The stick point is located at 7ff0h. See Table 2-9.

1 Triggered termination

4 Triggered termination

Table 2-9 VCNT_RLS_STK

Initiator VCNT_RLS_STK Comments

None 0 Normal operation mode, no stop at

7FF0h

VLOAD or VRESET 1 Stick at 7FF0h till load (usually FEN)

or reset asserted

Version G.5 BitFlow, Inc. NEO-2-23

Synchronizing Acquisition, Camera, CTABs and External Signals The Neon

VCOUNT Load To 8000h

This operation controls how and when VCOUNT loads (jumps to) 8000h. See Table 2-

10.

Table 2-10 VCNT_LD

Initiator VCNT_LD Comments

None 0 No load

FEN_ASRT and ENVLOAD

FEN_ASRT 2 Assertion of FEN only

TRIG_ASRT 3 Assertion of TRIGGER

Acquisition Command Control

This operations controls how the acquisition commands get initiated. There are two major acquisition commands. The SNAP command, which only acquires one frame. The GRAB command, which continuously acquires frames until a freeze or abort command is issued. In addition, the board has a continuous data mode which is not frame oriented. In continuous data mode, the board will acquire data based only on the clock and data qualifying signals. There are no acquisition commands in this mode. See Table 2-11.

1 Assertion of FEN qualified with ENV-

LOAD

Table 2-11 ACQ_CON

Initiator ACQ_CON Comments

HOST_WCMD_GRAB/ SNAP

TRIG_ASRT 1 Triggered initiated GRAB/SNAP/

0 normal, host initiated GRAB/SNAP/

FREEZE

TRIG_ASRT and HOST_ WCMD_GRAB

TRIG_HI 3 Continuous data, wo. CTABs

Note: See also Section 2.7 for more details on the how the acquisition commands work.

NEO-2-24 BitFlow, Inc. Version G.5

2 Triggered SNAP

Acquisition and Camera Control Synchronizing Acquisition, Camera, CTABs and External Signals

Freeze Command Control

This operation is used to stop acquisition when the board is in GRAB mode. Acquisition will stop immediately if the board is between frames, or at the end of the current frame, if the board is in the middle of a frame. See Table 2-12.

Table 2-12 FREEZE_CON

Initiator FREEZE_CON Comments

HOST_WCMD_ FREEZE

AQ_COUNT or HOST_WCMD_ FREEZE

TRIG_DASRT 2 Trigger de-asserted

Abort Command Control

This operations terminates the current acquisition immediately. This operation will terminate both a SNAP and a GRAB command. If the board is in the middle of a frame, only part of the frame will be acquired. See Table 2-13.

0 Normal, host initiated

1 Acquisition counter reaches number of

frames programmed in the AQ_COUNT register

Table 2-13 ABORT_CON

Initiator ABORT_CON Comments

HOST_WCMD_ ABORT

TRIG_DASRT or HOST_WCMD_ ABORT

0 Normal, host initiated

1 Abort on falling edge TRIG or host com-

mand.

2.6.2 Horizontal Operations and Events

The horizontal operations and events are related to the horizontal axis (of an image in memory or on the display) or line timing (of a camera). The operations are mainly commands to HCOUNT. Each operation can be initiated by some event. The selection of the event that will initiate the specific operation is done by a set of three control bits related to each operation.

Version G.5 BitFlow, Inc. NEO-2-25

Synchronizing Acquisition, Camera, CTABs and External Signals The Neon

Table 2-14 lists the horizontal events.

Table 2-14 Horizontal Operations

Horizontal operation Control bits

HCOUNT released from zero HCNT_RLS_ZERO

HCOUNT reset to zero HCNT_RST

HCOUNT load with 2000h HCNT_LD

HCOUNT release from 1FF0h HCNT_RLS7F0

HCOUNT increment HCNT_INC

Start horizontal active window HAW_START

The events that can initiate the horizontal operations are listed in Table 2-15.

Table 2-15 Horizontal Events

Event description Event Name

ENCODER asserted ENC_ASRT

ENCODER de-asserted ENC_DASRT

LEN asserted LEN_ASRT

LEN de-asserted LEN_DASRT

ENCODER is HI ENC_HI

ENCODER is LO ENC_LO

RESET from HCTAB RST_HCTAB

RESET from SW RST_SW

FEN asserted FEN_ASRT

The sections below enumerate all of the horizontal operations and how the various events can initiate them. The control of each operation is independent from all of the others.

NEO-2-26 BitFlow, Inc. Version G.5

Acquisition and Camera Control Synchronizing Acquisition, Camera, CTABs and External Signals

HCOUNT Release From Zero

This operation controls the behavior of HCOUNT when it reached zero (see Table 2-

16).

Table 2-16 HCNT_RLS_ZERO

Initiator HCNT_RLS_

ZERO

None 0 Normal operation mode, no stop at zero

ENC_ASRT 1 One-shot mode, wait for encoder for

HCOUNT Reset To Zero

This operation controls how HCOUNT is reset to zero (see Table 2-17).

Comments

release

Table 2-17 HCNT_RST

Initiator HCNT_RST Comments

END_OF_HAW 0 Default operation, end of HAW

FEN_ASRT or RST_ HCTAB

RST_HCTAB 2 Reset from HCTAB

Note: The HCOUNT can always be reset by RST_SW or HOST_WCMD_ABORT

1 Reset on FEN_ASRT, Random FEN mode

HCOUNT Release From Stick Point (1FF0h)

This operation controls the behavior of HCOUNT when it hits the stick point. The purpose of the stick point is to allow for very long periods of time between lines. The stick point is located at 1ff0h. See Table 2-18.

Table 2-18 HCNT_RLS_STK

Initiator HCNT_RLS_STK Comments

None 0 Normal operation mode, no stop at

1FF0h

HLOAD or HRESET 1 Stay at x1FF0 till load (usually LEN) or

reset asserted

Version G.5 BitFlow, Inc. NEO-2-27

Synchronizing Acquisition, Camera, CTABs and External Signals The Neon

HCOUNT Load To 2000h

This operation controls how and when HCOUNT loads (jumps to) 2000h (see Table 2-

19).

Table 2-19 HCNT_LD

Initiator HCNT_LD Comments

None 0 No load

LEN_ASRT 1 Load on LEN assert, qualified with

ENHLOAD column

ENC_ASRT 2 Load on ENCODER assert, qualified with

ENHLOAD column

NEO-2-28 BitFlow, Inc. Version G.5

Acquisition and Camera Control Acquisition Command and Status

2.7 Acquisition Command and Status

This section describes how the acquisition state machine works. This state machine controls which frames from the camera are acquired and which are ignored. As the commands can be issued asynchronous to the camera’s timing, the acquisition state machine will remember the command and execute it starting at the beginning of the frame. That will guarantee that whole frames will be acquired. Note that the acquisition state machine only marks the frames to be acquired. The amount of pixels/line and lines/frame to be acquired in the marked frame is determined by the HAW and VAW, see section Section 2.4.

The acquisition state machine is controlled by the following signals:

AQCMD, the acquisition command bitfield

VACTIVE, the camera’s vertical active timing (usually FEN for area scan cameras)..

TRIGGER, the selected trigger.

ACQ_CON, a bitfield that defines special acquisition modes for the state machine.

The current state of the machine can be observed by the AQCMD and AQSTAT bitfields described below.

2.7.1 The Acquisition Bitfields

The acquisition command bits, AQCMD describe the command to be performed in the next frame. The acquisition status bits, AQSTAT, describe the current command that is performed. The four acquisition commands are described in the Table 2-20.

AQCMD Command Comment

0 (00b) FREEZE Stop acquiring at end of current frame

1 (01b) ABORT Stop acquiring immediately, unconditionally

2 (10b) SNAP Acquire one frame

3 (11b) GRAB Acquire continuously

The following list details the behaviors of these bitfields.

The AQSTAT bits are set at the beginning of the VACTIVE. The last instance a com-

mand can be issued is about 4 LCLKs before the start of the VACTIVE. For a SNAP command, when the SNAP starts, the AQCMD bits are cleared. Note

that for SNAP, the AQCMD bits are written by the host and cleared by the

state machine. If during a SNAP/GRAB operation another SNAP/GRAB command is issued, it is

ignored.

Table 2-20 ACQCMD

Version G.5 BitFlow, Inc. NEO-2-29

Acquisition Command and Status The Neon

Sn a p c o mman d w r i tten

AQCMD reset andAQSTAT set

AQSTAT reset

VACTIVE

AQCMD 2

AQSTAT 20

Table 2-11 below describes the acquisition modes for ACQ_CON

Table 2-21 ACQ_CON

ACQ_CON Mode Description

0 (000b) Host command performed on next frame

1 (001b) Host command issued when TRIGGER asserted

2 (010b) As long as GRAB command is on, a single frame will be SNAPped

at every assertion of the TRIGGER.

3 (011b) Continuous acquisition mode. Host commands are ignored. Data

will be acquired continuously as long as the TRIGGER is asserted.

Figure 2-8 shows a timing diagram of the SNAP command, with ACQ_CON = 0. The command is written by the host during the active frame. The acquisition will start at the beginning of the next frame.

Figure 2-8 Snap Command Timing

NEO-2-30 BitFlow, Inc. Version G.5

Figure 2-9 shows the timing of the GRAB operation with ACQ_CON=0. Figure 2-10 shows the timing of the ABORT operation with ACQ_CON=0. Note that the ABORT command will cut off part of the frame. This command is useful for resetting the board without having to wait for the end of the frame. Figure 2-11 shows a SNAP operation with ACQ_CON=1. In this mode, after the TRIGGER has been asserted and the command executed, the host must write a new command in the AQCMD field. Figure 2-12 shows acquisition in ACQ_CON=2 mode. Here, as long as the GRAB command is on, a frame will be acquired for every assertion of the TRIGGER. In this mode, there is no need for the host to write a new command.

Acquisition and Camera Control Acquisition Command and Status

Grab command written

AQSTAT set, grabbing starts

Freeze command written

AQSTAT reset, grabbing ends

VACTIVE

AQCMD 3

AQSTAT 30

VACTIVE

AQCMD 3

AQSTAT 30

Grab command written

AQSTAT set, grabbing starts

Abort command written

AQCMD reset, AQSTAT reset, grabbing ends

Figure 2-9 Grab Command Timing

Figure 2-10 Abort Command Timing

Version G.5 BitFlow, Inc. NEO-2-31

Acquisition Command and Status The Neon

Trigger asserts

Snap command written

AQCMD reset and AQSTAT set

AQSTAT reset

VACTIVE

AQCMD 2

AQSTAT

TRIG

200

Figure 2-11 Snap Command Timing with ACQ_CON = 2

NEO-2-32 BitFlow, Inc. Version G.5

Acquisition and Camera Control Acquisition Command and Status

Trigger asserts

Grab command written

AQSTAT set

AQSTAT reset

AQSTAT set

AQSTAT reset

VACTIVE

AQCMD

AQSTAT

TRIG

220

Figure 2-12 Grab Command Timing with ACQ_CON = 2

Version G.5 BitFlow, Inc. NEO-2-33

Trigger Processing (CL & Dif Models Only) The Neon

4:1

MUX

DELAY

LINE

TRIGGER_TTL

TRIGGER_DIF

TRIGGER_OPTO

FEN

XOR

TRIGGER_DELAY

EN_TRIGGER

SW_TRIG

SEL_TRIG

TRIGPOL

TRIGGER

2.8 Trigger Processing (CL & Dif Models Only)

Note: BitFlow CoaXPress models have a different triggering system. Please see the chapter on the CoaXPress I/O system for more information. This section only applies to Camera Link and Analog models.

Note: The Alta only has one trigger input: TRIGGER_TTL.

This section describes how the trigger circuit works. The trigger is used to initiate a vertical operation (for example, capturing one frame). There are three possible external hardware inputs to the trigger circuit and a software input. Assertion of the trigger can be delayed by up to 8192 lines (granularity is 8 lines). This delay works only with the external hardware trigger. Figure 2-13 illustrates the trigger circuit.

Figure 2-13 Trigger Circuit

NEO-2-34 BitFlow, Inc. Version G.5

Acquisition and Camera Control Encoder Processing (CL & Dif Models Only)

3:1

MUX

)

) $ % 2

ENCODER_TTL

ENCODER_DIF

ENCODER_OPTO

XOR

ENC_DIV

EN_ENCODER

SW_ENC

ENCODER

SELENC

ENCPOL

2.9 Encoder Processing (CL & Dif Models Only)

Note: BitFlow CoaXPress models have a different triggering system. Please see the chapter on the CoaXPress I/O system for more information. This section only applies to Camera Link and Analog models.

Note: The Alta does not have any encoder inputs.

This section describes how the encoder circuit works. The encoder is used to initiate a horizontal operation (for example, capturing one line). There are three possible external hardware inputs to the encoder circuit and a software input. The selected external encoder can be divided by the value in the ENC_DIV register. Figure 2-14 illustrates the encoder circuit.

Figure 2-14 Encoder Circuit

Version G.5 BitFlow, Inc. NEO-2-35

The On-Board Signal Generator The Neon

2.10 The On-Board Signal Generator

The on-board signal generator has been replaced by the New Timing Generator (NTG). Please see Section 3.1 for more information.

NEO-2-36 BitFlow, Inc. Version G.5

New Timing Generator Introduction

New Timing Generator

Chapter 3

3.1 Introduction

This section covers the new timing generator (NTG) which can control cameras connected to the Karbon, Neon and Alta. The purpose of this timing generator is to provide a simple system of controlling a camera’s exposure time and line/frame rate from the frame grabber. The NTG is fully programmable and is easily controlled from software and/or from camera configuration files.

The NTG is based on a completely independent timing generator that is unrelated to acquisition and the CTabs. This timing generator is easy to program, does not depend on camera architecture or triggering modes, and offers the granularity and range that customers need. There is no connection between the NTG and the acquisition state machine, the CTabs, the VAW/HAW or the camera connected.

The New Timing Generator supports both triggered and free running modes. For triggered modes it supports both the trigger signal for area cameras or the encoder signal for line cameras.

The NTG requires that the camera be put in one of two modes. If the NTG is going to control just the line/frame rate, then the camera should be programmed into a “triggered” mode. In this case, the exposure is controlled by the camera. IF the NTG is to control both the line/frame rate as well as the exposure time, then the camera must be put into a “pulse width control” mode. In this case, neither the line/frame rate nor the exposure time are controlled by the camera. They are both completely controlled by the NTG.

Note: The NTG replaces the on-board timing generator that was prevouisly available on all boards. The NTG is much more flexible and easier to use. Please contact BitFlow if you have been using the previous on-board timing generator.

Version G.5 BitFlow, Inc. NEO-3-1

Components and Control The Neon

3.2 Components and Control

3.2.1 Periods and Frequencies

The NTG consists of a programmable signal generator based on a crystal controlled clock. This clock is always running and is unrelated to the camera connected or how other parts of the board are programmed. The base frequency of the clock is designed to handle any line scan camera system. For area scan cameras the clock can be divided 128 to increase the time range if very slow frame rates and/or line exposures are needed. To use the divided clock, program the bit NTG_TIME_MODE to 1. The frequency of the clock is different for the different frame grabber families as shown in Table 3-1.

Table 3-1 NTG Base Frequencies

Family Base frequency Reduced frequency

Karbon, Neon 7.3728 MHz 57.6000 KHz

Alta-AN 5 MHz 39.0625 KHz

The are two main timing registers: NTG_RATE, which controls the line/frame rate period, and NTG_EXPOSURE, which controls the exposure period. These are both 28 bits, which should be enough to support almost all applications. Table 3-2 shows the resulting ranges

Table 3-2 NTG Period Ranges

Family Mode Granularity (1 clock period) Max Period

Karbon, Neon Area ~17.4 microsecond ~77 minutes

Line ~136 nanoseconds ~36 seconds

Alta-AN Area 25.6 microseconds ~114 minutes

Line 200 nanoseconds ~ 53 seconds

The NTG uses a counter internally to create the programmed waveforms. Because the NTG registers can be set for very long times, reprogramming the NTG can be time consuming. In order to speed up modifications to the NTG parameters, the register NTG_RESET can be used. Poke this bit to a 1 resets the NTG counter to zero, and starts a new cycle with the latest register values.

Note: Use the base frequency when a high resolution timer is needed (fine granularity). Use the reduced frequency when long exposure periods and/or slow frame rates are needed (course granularity) You can use which ever mode suits your application regardless of whether you are using a line scan or an area scan camera..

NEO-3-2 BitFlow, Inc. Version G.5

New Timing Generator Components and Control

3.2.2 Waveform polarity

There is also a register that inverts the waveform generated, NTG_INVERT. This is different than the old signal generator on the R64, which supports asserted-low signals by increasing the high time to be one-over-the-low time. The NTG system is much simpler, poke NTG_INVERT to a 1 and the waveform goes from asserted high to asserted low.

3.2.3 Triggering

The NTG has two modes of operation, free-running and one-shot mode. The bit that controls this mode is, NTG_ONESHOT. In free-run mode, both NTG_RATE and NTG_ EXPOSURE are used. In one shot mode, only NTG_EXPOSURE is used, and the rate is controlled by the encoder/trigger.

Either the trigger input or the encoder input can be used to control the NTG in oneshot mode. This setting is controlled by the bit NTG_TRIG_MODE.

3.2.4 Output Signals

The waveform of the NTG can be routed to almost any of the board’s output signals. The waveform can be send to the CC lines on the CL connector, or the GPOUT lines on the I/O connector. The CCx_CON bitfields can be used route the NTG signal to the CCs output. For example, program CC1_CON to 3 to get the NTG output on CC1. Similarly, the GPOUTx_CON bitfields can be used to route the NTG signals to the GPOUTx outputs. For example, to put the NTG output on GPOUT1, program GPOUT1_CON to 6. The NTG waveform can be sent simultaneously to any and all of these outputs.

3.2.5 Master/Slave Control

On boards that support more than one VFG there is the option to make the slave VFGs have the same timing as the master VFG, or to run each slave VFG’s timing generator independently. The master VFGs always has its own timing. The selection is made by programming the NTG_SLAVE bit. On a given VFG, if this bit is set to 0, the VFG generates its own independent timing. If this bit is set to 1, the VFG’s timing is the same as that of the master VFG.

Note: On multi-VFG boards, there is always a master and one or more slaves for programming purpose. The master VFG must always have the bit NTG_SLAVE set to 0. The slave VFGs can either be indpendent (NTG_SLAVE = 0) or the same as the master VFG (NTG_SLAVE = 1).

Version G.5 BitFlow, Inc. NEO-3-3

Timing The Neon

NTG

NTG_RATE

NTG_EXPOSURE

Free-Running

Trigger

Reset counter, Wait for next trigger pulse

One-shot

3.3 Timing

The following diagram illustrates all of the relevant parameters of the NTG.

Note: In the diagrams below NTG_INVERT is set to 0. If it were set to 1, these diagrams would be inverted.

NEO-3-4 BitFlow, Inc. Version G.5

Figure 3-1 NTG Timing

In free running mode, the NTG counter will start at zero, one clock later it will assert the output. It will then count up to NTG_EXPOSURE clocks, then de-assert the output. It will then continue to count to NTG_EXPOSURE clocks then reset itself and start over.

In one-shot mode, the NTG clock will wait at zero and until the trigger is asserted, it will then start counting. On the first clock after the trigger is asserted it will assert its output. It will then count up to NTG_EXPOSURE clocks then de-assert its output. Next it will reset itself and wait for another trigger.

New Timing Generator NTG Control Registers

3.4 NTG Control Registers

The following table summarizes the registers:

Table 3-3 NTG Control Registers

Name Locations Purpose

NTG_RATE CON17[27..0] The line/frame rate period in units of one NTG clock (see

Table 3-2 for values).

NTG_ONESHOT CON17[30] 0 = Free-run mode, 1= one-shot mode, waits for either the

trigger or the encoder pules (depending on NTR_TRIG_ MODE).

NTG_TRIG_MODE CON17[31] 1 = Encoder for NTG trigger,0 = Trigger for NTG trigger

NTG_INVERT CON18[30] 0 = NTG asserted high, 1 = NTG asserted low

NTG_TIME_MODE CON18[31] 0 = Base NTG clock, 1= Base NTG clock / 128 (see Table 3-1

for values)

NTG_EXPOSURE CON26[27..0] The exposure time in units of one NTG clock.

NTG_RESET CON26[30] Writing a 1 resets the NTG counter

NTG_SLAVE CON26[31] 0 = NTG master, 1 = NTG timing slaved to master

Version G.5 BitFlow, Inc. NEO-3-5

NTG Control Registers The Neon

NEO-3-6 BitFlow, Inc. Version G.5

Quadrature Encoder Introduction

Quadrature Encoder

Chapter 4

4.1 Introduction

This section discusses support for quadrature encoders. A quadrature encoder is an encoder that outputs two signals A and B. Both signals are used as a line trigger. However, the signals are 90 degrees out of phase. By comparing the A and B signals, the direction of the encoder motion can be determined. There are a number of ways that quadrature encoders can be used to control acquisition. The following sections cover all of the support methods.

Most of the quadrature encoder system is based around a 24-bit counter. This normally starts at zero and then counts up or down every time the encoder moves. The counter can be observed at any time via the QENC_COUNT register. This registers is the heart of the encoder system. For example, triggers values can be programmed to start and end acquisition of lines. Also, as the counter tracks the motion of the stage attached to the encoder exactly, the system can be programmed to only acquire forward only or backward only stage movements. The system can be be programmed to only acquire one line for each encoder count that corresponds to a physical location on the stage. The encoder counter can be used in many different ways, described in more details below.

4.1.1 Simple Encoder Mode

The most basic method of using a quadrature encoder is to use it like a standard signal phase encoder. In this mode, the quadrature encoder provides a higher resolution signal, as both the A and B signals can be used to trigger lines. Also, by setting QENC_DECODE = 1, both the rising and the falling edges of both the A and B signals are used to trigger lines, providing a 4x increase in resolution over a signal phase encoder.

In this mode, every encoder edge triggers a line, the direction information from the encoder is ignored.

4.1.2 Positive or Negative Only Acquisition

The board can be programmed to only acquired lines when the encoder moves forward (increase the encoder count in a positive direction) or moves backwards (decrease the encoder count in a negative direction). This mode is useful in situations where a stage is moving back and forth, and lines need only be acquired if the stage is moving in one direction only. The direction of acquisition is controlled by the QENC_AQ_DIR register.

Version G.5 BitFlow, Inc. NEO-4-1

Introduction The Neon

4.1.3 Interval Mode

Often in situations when a stage is moving back and forth, acquisition is only required over a subsection of the total stage range. Interval mode has been designed for these situations. When the board is in interval mode, it only acquires lines when the encoder counter is between a lower limit and an upper limit. If the counter is outside these limits, lines are not acquired.

To use interval mode, set QENC_INTRVL_MODE = 1, and program QENC_INTRVL_LL and QENC_INTRVL_UL to the encoder ranges that bracket the section of your stage range that you wish to acquire. Interval mode can be used in conjunction with QENC_ AQ_DIR to acquire lines passing over the interval in the positive direction, the negative direction or both directions.

4.1.4 Re-Acquisition Prevention

Encoders are usually connected to mechanical systems which do not always move smoothly. Because of these imperfections, there can be “jitter” in the quadrature encoder signal. This jitter is not an electrical imperfection, but represent the reality of the mechanical system vibrating, jumping, bouncing, etc. If these imperfections occur during the period of time where lines are being acquired, the image will be distorted. Lines on the object can be acquired more than once as the stage jitters. To prevent reacquisition of lines, a circuit has been added to the quadrature encoder system that can prevent any line from being acquired more than once. To enable this mode, set QENC_NO_REAQ = 1.

4.1.5 Scan Step Mode

The encoder can also be used to trigger acquisition of full frames from an area scan camera. The idea is that every N lines, a trigger is issued to the board, which causes acquisition of a frame. This can be used, for example, with a linear stage, where an image is needed in steps across the range of the stage. This mode is enable by setting SCAN_STEP_TRIG = 1, and programming SCAN_STEP to the number of encoder counts per trigger.

4.1.6 Combining Modes

All of the modes above can be combined to support complicated encoder requirements. For example, the board can be programmed to acquire an interval in the positive direction only, with no lines being reacquired. Many combinations are possible.

4.1.7 Control Registers

Starting with Section 4.3 all of the registers needed to control the qudrature encoder system are explained.

NEO-4-2 BitFlow, Inc. Version G.5

Quadrature Encoder Introduction

4.1.8 Observability

The status of the quadrature encoder system can be observed at any time. Shown in Table 4-1are all the registers that can be used.:

Table 4-1 Observability Registers.

QENC_COUNT Encoder counter

QENC_PHASEA Phase of input A

QENC_PHASEB Phase of input B

QENC_DIR Direction of encoder

QENC_INTRVL_IN Interval status

QENC_NEW_LINES Indicates new lines are being acquired

4.1.9 Electrical Connections

Both TTL and LVDS (differential) quadrature encoders are supported. TTL connections are shown in Table 4-2 and LVDS connections are shown in Table 4-3.

Table 4-2 TTL Quadrature Encoder Connections

Encoder Frame Grabber

A VFGx_ENCODER_TTL

B VFGx_ENCODER_B_TTL

Ground GND

Table 4-3 LVDS Quadrature Encoder Connections

Encoder Frame Grabber

A+ VFGx_ENCODER+

A- VFGx_ENCODER-

B+ VFGx_ENCODER_B+

B- VFGx_ENCODER_B-

Note: VFGx - refers to the VFG number that you wish to connect to. For example, if you want to connect a TLL A output to VFG 0, then you would use VFG0_ENCODER_TTL.

Version G.5 BitFlow, Inc. NEO-4-3

Understanding Stage Movement vs. Quadrature Encoder Modes The Neon

Time

Encoder Counter

These lines are acquired

These lines are not acquried

Corresponding Encoder Count vs. Time

Stage Movement

Stage

Direction of Motion

4.2 Understanding Stage Movement vs. Quadrature Encoder Modes

The quadrature encoder system has many modes that can be used in various combinations. These combinations are easier to understand through a few simple illustrations. Figure 4-1 shows the basic Encoder Count vs. Time graph and how it corresponds to stage movement. Keep in mind that the encoder could be attached to any mechanical system, however, a back and forth stage is a simple way to illustrate these modes.

In Figure 4-1 you can see as the stage moves back and forth, the encoder counts up and down. Further, in this example we assume QENC_AQ_DIR = 1, which tells the system to only acquire when the encoder counter is moving in the positive direction. This is illustrated by solid lines in the positive direction and dashed lines in the negative direction.

Figure 4-1 Encoder Count vs Time

NEO-4-4 BitFlow, Inc. Version G.5

Positive Negative Both

Acquisition Direction

Simple No Re-AcquireInterval

Not Valid

Zoom In

Mode

Quadrature Encoder Understanding Stage Movement vs. Quadrature Encoder Modes

Figure 4-2 shows all of the major quadrature encoder modes.

Version G.5 BitFlow, Inc. NEO-4-5

Figure 4-2 Quadrature Encoder Modes vs. Acquisition

CON15 Register The Neon

4.3 CON15 Register

Bit Name

0 QENC_INTRVL_LL 1 QENC_INTRVL_LL 2 QENC_INTRVL_LL 3 QENC_INTRVL_LL 4 QENC_INTRVL_LL 5 QENC_INTRVL_LL 6 QENC_INTRVL_LL 7 QENC_INTRVL_LL 8 QENC_INTRVL_LL 9 QENC_INTRVL_LL 10 QENC_INTRVL_LL 11 QENC_INTRVL_LL 12 QENC_INTRVL_LL 13 QENC_INTRVL_LL 14 QENC_INTRVL_LL 15 QENC_INTRVL_LL 16 QENC_INTRVL_LL 17 QENC_INTRVL_LL 18 QENC_INTRVL_LL 19 QENC_INTRVL_LL 20 QENC_INTRVL_LL 21 QENC_INTRVL_LL 22 QENC_INTRVL_LL 23 QENC_INTRVL_LL 24 QENC_DECODE 25 QENC_AQ_DIR 26 QENC_AQ_DIR 27 QENC_INTRVL_MODE 28 QENC_NO_REAQ 29 QENC_DUAL_PHASE 30 SCAN_STEP_TRIG 31 QENC_RESET

NEO-4-6 BitFlow, Inc. Version G.5

Quadrature Encoder CON15 Register

QENC_INTRVL_LLR/WR/W, CON15[23..0], Karbon, Neon

This register contains the lower limit value that is used to start acquisition when the system is in interval mode (see QENC_INTRVL_MODE).

QENC_DECODE R/W, CON15[24], Karbon, Neon

This bit determines how often the quadrature counter is incremented.

QENC_DECODE Meaning

0 Counter increments on the rising edge of input A

and the rising edge of input B. This is also called “2x” modes.

1 Counter increments on both the rising and falling

edge of A and both the rising and falling edge of B. This is also called “4x” mode.

QENC_AQ_DIR R/W, CON15[26..25], Karbon, Neon

This bit controls which quadrature encoder direction is used for acquisition.

QENC_AQ_DIR Meaning

0 (00b) Lines are acquired in both directions

1 (01b) Lines are acquired only in the positive direction.

2 (10b) Lines are acquired only in the negative direction.

3 (11b) Reserved

QENC_INTRVL_

R/W, CON15[27], Karbon, Neon

MODE

When this bit is 1, interval mode is turned on. When interval mode is on, lines are only captured when the encoder counter is between the lower limit (set by QENC_ INTRVL_LL) and the upper limit (set by QENT_INTRVL_UL). If the counter is outside of this range, lines are not acquired. Whether lines are acquired as the counter increments through the interval, or decrements through the interval, or in both directions are controlled by QENC_AQ_DIR.

QENC_NO_

R/W, CON15[28], Karbon, Neon

REAQ

This bit controls how the quadrature encoder system handles the situation where the encoder does not smoothly increase (or decrease if QENC_AQ_DIR = 1). If there is “jitter” in the encoder signal, often caused by problems with the mechanical systems, it is possible for the board to acquire the same line or lines more than once as the

Version G.5 BitFlow, Inc. NEO-4-7

CON15 Register The Neon

mechanical system backs up and moves forward (jitter). This re-acquisition can cause problems as the resulting images will have distortions and will not accurately represent the object in front of the camera.

Programming this bit to a 1 turns on the no-reacquisition circuit. This circuit eliminates this problem as each line in the image will only be acquired once, regardless of how much jitter occurs in the quadrature encoder input. The circuit does this by making sure that only one line is acquired for each encoder counter value. If the quadrature encoder backs up, and then moves forward, the board will not acquire lines until a new encoder counter value is reached.

This system handles any amount of jitter, regardless of how many times the counter passes through a value, or to what extremes the counter goes. New lines will only be acquired when new values are reached.

Once the entire frame has been acquired, the system must be reset. The system can always be reset by poking QENC_RESET to 1. There are also ways that the system can automatically be reset, see QENC_RESET_MODE.

QENC_NO_REAQ Meaning

0 Lines are acquired every change in the encoder

counter (as controlled by QENC_AQ_DIR)

QENC_DUAL_ PHASE

SCAN_STEP_ TRIG

1 Lines are only acquired when the encoder counter

reaches new values (also controlled by QENC_AQ_ DIR)

R/W, CON15[29], Karbon, Neon

This bit controls which type of encoder is attached.

QENC_DUAL_PHASE Meaning

0 A single phase encoder is attached

1 A quadrature encoder is attached

R/W, CON15[30], Karbon, Neon

The scan step circuit uses the encoder to generate a trigger to the system. The scan step trigger generates a trigger every N lines (N is set in the SCAN_STEP register).

SCAN_STEP_TRIG Meaning

0 Trigger comes of the normal source

1 Trigger comes from the scan step circuit

NEO-4-8 BitFlow, Inc. Version G.5

Quadrature Encoder CON15 Register

QENC_RESET WO, CON15[31], Karbon, Neon

Poking this bit to a 1 resets the entire quadrate encoder system.

Version G.5 BitFlow, Inc. NEO-4-9

CON16 Register The Neon

4.4 CON16 Register

Bit Name

0 QENC_INTRVL_UL 1 QENC_INTRVL_UL 2 QENC_INTRVL_UL 3 QENC_INTRVL_UL 4 QENC_INTRVL_UL 5 QENC_INTRVL_UL 6 QENC_INTRVL_UL 7 QENC_INTRVL_UL 8 QENC_INTRVL_UL 9 QENC_INTRVL_UL 10 QENC_INTRVL_UL 11 QENC_INTRVL_UL 12 QENC_INTRVL_UL 13 QENC_INTRVL_UL 14 QENC_INTRVL_UL 15 QENC_INTRVL_UL 16 QENC_INTRVL_UL 17 QENC_INTRVL_UL 18 QENC_INTRVL_UL 19 QENC_INTRVL_UL 20 QENC_INTRVL_UL 21 QENC_INTRVL_UL 22 QENC_INTRVL_UL 23 QENC_INTRVL_UL 24 QENC_REAQ_MODE 25 QENC_REAQ_MODE 26 QENC_RESET_REAQ 27 N/A 28 N/A 29 N/A 30 N/A 31 N/A

NEO-4-10 BitFlow, Inc. Version G.5

Quadrature Encoder CON16 Register

QENC_INTRVL_ULR/W, CON16[23..0], Karbon, Neon

This register contains the upper limit value that is used to start acquisition when the system is in interval mode (see QENC_INTRVL_MODE).

QENC_REAQ_ MODE

R/W, CON16[25..24], Karbon, Neon

This bit controls how the circuit that prevents re-acquisition from encoder jitter is reset. Re-acquisition is prevented by keeping a list of lines that have been acquired, and making sure that only lines that are not on the list are acquired. Once the entire frame is acquired, there must be some way to reset the list, otherwise no new lines will ever be acquired See QENC_NO_REAQ for more information.

The reset can be either automatic or manual. Manual modes require that the host application software poke the QENC_RESET_REAQ bit when the reset is desired. Automatic modes do not require host interaction, the reset will occur automatically when the specified conditions are met.

QENC_REAQ_MODE Mode Meaning

0 (00b) Manual Reset the list of acquired lines when

QENC_RESET_REAQ is poked to 1.

1 (01b) Automatic Reset the list of lines when the

encoder counter is outside of the interval set by the upper limit and lower limit. Whether the reset occurs above the upper limit or below the lower limit depends on the QENC_ AQ_DIR register.

QENC_RESET_ REAQ

2 (10b) Reserved

3 (11b) Reserved

WO, CON16[26], Karbon, Neon

This register is used to reset the circuit that prevents the re-acquisition of lines when QENC_NO_REAQ is set to 1. Writing a 1 to this register deletes the list of acquired lines, thus next time the lines are passed over, they will be acquired again. Writing to this bit always resets the no re-acquistion circuit, regardless of the mode set by the QENC_REAQ_MODE. However, the register QENC_REAQ_MODE can be used to set the board in a mode where the no re-aquisition circuit is reset automatically every pass over the image.

Version G.5 BitFlow, Inc. NEO-4-11

CON22 Register The Neon

4.5 CON22 Register

Bit Name

0 Reserved 1 Reserved 2 Reserved 3 Reserved 4 Reserved 5 Reserved 6 Reserved 7 Reserved 8 Reserved 9 Reserved 10 Reserved 11 Reserved 12 Reserved 13 Reserved 14 Reserved 15 Reserved 16 SCAN_STEP 17 SCAN_STEP 18 SCAN_STEP 19 SCAN_STEP 20 SCAN_STEP 21 SCAN_STEP 22 SCAN_STEP 23 SCAN_STEP 24 SCAN_STEP 25 SCAN_STEP 26 SCAN_STEP 27 SCAN_STEP 28 SCAN_STEP 29 SCAN_STEP 30 SCAN_STEP 31 SCAN_STEP

NEO-4-12 BitFlow, Inc. Version G.5

Quadrature Encoder CON22 Register

SCAN_STEP R/WO, CON22[31..16], Karbon, Neon

This bitfield controls the number of encoder pulses that must occur before a trigger is issued to the system. See SCAN_STEP_TRIG for more information. The Scan Step circuit takes into account the interval and re-acquisition functions.

Version G.5 BitFlow, Inc. NEO-4-13

CON51 Register The Neon

4.6 CON51 Register

Bit Name

0QENC_COUNT 1QENC_COUNT 2QENC_COUNT 3QENC_COUNT 4QENC_COUNT 5QENC_COUNT 6QENC_COUNT 7QENC_COUNT 8QENC_COUNT 9QENC_COUNT 10 QENC_COUNT 11 QENC_COUNT 12 QENC_COUNT 13 QENC_COUNT 14 QENC_COUNT 15 QENC_COUNT 16 QENC_COUNT 17 QENC_COUNT 18 QENC_COUNT 19 QENC_COUNT 20 QENC_COUNT 21 QENC_COUNT 22 QENC_COUNT 23 QENC_COUNT 24 QENC_PHASEA 25 QENC_PHASEB 26 QENC_DIR 27 QENC_INTRVL_IN 28 QENC_NEW_LINES 29 Reserved 30 Reserved 31 Reserved

NEO-4-14 BitFlow, Inc. Version G.5

Quadrature Encoder CON51 Register

QENC_COUNT RO, CON51[23..0], Karbon, Neon

This bitfield displays the current quadrature encoder count.

QENC_PHASEA RO, CON51[24], Karbon, Neon

This bit displays the current logic level of the A quadrature encoder phase.

QENC_PHASEB RO, CON51[25], Karbon, Neon

This bit displays the current logic level of the B quadrature encoder phase.

QENC_DIR RO, CON51[26], Karbon, Neon

This bit displays the current quadrature encoder direction.

QENC_DIR Meaning

0 Direction is negative

1 Direction is positive

QENC_INTRVL_INRO, CON51[27], Karbon, Neon

This bit indicates the current status of the quadrature encoder if the system is in interval mode (see QENC_INTRVL_MODE).

QENC_INTRVL_IN Meaning

0 System is not inside the interval. Encoder counter is

not between QENC_INTRVL_LL and QENC_INTRVL_ UL. Lines are not being acquired.

1 System is inside the interval. Encoder counter is

between QENC_INTRVL_LL and QENC_INTRVL_UL. Lines are being acquired.

Version G.5 BitFlow, Inc. NEO-4-15

CON51 Register The Neon

QENC_NEW_ LINES

RO, CON51[28], Karbon, Neon

This bit indicates if the system is at an encoder count that corresponds to a new line. When QENC_NO_REAQ = 1, only lines that have not yet been scanned are acquired. This bit can be used to determine of new lines are being traversed, or if the system has backed up, and is revisiting old lines.

QENC_NEW_LINES Meaning

0 The system is traversing lines that have already been

visited. If QENC_NO_REAQ = 1, lines are not being acquired.

1 The system is traversing new lines. Lines are being

acquired.

NEO-4-16 BitFlow, Inc. Version G.5

Encoder Divider Introduction

Encoder Divider

Chapter 5

5.1 Introduction

This section covers the encoder divider which supported on the Karbon and the Neon Families. The purpose of Encoder Divider is to provide the ability to use an encoder running at one rate to drive a line scan camera at a different rate. This circuit is only useful for line scan cameras. The Encoder Divider can scale up or down the incoming encoder frequency. The encoder divider is fully programmable and is easily controlled from software and/or from camera configuration files.

The factor used to scaled the incoming encoder frequency does not have to be a whole number. For example, the encoder could be scaled by 0.03448 or 4.2666). Of course not all ration numbers in the available scaling range can be selected (there are an infinite number of them). However, a useful selection of values is available which should support most applications.

The Encoder Divider circuit takes as its input the selected encoder input (controlled by the register SELENC). The output of the encoder divider drives the same parts of the board the normal encoder usually does. The actual circuit(s) being driven depends on how the board is programmed. However, the Encoder Divider circuit can drive any of the following:

Horizontal CTAB (HCNT_RLS_ZERO = 1) NTG (NTG_ONESHOT = 1, NTG_TRIG_MODE = 1)

Note: The Encoder Divider circuit described in this chapter replaces the previous circuit which could only divide the incoming encoder by an integer value and could not increase the encoder frequncy. Please contact BitFlow if you have been using the previous on-board encoder divider.

Version G.5 BitFlow, Inc. NEO-5-1

Encoder Divider Details The Neon

out

-------

5.2 Encoder Divider Details

5.2.1 Formula

The following formula shows the equation used to scale the encoming encoder rate into the camera’s line rate:

Where:

Fout = The frequency used to driver the camera or the NTG or the CTabs Fin = The encoder (input) frequency N = An integer between 0 and 6 (set by the register ENC_DIV_N) M = An integer between 1 and 1023 (set by the register ENC_DIV_M)

5.2.2 Example

5.2.3 Restrictions

The above formula provides an effective scaling factor from 0.001 (N = 0, M =1023) to 64 (N = 6, M = 1). Not every scaling factor can be acheived between these two extremes, and the scaling factors are not evenly distributed. However, a scaling factor can be generally found that meets the requirments of most applications.

Let’s assume that the encoder frequency (Fin) is 10 KHz and that we need an output (Fout) of ~30 KHz. This means that we need to multiply by 3. Set N = 6 and M = 21. This will a scaling factor of 3.048. The result is an effective line rate of 30.48 KHz.

Because the encoder divider uses a digital PLL run by a 50 MHz clock, not all encoder input frequencies can be accurately scaled. The PLL has been designed to work in most machine visions applications. Support, therefore, is provided for the following inpute frequency range:

Minimum input encoder frequency: 1.6 KHz Maximum input encoder frequency: 300 KHz

NEO-5-2 BitFlow, Inc. Version G.5

Encoder Divider Encoder Divider Details

out

---------

5.2.4 PLL Locking

The encoder divider achieves its scaling using a PLL. By default the output waveform is locked to the input waveform. However, this locking can result in a small amount of jitter. To reduce the jitter, the output waveform can be run open loop. This mode is accessed by setting the register ENC_DIV_OPEN_LOOP to 1.

5.2.5 Handling Encoder Slow Down or Stopping

On some machine vision systems, the encoder is attached to a mechanism that may slow and/or stop. Any PLL has a limited range that it can track (based on the PLL master clock), outside of this range, the output signal can become unpredictable. The Encoder Divider circuit’s master clock is 50 MHz, which makes the minimum frequency that it can accurately track around 1.6 KHz. In order to avoid this situation and handle encoder slow down/stop gracefully, the encoder divider has has limiting circuit that can be run in one of two different mode described in the following two sections.

Slow Tracking Mode (ENC_DIC_FORCE_DC = 0)

In this mode, when the input frequency goes below the minimum of 1.6 KHz, the Encoder Divider circuit’s output will continue to track the input, but the output frequency will become simple divider on the input freqency. In this mode the output will track the input using the following formula (the variables are the same as in Section

5.2.1)

DC Mode (ENC_DIV_FORCE_DC = 1)

In this mode, the Fin goes below 1.6 KHz, Fout will goes to DC. This means that when the input frequency goes below the minium, the camera will be frozen, acquisition will stop. The board will stay in this state until Fin goes above 1.6 KHz. This is useful when the encoder is being driven by a stage that is travelling back and forth. At both ends of travel when the stage changes directions, the board will not acquire.

Version G.5 BitFlow, Inc. NEO-5-3

Encoder Divider Control Registers The Neon

5.3 Encoder Divider Control Registers

The following table summarizes the registers:

Table 5-1 Encoder Divider Registers

Name Locations Purpose

ENC_DIV_M CON6[27..18] This controls the M factor in the Encoder Divider equation

(see Section 5.2.1

ENC_DIV_N CON19[18..17] The controls the N factor the Encoder Divider equation

ENC_DIV_FORCE_DC CON16[27] Controls the behavior when Fin falls below the minimum.

0 = Output runs in simple divider mode. 1 = Output goes to DC.

ENC_DIV_OPEN_LOOP CON16[28] Controls whether the output signal phase of the Encoder

Divider is lock to the intput or is allowed to free run. 0 = Output phased locked to input. 1 = Ouput runs open loop.

ENC_DIV_FCLK_SEL CON16[31..29] Reserved for future support for alternate Encoder Divider

PLL Master clock frequencies. Currently must be set to 0, which selects 50 MHz clock.

NEO-5-4 BitFlow, Inc. Version G.5

Power Over Camera Link (PoCL) Introduction

Power Over Camera Link (PoCL)

Chapter 6

6.1 Introduction

This chapter describes the Power Over Camera Link (PoCL) support of the Neon-CL frame grabber. PoCL is a Camera Link standard designed to provide power to the camera from the frame grabber over the camera link cable. In order for this to work, all of the following must be true:

The frame grabber must be PoCL capable The camera must be a PoCL camera The cable must be PoCL compliant

If any of the above are not true, the camera will not be powered, and acquisition will not be possible.

The PoCL standard is described in version 1.2 and later of the Camera Link Specification. The standard is available from the Automated Imaging Association. Please see their web site for more information.

The PoCL standard is designed to be backwards compatible with existing equipment. See Section Table 6-1 for more information.

The PoCL standard provides 12 volts of power at up to 0.5 amps. Overcurrent protection is provided, as well as a variety of other safety features designed to protect all equipment in the system. See Section 6.3 for more information on equipment protection.

There are a number of registers on the Neon that are part of the PoCL system. Some of the registers provide control over PoCL and other provide feedback on the status of the PoCL system. See Section 6.4 for more information.

Version G.5 BitFlow, Inc. NEO-6-1

PoCL Compatibility The Neon

6.2 PoCL Compatibility

PoCl is designed to be backward compatible with existing equipment. PoCL backwards compatibility is designed to provide previous existing functionality, however, it should be obvious that power cannot be provided using non-PoCL equipment. Table 6-1 provides more information on compatibility.

Table 6-1 PoCL Compatibility

PoC L Camera Non-PoCL

Camera

PoCL frame grabber + PoCL Cabl e

PoCL frame grabber + Non-PoCL Cable

Non-PoCL frame grabber + PoCL Cabl e

Non-PoCL frame grabber + Non-PoCL Cable

Note: In the table above “Yes” means the combination will work and images will be acquired. “No” means the combination will not work and no images will be acquired, but no damage will occur to any of the equipment. Please see Section 6.3 for more information.

In summary, the only way to use a PoCL camera is with a PoCL frame grabber and PoCL cable. However, with non-PoCL cameras, any combination will work. Finally, even if the particular combination does not work, nothing will be damaged should the combination be plugged in.

Yes Yes

No Yes

NEO-6-2 BitFlow, Inc. Version G.5

Power Over Camera Link (PoCL) PoCL Safe Power

6.3 PoCL Safe Power

The PoCL specification is fairly simple in that it only described the amount of power that should be provided, which CL cable lines the power should be applied and that an over current protection device should be used on the power lines. It was quickly realized, however, that this specification was inadequate for the real world. This simple specification could lead to many different kinds of problems if proper frame grabber/cable/camera combinations were not always used. In the real world, engineers use whatever resource they have at hand to solve problems. With PoCL specification as it stood, many combinations could result in damage equipment.

The camera link committee decided to add a optional component to the specification called “Safe Power”. The safe power system would take an active role in testing any equipment connected and make sure everything was PoCL compliant before applying power. The goal being if any legacy equipment was plugged into a PoCL frame grabber, the power would never be applied because the frame grabber could detect that the equipment was not PoCL compliant.

The Safe Power system uses a state machine which proceeds though a number of tests before applying power. If any of the tests fail, the power is not applied. Also, if a power camera is removed, the safe power system detects this situation and goes back to a non-powered state. Figure 6-1 shows the state of the PoCL safe power system.

It is important to understand the board powers up with the PoCL system turned off. The PoCL system will not start up, and no power will be applied to any connector until the register POCL_EN is set to 1. This is an extra safety feature that gives the user complete control PoCL system. Also, this lets the board act as a normal CL frame grabber in situations where non-PoCL camera is being used.

The principle of safe power is that the state machine (once it is turned on) first tries to detect if a PoCL camera is attached or not. This is done by detecting the impedance of the camera with a very small voltage. Non-PoCL equipment will test one way and PoCL equipment will test another way. Once it is determined that a PoCL camera is attached, the frame grabber applies power. There is a small waiting time while the camera boots, then the state machine look for the clock coming back from the camera. If the clock is detected, the state machine goes into running mode. If at any point in time, the clock is lost (e.g. the camera is disconnected), the system falls back to the Sense state, looking for a camera. There is a over current circuit which acts like a fuse, if too much current is detected, the system shuts down power, and the board exits the PoCL normal state (resets POCL_EN). In order to recover from an over current event, the POCL_EN bit must be set to 1 again.

Version G.5 BitFlow, Inc. NEO-6-3

PoCL Safe Power The Neon

Power

Check

Mode

PoCL =

GND

POCL_EN_ = 0

Sense

POCL_EN = 1

PoCL =

Power

PoCL Camera Detected

Wait for surge (0.5 S)

Wait for clock (3.0 S)

Check

for

clock

No Clock

Running PoCL =

Power

Clock Detected

No Clock

PoCL =

GND

Legacy Camera/Cable

POCL_EN = 1

Check

for

clock

No Clock

Running

PoCL =

GND

Clock Detected

No Clock

EN_PO WER =

Fuse Blows

POCL_EN = 0

Fuse Blows

Wait for

clock

(3.0 S)

Fuse Blows

Figure 6-1 PoCL State Diagram

NEO-6-4 BitFlow, Inc. Version G.5

Power Over Camera Link (PoCL) PoCL Control Registers

6.4 PoCL Control Registers

The following registers are used as part of the PoCL state machine:

POCL_EN - this register turns on or off the PoCL state machine POCL_POWER_ON - indicates the PoCL power is turned on POCL_GND_ON - indicates the PoCL lines have been grounded POCL_CLOCK_WAIT - indicates that the PoCL state machine waiting for the clock

from the camera

POCL_SENSE - indicates that the PoCL state machine is looking to sense PoCL

equipment

POCL_CLK_DETECTED - indicates that the clock has been detected coming back

from the camera

POCL_DETECTED - indicates that the PoCL camera has been detected.

Only the register POCL_EN is a user programmable bit. The other registers are useful for determining the current state of the PoCL state machine.

The bitfield POCL_EN is located the CON0 register. The other bitfields are all located in the CON38 register.

Version G.5 BitFlow, Inc. NEO-6-5

PoCL Control Registers The Neon

NEO-6-6 BitFlow, Inc. Version G.5

System Status Introduction

System Status

Chapter 7

7.1 Introduction

This chapter describes the system status report that the board supplies through its registers. The system status will help the users in setting up their system: the camera, the frame grabber, the cabling, the I/O and the software. The list of the status bits is given in the Table 7-1. If more information is available for a given specification there will be an entry in the column marked “Details”. In addition, all of these registers are also described in Register Map chapter of this manual.

Table 7-1 Status Bits

Status Bits Function and Relationship Register Details

AQSTAT Acquisition status CON3 Section 8.6

FACTIVE Acquisition status, vertical

active

FCOUNT Acquisition status, 3-bit frames

counter

LCOUNT Camera status, LEN is toggling CON4 Section 7.3

PCOUNT Camera status, PCLK is toggling CON4 Section 7.3

FENCOUNT Camera status, FEN is toggling CON4 Section 7.3

RD_TRIG_DIFF/TTL/OPTO Trigger status CON5 Section 7.4

RD_ENC_DIFF/TTL/OPTO Encoder status CON5 Section 7.4

TRIG_QUALIFIED Selected trigger status CON6 Section 7.5

VCOUNT Acquisition status, VCTAB

cycling

HCOUNT Acquisition status, HCTAB

cycling

LINES_TOGO Acquisition status, current line

in frame

FIFO_EQ Camera status, video value CON20 Section 7.7

CON3 Section 7.2

CON6 Section 7.6

CON19 Section 7.6

DEST_ADD DMA running CON22 Section 7.8

Version G.5 BitFlow, Inc. NEO-7-1

FACTIVE, FCOUNT The Neon

7.2 FACTIVE, FCOUNT

FACTIVE is 1 during the active vertical. It works for both area scan and line scan comeras. For both line scan and area scan cameras there is always a vertical size defined by ALPF.

FCOUNT is a 3-bit frame counter that is incremented by the rising edge of FACTIVE. It can be used to track acquisition, especially in triggered modes. FCOUNT works for both area scan and line scan cameras.

NEO-7-2 BitFlow, Inc. Version G.5

System Status PCOUNT, LCOUNT, FENCOUNT

7.3 PCOUNT, LCOUNT, FENCOUNT

These three registers give an indication of the status the camera connected to the main connector:

PCOUNT is a 2-bit counter clocked by the camera’s PCLK. Reading a constant value from this register indicates that the camera’s clock does not reach the acquisition circuitry.

LCOUNT is a 2-bit counter clocked by the camera’s LEN. Reading a constant value from this register indicates that the camera’s LEN does not reach the acquisition circuitry.

FENCOUNT is a 2-bit counter clocked by the camera’s FEN. Reading a constant value from this register indicates that the camera’s FEN does not reach the acquisition circuitry.

Version G.5 BitFlow, Inc. NEO-7-3

RD_TRIG_DIFF/TTL/OPTO, RD_ENC_DIFF/TTL/OPTO The Neon

7.4 RD_TRIG_DIFF/TTL/OPTO, RD_ENC_DIFF/TTL/OPTO

The level of all trigger and encoder inputs can be read at any time. This helps establish connection with external industrial equipment.

NEO-7-4 BitFlow, Inc. Version G.5

System Status TRIG_QUALIFIED

7.5 TRIG_QUALIFIED

The bit TRIG_QUALIFIED is the current active state of the current selected trigger. The trigger is selected by the SEL_TRIG register. Each individual input can be monitored via the corresponding RD_TRIG_XXX bit, but the TRIG_QUALIFIED always reports the state of the trigger input that is current being used by the acquisition circuitry.

Version G.5 BitFlow, Inc. NEO-7-5

VCOUNT, HCOUNT, LINES_TOGO The Neon

7.6 VCOUNT, HCOUNT, LINES_TOGO

These three registers give feedback about the operation of the horizontal and vertical CTABs. VCOUNT is the address counter of the VCTAB. This register indicates the current VCTAB address.

HCOUNT is the 2 LSB of the HCTAB address counter. This register indicates only if the HCTAB is cycling. Reading a constant value on HCOUNT indicates that the HCTAB address is stuck.

LINES_TOGO specifies how more many lines there are till the end of the frame.

NEO-7-6 BitFlow, Inc. Version G.5

System Status FIFO_EQ

7.7 FIFO_EQ

This register gives the 8-bit value of the video from the first eight bits of the main connector. It is helpful to determine if the camera is reacting to light. Covering the camera’s lens will yield a low value in this register. Pointing the camera to a light source will yield a high value in this register.

Note: This register is not available on all models.

Version G.5 BitFlow, Inc. NEO-7-7

DEST_ADD The Neon

7.8 DEST_ADD

This register gives the DMA destination address. During acquisition, this register should change. Reading a constant value from this register suggests that the DMA operation is not progressing.

NEO-7-8 BitFlow, Inc. Version G.5

Camera Control Registers Introduction

Camera Control Registers

Chapter 8

8.1 Introduction

This section enumerates all of the bitfields in all of the registers used to control the acquisition and external I/O. If you compare the Alta, Karbon, Neon and R64 manuals you will see that almost all of these registers are the same. There are only a few bits that are different between these two models, these will be indicated in the bitfield definitions. Registers that are related to DMA operations have their own chapters.

All of the registers are 32 bits wide. These wide registers are named CON0, CON1, etc. Each registers is broken into one or more bitfields. Bitfields can be from one to 32 bits wide. Each bitfield controls a specific function on the board.

Version G.5 BitFlow, Inc. NEO-8-1

Bitfield definitions The Neon

8.2 Bitfield definitions

8.2.1 Example Bitfield Definition

Here is what each bitfield definition looks like:

BITFIELD R/W, CON0[7..0], Alta, Karbon-CL, Karbon-CXP, Neon, R64

Bitfield discussion.

8.2.2 Bitfield Definition Explanation.

The definitions is broken into three sections (see Table 8-1).

Table 8-1 Bitfield Sections.

Section Meaning

Bitfield name This is the name of the bitfield. This name is use to program

this bitfield from software or from within and camera configuration file. When programming bitfields from software using a Peek or Poke function, the bitfield is preceded with “REG_”. For example the bitfield CFREQ is referred to in software as REG_CFREQ.

Bitfield details This section describes how the bitfield is accessed. The first

part describes the how the bits can be accessed. For example R/W means the register can be both read and writen. See theTable 8-2 for details.The second part is the wide register that the bitfield is located in. In the example above this bitfield is in CON0. Following the wide register name is a bitfield location description, in hardware engineering format. For example, [7..0], means the bitfield has 8 bits, location in positions 0 to 7. Finally this section also indicates if the register is specific to only one product family.

Bitfield discussion This section explains the purposed of the bitfield in detail.

Usually meaning of every possible value of the bitfield is listed.

NEO-8-2 BitFlow, Inc. Version G.5

BitFlow NEO-PCE-CLB, NEO-PCE-CLD, NEO-PCE-CLQ, NEO-PCE-DIF Hardware Reference Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Table of Contents

Preface

P. 1 P u r p o s e

General Description and Architecture

1.1 The Neon

1.2 NEO-PCE-CLB General Description

1.3 NEO-PCE-CLD General Description

1.4 NEO-PCE-CLQ General Description

1.5 NEO-PCE-DIF General Description

1.6 Virtual vs Hardware Frame Grabbers

Acquisition and Camera Control

2.1 Introduction

2.2 BitFlow’s Flow-Thru Architecture

2.3 Camera Specific Firmware for Camera Link Models (CL Models Only)

2.4 Generation of Acquisition Windows

2.5 The Control Tables (CTABs)

2.6 Synchronizing Acquisition, Camera, CTABs and External Signals

2.7 Acquisition Command and Status

2.8 Trigger Processing (CL & Dif Models Only)

2.9 Encoder Processing (CL & Dif Models Only)

2.10 The On-Board Signal Generator

New Timing Generator

3.1 Introduction

3.2 Components and Control

3.3 Timing

3.4 NTG Control Registers

Quadrature Encoder

4.1 Introduction

4.2 Understanding Stage Movement vs. Quadrature Encoder Modes

4.3 CON15 Register

4.4 CON16 Register

4.5 CON22 Register

4.6 CON51 Register

Encoder Divider

5.1 Introduction

5.2 Encoder Divider Details

5.3 Encoder Divider Control Registers

Power Over Camera Link (PoCL)

6.1 Introduction

6.2 PoCL Compatibility

6.3 PoCL Safe Power

6.4 PoCL Control Registers

System Status

7.1 Introduction

7.2 FACTIVE, FCOUNT

7.3 PCOUNT, LCOUNT, FENCOUNT

7.4 RD_TRIG_DIFF/TTL/OPTO, RD_ENC_DIFF/TTL/OPTO

7.5 TRIG_QUALIFIED

7.6 VCOUNT, HCOUNT, LINES_TOGO

7.7 FIFO_EQ

7.8 DEST_ADD

Camera Control Registers

8.1 Introduction

8.2 Bitfield definitions