Changes

=== Transmitting ===

=== Transmitting ===

To the right is a diagram depicting the structure of an Ethernet packet.  On the left side is marked the blocks that must be defined by the FPGA to be passed to the CP2200/1.  The first 8 bytes ("Preamble and Start Frame Delimiter") and last 4 bytes ("CRC") will be generated by the CP2200/1, so the FPGA need not even be aware of them.  The first significant block is the 6-byte destination MAC address.  The FPGA will have to store this to know the address of its conversation partnet. The next block is the 6-byte source MAC address.  Each CP2200/1 comes with a factory-set unique MAC address stored in the last page of Flash memory that will be used as the source MAC address.  This address must be retrieved at start-up, inserted in the MAC interface of the CP2200/1 as well as stored by the FPGA for packet addressing. The next block is the 2-byte length block.  This is the number of bytes of data, i.e. everything between the length block and the CRC.  Then finally comes the data block, which must be padded to a minimum of 46 bytes but cannot exceed 1,500 bytes. In practice, out packets are padded to 47 bytes of payload: ''the letter'' of the CP2200/1 manual seems to indicate although this is likely a mistake. (Their likely error reduces to the fact that N-member array with first index 0 ends with index N-1, not N.)

To the right is a diagram depicting the structure of an Ethernet packet.  On the left side is marked the blocks that must be defined by the FPGA to be passed to the CP2200/1.  The first 8 bytes ("Preamble and Start Frame Delimiter") and last 4 bytes ("CRC") will be generated by the CP2200/1, so the FPGA need not even be aware of them.  The first significant block is the 6-byte destination MAC address.  The FPGA will have to store this to know the address of its conversation partnet. The next block is the 6-byte source MAC address.  Each CP2200/1 comes with a factory-set unique MAC address stored in the last page of Flash memory that will be used as the source MAC address.  This address must be retrieved at start-up, inserted in the MAC interface of the CP2200/1 as well as stored by the FPGA for packet addressing. The next block is the 2-byte length block.  This is the number of bytes of data, i.e. everything between the length block and the CRC.  Then finally comes the data block, which must be padded to a minimum of 46 bytes but cannot exceed 1,500 bytes. In practice, out packets are padded to 47 bytes of payload: ''the letter'' of the CP2200/1 manual seems to indicate although this is likely a mistake. (Their likely error reduces to the fact that an N-member array with first index 0 ends with index N-1, not N.)

The identifying (second) byte of this packet's payload is ASCII '''P''': 0x50, 0101 0000.  The next four bytes form a programming mask.  Any channel that is to be reprogrammed will have a 1 in the corresponding location, and any channel that is to be left alone will have a 0 in the corresponding location.  The MSB of the first byte refers to channel 0 and the LSB of the fourth byte will be channel 31.  Thus, if only channels 5 through 17 are to be programmed, the packet would contain:

The identifying (second) byte of this packet's payload is ASCII '''P''': 0x50, 0101 0000.  The next four bytes form a programming mask.  Any channel that is to be reprogrammed will have a 1 in the corresponding location, and any channel that is to be left alone will have a 0 in the corresponding location.  The MSB of the first byte refers to channel 0 and the LSB of the fourth byte will be channel 31.  Thus, if only channels 5 through 17 are to be programmed, the packet would contain:

[[Image:P-packetPayload.png|thumb|399px|P-type packet format]]

[[Image:P-packetPayload.png|thumb|348px|P-type packet format]]

{| align="center" cellpadding="4" border="0" cellspacing="0" style="text-align:left"

{| align="center" cellpadding="4" border="0" cellspacing="0" style="text-align:left"

! First data byte

! First data byte

| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0

| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0

|}

|}

Following this are 64 bytes of programming data listing the values for channels 0-31 (in that order) in 2-byte words. Each channel needs 14 bits, so the format is two leading zeros and 6 MSB of data is the first byte, then 8 LSB of data in the second byte.  Place holders for all channels must be present in the packet, but only those marked in the mask will be programmed; all other bytes will be ignored and can take on any value.  Regardless of the mask, the word corresponding to the ''last channel must be followed but another byte as padding.''

Following this are 64 bytes of programming data listing the values for channels 0-31 (in that order) in 2-byte words. Each channel needs 14 bits, so the format is two leading zeros and 6 MSB of data is the first byte, then 8 LSB of data in the second byte.  Place holders for all channels must be present in the packet, but only those marked in the mask will be programmed; all other bytes will be ignored and can take on any value.  Regardless of the mask, the word corresponding to the ''last channel must be followed but another byte as padding.'' The packet format is shown in detail in the adjacent figure.

=== "S" packet: status report ===

=== "S" packet: status report ===

This is the packet sent from the FPGA to the PC to report on the current status of the board.  The first two bytes of the packet will be the usual Location-stamp byte and the packet identifier: an ASCII '''S''': 0x53, 0101 0011.  After that will come the status data.

This is the packet sent from the control board to the PC to report on the current status of the board.  The first two bytes of the packet will be the usual Location Stamp byte and the packet identifier: an ASCII '''S''': 0x53, 0101 0011.  After that will come the status data.

* The first two bytes of data will be the temperature. The temperature sensor returns 10 bits of data.  The first byte will contain six leading zeros, then the two MSB of data.  The second byte will contain the 8 LSB of data.

* The first two bytes of data will be the temperature. The temperature sensor returns 10 bits of data.  The first byte will contain six leading zeros, then the two MSB of data.  The second byte will contain the 8 LSB of data.

* The next 16 bytes of data will be the ADC channels.  The ADC returns 8 channels of 12 bits each.  The first byte for each channel will have four leading zeros, then the 4 MSB of the data.  The second byte for each channel will contain the 8 LSB of the data.  The channels will be reported from channel zero to channel seven.

* The next 16 bytes of data will be the ADC channels.  The 12-bit values returned by the ADC are padded into 2-byte words.  The first byte for each channel will have four leading zeros, then the 4 MSB of the data.  The second byte for each channel will contain the 8 LSB of the data.  The channels will be ''reported from channel seven down to channel zero''.

This totals 20 bytes: one for Location, one for Packet Type, two of temperature, sixteen of voltages.

This totals 20 bytes: one for Location, one for Packet Type, two of temperature, sixteen of voltages. In an effort to pad the packet to the minimum size required by Ethernet standards, the temperature and ADC data values in the S-packet may be repeated again in the same sequence.

=== "D" packet: DAC setup complete ===

=== "D" packet: DAC setup complete ===

This is the packet sent from the FPGA to the PC to confirm that the DAC has been programmed to specifications.  The first byte of this packet is an ASCII '''D''': 0x44, 0100 0100.  The next 64 bytes are the values of the DAC channels.  As before, the format is two leading zeros and 6 MSB of data in the first byte and 8 LSB of data in the second byte. The channel values are listed from 0 to 31. This confirms to the PC that the data was programmed according to specification and helps synchronize the control board and the PC.  All channels are reported back, not just those that were reprogrammed during this conversation. Note that the DAC chip has no interface for querying the state of particular channels. The values reported are the nominal programmed values simply confirming that the correct values were received. If there remain free ADC channels, they can perhaps be wired to sample some DAC lines in order to have some real confirmation.

This is the packet sent from the FPGA to the PC to confirm that the DAC has been programmed to specifications.  The first byte of this packet is an ASCII '''D''': 0x44, 0100 0100.  The next 64 bytes are the values of the DAC channels printed in 2-byte words.  As before, the format is two leading zeros and 6 MSB of data in the first byte and 8 LSB of data in the second byte. The channel values are listed from 0 to 31. This confirms to the PC that the data was programmed according to specification and helps synchronize the control board and the PC.  All channels are reported back, not just those that were reprogrammed during this conversation. Thus PC software needing to rebuild its records of voltage values can issue a program (P) packet with the mask bits set to zero to read back the SiPM bias voltages from the control board.

 

Note that the DAC chip has a write-only interface: state of particular channels cannot be queried. The returned voltages are those stored by the FPGA for programming. The values reported are the nominal programmed values simply confirming that the correct values were received. However, the returned values do reflect the corrections made by the FPGA in the values that would have exceeded the voltage limits.

 

For real feedback, the "DAC health channel" may be used instead. The current control board hardware design specifies that DAC channel 31 be used as a DAC-health monitoring level. The line is connected with ADC channel 7. Assignment and reading back of values on this channel will be of great help in calibrating the DAC chip.

 

Channel ?? also has a special allocation: it control the gain switch on the amplifier board.