f00fc0d3

Ceva DSP is almost same story about compiler. They used to have GCC2.95 glued to their proprietary backend, 33% of compilations results in crash :-). They got better by going to GCC4.4, but still use crazy licensing. But other DSP cores are often even worse offering as little as only assembler.

But, DSP core itself is nice, very well thought out in contrary to mainstream DSPs from TI or Freescale(now NXP).

You clearly have no idea what you are talking about. I am doing baseband SW in tier1 vendor, and we have no processes, crappy tools (maybe you consider git and clang a crappy tool?) and don't give a flying f##k about management.

...and this is funny that you consider advanced signal processing, numerical analysis, SoC architecture, discrete optimization a CS 101 - what a joke.

>That's just to the base station, no? How does that in any way apply to what you transmit over your network? We are talking about ENB here, core LTE network is already virtualized.

>Because your comment about latency implied that. Goal with ENB virtualization is to have single or few server farms per city, unlike today where ENBs are spread all over the city, and such usecase is still problematic with latencies - been there, done that.

Yep, AVX is nice, but still it is far from current DSP chips. I ported a subset of PHY to real AVX2 CPU and AVX512 sim. It is (sometimes) comparable to c6x (which is a crap DSP) if you take (much) higher clock into account, but comparing to current DSP IP cores it is a joke.

Future standards will be even more tight, 5G working assumption is 1 ms HARQ loop.

Where you got the idea that I assume the ENB has to be on other side of the world ?

I have seen such projects - real LTE PHY algorithms are much more complex than stuff in 3GPP. You can write something 3GPP compliant in some simplified cases, but it would be totally useless in real network.

Secondly you don't really want to use FPGA for majority DSP processing in LTE PHY. Design cycles on FPGA are too slow and HLS techniques are still not trusted. Beside that x86+fpga are some kind of specialized stuff - you could just put a PCIe accelerator with some major wireless SoC.

HARQ loop in LTE is tight = 3 ms(3ms for ENB, 3ms for UE, 2 ms for air/RRH = 8 ms in total). It means that in those 3 ms you need to decode ack nacks in PHY, run scheduling and then send the data on other side of PHY.

LTE PHY requires a lot of algorithms that doesn't fit well on x86 or general purpose HW like FFT or turbo decoding. Those usually are done in HW accelerators of baseband SOCs. x86 lacks also complex arithmetic ISA, where wireless DSP do many complex multiplies in on cycle and complex ops are ~80% of signal processing done on DSP (not accelerators).

Second things is energy consumption, take e.g. Ceva XC4500 DSP core and a equivalent Xeon - it is magnitudes more efficient. In case of FFT or turbo it gets even worse.

Lastly, IQ data streams requires a lot of bandwidth ~1Gbps per one carrier in case of 20MHz. FDD LTE uses mostly 2 or 4 antennas in each direction, where TDD is good with 8 antennas, and this just one cell(sector). Newest ENB can handle up to 96 cells (with 2 antennas) in one box.

In theory you could run non-PHY layers of uplane in a server and use ENB as a L1 server, but still the lower MAC and scheduler needs tight latencies so server with DPDK is a must, but ARM/PowerPC/MIPS parts of the basebands SoCs are left idle (not really useful for PHY). PDCP layer seems reasonable to run in SDN because of carrier aggregation and not so tight latency requirements, but this layer is very simple.

Of course you can run whole control plane in a cloud, which actually makes sense but this is not a great achievement ;-)

This is totally wishful thinking. No one in industry has a slightest idea what 5G will be. We keep throwing fancy terms like eNodeB virtualization and then we have a reality check - LTE userplane cannot be virtualized due latency and performance reasons (LTE PHY on x86 - yeah, right...).

Same goes to those mm waves with beamforming - no DSP (IP core) can handle it now and even soon. You need to stick with very expensive FPGAs. Besides that there is WiGig coming and you can offload traffic from LTE to Wifi - investing in those mm wave small cells seems rather pointless.

Beside that you can get those multi-Gbps with new Rel13 LTE carrier aggregation (up 32 CC).

It is exactly the same what is happening to Nokia Networks. What saves them is fact that mobile networks market is pretty much closed and there is very high barrier of entry. If the market would be more open (patents!) - Nokia wouldn't survive a day there.

Nokia top management have no clue about technology, they are not engineers so you can sell them any s##t you what if you have smooth talk.

Nokia suffers also from politics and internal battles between sites and organizations (basically Finns vs everybody else). This results in ubiquitous NIH syndrome. Nokia Net reinvents wheel all the time, and almost every time they get a square.

c6x has 8-bit bytes.

Yeah, but you still need to write those maxi, maxd :-(

Template metaprograming is nonsense, not simple type substitution. C++ templates are just too much, especially when mixed with substandard developers.

Typeof is not standard and many DSP compilers do not implement that. Secondly I meant max search in array, not between to scalar values which is trivial. I really don't want to have for(...) inlined everywhere.

C99 is nice, but C still lacks generic. I am not talking about C++ template nonsense, but not having to write max element search for every primitive type.

I am working in DSP project which was started with typical C++ OO BS, finally with ended up with C compiled as C++ + some simple templates for cases as above.

Beginning of the end of Nokia Networks. Looks like they dont have any clue what to do. ALU enodeb is crap, Nokia ancient Flexi is crap and their new stuff will be crap if they will manage to sell this to somebody :-)