Start a new topic

Multiple board support

Does the driver/BSP supplied support controlling multiple boards (ML605 with FMC150 in our case via ethernet) via the same PC?  It seems that it should be possible if we have each board on a different ethernet device to open, however the sipif methods do not allow for anything other than an internal address to be passed in as an argument. Does that mean the device ID/address is hidden behind the driver?

Dear Sir,
That's correct, our reference design does not permit to use several devices. The protocol is low level packet based communication, we are not using TCP/IP as the MAC layer is handled by a state machine in the firmware. The ethernet mac IDs are hardcoded in both the firmware and the software.
I believe it should be possible to connect to Xilinx devboard on two distinct Ethernet peripherals on your machine even if they have the same ethernet ID as in this case it is on two different NDIS interfaces but this is not something we have attempted.
The API is actually process packets as per the ethernet star documentation and the device driver is a Windows NDIS driver.
One of our customers is using two FMCxxx product on the same machine so there must be a way to do it, we have provided ETHAPI source code "AS-IS" to this customer, meaning no support is provided on the API source code itself.
Best Regards,
Best Regards,
Thank you for the quick response. Is the source code for the driver available?
The driver itself, not. But it is pretty much the NDIS reference driver conatined the Windows Driver Kit. But you don't need the device driver, you would only need API source code. Typically you need to digitally sign drivers so they run on 64 bit windows, etc..
After looking into the reference code a bit more, it is pretty obvious the NDIS driver supports the multiple device access. Unfortunately the ethapi.dll 4dsp provides doesn't expose the device id to the read/write commands, which leads me to believe it always talks to the most recently opened device. If you could provide the ethapi code as a reference, then it would be a trivial change to add the device id to the access commands. Otherwise, that leaves me with a couple of unappealing (for me) options that I can see (I'm happy to hear other ideas, since you know the system much better than I do).
(1) open/close the device each time I need to access one of the boards. This is a timing nightmare.
(2) reconstruct the driver based on the state machine in the provided ref design (unless you could provide a document with the low level protocol that sits on top of the ethernet).

Any other ideas (or can you throw some source code or snippets of that have the protocol in it my way ;) [size=78%])?[/size]
Can you confirm if your email address is correct in our system, ie can I send you the ETHAPI source code to this email? You can check the email address in your account settings.
I send you the code, "AS-IS", this means no support is provided around the ETHAPI source code, do you also understand that? The reason about that is because what you are asking for is so outside the scope of technical support.
The driver is simply sending MAC packet over an NDIS interface, ETHAPI is building the packets as per SD040(sip_mac_engine).pdf and sending those packets to the NDIS layer via the NDIS device driver; you are correct, the driver itself should be able to work with several cards.
There might be problems about concurrent access to this driver and/or the API. We have a system to test FMC104 + FMC204 in order to test FMC204. In this case we have two PCI ethernet adapter hardware in the machine, two ML605s and we can communicate with both ML605 without problem, but this makes sense.
As a side note, I am not sure what will happen the moment both FMC cards are outputing samples in the same time, the NDIS driver has only one queue, you will need a way to differentiate between packets, ie packet top-1 is from card 1 and packet top-2 is from card 2, etc.. Implicitly extra software work which might causes missing frames, etc.. My point here is that it will not be as easy as dealing with "two IDs".
Also keep in mind the protocol is not reliable, the purpose of this link is to take/put snapshots to the board at a low speed in a point to point configuration. Anything else is not supposed to work as it wasnt tested that way. Typically there is no packet recovery algo, if you miss one MAC packet, you are screwed, it will not recover. We are not using TCP/IP which would make the protocol able to work over a switch, etc..
Best Regards,

The email in my account settings is correct. I do agree that you are going above and beyond in helping us out and have no problems with the "as is".  We've done some design mods to the reference design, so we aren't really doing a lot of data snapshots or offloading, 99% of it is sending settings to our new design via the mac engine.  So I think the first cut of mods will be rather straight forward, but the tip on not discriminating on data coming into the PC is appreciated. That is something we'd like to eventually work our way towards. Thank you so much for your help.
Hello Again,
I just sent the archive for you, it is a zip archive, it might be blocked by your email firewall, I hope not. If that is the case, send me another email as a gmail or something like that.
Best Regards,
Login or Signup to post a comment