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> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)

Regards,

Madhu