San Jose, California-based Cypress Semiconductor Corp has claimed performance leadership in the Sparc world with its superscalar HyperSparc RISC, but has been less than successful in gaining design wins against the Texas Instruments Inc SuperSparc. Last month it gave up on the unequal struggle. But for a few whispers about what it may imply about the progress or fate of HaL Computer Systems Inc – the press corp’s favourite non-computer computer company – and the more openly held opinion that it looks like an insurance policy safeguarding its ICL Plc sibling’s investment in the architecture, Fujitsu Ltd’s proposed $23m acquisition of Ross Technology Inc from Cypress, repository of all of the chip company’s Sparc work, appears to have been welcomed by most interested players. ICL denies that Fujitsu bought Ross for ICL’s benefit, and claims it is unlikely to get any get preferential treatment, although the two firms’ respective engineering teams are expected to get closer on development – technicians from each are already working side by side. Although Cypress returned to profit in the first quarter of 1993 after previous losses, Ross contributed only $3.9m to its parent’s $69.5m revenues, and there was speculation back then that the unit’s continued existence in its current form was in doubt because of Sun Microsystems Inc’s delayed design-in decision on HyperSparc. The sale of Ross to Fujitsu means Cypress will now concentrate on static RAMs, programmable logic devices and its high-performance niche product lines.
Is late and has suffered
The 75 Ross employees in Austin, Texas, will transfer to Fujitsu when the deal is completed, probably by the end of this month. Fujitsu and Cypress are committed to supporting current Sparc customers with both manufacturing and distribution and the two are also contributing $3m each towards the development of HyperSparc’s cache, memory management and multiprocessing technologies for use in architectures that will implement Intel Corp’s P6 processor and other Pentium follow-ons. Fujitsu is a licensee of the Sparc architecture, and has a range of standard Sparc implementations, but does not currently fabricate a device in the HyperSparc class. It abandoned plans for a top-end Sparc in 1990 in favour of variants like SparcLite for embedded applications after deciding that the high-end market would be too small. Some Cypress engineers are upset that the firm has cast off its six-year-old Sparc concern to Fujitsu just when the HyperSparc effort seemed to be coming to fruition. However most, including Sun Microsystems Inc, ICL and Ross itself, admit that Cypress undersized the investment required to bring HyperSparc to market. It looked at one point as if Ross’s plug-compatible competitor to SuperSparc would benefit from a window of opportunity left open by Texas. That company was unable to deliver its superscalar part on time, in sufficient numbers or with the required performance to its principal customer, Sun Microsystems Inc. However, HyperSparc too is late and has suffered its own technical problems. Announced back in May 1992, and due at the beginning of this year, the part now won’t ship in quantity until towards year-end. Some lay the blame for HyperSparc’s non-appearance at Sun’s door. One insider believes that despite its public claims of openess and desire to foster a Sparc-compatible community, the closed position of Sun constantly wrong-footed Cypress. The source says the workstation builder’s refusal to commit to using the part stymied its development while lack of support for HyperSparc in SunSoft’s Solaris operating system has prevented some firms from announcing HyperSparc strategies. Cypress sold [Ross] because it seemed Sun would never give HyperSparc the support it said it would, whether by using the CPU or putting Solaris up on it.
By William Fellows
With Sun apparently unwilling to sell or support the part the source says Cypress therefore didn’t need to sell Sun on the idea. He says Cypress could have employed a different strategy to get its technology ado
pted, namely touting HyperSparc’s performance advantages and selling into Sun’s customer base, starved, he says, of the high-performance SuperSparcs. Nevertheless, Ross’s Dave Pulling says the former Cypress unit is absolutely still looking for Sun to support HyperSparc the business is ours to win or lose, he maintains. Politics aside, SuperSparc can’t be manufactured in dual-channel modules for two CPUs, he says, claiming it is well understood amongst Sparc’s technical fraternity that HyperSparc is cooler and more efficient than SuperSparc. He cites HyperSparc’s 12m transistors against the 48m SuperSparc houses and claims a 15% integer and 40% floating point performance advantage for HyperSparc over over the Texas part. Cypress was responsible for HyperSparc fabrication, using an 0.65 micron process – and final sales. Now Ross will be using Fujitsu’s 0.5 micron technique, which means it can get a consistant 3V throughout the chip, not just on input-output – internal power consumption was formerly 5V using the Cypress fab process, says Pulling. He claims SuperSparc pays a cycle penalty for getting hold of the multiprocessing Mbus, which manifests itself at the compiler and application performance level: applications running on Texas parts require lots of cache memory or multiprocessing functions soon swallow all that is available. Pulling claims Texas has had to de-couple cache memory from the superscalar CPU to get it to work and says that this asynchronous link means SuperSparc doesn’t run as fast as HyperSparc. However, HyperSparc is still only out in sample quantities from Cypress and 66MHz modules won’t ship in quantity from Fujitsu until year-end. Planned 80MHz and 100MHz HyperSparcs are still in the works, says Pulling, and the firm is getting some yield at 80MHz now. Moreover, he says, Ross is now also working on 0.35 micron Gemini and Viper implementations of HyperSparc and claims they’ll go way beyond 100MHz. Overall, Ross believes Fujitsu has a better understanding of CPU business than Cypress and says it expects to get close technical co-operation from its new parent on all it does. HyperSparc modules are now installed at 12 alpha and beta sites – four in Europe. Indeed, ICL is currently working on four separate projects targeted for use with HyperSparc – Pulling says Ross engineers are already living at ICL. Industrade AG, Wallisellen, Switzerland; ECS in Dusseldorf and another unnamed site near Munich are the other Europeans. In the US, would-be HyperSparc supplier Columbus, Ohio-based Pinnacle Data Systems Inc, is confident Fujitsu’s acquisition of Ross will provide all the cash needed to bring HyperSparc to market. Pinnacle president Bob Henkel says his firm hasn’t been able to ship its promised HyperSparc systems not because there is any problem with the chip but because there is no version of Solaris for it yet.
It pukes
Content from our partners
So it is currently restricted to SuperSparc offerings – it just added a new Sparc-based RAID system – and will offer HyperSparc modules when SunSoft Inc delivers the necessary Solaris – this lack of support for HyperSparc in its Solaris Unix for Sparc architectures is a real problem. As it is presently configured, Solaris won’t boot up on HyperSparc – indeed it pukes, according to one commentator. As the boot procedure runs, the kernel polls the environment and detects what CPU it is on, and if it finds non-SuperSparc stuff it goes off into a corner and sulks… returning the message ‘illegal instruction set architecture’. All Solaris needs to run native on HyperSparc is a 38-line kernel patch and 10-line boot prompt patch. The patches are available from the Unix implementations part of the former Interactive Systems Corp, now owned by SHL Systemhouse Inc. The patches cajole Solaris into working with more underlying architectures than it is programmed to accept. All HyperSparc sites running Solaris currently use Interactive patches obtained together with the CPU from Ross, except for ICL, which is big enough to have done the required work on its DRS/NX Unix implementation
without help. Other potential HyperSparc suppliers don’t have the same resources and are awaiting a HyperSparc-enabled version of Solaris so they can shrink-wrap it. Observers say SunSoft could do the patch work without breaking sweat, although Pulling defends it, saying that Ross was still in lengthy debugging cycles while SunSoft, which has established its own process schedule for Solaris releases, couldn’t wait for it. Pulling hopes the patches will be written into the next Solaris release, 2.3, due October. Although nothing has been signed, he says Ross is more confident now than ever that SunSoft will do the job: all indications are that HyperSparc will be supported in 2.3. SunSoft admits that technically, HyperSparc support is only a port away.
