2009-02-06: Origin
Category: General
Posted by: afeldstein
The development of FSS predates the formation of the Cosmic Horizon business by at least two years. The project didn't start with market analysis. It was initially driven by a desire for fun and experience. Here is the story, to the best of my recollection.
In 2000, I landed a job with Motorola, working on functional verification of software. The design under verification (DUV) was CodeWarrior Development Studio for Motorola Star*Core digital signal processor. CodeWarrior is an IDE. This particular CodeWarrior's developer platform (i.e. the user's host platform ) was Solaris UltraSPARC. In order to verify the DUV, I had a Sun Ultra 5 workstation on my desk. I was working very hard on that job, putting in lots of extra hours for free. At some point, I decided to tap into some of those extra hours to do something for myself. With the assistance of SPARC Architecture, Assembly Language Programming, and C, I began to study the Sun Ultra 5.
Then I got the idea to give myself additional software engineering experience by creating something substantial, something with a GUI. The problem was that I was still giving Motorola a lot of hours, and studying SPARC on top of that. I didn't want to give up either. The solution was to combine the new software project with my SPARC study. Included with the CodeWarrior product was the SC100 Simulator, "an instruction-accurate, batch simulator for the SC100 generation of DSP cores.", in other words an instruction set simulator (ISS). This Star*Core simulator was in the form of an executable image. I knew how to create an executable image and my favorite language was C++.
To put things in perspective, at the time I began to focus on the Star*Core ISS (2001?), I didn't even know that I was interested in chip verification. I had been an intern on the Alpha verification team at Compaq in 1999. After that, I interviewed with Compaq's server group, so I was more interested in an SMP node than a microprocessor core. The first interview after Motorola in 2003 was a position that I pursued in embedded firmware, so I was still confused. Fortunately, I didn't accept a paying position until after I saw the light some time in 2004. I realized that the Alpha job was the best job I ever had (outside of Cosmic Horizon) and decided to get another one like it. By September, I was working on functional verification of IBM's POWER6 microprocessor.
back to the story:
Why didn't I do something with Verilog or VHDL? I don't have a good answer for that, not remembering exactly what my thoughts were at the time. But it seems that I had already narrowed my thinking to the idea of modeling a SPARC device using the object-oriented C++ language.
At home, I had a Pentium II PC running OS/2. For software development, I had VisualAge C++ for OS/2. I can find no evidence of the SPARC simulator project's existence before 2002 February, but I suspect that it goes back a little further. I created a basic prototype, just to work out a few issues (e.g. GUI, multithreading, register and address space modeling). I used VisualAge's "Project Smarts" to get started writing a Presentation Manager application. I figured out how to give the user the ability to open a SPARC-V9 executable file using the GUI. I created separate threads for the user interface and the simulation because the user would want responsiveness from the application even while the simulation is running. According to the VisualAge Programming Guide, "multithread programming is a feature of the OS/2 operating system and is supported by the VisualAge C++ compiler with code generation and linking options ... multithread libraries." When modeling a 64-bit microprocessor such as those that implement SPARC-V9, 64-bit attributes are pervasive. Therefore, it's natural to use a 64-bit primitive type. C++ doesn't guarantee a 64-bit primitive type. According to the C++ standard (INCITS/ISO/IEC 14882-2003), "There are four signed integer types : 'signed char', 'short int', 'int', and 'long int'. In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment". For example, if the natural size suggested by the architecture of the execution environment is 32 bits (e.g. OS/2 IA-32), then a long int may be only 32 bits wide. I found myself overly concerned with the details of the development platform.
Although most C++ compilers today have 64-bit integer support, Version 3.0 of VisualAge C++ for OS/2 did not. A 64-bit integer fundamental type is still not part of a ratified C++ standard. Even when finally added, it is expected that the standard will allow an implementation to make a 'long long int' longer than 64 bits. In other words, there will still be no fundamental type in C++ that is guaranteed to be exactly 64 bits in all compliant compilers. This is an inconvenience. And I'm sorry, but I'm not a big fan of typedef.
The Java Language Specification guarantees that 'long' is 64 bits, a natural fit for modeling SPARC-V9. Multithreading is inherent. Cross-platform GUI development is simplified with Desktop Java technologies.
Object-oriented programming makes sense for modeling the physical modules that make up a microprocessor. But then I started thinking about how I was going to connect the modules together. In a real microprocessor, wires make the connections. Was I going to call methods of each module in order to model inter-module signal propagation? If so, who would call those methods, the driving modules? What makes the whole system go? A peak at the SPARC-V9 Simulator for OS/2 source code reveals that I was far enough along that I must have had those same questions while working in C++. My memory has been telling me all these years that I decided to move to Java before resolving those questions. Perhaps I was only considering the move when I found the solution. Perhaps it was the solution that convinced me to move to Java after all. That solution was JHDL.
(If that's the way it happened, then I'm really glad I decided to write this blog item, because it has helped me to remember.)
If I hadn't found JHDL, I'd still be working on the simulation engine and other primitives. I wouldn't be having nearly as much fun as I'm having now. And I wouldn't know nearly as much as I do about SPARC-V9.
Next, three ideas came together at around the same time. I don't remember the exact sequence, but one of those ideas was to form the Cosmic Horizon business around FSS. Cosmic Horizon was formed in 2004. Another idea was to write an SRS. The third idea was to revisit an integer multiplication hardware design.
Whether I decided to form a business first or write the SRS doesn't really matter. The SRS represents a commitment to developing a useful product. Note the evolution of thought. I had started by looking at an ISS. Then I started reading about microprocessor simulation and gathering requirements. I ended up with an architectural simulator, not an ISS. FSS is designed to verify that a customer's RTL implementation complies with SPARC-V9.
Around the same time, I was writing a cover letter to align my skills to a job I was applying for. Skills acquired are skills acquired, regardless of how it happened. Having a strong interest in computer arithmetic, I blew the dust off one of my lab reports from 1988, when I was at RIT. I decided to read the report before writing the cover letter bullet. The report was on the implementation of an 8x8 integer multiplier. I felt back then that I had a novel idea, but the schedule did not permit thorough study. Reading the report, I knew that I could do a better job now. If only I didn't have so much on my plate already ... But of course I could extend it to 64x64 and make it implement the SPARC-V9 MULX instruction in the Sputnik microprocessor. I was going to need a multiplier anyway. This subproject gave me a specific place to get started. FSS was fully underway.
In 2000, I landed a job with Motorola, working on functional verification of software. The design under verification (DUV) was CodeWarrior Development Studio for Motorola Star*Core digital signal processor. CodeWarrior is an IDE. This particular CodeWarrior's developer platform (i.e. the user's host platform ) was Solaris UltraSPARC. In order to verify the DUV, I had a Sun Ultra 5 workstation on my desk. I was working very hard on that job, putting in lots of extra hours for free. At some point, I decided to tap into some of those extra hours to do something for myself. With the assistance of SPARC Architecture, Assembly Language Programming, and C, I began to study the Sun Ultra 5.
Then I got the idea to give myself additional software engineering experience by creating something substantial, something with a GUI. The problem was that I was still giving Motorola a lot of hours, and studying SPARC on top of that. I didn't want to give up either. The solution was to combine the new software project with my SPARC study. Included with the CodeWarrior product was the SC100 Simulator, "an instruction-accurate, batch simulator for the SC100 generation of DSP cores.", in other words an instruction set simulator (ISS). This Star*Core simulator was in the form of an executable image. I knew how to create an executable image and my favorite language was C++.
To put things in perspective, at the time I began to focus on the Star*Core ISS (2001?), I didn't even know that I was interested in chip verification. I had been an intern on the Alpha verification team at Compaq in 1999. After that, I interviewed with Compaq's server group, so I was more interested in an SMP node than a microprocessor core. The first interview after Motorola in 2003 was a position that I pursued in embedded firmware, so I was still confused. Fortunately, I didn't accept a paying position until after I saw the light some time in 2004. I realized that the Alpha job was the best job I ever had (outside of Cosmic Horizon) and decided to get another one like it. By September, I was working on functional verification of IBM's POWER6 microprocessor.
back to the story:
Why didn't I do something with Verilog or VHDL? I don't have a good answer for that, not remembering exactly what my thoughts were at the time. But it seems that I had already narrowed my thinking to the idea of modeling a SPARC device using the object-oriented C++ language.
At home, I had a Pentium II PC running OS/2. For software development, I had VisualAge C++ for OS/2. I can find no evidence of the SPARC simulator project's existence before 2002 February, but I suspect that it goes back a little further. I created a basic prototype, just to work out a few issues (e.g. GUI, multithreading, register and address space modeling). I used VisualAge's "Project Smarts" to get started writing a Presentation Manager application. I figured out how to give the user the ability to open a SPARC-V9 executable file using the GUI. I created separate threads for the user interface and the simulation because the user would want responsiveness from the application even while the simulation is running. According to the VisualAge Programming Guide, "multithread programming is a feature of the OS/2 operating system and is supported by the VisualAge C++ compiler with code generation and linking options ... multithread libraries." When modeling a 64-bit microprocessor such as those that implement SPARC-V9, 64-bit attributes are pervasive. Therefore, it's natural to use a 64-bit primitive type. C++ doesn't guarantee a 64-bit primitive type. According to the C++ standard (INCITS/ISO/IEC 14882-2003), "There are four signed integer types : 'signed char', 'short int', 'int', and 'long int'. In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment". For example, if the natural size suggested by the architecture of the execution environment is 32 bits (e.g. OS/2 IA-32), then a long int may be only 32 bits wide. I found myself overly concerned with the details of the development platform.
Although most C++ compilers today have 64-bit integer support, Version 3.0 of VisualAge C++ for OS/2 did not. A 64-bit integer fundamental type is still not part of a ratified C++ standard. Even when finally added, it is expected that the standard will allow an implementation to make a 'long long int' longer than 64 bits. In other words, there will still be no fundamental type in C++ that is guaranteed to be exactly 64 bits in all compliant compilers. This is an inconvenience. And I'm sorry, but I'm not a big fan of typedef.
The Java Language Specification guarantees that 'long' is 64 bits, a natural fit for modeling SPARC-V9. Multithreading is inherent. Cross-platform GUI development is simplified with Desktop Java technologies.
Object-oriented programming makes sense for modeling the physical modules that make up a microprocessor. But then I started thinking about how I was going to connect the modules together. In a real microprocessor, wires make the connections. Was I going to call methods of each module in order to model inter-module signal propagation? If so, who would call those methods, the driving modules? What makes the whole system go? A peak at the SPARC-V9 Simulator for OS/2 source code reveals that I was far enough along that I must have had those same questions while working in C++. My memory has been telling me all these years that I decided to move to Java before resolving those questions. Perhaps I was only considering the move when I found the solution. Perhaps it was the solution that convinced me to move to Java after all. That solution was JHDL.
(If that's the way it happened, then I'm really glad I decided to write this blog item, because it has helped me to remember.)
If I hadn't found JHDL, I'd still be working on the simulation engine and other primitives. I wouldn't be having nearly as much fun as I'm having now. And I wouldn't know nearly as much as I do about SPARC-V9.
Next, three ideas came together at around the same time. I don't remember the exact sequence, but one of those ideas was to form the Cosmic Horizon business around FSS. Cosmic Horizon was formed in 2004. Another idea was to write an SRS. The third idea was to revisit an integer multiplication hardware design.
Whether I decided to form a business first or write the SRS doesn't really matter. The SRS represents a commitment to developing a useful product. Note the evolution of thought. I had started by looking at an ISS. Then I started reading about microprocessor simulation and gathering requirements. I ended up with an architectural simulator, not an ISS. FSS is designed to verify that a customer's RTL implementation complies with SPARC-V9.
Around the same time, I was writing a cover letter to align my skills to a job I was applying for. Skills acquired are skills acquired, regardless of how it happened. Having a strong interest in computer arithmetic, I blew the dust off one of my lab reports from 1988, when I was at RIT. I decided to read the report before writing the cover letter bullet. The report was on the implementation of an 8x8 integer multiplier. I felt back then that I had a novel idea, but the schedule did not permit thorough study. Reading the report, I knew that I could do a better job now. If only I didn't have so much on my plate already ... But of course I could extend it to 64x64 and make it implement the SPARC-V9 MULX instruction in the Sputnik microprocessor. I was going to need a multiplier anyway. This subproject gave me a specific place to get started. FSS was fully underway.
Drema Garrett wrote: