从大算力到tranpose

最近忙于某个“大算力”芯片的架构设计，虽说运算单元和数据结构基本八九不离十了，却也没有时间完成预定的写作KPI。况且工作上想的多了其它自然想的就少了，整整一个月没有写出什么有价值的文章，甚至连好的选题都没有想到。也许接下来得把做过的Cellular工作list一下，既然没想法就讲讲以前做的工作吧，既轻车熟路又不需要考虑泄密的问题。 个人理解当下主流的大芯片设计，本质上其实都是在特定约束下解决大算力堆叠的问题，在芯片设计的过程中需要认真思考的核心抓手无非是下面五点： 1. 具体的目标到底是什么，是为了突破绝对的性能瓶颈，还是在某个power和area的成本约束下完成更高效的设计？ 2. 算力的提升，必须依赖增加算子的数量和密度。所谓一力降十会，简简单单的100个PE并行计算的算力远大于使用了所谓精妙算法和数据格式的1个PE 3. 需要设计合适的数据结构和系统通路保证算子的数据吞吐效率，且数据结构应该是自然且适合少copy的。 4. 越是面向云的大芯片，越需要保障设计的flexibility。在IoT领域的面向特定场景下实现极致PPA指标的专用加速器设计思路已经无法满足，即使在Cellular都已经不是趋势了，更别提云端芯片了。当下的主流是基于ISA的DSA设计，本质上也是一种类CPU设计，无非是去掉了为了支持图灵完备而加入的大量控制电路，取而代之的是各种面向特定场景的专用PE用于算力加速。结合最近的工作经验，保证性能的前提下做到flexibility是最难的事情。 5. 虽然工艺还在不断进步，但是SRAM密度提升的越来越小，基础单元功耗下降越来越少，先进工艺的晶体管价格越来越贵，传统的scale-up设计思路渐渐的会走到极限。芯片设计一定要考虑scale-out，chiplet是一种思路，更重要的是需要业务/框架/算法考虑如何把计算需求分布在不同芯片之间，同时保障芯片之间的带宽需求又没有那么大，毕竟最先进的NV-Link也只能提供900GB/s的片间带宽。 想明白了这些，其实大体上也就想明白了芯片该怎么做了。虽说芯片设计本身是不折不扣的水桶原理，但是一般而言还是有难有易的，比方ALU设计一般是容易的，但是指令和操作调度就难多了。最近这段时间，也算是演示了一遍从易到难的边学边想边做。可惜万万没想到，最近卡在了又快又省又flexible的HW实现transpose上。虽说认知到芯片设计是一场trade off已经很久了，但是干活的时候依然不自觉的既要…又要…还要… 随便说说对transpose的需求： 1. 高性能 为了整个计算的pipeline能力，需要transpose以很高的性能完成操作。举个例子，在128 cycle内完成256*256的矩阵转置 2. 高灵活度 灵活度体现在两个维度。第一个维度是支持从256*25 <-> 32*32的各种矩阵转置，且资源利用率保持不变（譬如支持1个256*256，4个128*128…）。第二个维度是原始矩阵可以放在一个memory中，也可以放在多个memory中。 不考虑性能和实现的情况下，transpose其实只是promutation中很简单的一种，本质上只是两块memory之间的load 、store。即使只考虑性能，也有不断4分、脉动阵列、数据ratate这三种成熟的实现方法。当考虑flexibility时，事情就复杂了，高性能、灵活度、可实现性似乎成了三个需要trade off的角，似乎只有复杂的2D Flattened Buttetfly NoC可以继续研究研究…… 闲话就不多说了，继续翻论文去了。芯片设计本质上只是个工程问题，说难也难说简单也简单，见过的都简单，没概念的都难。