Design and Verification
Sorry if this is a repeat, but what are your post-silicon validation plans? What tests will you run to ensure HORUS and Opteron work as expected?
We have verified HORUS and Opteron compatibility pre-silicon against Opteron RTL, and also using an FPGA implementation of HORUS. Post-silicon validation plans are split along the following major lines: function/feature validation, OS boot up, application testing and performance testing.
We have a suite of stress tests that our system folks use for 2P and 4P systems that we built. We have a validation team and performance team that are developing their own test suites. Once we have the systems verified, we also will be shipping some boxes to customer sites. Sorry we can’t go into detailed verification test plans here since they are large in number.
Rajesh, this question is from Rob Thorpe, one of our contributors who could not join us today: What was your experience like using System C? Any particular advantages or disadvantages?
We started our first model of HORUS using system C. This continued to become our performance model and it is still in system C. But our verification behavior model is in Vera and our RTL is in Verilog. The reason we moved away from system C was because of support from our EDA vendor 3+ years ago.
Were there any particularly interesting or difficult issues you had to deal with when designing around the glueless nature of the Opteron?
There were definitely a whole lot of issues. Most of these were due to undocumented Opteron behavior in coherent HT domains. Some of these caused extensive redesign of our architecture once they were found. Yes lots of difficult issues were found and resolved.
Be the first to discuss this article!