ZirconiumX

[The FreeBSD license] is a lax, permissive non-copyleft free software license

https://www.gnu.org/licenses/license-list.html#FreeBSD

Being female or male is a fact about the biological world.

I was responding to this line, which I feel marginalises intersex people and could have been more inclusively worded.

I apologise if my comment somehow seemed to defend LLMs having a biological sex, despite me having said nothing to that effect.

You appear to have forgotten the existence of differences in sexual development (DSD).

The chart in [1] is a good visualisation of that, if you wish to learn more.

[1] https://www.scientificamerican.com/article/beyond-xx-and-xy-...

Sorry, I really don't see where the issue is.

Nothing forces you to use C++ scripting here; Yosys has a shell that you can enter commands in, and it takes via `-s` a file of commands; a script.

That the default scripts are written in C++ to not need dependencies does not mean you also need to write your scripts in C++.

...is your bugbear here that these particular scripts are written in C++ instead of Python?

Yes, those flows use ScriptPass, because for the most part they are scripts. If they were written in Tcl, then Yosys would need to depend on a Tcl interpreter, and equivalently a Python interpreter for Python. By just using C++ for these scripts which usually only developers need to modify, Yosys does not need to depend on either.

But anyway, if I was going to mess about with the flow that much, I'd start by running `help synth_xilinx`, which outputs a list of all the commands that it calls (more or less; it can't model control flow like a proper language can), and then that can be edited into what I need it to do.

Reading your answers, I've noticed that there appear to be some major misconceptions about Yosys and how it works: certainly, ABC is a core part of a standard synthesis flow, but Yosys is based around a series of passes that modify a common intermediate representation. That should mean if anything it is very easy to use only part of Yosys.

Obviously it'd be off-topic to try to discuss your particular needs and use-cases of Yosys here, so feel free to email me at lofty@yosyshq.com.

If you have any questions about nextpnr, feel free to email me at lofty@yosyshq.com.

Well, at least part of this comes down to the fact that we did not choose a scripting language today, but at least a decade ago where Tcl was dominant in EDA and Python would not have been taken seriously.

> full disclosure: I work for YosysHQ

let me take this opportunity to ask a question about something that makes absolutely zero sense to me: why did yosys insist on sticking with tcl over some more modern/well-known/familiar scripting language? yes everyone has their favorite tcl scripts for vivado or intel or whatever but none of them are transferrable to yosys irrespective of that fact that yosys supports tcl.

First: PYosys exists as Python bindings for Yosys, so you can in fact use a more modern scripting language for this.

Second: even if the Tcl scripts are not transferrable, a lot of our users do still have Tcl experience, and that transfers if nothing else.

But personally? For a lot of tasks you don't need a scripting language. If you want to turn a set of Verilog files into a JSON to pass to nextpnr-ecp5, that's `yosys -p "synth_ecp5 -abc9 -top top -json design.json" *.v` and there is neither Tcl nor Python involved here.

further more, why is yosys itself basically scripting of ABC and nextpnr and etc using cpp instead of again using just some reasonable scripting language to connect the pieces?

Yosys is not simply some scripting around ABC: you need to parse input files, store this in an intermediate representation (RTLIL), elaborate and monomorphise the input structure, perform optimisation and logic minimisation on it; you need to map large structures like memories, hard multipliers and carry chains (ABC can't do that), legalise flop types and only then can you pass the logic to ABC. Once you get that logic from ABC, you need to turn it into cells that tooling recognises.

That the "script passes" we have that most front-end users use are so simple is because the complex logic is packed into neat passes to call.

> multi-electrostatic placer

um why? dreamplace exists? https://github.com/limbo018/DREAMPlace

We're aware of DREAMPlace, however: DREAMPlace itself is for ASIC applications, so you'd want to use DREAMPlaceFPGA instead, which is...limited to a simplified Xilinx architecture or whatever partial FPGA Interchange Format support they have. We consider speed a feature, and having to deserialise the target device and netlist into FPGA Interchange Format in the hopes that DREAMPlaceFPGA can understand it is...not fast.

So instead we're working on our own multi-electrostatic placer which can more tightly integrate with nextpnr than something using DREAMPlace[FPGA] could.

I should point out that even the F4PGA page [admits](https://f4pga.readthedocs.io/en/latest/how.html) that ECP5 and iCE40 support is done through nextpnr, rather than VPR.

(actually nextpnr has slowly-maturing support for Lattice MachXO{2,3}, Intel Cyclone V and Gowin parts too)

full disclosure: I work for YosysHQ, who have an alternative open-source place-and-route program - [nextpnr](https://github.com/YosysHQ/nextpnr/) - and YosysHQ presently has [a grant](https://activities.esa.int/4000141380) from ESA on improving nextpnr.

to be blunt: nextpnr is what happens when you look at VPR as prior art and base every design decision around doing the opposite of VPR.

VPR is flexible, true: you can define an architecture description inside an XML file, but I view the VPR XML format to be poorly considered.

- commonly in an FPGA you will have "legality constraints" - for example, a block of LUTs cannot simultaneously be in carry-chain mode and act as LUT RAM. to produce a legal solution, all these constraints must be satisfied. to nextpnr this is [two basic](https://github.com/YosysHQ/nextpnr/blob/master/docs/archapi....) [API calls](https://github.com/YosysHQ/nextpnr/blob/master/docs/archapi....). to vpr, you must [walk the architecture](https://github.com/verilog-to-routing/vtr-verilog-to-routing...) to discover and cache legal placement positions. - VPR often requires significantly more detail about an FPGA than is easy to provide; for example, [how switchboxes are laid out](https://docs.verilogtorouting.org/en/latest/arch/reference/#...), or [routing metal resistance/capacitance](https://docs.verilogtorouting.org/en/latest/arch/reference/#...). to nextpnr, routing is just nodes and edges on a graph.

Further, VPR's algorithms tend not to be designed with performance in mind; simulated annealing as a placement method does not scale well past the tens of thousands of LUTs, which is why nextpnr moved from full simulated annealing to [heterogenous analytic placement](https://ieeexplore.ieee.org/document/6339278), and recently we have been working on a [multi-electrostatic placer](https://dl.acm.org/doi/abs/10.1145/3489517.3530568); both significantly more scalable methods based on using mathematical optimisation methods to place things nearby.

DIre SIlicon DeXtrously Concatenates 8 and 9 (for SysV). Jubilee[1] came up with that and it's a useful mnemonic.

[1] https://twitter.com/workingjubilee

I asked whitequark about the name; it's named Glasgow because it's where the headquarters of FTDI are based, and the initial prototypes were intended to be an open-source serial adapter gateware before feature creep set in.

Distributing GCC does.

GOWIN's design is very similar to the ECP5 in architecture, but the bitstream formats are notably different.

Could you please point [6] at https://github.com/nmigen/nmigen which is the new upstream after a hard fork?

Additionally, I'd like to clarify that nMigen generates Verilog indirectly; it actually generates RTLIL, which is the intermediate representation of Yosys, and then Yosys turns it into Verilog after some cleanup passes.

I'll happily admit to being biased, but nMigen is so much easier for me to work in than Verilog ever was.

There are three killers here: self-modifying code, synchronisation, and parallelism, all of which are major headaches for a JIT.

The PS3 does not have self-modifying PPC code (SCEI forbade it), which means the PPE blob can be compiled ahead-of-time (RPCS3 converts it into LLVM). The SPE data can self-modify, however, but (to my knowledge) does not require extensive synchronisation, therefore each SPE core can be put on a thread.

The PS2 code has fairly extensive use of self-modifying code; Naughty Dog in particular will frequently load parts of the executable in and out of memory on both the PS2 main processor (the EE) and the PS1 processor (the IOP), and rely on the synchronisation between these two separate processors to be fairly tight. Trying to make the EE and IOP separate threads running simultaneously breaks this synchronisation, so the EE and IOP have to run on the same thread.

Additionally, the PS2 has two vector units; VU0 is associated with the EE (it can be used as a floating-point SIMD unit in the EE instruction stream) and VU1 is associated with the GS [the PS2's GPU, the Graphics Synthesizer] Interface (GIF) (it can directly output primitives to the GS). This means that VU0 needs to run on the same thread that the EE runs on (because there is instruction stream interlocking), and VU1 needs relatively tight synchronisation to the GS (it is feasible to put it on its own thread, but games can be quite picky with timings)

There are no plucky garage shops or "wise crowds" making FPGA tools that are even in the same galaxy as ISE or Vivado.

Symbiotic EDA comes to mind. However, I would argue they don't need to be great, just good.

I don't have a copy of Vivado to hand (I have an Altera dev board instead), but I can take PicoSoC with Yosys/nextpnr and have a bitstream in about a minute. If I try the same task in Quartus, that takes about five minutes. Producing a (relatively) inefficient bitstream actually speeds up the compile/run cycle in that scenario.

If the design meets timing, which is often decided by external factors, any extra time spend trying to make the design "better" is wasted time.

But modding a PS2 only requires a memory card with FreeMcBoot on it (it's literally plug and play), and at that point you might as well use an updated version of Linux like frno7's.

With the PlayStation 2 you can run Linux on MIPS[1], though it's a highly nonstandard MIPS; you'll need to get a memory card with FreeMcBoot. Plus, even if you plan to do embedded development, the PS2 is much more documented than the PS1.

As for a "more traditional computing" experience, you can always look for an SGI.

RISC-V borrows heavily from MIPS, so the two have a pretty similar development experience.

[1] https://github.com/frno7/linux or else source the official PS2 Linux Kit.

Which is why you implement a doubly linked list using data indices in a Vec<Node>. The resulting data structure is fully safe and resembles an ECS.

Rust is safe from race conditions, because race conditions are memory errors.

You should read [1] to understand how Rust achieves this.

[1] https://doc.rust-lang.org/nomicon/send-and-sync.html

So, I consider myself a MIPS fan, having studied the early (SGI era) MIPS revisions, but if I started from a clean sheet, I would pick RISC-V over MIPS, because while MIPS is a fairly clean architecture, RISC-V is cleaner.

For example, the MIPS R4000 CPU had three microarchitectural branch delay slots of which the latter two had to be cancelled, and that must have been awkward to design.

In contrast, RISC-V has no ISA branch delay slots, so requires less from lower-end implementations, and provides more to higher-end out-of-order CPUs.

I'm curious how you plan to detect dependencies from a file by piping it through a command that removes those dependencies.

But you also need compatibility with #include, so your build system also needs to become a preprocessor.

I've usually found -Og to inline functions or optimise out variables I needed to investigate. It's happened often enough that I just use printf in release mode.

Of those cores, MIPS own the direct rights to none of them.

The R3051 (used in the PlayStation 1) was a derivative of the R3000A (which MIPS should have the rights to) made by IDT. I don't think MIPS have the right to the modifications.

The R4300 (A derivative, the NEC VR4300 was used in the Nintendo 64) was designed by Quantum Effect; I think whoever owns what's left of them would own the HDL, if it's still around.

The R5900 (used as the core of the PlayStation 2's Emotion Engine) was designed by Sony and Toshiba; I'm pretty sure Toshiba have the rights to it.

A more complex instruction set needs more silicon to decode, and thus is less power efficient. However, I'd imagine that Intel are pretty good at decoding x86 at this point; they've had plenty of practice, so it might balance out.

While this is an issue, there are cooperative threading libraries (mainly Lwt and Async, though the community prefers Lwt) which can mitigate most of the reasons you'd need multithreading. Hell, because it's only single threaded, you can mostly ignore locking.

OCaml has odoc now, which is what creates the Core web page. Core does have bad documentation, but you can try Containers, which is much lighter and better documented, but less featureful.