On Sun, May 26, 2019 at 8:00 PM David Mertz <me...@gnosis.cx> wrote: > > On Sun, May 26, 2019, 1:12 PM Barry Scott <ba...@barrys-emacs.org> wrote: >> >> You said this: "Well, depends on how we define narrow ... you are writing >> probablythis email on a HDL designed machine ... and the entire world is >> powered 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. > > > I think the analogy is more like saying there are billions of Verilog users. > Chips designed using this software are probably more numerous than are human > beings, and nearly all humans use one or more such chips. This seems like a > poor line of reasoning though. There are really only maybe tens of thousands > of people in the world who use Verilog, and that is a nice target.
Thank you. It is definitely more than tens of thousands. I count only the 20 big names and it is already at least tens of thousands. All in all it should be a few millions. We should argue really from technical point of view, in the spirit of python, if this is worth or not rather than saying HDL is just too small a problem to address. > Pursuing the same indirect reasoning, we could also claim there are billions > of users of PSS/E, something I had not heard of until a web search a few > minutes ago. Apparently this is software used in design of electrical > distribution systems, required to make all of those ICs operate at all. Or > software used for building the construction equipment needed to construct the > power lines and factories where chips are made. Or... You know, Python and C are very close friends and operates almost like natively together and you have things like Cython to ease the creation of C-Python interface. If we look at the problem of building any complicated piece of hardware, it almost certainly done in this way: (1) C algo model -> (2) Virtual Prototype in SystemC (qemu-like software model but with proper partitioning of sw/hw, hw is still kind of a C model) -> (3) Verilog RTL model (Yes, RTL is actually just a model too, which is easier to be translated to actual hardware implementation). At each of the levels, it is a end-to-end complete system, and yet in each level, there are a lot of things duplicated, re-developed and eventually extremely difficult to have consistency. The big picture I want to achieve is to replace those (1)(2)(3) with Python + C -> Python + C -> Python + C. Where the interface between each layer can be easily unified through adapters and 99% of the knowledge only need to be developed once (if it is developed in C there will be a python interface). > In any case, as I said, modifying the whole Python language to allow use of > exactly the same symbols as Verilog users, seems foolish to me. Agree, that would be foolish. I would just ask for any way that overloads assign but not messing up existing operators (think of HDL signals as integers). > That said, '<=' is already perfectly well available for non-blocking > assignment. '=' cannot be overriden, but it occurs to me that a custom class > could perfectly well use '==' for blocking assignment just by customizing a > class. Yes, that would require 'foo.eq(bar)' for the old meaning of equality > (or something similar), but it seems like assignment is more common than > equality checks in Verilog. Not really, HDLs uses <= as less or equal than, as well as the equality check VERY VERY often. The sad thing is when I went through the entire python supported operators they can all be used with signals ... including the matrix operator @/@=. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
