Changes

== Interface ==

= Interface =

:''See also: [[Ethernet packets]]''

:''See also: [[Ethernet packets]]''

'''A discussion of the Multiplexed Intel bus format should be placed here.'''  Until this section is complete, refer to the CP2200/1 data sheet for information.

'''A discussion of the Multiplexed Intel bus format should be placed here.'''  Until this section is complete, refer to the CP2200/1 data sheet for information.

== The eight states ==

= The eight states =

There are eight major states to the module.

There are eight major states to the module.

=== State list ===

== State list ==

; (000) Reset Cycle

; (000) Reset Cycle

: This state packages and transmits a "D" packet over the Ethernet to report back the DAC voltages in response to a "P" packet.

: This state packages and transmits a "D" packet over the Ethernet to report back the DAC voltages in response to a "P" packet.

=== State interconnect ===

== State interconnect ==

These states will form the outline of the functional block diagram.  Within each state will be a smaller process or set of processes, possibly broken into substates.  This implementation calls for a central ''state'' register.  Each block reads the state value in the register and enables itself upon seeing its own value.  After completion of its function, a block will write a new value to the state register to enable the next block. With several modules writing to the register, usual precautions must be taken to avoid more than one drivers forcing a line simultaneously. All modules must be designed to go to high impedance on their output lines when they are not active.

These states will form the outline of the functional block diagram.  Within each state will be a smaller process or set of processes, possibly broken into substates.  This implementation calls for a central ''state'' register.  Each block reads the state value in the register and enables itself upon seeing its own value.  After completion of its function, a block will write a new value to the state register to enable the next block. With several modules writing to the register, usual precautions must be taken to avoid more than one drivers forcing a line simultaneously. All modules must be designed to go to high impedance on their output lines when they are not active.

=== State variable ===

== State variable ==

Based on the assignments of state values to the various states, certain interpretations of the state's bits arise.  They may or may not prove useful in coding the system.  They are given here in the case that they do become useful.

Based on the assignments of state values to the various states, certain interpretations of the state's bits arise.  They may or may not prove useful in coding the system.  They are given here in the case that they do become useful.

** S₀ = 1: "Transfer state" to communicate with the external PC.

** S₀ = 1: "Transfer state" to communicate with the external PC.

== Emulator ==

= Emulator =

== Controller ==

= Controller =

=== Foreword on Timing ===

== Foreword on Timing ==

With a controller this complex, the timing of signals must be inspected even more scrupulously than usual. In particular, simultaneous transitions of data and "Done" lines must be avoided.  When possible, a one-cycle-delayed "Done" signal is used to ensure that the data lines have been stabilized. (All delays are implemented via the <tt>c_delay</tt> module which postpones the signal by one cycle via two sequential flip-flops, each shifting by half-cycle).  When this is inconvenient (e.g. when writing to registers) the target component must not be enabled on rising edges on "Go" or the clock.  The registers, for instance, have been designed to read values on the ''falling edge'' of the clock - middle of the "Go" pulse, safely after the data line transitions.

With a controller this complex, the timing of signals must be inspected even more scrupulously than usual. In particular, simultaneous transitions of data and "Done" lines must be avoided.  When possible, a one-cycle-delayed "Done" signal is used to ensure that the data lines have been stabilized. (All delays are implemented via the <tt>c_delay</tt> module which postpones the signal by one cycle via two sequential flip-flops, each shifting by half-cycle).  When this is inconvenient (e.g. when writing to registers) the target component must not be enabled on rising edges on "Go" or the clock.  The registers, for instance, have been designed to read values on the ''falling edge'' of the clock - middle of the "Go" pulse, safely after the data line transitions.

=== Non-State Components ===

== Non-State Components ==

==== Transceiver ====

=== Transceiver ===

This block provides a level of abstraction between the precise CP2200/1 interface and a generalized interface seen by the internal blocks of the FPGA.  It takes information on the next transfer to carry out and returns information on the last transfer completed.  It has a pulse signal to begin a transfer and a pulse signal to notify of a completed transfer.  This eliminates a need for the internal workings of the FPGA to be aware of the timing of the interface; it simply begins a transfer and waits for notification of the transfer's completion.  The transceiver is intended to function on the Multiplexed Intel bus format to communicate with the CP2200/1.

This block provides a level of abstraction between the precise CP2200/1 interface and a generalized interface seen by the internal blocks of the FPGA.  It takes information on the next transfer to carry out and returns information on the last transfer completed.  It has a pulse signal to begin a transfer and a pulse signal to notify of a completed transfer.  This eliminates a need for the internal workings of the FPGA to be aware of the timing of the interface; it simply begins a transfer and waits for notification of the transfer's completion.  The transceiver is intended to function on the Multiplexed Intel bus format to communicate with the CP2200/1.

==== Registers ====

=== Registers ===

===== State Register =====

==== State Register ====

A three-bit register to store the current state.

A three-bit register to store the current state.

inputs

inputs

===== Temperature Register =====

==== Temperature Register ====

A 16-bit register to store the most recent temperature data.

A 16-bit register to store the most recent temperature data.

inputs

inputs

===== ADC Registers =====

==== ADC Registers ====

A set of eight 16-bit registers to store the most recent ADC data.  Also includes a demultiplexer to select which register to write to.

A set of eight 16-bit registers to store the most recent ADC data.  Also includes a demultiplexer to select which register to write to.

inputs

inputs

===== DAC Registers =====

==== DAC Registers ====

A set of 32/24/16 16-bit registers to store the most recent DAC data.  Also includes a demultiplexer to select which register to write to.

A set of 32/24/16 16-bit registers to store the most recent DAC data.  Also includes a demultiplexer to select which register to write to.

inputs

inputs

==== Reusable Components ====

=== Reusable Components ===

Several components were found useful as reusable units rather than unique modules.

Several components were found useful as reusable units rather than unique modules.

===== Byte Fetcher (<tt>getByte</tt>) =====

==== Byte Fetcher (<tt>getByte</tt>) ====

Fetches a byte of data from the Ethernet Controller control and data registers. This unit helps abstract and package the communication steps with the transceiver. The two step process of sending a request with all accompanying parameters and waiting for reply is now a matter of a single "call". Aside from packaging, the component ensures proper timing among the sent signals. The actual request is performed via the <tt>reqFromAddr</tt> unit described below.

Fetches a byte of data from the Ethernet Controller control and data registers. This unit helps abstract and package the communication steps with the transceiver. The two step process of sending a request with all accompanying parameters and waiting for reply is now a matter of a single "call". Aside from packaging, the component ensures proper timing among the sent signals. The actual request is performed via the <tt>reqFromAddr</tt> unit described below.

===== Auto-reader (<tt>AutoRd</tt>) =====

==== Auto-reader (<tt>AutoRd</tt>) ====

Performs the same function as the Byte Fetcher (described above) but is hard-wired to address the RXAUTORD (0x01). This is convenient because the Ethernet Controller's AutoRead interface will be used extensively to parse through packets. <tt>AutoRd</tt> is in fact a wrapper around <tt>GetByte</tt> passing through all signals accept the fixed address input.

Performs the same function as the Byte Fetcher (described above) but is hard-wired to address the RXAUTORD (0x01). This is convenient because the Ethernet Controller's AutoRead interface will be used extensively to parse through packets. <tt>AutoRd</tt> is in fact a wrapper around <tt>GetByte</tt> passing through all signals accept the fixed address input.

===== Read Request (<tt>reqFromAddr</tt>) =====

==== Read Request (<tt>reqFromAddr</tt>) ====

Sends request for reading (R/W pin high) to transceiver at the specified address. "Go" pulse is appropriately delayed to ensure that parameter signals sent to transceiver have gone through their transitions. This unit is not intended for direct use, but rather to be the core of the fetcher components described above.

Sends request for reading (R/W pin high) to transceiver at the specified address. "Go" pulse is appropriately delayed to ensure that parameter signals sent to transceiver have gone through their transitions. This unit is not intended for direct use, but rather to be the core of the fetcher components described above.

===== Write Request (<tt>wrToAddr</tt>) =====

==== Write Request (<tt>wrToAddr</tt>) ====

Sends a write request (R/W pin low) to transceiver at the specified address with the specified byte of data. The primary reason of this instruction "packaging" is to obscure the complexity of appropriate delays to ensure proper signal latching.

Sends a write request (R/W pin low) to transceiver at the specified address with the specified byte of data. The primary reason of this instruction "packaging" is to obscure the complexity of appropriate delays to ensure proper signal latching.

===== Miscellaneous Components =====

==== Miscellaneous Components ====

=== (000) Reset Cycle ===

== (000) Reset Cycle ==

Block 000 will have four functional blocks: one each for the DAC, ADC, and Ethernet controller, and one to coordinate their completion.  The temperature sensor lacks an external reset function; it self-initializes on startup.  The "R" packet will supply flags as to whether or not to enable the various blocks.  A power-on reset will default to resetting all components.  Using the enable flags like a mask on the done lines, the fourth functional block will update the state register.  For information on the reset procedures, see [[Reset and Initialization]].

Block 000 will have four functional blocks: one each for the DAC, ADC, and Ethernet controller, and one to coordinate their completion.  The temperature sensor lacks an external reset function; it self-initializes on startup.  The "R" packet will supply flags as to whether or not to enable the various blocks.  A power-on reset will default to resetting all components.  Using the enable flags like a mask on the done lines, the fourth functional block will update the state register.  For information on the reset procedures, see [[Reset and Initialization]].

*** ''New_St'': new state to be written to the state register; goes to 001 while ''Done'' is high

*** ''New_St'': new state to be written to the state register; goes to 001 while ''Done'' is high

=== (001) Transmit "I" ===

== (001) Transmit "I" ==

This is a simple state.  It loads to the CP2200/1 a packet containing an ASCII "I" in the first byte and padding (any value) in all remaining bytes (minimum size of data is 46 bytes, so there needs to be 45 bytes of padding).  After the transmission is complete, the block writes a 010 to the state register.

This is a simple state.  It loads to the CP2200/1 a packet containing an ASCII "I" in the first byte and padding (any value) in all remaining bytes (minimum size of data is 46 bytes, so there needs to be 45 bytes of padding).  After the transmission is complete, the block writes a 010 to the state register.

*** ''New_St'': new state to load into state register; goes to 010 when ''Done'' is high

*** ''New_St'': new state to load into state register; goes to 010 when ''Done'' is high

=== (010) Idle ===

== (010) Idle ==

Block 010 continuously polls the interrupt registers on the CP2200/1 until the Receive FIFO Empty flag comes back as a zero.  On this condition it transitions to state 011.

Block 010 continuously polls the interrupt registers on the CP2200/1 until the Receive FIFO Empty flag comes back as a zero.  On this condition it transitions to state 011.

*** ''New_St'': new state value to load into state register; goes to 011 when ''Done'' is high

*** ''New_St'': new state value to load into state register; goes to 011 when ''Done'' is high

=== (011) Read Packet ===

== (011) Read Packet ==

Block 011 is the only block with switching between following states.  Its first task is to load the MAC data of the packet.  If filtering inside of the FPGA is required, this block is responsible for it.  The only MAC filtering likely to be needed is a check to see if the destination MAC address matches the MAC address of the CP2200/1, but the CP2200/1 should filter this itself (verify in the data sheet).  If the packet is bad, this block tells the CP2200/1 to skip the packet and returns to block 010.  The MAC filter would be the first substate.

Block 011 is the only block with switching between following states.  Its first task is to load the MAC data of the packet.  If filtering inside of the FPGA is required, this block is responsible for it.  The only MAC filtering likely to be needed is a check to see if the destination MAC address matches the MAC address of the CP2200/1, but the CP2200/1 should filter this itself (verify in the data sheet).  If the packet is bad, this block tells the CP2200/1 to skip the packet and returns to block 010.  The MAC filter would be the first substate.

*** - transceiver control lines -

*** - transceiver control lines -

=== (100) Poll Status ===

== (100) Poll Status ==

This block will have at least two functional blocks: one to poll the temperature sensor and one to poll the ADC.  Its job is to update all status values from the status chips in preparation for transmission.  Additionally, it converts all values to 16-bit two's-complement before storing locally.  Once all status values have been updated it transitions to state 101.

This block will have at least two functional blocks: one to poll the temperature sensor and one to poll the ADC.  Its job is to update all status values from the status chips in preparation for transmission.  Additionally, it converts all values to 16-bit two's-complement before storing locally.  Once all status values have been updated it transitions to state 101.

*** ''New_St'': new state to be written to the state register; goes to 101 while ''Done'' is high

*** ''New_St'': new state to be written to the state register; goes to 101 while ''Done'' is high

=== (101) Transmit "S" ===

== (101) Transmit "S" ==

This block compiles the status values into a single packet by loading them into the CP2200/1 in a defined order and format, including padding/converting any values that need it.  Once the packet has been sent, the block transitions to state 010.

This block compiles the status values into a single packet by loading them into the CP2200/1 in a defined order and format, including padding/converting any values that need it.  Once the packet has been sent, the block transitions to state 010.

*** ''Done'': pulse to signal completion

*** ''Done'': pulse to signal completion

=== (110) Program DAC ===

== (110) Program DAC ==

This block will have a substate to obtain the programming mask.  It then loops 32 (or 24 or 16) times on a second substate that obtains the next programming value and, if the corresponding mask bit is high, programs that channel of the DAC.  A mux may be needed to select the appropriate bit from the programming mask.  It also updates the locally stored DAC channel values (which may be stored on the FPGA, the CP2200/1 Flash, or other) in preparation for a "D" response packet.  Then it transitions to state 111.

This block will have a substate to obtain the programming mask.  It then loops 32 (or 24 or 16) times on a second substate that obtains the next programming value and, if the corresponding mask bit is high, programs that channel of the DAC.  A mux may be needed to select the appropriate bit from the programming mask.  It also updates the locally stored DAC channel values (which may be stored on the FPGA, the CP2200/1 Flash, or other) in preparation for a "D" response packet.  Then it transitions to state 111.

*** ''New_St'': next state to load into the state register; goes to 111 when ''Done'' is high

*** ''New_St'': next state to load into the state register; goes to 111 when ''Done'' is high

=== (111) Transmit "D" ===

== (111) Transmit "D" ==

This block loads a "D" to the transmit buffer then loops 32 (or 24 or 16) times to load the locally stored DAC channel values to the transmit buffer.  Once the full packet has been loaded, it sends the packet, then transitions to state 010.

This block loads a "D" to the transmit buffer then loops 32 (or 24 or 16) times to load the locally stored DAC channel values to the transmit buffer.  Once the full packet has been loaded, it sends the packet, then transitions to state 010.