UNCLASSIFIED Hi,
Moving logic down the hierarchy (or up the hierarchy into fpgaTop) so that mkFTop is purely structural (instances wired together) would help me greatly. Hand writing code that may be automated in the future is not an issue for now. As long as I can show that we are capable of making out own devices and platforms I will have proven what I want to. If there is anything I can do to help let me know. Cheers, Troy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of James Kulp Sent: Wednesday, 2 May 2012 9:34 PM To: [email protected] Subject: Re: [opencpi_dev] DIY mkFTop [SEC=UNCLASSIFIED] Hi Troy, Unfortunately, there is at the moment a significant lag between Shep's new HDL work and the main OpenCPI repository. This is mostly due to a batch of platform work on things like FMC150 and USRP N210, that will be integrated when they are done in a month or two. We do not have a commitment for full FMC150 support in the short term, but as you can see we have done some of it already. Will will probably do a partial sync-up sooner than that (in May) in order to bring a few small improvements forward, and probably the ethernet control plane (which will work on the ML605 and N210 at least). For your purpose, if you have to now, working with the current OpenCPI repo is probably best. We definitely have plans for what we call "container automation". That is, auto-generating the layer between the application and the platform, including the optional inclusion of the "device workers" and "interconnect workers". Right now the HDL modularity for this isn't quite right for this purpose. There are a few half-way steps that would make the mkFTop problem easier by moving some logic down the hierarchy. I'll see if we can do that sooner than later, but we are once again on a "sprint" through the (our) summer that won't allow for real container automation to happen until later this year. Interestingly enough we have recently been asked to make the "platform support" process more regular and documented. Probably after the USRP N210 we will be ready to do that. Jim On 5/2/12 12:27 AM, Ziersch, Troy (Contractor) wrote: > UNCLASSIFIED > > Hi, > > I've partially completed a HDL device to add support for the FMC150 to > the ML605 platform. > It's at a point where I'd like to download it to the HW and do some > testing. > > I see Shep has been doing some work on the FMC150 as well but I need > to be able to show that we can produce our own FMC support. > > To test the FMC150 device in HW I'm creating a new HDL platform based > on the existing ML605 one. > > This appears to require me to create two new files based on > mkFTop_ml605.v and fpgaTop_ml605.v. > > Creating a file based on fpgaTop_ml605 is straight forward. > Creating a file based on mkFTop_ml605.v is not trivial without a > BlueSpec compiler. > > Also looking at the BlueSpec in Sheps repository I've noticed that the > RTL in the OpenCPI repo seem quite a bit older. > > So I have some questions: > - Are there any hand written Verilog examples of mkFTop? > - Is there a plan to eventually automate the generation of mkFTop > from an xml description? > - Should we be using RTL from the OpenCPI repo or Shep's repo? > > Any advice on the easiest way to generate my own mkFTop would be > appreciated. > > Thanks, > Troy > > IMPORTANT: This email remains the property of the Department of > Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. > If you have received this email in error, you are requested to contact > the sender and delete the email. > > _______________________________________________ > opencpi_dev mailing list > [email protected] > http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org _______________________________________________ opencpi_dev mailing list [email protected] http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. _______________________________________________ opencpi_dev mailing list [email protected] http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
