On Sun, May 26, 2019 at 8:00 PM David Mertz firstname.lastname@example.org wrote: >
On Sun, May 26, 2019, 1:12 PM Barry Scott email@example.com 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 @/@=.