C2.1. Introduction

The DEB board originated in the early days of CFT's Verilog verification. A test framework would run the Verilog simulator with various test programs, which needed to be able to print output and make test assertions which would halt the computer when failed.

A number of ‘magic’ instructions were added, including SUCCESS (to log a test success), FAIL (to log a test failure), as well as various PRINTx instructions to log the value of the Accumulator (AC) in binary, decimal, hexadecimal, or a UTF-8 character. These behaved like a standard CPU extension board. The instructions would log appropriate messages to the testbed output file, and the simulator's output could be compared against the expected output to detect problems.

This design stuck, and grew to become a virtual device in the CFT Emulator, which allowed the emulator to be tested on the same framework — better yet, peripherals could also be tested, and tested much faster than in Verilog. As a side effect, it also allowed testing of various algorithms used in the ROM, including integer division, which also tests the processor’s overall behaviour quite well. The success of this technique has (unsurprisingly) been great: several serious issues with the processor and its microcode were found.

It only made sense that there should be a hardware implementation, to bring the unit tests to the constructed CFT. As the test suite grows, it will help verify that individual features of the processor and computer at large work as expected.

C2.2. Design

There are a number of very useful features provided by the DEB board:

• It can be directed by CFT instructions to output data to the controlling computer.

• It can provide information on test progress to the controlling computer.

• It can mark failed tests to the controlling computer, and optionally halt so that the CFT’s state can be inspected.

• It can upload memory images to the computer.

• It can examine memory locations.

• It performs operations in I/O space, to initialise and test peripherals.

• It can be used to reprogram the CFT’s Flash ROM in-circuit.

• It controls the run state of the machine, making it double as a simple virtual front panel.

• It can be used by both humans and automated tools.

• It provides four diagnostic LEDs (entirely user-controlled) to show the state of testing.

This feature set also provides a number of unforeseen benefits:

Construction freedom.

Cards can now be constructed in any order whatsoever. The memory and IDE cards can be constructed first and tested to ensure they work before the processor is even attempted. This removes degrees of freedom and uncertainty should a bug be found later on. It is preferable to know that simpler devices (like the memory board) are working well, so issues can be tracked to more complex devices instead.

Build safety.

All the cards can be pulled out of the card cage, leaving the DEB board and a newly constructed peripheral board. The peripheral board can be tested on its own, again removing degrees of freedom and uncertainty. If something goes really wrong, the worst case scenario is that some chips on the debugging board need to be replaced, and the misbehaving new peripheral needs to be rewired slightly. This is naturally better than having to diagnose a fault when the set of potential failures contains over 250 ICs.

Manual operation.

With the current firmware, it is be easy to operate the DEB card manually using a serial terminal, and get something resembling a basic programmer’s front panel.

Flash Programming for free.

Since the DEB board can write to memory and I/O devices, it can also flash the machine's non-volatile memory. The Microcode store and ALU tables will have to be pulled to be reprogrammed, but those are not devices that will need to be reprogrammed often.

C2.3. Theory of Operation

The DEB board has two main parts:

The CFT Bus Interface

attaches the DEB board to the CFT, and allows it to be addressed and used by the CFT.

The Controller Interface

interfaces the DEB board to an external controlling device using a TTL serial-to-USB bridge, and allows devices on the CFT bus (including the processor) to be remote-controlled, debugged and tested.

At the heart of the DEB board is an Atmega 168 Microcontroller Unit (MCU), which handles the serial debugging interface. The Atmega's microprocessor nature makes it too slow and too unpredictable to act as the CFT Bus interface, so this part is ‘autonomic’. When the board is addressed, it immediately triggers a Wait State which persists until the microcontroller has read the bus and is ready to go on. Here is how this was designed:

The address decoder decodes fully the I/O address range 03F0-03FF and generates a standard active-low pulse when one of these addresses is written to.

he active low pulse asynchronously clears a D flip-flop, so its Q output goes high. This is inverted using an open-drain inverter and used to assert the WS signal. The flip-flop is reset by the bus RESET signal, and also by the microcontroller under control of its firmware.

This implements the following behaviour: on reset, WS is guaranteed to be de-asserted, which is the desired behaviour. When the CFT processor performs an OUT R &3Fx instruction, a a wait state is asserted, freezing the computer and its buses mid-write.

Simultaneously, the strobe interrupts the MCU, which wakes from sleep, samples the address and data buses, acts according to the operation selected by the I/O address, and strobes DEBCONT, which de-asserts WS, and the computer resumes operation.

Please note that this wait state can be very long, perhaps in the order or milliseconds. This is done because the MCU and CFT processor are mutually asynchronous, and the MCU uses a number of slow, serially-controlled GPIO chips to sample the CFT's buses. Not to mention having to send out data via a serial port. A fast serial port, but nowhere near as fast as the CFT bus. The long wait state is pretty much obligatory for this to work.

C2.4. Controller Interface

the controller interface is simple but very powerful. It has three hardware parts:

The MCU.

This is responsible for the operation of the board. It is an Atmel^®> AVR^® Atmega 168 unit with flash memory and an on-board SPI header for in-circuit programming. The MCU controls 48 GPIO pins via an I²C two-wire bus, as well as the MEM, IO, R and W control signals on the CFT bus. In addition, it can stop and single-step the processor by driving the FPCLKEN and FPUSTEP lines usually controlled by the front panel. Finally, it controls a bank of four LEDs which can be illuminated to show progress, status and diagnostics.

Three 16-port GPIO devices.

Two of these are attached to the address and data buses. To simplify wiring (and routing), one is attached to the eight most significant lines of each bus, while the other to the eight least significant ones. The third is for future expansion. A 16-pin header on the board allows e.g. bus pins to be connected to it via jumper cables for sampling or control. GPIO pins may be configured as inputs or outputs, reducing the chip count significantly. The devices are Microchip^® MCP23016 units, controlled by the MCU via its I²C bus, running at a pretty pathetic 100 kHz. The three GPIOs are referred to by their I²C addresses or their function:

The serial-to-USB bridge

is implemented using an FTDI TTL serial-to-USB cable. It connects the MCU to a testing controller via USB. This allows high communication speeds — by default, the DEB card communicates at 921,600 bps, while ensuring near-universal compatibility with computing devices.

The MCU firmware controls these hardware assets programmatically, so behaviours can be changed, and features may be upgraded as required.

C2.5. The GPIOs and I²C bus

The three GPIO chips are configured and attached to the bus as follows:

Please note that there is nothing at I²C address 22.

C2.6. Serial Communication

Serial communication is at 921,600 bps, 8 bits per byte, and no parity. There are no hardware or software handshakes. The protocol is text-based and friendly to both humans and machines. The MCU's serial out port is used and serial levels are TTL, not RS-232. An FTDI TTL serial-to-USB adapter cable converts TTL serial data to USB for connection to a modern computer.

C2.7. Operation

When powered on or reset, the board goes through a brief self-diagnostic phase, ensuring that the GPIO chips are in good working order. The LED testing lights should illuminate on power on, then turn off in sequence, until none remain lit. This process should last no longer than around three seconds.

If the board stops before completing initialisation, the LEDs will be left in one of the following diagnostic patterns: meaning of the diagnostic LEDs:

If all devices pass power-on tests, all the LEDs should initially be off.

If a GPIO is reported failed, the fault may be transient. Inexplicably, the MCP23016 GPIO has no reset signal, and its error recovery is less than perfect — if an I²C or protocol error is encountered, it can hang. Resetting the DEB board is not enough to clear the error condition. Power cycling is required instead. This flaw alone was nearly reason enough to make me mark the device obsolete in favour of some better way of talking to the CFT's buses.

Diagnostics are also indicated via the serial connection. Upon power-up or reset, the following should appear:

CFT DEB Board Booting.
GPIO diag: 20 21 23 Ready.
201 Version: 0.5
201 BufSize: 104
202 (c) 2012 Alexios Chouchoulas <[email protected]>
202 Licensed under the GNU Public License v.2.
202 http://www.bedroomlan.org/cft
[running]>

C2.8. Interactive Operation — The Virtual Front Panel

Interactive operation is via a TTL-level serial line running at 921,600 bps, with no parity and 8 bits per byte. The TTL serial line connector is wired to accept an FTDI TTY-to-USB converter ‘cable’ (a microcontroller in the plug manages the conversion), which allows the DEB board to be connected to a computer via a more modern and much more common USB interface.

The firmware presents an interactive user interface intended for both humans and machines, in the style of the SMTP, FTP and HTTP protocols. The user enters short commands, optionally followed by one or more arguments, and the board responds with a three digit response code and a human-readable message. A human ignores the response code; a machine ignores the text message.

A rudimentary line editor is provided for command lines:

• Backspace or DEL keys delete the last character in the current command.

• Ctrl-C or Ctrl-X keys abort the current command, and may also be used to abort a long-running process.

• Enter or Return keys submit the current command for processing.

Help may be obtained by using the ? or help commands, which print out something like this:

201 Available commands:
201  ? -- Show help.
201  help -- Show help.
201  ver? -- Show version.
201  buf? -- Show size of command buffer.
201  c? -- Show current word count.
201  ob -- Set binary for dump.
201  ot -- Set text for dump.
201  leds NIBBLE -- Set diagnostic LEDs (0-F).
201  halt -- Halt the CFT & become bus master.
201  run -- Resume the CFT.
201  rst! -- Reset the CFT.
201  e0 -- Local echo off.
201  e1 -- Local echo on.
201  hof0 -- Halt on FAIL.
201  hof1 -- Continue on FAIL.
201  a WORD -- Set address.
201  c WORD -- Set count.
201  r -- Read word from memory.
201  w WORD ... -- Write words to memory, step address.
201  in WORD -- Read from I/O address WORD.
201  out ADDR WORD -- Write WORD to I/O ADDR.
201  d -- Dump count words starting at addr, step addr.
201  clr! -- Reset the DEB board.
201 Consult documentation for details.
[running]>

The DEB board has two modes of operation:

Run mode.

In this mode, the CFT is executing its program as per normal. It is not possible to modify the computer's state in this mode, except to stop it or reset it. The run command (described below) activates this mode.

Stop mode.

In this mode, the DEB board has master access to the computer's buses and can inspect and modify memory and I/O locations. The halt command (described below) activates this mode and unlocks the full DEB command set.

The following is a brief description of available DEB commands.

C2.8.1. Querying the DEB Board

ver? prints out the current firmware version. The presence of +t in the version signifies that text dumping is available, which is always the case on the Atmega 168-based board. Text dumping is for dumping ROMs in a human-readable hex dump: the firmware for the DEB board originated on my based FlashProg project. FlashProg originally ran on an Atmega-8, and the text dumping feature would not fit in the MCU's 8 KByte Flash.

[running]> ver?
201 Version: 0.5+t

Querying the Buffer Size: buf?

buf? displays the size of the input line buffer in hexadecimal. This affects the maximum number of values that can be written to memory on one line.

[running]> buf?
201 BufSize: 200

c? displays the current word count in hexadecimal. This is the size of the block displayed by the d (dump) command. The default count is 80, i.e. 128 words.

[running]> c?
201 Count: 0080

C2.8.2. Memory Dump Mode: ob and ot

Th d command can dump data in a user-friendly textual way, or in binary when the DEB board is driven by an automated system.

ob (output-binary) Makes the d (dump) command dump in binary. The default is text dumping.

[running]> ob
206 Output: bin

ot (output-text) Makes the d (dump) command dump in text, which is also the default.

[running]> ot
205 Output: text

C2.8.3. Controlling the Diagnostic LEDs: leds

leds NYBBLE sets the bit pattern of the diagnostic LEDs. NYBBLE is a hexadecimal value in the range 0-F (four bits). Bits 0–3 represent LEDs A–D in order. LED D is the most significant bit and controls the red LED. A bit value of 1 turns on a LED; a value of 0 turns it off. To turn on all LEDs but LED A (1110 = E):

[running]> leds e
209 LEDs: e

C2.8.4. Controlling the Computer's State

halt stops the computer and unlocks the full DEB command set. The mode changes to halted, and the prompt changes to show the current address:

[running]> halt
306 Host halted
[halted] 0000> halt
505 Already halted.
[halted] 0000>

run locks the DEB command set and starts the computer. The mode changes to running, and the prompt changes to reflect this:

[halted] 0000> run
305 Host running
[running]> run
506 Already running.
[running]>

rst! resets the CFT processor and all peripherals. The DEB board itself is not affected by this. No confirmation questions are asked.

[halted] 0000> rst!
307 Host reset

C2.8.5. Local Echo

Humans using a terminal generally need typed characters to echo back to the terminal for display. Computers are more confident in their typing skills and often get confused by this echoing.

e0 disables local echo. This is useful for certain remote terminals that have custom line editors and/or their own echo, which make typed characters appear twice. The default is to perform local echo (e1).

[halted] 0000> e0
208 Echo: off

e1 enables local echo. Use this command if typed characters are invisible. This is the default behaviour.

[halted] 0000> e1
207 Echo: on

C2.8.6. Setting Halt-on-Fail

When the computer executes the FAIL instruction, the DEB can halt it for immediate state inspection.

hof0 disables halt-on-FAIL mode. When the CFT issues the FAIL extended instruction, the computer will be allowed to keep running. This is the default behaviour, and useful for automated testing where we need to collect all the failures, even if they're cascading off a single bug.

[halted] 0000> hof0
211 Halt on FAIL: off

hof1 enables halt-on-FAIL mode. When the CFT issues the FAIL extended instruction, the computer will be halted (and the full DEB command set unlocked) to allow state inspection. The default behaviour is hof0.

[halted] 0000> hof1
210 Halt on FAIL: on

C2.8.7. Inspecting and Modifying Memory and I/O Space

The DEB can read and write to both Memory and I/O space. It presents a user interface similar to that of a computer monitor (in the software sense, not the device that displays output).

a ADDRESS sets the current address to ADDRESS, which is a 16-bit value expressed in hexadecimal. The current address affects memory reads (using the d command) and memory writes (using the w command). If the DEB board is in the halted mode, the prompt also indicates the current address:

[halted] 0000> a 1234
203 Address: 1234
[halted] 1234>

c COUNT sets the current count to COUNT, which is a 16-bit value expressed in hexadecimal. Please note that this makes it impossible to, for instance, dump 65,536 words (the full CFT logical address space) because the largest acceptable count is FFFF or 65,535.

[halted] 0000> c 8000
204 Count: 8000

r reads one word from memory space at the current address. The read word is reported in hexadecimal. The current address is incremented by one. This command only works with the DEB board in halted mode.

[running]> a 1234
203 Address: 1234
[running]> r
503 Halt host first.
[running]> halt
306 Host halted
[halted] 1234> r
304 Value: DEAD
[halted] 1235> r
304 Value: BEEF
[halted] 1236> r
304 Value: 63FF
[halted] 1237>

w WORD ... writes one or more words to memory space starting with the current address. Words are 16-bit values expressed in hexadecimal. The current address is incremented after each write. This command only works with the DEB board in halted mode. A simple checksum (a 32-bit sum of all input values expressed in hexadecimal and padded to 8 digits) is reported at the end of the command's execution.

[running]> a 1234
203 Address: 1234
[running]> w dead beef 63ff
503 Halt host first.
[running]> halt
306 Host halted
[halted] 1234> w dead beef 63ff
301 Done
303 Checksum: 0002019b
[halted] 1237>

in ADDR reads one 16-bit value from the I/O space address provided (in hexadecimal), padded to 4 digits. This command only works with the DEB board in halted mode. The current address is not used in this command.

[running]> in 23
503 Halt host first.
[running]> halt
306 Host halted
[halted] 0000> in 23
304 Value: 00FF
[halted] 0000>

out ADDR WORD writes the 16-bit WORD to I/O space address ADDR. This command only works with the DEB board in halted mode. The current address is not modified (as it addresses memory space).

[running]> out 16f 1234
503 Halt host first.
[running]> halt
306 Host halted
[halted] 0000> out 16f 1234
301 done
[halted] 0000>

d Dumps a block of COUNT (see c and c? commands above) words starting at the current address, as set by the a command. The current address will be incremented by COUNT. This command only works with the DEB board in halted mode. In text mode (see ot), the command works like this:

[running]> c 20
204 Count: 0020
[running]> d
203 Address: 0000
204 Count: 0020
300 Dumping
503 Halt host first.
[running]> halt
306 Host halted
[halted] 0000> d
203 Address: 0000
204 Count: 0020
300 Dumping
0000 | 1234 1234 1234 1234 1234 1234 1234 1234 | 44444444 | 000091a0
0008 | 1234 1234 1234 1234 1234 1234 1234 1234 | 44444444 | 00012340
0010 | 1234 1234 1234 1234 1234 1234 1234 1234 | 44444444 | 0001b4e0
0018 | 1234 1234 1234 1234 1234 1234 1234 1234 | 44444444 | 00024680
301 Done
303 Checksum: 00024680
[halted] 0020>

The dump is in four columns. The leftmost column is the current address. The second column lists eight 16-bit hexadecimal word values (padded to four digits), starting at the current address. The third column shows ASCII characters by examining the least significant seven bits of the value (34, ASCII 52 or ‘4’ in the example above). Unprintable characters are shown as full stops (.). The rightmost column shows a running checksum of the values listed so far, including previous lines. The checksum starts at 0 for every execution of the d command.

At the end of the dump, the final checksum is reported.

In binary mode, the newline at the end of the ‘300 Dumping’ message signals the start of the dump. 2×COUNT 8-bit bytes are transmitted. Each pair of bytes is one value from memory. The most significant byte is transmitted first. The receiver should read exactly 2×COUNT bytes and attempt to parse the ‘301 Done’ result to ensure success. As with the text dump, the block checksum is reported afterwards. This may be parsed and checked.

[halted] 0000> c 20
204 Count: 0020
[halted] 0000> d
203 Address: 0000
204 Count: 0020
300 Dumping
(64 bytes of binary data follow)
301 Done
303 Checksum: 00024680
[halted] 0020>

C2.8.8. Resetting the DEB board: clr!

Sometimes the DEB board may need to be reset. The clr! command performs a warm reset of the board, reverting all settings to their defaults. This does not affect operation of the CFT computer itself, nor does it change the current mode run/stop mode. Thus, a halted computer will remain halted after the warm reset.

[halted] 6120> clr!
GPIO diag: 20 21 23 Ready.
201 Version: 0.5+t
201 BufSize: 200
202 (c) 2012 Alexios Chouchoulas <[email protected]>
202 Licensed under the GNU Public License v.2.
202 http://www.bedroomlan.org/cft
[halted] 0000>

Sadly, it also doesn't reset the GPIO chips. This is a limitation of the GPIO chips themselves. To reset hung GPIO chips (yes, this happens a lot) cycling power is necessary.

C2.9. Result Codes

The DEB firmware reports three-digit result codes in decimal followed by human-readable messages. These are broken down into four categories:

C2.9.1. Information Messages (200–299)

Informational messages and acknowledgments. These do not affect the operation of the computer.

201

Supplemental information, boot-up banners.

202

Copyright and licensing notices.

203 Address:

The current address is the last field or last four characters of the line.

204 Count:

The word count the last field or last four characters of the line.

205 Output: text

Dump output mode has been switched to text.

206 Output: bin

Dump output mode has been switched to binary.

207 Echo: on

Local echo activated.

208 Echo: off

Local echo deactivated.

209 LEDS:

LED output pattern set. The pattern is the last space-delimited field (one hexadecimal digit) on the line.

210 Halt on FAIL: on

Halt-on-FAIL enabled.

211 Halt on FAIL: off

Halt-on-FAIL disabled.

C2.9.2. Accessing or Modifying Computer State (300–399)

Messages pertaining to processes that access or modify computer state.

300 Dumping

A memory dump follows.

301 Done

Process is finished.

302 Aborted

A process was aborted by the user.

303 Checksum:

The last space-delimited field on the line (eight characters) is a 32-bit hexadecimal representation of the checksum of the last block of data sent or received.

304 Value:

The last space-delimited field on the line (four characters) is a 16-bit hexadecimal representation of the value read from memory, as requested.

305 Host running

The CFT computer was started or restarted. DEB commands that use the computer buses are now locked out.

306 Host halted

The CFT computer was halted. The full DEB command command set is now unlocked.

307 Host reset

The CFT computer was reset.

C2.9.3. Warnings (400–499)

There is currently only a single warning.

401 Warning: write will wrap around

If COUNT words are written at the current address, the address will wrap around to 0000 during the block write.

C2.9.4. Errors (500–599)

Errors.

500 Unknown command

The last command was not recognised.

501 Bad value

An argument was not a valid hexadecimal number.

502 Count must be multiple of 8

For proper behaviour of dumping, the word count should have its least significant three bits clear, i.e. be a multiple of eight.

503 Halt host first

A locked-out command was issued. The computer must be halted for these commands to become available.

504 Bus chatter

For safety, CFT buses are sampled before driving them. If changing values are seen, this message appears and the command is aborted to avoid bus contention. This is an indication of something wrong with the bus connections.

505 Already halted

The computer is already halted. The halt command had no effect.

506 Already running

The computer is already running. The run command had no effect.

C2.10. Automated Operation — The DEB Tool

The DEB board may be used remotely by a controlling computer, to automate unit testing of the CFT. The tool allows memory images to be downloaded to the DEB card and written to CFT memory, then executed, and their output captured for analysis by the controlling computer.

C2.11. Programmatic Operation from the CFT

The DEB board may be used directly from the CFT, and therein lies its power: the computer can perform tests and send out output to the DEB board which is then collected and used for automated testing.

C2.11.1. Detection

The DEB board is output-only: it is impossibly for the processor to detect its presence, and using the extended instructions without a DEB board present will have no effect.

C2.11.2. Operation

The mapping of the DEB board to the I/O space provides sixteen extended CFT instructions with unusually long names due to their unique history. The following is a list of these I/O addresses:

C2.11.2.1. Printing the Accumulator

There are no fewer than ten extended instructions that log the value of the AC in different formats. Here they are:

PRINTA:

The current value of AC is output from the DEB board to the controlling computer in the format XXXX (label+N), where XXXX is the hexadecimal value of the AC padded to four digits, label is the most recently passed Assembly source label, and n is the offset (in words, in decimal) from that label. If a label is not available, ‘XXXX (?)’ is output instead. Labels and offsets are only available on the (C, not Verilog) emulator with a map file loaded. They're there only for human convenience. The test benches include the parenthesised part and only parse and check the hexadecimal number.

PRINTC:

The least-significant byte of the current value of the AC is output to the controlling computer as an 8-bit character.

PRINTD:

The current value of the AC is output to the controlling computer as a decimal, signed, Two's Complement integer in the range -32,768–32,767. There is no zero-padding.

PRINTU:

The current value of the AC is output to the controlling computer as a decimal, unsigned integer in the range 0–65,535. There is no zero-padding.

PRINTH:

The current value of the AC is output to the controlling computer as a hexadecimal unsigned integer in the range 0000–FFFF. The number is zero-padded to four digits. The case of the alphabetic digits is purposefully unspecified. Parsers should handle both upper and lower case.

PRINTB:

The current value of the AC is output to the controlling computer in its raw binary representation, in the range 0000000000000000–1111111111111111. The number is zero-padded to sixteen bits.

PRINTSP:

A single space (ASCII codepoint 32) is output to the controlling computer. This simplifies debugging and testing, since none of the other instructions space-pad their output. The value of the AC is ignored.

PRINTNL:

A single Unix new line character (ASCII codepoint 10) is output to the controlling computer. This simplifies debugging and testing, since none of the other instructions use white space. The value of the AC is ignored.

PRINTHI:

Stores the current value of the AC in a temporary register on board the DEB board. Meant to precede the PRINTLO instruction to print out 32-bit hexadecimal values.

PRINTLO:

Prints out the 32-bit integer made by combining the last value stored by PRINTHI, shifted 16 bits to the left, and the current value of the AC. The number reported is in the range 00000000-FFFFFFFF and is zero padded to eight digits. The case of the alphabetic digits is purposefully unspecified. Parsers should understand both lower and upper case.

C2.11.2.2. Tracing and Debugging Facilities

These instructions are only available on the C-based emulator. On every other platform, they're effectively NOP instructions.

DEBUGON:

The C-based emulator will start printing a symbolic listing of every instruction executed. If a map file is loaded, the instructions will come straight out of the source listing (with macros expanded) to aid debugging. If a map file isn't specified, the emulator will disassemble the instructions. This obviously slows down emulation.

DEBUGOFF:

Executed instructions will not be output. This is the default state.

DUMP:

Dumps the current state of the computer in an implementation-specific way intended for post-mortem debugging. This will include the values of all registers, plus the internal state of the processor as defined in the emulator.

C2.11.2.3. Testbench Facilities

There are two instructions available to enhance testing. These allow the processor to inspect its own state and pronounce test successes/failures on its own.

SUCCESS:

Registers a successful test checkpoint with the test framework. These may be used to provide progress reporting as well as to ensure an exact, certain number of checkpoints are reached by the code. To mark the checkpoint, the sequence ‘[ok]’ is transmitted to the controlling computer.

FAIL:

Registers a failed test assertion with the test harness. This is used to provide information to the controlling computer. The failure is denoted by sending the sequence ‘[fail]’ to the controlling computer. On the DEB board hardware implementation, executing FAIL also illuminates the red LED (LED D). If Halt-on-FAIL mode is enabled, the processor is also halted. On the Verilog simulator and C-based Emulator, FAIL always terminates the Verilog or emulator session, and usually dumps the full state of the CFT and its peripherals for post-mortem analysis (identical to the side-effects of the DUMP instruction.

C2.12. Schematics

This is the full schematic drawing of the DEB board on a single, tightly packed sheet that doesn't quite follow the style of other CFT schematics.

C2.13. Board

The board was never fabricated, but a design exists. It's an early, through-hole design with early design rules belying the fact that the board was never even sent to a fab facility. Here it is anyway, for sheer historical value.

Note the two 8-bit pods (JP1 and JP2, center left) that were meant to be connected to the pin headers on the right of the board via jumpers.

The routing of this board is atrocious. It's ugly, it makes for bad signal integrity, and chances are it'd never pass constraints checking. The board was never fabricated, though, so it's okay.