Hi Troy, If there are ways that we can help you with your own parallel thread on the FMC150; please let us know.
We have a lot on our platform maturity and diversity plate (and it seems more every day). But if you get hung up for more than a day on something that seems simple; and it's a nut you suspect we may have already cracked, please get in touch directly and we can talk, email, skype, etc as needed to help. For example, we spent a few days specializing an SPI code just for the format of CDCE72010 on the FMC150. This is normally a one hour affair - but we were working off an old, defective, TI datasheet. If we can help you avoid similar pitfalls, that would make us feel good, as well as save you some cycles. -Shep The BSV looks very "Verilog-like" in this case, on purpose: https://github.com/ShepardSiegel/ocpi/blob/master/bsv/prm/SPICore32.bsv As Jim mentioned, best to use the real OpenCPI repo and then escalate to push our upstream sandboxes to mainline. On Wed, May 2, 2012 at 8:04 AM, James Kulp <[email protected]> wrote: > 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<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<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
