274 karma · joined November 20, 2018
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...
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.
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.
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.
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...
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)
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/
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.
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.
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.
"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.
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.
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.
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...
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.
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.
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.)
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.
[1]: https://f4pga.readthedocs.io/projects/prjxray/en/latest/
...at least that's my best guess.
* Integration level: this is typically Yocto or Buildroot. It's architected to want its own repository, and should diverge from "upstream" repositories as little as possible (except for, basically, whatever configuration files tailor the build to your application.)
* Hardware design (PCB tools): Altium, at least, comes with its own Git integration and wants to control the entire repository. I have kept PCB designs separate from other SCM tooling and haven't found it to be too problematic. I think KiCAD is the only tool where I'd even consider combining the schematic/PCB with other stuff, since it uses a text-oriented storage format and doesn't try to micro-manage the SCM flow.
* Firmware (software and RTL) that's closest to the hardware/software design boundary: I really do want these to live in the same repository, so that it's easy to make changes that span the hardware/software divide. I would also argue that corresponding detailed design documentation lives here, too, since it incentivises documents to be maintained like source code, rather than as a grudging afterthought. Only source code is checked in (no build artifacts, no binaries - these would be a constant source of merge conflicts otherwise.)
* User-facing interface code: for me, this is a Python API and access to pre-built firmware releases. These live in a single git repository for user convenience. Firmware images are kept using git-lfs (and are --excluded by default .lfsconfig to keep new clones reasonable.) This has worked very well.
SERV is a fair comparison, since it's architected for 4LUTs and I suspect the synthesis results come from iCE40 tools.
I have a contender in the "very small" space, too [1], although I don't claim it's as mature or complete as SERV. (If Minimax was excluded from your post on the basis of insanity, I'm OK with that.)
The reported synthesis results ("440 LUTs") are on old Spartan-3 fabric. These are LUT4s, and anything from Xilinx newer than about 2006 uses much more capable LUT6s. Hence, it's unfair to compare these figures directly. (Comparing against ICE40 fabric is better.)
First: the "slow" part of an HDL toolflow is synthesis/place-and-route, not elaboration or translation from an HLS into Verilog (which is discussed here). It's not even close: synthesis/P&R times for complex designs are measured in hours. Even complex HLS elaboration/translation (e.g. where scheduling algorithms are involved), it's a much simpler, smaller computational problem than synth/P&R.
In other words: this work does not aim to make FPGA development look like software development. As the authors point out, it's most relevant for simulation toolflows, where synth/P&R are not involved anyways.
Second: there are several reasons synth/P&R flows do not fully make effective use of multiple threads. These reasons are just as applicable here. One critical factor is repeatability: to whatever extent work can be parallelized, the results must stay identical run-to-run - otherwise the design outputs change even when the input HDL doesn't. EDA vendors are very careful to prevent (or limit) this variation because their biggest clients insist on it.
It's not clear whether this paper (discussing elaboration) considers repeatability or not. To pick an example: if an HDL translator needs to generate a new net or instance name in one thread, it cannot race with another naming allocation on another thread except on a completely different piece of code - otherwise, net or instance names will not be repeatable run-to-run. (Even the order of generated code needs to stay consistent run-to-run - even if a permuted order is just two blocks of text changing position with no semantic difference.) Serializing around every possible race is obviously a huge buzzkill for parallel performance, unless the problem can be consistently partitioned so these races don't occur.
Normally, the synth/P&R flow gets all the attention - I view the authors' contribution primarily as a way to accelerate simulation and chip away at Verilog's rather ratty position as a machine-generated IR. Both of these are excellent places to be focusing and I'm delighted to see papers like this.
I think you're vastly overstating how much "bad" advice there is in the video, and the degree to which aesthetics are opposed to function. It is possible to get silly (e.g. luridly coloured PCBs, "artistic" routing, and silkscreen-as-canvas), but this video doesn't push very hard.
Phil mostly stresses attention to consistency in placement, routing, and silkscreen, which is 100% solid. A PCB layout is like a schematic: it's read far more than it's written, and efforts to make it legible and coherent have an excellent payoff/effort ratio. Efforts here make bring-up, rework, debugging, and overall comprehension easier for the EEs involved. They also make the design more accessible to non-EEs, which fosters collaboration with mechanical/thermal, assembly, debugging, etc. They may have minor impacts on cost and manufacturability, but the right compromises are usually obvious if the knowledge is there.
There is a design sensibility for PCBs that combines form and function without compromising either. Most experienced EEs can tell with a single glance whether a board was laid out with care by an experienced practitioner or not. I find good PCB design to be beautiful by construction, in the same way that good architecture is beautiful by construction (and not by slapping lipstick on a pig).
In my small team, our solution has been:
- Commit to PDF as a documentation mechanism. Trying to co-maintain HTML and paginated outputs is too challenging.
- Maintain and track documentation in the same infrastructure as source code. For us, this means git and AsciiDoc (formerly, LaTeX). Asciidoctor to PDF via XSLT is crufty and slow but looks good enough and addresses most of our "wants" (table of contents, list of tables, list of figures, glossary, ...).
- Try to keep documents consolidated in relatively few repositories. A project-wide repository allows documents to share content (e.g. images) and encourages a coherent, consistent document tree.
- Provide a (hair-shirted, Makefile-based) mechanism to publish updated PDFs of these documents. Having a centralized publication site is critical, since it teaches people where to look and allows us to control document review/release cycles.
Purpose-built documentation management systems (e.g. Alfresco) might seem be better tailored towards documentation and might play nicer with Word, but it also keeps documentation in a ghetto and allows people to abandon it. Less is more.
Unlike adders, a barrel shifter does not generalize well enough to be implemented as a hard block in its own right.