mng2
I was too intimidated to take the honors series in undergrad but I sat in on one lecture and was totally lost in a room that seemed to be nodding along with the preacher, so to speak. From the syllabus I found out they used K&K, so I asked my father to buy it for me so I could study it at my leisure.
At the end of one of the first chapters there's a statement about how we can trivially extend the equations of mechanics to three dimensions. It blew my mind at the time, but after spending enough time studying physics, I am in agreement.
I'm skeptical that these pixelated structures are going to turn out anything better than the canonical shapes. They look cool but may just be "weird EM tricks", deconstructing what doesn't really need to be. Anyone remember the craze for fractal antennas?
https://github.com/mng2/AcornHDMI
Even with the fastest speed grade Artix, 1080p output is technically out of spec, but it seems to work OK.
As you might guess I had/have my own ambitions of making a video card. The software side has been a source of dread for me, but with OP's tutorials I may have enough guidance to get back to it.
I'm not that familiar with OCP but certainly driving commodity hardware costs down is a valid object. My interest is more in specialized hardware at the board level. I believe CERN and other high-energy physics labs collaborate on designs, but I've been out of the field for a long time. Much of that sort of hardware doesn't have use in the industry at large; historically speaking, if there is demand, the model has been to spin out a small company to sell equipment to other labs.
The only category of core with what I'd call a big open-source impact is RISC-V processors, as you mentioned above. This is because a small processor is often useful on a non-SoC FPGA. But there were already free-as-in-beer microprocessors available from the FPGA vendors, so RISC-V adoption is really more of a political/philosophical choice.
When people talk about someday having an OSHW scene approaching the vibrancy of the FOSS scene, I'm not so sure there are parallels. People talk about having open tooling, but the existing tooling is already free-as-in-beer (for the device types most people could afford, anyway). The cost of the vendor IPs is already baked into the cost of the device, so you'd still be paying for it. The argument is that open source tools will be easier to use, but I haven't found that to be the case at this point in time.
I think that hardware is just a fundamentally different medium from software, and attracts different kinds of people. It's a comparatively smaller crowd, who tend to be lone wolves. Maybe someday there'll be a critical mass.
>what do you _do_ with the cores?
I mean, this is kind of the problem, but in a way it's a funny problem. The strength and the curse of FPGAs is that they can become almost anything you want. However getting that sea of logic into the desired form requires knowledge of the FPGA family, the tools, the hardware, and digital design in general. The "tedious stuff" unfortunately makes up a great deal of FPGA work! Many days I feel like a glorified plumber...
As far as cores go, in FPGA land, the vendor would probably already provide a core (IP, in hardware parlance) for say fooing bars, that is easier to use and probably a far sight more reliable than the project on OpenCores. (Which probably hasn't been touched in a decade, is written in VHDL-87, is using Wishbone when you want AXI, and lacks a test suite.)
As a hobbyist, you might search and find the project on OpenCores, but be scared away by the cruftiness. You then write your own foo_bars module, thereby learning a great deal, but contributing to the fragmentation problem. Plus seeding the internet with weird code with corner-case bugs for LLMs to trip over.
In recent years I've gotten better about hitting the library first instead of buying books. It imposes a natural deadline on things: if you couldn't be bothered to start reading in 3 weeks, then maybe it was just a passing fancy.
Getting older helps too. I feel like I have less energy, which needs to be spent more carefully. But there's also perspective that comes with maturity, and the willingness to forgive myself for not being maximally "productive".
If you don't have any digital design experience, an oft-recommended course is nand2tetris.
I should say though, that that is the bottom-up approach. It is possible these days to string together a bunch of IPs and not write any HDL, depending on what you want to do. But you will probably be stuck if anything at all goes awry, so I don't recommend the top-down approach.
Purcell is a physics book, but I think with your math background it might be fine? From there I'd suggest Griffiths E&M, as far as setting up more complicated problems goes. I don't really like the EE-oriented E&M books, but if you need some of the "calculate this value" style of problem maybe you'd want to take a look at them.
Circuit design is kind of unsatisfying these days since on the professional side there's a lot of throwing stuff in the simulator, especially with IC design. I'm an advocate for more hands-on stuff. For the absolute basics I feel there's no substitute for getting some LEDs, resistors, breadboard, and multimeter, and doing some kid level projects. Then there's audio projects, and RF projects, since once you've learned the textbook fundamentals of amplifiers, there's no substitute for building some. Pozar and the ARRL RF project book will take you a long way, though you'll have to buy some test equipment...
But honestly, do you really want to get distracted from your main focus? You may have lost interest by the time you're done with the curriculum. There's a lot you can get done by forging ahead and just learning what you need to as you go along. Why learn amplifier design when the industry is all too happy to sell you a black box gain block? Why learn digital design when microcontrollers are getting faster and cheaper all the time? ;)
At today's price of $50 it might be cost effective to do as you say, but I imagine there's not a huge market.
Technology moves so fast that perhaps tech patents should be given shorter terms. As it stands, the big companies just build up huge patent portfolios which discourage competition.
What is the thinking behind this? Build it and they will come?
Shrinking isn't always a walk in the park though. Some nodes ago subthreshold leakage became a big problem until they figured out how to solve it.
I don't drink much wine so I have bottles in the fridge that have been there up to a year. When using the gas, I think the decay is more related to how often the bottle is opened and poured. So a bottle that I gas-treat after the initial opening seems to be happy to sit for quite some time. Subsequent treatments are not as effective.
It costs time and effort to translate a software function to HDL/FPGA, so it's not always worth doing. For example you could do TCP/IP in hardware, but unless you have particular performance requirements (say HFT) you're probably better off with a soft core and a tested software TCP/IP stack.
Also each feature translated to hardware takes up space in the fabric. When you crunch numbers on an FPGA, it's ideal if you can lay out the entire sequence of operations as one big pipeline, so you can keep throughput as high as possible. Sufficiently long or complex sequences may not translate efficiently to FPGA.
I think there are a few fundamental problems with FPGA compute offload. First is that, as niche products, FPGAs are always a node or two behind the leading edge, so their logic gates run slower than CPUs and GPUs; even their "hard" compute blocks are not as fast. Second, the fundamental nature of FPGAs as a "sea of logic" mean that routing delays reduce your max frequency, or make pipelining necessary thereby incurring latency. Third is memory; historically, FPGAs have not supported high-bandwidth GDDRx, and if you're crunching on something you generally want bandwidth. The latest high-end FPGAs do have HBM but they are quite expensive.
So why would anyone want something that's slower and more expensive? Well, you have to be doing something special, like a lot of custom parallel processing pipelines, or with hard realtime requirements. Basically, a niche, and that doesn't lend itself to economies of scale.
Famous last words...
>we need to build and fail a lot more
You know, that actually describes the early years of fusion research. People thought it would be easier than it has turned out to be. There are lots of gremlins...
I will also note that SPARC is a tokamak, the same as ITER. It's decades of steady tokamak research that has gotten us to this point.
However there will be a few extremely smart jerks, and leadership seems to spend a lot of time applying/fighting for funding. I definitely got the sense that there was a pecking order. The PhDs are at the top, engineers and technicians don't get as much respect. Also in these days I hear that US national labs are moving to a more "flexible" model. In days past an engineer might be assigned to an experiment for the duration, but now leadership wants to be able to assign resources on a more fine-grained basis. (Though I think this is becoming more the case in industry too.)
All that said, if I was in a position to not mind a pay cut, I'd definitely consider going back to pure research.