Changes

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.

== 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. This eliminates a need for the internal workings of the FPGA to be aware of the timing of the interface; hey simply order a start of transfer and wait for notification of the transfer's completion. The transceiver for its part initiates a read or write conversation with the CP2200/1 over the multiplex Intel bus upon request from the internals and returns data, if applicable, along with a "Done" pulse at the end of the conversation.

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. This eliminates a need for the internal workings of the FPGA to be aware of the timing of the interface; hey simply order a start of transfer and wait for notification of the transfer's completion. The transceiver for its part initiates a read or write conversation with the CP2200/1 over the multiplex Intel bus upon request from the internals and returns data, if applicable, along with a "Done" pulse at the end of the conversation.

For debugging purposes, a test input buffer will be added as stimulus for the combined FPGA simulation. This could take the form of a single packet or a full Ethernet Controller emulator. with the test waveform being injected either directly into the internal bus or on the Intel bus.

For debugging purposes, a test input buffer will be added as stimulus for the combined FPGA simulation. This could take the form of a single packet or a full Ethernet Controller emulator. with the test waveform being injected either directly into the internal bus or on the Intel bus.

=== 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

* ''Q'': 16-bit data-out bus (data pre-padded with 4 zeros to facilitate packaging into 2-byte words)

* ''Q'': 16-bit data-out bus (data pre-padded with 4 zeros to facilitate packaging into 2-byte words)

==== 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 ==