On Sun, May 26, 2019 at 11:27 AM Barry Scott <firstname.lastname@example.org
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.
You said this: "Well, depends on how we define narrow ... you are writing probablythis email on a HDL designed machine ... and the entire world ispowered by HDL designed silicons. that is not small for me at all."
Which I take to mean that because there are billions of chips in the world there are
billions of python users. And the change you want is justified by the billions of python users.
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.
There is a reason that there are 1,000s of computer languages in the world.
Not all computer languages are able to solve all problems.
If Chisel or Scala is closer to what you want why are you not using them for
your HDL tools?
And what is the problem python solves that C doesn't solve?
is the problem C solves that assembly doesn't solve?
One common answer
to all of them would be: fewer chars for bigger ideas.
What has that got to do with justifying a change to the python language?
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
And it seems that you have hit a major problem with the HDL syntax not mapping to python.
Maybe python is not the right choice?
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 ...)
Packages like numpy are not written in python for a reason. A pure
python numpy would be very slow. So yes we worry about run time speed.