gsmecher

If AI does anything to the EDA space, I hope it helps break the chokehold the "big 3" have on tooling. Any startup that threatens their dominance gets acquired and disappeared.

I also hope this is coming anyway (see e.g.: KiCad nipping at Altium's heels, and Verilator's recent progress). There is just so much more to do, though...

I love that VHDL formalizes Verilog's pragmatic blundering, but emphasizing delta-cycle ordering is "inside baseball" and IMO bad marketing. VHDL's approach is conceptually clean, but from a practical perspective, this ordering doesn't (and shouldn't) matter.

Better to emphasize the type system, which make a durable and meaningful difference to users (both experienced and new). My go-to example is fixed-point arithmetic: for VHDL, this was an extension to the IEEE libraries, and didn't require a change to the underlying language (think of how c++'s std:: evolves somewhat separately from compilers). Verilog's type system is insufficiently expressive to add fixed-point types without changes to the language itself. This positions VHDL better for e.g. low-precision quantization for AI/ML.

In any case, the VHDL/Verilog language wars are over, and while VHDL "lost", it's clear the victory was partly Pyrrhic - RTL probably has a polyglot future, and everyone's waiting (with mixtures of resignation and hope, but very little held breath) for something better to come along.

Towards the end of my EE degree in the mid-2000s, I hoodwinked Ralph into dropping by my dingy east-Vancouver rental for a tech demo. I was trying to find a home for my thesis research project, which was a very niche-y DSP algorithm that had only the very faintest relevance to Xiph's mission. I was 100% enthusiasm and 0% practical sense.

Ralph was interested and engaged, and when he turned down the project (absolutely the right call) he was beyond gracious about it. It is rare that you can call someone "classy" and "nerdy" at the same time. Ralph was it.

There's nothing wrong with an open clone when everybody is acting in good faith. (In fact, "good faith" does not even necessarily mean "according to the letter of the law in $jurisdiction". Sometimes the law is an ass.)

However, there's nothing more toxic to an OEM than a vendor relationship founded on dishonesty. I know I shouldn't trust them, they know it too, and even if it seems advantageous at first I shouldn't be surprised when they turn on me.

Since these parts are being sold as genuine TI parts, I don't care whether the clone is physically faithful or just functionally faithful - I should treat it like it's poisonous.

These experiments are always unique, and each is interesting in its own way.

Can you comment on the use of asynchronous code rather than generators? For example, here's a throw-away example of a clock using generators and a syntax that's otherwise similar to yours:

  from more_itertools import take
  
  def drv_clock():
      while True:
          yield "1b1"
          yield "1b0"
  
  for x in take(10, drv_clock()):
      print(x)

I have written signal flow graphs (including feedback) using a generator-style approach, intended to prototype datapaths that are then manually translated into RTL. It's different, but not completely different.

You should talk with Metrics (metrics.ca), who are walking a similar path and have a few years' head start. They are a solid team and are likely to be open and friendly about their direction and challenges. Metrics has an independently developed mixed-language simulator that claims decent standards compliance with both VHDL and SystemVerilog. It's an impressive feat that puts them in a different class from Verilator (for now - Verilator is moving fast these days, thanks to Antmicro's excellent work.)

In my opinion, the extraordinarily poor design productivity associated with RTL designs is unlikely to change much until we can change the languages themselves. Yes, EDA vendors' tendency to extract maximum revenue for minimum tooling is a cherry on top, but solving that problem alone does not resolve the underlying productivity crisis.

For example: when I implement a complex datapath in VHDL, I become responsible for verifying every nook and cranny of both the signal path and the scheduled design that implements it. If I can effectively do design entry in HLS, I no longer need to verify the scheduled design by hand. That's a very big win.

The "language wars" narrative feels pretty played-out, so I'm not going to get drawn into it. In the software world everyone seems to recognize that different languages have different strengths, and that there's room for more than one. I'd love to play to the strengths of each language (example: SystemVerilog for verification; VHDL for fixed-point DSP).

A polyglot HDL world is elusive because simulator vendors insist on charging incrementally for language support, and open-source tools fall into either camp Verilog or camp VHDL. This is just another thing to lament.

From 2020. This article is hagiography - while it's worth celebrating how far HDL has come, it's also worth looking into what's holding us back. Verilog is one of those things, so here's a short complaint.

Modern Verilog/SystemVerilog is profoundly hobbled by Verilog's origins as a loosely typed, ad-hoc language (think: Perl, MATLAB, or on an especially rough day, PHP). It has evolved in a committee-and-footgun-rich way reminiscent of C++ - to the point that the article ends by admitting "[i]t is difficult if not impossible for any one engineer to be fluent in the complete language." The language is simultaneously too simple and too complex.

I write VHDL where I can, am hopeful about Clash/Chisel/Lambda, and am optimistic that efforts like CIRCT can replace Verilog in its weird role as machine-produced and machine-digested RTL. In the meantime, though, I don't think Verilog's supremacy is something to be celebrated uncritically.

Xilinx/AMD doesn't make overt donations any more AFAIK, but they still subsidize hardware as a loss leader and for academics. For example, academic groups can buy the RFSoC 4x2 board for $2149 USD, which is a small fraction of the volume price of the chip that's on it.

"EDA software is crap" is so close to an axiom around here that I think Vivado doesn't get the credit it deserves. The synthesis flow has been rapidly modernizing and supports a chunk of VHDL-2019. The bundled simulator still lags on support and features, for reasons that are pretty easy to understand.

I posted the Reddit link because it wasn't my insight - but I agree it's a dubious source. That doesn't make it wrong. (I'm not certain it's right, either - it's an interesting claim.)

A RV32I core is easy to implement from scratch, but Microblaze-V already has a single-precision FPU, and it will need an MMU to reach feature parity. It's much bigger than a weekend project to produce a RISC-V core that's feature-matched with MicroBlaze.

> This is dead right, the enabling technologies like

You fundamentally misunderstand. Soft core CPUs aren't enabling technologies and haven't been for decades. They are plumbing, like FIFO or SERDESes. You can't sell an FPGA into most markets without them.