On 26 May 2019, at 08:07, Yanghao Hua email@example.com wrote:
On Sun, May 26, 2019 at 12:04 AM David Mertz firstname.lastname@example.org wrote:
I don't really understand HDL/Verilog, but I've worked with people who do. In fact, I even wrote a pre-processor that transformed the same DSL to Python, C++, and Verilog.
In my mind, the HDL use case is FAR too narrow and specialized to warrant a new arrow operator, let an entirely new parser and semantics around arbitrary operators. There are several existing dunders that could plausibly be repurposed already (<<, <<=, <=, etc). Those might look sightly different than the verilog operators, but that's a very small price. In fact, just using attributes and assignment is an incredibly low bar too, and allows whatever overriding you wish.
Well, depends on how we define narrow ... you are writing probably this email on a HDL designed machine ... and the entire world is powered by HDL designed silicons. that is not small for me at all.
I think you are confusing the number of people that use HDL with the amount of product created.
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?
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.
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?
I just don't buy the idea that such a DSL can only be useful if it spells 'abc <== message' and useless if it spelled the same thing as 'abc <<= message'.
So you don't find this is confusing?
signal <<= 5 # does it mean left shifting signal or assigning 5 to signal??
I really do think it is confusing.
Isn't that a matter of familiarity with HDL? Many people replying are not familiar with HDL.