Hacker News new | past | comments | ask | show | jobs | submit login

The flow is not good IMO.

They haven't followed engineering practices which is one of the issues mdwelsh was talking about.

If they've synthesized to 45nm and 28nm, where's all their synthesis stuff - constraints etc.?

They have no back end stuff, very little docs, almost no tests, almost no verification infrastructure.




Hmm. Im clearly not an ASIC guy so I appreciate the tip on this. News to me. Ill try to look into it.

Any link you have where people mention these and any other issues?


Maybe I was a bit harsh with the "almost no tests". They have some tests.

Someone name fmarch asked on https://news.ycombinator.com/item?id=10831601 about verification against the ISA model.

It possibly can be done via a torture tester apparently, https://github.com/ucb-bar/riscv-torture , but taking a quick look I don't think it handles loops, interrupts, floating point instructions etc.


There didn't seem to be a lot in there but I don't know Scala. I wish it was scripted in Lua or something with the Scala doing execution and analysis. Make it easier for others to follow.

Doesn't seem nearly as thorough as what I've read in ASIC papers on verification. They did (co-simulation?), equivalence, gate-level testing, all kinds of stuff. Plus, you did it for a living so I take your word there. I do hope they have some other stuff somewhere if they're doing tapeouts at 28nm. Hard to imagine unless they just really trust the synthesis and formal verification tools.

The flow is here:

http://www.cs.berkeley.edu/~yunsup/papers/riscv-esscirc2014....

Are those tools and techniques good enough to get first pass if the Chisel output was good enough to start with? Would it work in normal cases until it hits corner cases or has physical failures?


Interesting paper. It sounds good until you look for the actual work. With a possibly limited amount of testing, you can't be sure of anything. In verification, you can never just trust the tools. With no code coverage numbers, how do I know how thorough the existing tests are? The tests themselves have no docs.

The torture test page said it still needed support for floating point instructions. That kinda says, they did no torture tests of floating point instructions. I wouldn't be happy with that. Same goes for loops. Etc.

You have to think about physical failures as well: the paper mentions various RAMs in the 45 nm processor. You should have BIST for those and Design For Test module/s. Otherwise you have no way to test for defects.


Yeah, that all sounds familiar from my research. Especially floating point given some famous recalls. Disturbing if it's missing. I'll try to remember to get in contact with them. Overdue on doing that anyway.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: