官方淘宝店 易迪拓培训 旧站入口
首页 > 无线通信 > 通信技术学习讨论 > nvidia的modem号称纯软的

nvidia的modem号称纯软的

12-30
页面下方,切换到 the modem章节 具体链接 http://www.anandtech.com/show/6787/nvidia-tegra-4-architecture-deep-dive-plus-tegra-4i-phoenix-hands-on/7
这个,你怎么看。为啥高通不这么做。icera果然有金刚钻吗? --
※ FROM: 114.248.230]
※ 来源:·水木社区 http://m.newsmth.net·[FROM: 61.148.243]

我咋没在这篇文章里面看到基带处理?
“纯软”基带还无法解决功耗问题,所以或多或少需要硬件协处理电路支持,高通有自己的方案

看到不够仔细?
里面特意说解决了纯软的功耗问题。

页面下方,切换到 the modem章节
具体链接
http://www.anandtech.com/show/6787/nvidia-tegra-4-architecture-deep-dive-plus-tegra-4i-phoenix-hands-on/7

The reality is that nobody is either fully software defined or burned out to ASIC (hardware), but rather somewhere inbetween. For example, Qualcomm is a combination of software and hardware, though it’s never been entirely clear what functional blocks are ASIC and which other blocks are software, though I’ve been told this isoften a matter of whatever is most advantageous for power and what gets re-used most. That said, Icera’s implementation is the furthest towards being pure software definedof anyone, with the entire digital baseband being just one big platformto run their own software atop. There’s an external transceiver whichdoes downconversion, but after that it’s pure software. The question has always been how Icera could afford to build a power competitive platform with an entirely software designed stack, and the clue lies in their choice of 28 HPM instead of LP or HPL silicon for i500 and 4i. Icera designs to a high performance process, then turns off blocks when they’re not in use, rather than make a larger SoC that’s lower leakage. The result is that NVIDIA claims a 40% smaller die for i500 than MDM9x15.
The entire stack ends up being 1.2 million lines of C and DXP code, with a total size of 7.7 MB compiled. NVIDIA gave a great breakdown of the protocol stack as well.The real name for Icera i500 is ICE9045, and it is paired with a ICE9245 transceiver. ICE9045 is built on 28nm HPM as I mentioned before, and ICE9245 remains 65nm TSMC LP CMOS process which is RF friendly. ICE9045 supports basically all the 3GPP air interfaces, as mentioned in the earlier announcement piece. There’s up to Category 3 LTE on the baseband at launch, with Category 4 in the future.For WCDMA, up to Category 24 (42 Mbps) (dual carrier with 64QAM), andinterestingly enough the same Category 18 16 QAM with 2x2 MIMO (28 Mbps) as earlier implemented in Icera 450, and an optional future upgrade to Category 28 64 QAM with 2x2 MIMO (84 Mbps). Of course there’s also TD-SCDMA, GSM/EDGE, full support for voice including AMR-WB and VoLTE/IMS. In addition to 2x2 MIMO the ICE9045 can also do4x4 MIMO on LTE with a second ICE9245 transceiver.
NVIDIA broke down the ICE9045 functionally, which consists of two large DXP units and one smaller DXP unit which runs the rest of the software and management stack. The two larger DXP units run at up to 1.3 GHz. The Icera instruction set consists of two different fundamentalsets. Icera refers to these as the “C” and “D” side, with C being rather obvious. The C side is unsurprisingly a C-complier targeted version of the 3GPP protocol stack, and manages the higher level functions of the modem above physical interface, andis a scalar machine. In the block diagram, the C side runs on DXP1, the D side runs on the larger beefier DXP0 and DXP2 machines.
The D side is a proprietary assembly language vector instruction set that runs the physical layer of the modem, this is a combination of specific libraries that really make up the magic and give the Icera platformits reconfigurability. NVIDIA gave an excellent breakdown of the data paths inside both sides. It turns out that in an LTE configuration one core does all the inverse FFTs and MIMO matrix math, the second core does rate matching and decoding. The ultimate goal is to have each of the cores processing around the same equal workload, and since it’s software these tasks can be shuffled in-between to get the i500 running each core at the lowest possible frequency and voltage. Each of the cores can also be individually power collapsed.

第一句话就不对,国内公司已经做出来纯软的基带芯片了,目前正在MWC上展出呢

哪个公司?

简约纳SimpLight
http://www10.edacafe.com/nbc/articles/view_article.php?articleid=1164007

看到里面提到的低功耗工艺和门控供电我就笑了——混合方案的公司难道就不采用这些低功耗设计技巧嘛?况且,RTL电路要比DSP处理器更灵活更方便地实现门控时钟和门控供电
BTW,此文都是些定性分析,关键要看同工艺条件下,不同芯片的功耗测试对比

简约啥时候这么强了。
有点不相信。

你咋就注意到简约纳了呢?

这个 ConnX Turbo16MS,a programmable offload accelerator
能用c或者汇编来编程?纯软的话也就没必要单列了啊。

打开一看原来是简约买的啊。
拿了国家的钱,不花白不花。最后还是流到国外公司手里了。

是纯软的 支持哪个速率靠软件版本区分
.107

没有什么太出彩的东西
现在所有的modem都是朝这个方向走
asic里面的大头也是一个支持vector运算的DSP

得看物理层有多少比例是纯软的,调度、资源映射之类的确适合软件,但像cc,mimo这种
一般都有积累,改硬件比现编再优化快很多吧。

如果使用传统硬接线解决方案,则必须举出所有信号处理算法的实例,这些算法用于接收信号并将其解码为单独的硅片区域。 如此一来会造成解决方案成本较高,而且缺乏弹性。 此外,验证这些单独的硬件工作模式费力而困难。 这样会导致打造的解决方案可能无法在所有情况下发挥出最佳性能,因为算法参数会不可避免地牺牲性能。
相比之下,在软件中实施这些复杂算法就不必始终使用同一个接收器架构。 例如,可以让调制解调器使用一系列接收器算法,其中包括先进的接收器以及接收分集,这种做法并不会增加成本和硅片的验证时间。 Adaptive Wireless 解决方案可自动选择最佳的算法组合,从而实现最高系统性能。 该解决方案始终监控频道状况以及其它性能衡量指标,以确定最佳的接收器配置、实现最高性能。
DXP 设计让整个调制解调器的功能 (其中包括物理层、协议堆栈、RTOS、驱动程序以及编解码器) 均能够在单核设备上用软件来实现。 无需硬件加速模块、单独的协议堆栈处理器、双重的紧耦合存储器或者设备上的分布式存储器,即可实现这一点。
他宣称是纯软的
.164

C编程的DSP

全球业界公司里面,有自己DSP内核的也没几个,大部分是采用Ceva的方案

这个所谓的纯软和通用处理器意义上的软件还是不一样的吧
只是某种特殊架构的硬件,并且完全可编程吧

那个就是基于DSP内核
你说的那种也有,Coresoic公司推出过(后来被联发科收购了)

估计其中还是会有一些稍微FEC专用一些的指令吧,比如加比选什么的。

我猜他的意思是说DSP不属于通用处理器范畴,所有称之为纯软有待商榷。
毕竟dsp上跑的一般叫firmware不叫software,呵呵。
不过在BB范畴里,DSP已经算纯软了。一个计算领域,一个BB芯片领域,叫法不同。

明白人 :)

- 与DSP对应的概念应该是嵌入式处理器——那上面也有firmware
- firmware本质上就是software——代码针对具体硬件优化设计,但是不向外开放编程,只提供调用接口
- DSP编程无论在哪个领域,也都算“纯软”

我看到有个框图画了个turbo decoder
这也是我为什么说不必纠结纯软不纯软
FEC应该算asic实现吧
但是你说它是“纯软”也说的过去
因为现在的FEC设计也需要一大坨firmware来配置它

我觉得是不是纯软取决与其中有多少硬件功能单元是专用的。
比如,如果processor里面有一些加比选功能单元只能被加比选指令调用用于加比选运算,那么就不能称之为纯软,因为有专用硬件。
但是如果这些加比选功能单元也能被加法、比较等通用指令调用用于通用功能(复用内部硬件资源),这样的话可以认为processor里面的硬件都是通用的,那么就能算纯软。

如果按照你这个定义的话,简约纳的方案可以算是“纯软”的——那些专用指令会共享硬件电路

那你觉得那个框图里的turbo decoder算不算“纯软”呢?
我觉得不算

从icera 500的硬件架构图来看,所有算法都跑在两个大dxp上,dxp0和dxp2。较小的dxp1跑控制。没有哪个硬件block是turbo decoder.
从软件架构图上来看,包含turbo decoder. 但这个是软件层面的。
根据前面的介绍,fec 和 rate matching跑在一个dxp,其他的mimo和ce之类的跑在另一个dxp。
dxp0和dxp2完全相同,意味着上面的算法可以在两个dxp上互换。
至少从这篇文来说,icera 500是纯软的。

Top