Wanted: an old SILOS primitive library (pri150ww.lib)

[exxos]

I'm after a long-lost file called pri150ww.lib. It's a standard SILOS primitive library, so it's not an Atari file and won't be in any Atari source dump. It would have lived in the SILOS install directory.

Where it's likely to be: any archived SILOS III installation from the late 1980s, or a FutureNet DASH setup from the same era, since those two tools went together. So it would be on someone's old EDA tool disks or a design house backup rather than on any Atari CD. If you ever worked with SILOS or FutureNet back then, or you've got a shoebox of 5.25 inch disks from that world you've never dared boot, that's exactly where to look.

The filename to grep for is pri150ww.lib, though the whole pri150 primitive set would do just as well. Even a broken or partial copy is worth a look.

If anyone has it, or knows someone who might, give me a shout.

[alexh]

What is this for? Simulating a Verilog netlist for an old ATARI chip?

SILOS III appears to be a VERILOG simulator from SimuCad (now SilvaCo)?

The latest version of SILOS is now part of a tool called "Gateway Schematic Editor" the last version being 4.2407.0 dated 2024.

While probably irrelevant there are some examples of using Gateway with SILOS to simulate ultra basic digital designs.

We could probably "best guess" at primitives in that library if you have a verilog design that you can't simulate using Icarus or Verilator?

[exxos]

It's for the ST Blitter. I've got Atari's own netlist and I'm converting it to Verilog, but a few of the AND-OR-invert gates reference pri150ww.lib for their definitions, and that's the missing file. Without it I'm reconstructing one gate by hand from the pin connections, which leaves me with 127 possible truth tables rather than one.

[alexh]

If I got to see the netlist file, I could possibly help re-create these primitives but it would be guess work.

Are you sure pri150ww.lib is not a technology library for the silicon process Atari was using? If so it is not going to be part of any EDA software. They typically come from the vendor (i.e. the FAB)

While it is probably of no-use (as it won't look anything like your netlist) you might want to refer to iJor's re-created blitter for inspiration?

I think that some of the ST chips have been re-created from Atari schematics (GST MCU) or a chip decap (GST SHIFTER) but I think this is a re-creation based on observations. But ijor will know for sure. Maybe you can "match up" the logic and so confirm what these primitives do?

[exxos]

Yeah we tested ijor's core a while ago, and it's going into Nexus, so it's a known quantity for me rather than something new to chase.

It probably would help me read off what this gate is doing, you're right. But I'd rather track down the actual library first, or have a proper go at reconstructing it from the netlist, so the definition comes from the real primitive rather than inferred from someone else's recreation. If that draws a blank, ijor's logic is a good fallback to sanity check against.

Happy to send you the gates that reference pri150ww.lib so you can see what they hook up to. Between the surrounding logic and a best guess we might get there.

[alexh]

Go for it

[exxos]

Go for it

Have fun

blitter-an-gates.zip

(19.83 KiB) Downloaded 20 times

[czietz]

Any reason that you distrust the 4051 schematic symbols (which do show the grouping quite clearly, imho)? For example, "AN17" is 4+3+3+3+4 in the schematic:

an17.png (24.58 KiB) Viewed 258 times

Sorry, I don't have a better quality PDF at hand a.t.m.

[exxos]

Any reason that you distrust the 4051 schematic symbols (which do show the grouping quite clearly, imho)? For example, "AN17" is 4+3+3+3+4 in the schematic:

ah yes your right, I somehow totally missed it

[ijor]

It's for the ST Blitter. I've got Atari's own netlist and I'm converting it to Verilog,

But what do you want to do with that? If it's for simulation purposes, the netlist could be useful. For actual implementation, is not really a good idea. Blitter, as the ST chipset in general, and as most legacy chips, doesn't follow good synchronous design practices. They use gated clocks, derived clock, clock as data, and even ripple counters or pulse generators. You can't use such a design reliably on a modern FPGA (or modern ASIC for that matter). It was even a problem already back then.

My Blitter core is based in the same original schematics (you can't really get a cycle exact core without original design files or decap). But it is not the same netlist. I never reproduce the original netlist, precisely for the reason mentioned above. The goal is to implement a core that behaves identically, but following good synchronous practices.