HackerTrans
TopNewTrendsCommentsPastAskShowJobs

gsmecher

no profile record

Submissions

Awaitless: Ipython and REPL and Coroutines – Suffering

github.com
3 points·by gsmecher·vor 2 Jahren·1 comments

comments

gsmecher
·vor 4 Monaten·discuss
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...
gsmecher
·vor 4 Monaten·discuss
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.
gsmecher
·vor 5 Monaten·discuss
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.
gsmecher
·vor 9 Monaten·discuss
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.
gsmecher
·vor 9 Monaten·discuss
Oh my - good find, and also, eek.

Analogy: https://datasheet.lcsc.com/lcsc/2302211830_analogysemi-ADX11...

TI: https://www.ti.com/lit/ds/symlink/ads1115.pdf

Analogy's datasheet is directly cribbed from TI's (see TI Fig. 7-7 / Analogy Fig. 22½, pg. 18).

This already passes my "run away screaming" threshold for trust, but a decapping would help me understand whether they've stolen the physical design (bad) or just cloned it (bad).

See also: https://community.element14.com/members-area/f/forum/53365/n...
gsmecher
·vor 2 Jahren·discuss
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.
gsmecher
·vor 2 Jahren·discuss
I've pushed a couple of boulders up this particular hill, and none of them have stayed there.

Trouble is, Python is a great stack for communicating with networked instrumentation - except when asyncio gets involved. And, talking with devices over a network is a picture-perfect use case for asyncio.

My last attempt was "tworoutines" [1], which tried to marry async and sync functions under a common wrapper. At the time I wrote it, it was clear tworoutines ran contrary to the direction Python was taking asyncio. Without nest_asyncio [2], It was fairly brittle and has become more brittle over time. The primary developer for nest_asyncio unfortunately passed away earlier this year.

There is a long discussion here [3, 4], including representation from Python higher-ups as well as other people writing instrumentation/science software. In other words, it's not just us.

[1]: https://github.com/gsmecher/tworoutine

[2]: https://pypi.org/project/nest-asyncio/

[3]: https://bugs.python.org/issue22239

[4]: https://github.com/python/cpython/issues/66435
gsmecher
·vor 2 Jahren·discuss
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.
gsmecher
·vor 3 Jahren·discuss
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.
gsmecher
·vor 3 Jahren·discuss
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.
gsmecher
·vor 3 Jahren·discuss
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.
gsmecher
·vor 3 Jahren·discuss
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.
gsmecher
·vor 3 Jahren·discuss
> 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.
gsmecher
·vor 3 Jahren·discuss
According to a Reddit comment [1], this is the same MicroBlaze RTL with a RISC-V instruction decoder in front of it. This seems crazy from a let's-make-the-best-RISCV-core perspective, but that's never been Xilinx/AMD's goal.

MicroBlaze has always been a great example of a boring in-order RISC CPU in a boring niche. For an FPGA vendor, soft cores are loss leaders: they sell silicon but don't make money on their own. They are also boring technology: they are "integration glue", and don't belong in the portion of the FPGA that drives performance. "Good enough" is good enough.

If AMD really is reusing MicroBlaze RTL, then they're able to keep their existing firmware (core, FPU, debug, peripherals, etc) and software (HAL, compiler, drivers). These are all highly desirable from the perspective of the vendor, and any users looking for a painless transition to the new MicroBlaze core.

1: https://old.reddit.com/r/FPGA/comments/17mdcyt/microblaze_go...
gsmecher
·vor 3 Jahren·discuss
> Depends on what AMD does with Xilinx.

Currently the AMD/Xilinx dynamic seems to reverse this: "Depends on what Xilinx does with AMD".

AMD's software roadmap for AI/datacentre leans heavily on Vitis (for software) and AI Engines (as an execution platform). CPUs that integrate AI engines are already shipping (Ryzen AI). It's Xilinx technology, but you should expect it to look more like a GPU accelerator than a traditional LUTs-and-routing FPGA. And, as duskwuff have pointed out, this sucks a lot of the oxygen out of the CPU-with-FPGA design space.
gsmecher
·vor 3 Jahren·discuss
The integrated Ethernet switch is only as useful as its software stack - I say this after an excruciating decade with TI's Sitara devices (and the built-in CPSW ethernet switch.)
gsmecher
·vor 3 Jahren·discuss
On FPGAs, a register file probably fits better into distributed RAM than block RAM.

On Xilinx, for example: a 64-bit register file doesn't map efficiently to Xilinx's RAMB36 primitives. You'd need 2 RAMB36 primitives to provide a 64-bit wide memory with 1 write port and 2 read ports, each addressed separately. Only 6% (32 of 512) entries in each RAMB36 are ever addressable. It's this inefficient because ports, not memory cells, are the contented resource and BRAMs geometries aren't that elastic.

A 64-bit register file in distributed RAM, conversely, is a something like an array of DPRAM32 primitives (see, for example, UG474). Each register would still be stored multiple times to provide additional ports, but depending on the fabric, there's less (or no) unaddressed storage cells.

The Minimax RISC-V CPU (https://github.com/gsmecher/minimax; advertisement warning: my project) is what you get if you chase efficient mapping of FPGA memory primitives (both register-file and RAM) to a logical conclusion. Whether this is actually worth hyper-optimizing really depends on the application. Usually, it's not.
gsmecher
·vor 3 Jahren·discuss
> What's your issue with Shockley btw?

Nobody can pick fights with Shockley any more (he's dead) - but Shockley is almost a household name, and Bardeen/Brattain's aren't. It's worth trying to adjust the record, both because Shockley was an abusive jerk and because he gets more credit than is due for the transistor.

(I'm not denying that Shockley was brilliant and effective.)
gsmecher
·vor 3 Jahren·discuss
> everything comes down to datapath.

Ain't that the truth.

However: Xilinx's DSP58 blocks (Versal devices), and older Intel DSPs, do integrate floating point into the DSP tiles - which does narrow the gap between the datasheet's DSP count and the number of floating-point operations achievable per clock.
gsmecher
·vor 3 Jahren·discuss
Also discussed here: https://old.reddit.com/r/FPGA/comments/15fnb6u/egpu_a_750_mh...