Truly random access

[RobS]

While constructing an SRAM memory board as a testing aid for my Honeywell 200 Resurrection project (described at great length in another thread hereabouts) something fundamental occurred to me. I haven't had to design and construct one before and I was working out how to route the wires on a prototyping matrix PCB when I realised that exactly how I did it didn't matter in the least. The address pins on these 32k SRAM IC's are conveniently, or maybe that is conventionally, numbered from bit zero to bit fourteen in the documentation but this appears to be solely to distinguish them from each other as, these being random access memories, there is no concept of any order to the address lines because no matter how one connects them each unique address will consistently access the same specific single location somewhere in the memory. Being a pedantic person had I not thought about it I would have routed the wires to ensure that the address bit numbers on the pins on the address driver IC's matched the connected pins on the SRAM's but there is actually no point in bothering to do this. I wonder how many people have ensured that such connections are consistent in this way without realising that they are being unnecessarily pedantic. My design actually uses two SRAM's attached to the same address lines but it appears that I can even connect the address lines to them differently from each other to suit the board layout without affecting correct operation of the overall memory, or am I mistaken? Maybe because we focus on getting every detail "right" when building such devices we can easily overlook which details are essential and which are merely conventions. Of course whether I can overcome my innate pedantry to take advantage of this freedom to act quite randomly is another matter.

It might be suggested that such irregular arrangement of connections would make tracing faults all the more difficult but tracing any fault relies substantially on the adequacy of the accompanying design documentation and anyway, as I stated initially, I need this memory simply as an aid to testing the fickle much older technology that I am working with so if the memory itself has any faults and proves to be untrustworthy then it will be entirely counterproductive to use it at all. More sources of faults I do not need.

 

[krebizfan]

That somewhat depends on the chip. As long as there is no special function on a specific pin, scrambling the address lines only causes a bit of confusion for the person making modifications. A number of ROM protection schemes have relied on this since an extracted ROM will not work if the address lines were conventionally laid out.

 

[WSM]

It might be suggested that such irregular arrangement of connections would make tracing faults all the more difficult ...

Therein lies the exact reason why I try as a designer to follow the exact datasheet references. Even though I include accurate schematics, I design with the assumption that someone else may be trying to debug one of my boards and/or designs.

My only exception comes when I choose to place a second RAM chip on the opposite side of a PCB underneath the main RAM chip. Although I try to maintain consistency, the reversed see-through order can sometimes make that difficult and even more so if a different type of memory is used. Whenever I do this, I make a bold statement on the schematic to carefully note the non-standard pin configuration.

As to whether randomizing address lines works ... I've had absolutely no issues doing that with SRAM and non-removable MRAM. I've also done non-standard ordering of the data pins.

 

[Plasma]

I wonder how many people have ensured that such connections are consistent in this way without realising that they are being unnecessarily pedantic.

It's not unnecessarily pedantic, it's best practice. Anyone troubleshooting in the future will greatly appreciate the consistency. Connecting the address/data lines randomly "just because you can" is the hardware equivalent of writing spaghetti code.

For a personal project that nobody else will use, of course you can do whatever you want...

 

[RobS]

It's not unnecessarily pedantic, it's best practice. Anyone troubleshooting in the future will greatly appreciate the consistency. Connecting the address/data lines randomly "just because you can" is the hardware equivalent of writing spaghetti code.

For a personal project that nobody else will use, of course you can do whatever you want...

Best practice is a luxury as our very experienced plumber will assert. However, the equally experienced bricklayer who built the extension to our house said that "we have to consider those who come after", so perhaps it depends on the longevity of the product.

During my working life as a software developer some people referred to me as a "cowboy" (maybe they meant "maverick") because I tackled the difficult projects that others had written off as unachievable. If the hardware and budget available for a project were inadequate it was given to me and because I so often succeeded I worked for the same company for the whole of my working life and was often invited to sit in on meetings about projects that I wasn't even working on simply because I was good at identifying what really mattered.

Working "by the book" is fine so long as one understands why the contents of the book were written. At our company I said that I was prepared to follow any standards set provided that they were issued along with the justifications for their existence so that one could determine when they did not apply. Many anomalies occur across society because rules are not revised to take new circumstances into account. "Religions of the book" have a lot to answer for.

As my project is one of a kind I have no idea whether anyone will want to take it over in later years. However, that is the essence of what we do here and even though I am building my replica computer now I am severely restricted by what came before some sixty years ago. Even more recent technology appears to be at loggerheads with itself. I am building my SRAM memory on a standard Eurocard prototyping PCB using series 74 IC's so one might expect everything to fit together in conformance to best practice but when I laid out the IC's all the same way round I discovered that some had the ground pin on the low numbered side and the power pin on the high numbered side but others had them the other way round. As the power and ground bus lines on the single sided PCB run between the pins it is very inconvenient to cross the connections to the pins of an IC over the bus lines on the underside of the board, so I am obliged to place some IC's the other way round. No doubt best practice favours having all the IC's the same way round and I would agree if such practical issues permitted it. As every board that I create is effectively a prototype I doubt that any best practice can prevail and I assume that anyone who comes after me will have a large enough budget to replace my prototypes with best practice substitutes, if they can remove the priceless irreplaceable vintage IC's from the existing vintage boards without damaging them irreparably of course.

The reason for my potential maverick arrangement of the address lines is that I am using sockets for all of the IC's on this potentially temporary PCB and they don't leave much space between them for the connecting wires. Of course using sockets does provide scope for inserting the IC's the wrong way round, where the wrong way isn't actually the right way, that is . . . oh, I have so many caveats to document in this project.

Here in the UK I belong to the Computer Conservation Society where some members work with the very oldest machines which may or may not still exist. As there are often no records of exactly how these machines were used sometimes their wiring is very puzzling and it takes a lot of thought to work out the circumstances under which this wiring would serve any purpose. That is of course all part of the experience that attracts people to this work.

For an example of spaghetti code tackling otherwise unachievable objectives see my "Pi Factory" programme on my website, although I'm not sure that spaghetti pie is actually a thing.

 

[Bentendo64]

This shouldn't matter in your situation, but there may be different address selection propagation delays that are dependent upon the address being requested. The datasheet is going to list the worst case delay, so that shouldn't be a huge deal anyway.

If it were me, and this is an artifact that could be passed from my own possession, I would document any oddities on the board itself, as "accompanying" documentation is bound to get lost. If this is a production design, I wouldn't take a shortcut like this, and would prefer "proper" form. Connecting a logic probe could be a nuisance too!

 

[RobS]

The bit numbers on the address pins on the SRAMs that I am using aren't even in numerical order along the IC, so this does suggest that they they result in some way from the internal structure of the device that isn't mentioned in the user specification. Anyway, that shouldn't affect my application, which is emulation of a far slower magnetic core memory from the 1960's. I have now wired up the address lines and the physical layout of the IC's did indeed require connection of the two SRAM's differently to avoid creating a birds nest of wires finding their ways to the "best practice" matching pins on the other IC. The wiring actually laid out is tidy enough that one can see exactly where each wire goes even without documentation. The board isn't large enough for any onboard documentation as it has to fit within the standard board profile for the computer it is being installed into. Each board in the computer is only about six inches square and there are sixteen IC's within that space on the SRAM board as well as a margin left around the edge to fit into the guide channels on the backplane.

Heaven forbid that I should have to connect logic probes to the board. Its purpose is to assist in testing the older logic in the rest of the computer so I expect it to be reliable itself. As all the IC's will be in sockets the approach to testing it, should that prove necessary, would be to remove all of the ICs to test the wiring and sockets and then to swap the ICs around to test them. I think in PC's they call that reseating the memory.

I used to terrify the management at my company by spending so much time designing and writing my software that there was barely enough time left to test it and certainly no time to correct errors, but there never were any. On the assembler language programming course they never told us how to build in errors so I didn't. I didn't even know that it was expected of me. Years later we were using Microsoft software and I spent a good deal of my time working around the errors they'd left in their code. I hate having to do things twice because they weren't done correctly the first time, especially when working with a limited stock of irreplaceable vintage ICs as I am doing on my project.

 

[Eudimorphodon]

As to whether randomizing address lines works ... I've had absolutely no issues doing that with SRAM and non-removable MRAM. I've also done non-standard ordering of the data pins.

With conventional SRAM there definitely shouldn't be a problem. With DRAM you could open up a can of worms with regards to both refresh and, if the memory design actually uses it, things like fast page mode access.

I kind of wonder if there could be implications if instead of "true" SRAM you used a pin-compatible psuedostatic RAM. Those of course are chips which *act* like SRAMs from the outside but actually contain DRAM with a built-in refresh controller. Usually you can treat them just like SRAMs, but if the circuit leverages access modes like address-following read cycles (that's where you just hold down CE/OE and expect the data output to follow the address input as it's changed) shuffling the address lines could potentially cause weird things to happen *if* the chips supports that mode at all. (I was digging through pseudostatic ram datasheets a few years ago for a project idea and, yeah, it's kind of a rabbit hole when it comes to duty cycles and stuff. Of course if the project here uses a 32K chip it's going to be real SRAM unless you dredge up a part from the 80's.)

 

[RobS]

The chips do support address following but I won't be using it. In fact the board contains latches that isolate the address lines from the input from the CPU before the read and write cycles start as the CPU changes the address to that for the next action before the slow magnetic core memory has time to complete its full read write cycle. Hence the address lines will always be stable well before any control lines on the SRAMs go active. In fact the task that these SRAMs have to do is a breeze for them as the read write cycle that they are emulating takes two microseconds, so they will spend a lot of time being entirely static.

 

[MiaM]

I don't know if any SRAM chips have any special mode where you can inquire the chip what type of chip it is.
The pinout for many SRAMs (that are 2kbyte or larger in size) follows the same JEDEC pinout standard as ROMs, EPROMs EEPROMs and flash ROMs, and for all those it's possible to set some pins in a specific state to inquire what chip type it is (this is why better/more expensive programmers are able to auto detect what chip you have). Also EEPROMs have specific methods to enable/disable write protection, and for flash ROMs erasure happens in blocks, so for all these chips the actual address and data line numbering is important.
And this numbering just carried over to SRAM chips.
(The point of having almost the same pinout is to be able to use the same PCB both for SRAM and ROMs with just a few jumpers rather than having completely different pinouts).

 

[RobS]

My next task is to wire up the data lines on the board. The SRAMs hold eight bits per location and one of them is required to store bits one to six and nine of the computer's data to maintain compatibility with the machine's own magnetic core memory unit. Um . . .