We have designed a product that has SFP gages, everything works with optical SFPs. With copper SFPs we get no link. Is there anything that we need to write to the SFP registers to make copper SFP work? They should be in SGMII mode and we talk SGMII to them. So it looks like it should work, but it doesn't, checked out several different copper SFP modules. The SFP is connected to Xilinx FPGA and we do not access the i2c interface at all.
Related
I am testing a custom FPGA NIC and I need to send management information (such as header info for matching) and traffic data to it using a traffic generator from within the user space.
The driver built for the FPGA is a modified version of IXGBE with DMA support for management, and also supports DPDK for kernel bypass to achieve high throughput.
I am trying to understand how the various software (driver, userspace application, etc) should be stacked/connected to each-other so I can achieve the objective of reading and writing to PCIe on the NIC using set of scripts from user space?
I have also been looking at this project
https://github.com/CospanDesign/python-pci
which is useful however based on Xilinx XDMA.
Would appreciate any help, pointers on this.
Sorry, the question is too broad. For such a broad question there is a generic answer: have a look at Inter Process Communication:
https://en.wikipedia.org/wiki/Inter-process_communication
There are variety of methods, like Unix sockets, shared memory, netlink etc, to communicate between user space processes. As well as a variety of methods to communicate between user space and kernel space.
Just pick the best for you and try to do something. If it fails, come again on SO and ask ;)
I was wondering that how can all different network devices have different MAC ID's.
is it hardcoded separately for each device ? (extremely unlikely..since in production nobody would like to change the code and recompile and load the program...)
or
a switch is used to set the address
or
is it loaded from the ROM ?
or something else ..
Many networking interfaces use EEPROMs that come pre-programmed with EUI-48 or EUI-64. They use EEPROMs to store configuration settings and other data anyway, so they don't have any additional cost using the pre-programmed EEPROMs other than the chips ending up slightly more expensive per 1k. Programming each device with a unique ID would however incur additional cost.
For instance, 24AA02xE is an I²C SEEPROM with pre-programmed EUI-48/EUI-64 at standard addresses. 93AA46AE48 is an SPI SEEPROM with pre-programmed EUI-48 that's directly compatible with LAN9xxx Ethernet Controllers.
I'm not affiliated with Microchip. I used their chips in a hobby project and noticed the datasheet mentioning the EUI-48 features.
I have a project that I need to control my Irobot creative using microblaze and Pmodacl or Pmodjstck from digilent.
I already set up my peripheral to be SPI interface (I also understand SPI working); however, I dont know how to communicate with the pmodacl?
I have searched all over the net and I dont see any example how to do it. I would be a great help if you give me some example.
WHat I only need is to be able to read/write to the slave registers of my custom IP and be able send a software reset and give clock to my custom IP module. What can I exclude from the bus signals so to be able to insert more ports for my custom IP, in overcoming the limitation of the IOBs.
Honestly, you can't leave out anything. There's a very good reason it's called a bus standard.
Write you logic in Verilog or VHDL and then just use the EDK import peripheral tool and you're done.
Make your peripheral as simple as you want/need it. The tool will properly wrap it in the bus logic and provide the necessary files for the /data directory of your pcore.
All the seeminly "extra" connections really don't cost you any chip-area or performance. But leave the wrong thing out and you'll spend weeks trying to sort out the mess.
few days ago I asked here about implementing USB. Now, If I may, would like to ask few more questions, about thing I dind´t quite understood.
So, first, If I am right, Windows has device driver for USB interface, for the physical device that sends and receives communication. But what this driver offers to system (user)? I mean, USB protocol is made so its devices are adressed. So you first adress device than send message to it.
But how sophisticted is the device controller (HW) and its driver? Is it so sophisticated that it is a chip you just send device adress and data, and it writes the outcomming data out and incomming data to some internal register to be read, or thru DMA directly to memory?
Or, how its drivers (SW) really work? Does its driver has some advanced functions like send _data to _device? Becouse I somewhat internally hope there is a way to directly send some data thru USB, maybe by calling USB drivers itself? Is there any good article, tutorial you know about to really explain how all this logic works? Thanks.
The USB protocol stack has several layers and is quite complex. You really need to read a good book on USB (e.g. USB Complete) to get an understanding of how it all fits together. The bottom line though is that you want to go as high up the protocol stack as you can, ideally using a system level API (e.g. if it's a USB HID device then just treat it like any other HID device, rather than thinking if it as a USB device - ditto for mass storage devices, etc).