The purpose of this component is allow students to take their instantiated design for the Nexys video and debug them.
Despite extensive workbench testing, it is difficult to write test suites that check for every possible scenario. In fact, this is a widely researched subject in the areas of computer science, software engineering, and cybersecurity. As a result, despite best efforts it can be significantly challenging to determine the cause of unexpected malfunction with an synthesized design. This project makes it possible for a user to instantiate a simple component which allows for desired data values to be sent from a running design to the user's computer, where the data can be examined using Wireshark.
The project extends hamsternz's basic ethernet packet transmission and is built on his original reduced gigabit media-independent interface implementation. The design debugger is one modular component, defined in gigabyte_test, and can easily be imported into other projects provided the naming conventions in the constraint file are either directly used or followed in the signals mapped onto the instantiated component. There are two reasons hamsternz's project was used as the base. First, as can be seen in rgmii_tx and rgmii_rx, it makes very clean usage of the Artix 7's input and output DDR pipelining to meet the timing constraints for gigabit ethernet. Secondly, though not perfect, it has extensive logic for transmission speed negotiation, eliminating several potential sources for Layer2 errors. In practice, it was found to be highly reliable.
The main modification this work makes is the addition of a controllable data input into the component. The size of this input is controllable as a generic to eliminate the need for zero padding. The component also uses pkt_sent_n as an output so that external processes can be synchronized with the state of data transmission inside the interface. The component makes use of 5 smaller components, three major and two minor. Rgmii_tx/rx handle the board level signal mapping onto the pin lines for transmitting and receiving (mostly clock synchronization logic) respectively and were not modified. Rx does minimal data handling. Addcrc_32 and add_preable externalize the cyclic redundancy check and frame delimiter.
The key modification to the design is found in the last major component, byte_data. This is where all layer 3 data is set and handled. The packets generated by this logic are extremely simple to reduce the likelihood of filtering or errors. The length of the packet is fixed for the same reasons. The core logic dictacting the byte to be sent to the RGMII is handled by a case statement. One of the major modifications to the project was to rebake this case statement using hexidecimal integers. VHDL case statements will not allow ranges with vector types, so while they are more familiar and easier to read, this change improves the project's long term function.
The key contribution of this project was the logic activated when data_user is high. By giving the case statement an input type which does accept ranges, matching over a hundred bytes is done in a single case. The core challenge is synchronizing which byte of the data packet is being fed into the interface. This is done by adding a corresponding index value to the current counter value just before the case statement. The p_index then bitslices the correct byte from the payload as the counter increments.
All inputs and outputs to the main component can be directly mapped to their respective pins (ethernet has ~11 pins alone), excepting two which are used by the user: payload and pkt_sent_n. Furthermore, payload makes use of the generic N which must be portmapped when instantiating the component. Payload is the data payload of the packet to be sent and is N bits. The maximum size of this payload is 1024 bits and can be comprised of any arbitrary binary data as formatted by the user. Thus, the signal or value mapped to payload in the port map must be a standard logic vector with bits N-1 down to 0. Finally, the pkt_sent_n can be thought of as a reset low line for queued data to be transmitted. This line goes low after a packet with a data payload has been sent out, informing the system that the ethernet transmitter is ready for the next packets data payload and otherwise remains high when the line is currently transmitting.
The largest issue with this system is that the ordering of the packets cannot be used to recreate the original data. The connection is UDP, so any packets dropped for whatever reason are not retransmitted. As a result, if you choose to use this system to check values which may change during the operation of the design, it is highly recommended that some form is time stamping or further context (like the current value for whatever signal/input causes the changes) is included with the data. Another simpler approach is creating logic which checks for a particular value associated with a desired state and only outputting that value down the data line. If the value appears in a packet, you know that part of the logic is working correctly.
All packets originate from 192.168.1.64 destined for the broadcast address (255.255.255.255) over port 4069, as set in byte_data.vhd.