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.

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).

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.

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.

I think it's slowly being replaced there by Python, but it's very slow.

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.

Comments URL: https://news.ycombinator.com/item?id=45865297

Points: 2

# Comments: 0

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.

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.

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.

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.

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".

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.

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, ... .

The only times I've seen more than the driver on trams/Stadtbahns/metros, they checked tickets. This also happens surprisingly rarely.