对某所谓“高速单周期51核”的分析和猜想

sqdym

还在学校时，用51用得最多，当时就很喜欢一些增强型（6T）的51，如philips x2系列，国内某公司的6T系列等。走出校门之后，发现慢慢出现了一些性能更强的51核芯片，如某公司所谓的1T系列，据说可以快上8~12倍，也买来玩过一小阵，但对该指标较怀疑，于是从分析，猜想和测试的角度来探讨一下该核的设计。因涉及硬件设计，所以发在fpga版，如有问题请版主帮手挪窝。
有关于指令的描述资料均出自其官方spec。

首先区分一下memory和register的访问性质：
同步sram的读出：在cycle（n）发出读信号（读使能和地址），cycle（n+1）时在sram的Q端获得读出的数据。
同步sram的写入：在cycle（n）发出写信号（写使能和地址，数据），在当前cycle末的时钟上升沿将数据写入，所以写入只占用cycle（n）这一个周期。
寄存器的读出：在cycle（n）发出读信号，当前cycle就可获得需读的数据。
寄存器的写入：在cycle（n）发出写信号，在当前cycle末的时钟上升沿将数据写入，所以写入只占用cycle（n）这一个周期。


1, 所有指令的执行周期数都不小于指令的字节数。
猜想：物理上code memory宽度为8bit，而没有使用更宽的宽度。

例：mov dptr, #data16           3byte, 3cycle
将16bit立即数送入dptr，这条指令执行过程很简单：从指令码中取得操作数，写入dptr寄存器，如果操作数已准备好，只需要一个cycle就可以完成写入过程，而多余的cycle很可能是用于从code memory中读取操作数。分析执行过程如下：

cycle n: code memory 的Q端出现前一cycle request的数据（op code），组合逻辑对其decode之后，认出是“mov dptr, #data16”指令，于是n和n+1连续读两次code memory，取得操作数。

cycle n+1: Q端出现操作数的第一byte，cpu将其锁存，并发出读后8bit的读信号

cycle n+2: Q端出现操作数的第二byte，cpu将其连同前一cycle锁存的第一byte一起写入dptr寄存器。本条指令至此执行完毕。发出对code memory的读信号，读取下一条指令的第一byte数据。

sqdym

回复【楼主位】sqdym
-----------------------------------------------------------------------


2，关于几条对a操作的指令的比较
猜想：对关键路径使用multi-cycle约束
例：
inc a                        1byte, 2cycle
clr a                        1byte, 1cycle
cpl a                        1byte, 2cycle
rl a                        1byte, 1cycle
swap a                1byte, 1cycle
这几条都是直接对a操作的指令，对比结果非常有趣，指令码长度相同（1byte），inc/cpl是需要经过alu运算才能获得结果的（加法/异或0xff），需要2cycle完成，而clr/rl/swap是不需要alu运算即可获得结果的（clr直接写0/rl和swap只需构建一条扭转的data path），就只需1cycle完成。于是猜想，可能关键路径在alu，为了获得尽量高的运行频率，需要alu运算的指令就使用了multi-cycle设计， 多等待一个cycle以使alu运算结果稳定后再回写。


待续，有空慢慢想慢慢写了......

longquan

好帖,流水线怎么不考虑

sqdym

我估计是没有使用流水线，因为所有直接或间接寻址memory的指令，没有一条是1cycle完成的。而若有使用流水线的话，只要ex段的回写和of段的读取没有相关性，那么是可以做到1cycle完成的。另外，如果有使用流水线，指令的运行速度提高很多，8bit宽的code memory就会造成取指瓶颈（因为很多指令码大于1byte），就是说，想快又没快彻底，从系统均衡性上来说的话，应该不会这样做。

sqdym

2b, 对第2点的补充。
第2点中分析了类似的指令，经过/不经过alu运算而导致执行cycle数有差异的问题，除了使用multi-cycle约束之外，也有可能是在alu的输出端增加了一级寄存器，切断组合逻辑path造成的（alu本身是由纯组合逻辑构造的，一般来说path比较长）。这样的结构和使用multi-cycle约束可以达到相似的效果，即可以放松对数据稳定时间的要求，且时序约束更简单（综合时不用特别约束multi-cycle），但逻辑量上可能稍微会大一些（FIFO是很大的）。

sqdym

3，对Rn的读操作可以在当前时钟周期完成
猜想：共32个的Rn是由独立的寄存器构造的，而不是映射至data ram中实现的。
mov a, Rn 这是为数不多的几条1cycle完成的指令中最特别的一条，因为它需要在1cycle中完成Rn的读出。之前有提到，同步sram的读取，数据需要在下一个cycle才能获得，那么说明Rn在物理实现上并不是sram，只能是寄存器。这点从mov a,@Ri指令（1byte，2cycle）也可以得到证实，只有Rn物理上是寄存器时，才只需要读1次sram而不是读2次，从而在2cycle内完成。问题在于这样的结构需要256bit寄存器来构造Rn，逻辑耗费很大，如果将Rn 映射至data ram中实现的话，可以瘦身很多，代价就是执行周期更长，但这无谓好坏，看designer怎样在时间和空间上取得一个平衡罢了。
有点意外的是，mov Rn, a这条指令，却要耗费2cycle完成，这一点是比较奇怪的，因为mov a, Rn，  mov Rn, a这两条指令的opcode都只有1byte，Rn是隐含在opcode中的，不需要再读另外的operand来指定，并且mov Rn, a是直接将acc的内容写入Rn，也不需经过alu，应该不存在第2点讨论的情形。那么为什么还需要多1个cycle呢？这点实在是很费解，暂无结论。

sqdym

呵呵，似乎大家对rtl结构设计并没有什么兴趣......

dickhou

晕，你是看的哪个1T的8051？我这边做的inc a/mov rn,a都是1 cycle啊。

sqdym

回复【7楼】dickhou
晕，你是看的哪个1t的8051？我这边做的inc a/mov rn,a都是1 cycle啊。
-----------------------------------------------------------------------

STC滴...

sqdym

还有，1T !== pipeline
stc有混淆概念误导大众的嫌疑，1T只是1个指令周期只消耗1个时钟，但绝大多数指令需要多于1个指令周期来完成。而pipeline结构的51，如果不论跳转引起的流水线阻塞的话，只有lcall和acall两条指令是需要2cycle完成，其余所有指令都只需要1cycle。这两者速度是完全不可同日而语的。

andriy

呵呵 围观