Open sly74fr opened 4 years ago
Hi Sly: sorry it's taken to long to reply to this. Can you outline a use case for what you suggest? What would be the performance requirements? People are doing similar things to debug their firmware, but typically using a VHDL simulator (modelsim, etc) rather than software.
No problem ! And thank you first for taking the time to look at my request 😁
My use-case is as follow: I am developing a software stack for CERN ATLAS to control a cluster of IPbus-driven FPGA boards. I would really appreciate being able to have some stub-like software to ease continuous integration of my tests against virtual IPbus hardware. It is clear enough ? Otherwise I will detail some more if you want ?
Performance-wise no hard show-stopper for me by the way...
Best regards, Sly
Hi Sly. Can you comment further on your original proposal? I can see how we could provide a registration / callback mechanism for user-written slave emulators to receive ipbus transactions. It's harder to see how that can be automatically done from the address table, as the behaviour of slaves is not really well defined there. Not everything is a register or a ram, right?
Dear Dave,
On my side everything is either a register or a ram indeed. And I do not forsee an easy way to define the stub behaviour from the address table, apart from hypothetic simple, static, default values. I think the dynamic behaviour should be of the entire responsability of the stub code. This would already represents a big step forward from my point of view.
Did I respond to your interrogations ? Sly
Right, I think we agree. So the address table decoding could happen on the framework side, but everything else is up to the user. Note that in hardware world, slaves do not know their base address, and probably that should also be true in an emulation world.
Tom and I are thinking about how this could be implemented easily, and what language bindings might the most useful. Do you have any time to help in implementation?
I would really enjoy getting my hands on but cannot make any promesses as my schedule is already awful ! What timeline is on your mind ?
Hm, when do you want it? 8-)
Prof David Newbold | Director Particle Physics Department STFC Rutherford Appleton Laboratory, Harwell Campus, Didcot OX11 0QX United Kingdom Tel | Office: +44 (0) 1235 446760 https://ukri.zoom.us/my/dave.newbold Email | dave.newbold@stfc.ac.ukmailto:dave.newbold@stfc.ac.uk http://www.stfc.ukri.orghttp://www.stfc.ukri.org/
From: Sylvain LAFRASSE notifications@github.com Reply-To: ipbus/ipbus-software reply@reply.github.com Date: Monday, 25 May 2020 at 08:14 To: ipbus/ipbus-software ipbus-software@noreply.github.com Cc: "Newbold, Dave (STFC,RAL,PPD)" dave.newbold@stfc.ac.uk, Comment comment@noreply.github.com Subject: Re: [ipbus/ipbus-software] Feature Request: SmartDummyHardware ? (#169)
I would really enjoy getting my hands on but cannot make any promesses as my schedule is already awful ! What timeline is on your mind ?
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/ipbus/ipbus-software/issues/169#issuecomment-633418160, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBRUSHYVLLTP5LJSF52MGDRTILGDANCNFSM4J2BVLGA.
This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.
No pressure here as I am not able myself to contribute effectivly...
Dear IPbus team,
Back to the topic following issue #149...
My use-case of such a 'SmartDummyHardware' class is:
Once again thank you very much for all your great work on IPbus. I would also happily contribute to this enhancement...
Best regards, Sly