On Thu, May 30, 2019 at 12:56 PM Richard Damon Richard@damon-family.org wrote:
As someone who does hardware design with HDLs, I would say that to think that it would be easy to recreate the abilities of them in a 'conventional' programming language doesn't really understand at least one of the languages, as there is a SIGNIFICANT difference in there fundamental mode of operation.
The one key thing here is that with non-blocking assignment, the order they are written is totally not important. I can write:
y <= z;
y <= z;
x <= y;
( <= is the non-blocking assignment operator in verilog), and in both instances get exactly the same result, namely that x gets the value of y BEFORE either of those statements occurred. Basically, all the non-blocking assignments happen in parallel through the whole design, and when that assignment happens is controlled by the context of where that assignment is written (it might be conditioned on a clock edge, of by an if statement to only happen when some other combination of signals occur)
This is really the basics in school times and actually MyHDL and my private HDL does implement exactly this in Python. I do not see why this is taken as a major thing even, this is how HDLs work to model/mimic real hardware behavior and is very straightforward to implement in any programming language.
There ARE programs that will take a HDL program and convert it into a conventional programming language, and other programs to take a design written in a conventional programming language and convert it to HDL,
Verilator, Synopsys VCS translates HDL into C/C++, which is still basically simulating the HDL design, it is not converting it to a higher level functional equivalent. Converting conventional programming language to HDLs is called high level synthesis (HLS).
and these mostly work as long as you started off remembering their restrictions when you started writing the original program. To expect
HLS started to be widely used too, but as you said HLS has a lot of constrains and was never really straightforward.
that you could get anything similar by just defining a few operators to deal with thing in a special manner seems unlikely. I think that I personally would have a hard time understanding a program written where many of the assignments behave sequentially like is normal in a conventional programming language but many other behave concurrently as in HDL.
Absolutely right and nobody would want to mix pure software constructs with hardware constructs. Please take a look at Chisel build on top of scala. I want to build a HDL in Python, not a HLS for Python, and you could use meta classes/decorators to actually restrict what uses can do and even looking the user code as raw AST to further process it (there are people doing this already). The end result is then a domain specific language.
The operator thing is to make HDL description in python is at least as clean/elegant (as well as easier implementation if you followed the discussion w/ descriptors) as in Verilog or Chisel.
I would think it would be much clearer if you wanted to simulate the action of hardware, to first have 'definition' stage where you defined the interconnection of the signals within a system (and here you would naturally be dealing with methods and attributes of some object that represents the hardware system), and then after defining that, using some method to 'run' that hardware. Thus having the above be written as
hardware.x = hardware.y
hardware.y = hardware.x
and then later:
where the attribute assignment recorded the interconnections and the run did them. I think this is all possible currently in Python where hardware is an object of an appropriatly written class.
I do not understand this part entirely. What is the difference of designing hardware in Python and simulating hardware in Python? We are not discussing using Python to build a virtual prototype for software to run, though I did implement such a thing many many years ago. We are talking about using Python to really build VLSI down to its bare bones, gates, flip-flops (combinational & sequential logic).