Sendiing IPv4/UDP packets through RGMII interface

[Zhargal]

Hello, everyone!

I want to send some data from ADC using UDP protocol using ethernet on Genesys 2 board, but I don't see anything on Wireshark. Even though, I tried to sent example packet from here:

https://www.fpga4fun.com/10BASE-T2.html

And even my checksum at the end is calculated properly. I tried 125 MHz at first, then shifted to 25 MHz and still don't know how to handle this. What should I do and how to find my mistake? Even LED on board is blinking and firewall is off in Windows.

[zygot]

As I've mentioned in other posts, neither VHDL nor Verilog were designed with logic synthesis in mind. They were designed as general purpose simulation or modeling languages. Neither of them nor their descendants like System Verilog, are complete logic synthesis languages. There have been libraries added to both that let people describe their logic designs and allow FPGA tool vendors to synthesize implementations from text. But this isn't the complete solution. Programmable logic devices from different families don't function exactly the same way. Vendor tools don't treat certain clocking schemes the same way. A good example of this is DDR. Neither VHDL nor Verilog have a keyword for DDR or SDR. Quartus DDR IP is different than Vivado DDR conceptually. So, an HDL source isn't sufficient to implement all logic designs. That's why all logic vendors require timing and IO constraints. It would be nice if you could put all of this information into your source code. Though, to a limited extent, some vendor do allow some of this design information to be in source code it's a hit or miss proposition. I don't see this changing any time soon. Besides, the physical differences in how programmable logic functionality is implemented between vendors or even families from the same vendor, FPGA companies really don't have much interest in supporting anything that trivializes porting a design for their products to a competitor's products. even if the HDLs drove FPGA device, instead of the other way around, on the lowest level there are a lot of details to support.

My point is that if you treat an HDL like a programming language that creates logic, then you are in for a difficult time when the design hits the hardware. Perhaps simple designs might work out, if you aren't too fussy about what "work" means. When you get to advanced IO features like DDR and LVDS a naive view of what an HDL does quickly becomes inadequate.