6 ms·

I dunno, Adapteva taped out at 28nm with 5 people. Do you mean that full custom design is particularly hard at 28nm or that it's hard for EDA vendors? 28nm is a

by _yosefk 11y ago

I dunno, Adapteva taped out at 28nm with 5 people. Do you mean that full custom design is particularly hard at 28nm or that it's hard for EDA vendors? 28nm is also a bulk node, I think it ought to have been easier to understand for everyone relatively to FinFET nodes.

nickpsecurity 11y ago
I've given them props before as they're a special case. They wrote a whole blog article on how they kept things cheap. In comments in past 48 hours, they mentioned something like $2-3 million in 3 years to get their relatively simple design done. I also remember they deal with HPC crowd that pays good money for even low-volume. So, they're just unusual across the board. Doesn't tell us much about a large design except to say physics will fight us every step of the way. Various approaches like asynchronous and self-correcting circuits might help us a bit. Look at Achronix FPGA's to see the power of the former.
gluggymug 11y ago
Uh, tape out doesn't mean you've verified anything properly. Looking at the various Intel bugs found, I can't help sniggering a little. Verification mistakes happen all the time though. It's just a matter of when the bugs are found: if found later, it has much greater impact. On the 28nm issue, getting your design to synthesize to 28 nm depends on the architecture and your constraints. Trickier data paths make it harder to get it meeting timing. Where your IOs are placed, where your RAMs are placed and how much you have, each thing can make it harder and harder to synthesize. Adapteva doesn't have much RAM I believe.
- _yosefk 11y ago
  Well, yeah, I'm just saying it wasn't a picnic at 40nm or 90nm, either. It didn't go from a walk in the park to a nightmare at 28nm. Also I believe all the bugs in TFA are logical bugs where the circuit would have misbehaved in a logical simulation, not the kind where the circuit "flips zeros to ones" or vice versa because of physical implementation issues. In this sense advanced nodes make things worse only indirectly by enabling larger, more complex designs.
  - gluggymug 11y ago
    Agreed. The bugs seem logical. It doesn't reflect well on the Intel verification effort if they were logical though. It means they didn't verify properly. One possible guess/excuse-for-stuffing-up is that tools don't always simulate correctly. There can be weird gotchas where simulation models and reality don't match.
- nickpsecurity 11y ago
  Are you joking? Intel uses (even invented) so much verification tech it's crazy. I'm talking more than any small vendor could hope to use as it would slow them down or take too much brains/training. Any bugs they're having are more likely due to size of their project or how custom the optimizations are. Here's some Intel techniques they use for verification: https://www7.in.tum.de/um/25/pdf/LimorFix-2.pdf https://www7.in.tum.de/um/25/pdf/LimorFix-2.pdf https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.pdf https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.p... IBM's papers on their verification system for POWER processors mention all kinds of optimizations for things like pipelines that make the logic ridiculous. Then they jump through hoops in verification. Yet, they don't hit 3+GHz on good pipeline without that. Undoubtedly, Intel's using similar tricks with similar issues. Regular ASIC verification doesn't cut it at their level. What they're doing is on another level. It's hard to say what exactly we should expect in terms of errata level given their operating constraints (esp marketing). Only thing I expect is to know clearly the circumstances errata appears so I can avoid it. They let me down...
  - gluggymug 11y ago
    "Are you joking? Intel uses (even invented) so much verification tech it's crazy." That's kinda why I am sniggering. Intel has a rep for letting bugs go to silicon despite all that stuff. In terms of verification, they dropped the ball probably (unless they found these bugs in verification and decided to tape out anyway). One area where they fell on their face seems to be AVX. From TFA, "Certain Combinations of AVX Instructions May Cause Unpredictable System Behavior". That's a huge bug. Remember how we discussed the torture testing of floating point on the RISC-V ? Kinda similar issue. A customer wouldn't be happy with a huge bug there. The big 3 of EDA tools (Cadence, Synopsis, Mentor Graphics) provide their own tools for verifying this stuff called UVM. Like anything, it still relies on the person using the tool. It takes a lot of effort and planning to use this stuff. Whenever the verification engineer has to create Verification IP to test the IP, there's a chance they create bugs of their own. It's like a golden rule. That's why I am not a fan of formal methods. Nothing is proven until you have it working in silicon.
    - nickpsecurity 11y ago

by _yosefk 11y ago

nickpsecurity 11y ago

I've given them props before as they're a special case. They wrote a whole blog article on how they kept things cheap. In comments in past 48 hours, they mentioned something like $2-3 million in 3 years to get their relatively simple design done. I also remember they deal with HPC crowd that pays good money for even low-volume. So, they're just unusual across the board. Doesn't tell us much about a large design except to say physics will fight us every step of the way. Various approaches like asynchronous and self-correcting circuits might help us a bit. Look at Achronix FPGA's to see the power of the former.

gluggymug 11y ago

Uh, tape out doesn't mean you've verified anything properly. Looking at the various Intel bugs found, I can't help sniggering a little. Verification mistakes happen all the time though. It's just a matter of when the bugs are found: if found later, it has much greater impact. On the 28nm issue, getting your design to synthesize to 28 nm depends on the architecture and your constraints. Trickier data paths make it harder to get it meeting timing. Where your IOs are placed, where your RAMs are placed and how much you have, each thing can make it harder and harder to synthesize. Adapteva doesn't have much RAM I believe.

_yosefk 11y ago
Well, yeah, I'm just saying it wasn't a picnic at 40nm or 90nm, either. It didn't go from a walk in the park to a nightmare at 28nm. Also I believe all the bugs in TFA are logical bugs where the circuit would have misbehaved in a logical simulation, not the kind where the circuit "flips zeros to ones" or vice versa because of physical implementation issues. In this sense advanced nodes make things worse only indirectly by enabling larger, more complex designs.
- gluggymug 11y ago
  Agreed. The bugs seem logical. It doesn't reflect well on the Intel verification effort if they were logical though. It means they didn't verify properly. One possible guess/excuse-for-stuffing-up is that tools don't always simulate correctly. There can be weird gotchas where simulation models and reality don't match.
nickpsecurity 11y ago
Are you joking? Intel uses (even invented) so much verification tech it's crazy. I'm talking more than any small vendor could hope to use as it would slow them down or take too much brains/training. Any bugs they're having are more likely due to size of their project or how custom the optimizations are. Here's some Intel techniques they use for verification: https://www7.in.tum.de/um/25/pdf/LimorFix-2.pdf https://www7.in.tum.de/um/25/pdf/LimorFix-2.pdf https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.pdf https://www.cl.cam.ac.uk/~jrh13/slides/nasa-14apr10/slides.p... IBM's papers on their verification system for POWER processors mention all kinds of optimizations for things like pipelines that make the logic ridiculous. Then they jump through hoops in verification. Yet, they don't hit 3+GHz on good pipeline without that. Undoubtedly, Intel's using similar tricks with similar issues. Regular ASIC verification doesn't cut it at their level. What they're doing is on another level. It's hard to say what exactly we should expect in terms of errata level given their operating constraints (esp marketing). Only thing I expect is to know clearly the circumstances errata appears so I can avoid it. They let me down...
- gluggymug 11y ago
  "Are you joking? Intel uses (even invented) so much verification tech it's crazy." That's kinda why I am sniggering. Intel has a rep for letting bugs go to silicon despite all that stuff. In terms of verification, they dropped the ball probably (unless they found these bugs in verification and decided to tape out anyway). One area where they fell on their face seems to be AVX. From TFA, "Certain Combinations of AVX Instructions May Cause Unpredictable System Behavior". That's a huge bug. Remember how we discussed the torture testing of floating point on the RISC-V ? Kinda similar issue. A customer wouldn't be happy with a huge bug there. The big 3 of EDA tools (Cadence, Synopsis, Mentor Graphics) provide their own tools for verifying this stuff called UVM. Like anything, it still relies on the person using the tool. It takes a lot of effort and planning to use this stuff. Whenever the verification engineer has to create Verification IP to test the IP, there's a chance they create bugs of their own. It's like a golden rule. That's why I am not a fan of formal methods. Nothing is proven until you have it working in silicon.
  - nickpsecurity 11y ago