Hacker News Reader

Comment by naikrovek | Hacker News Reader

why is this stuff almost always Python-based?

Have we not learned? Python is a fine language, but it is dynamically type checked, and not compiled to binaries. There is so much evidence all around us that statically type-checked, compiled languages produce better, more performant code, and allow for application stability and longevity much more easily.

I get that Python may be your favorite language, and that's fine, and that alone doesn't immediately qualify it as a good choice for anything, if you're being objective.

View on HN

Authore here. Python is for the build system. Plug in any front end you want. If you want to turn it into silicon, you will need to go through commercial tools which interface through proprietary tcl. How would you solve that problem? We solved it using python.

This seems like a pretty egregious misreading of the project?

Python isn't being lowered into silicon. It's a glue language for Boring Old Verilog that's been "compiled" into silicon since 1984.

chip.set('source', 'heartbeat.v')

It seems you're right but I also misread it. I think it's badly written. Does this not sound like high level synthesis?

> Process scaling is coming to an end and it is a social imperative that we find a new path to extend the Moore's Law exponential. The most viable option is extreme silicon specialization, which will require fast automated translation from program to silicon. Compiling simple programs into silicon should be like using llvm or gcc

> development should be like programming in Python

It actually seems like it is just a Python EDA build system. Python is still a terrible choice though.

Expressing a complex project succinctly enough that all of HN will get it within 5sec is an np hard problem...here are the full docs. https://docs.siliconcompiler.com/en/latest/

I don't think the project is putting their best presentation forward, but the second image on the intro makes it pretty clear there's a .v/.sdc/.def file kicking around. Without any relevant tooling to develop, debug, or modify them, but it's clear the python is just shuffling deck chairs.

I think the reason we argue about this constantly is that we treat this like a 1 dimensional problem when it's the classical 2 dimensional problem where 3 quadrants are tenable and people only agree that there is a bad quadrant, an ideal quadrant, and then we argue endlessly about the remaining two.

The truth is probably that the value of verifying correctness at compile time is proportional to how often the code will be run. There is space for 'glue' code that is in a simpler language, as long as we relentlessly search for code that deserves to be promoted to a more robust representation.

Take game engines for example, where story-driven elements are driven by a scripting language, often Lua, for decades now. The real engine is in a language the narrators probably can't understand, which affords the engine designers the right to change their minds about how it actually works.

I think we expect firmware and silicon to be run millions of times more than any particular piece of code. So the question is "Why Python for this scenario?" and I'd like to know the answer too.

You are missing the point. This is the language for the REPL, not "compiled to binaries". Python may or may be not be an improvement over Tcl, but that's what you're competing with here.

> I get that Python may be your favorite language, and that's fine, and that alone doesn't immediately qualify it as a good choice for anything, if you're being objective

Actually I believe you are incorrect here. From my reads, I think the research shows that factors that depends on the programmer still contribute more heavily to code correctness and success than static vs dynamic typing.

So I'd hypothesize that how much the programmer enjoys themselves when working and programming in a language on a given code base plays a significant role to the code quality, correctness and overall success.

It doesn't have to be. I once made a julia->verilog transpiler that even recompiled your julia functions with verilator, so you could verify that the code was correct.

https://github.com/interplanetary-robot/Verilog.jl

Of course, gaining traction on something like this is tricky.

I actually think Erlang/BEAM would be a great choice for making EDA tools, because it has concurrent execution model that you could probably very easily make play nice in rudimentary simulations of circuits that have triggers (`always @` sort of stuff.

This is not a transpiler. You are using Julia as a templating language for HDLs.

Do you prefer TCL?

As far as I can tell this is python replacement for https://github.com/The-OpenROAD-Project/OpenLane/blob/master...

The CAD tools it calls will be the bottleneck, not the wrapper script. https://docs.siliconcompiler.com/en/latest/reference_manual/...

Python is just exposing the interface. It's like using Boto3 and calling S3 python based. You should write a wrapper for your favorite language.

Btw, what do you recommend instead of Python?

> It's like using Boto3 and calling S3 python based.

Well, except this project is just the Boto3 part. It's like calling Boto3 Python-based. Under the hood it uses existing projects like Yosys and Verilator. The only bit's they've added are in Python as far as I can tell.

> Btw, what do you recommend instead of Python?

If you really want to retain the scripting aspect I would use Typescript via Deno. It's a gazillion times faster than Python, much better infrastructure (no venv/setuptools/dependencies.txt nonsense) and has a much more solid type system.

If you don't care about that I would go with one of: Rust, Go, Kotlin, Dart or C#. All better options than Python.

> why is this stuff almost always Python-based?

Because schools teach Python...

> but it is dynamically type checked,

There is a difference between type safety and dynamic vs static type checking. Static checking is actually more difficult to generate safe code.

> compiled languages produce better, more performant code,

It depends on the compiler/VM. For example taking a VM snapshot and saving it as a binary actually makes the program slower as it can not take advantage of runtime optimizations.

> and allow for application stability and longevity much more easily.

You could statically link an app and it would live through breaking changes in libs. But if there is an architecture or kernel breaking change your binary wont work at all - meanwhile a VM based language would work if it has support for the new architecture.

> Python may be your favorite language, and that's fine, and that alone doesn't immediately qualify it as a good choice for anything,

The best language is the language you know best. You will have to be a specialist programmer to know many languages so well that you could choose the best language for the job. And most languages are general purpose languages.

Arguments aside. My interpretation of the article is that the author thinks it should be as easy as python, not that Python itself should be printed into hardware.

> There is so much evidence all around us that statically type-checked, compiled languages produce better, more performant code, and allow for application stability and longevity much more easily.

Does any of this evidence address how those characteristics affect company or product success? (There are lots of failed products written in statically type-checked compiled languages.)

They've shipped. We'll find out if it is good enough.

That said, it is already better than everything that hasn't shipped, no matter what language was used to implement those other things. Maybe they can catch up, but they are behind.

Agree that the best tool for the job should be used. In this case if python is gluing together different technologies to get this working it might have been the best tool for the job. Generally I would rather have my code compiled (into silicon in this case) be fast, even if it means the compiler itself is slower.

how about the person building the thing gets to choose their tools

I agree, Python is an absolutely terrible choice here (MyHDL made the same mistake). Still it could be worse. Most of the EDA world is still heavily built on TCL!

Reply on news.ycombinator.com