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