2
points
danhor
Joined 1,098 karma
- 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".
- That is the point of Amaranth (and migen). It's not HLS, it doesn't try to generate logic from normal python code. It's an HDL implemented in python, not trying to look like python code.
In my opinion, it's even more of an HDL than SV or VHDL: It has native concepts of Clock Domains, reset handling and e.g. blockram, it describes the hardware. There is no missmatch with two different, weird assignment types. It's occupied with with accurately covering available/commonly used hardware constructs with commonly used features, not introducing useless abstractions that don't help in practice (trivial example: Your clock signals are not just another signal that mess up timing everywhere if you try to use them that way).
But on the other hand, there is no weird, half-useless metaprogramming/simulation layer with almost the same syntax but tricky rules that differ. That part is proper python.
Thus it's easy to write code that is flexible over different interface types (i.e. one async fifo that can be used for almost all data or an width adapter that mostly works automatically), generate memory-mapped registers that are correctly hooked up, generate wide e.g. CRC operations that are optimized in python code before making HDL out of it as Vivado barfs on them (which I've also seen done with python code that generates systemverilog using string concatenation).
I think my point is just that SystemVerilog isn't a good HDL. It makes it hard to (correctly) describe hardware and makes reuse often harder than it needs to be.
Regarding the intermediate translation step: Amaranth has it's own native simulator and for system-level simulation interfaces directly with yosys for cxxrtl or synthesis for parts directly supported by yosys, bypassing the need for a yosys-> verilog conversion. It's "only" needed for most commercial tools, that can only process SV and VHDL.
- Alon Levy has also written some more on Tram-Trains: https://pedestrianobservations.com/2020/11/03/tram-trains/
A few points I want to add: The Stadtbahn (called Tram-Metro in this Article) is usually just as fast in the outlying areas as in the inner areas and rarely street running, just doing it with less infrastructure. It's just that rail tracks are even faster.
There are quite a few newly built S-Bahn Tunnels in cities under a Million in Germany, in Frankfurt, Stuttgart and Leipzig (you could quibble about citie vs metro area population).
The major downside of Tram-Trains compared to S-Bahns, Rapid Transit or just through running away from the city center is that they slow way down in the city center, much more than the other options. This makes it a bad fit for the sprawly, north american cities without a strong center which have much more demand for non city center destinations and a much more expansive center compared to european cities with tram-trains.
The big benefit of Tram-Trains is the flexibility. Over a region, some sections can implement their own new through running section for the Network (Heilbronn), be almost a metro (the Kombilösung and some parts of S11) or provide S-Bahn style service (e.g. Freudenstadt for a mediocre Regio S-Bahn).
But it's a master of none: Too slow and cramped for high-quality regional services, too few doors for rapid passenger exchange, too demanding and expensive (electrification and vehicles) for connecting small rural lines, legally limited in capacity (75m) for very busy services.
They can be great, but it really depends on local circumstances.
Before converting commuter rail to Tram-Trains, most American cities should first implement a frequent (at least 2tph), all-day, regular service with more urban stations for commuter rail and perform true ticket integration between mainline rail and their other urban transport (the ticket integration is very important!). This also applies to many european cities, such as in France, Spain, Belgium, ... .
- Mont (if not allmost all) S-Bahn trains in Germany only have one staff member. The space for wheelchairs is directly behind the drivers cabin and the few times I've seen a ramp being deployed, it took the driver 1-2 minutes (Usually the automatically deployed gap filler is good enough). A large portion (I'd guess somewhere around 20-40%) of regional trains are also only staffed with the driver. The others do have an additional staff member, but they're almost always not safety relevant and only perform ticket checks, answer questions and help with ramp deployment.
The only times I've seen more than the driver on trams/Stadtbahns/metros, they checked tickets. This also happens surprisingly rarely.
- As the local machine is there anyway, only the increase in energy usage should be considered, while the server only exists for this use case (distributed across all users).
The local machine is usually also highly constrained in computing power, energy (when battery driven) and thermals, I would expect the compute needed to be very different. The remote user will happily choose a large(r) model, while for the local use case a highly optimized (small) model will be chosen.
- Most car trips could be replaced with ebike trips, but the majority of distance travelled (and thus, roughly, carbon emitted) can't. 80% of the distance driven is with trips >10 km, 70% of the distance driven already at >20 km. There are people doing these trips on E-Bikes daily, but even with great infrastructure they'll remain a small proportion of the modal split (Data from Germany, MiD, 2017). The long(er) trips are the majority of the problem, as the rest are, well, short.
Most rail should be powered by overhead electricity, but for short- to medium-term gains BEMUs are also great, with most European train manufacturers not building DMUs anymore. They'll hopefully also come down in price, as this first generation is really expensive.
I know that the US (and Canada) has issues with battery busses, but in (western) Europe, they work great (but currently still a tad too expensive). Trolley busses are even more expensive (similar if not higher purchasing cost, much higher infrastructure cost, slightly less energy usage) and require a whole lengthy political process to deploy, while battery busses can be deployed in a few months.
BEVs are the only feasible solution for replacing a large part, if not most, of the emissions from cars. Even in countries with a great countrywide transit network and reasonable bike infrastructure (Germany), 73% of passenger-kilometers are traveled by car (MiD 2023, 19% by transit, 4% by bike, 4% by walking), down from 80% in 2002. There is no way to much more than double transit usage in the next 15-20 years. And the situation is much worse in e.g. the USA where little good transit exists, where good infrastructure exists operations suck, building transit is astoundingly expensive, land developmental patterns run contra feasible attractive transit and transit agencies seem unable to learn anything from outside the US (in operations, construction, planning, ...).
This is not to say that anti-car policies (and pro-walking/biking/transit) policies shouldn't be implemented and are in many cases preferable compared to subsidizing BEVs, but their potential in the short- to medium-term for carbon reduction is quite limited.
- > It appears to be possible to debug the Hazard3 cores in the RP2350 in the same way as the ARM cores:
It is, but (as far as I understood it), they're using ARM SWD IP (which is a fine choice). But since their connection between the SWD IP and RISC-V DM is custom, you're going to need your adjust your debug probe software quite a bit more than between different Cortex MCUs.
Other vendors with similar issues (for example WCH) build something similar but incompatible, requiring their own debug probe. This is a solved problem for ARM cortex.
- RISC-V is even worse: The Cortex-M series have standardized interrupt handling and are built so you can avoid writing any assembly for the startup code.
Meanwhile the RISC-V spec only defines very basic interrupt functionality, with most MCU vendors adding different external interrupt controllers or changing their cores to more closely follow the faster Cortex-M style, where the core itself handles stashing/unstashing registers, exit of interrupt handler on ret, vectoring for external interrupts, ... .
The low knowledge/priority of embedded of RISC-V can be seen in how long it took to specify an extension tha only includes multiplication, not division.
Especially for smaller MCUs the debug situation is unfortunate: In ARM-World you can use any CMSIS-DAP debug probe to debug different MCUs over SWD. RISC-V MCUs either have JTAG or a custom pin-reduced variant (as 4 pins for debugging is quite a lot) which is usually only supported by very few debug probes.
RISC-V just standardizes a whole lot less (and not sensibly for small embedded) than ARM.
- > But this is the problem. It means that a party being illegal isn't such a big deal in and of itself.
Yes, this is what the constitutional court decided.
> If some party is illegal for whatever reason, it should be banned right away.
It should be hard (and is very hard) to ban a party. Thus if every party illegal should be banned right away, a large amount of effort would need to go into banning by the highest legislative and judicial bodies in the nation. It's furthermore quite hard to definitively establish a party as such, which further makes such things much slower (calls to ban the AfD have been happening for more than a decade now).
- > AFD obviously still exists so a court has not banned them. Innocent until proven guilty.
A court can only ban them after the parliament has voted to ban them. One of the hurdles on getting the parliament to vote on this topic has been the outstanding decision by this body, if it's really "gesichert rechtsextrem". At least in many previous cases surrounding this question (mostly libel cases), courts have argued that the specific people these cases were about could be seen as "outside of the democratic spectrum".
> The measures would of course need to be biased toward false-postives to prevent future false negatives.
Certainly, that's why both the parliament and the highest court have to decide, with previous instances sometimes not coming through (for example, the NPD for not being relevant even though they were certainly Nazis).
> That the afd growth of doubling their power since last election and AFD is now polling in first place. So to win the next election they need to essentially remove AFD from being an option; or los
There would be no reason to ban a party if they could be ignored (see the NPD), you only need to ban extreme parties if they're popular. If the AfD were at 3% this would be a much smaller topic, since there would be no foreseeable risk. But even with the AfD at much lower than <15%, this was very much an area of concern, with steady (legal, as with this classification and previous ones concerning subgroups) progress towards establishing their extremist status.
- The data on EVs is that maintenance (at least on the drive train + battery) is not an issue, excluding air cooled designs like the Nissan Leaf which were doomed from the start.
But hydrogen fuel cells are also expensive to maintain and have been a huge maintenance burden, as they're quick to fail with contamination (and lots of other factors), leading to hydrogen trains being replaced by diesel trains.
Hydrogen can be clean, but it isn't and won't be for the forseeable future for the simple fact that it would be way to expensive. Almost all hydrogen today is made from natural gas and much less efficient than powering an electric car from a gas plant. But even if hydrogen was produced with electricity, due to the low efficiency it would be much dirtier than an electric car (And we're entirely discounting hydrogen leakage, which is much more potent at heating up the planet than CO2).
Hydrogen can also be fast to refuel, but it takes much longer than gas and often requires a long "time-out" after the last refueling. Hydrogen fuel stations are also very unreliable. With current EVs, 20%-80% charging in 20 minutes is state of the art, which should make charging times mostly a non-issue when this is also available in most "cheap" EVs.
- The vast majority of germans use statutory health care insurance, with only 10% using private insurance.
Many other aspects of healthcare follow a similar model, where parts are fully private, parts are non-government-but-quite-close-in-function (Ärztekammern and other things) and many to most are public in some sense.
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.