[<<][rtl][>>][..]
Wed Aug 22 23:45:21 EDT 2018

Macro languages / Simulation

Maybe there is some room for improvement?  I guess I can continue with
this, find abstractions that work.  Comments, follow-ups

- multi-level sim (rtl, gate-level)
- asic: problem is verification (design for verification)
- RTL synthesis
- Event-driven approach is necessary (multiple clock domains)
- Seq test benches should be able to drive a verilog simulator (cosim)
- MyHDL cosim with icarus









https://news.ycombinator.com/item?id=9516217

"If you have worked in ASIC designs that you are almost certainly used
to not work with Verilog directly, but with an ad-hoc macro
language. I've seen them all, but most commonly Perl is used. It is
especially for circuits that we desperately need better tools and
abstractions."


> They are all toys aimed at newbies. They address problems that are
  no problem at all to a qualified engineer in the profession.

I think this kind of attitude is one of the main problems of the
hardware design industry (the other one is the conservative mindset).


The bugs are not due to language generally. If software guys want to
write a new language for HW engineers, they need to ask HW engineers
what the issues are rather then go off on a tangent.


As it is they don't even know what the workflow is like and where the
real pain lies. They are just writing tools for themselves. The
problem is their applications are not commercial.


Imperative synchronous languages.

https://news.ycombinator.com/item?id=9948906

Exactly. It's crazy to even think, outside of analog, that someone
would want to build a modern SOC with RTL directly. Even the
full-custom folks like Intel, correct me if I'm wrong, essentially use
a hardware approach where they can abstract away from and use EDA to
synthesize to the stuff they hand-craft. Most SOC builders simply
don't have the labor to waste working at RTL for a complex design &
its inevitable problems. It's why they pay so much to the Big Three
for synthesis tools.


The real difference is that in event-driven languages, clock events
are explicit, instead of implicit like in Chisel and the whole array
of dead HDLs that preceded it. So if history is any guide, Chisel is
dead upon arrival.


Essentially once you translate your Chisel design to verilog you
basically can't reuse your verification environment for the RTL
simulation or the gate-level. How are you going to check timing if you
wrote all your tests in Chisel?


So much more logic is added to chips during/after synthesis these days
and you have no way to get any of your tests running on that net list.


productivity bottleneck in hardware is not in design but verification
and specifically sequential verification. Combinational verification
is quote easy, because modern SAT solvers can prove almost all
combinational properties you can throw at them.


Lots of progress is happening though: Aaron Bradley's PDR
(http://theory.stanford.edu/~arbrad/) and Arie Gurfinkel and Yakir
Vizel's AVY (http://arieg.bitbucket.org/avy/) have made pretty major
breakthroughs in proving a lot of complex sequential properties and
these algorithms have made their way into industrial formal tools as
well.

(on clash) And you're still describing the transfer function between
states; C╬╗aSH does not seem to allow you to describe your program in a
structured way (such as loop until x becomes true, wait for 3 cycles,
read z, while z > 0 decrement z, etc.)



[Reply][About]
[<<][rtl][>>][..]