> Nuclear has the most bizzare cost curve of any new technology where every year it costs more than the year before; a pattern which makes effectively no sense and is really only explainable by the heavy and effective political attack that nuclear has been under in the US and EU.
Or by generally exploding costs of megaprojects. Look at e.g. high-speed-rail in UK, France, Germany, ... . The first projects were the cheapest, after that it only got more and more expensive.
The PS5 and Xbox are also very close to being an x86 PC, but you're not installing your own OS on there even though there are few technical hurdles if the manufacturer removed the mechanisms to prevent that.
> You can just ignore the EULA. Nobody is coming to get you.
You can, but it's not gonna gain broad attention.
> Why is nobody using it?
It's used for chips with a good open source backend (lattice, gatemate). But it's non-trivial to integrate with the vivado backend and doesn't bring many benefits when used as such.
> You can extract the timing information from Vivado. Such information is not copyrightable.
Yes
> You could also collaborate with someone with a really fast oscilloscope to gather some timing yourself
No. Especially not fast-fast and slow-slow corners.
> Even if you just get the connectivity data and bitstream format and no timing, that's massively useful for less-than-high-speed projects.
Not really, you need at least a rough worst-case estimate. Otherwise even trivial designs might not work.
> A single open source developer just has to make a contribution, doesn't have to do the whole thing in one go.
A large part (clocks, routing, LUTs, BRAM, IO, a basic timing model) has to work, otherwise it's not really usable.
It's really non-trivial to get to a basic usable point. I would estimate at least 4-5 very experienced people working on this 2-3 years. Nothing impossible, but also not something that easily happens.
> Nothing stops someone from taking the free Windows Vivado and making it run on Linux
The EULA and the fact that the linux versior runs faster & has fewer bugs.
> just the device-dependent backend would be a major improvement and the frontend and optimizer could be shared with other toolchains
That's yosys and it's used by smaller commercial vendors.
> or reverse engineering then bitstream format for these FPGAs
Getting the timing is the hard part (+ good routing afterwards). The bitstream format has AFAIK mostly been reversed. 7 series has mediocre support , but US, US+ and Versal doesn't (probably because they're too expensive for personal usage).
A PDF of a long document such as a standard or reference manual is almost always preferable to an HTML version. HTML versions have issues with formatting, searching (as browsers struggle with multi-thousand page documents and non-native search document search implementations almost always suck), indexing, correct behavior on windows size change (especially a side-by-side pdf view is almost unheard of for webpages), ... . Some vendors have switched to online-only for some documents and it always annoys me.
It's often a requirement for bare metal embedded development (too heavy in terms of memory), so it's basically unavoidable. Non-standard languages are very common for this kind of thing, just look at the linux-flavoured C.
Signal Priority only works well if the arrival time of the bus can be predicted some time before arrival at the signal (~30 seconds is a number I've heard a few times). As bus stopping times are highly unpredictable, a lower number of bus stops makes signal priority work much better (and far-side bus stops).
Furthermore signal priority and own lanes are almost always beaten by good circulation planning, reducing the number of traffic lights and cars on the route of the bus.
Certainly not with hydrogen directly. It might be involved in the production chain, but it's such a pain. If it's at all possible to electrify, that'll very likely win.
For flights, a combination of batteries for smaller, regional planes starting with "islands hoppers" now and SAF from either Biofuel or produced from Electricity (with Hydrogen as an intermediate step). Although I think that we might first see moves to reduce the 2x non CO2 Climate Impacts which can be much cheaper to tackle (such as Contrails).
For maritime applications, batteries when regularly near ports, probably hybrids with methanol for cross-ocean passage far away from coasts.
The Hazard 3 is basically a hobby project of Luke Wren, a Raspberry Pi Employee. He's contiuing to evolve it further, but I don't think it's ready for a full replacement of the Cortex-M yet, especially in regards to the Security Features.
The source code is all from Luke Wren and I don't think other cores use the source code directly, but improvements to test harnesses or general implementation patterns as well as better software support help other cores: https://github.com/Wren6991/Hazard3
For the SoCs I would expect to see an off-the-shelf Risc-V core (certainly no Hazard3 as the main CPU), but we'll see.
My "Homeserver" with its database running on an old laptop has less downtime than AWS.
I expect most, if not 99%, of all businesses can cope with a hardware failure and the associated downtime while restoring to a different server, judging from the impact of the recent AWS outage and the collective shrug in response. With a proper raid setup, data loss should be quite rare, if more is required a primary + secondary setup with a manual failover isn't hard.
One of the reasons amaranth (and other neo-HDLs) is so great is the full-fleged seamless integration with the host language. Generating DSP filters using the numpy for all parameters, creating CRC structures, diffent logic for different word widths, ... .
This is all feasible with SV or an embedded Macro language as well, but you'll either have to live with a poorly documented meta language (as not a whole lot of people are using it) or heavy missmatches between the meta language and the "real" language. Cocotb very much suffers from this for simulation usage.
And, tbh, if it can be nicely implemented in the host language (which IMHO is the case with amaranth, less so with migen), I don't think there are many benefits by being standalone.
What are the benefits of SV for multi-clock design? I found migen (and amaranth) to be much nicer for multi-clock designs, providing a stdlib for CDCs and async FIFOs and keeping track of clock domains seperately from normal signals.
My issue with systemverilog is the multitude of implementation with widely varying degrees of support and little open source. Xsim poorly supports more advanced constructs and crashes with them, leaving you to figure out which part causes issues. Vivado only supports a subset. Toolchains for smaller FPGAs (lattice, chinese, ...) are much worse. The older Modelsim versions I used were also not great. You really have to figure out the basic common subset of all the tools and for synthesis, that basically leaves interfaces and logic . Interfaces are better than verilog, but much worse than equivalents in these neo-HDLs(?).
While tracing back compiled verilog is annoying, you are also only using one implementation of the HDL, without needing to battle multiple buggy, poorly documented implementation. There is only one, usually less buggy, poorly documented implementation.
>
There's still relevance in making it stupidly easy to make an LED blink and make basic apps on circuit boards. Education + weekend hardware hackers might look for something different in a framework than a professional.
This group is has been moving to circuitpython, which is much less performant, but even easier to use. The more serious cross-platform development environments, like Zephyr, have also become much better.
How would you effectively stop windows updates to china? Bypassing the Windows activation measures isn't stopping single pirates (or people still wanting Windows 7 updates intended for big business with legacy devices), the only way to stop windows updates is preventing access to it. It's impossible to do so while still having Windows as an Operating System that people outside high security environments use.
While energy is expensive, I find it hard to blame on the "green stuff".
The majority of the energy cost increases in the last few years are because fossil fuels got more expensive for europeans, as cheap gas and oil from Russia wasn't cheap nor very available any more. Lower emissions technologies require much less energy: Heat pumps, induction stoves, electric goods and private transport. Renewables are furthermore more resilient to supply shocks, as they aren't as dependent on from despotic states such as Russia, Saudi Arabia or (seemingly) the US for much of the (fossil) energy. The correct response would be to electrify as much as possible (much less energy required) and produce electricity without the need for importing fossil fuels.
The housing situation sucks, but while many rules discourage housing production, only a smaller subset is there to reduce emissions (requirements about amenities such as outlets, room size and layout, parking and local opposition have little to do with emissions). Many countries such as the US which care much less also suffer heavily as well from being unable to build enough housing.
I have little idea about what specifically the netherlands are doing on climate, but it has at least not been my impression that they were the "best boy in class".
It takes a bit of effort to add all you would want and, for me personally, bangs can be anywhere instead of having to be at the start of a search query as is needed for custom search keywords.
While people don't discover these apps on the play store, they will hear of the App, search on the App/Play Store and install it. If they can't find it by typing the app name into the search bar there, they won't install it.
I doubt most users will, even when given the link to an .apk, install it. Either because they are discouraged by the alarming prompts (in my opinion a tradeoff that is unfortunately worth it) or because they get lost.
xdg-desktop-portal-wlr works (with a bit of cli work) with MS Teams in chromium with a flag to enable pipewire. The Desktop app will only support it when the Electron release containing pipewire support releases & gets used in Teams.
Or by generally exploding costs of megaprojects. Look at e.g. high-speed-rail in UK, France, Germany, ... . The first projects were the cheapest, after that it only got more and more expensive.