Skip to content
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

Open
casager opened this issue Aug 21, 2024 · 4 comments
Open

Defining the ethernet frame in verilog testbench #220

casager opened this issue Aug 21, 2024 · 4 comments

Comments

@casager
Copy link

casager commented Aug 21, 2024

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:

payload = bytes([x % 256 for x in range(256)])
eth = Ether(src='5a:51:52:53:54:55', dst='02:00:00:00:00:00')
ip = IP(src='192.168.1.100', dst='192.168.1.128')
udp = UDP(sport=5678, dport=1234)
test_pkt = eth / ip / udp / payload

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!

@gabriserra
Copy link

gabriserra commented Aug 30, 2024

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?

@casager
Copy link
Author

casager commented Aug 30, 2024

@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!

@gabriserra
Copy link

gabriserra commented Sep 2, 2024

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 fpga_core.v. Most of the wires can be assigned to constant values (source ip address and destination, ..). For the payload, on the other hand, you will need some kind of state machine.

@casager
Copy link
Author

casager commented Sep 4, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants