On Sun, May 26, 2019 at 11:27 AM Barry Scott
I think you are confusing the number of people that use HDL with the amount of product created.
I don't see how I did that but if you intercepted that way I must have done that somehow.
Also I was under the impression that HDL tools exist already that are considered usable and yet do not need python.
What is the problem that you aim to solve with a python HDL tool?
I think the question should be which part of existing HDLs does not need to be fixed? The answer would be easier: the assignment syntax is pretty elegant. I would recommend to take a look at Chisel, all the motivations for creating Chisel is pretty much the same reason I would create a python equivalent and I had a prototype shows in some area it could even be better. And what is the problem python solves that C doesn't solve? And what is the problem C solves that assembly doesn't solve? One common answer to all of them would be: fewer chars for bigger ideas.
If the syntax of the HDL is so important I do not understand why you do not write a parser for the HDL and build the run-time model in python. Then run the model - no new syntax required.
Many many people and company did it already ... I am just exploring a different possibility.
For any non-trivia hardware I'm finding it hard to believe that python will run fast enough to be useful. What is it that I'm missing?
We are all Python users and we start to worry about running fast? really? ;-) I thought we all understood development time matters (if not even more ...)