2006-08-29: Icarus Verilog
Any SPARC-V9 implementation can be described by a functional/structural model in JHDL. In order for FSS to be useful for verification of a user-supplied SPARC-V9 design, that design must be modeled in JHDL.
Tom Hawkins promises "a path from Verilog to ... JHDL" requiring that the Verilog be constrained to the subset understood by Icarus Verilog. I am doing some trailblazing by attempting to prove Hawkins's assertion with respect to the Verilog RTL model of the OpenSPARC T1 microprocessor. At this point, I am happy to report that a check of the syntax of the OpenSPARC T1 Verilog source using Icarus Verilog was successful. I wish to thank Alexei Duhovich, who worked with me on IBM's POWER6™ microprocessor, for his assistance with this task.
Stay tuned for more on this as I continue to push OpenSPARC T1 toward FSS.
Tom Hawkins promises "a path from Verilog to ... JHDL" requiring that the Verilog be constrained to the subset understood by Icarus Verilog. I am doing some trailblazing by attempting to prove Hawkins's assertion with respect to the Verilog RTL model of the OpenSPARC T1 microprocessor. At this point, I am happy to report that a check of the syntax of the OpenSPARC T1 Verilog source using Icarus Verilog was successful. I wish to thank Alexei Duhovich, who worked with me on IBM's POWER6™ microprocessor, for his assistance with this task.
Stay tuned for more on this as I continue to push OpenSPARC T1 toward FSS.
2006-08-14: I Owe You an Explanation
To those who visit my Web site (there has been fantastic traffic growth over the last year), I feel that I owe you an explanation about where Cosmic Horizon is and where it is going. That is my motivation for starting this blog.
When I returned from the Design Automation Conference (DAC), I decided to start a blog, and then look into the Sun Partner Advantage Program for Independent Software Vendors (ISVs). After that, I'll get back to work on the Feldstein SPARC-V9 Simulator (FSS).
It is fair to say that FSS is in the early stages of development, but it's a bit more impressive (if I do say so myself) than the Version_0-003 that some of you might have downloaded.
FSS Version_0-004 introduced a program counter, and achieved the milestone of executing a series of instructions in an application program. Along the way it became convenient for me to have a memory view, so it was time to implement that requirement.
FSS Version_0-004 was tagged for release on 2006-04-14, but withheld because it introduces a dependency on a broken part of Apache Axis2, a part that I fixed. I provided a patch to The Apache Software Foundation (ASF) on 2006-03-17. On 2006-03-23, ASF released Axis2 Version 0.95 without my patch. On 2006-05-04, ASF released Axis2 Version 1.0, still without my patch! I had underestimated the amount of hand-holding that was required to get that project team to simply apply a patch to a "Major" issue. I won't make that mistake again. (If I sound a little annoyed, I am.) On 2006-06-01, my patch was applied to ASF's trunk. We anxiously await release of Axis2 Version 1.1. The latest estimate on that is that ASF "can do a release after ApacheCon Asia", which is taking place in Sri Lanka this week.
FSS Version_0-005 implements all of the instructions required to start in the RED_state trap table (i.e. the bootstrap loader), jump to the main entry point of an application program, and execute that program (a load/add/store sequence).
FSS Version_0-005 was tagged for release on 2006-06-07, but withheld for the same reason as the previous version.
FSS Version_0-006 is under development. This version is about automating the verification of the ADD instruction. Instead of getting an individual ELF file from your file system (interactive mode), FSS gives the user the option (automated mode) of pulling test programs from a test cases database, which you'll have to provide and I'll have to define. If such a database is not available, automated mode will be disabled. This rudimentary front end is in place already, and I'm working on the back end (a results database), which probably can be created/filled by FSS. The reason that the test cases database is not provided is that I've created an in-house Random Test Program Generator (RTPG) that works in assembly language and depends on Solaris SPARC for assembling and linking. RTPG creates the test cases database, in my case. FSS is designed to run anywhere, so I can't count on the user's environment having a SPARC assembler and linker. Therefore, RTPG is not part of FSS.
As I began to work on the results database, a colleague working at a major Sun competitor pointed out that they don't store identification of the design under verification in their database. For example, if there is a "fail" result, that is not accompanied by information about which night's build (i.e. which "chip release") exhibited that behavior! FSS can do better than that.
Going down that path, I am forced to deal with a refactoring that I had been postponing. Each release of FSS has included Cosmic Horizon's SPARC-V9 implementation (i.e. the design under verification). In the SRS, there is mention of a "SPARC-V9 Standard Reference Model". I have not begun work on that. All of the instruction execution capability comes from the design under verification at this time. To keep with the cosmic horizon metaphor, this first Cosmic Horizon microprocessor has been named "Sputnik". Like I said, Sputnik is currently part of FSS, but that is where your design under verification will go, so Sputnik may be withheld in the future. The point I want to make is that I am doing some refactoring now, so that another in-house tool (one that reads the chip release from the UML model, writes this as metadata into the structural model, then commits and tags with the same name) works the way I want it to. This refactoring is about making Sputnik more distinct from the rest of FSS. The difference probably won't be noticeable in Version_0-006. After all, FSS is closed source.
The plan for FSS Version_0-007 is to keep pushing toward at least Level 1 SPARC-V9 compliance in Sputnik before beginning work on the SPARC-V9 Standard Reference Model. The feedback I've been getting is that there is interest in how many instructions FSS implements, so l'm inclined to keep going that way rather than start the SPARC-V9 Standard Reference Model from zero at this time. Besides, I have some personal interest in computer arithmetic that I want to explore, and MULX is next. An implementation of MULX is already in Sputnik, even in FSS Version_0-003. It's just not turned on yet. It's a multiplier that I designed in 1998. I've learned a lot since then, so I might want to do a little design space exploration. Nevertheless, FSS Version_0-007 will be able to execute MULX.
After FSS Version_0-007, I think it would be fun to find the SPEC CPU2000 integer benchmark program that uses MULX the most (please don't tell me; that's part of the fun). Running that program will certainly require implementation of more instructions.
Finally, let me say that I've decided to spend some time on OpenSPARC. I have said that "any SPARC-V9 implementation, including the OpenSPARC T1 processor, can be described by a functional/structural model in JHDL." FSS should be able to verify OpenSPARC T1. In parallel with my other efforts, I am taking some steps in that direction.
When I returned from the Design Automation Conference (DAC), I decided to start a blog, and then look into the Sun Partner Advantage Program for Independent Software Vendors (ISVs). After that, I'll get back to work on the Feldstein SPARC-V9 Simulator (FSS).
It is fair to say that FSS is in the early stages of development, but it's a bit more impressive (if I do say so myself) than the Version_0-003 that some of you might have downloaded.
FSS Version_0-004 introduced a program counter, and achieved the milestone of executing a series of instructions in an application program. Along the way it became convenient for me to have a memory view, so it was time to implement that requirement.
FSS Version_0-004 was tagged for release on 2006-04-14, but withheld because it introduces a dependency on a broken part of Apache Axis2, a part that I fixed. I provided a patch to The Apache Software Foundation (ASF) on 2006-03-17. On 2006-03-23, ASF released Axis2 Version 0.95 without my patch. On 2006-05-04, ASF released Axis2 Version 1.0, still without my patch! I had underestimated the amount of hand-holding that was required to get that project team to simply apply a patch to a "Major" issue. I won't make that mistake again. (If I sound a little annoyed, I am.) On 2006-06-01, my patch was applied to ASF's trunk. We anxiously await release of Axis2 Version 1.1. The latest estimate on that is that ASF "can do a release after ApacheCon Asia", which is taking place in Sri Lanka this week.
FSS Version_0-005 implements all of the instructions required to start in the RED_state trap table (i.e. the bootstrap loader), jump to the main entry point of an application program, and execute that program (a load/add/store sequence).
FSS Version_0-005 was tagged for release on 2006-06-07, but withheld for the same reason as the previous version.
FSS Version_0-006 is under development. This version is about automating the verification of the ADD instruction. Instead of getting an individual ELF file from your file system (interactive mode), FSS gives the user the option (automated mode) of pulling test programs from a test cases database, which you'll have to provide and I'll have to define. If such a database is not available, automated mode will be disabled. This rudimentary front end is in place already, and I'm working on the back end (a results database), which probably can be created/filled by FSS. The reason that the test cases database is not provided is that I've created an in-house Random Test Program Generator (RTPG) that works in assembly language and depends on Solaris SPARC for assembling and linking. RTPG creates the test cases database, in my case. FSS is designed to run anywhere, so I can't count on the user's environment having a SPARC assembler and linker. Therefore, RTPG is not part of FSS.
As I began to work on the results database, a colleague working at a major Sun competitor pointed out that they don't store identification of the design under verification in their database. For example, if there is a "fail" result, that is not accompanied by information about which night's build (i.e. which "chip release") exhibited that behavior! FSS can do better than that.
Going down that path, I am forced to deal with a refactoring that I had been postponing. Each release of FSS has included Cosmic Horizon's SPARC-V9 implementation (i.e. the design under verification). In the SRS, there is mention of a "SPARC-V9 Standard Reference Model". I have not begun work on that. All of the instruction execution capability comes from the design under verification at this time. To keep with the cosmic horizon metaphor, this first Cosmic Horizon microprocessor has been named "Sputnik". Like I said, Sputnik is currently part of FSS, but that is where your design under verification will go, so Sputnik may be withheld in the future. The point I want to make is that I am doing some refactoring now, so that another in-house tool (one that reads the chip release from the UML model, writes this as metadata into the structural model, then commits and tags with the same name) works the way I want it to. This refactoring is about making Sputnik more distinct from the rest of FSS. The difference probably won't be noticeable in Version_0-006. After all, FSS is closed source.
The plan for FSS Version_0-007 is to keep pushing toward at least Level 1 SPARC-V9 compliance in Sputnik before beginning work on the SPARC-V9 Standard Reference Model. The feedback I've been getting is that there is interest in how many instructions FSS implements, so l'm inclined to keep going that way rather than start the SPARC-V9 Standard Reference Model from zero at this time. Besides, I have some personal interest in computer arithmetic that I want to explore, and MULX is next. An implementation of MULX is already in Sputnik, even in FSS Version_0-003. It's just not turned on yet. It's a multiplier that I designed in 1998. I've learned a lot since then, so I might want to do a little design space exploration. Nevertheless, FSS Version_0-007 will be able to execute MULX.
After FSS Version_0-007, I think it would be fun to find the SPEC CPU2000 integer benchmark program that uses MULX the most (please don't tell me; that's part of the fun). Running that program will certainly require implementation of more instructions.
Finally, let me say that I've decided to spend some time on OpenSPARC. I have said that "any SPARC-V9 implementation, including the OpenSPARC T1 processor, can be described by a functional/structural model in JHDL." FSS should be able to verify OpenSPARC T1. In parallel with my other efforts, I am taking some steps in that direction.
Sidebar
