On Sat, Apr 16, 2016 at 1:36 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Madhu,
On Mon, Apr 11, 2016 at 08:50:17PM +0530, Madhu Macaque Labs wrote:
I am the project lead for the SHAKTI open source processor project.
Thanks a lot for introducing yourself, your extremely ambitious project and for reaching out to us. I can hardly grasp the complexity of your enormous task, and I think it would still be extremely challenging if you would only focus on the cellular side of things, ignoring the application processor side.
We have in fact decided to split the work into two projects. I have no option but to do the AP and other server SoCs since that is the core project. But we now have a separate LTE/5G modem effort. Focus will be more on programmability than the lower power core. The turbo encoder/decoder is tricky. But then I have a lot of Mater's students at my disposal !
snapdragon 820 or the Apple A9. the CPU core is pretty much under control but we are exploring the DSP needed for running the lower levels of the 3G/LTE stack.
I am not aware of anyone having done any free software work on the MS/UE side of GPRS, EDGE, UMTS or HSPA, so I think you will have to start from scratch there - not only ergarding the DSP performance/capability requirements, but also regarding the actual implementation.
There seem to be a few openLTE efforts including UE stacks. Looking at those. Fortunately we have a full fledged LTE lab on campus with all the necessary test equipment.
There's the OsmocomBB work that focusses on classic circuit-switched GSM only, and there is srsUE (see below) for LTE. But everything in between is a big gap. You might be able to extend and re-use OsmocomBB Layer3 for UMTS circuit-switched NAS, but that's just a very small fraction of the problem.
Most of the other Osmocom wokr has been focusing on the netwokr side of the protocol stacks, so we have GSM, GPRS and partial EDGE support for all of the network side (PHY to RAN to CN), and we are working on the core-network parts of UMTS/HSPA at this point. But that's of very little use for UE side work, at least on anything beyond message encoding/decoding, some definitions.
Another group does LTE stacks and so we have complete testing equipment available to test for compliance.
I would seriously have a look at the excellent work been done at Software Radio Systems on their srsUE implementation of LTE. They implemented a full LTE UE from PHY via AS to NAS as free software under AGPLv3. They are running all of this on an Intel Core i7 CPU, but I'm sure you could re-implement the performance criticla SDR part of the PHY in your DSP and re-use everything on top.
Have looked at it. Trying to figure out how complete it will be. It is a circular problem. Want to co-design the DSP along with the stack and not dump a DSP on the SW team. My only problem is that our language of choice is Bluespec and not everybody has the toolchain for it. It is a high level HW desgn language (actually a Haskell derivative). Would love to have other enhancing our RTL too. Fortunately the tool is free for open source developers.
FOSS is abut collaboration and not re-inventing the wheel, after all :)
I am basically looking for co-conspirators who can help identify the components I can use from the osmocom stack and figure out what else we need to develop.
I personally would love to be involved, but I am already working what other people would consider two full time jobs and there is absolutely no time left to engage in any additional projects without long-term scheduling and planning, sorry. Maybe there are others in Osmocom who'd have more time and interest.
That is OK. Just spread the work around. The key is to get a completely open LTE HW platform that can be the basis for many commercial implementations. I already have two major phone OEMs signed up for using our modem (when it arrives !).
In any case, it would be great if you could keep us posted in some way about your progress.
Regards, Harald --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)