Close

Refresh logic

A project log for AMBAP: A Modest Bitslice Architecture Proposal

Trying to unify and simplify a minimal architecture for various implementation technologies...

yann-guidon-ygdesYann Guidon / YGDES 11/21/2016 at 23:200 Comments

With at least 2 minutes of data retention, the requirements for the refresh cycles don't look too bad.

Yet, with a "worst/best case" of 512 words to refresh every 2 minutes, or 120 seconds, that's 4 words to refresh every second. With an optimistic rate of 12 instructions per second, every third cycle will be stolen by the refresh cycles. That's a LOT and my idea to use an interrupt is now unrealistic. I can already forget about the scratch memory area, which would consume circuits anyway.

Now let's suppose I could "steal" one computing cycle every 4 or 8 cycle. The aim is to reuse as much existing circuits as possible to avoid bloating the architecture. Relays are cheap but not free.

The refresh occurs with a single instruction : increment an address register. The result goes back to the register and to the address bus, which triggers a read-and-rewrite cycle. This single instruction can be hardwired and injected in the instruction stream periodically, using a different "mode".

A "shadow A0" register can be implemented (3 relays, no need to decode 2 operands) and selected in the "refresh" mode. The increment instruction is selected automatically, "clear 2nd operand in ROP2 and set carry-in to 1 then add".

Another solution is to "steal" memory cycles, when no write to the memory is detected, so it occurs in the background, transparently. The address is generated by a LFSR, of a width that is equal to the address bus, +1 to prevent the "blind address 0" problem. Cost : maybe a bit less, this requires another MUX on the address bus, but the LFSR is not as wide as the whole system. 512 words will require 10 bits and 9 MUX (plus a little bit of detection logic to enable the address increment).


So this is another occurence today where the solutions come when I write about them :-D

The cycle-stealing idea is probably a bit sophisticated but it doesn't cripple the already poor performance. And it boils down to

  1. detect when no write to A0 or A1 might take place (it's not important if the instruction inhibits the write)
  2. create a suitable LFSR with a minimal amount of gates

The first is easy : detect when the instruction does not contain A0/D0 or A1/D1 in the destination register. It's as simple as checking 1 bit (the MSB) in the instruction "destination register" field.

The second part is a bit more heavy, as it requires significantly more relays. But it's an interesting exercise.


So we're going to make a LFSR with relays.

Let's start with the polynomials: I have written an article about them in 2009 so I have a list of minimal-XOR polynomials of relevant sizes. Look at some source code at http://ygdes.com/GHDL/lfsr4/ : there are a few polynomials that require only a XOR2 :-)

2=>1
3=>2
4=>3
5=>3
6=>5
7=>6
9=>5
10=>7
11=>9

So all that's left to implement is : a 2-inputs XOR and DFF latches.

I suppose I could reach 512 words (2^9) so the 11-tap polynomial looks good, since it will "skip" address 0 only once every 4 full cycles. Or we can just say "address 0 is the PC" and stick to a 9-tap LFSR (ensuring that the whole range is covered once and only once every 511 cycles).

The LFSR should not be 0 : 1s can be injected during the power-up sequence, or some relays could be set to power up in a set state.


Update: even-sized polynomials are preferred...

Discussions