HN user
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.
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...
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'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/
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.
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...
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.
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.)
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.
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.)
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.
Also discussed here: https://old.reddit.com/r/FPGA/comments/15fnb6u/egpu_a_750_mh...
Project X-Ray [1] and Project U-Ray [2] are the best source for configuration details that Xilinx/AMD doesn't publish. These projects focus, respectively, on the 7-series and UltraScale FPGAs.
[1] https://f4pga.readthedocs.io/projects/prjxray/en/latest/
Interesting. If you ever do track down the scuttlebutt on poor-performance internal regulators, please pass it along? I'm not terribly hard to find.
On the mystery voltage regulator: most OCXOs also provide a regulated reference output on the pin that's marked N/C on this device. This reference is important because the tuning voltage is scaled relative to some reference voltage, and a modulation in that reference voltage can be seen as an out-of-phase modulation in the tuning voltage. Hence, bringing a pristine reference out of the oven is the cleanest option. Second best is to place an external regulator close to the oven, as they've done here.
...at least that's my best guess.
The software/firmware/hardware stack is layered. Here's what has worked for me, for several FPGA-based instrumentation applications.
* 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.
Note that you can't compare LUT4 results (ZPU @ 440 LUTs) against LUT6 results (PicoRV32 @ 750 LUTs). The ZPU is remarkably small, and it's a bigger gap than a direct comparison shows.
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 ZPU may be smaller than you're crediting. 440 LUTs is very little space.
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.)
It is wonderful to see open-source tooling continue to invade the EDA space. Two pieces of context for non-practitioners:
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.
As someone who's manufactured thousands of PCB designs, I couldn't disagree with this article/video more.
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).
My best-in-class example of document management is Xilinx (now AMD). Internally, they use an XML flow based on DITA - but the specifics aren't nearly as important as an apparent organizational commitment to delivering quality documentation. (They hire technical writers - these job postings are how I've gleaned most of the details about their documentation toolflow.)
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.
I don't think this is true - on Xilinx, you can coax a DSP48 macro into implementing a barrel shifter, but the underlying primitive is a multiplier and not a barrel shifter.
Unlike adders, a barrel shifter does not generalize well enough to be implemented as a hard block in its own right.