Mon Jun 27 10:04:17 2005 吴海周 vs. 章亦春

  我现在还在考虑模型机的设计与测试问题，呵呵  	  我在想如果在一开始就考虑哪些东东是 Synthesizable，哪些不可以，那么我会死掉的。  	  所以我决定只要我的设计能单纯地进行仿真就可以了。  	  日后有机会再把不能综合(synthesis)的代码改成可以综合的。  	  事实上我现在也搞不清到底哪些是可以综合的，因为这是由 Vendors （供应商）自己决定的。  	  另外，我决定不使用 VHDL 语言，它实在是太难看了。  	  经过比较，我发现 Verilog HDL 是更好的选择，它不仅记法很干净，而且没有 VHDL 中类型转换方面的困挠，更重要的是它也是 IEEE 标准的一部分，呵呵。  	  我在网上找到一个名为 X-HDL 的工具，它可以在两种 HDL 语言之间进行自动转换——嗯，非常有趣的东东哦。  	  不过还是有些限制的。  	  如果我使用 Verilog 语言的高级特性，在翻译到对应的 VHDL 语言时可能没有对应的等价物。  	  因此我被限制在一个子集之中。  	  不过如果我能自己提供 Verilog 在 VHDL 中的“等价物”（比如 ShiftRight函数）的库实现的话，可以使我能使用的子集接近全集，呵呵。  	  你看，PSW(Process Status Word) 是作为一个单独的模块来实现呢，还是作为其他模块，比如 ALU 的一部分？  	  PSW 与 ALU有关联  	  ALU 每计算出一个结果都应当设置 PSW 中的相应的位(bit)。  	  那么你说 PSW 的位的修改是在与 ALU 操作的同一个 CPU 周期内完成呢，还是等下一个 CPU 周期到来的时候再生效呢？  	  不过 PSW 中的位应该用寄存器来实现，应当是时钟信号边沿触发的。  	  PSW 在下一个 CPU 脉冲的上升沿完成设置应当是来得及得吧？  	

	Wed Jul 6 15:33:59 2005 章亦春 vs. 成事有余
 
    比如 RAM、I/O device 等等。
...
现在32位的 RAM 已经设计完成，使用 Verilog HDL，而且用基于 Perl Template Toolkit 的自动化测试框架对其进行了比较彻底的测试。
	

	Wed Jul 6 17:22:54 2005 章亦春 vs. 张震波

      震波兄，一个简单的问题，如果地址是 32 位，而且是 byte-addressable，那么 RAM 是否应该自己推导到 字(word) 的地址（即忽略掉32位地址的最后两个bit）？  	  还是由处理器负责将字节地址转换为节地址？
不过那样的话，地址总线上的地址就不再是 32 位长，而是 30 位长了。 	是啊，确实有点。
不过我在设计计算机系统的时候必须考虑清楚。 	特别是将 字 切片为字节的问题。 	再有就是 字 的地址与 字节 的地址之间的相互转换。 

	Thu Jul 14 14:56:25 2005 章亦春 vs. 成事有余
  	现已完成 RAM 和 ALU 的设计与测试，正在考虑指令译码器的自动化构造问题。
	

	Thu Jul 14 19:55:33 2005 章亦春 vs. 代晓珂

      晓珂，我刚刚完成 ALU 的设计与测试工作。  	  我们支持以下操作：
ADD ADC SUB SBB MUL IMUL DIV IDIV
AND OR XOR
SHL SHR SAL SAR
ROL ROR RCL RCR
NOP 	我们的目标就是提供 Pentium4 所提供的非64位通用目的的 ALU 操作 	包括有/无符号的加减乘除、算术/逻辑移位、带/不带 CF 的位旋转(Rotate) 、按位与/或/非/异或。 	刚才的列表还漏了两个：
NOP NEG 	都是单操作数。 	我可是对照着 Intel 文档来做的噢。 

	Tue Jul 19 13:03:15 2005 章亦春 vs. 蔡玉飞

  	  最近，我和祥子的水平都有了很大的进步，多谢 Salent 项目了。  	  最近我设计出了一个通用的自动化硬件测试框架，从测试输入的生成，到测试结果的验证，全部自动化，无需人的干预。
我们已经用该框架对 Salent 模型机的 RAM 和 ALU 部件进行了彻底的测试。 	测试找出了许多很微妙的 bug，有的是我的 Verilog 实现的，有的是我的测试代码本身的问题，还有的是 ModelSim 仿真器的 BUG. 	无论如何，由于输入信号是测试台随机生成的，只要运行足够长的时间，便可以发现几乎所有的 bug. 	只要捕捉到 bug，纠正一般都是很直截了当的。 	我现在对我们的 RAM 和 ALU 已建立起了足够的信心。 	是啊，测试台迫使项目总是在正确的可以控制的轨道上前进。 	我们每作一处改动，就运行整个测试集，确保所作的修改没有碰坏其他原本可以工作的东西。 	同时这也可以通过测试台生成的报表，评价所作修改的实际效果。 	不过，测试台运行时间比较长，大约是十几秒到几十秒不等。比如 ALU 的测试集，运行一次，将进行 6887 个测试。而且每次运行，所进行的测试都不一样，因为输入都是随机生成的，而且种子是使用的系统时间。 	我们用模板生成任何东西，从 Verilog 代码到 Perl 程序，从 Tcl 仿真脚本到 POD 和 HTML 文档。 	还有写程序的程序…… 	I'd rather write programs to write programs to write programs. 	我注意到 ModelSim SE 6.0 的仿真器在性能上远不及 5.7d 这个较老的版本。真奇怪。 	在我这台装有 ModelSim 6.0 的 Pentium4 2.6GHz 的机器上运行 ALU 的测试集还不及我家那台装有 5.7d 的 赛扬 330 的破机器。 	为什么啊#55 	估计 6.0 做得太庞大了。 	我是 ALU 测试台刚刚生成的测试表报：
alu.........ok
talu1.op....ok
talu2.op....ok
talu3.op....ok
talu4.op....ok
talu5.op....ok
All tests successful.
Files=6, Tests=6887, 12 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)
Timing Result: 525.359000 sec on average. 	一共花了 525 秒耶！ 	在测试中，“错误就是命令！” 	如有错误，测试台会报告发生错误的具体位置，比如文件名、行号、仿真时间区间、ALU 输入信号的取值、等等。 	这些信息给排错带来了极大的便利。 	仲伟祥在我的框架基础上编写的 RAM 的“随机应力测试台”捕捉到了 ModelSim 仿真器的一个 bug. 太棒了！ 	这种高强度的随机测试对包括仿真器在内的每一个部件，每一行代码都施加了巨大的压力，不是么？ 	Well done! Sal++ 	

	Wed Jul 20 15:02:05 2005 章亦春 vs. 蔡志芹
  	我们从零开始，自己设计 CPU，RAM 这样的超大规模集成电路。
	

	Sun Jul 31 16:23:24 2005 章亦春 vs. 吴海周

      不知道你有没有考虑到“字切片”的问题？  	  RAM 和 总线都是按照“字”来读写的，而 CPU 却常常需要对单个或两个字节进行操纵，如何解决这个问题？  	  给定一个字是32位。  	  首先，请回答一个问题：
RAM 内部应按“字”来存取，还是按“字节”来存取？ 	第二个问题：
数据总线上一次传输一个字呢，还是一次传输一个字节？ 	在 32 位地址模式下，字的地址是否当是 0，4，8，12……
而字节的地址应当是 3，2，1，0，7，6，5，4，……？ 	我现在最不能确定的是 RAM 内部到底该以字为单位来存放呢，还是以字节为单位来存放。 	我在想 RAM 以字节来存放数据，是否合理？ 	CPU 这样就必须指明要传输的连续的字节数目？ 	CPU 必须告诉 RAM 首字节的地址，然后告诉它 连续读取的字节个数，如此一来，“字”的意义就全然丧失了？ 	“字地址”的概念不也全然失去实际意义了？ 	目前，我们的 RAM 在内部是以“字”为单位来存放数据的。 	CPU 仍然在地址总线上放置 32 位字节地址，但 RAM 在内部忽略地址的最后两个比特，自己推导出字的地址，然后完成读写操作。 	我不知道让 RAM 自己完成字的切片问题，究竟有多少优点。 	如何 RAM 对字节地址完全忽略，那么 CPU 的工作将变得很多。 	我在考虑专门编写一个硬件模块来完成 RAM 与 CPU 之间“字”与“字节”的转换工作。 	我打算将之命名为 MMU (Memory Management Unit)，不知你有何意见？