S1 Core

<p>The S1 Core testbench is written to make it possible to load directly the hexadecimal memory images of the official OpenSPARC T1 environment: <div align="center"><tt><b>$S1_ROOT/tests/boot/mem_*.image</b></tt></div> </p><p>The eight <tt><b>*.image</b></tt> files are linked in the <tt><b>$S1_ROOT/run/sim</b></tt> directory and then loaded by the testbench, so that the boot sequence of the S1 Core could resemble the one of the OpenSPARC T1.</p><p>The list of the expected first accesses is detailed in the file <div align="center"><tt><b>$S1_ROOT/docs/other/ACCESSES.txt</b></tt></div> </p><p>The problem is: we had to use an empty <tt><b>mem_RED_EXT_SEC.image</b></tt> file so after reading the SSI ROM (RED_SEC file) the SPARC Core gets just the default NOP values (0x01000000) and this is all we can do (at least it works since we see the Program Counter incremented).</p><p>Otherwise if we use exactly the same RED_EXT_SEC code of the T1 environment, by typing in <div align="center"><tt><b>mv -f $S1_ROOT/tests/boot/mem_RED_EXT_SEC.image_ORIGINAL $S1_ROOT/tests/boot/mem_RED_EXT_SEC.image</b></tt></div> before running the simulation, you will see that after a while the SPARC Core sends dirty requests and then the simulation hangs.</p><p>The same thing happens either with the byte code provided with the T1 or with a new one obtained by an objdump with GCC: after some ifetches all the signals get dirty.</p><p>To backtrack the problem you can open the <tt><b>trace.vcd</b></tt> file with GTKWave and then load the list of signals contained into the file <div align="center"><tt><b>$S1_ROOT/tools/src/gtkwave.sav</b></tt></div> where all the signals after wb_datain are there just to see which one gets dirty first.</p><p>We have investigated for a while and we have found that the PCX/CPX packet format we have used as a reference is probably wrong: <div align="center"><tt><b>http://forum.java.sun.com/thread.jspa?threadID=5108508&tstart=15</b></tt></div> </p><p>At the beginning the T1 guys told us to take the file <tt><b>iop.h</b></tt> as a reference but it seems that now it is wrong!</p><p>So the signals go dirty probably because our bridge puts some unexpected fields into the return packet (at least the CPX Packet ID is wrong since we were unable to reverse engineer it from the T1 waveforms and we had to tie it to a fixed value).</p>

<br><br>Someone should:

<ol> <li>Download the "OpenSPARC T1 Microarchitecture Specification" from <tt><b>http://opensparc.info/cgi-bin/goto.php?w=http://opensparc-t1.sunsource.net/specs/OpenSPARCT1_Micro_Arch.pdf</b></tt></li> <li>Read carefully the two tables in paragraph <b>"3.1.5 CPX and PCX Packet Formats"</b> on pages 107-108;</li> <li>Check what's wrong in our SPARC-to-Wishbone bridge <tt><b>$S1_ROOT/hdl/rtl/s1_top/spc2wbm.v</b></tt> and fix it.</li> </ol><p>It could be just a trivial task... the only problem being the fact that the two tables describing the PCX/CPX packet formats in the only available document (uArch) are very succinct.</p>