On Tue, May 28, 2019 at 10:46 PM Ricky Teachey email@example.com wrote: >
I don't want to pile on, but: you have also not given any actual reason why overloading the = operator using descriptors:
stuff.a = 8
...is not sufficient, other than a general "well I don't like that". Come on, guy. If you can't give a real actual reason why that won't work for HDL programming, you can be sure as heck nobody is ever going to listen to your idea of changing the way the language behaves.
Have you even attempted to write a descriptor that handles the assignment of signals the way you want and tried it out for a bit?
Yes I have, and none of them working in a way that can easily reflect the hierarchical nature of hardware design.
Suppose you have class A and class B, and a third class C want to use class A and B, the very natural way that all hardware engineer would construct this is like below:
class C: def __init__(self, in, out, ...):
# suppose A has one input and two output, B has two input and one output # so A and B can be chained together sig0 = signal() sig1 = signal() a = A(in, sig0, sig1) b = B(sig0, sig1, out)
Descriptor does not work as a local variable, it does not even work if you instantiate it in the __init__() function, it has to be declared as a class attribute for it to work. And when you passing it around, it will not work, unless you pass class C's self around ... which is really not pleasant to read (I had this example already in previous postings).
If anyone could teach me how to do hardware hierarchical design as elegant as in verilog or Chisel, I'd be happy to use it. What I see is, myhdl is using signal.next = something, cocotb is only for verification so ... not really relevant. In short, I haven't found any evidence out there that this can be done naturally (e.g. as in verilog or Chisel). You can argue that why do I even want to define verilog/chisel's way is the natural way, well, this is I believe the common understanding in hardware design community, and this is the reason why new HDL like Chisel choose Scala to implement exactly the same thing. But anyone who could propose a even simpler syntax that can describe the same thing with less chars I'd definitely be happy to take it.