Changes

Jump to navigation Jump to search
463 bytes added ,  19:51, 20 October 2009
no edit summary
Line 1: Line 1: −
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.
+
This page details the packets we will send across our internal network 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.
      Line 8: Line 8:  
=== 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 (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.
+
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 startup, insterted 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.)
       
=== Receiving ===
 
=== 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.
+
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/1 can be programmed to filter out any packets not addressed to it, but it only verifies the first 5 bytes of the MAC address, which is useless, given that out system would likely be equipped with a single batch of controllers, differing only in the last octet of their MAC address. 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 two data bytes to specify intended physical address and packet type.)  From there the FPGA can parse the data field according to the specifications outlined below.
     
1,004

edits

Navigation menu