You're right, but I knew that. I should've worded my statement in such a way to prevent criticism.
Gamma rays always follow the speed of light in the medium that they travel through, because they are light. They cannot exceed the local speed of light, thus they cannot generate Cherenkov radiation. It must be particles with charge and non-zero mass that are capable of generating Cherenkov radiation.
The product table says that MPFS025 works with the free Silver license. Only the -S (security) versions require a paid license. Meaning, the MPFS025T has a free license, but the other MPFS025TS would not.
When searching for hardware part numbers, you should first omit the letters at the end, and then read carefully about what they mean.
The product table I saw says "MPF100 (non 'S' devices)", and then I checked their MPF100 family comparison page and saw that no "MPFS*" devices were listed there. Is there a more informative product table on some page? Or how is one expected to know that MPFS025 is a "MPF100 non S" device? Genuine question, I am curious
Then click on the link "Libero license selector guide" to download the Excel spreadsheet. Filter or search for MPFS025.
Microchip does Excel spreadsheet selector guides for everything. As a general guideline when dealing with hardware components, don't trust anything you read on a web page.
Software engineers can sometimes find it difficult as with a HDL you (should) describe hardware that exhibits the intended behaviour, rather than just directly describing the behaviour.
HDLs have familiar syntax that makes it seem like you can just program algorithms imperatively (for loops, if statements, functions etc) but it's all just a mean trick to catch software people out, and generally won't give the results you expect.
On top there's then the fact everything happens at the same time, the faff of making everything synchronised and making sure it meets timing and fighting the frankly awful tooling every step of the way.
Once you get it, it's fine, but you have to unlearn a lot of software muscle memory and keep the actual design work (boxes and lines) almost entirely separate from the implementation (typing your boxes and lines into a text editor).
I've written software for decades and didn't find it very difficult at all to pick up HDLs conceptually. The idea that you're writing a circuit that all executes in parallel is really not a difficult one.
The biggest issues are really:
1. The tooling is generally awful. Open source tooling is very primitive and not usable. Commercial tooling is unaffordable to hobbyists. There are a couple of exceptions:
a) Vivado which I haven't used extensively but seems fairly nice. Unfortunately the FPGAs it works with are not cheap.
b) I discovered that Intel provides a free version of ModelSim. I've used Questa a lot (the "pro" version of ModelSim more or less; their branding is confusing) and it's great.
It also doesn't help that all the tools use TCL which is also awful.
2. SystemVerilog is just a really bad, ancient language. It wasn't even designed for synthesising ASICs, let alone FPGAs! You're writing a simulation of an ASIC, and then some other tool tries to infer how it should run that simulation on an FPGA. It's a completely bonkers system.
It's not just the system that is bonkers. The language is too. Implicit casts all over the place, undefined values as part of the language (though not in Verilator!), multiple assignment types, ridiculously flexible array indexing.
Maybe VHDL is better... but unfortunately SystemVerilog won the language war in the ASIC space so that's what I know.
It also doesn't seem like we'll get a replacement any time soon. You'd need buy-in from the big vendors otherwise debugging will always be a total nightmare.
Though it would be nice if there was something like Typescript for SystemVerilog - something that fixed all the very rough edges and footguns but didn't change the code so much that debugging is painful.
> Open source tooling is very primitive and not usable
Maybe you're working off old information, but the FOSS tooling (ghdl, yosys, nextpnr) is completely sufficient for hobbyists. If you're doing huge, high-speed designs on expensive FPGAs, sure, use the vendor tools, but for your average iCE40/ECP5-scale design, FOSS is the way to go.
Sufficient, sure. But in terms of usability it's like giving someone sed and grep and saying "this is sufficient for writing a novel".
Maybe in time they'll move on from the "here's a bunch of random poorly documented tools, you only have to do all of the integration work!" stage, but they aren't there yet.
Airborne Electronic Hardware Design Assurance: A Practitioner's Guide to RTCA/DO-254 by Randall Fulton and Roy Vandermolen
Might sound a bit niche, and it is, but even if you ignore the stuff about actually certifying stuff to fly, it has some extremely useful and interesting tidbits about how to go about running very large and highly complex hardware/firmware projects in safety critical industries.
The chapter on requirements is especially useful, and the whole thing is written in a (relatively, for the topic) light-hearted way.
I do, as it happens. But your snippy response isn't responsive to the core of the concept to which my question referred.
"Pulling in a chunk of content and probabilistically summarizing it is somehow not generative work" does not make pass the sniff test. And "probabilistically" is load-bearing there: you are reliant on probabilistic weights to not have that generated summary turn out to be hogwash.
The floppotron