Difference between revisions of "Programming the Ethernet controller"

From UConn PAN
Jump to navigation Jump to search
 
(108 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
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
 +
# 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.
 +
 +
== 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.
 +
 +
{| class="wikitable" border="1" align="center" style="text-align:center" cellspacing="0" cellpadding="4"
 +
|+ State-Module Index
 +
|-
 +
! State !! Module Name !! Description !! Succeeding State
 +
|-
 +
| align="center" | 000 || [[FPGA_Reset|Reset]]_hard || align="left" |Coordinates the reset and start-up of the EC. || 100
 +
|-
 +
| 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
 +
|-
 +
| 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
 +
|-
 +
| 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
 +
|-
 +
| 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 
 +
|-
 +
| 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
 +
|-
 +
| 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
 +
|-
 +
|}
 +
 +
=== 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:
 +
* [[FPGA_Registers|Registers]]
 +
* [[FPGA_Reusables|Miscellaneous Reusable Components]]
 +
 +
 
== Interface ==
 
== Interface ==
  
:''See also: [[Ethernet packets]]''
+
[[Image:MuxIntelTiming.png|frame|Multiplexed Intel Bus and internal I/O timing scheme enforced by FPGA clocks]]
:''See also: [[Ethernet state diagram]]''
+
 
 +
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.
  
== Emulator ==
+
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.
  
== Controller ==
+
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.
  
* '''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.
 
** inputs
 
*** ''CLK'': clock
 
*** ''/Rst'': asynchronous, active-low reset
 
*** ''Go'': pulse to begin a transmission
 
*** ''R/W_in'': read/write toggle: active-high read, active-low write
 
*** ''A_in'': 8-bit bus for address to read to/write from
 
*** ''D_in'': 8-bit bus for data to write; ignored during a read
 
** outputs to internals
 
*** ''Done'': pulse to signal completion of a transmission
 
*** ''R/W_out'': read/write flag: active-high read, active-low write
 
*** ''A_out'': 8-bit bus for address of last read/write
 
*** ''D_out'': 8-bit bus for data of last read; internal systems should ignore for a write
 
** 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
 
  
=== (000) Reset Cycle ===
+
== Combined control flow ==
  
inputs
+
[[Image:OperationCourse.png|frame|Operation course between the digital board and the controller PC]]
* ''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
+
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.)
* ''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
+
The internal FPGA operation course that supports this scheme (and the general control board functionality requirements) is outlined below.
* '''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 counter as an enable (thereby incrementing the ''State'' to 001)
 
  
=== (001) Transmit "I" ===
+
[[Image:DigBoardScheme.png|center]]
  
=== (010) Idle ===
 
  
inputs:
+
= Emulator =
* ''Clk'': clock
 
* ''/Rst'': asynchronous, active-low reset
 
* ''State'': 3-bit state value
 
* ''TxRx_A'': 8-bit address from transceiver
 
* ''TxRx_D'': 8-bit data from transceiver
 
* ''TxRx_Done'': pulse from transceiver to signal transfer complete
 
  
internal signals
+
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.
* ''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
+
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.
* '''Fetcher'''
 
** Reads register 0x76 (INT0RD) by sending a read request to the transceiver
 
** inputs
 
*** ''F_Go'': pulse to start request, ''F_Go'' <= ''Go'' or ''Loop''
 
** outputs
 
*** ''TxRx_Go'': ''Go'' line on transceiver
 
*** ''TxRx_R/W'': ''R/W'' line on transceiver, tied high (read)
 
*** ''TxRx_A'': ''A_in'' bus on transceiver, tied to 0x76 (0111 0110)
 
**** Note: ''D_in'' on transceiver is not used; assume this line defaults to zero
 
* '''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
 
*** ''Loop'': 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 in order to increment the state to 011; ''Done'' <= ''S_En'' and ''TxRx_Done'' and not ''TxRx_Data(6)''
 
  
=== (011) Read Packet ===
 
  
=== (100) Poll Status ===
+
= See Also =
  
=== (101) Transmit "S" ===
+
* State Modules
 +
** [[FPGA_Reset|Reset]]
 +
** [[FPGA_Idler|Idler]]
 +
** [[FPGA_Reader|Reader]]
 +
** [[FPGA_Querier|Querier]]
 +
** [[FPGA_Programmer|Programmer]]
 +
** [[FPGA_Transmitter|Trasmitter]]
  
=== (110) Program DAC ===
+
* Non-state Modules
 +
** [[FPGA_Transceiver|Transceiver]]
 +
** [[FPGA_Interrupt_Catcher|Interrupt Catcher]]
 +
** [[FPGA_Registers|Registers]]
  
=== (111) Transmit "D" ===
+
* [[Ethernet_packets|Ethernet Packet formatting]]

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