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')
> 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.
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.
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.
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.
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/...
Btw, what do you recommend instead of Python?
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.
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.
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.
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.