-
Notifications
You must be signed in to change notification settings - Fork 710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defining the ethernet frame in verilog testbench #220
Comments
Hi casager. The examples are typically realizing a echo back. Therefore your device should send a UDP packet to the board and the board will receive the echo packet and replies it back with the very same payload. Your device should therefore know the IP address of the board (which is the one configured in one of the line you provided). Btw, the ARP query is sent over Ethernet and not over UDP/IP. What's the purpose of your TB? |
@gabriserra , thank you so much for the response! The echo back clears a lot of confusion that I had. Understanding where the ARP query is coming from is also very helpful. I am attempting to create a testbench in SystemVerilog in order to replicate a lot of the functions that are being used within cocotb. Building this for a Digital Logic Design lab and it would be preferred not to use cocotb at this point. Rather than have an echo response, however, I would like to transmit an original payload from the board to a mobile device or some device that is on the network via email. In order to do this, I have been trying to find the point in which the tx payload is returning the data, and replace this echoed data with original data. Have also been attempting to mess with the MAC control modules in order to be able to create a custom payload that is sent from board, but have not successfully been able to create a signal that reaches the phy_tx point of transmission. I understand there is some intermediate steps of header processing and such, so I have been trying to figure this out as well. Again, I very much appreciate your help! |
What does it mean via email? And what should be the data trigger event? Consider that, if you want to send a packet from the board to the device, there should be a trigger event i.e., a user button. You should write your own logic which senses the button and drives the various wires in |
@gabriserra Sorry the email part was misleading and isn't really important at this point. That makes sense with the trigger point and how I would need to drive the wires in fpga_core.v using such trigger. My issue still is where to exactly assign these constant values. At what point in the fpga_core.v process (in which verilog module) does the source and destination MAC need to be assigned to constant value, for example, so that it can eventually be encoded and output as phy_txd data? Additionally, will the MAC, IP, header info and such need to be included in the payload that is being controlled by the state machine? Again, appreciate all of your help. |
Hello, I am attempting to write a testbench in verilog for the Arty A7 in order to send a simple message from the board to a mobile device, but am having trouble translating how the ethernet frame variables for the cocotb testbench are defined and used. Since the inputs to fpga_core.v are sent to the phy, what would be the best way to define a destination address and send some data to this address? Similar to how these are defined in test_fpga_core.py:
I understand that some configuration values are set in fpga_core.v:
// Configuration
wire [47:0] local_mac = 48'h02_00_00_00_00_00;
wire [31:0] local_ip = {8'd192, 8'd168, 8'd1, 8'd128};
wire [31:0] gateway_ip = {8'd192, 8'd168, 8'd1, 8'd1};
wire [31:0] subnet_mask = {8'd255, 8'd255, 8'd255, 8'd0};
However, how is the destination known by the device? I am assuming it has to do with the ARP query that is sent via UDP but would highly appreciate some clarification on the idea.
I also checked the Alveo example that has a verilog testbench (test_fpga_core.v), but that did not help much with the confusion.
Thank you!
The text was updated successfully, but these errors were encountered: