Ethernet packets
This page deals with material under development. Please be aware that the information here may change as development proceeds.
This page details the packets we will send across our internal Ethernet to define the standards of communication between the digital boards and the controlling PC. Both the FPGA designer and the PC software programmer will need to make reference to this page in order to coordinate their respective designs.
Open questions
- How will the FPGA obtain the MAC address of the PC? Can the cards broadcast, but filter out all packets not directly addressed to them? How would PC get board MAC addresses then? Print on PCB?
Structure of a packet
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 (internally or using the RAM supplied by the CP2200/1) and then insert it into the appropriate place. 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. The next block is the 2-byte length block. This is the number of bytes of data, which can be as small as 46 or as large as 1,500. Then finally comes the data block, which must be padded to a minimum of 46 bytes but can not exceed 1,500 bytes.
Receiving
The CP2200/1 appears to give access to the entire 64-byte (minimum) packet, which would include everything on the above diagram except for the "Preamble and Start Frame Delimiter". The CP2200/2 can be programmed to filter out any packets not addressed to it. However, it only verifies the first 5 bytes of the MAC address. Checking the 6th byte and using the skip procedure is left to the FPGA. For good packets the FPGA can strip away and ignore the first 14 bytes (it does not need the length field, as we define our own standard for the packets below, using the first data byte to specify the type of packet). From there the FPGA can parse the data field according to the below specifications.
Our packets
We will use six types of packets in our communications, paired into three "conversations" or "cycles": a reset cycle, a query cycle, a programming cycle. Each packet's data section will begin with a single-byte code to identify the packet type. As a mnemonic, these bytes will use ASCII codes to represent a single-letter shorthand for each packet.
The reset cycle
The reset cycle is a conversation whose purpose is to reset the digital control board. On each power-on, the various chips on the digital board need to be re-initialized. This includes the Ethernet chip itself, so the reset functionality needs to be built into the FPGA logic by default and needs to execute on start-up with no external stimulus in order to obtain Ethernet control. However it may also be necessary to instigate a reset externally for some reason. This cycle allows the external PC to initiate a reset and will notify the PC when the system is fully initialized.
"R" packet: reset
This is the packet sent from the PC to the card to initiate a reset process. Two possible reset packet ideas can be considered:
- Full reset: This resets all chips on the board (except for the FPGA; that should reset only during a power-up) together. This will contain no data.
- Selective reset: This will have flags to reset the Ethernet chip, the ADC, the temperature sensor, and the DAC. Combinations of flags allow a selective reset of any combination of the four chips. This will contain four flags which can be packaged into a single byte.
The first data byte will be an ASCII R: 0x52, 0101 0010. For a full-reset-only design, all remaining bytes in the packet will be padding that the FPGA can ignore. For a selective-reset design, the second data byte will contain the four flags, and all bytes after that will be padding. A selective-reset design allows a form of "Are you awake" query to the board: Send a reset packet with all reset flags turned off; the system will not reset any devices but will still respond with an "I" packet. This may be an unnecessary feature, as the query cycle already acts as a more complex "Are you awake" query.
"I" packet: initialization complete
This is the acknowledgment packet sent from the FPGA to the PC to state that the reset cycle has been completed and the digital board is ready to resume regular operations. At this point all settings on the digital board have returned to their defaults (likely to mean all DAC channels set to zero). There is no data associated with this packet, so the only significant byte is the first byte, an ASCII I: 0x49, 0100 1001.
The query cycle
The query cycle is a conversation regarding the status of the digital board. It polls the sensor devices and reports back their most recent data.
"Q" packet: query
This is the packet sent from the PC to the FPGA to request a status report. This could be made selective (status of ADC only, status of temperature sensor only, or full status report). However, as the size of an Ethernet packet is so large compared to the amount of data being requested, all data will be sent and the PC can use the data as it desires. Thus there is no data attached to a query packet. The first byte is an ASCII Q: 0x51, 0101 0001.
"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 byte of the packet will be 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. An alternate scheme would be to convert the 10-bit two's-complement data into 16-bit two's-complement data and return that in two bytes.
- 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. An alternate scheme would be to convert the 12-bit two's-complement data into 16-bit two's-complement data and return that in two bytes each.
This totals 19 bytes: one of ASCII, two of temperature, sixteen of voltages.
The programming cycle
The programming cycle is a conversation intended to set the values of the DAC channels. It sends programming data to the board and receives confirmation of the programming.
"P" packet: programming
This is the packet sent from the PC to the FPGA to set new values to the DAC channels. The first byte of the packet will be an ASCII P: 0x50, 0101 0000. The next four bytes (if all 32 channels are used; 3 if 24 channels, 2 bytes if 16 channels) together 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 will be channel 31 (or 23 or 15) and the LSB of the fourth (or third or second) byte will be channel 0. Thus, if all 32 channels are to be used, but only channels 14 through 26 are to be programmed, the packet would contain:
| First data byte | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 |
|---|---|---|---|---|---|---|---|---|
| Second data byte | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| Third data byte | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
| Fourth data byte | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Following this are 64 (or 48 or 32) bytes of programming data. The first two bytes are for channel 31 (or 23 or 15) and the last two bytes are for channel 0. Each channel has 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. All channels are 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. The total size of the data in a programming packet is:
| Number of channels | Data Bytes per Packet | |
|---|---|---|
| 32 | 69 | |
| 24 | 52 | |
| 16 | 35* |
Since the minimum number of data bytes in a packet is 46, the packet may need to be padded if only 16 channels are to be used. Alternately the mask can be eliminated, forcing all channels of the DAC to be reprogrammed every programming cycle; however, having a mask allows a query of all DAC channels: set the mask to all zeros to reprogram nothing and the response will report back channel values according to the FPGA.
"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 (or 48 or 32) bytes are the values of each DAC channel. 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, channel 31 (or 23 or 15) first, channel 0 last. 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. This will require that the FPGA (or the RAM in the Ethernet chip) store the values of the DAC channels, as the DAC has no interface to report back the value of a given channel. The size of this packet will be 4 (or 3 or 2) bytes less than for the corresponding programming packet, to account for the programming mask.