Difference between revisions of "Programming the Ethernet controller"

From UConn PAN
Jump to navigation Jump to search
m
 
(43 intermediate revisions by the same user not shown)
Line 1: Line 1:
The modules involved in communication with the Ethernet Controller chip serve as the core of the FPGA. The different tasks that need to be performed by these modules include  
+
The modules involved in communication with the Ethernet Controller chip (EC) serve as the core of the FPGA. The tasks that need to be performed by these modules include  
 
* executing the complex board reset and address lookup sequence
 
* executing the complex board reset and address lookup sequence
 
* polling for new packets and switching execution accordingly
 
* polling for new packets and switching execution accordingly
Line 6: Line 6:
 
* building return packets
 
* building return packets
  
In  our design, the modules involved with packet handling and interfacing with sensor chip controllers are organized by ''state''. A state register specifies the current stage of the process and only the corresponding module is allowed to act during that stage. Aside from defining a process sequence, the state serves as a complex "enable" signal for the modules, ensuring that only one module is driving the communication bus used to query the Ethernet Controller chip.
+
In  our design, the modules involved with packet handling and interfacing with sensor chip controllers are organized by ''state''. A state register specifies the current stage of the process and only the corresponding module is allowed to act during that stage. Aside from defining a process sequence, the state serves as a complex "enable" signal for the modules, ensuring that only one module is driving the communication bus used to query the EC.
 
 
 
 
 
 
= Interface =
 
 
 
:''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.
 
 
 
= The eight states =
 
 
 
There are eight major states to the module.
 
 
 
== State list ==
 
 
 
; (000) Reset Cycle
 
: The reset cycle resets the selected chips.  There are flags for resetting all 4 chips: DAC, ADC, temperature sensor, Ethernet controller.  This is the entry state from a power-on.  From this state, proceed unconditionally to 001.
 
; <s>(001) Transmit "I"</s>
 
: <s>This state transmits an "I" packet to acknowledge that a reset occurred but the board is now prepared to accept new packets and function normally. From this state, proceed unconditionally to 010.</s> "S"-Packet (from state 101) would do just as well, returning zeroed registers, location address etc for computer's address LUT.
 
; (010) Idle
 
: This is the idle state where the state machine awaits a new packet's arrival.  If the Receive FIFO is empty, it loops back on itself and continues checking the FIFO.  If the FIFO is not empty, proceed to 011.
 
; (011) Read Packet
 
: This state accesses the first packet.  If packets need to be filtered by the FPGA, this state will filter and return to 010 on a bad packet.  The MAC data is discarded, as it is unimportant to the FPGA, and the first data byte is read.  This byte is used as a switch: an ASCII "R" loops to 000.  A "Q" proceeds to 100.  A "P" proceeds to 110.  Any other value is a bad packet and the state machine returns to 010.
 
; (100) Poll Status
 
: This state polls the status chips (the ADC and the temperature sensor) so that recent data is ready for transmission.
 
; (101) Transmit "S"
 
: This state packages and transmits an "S" packet over the Ethernet to report back the status of the board in response to a "Q" packet.
 
; (110) Program DAC
 
: This state programs the DAC with new values according to the mask and data in the "P" packet.
 
; (111) Transmit "D"
 
: 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 ==
 
 
 
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 ==
 
 
 
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<sub>2:1</sub>:
 
** S<sub>2</sub> = 0: "Core cycle" that executes regularly and forms the spine of the state diagram.
 
*** S<sub>2:1</sub> = 00: "Initialization cycle" that prepares the state diagram for normal functioning.
 
*** S<sub>2:1</sub> = 01: "Standard cycle" that the state machine returns to most frequently to process appropriate switching to branches.
 
** S<sub>2</sub> = 1: "Branch cycles" that execute selectively based on received packets.
 
*** S<sub>2:1</sub> = 10: "Query cycle" as described in the page on [[Ethernet_packets#The_query_cycle|Ethernet packets]].
 
*** S<sub>2:1</sub> = 11: "Programming cycle" as described in the page on [[Ethernet_packets#The_programming_cycle|Ethernet packets]].
 
* S<sub>0</sub>:
 
** S<sub>0</sub> = 0: "Setup state" to prepare internal workings for a communication.
 
** S<sub>0</sub> = 1: "Transfer state" to communicate with the external PC.
 
 
 
  
 
= Controller =
 
= Controller =
Line 62: Line 12:
 
== 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. Simultaneity of the rising edge of the "Done" signal and the corresponding output data may not be guaranteed. This is solved by either
 +
# a one-cycle-delayed "Done" signal 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).   
 +
# coding the target component to read the data lines on the ''falling edge'' of the clock during the a "Go" signal.
 +
The latter method turned out to be the dominant one in this design.
  
== Transceiver ==
+
== The eight states ==
  
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.
+
=== State-Module organization ===
  
This unit serves as a bridge between the Ethernet Controller chip and the FPGA in terms of timing as well. The latter is run at the rate of its slowest client: the Temperature sensor which has a top recommended clock rate of 10 MHz. Given that CP2200/1 prefers 20 MHz, it was resolved that the FPGA will run on a 5 MHz clock subdivided from the Ethernet Controller's. The transceiver performs this subdivision and ensures data latching on the external and internal buses, as shown in the adjacent diagram.
+
The core of the the FPGA is divided roughly into eight modules enabled by by the 3-bit state value. Below is an index of the states and their corresponding modules. In this discussion of states, 'X' is a binary wild card the values are immediately explained.
  
[[Image:MuxIntelTiming.png|frame|Multiplexed Intel Bus and internal I/O timing scheme enforced by FPGA clocks]]
+
{| class="wikitable" border="1" align="center" style="text-align:center" cellspacing="0" cellpadding="4"
 
+
|+ State-Module Index
inputs
+
|-  
* ''fCLK'': "fast" (20MHz) clock
+
! State !! Module Name !! Description !! Succeeding State
* ''/Rst'': asynchronous, active-low reset
+
|-
* ''TxRx_Go'': pulse to begin a transmission
+
| align="center" | 000 || [[FPGA_Reset|Reset]]_hard || align="left" |Coordinates the reset and start-up of the EC. || 100
* ''TxRx_RiW'': read/write toggle: active-high read, active-low write
+
|-
* ''TxRx_Ain'': 8-bit bus for address to read to/write from
+
| align="center" | 001 || [[FPGA_Reset|Reset]]_soft || align="left" | Extends the reset to the PC-requested chips and records PC's MAC for later communication. || 100
* ''TxRx_Din'': 8-bit bus for data to write; ignored during a read
+
|-
 
+
| align="center" | 010 || [[FPGA_Idler|Idler]] || align="left" | This is the active module during the FPGA's default idle state. It awaits the "Receive FIFO buffer not empty" interrupt and passes control to the Reader || 011
outputs to internals
+
|-
* ''Done'': pulse to signal completion of a transmission
+
| align="center" | 011 || [Packet] [[FPGA_Reader|Reader]] || align="left" | Skips the packet header and reads the first two bytes ("location" and "type") of the packet payload. It rejects misdirected or invalid-type bytes. Control is passed according to packet type to Query, Program or Reset Modules || 100, 110, 00X
* <s>''R/W_out'': read/write flag: active-high read, active-low write</s>
 
* <s>''A_out'': 8-bit bus for address of last read/write</s>
 
* ''D_out'': 8-bit bus for data of last read; internal systems should ignore for a write
 
* ''CLK'' : 5MHz clock for all internals subdivided from the master 20MHz clock.
 
 
 
outputs to CP2200/1
 
* ''/CS'': active-low chip select
 
* ''MotEn'': Motorola/Intel format toggle: active-high Motorola, active-low Intel
 
* ''MuxEn'': Multiplexed flag; not used for CP2201
 
* ''ALE'': ALE strobe
 
* ''/Wr'': Active-low write flag
 
* ''/Rd'': Active-low read flag
 
 
 
inouts
 
* ''AD'': 8-bit address and data 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 ==
 
 
 
=== State Register ===
 
A three-bit register to store the current state.
 
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset to zero the register (puts system into reset state)
 
* ''En'': write enable
 
* ''D'': three-bit data-in bus
 
 
 
outputs
 
* ''Q'': three-bit data-out bus
 
 
 
 
 
=== Packet Type Register ===
 
An 8-bit register to store the 2nd byte of an accepted packet.
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset to zero the register (puts system into reset state)
 
* ''En'': write enable
 
* ''D'': 8-bit data-in bus
 
 
 
outputs
 
* ''Q'': 8-bit data-out bus
 
 
 
 
 
=== Temperature Register ===
 
A 16-bit register to store the most recent temperature data.
 
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset to zero the register (puts system into reset state)
 
* ''En'': write enable
 
* ''D'': 10-bit data-in bus
 
 
 
outputs
 
* ''Q'': 16-bit data-out bus (data pre-padded with 6 zeros to facilitate packaging into 2-byte words)
 
 
 
 
 
=== 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.
 
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset to zero the register (puts system into reset state)
 
* ''En'': write enable
 
* ''A'': 3-bit address
 
* ''D'': 12-bit data-in bus
 
 
 
outputs
 
* ''Q'': 16-bit data-out bus (data pre-padded with 4 zeros to facilitate packaging into 2-byte words)
 
 
 
 
 
=== 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.
 
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset to zero the register (puts system into reset state)
 
* ''En'': write enable
 
* ''A'': 5/5/4-bit address (currently set at 5-bit)
 
* ''D'': 14-bit data-in bus
 
 
 
outputs
 
* ''Q'': 16-bit data-out bus (data pre-padded with 2 zeros to facilitate packaging into 2-byte words)
 
 
 
== Reusable Components ==
 
 
 
Several components were found useful as reusable units rather than unique modules. They are listed here roughly from the low level units to high level "wrappers".
 
 
 
=== Read Request (<tt>reqFromAddr</tt>) ===
 
 
 
Sends request for reading (R/W pin high) to the Transceiver at the specified address. (Optionally "Go" pulse can be appropriately delayed in this module to ensure that parameter signals sent to transceiver have gone through their transitions. Currently, these provisions are commented out, relying on clock falling edge latching of the sent data.) This unit is not intended for direct use, but rather to be the core of the fetcher components described here.
 
 
 
 
 
=== 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" was to obscure the complexity of appropriate delays to ensure proper signal latching. The delayed version is currently commented out under the assumption of falling edge of clock latching of data by the Transceiver.
 
 
 
 
 
=== 2-byte Write Request (<tt>wr2BtoAddr</tt>) ===
 
 
 
Coordinates write operations to two adjacent 1-byte registers in the Ethernet Controller chip. This is an essential abstraction because the controller often requires 16-bit exchanges especially when specifying 16-bit buffer locations in random memory access. Only the address of the first register needs to be passed in.
 
 
 
 
 
=== Byte Fetcher (<tt>getByte</tt>) ===
 
 
 
Fetches a byte of data from the Ethernet Controller registers via the Transceiver. This unit creates yet another abstraction layer "in series" 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". The actual request is performed via the <tt>reqFromAddr</tt> unit described above, so the timing characteristics are inherited from that module.
 
 
 
 
 
=== 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 just a wrapper around <tt>GetByte</tt> passing through all signals accept the fixed address input.
 
 
 
 
 
=== Random Access Write (<tt>RAwrToAddr</tt>) ===
 
 
 
Writing directly to Ethernet Controller RAM (not to be confused with the control registers) in random access mode requires more work. A 16-bit address needs to be passed in 8 bits at a time to appropriate control registers and the actual 8-bit data is sent on the third transaction. Because the buffer is sometimes loaded in sequentially, this unit is designed to just increment the address of the previous random access write if the passed in address has a '1' in the MSB. (This would never be a legal address, as it is out of range.) The calling module, therefore, does not need to store the current write location of the RAM. <tt>wr2BtoAddr</tt> and <tt>wrToAddr</tt> are very convenient for these three transactions.
 
 
 
 
 
=== 2-byte Random Access Write (<tt>RAwr2BtoAddr</tt>) ===
 
 
 
Because the data values exchanged between the board and the PC range from 10 to 14 bit depth, zero padded 16-bit words will be used. So, to load this 2-byte word into the transfer buffer requires two random access writes.  This module packages this functionality by including two calls to <tt>RAwrToAddr</tt> with address increments and input data latching taken into account.
 
 
 
=== Miscellaneous Components ===
 
 
 
== (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]].
 
 
 
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
* ''D_En'': DAC enable, assume held high/low by previous block
 
* ''A_En'': ADC enable, assume held high/low by previous block
 
* ''E_En'': Ethernet enable, assume held high/low by previous block
 
 
 
internal signals
 
* ''S_En'': state enable, ''S_En'' <= not (''St(2)'' or ''St(1)'' or ''St(0)'')
 
* ''Go'': when ''S_En'' goes high ''Go'' pulses for one cycle
 
* ''D_Go'': DAC reset go pulse, ''D_Go'' <= ''Go'' and ''D_En''
 
* ''A_Go'': ADC reset go pulse, ''A_Go'' <= ''Go'' and ''A_En''
 
* ''E_Go'': Ethernet reset go pulse, ''E_Go'' <= ''Go'' and ''E_En''
 
 
 
blocks
 
* '''DAC Reset'''
 
** Resets and initializes the DAC.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''D_Go'': go pulse to begin reset/initialization process
 
** outputs
 
*** - All DAC reset/initialization control lines -
 
*** ''D_Done'': goes high when reset/initialization process is complete, falls on ''D_Go'' pulse
 
* '''ADC Reset'''
 
** Resets and initializes the ADC.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''A_Go'': go pulse to begin reset/initialization process
 
** outputs
 
*** - All ADC reset/initialization control lines -
 
*** ''A_Done'': goes high when reset/initialization process is complete, falls on ''A_Go'' pulse
 
* '''Ethernet Reset'''
 
** Resets and initializes the Ethernet controller.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''E_Go'': go pulse to begin reset/initialization process
 
** outputs
 
*** - All Ethernet reset/initialization control lines -
 
*** ''E_Done'': goes high when reset/initialization process is complete, falls on ''E_Go'' pulse
 
* '''Coordinator'''
 
** Coordinates the completion of each reset cycle and notifies other blocks that the reset process is complete.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''D_En'': high when DAC is to be reset
 
*** ''D_Done'': high when DAC is done resetting
 
*** ''A_En'': high when ADC is to be reset
 
*** ''A_Done'': high when ADC is done resetting
 
*** ''E_En'': high when Ethernet controller is to be reset
 
*** ''E_Done'': high when Ethernet controller is done resetting
 
** internal signals
 
*** ''Flag'' <= (''D_Done'' or not ''D_En'') and (''A_Done'' or not ''A_En'') and (''E_Done'' or not ''E_En'')
 
** outputs
 
*** ''Done'': when ''Flag'' goes high, ''Done'' pulses for one cycle; connects to state register as an enable
 
*** ''New_St'': new state to be written to the state register; goes to 001 while ''Done'' is high
 
 
 
== (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.
 
 
 
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
 
 
internal signals
 
* ''S_En'': state enable, ''S_En'' <= not ''St(2)'' and ''St(1)'' and not ''St(0)''
 
* ''Go'': when ''S_En'' goes high ''Go'' pulses for one cycle
 
 
 
blocks
 
* '''Transmitter'''
 
** Loads an ASCII "I" (0x49, 0100 1001) to the transmitter 46 times (the first value must be "I" and the rest are garbage, so padding with "I" is simplest) to fill in a complete packet (accounts for any register incrementing or other loading control necessary).
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin sending
 
*** ''Inc'': ''Done'' signal from transceiver; initiates next sending
 
** outputs
 
*** ''TxRx_A'': ''A_in'' signal to transceiver
 
*** ''TxRx_D'': ''D_in'' signal to transceiver
 
*** ''TxRx_R/W'': ''R/W'' signal to transceiver; tied to write (zero)
 
*** ''TxRx_Go'': ''Go'' signal to transceiver
 
*** ''Done'': pulses for one cycle; connects to state register as an enable line
 
*** ''New_St'': new state to load into state register; goes to 010 when ''Done'' is high
 
 
 
== (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.
 
 
 
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''state_in'': 3-bit state value
 
 
 
* ''TxRx_D'': 8-bit data from transceiver
 
* ''TxRx_Done'': pulse from transceiver to signal transfer complete
 
* ''TxRx_Go'': transceiver go line
 
* ''TxRx_R/W'': read/write flag for transceiver
 
* ''TxRx_Aout'': register address bus for transceiver
 
 
 
 
 
blocks
 
* '''Request INT0RD''' (0x76) register via <tt>reqFromAddr</tt> pulsed by the ''LoopEn'' signal from Looper (below).
 
* '''Looper'''
 
** Switch to determine if this state should loop on itself or continue to the next state.
 
** inputs
 
*** ''S_En'': state enable
 
*** ''TxRx_Done'': ''Done'' pulse from transceiver
 
*** ''TxRx_Data'': ''D_out'' bus from transceiver
 
** outputs
 
*** ''LoopEn'': pulse to repeat fetch cycle; ''Loop'' <= ''S_En'' and ''TxRx_Done'' and ''TxRx_Data(6)''
 
*** ''Done'': pulse to finish state; connects to state counter as an enable; ''Done'' <= ''S_En'' and ''TxRx_Done'' and not ''TxRx_Data(6)''
 
*** ''New_St'': new state value to load into state register; goes to 011 when ''Done'' is high
 
 
 
== (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.
 
 
 
After MAC filtering comes the second substate (or the only substate if MAC filtering is found to be unnecessary).  This reads the first byte of the packet's data and uses it as a switch to determine the transition to the next state:
 
{| align="center" cellpadding="4" border="0" cellspacing="0" style="text-align:center"
 
! ASCII
 
|  
 
! Next State
 
 
|-
 
|-
| R ||     || 000
+
| align="center" | 100 || [[FPGA_Querier|Querier]] || align="left" | Queries the values of the Temperature sensor and ADC, stores them in their respective registers and passes control to the Transmitter for delivery || 101 
 
|-
 
|-
| Q ||     || 100
+
| align="center" | 110 || [DAC] [[FPGA_Programmer|Programmer]] || align="left" | Programs the DAC based on instructions in packet and stores the values in the DAC register. || 111
 
|-
 
|-
| P ||     || 110
+
| align="center" | 1X1 || [Packet] [[FPGA_Transmitter|Transmitter]] || align="left" | Composes and sends a packet of either [[Ethernet_packets|'S' or 'D' type]]. These correspond respectively to "'''S'''tatus" values reported by the sensor chips (state=101) and current '''D'''AC values (state=111) || 010
 
|-
 
|-
| other ||      || 010
 
 
|}
 
|}
Anything other than the three defined packets is considered a bad packet and is discarded in the CP2200/1 before transitioning back to state 010.  An "R" packet obtains the reset mask from the second byte then discards the packet before transitioning to state 000.  State 000 assumes that the reset mask is held, so this output needs to be latched in place until the next time this block activates.  A query has no switches or masks on it, so a "Q" packet will be discarded from the CP2200/1 before continuing on.  A "P" packet has a large amount of data attached to it, so that is the only packet not discarded before continuing to the next state.  This allows later states to access the packet data, but also puts on those later states the responsibility for discarding the packet once finished with it.
 
  
inputs
+
=== State interconnect ===
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
* - transceiver control lines -
 
  
internal signals
+
As described above, these states form the outline of the functional block diagram. 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.
* ''S_En'': state enable, ''S_En'' <= not (''St(2)'' or ''St(1)'' or ''St(0)'')
 
* ''Go'': when ''S_En'' goes high ''Go'' pulses for one cycle
 
  
blocks
 
* '''MAC Filter'''
 
** This block checks that the MAC address in the packet destination field is the same as the MAC address of the board.  If not the packet is discarded, if so then the MAC data (destination and source MAC address, packet length) are discarded and processing continues.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin
 
*** - transceiver control lines -
 
** outputs
 
*** ''Discard'': pulse to State Advance to discard packet and return to 010
 
*** ''Continue'': pulse to Switch to continue processing
 
*** - transceiver control lines -
 
* '''Switch'''
 
** This block reads the first data byte of the packet and uses it as a switch to direct the state machine to the appropriate next step.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin
 
*** - transceiver control lines -
 
** outputs
 
*** ''Discard'': pulse to State Advance to discard packet and return to 010
 
*** ''Reset_000'': pulse to State Advance to discard packet and go to 000
 
*** ''Query'': pulse to State Advance to discard packet and go to 100
 
*** ''Program'': pulse to State Advance to keep packet and go to 110
 
*** - transceiver control lines -
 
* '''State Advance'''
 
** This block has several ''Go'' lines and based on which is pulsed the next state is set up by loading a new state value into the state register.  It also discards packets other than "P".
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Discard'': pulse to discard packet and return to 010
 
*** ''Reset_000'': pulse to discard packet and go to 000
 
*** ''Query'': pulse to discard packet and go to 100
 
*** ''Program'': pulse to keep packet and go to 110
 
*** - transceiver control lines -
 
** outputs
 
*** ''Done'': pulse to signal completion; connects to state register enable
 
*** ''New_St'': new state to load to state register; goes to 000, 010, 100, or 110 when ''Done'' is high depending on switching
 
*** - transceiver control lines -
 
  
== (100) Poll Status ==
+
== Miscellaneous non-state-based components ==
  
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.
+
Please refer to the individual design detail pages for:
 +
* [[FPGA_Registers|Registers]]
 +
* [[FPGA_Reusables|Miscellaneous Reusable Components]]
  
Currently we assume that data values will be stored in the FPGA.  If data values will be stored on CP2200/1 Flash memory or other storage device, the interfaces and blocks will have to be adjusted appropriately.
 
  
inputs
+
== Interface ==
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
  
internal signals
+
[[Image:MuxIntelTiming.png|frame|Multiplexed Intel Bus and internal I/O timing scheme enforced by FPGA clocks]]
* ''S_En'': state enable, ''S_En'' <= not (''St(2)'' or ''St(1)'' or ''St(0)'')
 
* ''Go'': when ''S_En'' goes high ''Go'' pulses for one cycle
 
  
blocks
+
The compact approach to wire and poll the EC is via the Multiplexed Intel bus format. Aside from some use of the interrupt and reset pins, all communication is done via this bus. (The control architecture of the chip uses 8-bit registers selected with 8-bit addresses.) A communication over this bus begins with an pulse on the "ALE" pin, by the fall of which a valid address is expected on the 8-bit inout "AD" bus. After this /RD (/WR) signal falls, executing the read (write) process, and then rises accompanied with valid input from (to) the chip. The adjacent figure illustrates this process along with the approach to timing the conversation taken in this design. Please refer to Section 16.2 in the manual for details on the timing tolerances on this bus.
* '''ADC Poll'''
 
** Updates values stored in the FPGA from the ADC. Obtains data from ADC, converts to 16-bit two's-complement, and stores.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': go pulse to begin
 
** outputs
 
*** - All ADC control lines -
 
*** ''A_Done'': goes high when reset/initialization process is complete, falls on ''Go'' pulse
 
*** ''En'': enable line for writing to the internal registers
 
*** ''Sel'': 3-bit select bus to specify which ADC channel data is available
 
*** ''Data'': 16-bit data bus to carry data to FPGA internal registers
 
* '''Temp Poll'''
 
** Updates value stored in the FPGA from the temperature sensor. Obtains data from temperature sensor, converts to 16-bit two's-complement, and stores.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': go pulse to begin
 
** outputs
 
*** - All temperature sensor control lines -
 
*** ''En'': enable line for writing to the internal register
 
*** ''Data'': 16-bit data bus to carry data to FPGA internal registers
 
* '''Coordinator'''
 
** Coordinates the completion of each polling cycle and notifies other blocks that the polling process is complete.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''A_Done'': high when ADC is done polling
 
** outputs
 
*** ''Done'': when ''A_Done'' goes high, ''Done'' pulses for one cycle; connects to state register as an enable
 
**: Note that the temperature sensor does not signal completion. That is because the temperature sensor need only update one value, while the ADC must update eight values. Thus it is known ahead of time that the temperature sensor will already be done by the time the ADC is done.
 
*** ''New_St'': new state to be written to the state register; goes to 101 while ''Done'' is high
 
  
== (101) Transmit "S" ==
+
As shown in the figure, the 20&nbsp;MHz clock is very convenient for metering this conversation. The communication delay for the FPGA (most of which runs essentially on 5&nbsp;MHz) turns out to be only two clock cycles.
  
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 communication standard calls for a bridge module that communicates with the EC upon request from other modules. A "[[FPGA_Transceiver|Transceiver]]" was designed for this purpose. It abstracts the communication with the EC as well as the clock frequency difference. This module in fact subdivides the main 20&nbsp;MHz; clock to generate the "slow" 5&nbsp;MHz clock for the rest of the FPGA. Please refer to the [[FPGA_Transceiver|detailed page]] on the Transceiver for more information.
  
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
  
internal signals
+
== Combined control flow ==
* ''S_En'': state enable, ''S_En'' <= not (''St(2)'' or ''St(1)'' or ''St(0)'')
 
* ''Go'': when ''S_En'' goes high ''Go'' pulses for one cycle
 
  
blocks
+
[[Image:OperationCourse.png|frame|Operation course between the digital board and the controller PC]]
* '''Temp Loader'''
 
** This block reads the temperature value from the internal registers and loads it to the transmit buffer.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin; feeds from ''Go'' internal signal of block 101
 
*** ''D_in'': 16-bit data bus from internal registers
 
*** ''TxRx_Done'': ''Done'' signal from transceiver
 
** ouputs
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_R/W'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''TxRx_D'': ''D_in'' bus on transceiver
 
*** ''Done'': pulse to signal completion
 
* '''ADC Loader'''
 
** This block reads the ADC values from the internal registers and loads them to the transmit buffer in order: channel zero to channel seven.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin; feeds from ''Done'' signal of Temp Loader
 
*** ''D_in'': 16-bit data bus from internal registers
 
*** ''TxRx_Done'': ''Done'' signal from transceiver
 
** ouputs
 
*** ''Sel'': 3-bit select bus for internal registers
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_R/W'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''TxRx_D'': ''D_in'' bus on transceiver
 
*** ''Done'': pulse to signal completion
 
* '''Padder'''
 
** This block pads the packet to the minimum 46 bytes.  Only 19 bytes have been loaded by this point (1 byte "S", 2 byte temperature, 8 x 2 byte ADC), so 27 bytes of padding (zero) must be loaded.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin; feeds from ''Done'' signal of ADC Loader
 
*** ''TxRx_Done'': ''Done'' signal from transceiver
 
** outputs
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_R/W'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''TxRx_D'': ''D_in'' bus on transceiver
 
*** ''Done'': pulse to signal completion
 
* '''Sender'''
 
** This block tells the CP2200/1 to send the completed packet.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin; feeds from ''Done'' signal of Padder
 
*** ''TxRx_Done'': ''Done'' signal from transceiver
 
** outputs
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_R/W'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''TxRx_D'': ''D_in'' bus on transceiver
 
*** ''Done'': pulse to signal completion
 
  
== (110) Program DAC ==
+
Conceptually, the operation course must proceed as outlined in the adjacent figure. The main concern in the tagger control is maintaining a map between board/channel addresses and actual energy bins. For this purpose, the diagrammed two-stage reset plan was devised in the course of which the FPGA learns the PC's MAC address and the PC builds a MAC-Location lookup table. (The "Location" is an 8-byte slot identifier which allows the PC to pinpoint the SiPM channel group.)
  
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.
+
The internal FPGA operation course that supports this scheme (and the general control board functionality requirements) is outlined below.
  
inputs
+
[[Image:DigBoardScheme.png|center]]
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
  
internal signals
 
* ''S_En'': state enable, ''S_En'' <= not (''St(2)'' or ''St(1)'' or ''St(0)'')
 
* ''Go'': when ''S_En'' goes high ''Go'' pulses for one cycle
 
  
blocks
+
= Emulator =
* '''Mask Fetcher'''
 
** This block reads the programming mask, contained in the second data byte (first remaining byte) through the 5th/4th/3rd byte (4th/3rd/2nd remaining byte), and saves it into a 32/24/16-bit register.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin, comes from ''Go'' internal signal of block 110
 
*** ''TxRx_D'': 8-bit data bus from transceiver
 
*** ''TxRx_Done'': ''Done'' signal from transceiver
 
** outputs
 
*** ''TxRx_Go'': ''Go'' input on transceiver
 
*** ''TxRx_R/W'': ''R/W'' input on transceiver; tied to read (one)
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''Mask'': 32/24/16-bit readout of programming mask
 
*** ''Done'': pulse to signal that mask has been obtained
 
* '''Programmer'''
 
** Programs the DAC.  Loops 32/24/16 times, obtaining the next byte from the CP2200/1 buffer, checking the mask, programming the DAC if the mask is 1 or skipping if the mask is 0.  Also writes the value to the internal DAC value storage registers (or Flash memory or other).
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin; feeds from ''Done'' signal of Mask Fetcher
 
*** ''TxRx_D'': ''D_out'' bus on transceiver
 
*** ''TxRx_Done'': ''Done'' signal on transceiver
 
** outputs
 
*** - DAC control lines -
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_R/W'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''Sel'': 5/5/4-bit select bus to internal registers
 
*** ''Data'': 32/24/16-bit data bus to internal registers
 
*** ''Done'': pulse to signal completion
 
* '''Discarder'''
 
** This block orders the CP2200/1 to discard the packet, now that the FPGA is done with all the data contained within the packet.
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin; feeds from ''Done'' signal of Programmer
 
*** ''TxRx_Done'': ''Done'' signal on transceiver
 
** outputs
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_R/W'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''Done'': pulse to signal completion
 
*** ''New_St'': next state to load into the state register; goes to 111 when ''Done'' is high
 
  
== (111) Transmit "D" ==
+
Since the modules described here represent the core of the FPGA, their combined simulation calls for inclusion of all other fringe modules.  Essentially the whole FPGA will have to be tested to ensure this scheme for the core is acting properly. The challenge is in the complexity of the stimulus for such simulation: whole packets will need to be sent in and possibly inter-packet Ethernet Controller Chip states tested.
  
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.
+
A stripped down emulator for the Ethernet Controller has been written. It is a essentially a set of registers with a Multiplexed Intel bus communication layer and packet file read/write layers. These registers, however, are not passive memory banks but include "events" that are triggered by particular register states. For instance writing to registers designated to make up a receive buffer pointer actually delivers the requested byte from the buffer to the appropriate control register to be available for a subsequent request. A simple interrupt system (stimulated externally by the simulation layer) has also been included.
  
inputs
 
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
  
internal signals
+
= See Also =
* ''S_En'': state enable, ''S_En'' <= not (''St(2)'' or ''St(1)'' or ''St(0)'')
 
* ''Go'': when ''S_En'' goes high ''Go'' pulses for one cycle
 
  
blocks
+
* State Modules
* '''Loader'''
+
** [[FPGA_Reset|Reset]]
** Loads the DAC values into a packet in the transmission buffer of the CP2200/1.  Loops through all values and loads them in order (channel zero to channel thirty-one).
+
** [[FPGA_Idler|Idler]]
** inputs
+
** [[FPGA_Reader|Reader]]
*** ''Clk'': clock
+
** [[FPGA_Querier|Querier]]
*** ''/Rst'': asynchronous, active-low reset
+
** [[FPGA_Programmer|Programmer]]
*** ''Go'': pulse to begin loading a packet
+
** [[FPGA_Transmitter|Trasmitter]]
*** ''TxRx_Done'': ''Done'' signal on transceiver
 
*** ''Data'': 14-bit data bus from internal registers
 
** outputs
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_RW'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''TxRx_D'': ''D_in'' bus on transceiver
 
*** ''Done'': pulse to signal completion
 
* '''Sender'''
 
** Tells CP2200/1 to send the packet
 
** inputs
 
*** ''Clk'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin, connected to ''Done'' signal from Loader
 
*** ''TxRx_Done'': ''Done'' signal from transceiver
 
** outputs
 
*** ''TxRx_Go'': ''Go'' signal on transceiver
 
*** ''TxRx_RW'': ''R/W'' signal on transceiver
 
*** ''TxRx_A'': ''A_in'' bus on transceiver
 
*** ''TxRx_D'': ''D_in'' bus on transceiver
 
*** ''Done'': pulse to signal completion
 
*** ''New_St'': 3-bit bus of new state to write to state register; goes to 010 when ''Done'' is high
 
  
 +
* Non-state Modules
 +
** [[FPGA_Transceiver|Transceiver]]
 +
** [[FPGA_Interrupt_Catcher|Interrupt Catcher]]
 +
** [[FPGA_Registers|Registers]]
  
= Emulator =
+
* [[Ethernet_packets|Ethernet Packet formatting]]
 
 
Since the modules described here represent the core of the FPGA, their combined simulation calls for inclusion of all other fringe modules.  Essentially the whole FPGA will have to be tested to ensure this scheme for the core is acting properly. The challenge is in the complexity of the stimulus for such simulation: whole packets will need to be sent in and possibly inter-packet Ethernet Controller Chip states tested.
 
 
 
Proper reading of packets can be implemented with a module inside the Transceiver that releases its test buffer byte by byte to simulate the AutoRead mode. A more extensive simulation would be useful which includes the testing of the Intel Muxed bus and which would test packet assembly, sending and Ethernet polling procedures.
 

Latest revision as of 06:33, 5 November 2009

The modules involved in communication with the Ethernet Controller chip (EC) serve as the core of the FPGA. The tasks that need to be performed by these modules include

  • executing the complex board reset and address lookup sequence
  • polling for new packets and switching execution accordingly
  • collecting sensor information upon a status report request
  • programming the DAC upon a program packet receipt
  • building return packets

In our design, the modules involved with packet handling and interfacing with sensor chip controllers are organized by state. A state register specifies the current stage of the process and only the corresponding module is allowed to act during that stage. Aside from defining a process sequence, the state serves as a complex "enable" signal for the modules, ensuring that only one module is driving the communication bus used to query the EC.

Controller

Foreword on Timing

With a controller this complex, the timing of signals must be inspected even more scrupulously than usual. Simultaneity of the rising edge of the "Done" signal and the corresponding output data may not be guaranteed. This is solved by either

  1. a one-cycle-delayed "Done" signal to ensure that the data lines have been stabilized. (All delays are implemented via the c_delay module which postpones the signal by one cycle via two sequential flip-flops, each shifting by half-cycle).
  2. coding the target component to read the data lines on the falling edge of the clock during the a "Go" signal.

The latter method turned out to be the dominant one in this design.

The eight states

State-Module organization

The core of the the FPGA is divided roughly into eight modules enabled by by the 3-bit state value. Below is an index of the states and their corresponding modules. In this discussion of states, 'X' is a binary wild card the values are immediately explained.

State-Module Index
State Module Name Description Succeeding State
000 Reset_hard Coordinates the reset and start-up of the EC. 100
001 Reset_soft Extends the reset to the PC-requested chips and records PC's MAC for later communication. 100
010 Idler This is the active module during the FPGA's default idle state. It awaits the "Receive FIFO buffer not empty" interrupt and passes control to the Reader 011
011 [Packet] Reader Skips the packet header and reads the first two bytes ("location" and "type") of the packet payload. It rejects misdirected or invalid-type bytes. Control is passed according to packet type to Query, Program or Reset Modules 100, 110, 00X
100 Querier Queries the values of the Temperature sensor and ADC, stores them in their respective registers and passes control to the Transmitter for delivery 101
110 [DAC] Programmer Programs the DAC based on instructions in packet and stores the values in the DAC register. 111
1X1 [Packet] Transmitter Composes and sends a packet of either 'S' or 'D' type. These correspond respectively to "Status" values reported by the sensor chips (state=101) and current DAC values (state=111) 010

State interconnect

As described above, these states form the outline of the functional block diagram. 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.


Miscellaneous non-state-based components

Please refer to the individual design detail pages for:


Interface

Multiplexed Intel Bus and internal I/O timing scheme enforced by FPGA clocks

The compact approach to wire and poll the EC is via the Multiplexed Intel bus format. Aside from some use of the interrupt and reset pins, all communication is done via this bus. (The control architecture of the chip uses 8-bit registers selected with 8-bit addresses.) A communication over this bus begins with an pulse on the "ALE" pin, by the fall of which a valid address is expected on the 8-bit inout "AD" bus. After this /RD (/WR) signal falls, executing the read (write) process, and then rises accompanied with valid input from (to) the chip. The adjacent figure illustrates this process along with the approach to timing the conversation taken in this design. Please refer to Section 16.2 in the manual for details on the timing tolerances on this bus.

As shown in the figure, the 20 MHz clock is very convenient for metering this conversation. The communication delay for the FPGA (most of which runs essentially on 5 MHz) turns out to be only two clock cycles.

This communication standard calls for a bridge module that communicates with the EC upon request from other modules. A "Transceiver" was designed for this purpose. It abstracts the communication with the EC as well as the clock frequency difference. This module in fact subdivides the main 20 MHz; clock to generate the "slow" 5 MHz clock for the rest of the FPGA. Please refer to the detailed page on the Transceiver for more information.


Combined control flow

Operation course between the digital board and the controller PC

Conceptually, the operation course must proceed as outlined in the adjacent figure. The main concern in the tagger control is maintaining a map between board/channel addresses and actual energy bins. For this purpose, the diagrammed two-stage reset plan was devised in the course of which the FPGA learns the PC's MAC address and the PC builds a MAC-Location lookup table. (The "Location" is an 8-byte slot identifier which allows the PC to pinpoint the SiPM channel group.)

The internal FPGA operation course that supports this scheme (and the general control board functionality requirements) is outlined below.

DigBoardScheme.png


Emulator

Since the modules described here represent the core of the FPGA, their combined simulation calls for inclusion of all other fringe modules. Essentially the whole FPGA will have to be tested to ensure this scheme for the core is acting properly. The challenge is in the complexity of the stimulus for such simulation: whole packets will need to be sent in and possibly inter-packet Ethernet Controller Chip states tested.

A stripped down emulator for the Ethernet Controller has been written. It is a essentially a set of registers with a Multiplexed Intel bus communication layer and packet file read/write layers. These registers, however, are not passive memory banks but include "events" that are triggered by particular register states. For instance writing to registers designated to make up a receive buffer pointer actually delivers the requested byte from the buffer to the appropriate control register to be available for a subsequent request. A simple interrupt system (stimulated externally by the simulation layer) has also been included.


See Also