On 5/30/19 4:09 AM, Yanghao Hua wrote: > On Thu, May 30, 2019 at 12:50 AM Greg Ewing <greg.ew...@canterbury.ac.nz> > wrote: >> Steven D'Aprano wrote: >>> Yanghao Hua wants to customise the behaviour of assignment. I believe >>> that he wants to emulate the behaviour of some hardware description >>> languages, where the equals sign = doesn't mean assignment (if I have >>> understood correctly, which I may not have), but Something Else. >> Maybe I can help a bit here. I don't have a deep knowledge of HDLs. but >> from what I gather, they typically have two *different* assignment-like >> operations. One of them is like assignment in a functional language, >> where you're defining a signal as a function of other existing signals. >> This corresponds to combinatorial logic in hardware. Python's existing >> assigment is fine for this, I think. >> >> The other represents updating a signal when some event occurs, such >> as a clock transition. In hardware terms, it corresponds to changing >> the state of a flip-flop. The OP wants a new operator and associated >> dunder method to represent this operation. He doesn't want to override >> normal assignment. > That's basically right. And three small addition/correction: 1. > Actually combinational logics can be modeled with both blocking and > non-blocking logic. So one of them is enough already. 2. python's > assignment is having very different semantics, so even for the verilog > blocking assignment, which need to make the current "thread/process" > to wait until the assignment finishes, is still not possible to model > with python's assignment operator. 3. the signal change is really > modeled on gate level, which are AND/OR/XOR/MUX gates. There are > optimized flip-flop entities too but basically you can also build FFs > from the primary gates. And the change of the signal, is actually just > change the input of the FFs, not really the FF states itself. FF state > change is modeled and inferred with a sensitivity list (a list of > signals which triggers a thread/process to run) that has a clock. > 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: x<= y; y <= z; or 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) 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, and these mostly work as long as you started off remembering their restrictions when you started writing the original program. To expect 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. 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: hardware,run() 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. -- Richard Damon _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
