Madhu Macaque Labs
madhu at macaque.in
Sat Apr 16 07:38:19 UTC 2016
On Sat, Apr 16, 2016 at 1:36 AM, Harald Welte <laforge at 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
but to do the AP and other server SoCs since that is the core project. But
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
Fortunately we have a full fledged LTE lab on campus with all the necessary
> 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
HW platform that can be the basis for many commercial implementations. I
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.
> - Harald Welte <laforge at gnumonks.org>
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel