ConvertBot: Current IOC code algorithms

2020-04-27T18:33:01Z

Current IOC code algorithms

New page

<div style="background-color: #eef9ff; border: 1px solid #999; padding: 10px;">[[ICE_Help|↑ ''Go to the full list of ICE Help pages'']].</div>
<onlyinclude>

'''Summary:''' Current IOC code algorithms


This file contains a brief text description of the currently available code
downloads for the Altera IOC (I/O Controller) Chip. Standard Input/Output
configurations handle packing/unpacking of 1|4|8|16 bit data words, gating,
triggering, embedded timecode, and module programming.

The mux clock options are controlled by the MUXCLK=s flag. [[ICE_Help_FLAGS#MUXCLK|See Help on MUXCLK flag]].

=== II - Mod1=StdInput Mod2=StdInput ===

Standard input on modules 1 and 2 with standard input clocks.

=== IIX - Mod1=StdInput Mod2=StdInput with mux clock ===

Standard input on modules 1 and 2 with a common muxed input clock.

=== IIR - Mod1=StdInput Mod2=StdInput with internally generated ramp ===

Internally generated test ramps on input on modules 1 and 2 with a
common muxed input clock.

=== IIS - Mod1=SDDSInput Mod2=SDDSInput with packet handlers ===

The UDP module presents the ICE 8-byte sync.addr.port Header, SDDS Packet Header, and
SDDS Data, to the IOC running IIS or IOS to strip off the header, interpret timecode,
and unpack the data words for the proper tuner or module input.

If the UOPT flag is included, the ICE and SDDS headers are not stripped off of the
module data acquired by the host. They are always stripped off of the tuner input.

=== IO - Mod1=StdInput Mod2=StdOutput ===

Standard input on module 1 with standard input clock.
Standard output on module 2 with muxed output clock.

=== IOX - Mod1=StdInput Mod2=StdOutput with mux clock ===

Standard input on module 1 with muxed input clock.
Standard output on module 2 with muxed output clock.

=== OO - Mod1=StdOutput Mod2=StdOutput ===

Standard output on modules 1 and 2 with muxed output clock.

=== OOY - Mod1=StdOutput Mod2=StdOutput with independent clocks ===

=== OOW - Mod1&2 internally generated white noise with timecode ===

Standard output on modules 1 and 2 with muxed output clock.
The download internally generates identical white noise in both
channels with timecode on bit 0. Module-1 outputs standard SDN
format timecode and Module-2 has double-clutch SDN timecode.

=== T1 - Test internal loopback module 2 out to module 1 in ===

=== T2 - Test internal loopback module 1 out to module 2 in ===

=== E321 - Dual E3 to 16xE1 Demux w/ optional sync ===

In E321/E1MUX mode, the IOC expects an E3 input stream. The stream is
processed for E3 sync. If found, four E2 streams are extracted. These
in turn are processed for sync and four E1s extracted from each E2. The 16
E1s are processed for sync and output on frame boundaries. E1 data is copied
to the host buffer in 32 bit packed words, each with a channel designator.
The host then demultiplexes the 32 bit data words to the appropriate output.

=== 8E1 - Dual asynchronous 8 clock/data pairs ===

In 8E1/E1MUX mode, the IOC expects 8 E1 clock and data lines. The 8 serial
streams are optionally processed for sync and output on frame boundaries.
Data is copied to the host buffer in pairs of 32 bit packed words, oriented
as 32b channel number followed by 32b data word. The host then demultiplexes
the 32 bit data words to multiple continuous output streams.

To run 8E1 the IOC must be loaded with:
pic reset <card alias> "8e1" from Midas
pic_loadfile (p, "*_8e1", FLG_IOC); from C

The IOPORT call must include the flag FLG_DUAL.

The connector from LSB to MSB in 8E1 mode is defined as:
dat0,clk0,dat1,clk1, ... dat7,clk7 with BIT=0 flag (default)
clk0,dat0,clk1,dat1, ... clk7,dat7 with BIT=1 flag

The KEY_IOCALG byte registers are as follows:
KEY_IOCALG+0 datinv[7..0] inverts the input data if channel bit is set
KEY_IOCALG+1 clkinv[7..0] inverts the input clock if channel bit is set
KEY_IOCALG+2 usesync[7..0] only output on frame boundaries where E1 sync found
KEY_IOCALG+3 disable[7..0] disables input if channel bit is set

Use
pic_setkey(p,dmac,KEY_IOCALG+0,datinv,1);
pic_setkey(p,dmac,KEY_IOCALG+1,clkinv,1);
pic_setkey(p,dmac,KEY_IOCALG+2,usesync,1);
pic_setkey(p,dmac,KEY_IOCALG+3,disable,1);

or if these four bytes are packed into 1 int_4 register,
pic_setkey(p,dmac,KEY_IOCALG,&register,4);
or
pic_setkeyl(p,dmac,KEY_IOCALG,register);

=== GSM - Dual E1 channelizer/unpacker ===

In GSM mode, the IOC expects an E1 input stream. The stream is synchronized,
and processed for E1 sync. If found, blocks of 2k bits, or 8 E1 frames, are
restructured and packed as if 8bit, 4bit, 2bit, and 1bit data. These four
blocks are copied to the host, where multiple channels with arbitrary width
and offset can be extracted with little CPU load.

=== FMDE - Handles framing of FMDE signals ===

Each sample of data and time code is packed and presented as 8 bytes.
Therefore, all data whether it be true data or time code is on an 8 byte
boundary when acquired.
A sample is determined to be valid if byte 4 (the 5th byte) is a non-zero value.
This non-zero value is the composite sync packed into 8 bits. Bytes 0 through
4, in order, are NDU, DU, NSPU, SPU.

If byte 4 is a zero, then the sample is time code. The first 4 bytes
represent the time code in LSB to MSB order. This is different from an earlier
version that represented time code in MSB to LSB order within the 8 byte
time code long word. (long word = 8 bytes)

For FMDE data (not Time Code), the Most Significant 3 Bytes contain a 24 bit
count-with the MSByte occurring in the MSByte of the 8 byte data long word.
This count represents the number of clocks from the detection of the latest
time code barker code. In other words, this is the clock count from the
prior arriving time code.

For FMDE time code, the Most Significant 3 Bytes contain a 24 bit count-with
the MSByte occurring in the MSByte of the 8 byte time code long word. This
represents the number of clocks from the detection of the PRECEDING time
code barker code. In other words, this is the clock count from the prior
arriving time code.

In summary,
Byte order for 8 bytes of data,
1st BYTE 8th Byte
NDU, DU,NSPU,SPU,CSYNC,LSB Count,MIDDLE Count,MSB Count -- DATA
TC LSB BYTE,TC,TC,TC MSB BYTE,ZERO,LSB Count,MIDDLE Count,MSB Count -- Time Code

Because the ICE card interface is 16 bits the following bits are
assumed to contain FMDE data.

Bit 4 Time Code
Bit 6 NDU Stream
Bit 7 DU Stream
Bit 8 NSPU Stream
Bit 9 SPU Stream
Bit 10 CSYNC Stream

Note-Bit 4 is the 5th bit. (Bit numbering-0,1,2,3,4,5,...,15)
Connecting the 10 bit FMDE cable to the 16 bit ICE transition
panel will yield correct bit connections.

=== BP - Handles bit packing of 1,2,3,4,5,6,7 or 8 bit data ===

In BitPack mode, the IOC expects 1 clock and 1-8 data lines.
Data is packed little endian into consecutive bytes.

To run BP the IOC must be loaded with:
pic reset <card alias> "bp" from Midas
pic_loadfile (p, "*_bp", FLG_IOC); from C

The connector from LSB to MSB in BP mode is:
dat0, dat1 ... dat15 with BIT=0 flag (default)
dat15, dat14 ... dat0 with BIT=1 flag

Valid data bits are 0 to N-1 for N bit data.

The KEY_IOCALG byte register is used as follows:
reg.bits[2..0] number of valid bits (1-8) minus 1

Use pic_setkey(p,dmac,KEY_IOCALG,register,1); to set the word width.

Setting the BIGE flag reverses the bit order of the output byte.

The Standard Input/Output configurations are loaded automatically during a
pic_reset according to the specified module configuration. The non-standard
IOC downloads can be performed during a reset using the IOC=xxxx flag, or
after a reset by calling pic_loadfile. From Midas, this is an optional
parameter on PICDRIVER, ie: PICD RESET PIC1 8E1

For PIC5 and later cards, the IOC= setting is not actually a FPGA download file,
but a register setting in the SoC download to implement that function.
The specific algorithms E321 ... BP would be handled in FPGA cores loaded onto
processor modules or the main board in some cases.

</onlyinclude>
[[Category:ICE_Help]]

ICE Help IOC - Revision history

ConvertBot: Current IOC code algorithms