The BitScope Virtual Machine

All commands execute in the context of a set of byte wide registers:

Register addresses are expressed in bracketed hexadecimal notation, for example:

Reg	Hex	Name
R0	[00]	Data Register
R1	[01]	Address Registers
R134	[86]	General Purpose Register 134
R201	[c9]	General Purpose Register 201

Data is expressed in the same way.

Eg. [10] means the number 16 and [da] means the number 218.

Every VM command token is echoed back to the host to acknowledge its execution. Most commands execute and acknowledge within the time it takes to receive the next command (aka the "command window").

This simple protocol means that in most cases no other form of flow control is required because the command echo itself can be used; no "out of band" signalling is required (e.g. no XON/XOFF or RTS/CTS etc).

It also means that any octet stream comms link can be used quite easily either in half duplex or full duplex mode. For example, any serial link including RS-232, 1-wire, USB, TCP or UDP can be used from a protocol perspective.

There are some commands that may not execute within the command window (because they have more work to do than can be completed within that time). There are others that produce data after the command echo which must be received and there are others that take an indeterminate period of time to complete (e.g. trace command D which will not complete until a trigger or timeout occurs). It is therefore important to distinguish between these types of commands and use them appropriately.

Type	Example Commands	Description
Simple	[ ] 0 a @ s z .	Guaranteed to execute within the command window. May be concatenated into strings without waiting for each command to be acknowledged. For example [08]@[12]z[34]z[56]z[78]s
Delayed	X Y Z U >	These commands may take longer than the command window to execute. This means they must appear at the end of the command string. For example [08]@[12]z[34]z[56]z[78]s> where the > command must not be followed by any other command until its reply is acknowledged.
Complex	T D A S p !	These commands produce additional data following the acknowledge and therefore must only ever appear at the end of a command string and their payload data must be received by the host before any further commands are issued to the VM. What the payload data is depends on the command and how it's being used. The host knows this (it programmed the command) and it must act accordingly. So [08]@[12]z[34]z[56]z[78]s>D is legal but [22]@[d2]>DA is not (because the D command must be acknowledged and its payload received before the A command can be issued).

All ASCII characters are commands.

A sub-set of these commands are used exlusively for data entry.

Data entry commands "assemble the data" in Data Register R0 as follows:

Character	Action
[	Clear R0. Usually commences byte entry. (optional)
0..9..f	Left shift R0 4 bits and write the specified digit to the lower nibble.
]	NOP. Concludes byte entry. (optional)

For example, to put the value 193 into the data register R0 simply requires the following command string: [c1]. This implicitly results in the [??] notation used for representing data values where ?? are the hex digits of the value.

Register programming means to assign values to set registers other than R0 and R1.

There are two command defined specifically for this purpose:

Character	Action
@	Set Address Register R1.
s	Store the value in R0 to the register pointed at by R1.

When a value is assembled in the data register R0 it may be used to address another register via R1 by:

For example to program the value 184 to register R69: [45]@[b8]s

That is, the modus operandi for register programming is:

[XX]@[YY]s

where XX is the (lower case) hexadecimal register address and YY is the byte value to be stored there.

Most registers are used to control the operation of the device.

Once a value is written it does not change.

However, other registers may be used to report value which are changed by the VM itself or shared between multiple clients of the VM. In these cases (and for debugging) it is necessary to be able to read register values:

Character	Action
p	Print the register pointed to by R1.

The p command prints the value of the register pointed to by R1 as a carriage return bounded hexadecimal value:

<CR>XY<CR>

where XY are two ascii characters representing the register value.

The carriage returns are a convenience; it means you can talk to the VM using a standard terminal and read back any register value required, for example:

[45]@p

to read the value of register R69 which would per the earlier example return

<CR>ba<CR>

Everything needed to program and view register values can be done using commands already described. However, there are a number of commands and shortcuts which can simplify the addressing and programming of VM registers, especially multi-byte registers.

These are listed in the Command Chapter but two of the most useful are:

Character	Action
z	Store value in R0 and increment the value of R1.
n	Increment Address Register

Sets of adjacent registers are used by some VM commands to represent 16, 24 or 32 bit values. They are arranged in little-endian order and the z command makes their programming easy. For example, to program the 32 bit value 305, 419, 896 to the 32 bit register set R80 to R83 can be done as follows:

[50]@[78]z[56]z[34]z[12]s

This can be further simplified in most VM versions because the [ and ] commands are optional:

50@78z56z34z12s

The [ and ] commands will usually be used throughout the remainder of this document for clarity and portability. They are also often used in driver code to parse command string templates (used to generate command strings).

There are a few special commands reserved for or used by the VM (in all versions):

Command	Action
?	Print a <CR> delimited 8 character string identifying the VM version.
!	Soft VM reset, stop active operations, terminate command sequence.
.	Terminate a command sequence (with optional context switch).

Use of these commands is optional but ? is recommended (to confirm the VM version being used) and ! or . to stop the device from active operations and return it to its quiescent (i.e. low power) state when required.

The primary functions of BitScope are:

1. High speed analog and logic waveform capture to internal buffers
2. Acquisition of previously captured data from those buffers to the host
3. Lower speed continuous streaming capture to the connected host device
4. Generation of analog and logic waveforms, voltages and clocks

Different models offer different performance characteristics but all devices include these functions.

Most BitScopes offer a range of secondary functions including:

1. Providing power, ground, clocks and control signals to connected circuits
2. Storing and recalling persistent values from on-board FLASH (e.g. calibration coefficients)
3. Driving various physical indicators including LEDs and control voltages
4. Communicating and controlling connected Smart POD devices (using VM byte-code)
5. Performing post-capture signal processing such as decimation and filtering

Not all BitScopes include all of these functions but this is indicated elsewhere in this document.

Viewed as a generic virtual machine, the register map is simply a set of 256 byte-wide registers where the first two registers (R0 and R1) and a small sub-set of commands have functionality dedicated to the operation of the VM itself.

All the other registers are defined and used in the context of the BitScope commands that perform the waveform capture, generation and acquisition functions of the device. These are managed in command groups follows:

Group	Description
Core	Core Virtual Machine functionality (R0, R1)
Entry	Data entry commands and registers ([ , ], 0..9..f)
RegOps	Register operations to store, print and manage registers (s, p, z)
Trace	Frame based high speed waveform and logic capture (D & C)
Stream	Continuous streaming waveform and logic data capture (T)
Acquire	High speed data acquisition to the host (S and A, usually user after a Trace)
Generate	Programmable voltage, waveform, clock and logic/protocol pattern generation.
System	System commands to control host communications with the BitScope.
I/O	Smart POD I/O commands for communicating with connected peripherals.
Flash	Access to BitScope's onboard persistent storage.

In addition to the command groups, registers may be further classified as follows:

Group	Description
Spock	High speed capture hardware control registers (< and > commands).
Config	Pre-op hardware configuration registers, automatically applied.
Gen	Waveform and logic generator control registers (R, W, X, Y, and Z commands).
Comms	Baud rate control for host communications (only some models).
Update	Pre-op hardware configuration registers requiring the U command.

There are many registers associated with programming each of BitScope's functions so the command and register tables at the end of this document are defined in terms of these command and register groups.

Using VM10 (BS10) one can control the intensity of the front panel LEDs via their respective registers:

Group	Register	N	A	Description
System	vrLedLevelRED	1	[fa]	Red LED Intensity
System	vrLedLevelGRN	1	[fb]	Green LED Intensity
System	vrLedLevelYEL	1	[fc]	Yellow LED Intensity

To turn the RED LED on to full intensity:

[fa]@[ff]s

To turn it off (note: it will continue to glow very dimly to indicate that BS10 has power applied):

[00]s

and to enable it at low intensity:

[10]s

Note that it's not necessary to reprogram R1 each time, it already has the correct value from the first call. Also, the short-cuts (omitting [ and ]) mean turning all three LEDs on can be done as:

fa@ffzffzffs

or even:

fa@ffzzs

and off again as:

fa@00zzs

Note that in this case it is necessary to reprogram the address register because the z commands modified it. All register programming is as simple as this but unlike most, this example has results that are immediately visible (the LEDs turning on and off).

The core set of registers used to program a trace are:

Group	Register	N	A	Description
Trace	vrTraceMode	1	[21]	Trace Mode
Trace	vrClockTicks	2	[2e]	Master Sample (clock) period (ticks)
Trace	vrClockScale	2	[14]	Clock divide by N (low byte)
Trace	vrTraceIntro	2	[26]	Pre-trigger capture count (samples)
Trace	vrTraceOutro	2	[2a]	Post-trigger capture count (samples)
Trace	vrTraceDelay	4	[22]	Delay period (us)
Trace	vrTimeout	2	[2c]	Auto trace timeout (auto-ticks)

The most important register is vrTraceMode.

It selects the method by which the device will perform the trace.

The trace mode automatically selects the associated clock and buffer modes used which in turn define the available sample rates and capture channels. For example the tmMixedChop trace mode selects ckChop and bmChopDual clock and buffer modes. See the trace mode table for the full list of trace modes and associated clock and buffer modes.

When the trace mode is selected the sample rate is programmed via the vrClockTicks and vrClockScale registers. With reference to the clock mode table, the vrClockTicks register must be programmed with a value within the clock tick limits defined for the selected clock mode. A "tick" is a divisor of the master clock (40 MHz) to produce the desired sample rate. In some modes this may be further divided via the vrClockScale register.

The sample rate (Fs) used for the trace can therefore be calculated as:

Fs = 40 MHz / (vrClockTicks * vrClockScale)

Next the duration of the post trigger capture is programmed via vrTraceOutro (expressed in sample units at the programmed sample rate) and (optionally) the pre-trigger capture duration via vrTraceIntro (also in samples).

The post trigger duration is very important because it defines the minimum number of samples the trace will acquire after the trigger. Depending on the trigger event more samples than vrTraceIntro samples may be acquired but at least this number is guaranteed to be captured (so long as the sum of both registers does not exceed the buffer size).

If the trace is to start the data capture at some point in time after the trigger event, the duration of this post- trigger delay may be specified via the vrTraceDelay register. Unlike the intro and outro registers, this value is expressed in microseconds (not samples). When a non-zero value is used for trace delay means there will be a discontinuity in the captured data at the trigger point because capture ceases (for vrTraceDelay microseconds) before resuming (for vrTraceOutro samples).

An optional (auto trace) timeout may also be specified via vrTimeout. The best way to understand the steps involved to set up a trace is to work through an example, in this case an analog signal is captured for 1.76mS following a rising edge zero crossing sampled at 1MHz on Channel A:

[7b]@[80]s                      # KitchenSinkA* (enable hardware comparators)
[7c]@[80]s                      # KitchenSinkB* (enable analog filter)
[fb]@[00]s                      # LedLevelGRN (turn CHB LED off, VM10 only)
[fc]@[c0]s                      # LedLevelYEL (turn CHA LED on, VM10 only)
[37]@[01]s                      # AnalogAnable (enable CHA input circuits)
[64]@[28]s[65]@[1c]s            # ConvertorLo (set convertor range, low side)
[66]@[c1]s[67]@[b5]s            # ConvertorHi (set convertor range, high side)
[14]@[01]s[15]@[00]s            # ClockScale (set clock prescaler)
[2e]@[28]s[2f]@[00]s            # ClockTicks (set clock divider)
[31]@[00]s                      # BufferMode (choose the capture buffer mode)
[21]@[00]s                      # TraceMode (choose the trace mode)
[22]@[00]s[23]@[00]s            # TraceDelay (set post trigger delay, low)
[24]@[00]s[25]@[00]s            # TraceDelay (set post trigger delay, high)
[26]@[80]s[27]@[00]s            # TraceIntro (set pre-trigger capture count)
[2a]@[e0]s[2b]@[06]s            # TraceOutro (set post-trigger capture count)
[06]@[7f]s                      # TriggerMask (set the trigger logic mask)
[05]@[80]s                      # TriggerLogic (program the trigger logic)
[32]@[04]s[33]@[00]s            # TriggerIntro (set trigger hold-off filter duration)
[34]@[04]s[35]@[00]s            # TriggerOutro (set trigger hold-on filter duration)
[44]@[00]s[45]@[00]s            # TriggerValue (set digital trigger level, optional)
[68]@[f5]s[69]@[68]s            # TriggerLevel (set analog trigger level)
[07]@[20]s                      # SpockOption* (choose edge triggered comparator mode)
[2c]@[00]s[2d]@[00]s            # Timeout (specify a timeout, forever in this case)
[3a]@[00]s[3b]@[00]s            # Prelude (set the buffer default value; zero)
[08]@[00]s[09]@[00]s[0a]@[00]s  # SampleAddress (assign the trace start address)
>                               # (program capture hardware registers)
U                               # (programming other hardware registers)
D                               # commence the trace!

Normally, the trace will be triggered. The registers used are:

Group	Register	N	A	Description
Spock	vrSpockOption	1	[07]	Spock Option Register
Trace	vrTriggerIntro	2	[32]	Edge trigger intro filter counter (samples/2)
Trace	vrTriggerOutro	2	[34]	Edge trigger outro filter counter (samples/2)
Trace	vrTriggerValue	2	[44]	Digital (comparator) trigger (signed)
Update	vrTriggerLevel	2	[68]	Trigger Level (comparator, unsigned)
Trace	vrTimeout	2	[2c]	Auto trace timeout (auto-ticks)

First choose the trigger type, source, edge and channel swap via vrSpockOption register. Next set up the trigger filter parameters via the vrTriggerIntro and vrTriggerOutro registers. Finally, assign the level via vrTriggerValue (if using SALT) or vrTriggerLevel (if using COMP).

If the trace should trigger when no trigger event is seen, put a non-zero value (in auto-tick) in the vrTimeout register.

The values used for the trigger intro and outro define the number of samples the signal must be seen to be FALSE followed by the number of samples it must be seen to be TRUE for a trigger event to be registered.

The minimum intro is zero but the minimum outro must be one or more. If the intro is set to zero it means the trigger will occur as soon as it is seen to be true (i.e. it will effectively be a LEVEL trigger not an EDGE) trigger. The recommended default for both registers is 4. This will ensure that the signal must be in the trigger false condition for at least 4 samples followed by the true condition for another 4 samples. This will reject most noise and glitches appearing in the signal. For a hair trigger use the values 1 and 2 or for greater noise rejection (but slower trigger) values larger than 4.

While tracing and upon completion, the D command returns a series of status packets that look like this.

02           # stWait (trace started)
41b799c8     # timestamp
00           # stDone (trace complete)
41b8d784     # timestamp
000007eb     # address

Each packet comprises a status token (e.g. stWait, stDone) followed by one or more payload fields. Each token and all the fields that follow are delimited by carriage return characters.

The set of all status tokens and their payloads returned by the D and K commands are:

Name	Token	Payload	Description
stDone	0	timestamp, address	trace complete (normally)
stAuto	1	timestamp, address	trace terminated (timed out)
stWait	2	timestamp	trace in progress (waiting for trigger)
stStop	3	timestamp, address	trace terminated (manually, K command)

The D command always returns stWait immediately (to report when the trace actually commenced). When the trace completes normally the stDone token is returned or if a timeout occurs or the trace is terminated the stAuto or stStop tokens is returned instead.

Every packet reports a timestamp and most report a buffer capture address as well.

BitScope applies a timer to all trace operations. The timer is maintained to very high precision (25 ns) regardless of the sample rate used for the trace and it is reported (as a timestamp) each time a status packet is returned. It is reported as a 32 bit value in units of 25 ns ticks.

The timer operates continuously and rolls over in epochs of approximately 107 seconds. The host can synchronise its own time of day with the timer via timestamps to reconcile the epoch periodically (once a minute or more often is recommended).

In many applications timestamps may be ignored. However, they are very useful if performing multiple high speed episodic waveform captures where all the results need to be precisely time referenced to each other. This is exceptionally useful in data acquisition, remote telemetry and phase coherent monitoring applications.

When performing a trace the acquired signal data is written to a high speed internal capture buffer. The number of channels and data types captured depends on the buffer mode used by the selected trace mode but in all cases the buffer is circular. Acquisition continues "forever" (oldest data is overwritten by the newest) until the specified trigger event, a timeout or a cancellation event occurs.

The buffer address to which the next sample is written is to be written is maintained by the vrSampleAddress register. This register may be manually programmed (normally to start at "zero") but it need not be. It may also be read (via the vrSampleCounter register) but usually this is usually not necessary either because its value is reported as the address payload in the stDone, stAuto and stStop status packets upon completion of a trace.

This address is used to calculate the starting point of the captured data when uploading it to the host. Important: the address is that of the next sample to be written. Upon trace completion this address must be "rewound modulo the buffer size" by the number of post trigger samples requested for the trace (i.e. vrTraceOutro=samples). This value is then written to =vrSampleAddress prior to issuing the dump command to acquire the data.

If a trace is initiated which never triggers (either because the trigger condition programmed for the trace is incorrect or the expected event never occurs) the trace will never complete. To prevent this a timeout can be used to force an "auto trace" or the trace can be cancelled manually (and signals captured up until that point may then be acquired).

Trace termination is achieved in one of two ways:

If a non-zero value is assigned to the vrTimeout register a timeout down-counter is activated upon trace start which counts in "auto ticks". When the count reaches zero a timeout event occurs. This is identical to a trigger event in that the trace terminates and the completion data is returned but the stAuto token is returned instead of stDone. A timeout tick period is 6400 nS and vrTimeout is 16 bits which supports a maximum timeout of 419 ms. If a timeout longer than this is required the K command must be issued to terminate the trace instead.

The buffer address vrSampleAddress and the buffer mode vrBufferMode registers are shared with the trace command D and perform the same functions. Once programmed (for a trace) they may not need to be changed for the dump A when dumping the entire buffer to the host. To dump only part of the buffer the (start) sample address may be programmed each time the dump is performed to start at the trigger point or some point before the trigger.

BitScope offers a range of dump modes which define how data is uploaded to the host:

Name	Token	Format	Description
dmRaw	0	unsigned 8 bit	raw dump (send/skip ignored)
dmBurst	1	unsigned 8 bit	decimated send burst, skip block (depreciated)
dmSummed	2	signed 16 bit	decimated (skip), summed (send)
dmMinMax	3	unsigned 8+8 bit	decimated (skip), min/max (send)
dmAndOr	4	unsigned 8+8 bit	decimated (skip), and/or (send)
dmNative	5	signed 1.15 bit	raw dump (send/skip ignored)
dmFilter	6	signed 1.15 bit	decimated (skip), decimated & filtered (send)
dmSpan	7	signed 1.15 bit	decimated (skip), min/max (send)

The default and recommended mode is dmRaw which is used in the examples. The other modes are documented later.

BitScope can trace multiple channels simultaneously but one normally dumps them one at a time. The dump channel register vrDumpChan specifies which of several channels to dump next.

Type	H	Index	Value	Description
Analog	0	0..127	0..127	Analog channel index
Logic	1	0..126	128..254	Logic channel index
Diagnostic	1	127	255	Diagnostic channel

There are only two analogue channel indexes (0 and 1) and eight logic (128..135). The other values are reserved for models with different numbers of channels.

The dump count vrDumpCount specifies how many (optionally decimated) samples to dump from the device. How many samples are read from the buffer depends on the decimation ratio and may be more than the count but the number of samples returned to the host will always been the count.

The number of dumps (of size vrDumpCount) may be repeated as specified by vrDumpRepeat. Normally this register will be set to one. If more than 2\^16 samples are required (i.e. on devices with larger buffers) and/or if a dump needs to be broken down into smaller chunks (e.g. to meet MTU requirements of the host link), this register may be used.

The send vrDumpSend and skip vrDumpSkip registers specify a decimation ratio to apply when dumping data. This is a convenience and bandwidth optimizing feature; it means that only a (useful) data sub-set needs to be dumped to the host. The data that is actually sent to the host depends on the dump mode.

The following sub-set of the VM registers are used for waveform, clock and logic pattern generation:

Group	Register	N	A	Description
Gen	vpCmd	1	[46]	Command Vector
Gen	vpMode	1	[47]	Operation Mode (per command)
Gen	vpOption	2	[48]	Command Option (bits fields per command)
Gen	vpSize	2	[4a]	Operation (unit/block) size
Gen	vpIndex	2	[4c]	Operation index (eg, P Memory Page)
Gen	vpAddress	2	[4e]	General purpose address
Gen	vpClock	2	[50]	Sample (clock) period (ticks)
Gen	vpModulo	2	[52]	Modulo Size (generic)
Gen	vpLevel	2	[54]	Output (analog) attenuation (unsigned)
Gen	vpOffset	2	[56]	Output (analog) offset (signed)
Gen	vpMask	2	[58]	Translate source modulo mask (unused)
Gen	vpRatio	4	[5a]	Translate command ratio (phase step S15.16)
Gen	vpSymmetry	2	[5a]	Synthesize Symmetry (U0.8)
Gen	vpRise	2	[82]	Rising edge clock (channel 1) phase (ticks)
Gen	vpFall	2	[84]	Falling edge clock (channel 1) phase (ticks)
Gen	vpControl	1	[86]	Clock Control Register (channel 1)
Update	vrKitchenSinkB	1	[7c]	Kitchen Sink Register B (Waveform Output Enable, Bit 6)
Update	vpMap	1	[99]	Clock Output Enable ([00] > disabled, =[12] => enabled)

Before generating a waveform the wavetable must be created. There are two ways to do this:

The waveforms that can be synthesized using the Y command cover all the primary function generator applications; sinusoid, sawtooth triangle and square waves, steps, impulses and exponential decays and ramps. Using the Y command is atomic and instantaneous and is recommended for most waveform and function generation purposes:

vpCmd	vpMode	Function	Size	Bits	Description
0	0	SINE	1024	8	Sinusoidal Waveform
0	1	RAMP	1024	8	Triangle/Sawtooth Waveforms
0	2	EXPN	1024	8	Exponential Waveform
0	3	STEP	1024	8	Square/Impulse Waveforms
0	0	SINE	512	16	Sinusoidal Waveform
0	1	RAMP	512	16	Triangle/Sawtooth Waveforms
0	2	EXPN	512	16	Exponential Waveform
0	3	STEP	512	16	Square/Impulse Waveforms

The alternative to the synthesize command Y is the write command W. With this command a completely arbitrary waveform of up to 1024 samples per period can be generated. The SYNTHESIZE step can be replaced with DOWNLOAD as:

[7c]@[40]sU                                  # KitchenSinkB (Enable generator output)

[46]@[00]s[47]@[01]s                         # vpCmd, vpMode (8-bit write, wavetable target)
[4a]@[01]s[4b]@[00]s                         # vpSize (Write operation size, 1 sample)
[4e]@[00]s[4f]@[00]s                         # vpAddress (Destination Address, wavetable start)

[01]W[02]W[03]W…                             # write values (01,02,03 to wavetable, 1000 times)

[4a]@[e8]s[4b]@[03]s                         # vpSize (Operation size, 1000 samples)
[4c]@[00]s[4d]@[00]s                         # vpIndex (Operation Index, table start)
[4e]@[00]s[4f]@[00]s                         # vpAddress (Destination Address, buffer start)
[54]@[ff]s[55]@[ff]s                         # vpLevel (Output Level, full scale)
[56]@[00]s[57]@[00]s                         # vpOffset (Output Offset, zero)
[5a]@[93]s[5b]@[18]s[5c]@[04]s[5d]@[00]s     # vpRatio (Phase Ratio)
[46]@[00]s[47]@[00]sX                        # vpCmd, vpMode, TRANSLATE!

[48]@[04]s[49]@[80]s                         # vpOption (control flags)
[50]@[28]s[51]@[00]s                         # vpClock (Sample Clock Ticks)
[52]@[e8]s[53]@[03]s                         # vpModulo (Table Modulo Size)
[5e]@[0a]s[5f]@[00]s                         # vpMark (Mark Count/Phase)
[60]@[01]s[61]@[00]s                         # vpSpace (Space Count/Phase)
[78]@[00]s[79]@[7f]s                         # vrRest (DAC Level)
[46]@[02]s[47]@[00]sZ                        # vpCmd, vpMode, GENERATE!

When the wavetable has been synthesized and translated to the play buffer the generator can started and stopped:

vpCmd	vpMode	Action	Description
1	0	Stop	Stop waveform generator and clock.
2	0	Start	Start waveform generator and clock.
3	0	Clock	Start clock (without waveform generator).

When the waveform generator is running the clock is also running internally. If you wish to generate the clock but not produce any analog waveform, use the Clock sub-command instead of Start sub-command.

The clock generator is part of the waveform generator. It may be enabled or not but when the waveform generator is running the clock is used internally to generate the sample clock. When used this way the clock generator is limited to the D/A sample rate, typically 1MHz. When used on its own it can run up to 20MHz (via the Clock sub-command). There are in fact up to three clock channels, all of them running from the same master clock but each of which can be routed to a different output pin and operate at a different phase, e.g. it's easy to produce quadrature phase clocks or generate edge-to-edge logic timing across up to three logic channels.

The modus operandi for clock generation is to:

The best way to understand the steps involved is to see an example, in this case to generate a 4kHz clock:

[99]@[12]sU                                  # vpMap (Enable clock 1 on output L5)
[50]@[10]s[51]@[27]s                         # vpClock (Master clock ticks per period, 20)
[82]@[00]s[83]@[00]s                         # vpRise (Rising Edge at tick 0)
[84]@[88]s[85]@[13]s                         # vpFall (Falling Edge at tick 10)
[86]@[80]s                                   # vpControl (Enable clock source 0)
[46]@[03]s[47]@[00]sZ                        # vmCmd (Command Vector), GENERATE!

To simplfy range programming the following command strings produce the tabulated ranges.

The kitchen sink registers provide control flags for these features.

The onboard peripherals can be mapped to logic signals.

Trace Mode	M	Type	Mode	Trig	Clock	Buffer
tmAnalog	0	analog	single	mask	ckMixed	bmSingle
tmAnalogFast	4	analog	single	mask	ckMixedFast	bmSingle
tmAnalogShot	11	analog	single	mask	ckMixedShot	bmSingle
tmMixed	1	mixed	single	mask	ckMixed	bmDual
tmMixedFast	5	mixed	single	mask	ckMixedFast	bmDual
tmMixedShot	12	mixed	single	mask	ckMixedShot	bmDual
tmLogic	14	logic	single	mask	ckLogic	bmSingle
tmLogicFast	15	logic	single	bit	ckLogicFast	bmSingle
tmLogicShot	13	logic	single	mask	ckLogicShot	bmSingle
tmAnalogChop	2	analog	chop	mask	ckChop	bmChop
tmAnalogFastChop	6	analog	chop	mask	ckChopFast	bmChop
tmAnalogShotChop	16	analog	chop	mask	ckChopShot	bmChop
tmMixedChop	3	mixed	chop	mask	ckChop	bmChopDual
tmMixedFastChop	7	mixed	chop	mask	ckChopFast	bmChopDual
tmMixedShotChop	17	mixed	chop	mask	ckChopShot	bmChopDual
tmMacro	18	analog	single	mask	ckMacro	bmMacro
tmMacroChop	19	analog	chop	mask	ckMacro	bmMacroChop

See Trace Setup for information about how to use trace modes.

Trace	M	C	F	B	T	Fs	Link	Comment
tmSteamAny	0	-	1	8	24	1666667	1666667	Link speed test mode
tmStreamRaw	2	ANY	1	8	67	597015	597015	Single 8 bit channel, fastest
tmStreamAll	1	ALL	5	8	114	350877	1754385	Mixed signal, 1, 2 or 3 channels
tmStreamOne	4	A/B	2	12	125	320000	640000	Single 12 bit channel (on-board)
tmStreamTwo	3	A+B	4	12	241	165975	663900	Dual 12 bit channel (on-board)

See data acquisition for information about how to use stream modes.

Cmd	V	Mode	M	Operation
zvStop	1	zmStop	0	Stop Generator (reset phase, mute output)
zvStop	1	zmPause	1	Pause Generator (hold output)
zvPlay	2	zmStart	0	Start Generator
zvPlay	2	zmContinue	1	Continue Generator
zvPlay	2	zmOneShot	2	Play Generator (one shot)
zvClock	3	zmClock	0	Generate clock signal

The buffer mode defines the layout and addressing of the buffer memory used for data capture. The buffer mode is selected automatically (via the chosen trace mode) when performing a trace but it must be explicitly selected (via the vrBufferMode register) when performing a dump. It's possible (but not recommended) to dump data in a different buffer mode than which it was traced (advanced use only). For each buffer mode the address range, layout and trace modes that select it are shown in this table:

Mode	M	Size	Units	Layout	N	Trace Modes
bmSingle	0	12k	Full	12k	1	tmAnalog, tmAnalogFast, tmLogic, tmLogicFast
bmChop	1	12k	Semi	6k+6k	2	tmAnalogChop, tmAnalogFastChop,
bmDual	2	6k	Full	6k+6K	2	tmMixed, tmMixedFast, tmMixedShot
bmChopDual	3	6k	Both	3k+3K+6k	3	tmMixedChop, tmMixedFastChop, tmMixedShopChop
bmMacro	4	6k	Full	6k	1	tmMacro
bmMacroChop	5	6k	Semi	3k+3k	2	tmMacroChop

Mode	M	Low	High	High (MHz)	Low (Hz)	PreScale	Trace Modes
ckMixed	0	15	40	2.67	15	65536	tmAnalog, tmMixed
ckMixedFast	1	8	14	5.00	2857143	1	tmAnalogFast, tmMixedFast
ckMixedShot	2	2	5	20.00	8000000	1	tmMixedShot, tmAnalogShot
ckLogic	3	5	16384	8.00	2441	1	tmLogic
ckLogicFast	4	4	4	10.00	10000000	1	tmLogicFast
ckLogicShot	5	1	3	40.00	13333333	1	tmLogicShot
ckChop	6	15	40	2.67	15	65536	tmAnalogChop, tmMixedChop
ckChopFast	7	8	40	5.00	1000000	1	tmAnalogFastChop, tmMixedFastChop
ckChopShot	8	4	5	10.00	8000000	1	tmAnalogShotChop, tmMixedShotChop
ckMacro	9	10	16384	4.00	2441	1	tmMacro, tmMacroChop