Memory-mapping logic - a thought

[BigDumbDinosaur]

bluesky6 wrote:

But what’s all this obsession with speed/performance anyhow?

If you have to ask such a question...

Ahem...the focus isn't on absolute system performance per se, but on the cumulative propagation time of the glue logic. The more granular your memory map becomes the more gates are required to implement the logic. Hence the speed of the individual gates can quickly become an issue.

[GARTHWILSON]

Although there will always be plenty of applications that don't require much speed, there seems to be a legitimate challenge in things like maximizing the performance you can get from a given technology, minimizing the complexity, modularizing, etc.. I have a vague memory about something said decades ago regarding the Indy 500 when there was concern that the cars were getting too fast for the track, and discussion about further limiting the engine size to keep the race from getting too dangerous. Exaggerating to make a point, the driver being interviewed said that even if they were limited to lawn mower engines, they would still continue the sport and pursue the challenge and the competition. (Maybe someone here who follows this kind of racing remembers the situation and the quote better than I. I think you can see the analogy though.)

[BigEd]

I think it's a fair question, if instead of asking "how can we have the fastest decoder" we ask "how can we design a decoder to meet the target clock speed" - for various choices of target clock speed there will be different applicable approaches to memory decode. It would be unhelpful to suggest that every design needs the fastest possible decoder - that's not how synchronous design works - much better to discuss how to calculate propagation delays and how much margin to apply.

[GaBuZoMeu]

commodorejohn wrote:

Ah, you know, I think I was confusing EEPROM with UV-erase EPROM, which I believe I have in 45ns form.

OK, this is something different

Such EPROM (UV or electrically erasable doesn't matter, you always need a programmer to set up its contents) cannot be altered during runtime - the suggested jumper or pushbutton is useless.

Rated as 45ns may get you beyond 10 MHz cycle time. But I wouldn't be astonished if the long bus line will then cause grief. You should provide a pluggable can oscillator. Then you can easily check whether future bugs are hard- or software related.

[commodorejohn]

I'd be plenty happy with 5-8 MHz anyway.

[BigDumbDinosaur]

GaBuZoMeu wrote:

Rated as 45ns may get you beyond 10 MHz cycle time. But I wouldn't be astonished if the long bus line will then cause grief. You should provide a pluggable can oscillator. Then you can easily check whether future bugs are hard- or software related.

My POC V1 unit will boot at 15 MHz using a 45ns OTP ROM. Cycle time at that speed is 66.7ns, so it's patent I'm pushing that ROM pretty hard. I normally run POC V1 at 12.5 MHz, whose 80ns cycle time is safe with a 55ns EPROM. POC V2 wait-states ROM and I/O accesses, so timing violations don't occur at any speed up to 20 MHz.

[GaBuZoMeu]

commodorejohn wrote:

I'd be plenty happy with 5-8 MHz anyway.

That will help a lot!

BigDumbDinosaur wrote:

My POC V1 unit will boot at 15 MHz using a 45ns OTP ROM. Cycle time at that speed is 66.7ns, so it's patent I'm pushing that ROM pretty hard. I normally run POC V1 at 12.5 MHz, whose 80ns cycle time is safe with a 55ns EPROM. POC V2 wait-states ROM and I/O accesses, so timing violations don't occur at any speed up to 20 MHz.

My estimation was very conservative, just to be save. I know - as well as you - that (a) the timing (and other) specs of most ICs are conservative as well and cover the full operation range and (b) that most if not all ICs don't know their specs themself, causing them to be more powerful, faster, less noisy, having lower offsets, less power drain, ...

... some even have more instructions than they ought to have!

[GARTHWILSON]

GaBuZoMeu wrote:

... some even have more instructions than they ought to have!

...especially when Jeff Laughton gets involved!
65c02 single-cycle I/O
KimKlone 65C02 w/ pointer-arithmetic-friendly extended address space and 9-cycle ITC Forth NEXT
(and 65816 fast I/O coming)

[commodorejohn]

So I think I am going to try the PLD approach after all, as it opens up some nice options. I was tentatively thinking of using this. Is there anything specific about the part that I should look for other than being compatible with a 5V supply and TTL logic levels?

Also, on the subject of parts: on the electrical end of things, I'm pretty well a novice, but I do know that good practice is to use decoupling capacitors for the ICs and going off the other RC2014 boards I'm assuming 0.1uF should do fine for that. And as various people mentioned, I'll need pullup resistors to keep the control lines for the memory mapper (coming out of one of the ports on a 65C22) in a valid state at reset - what value do they need to be? And beyond that (and the memory elements, of course,) are there any other components that will be necessary?

[GARTHWILSON]

commodorejohn, you'll want to see our sticky topic, Techniques for reliable high-speed digital circuits.

[DerTrueForce]

I use that part, and it works for me with a TL866A programmer. It should work with the TL866CS as well.
However, if you have a different programmer, you might want to try for some other brand. I have been told that that Atmel part uses a non-standard programming algorithm that is usually not on the cheaper programmers.

[BigDumbDinosaur]

commodorejohn wrote:

So I think I am going to try the PLD approach after all, as it opens up some nice options. I was tentatively thinking of using this. Is there anything specific about the part that I should look for other than being compatible with a 5V supply and TTL logic levels?

As already noted by DerTrueForce, Atmel GALs use a proprietary programming algorithm. Only a few specific programmers can successfully burn one of these devices.

Instead of the 16V8, you might want to consider the 22V10 and give yourself a little design elbow-room. Aside from having more I/O pins, it has more logic resources.

Quote:

Also, on the subject of parts: on the electrical end of things, I'm pretty well a novice, but I do know that good practice is to use decoupling capacitors for the ICs and going off the other RC2014 boards I'm assuming 0.1uF should do fine for that.

Garth already linked to the relevant topic on construction methods. Bypass capacitors are like money: you can always use more.

Quote:

And as various people mentioned, I'll need pullup resistors to keep the control lines for the memory mapper (coming out of one of the ports on a 65C22) in a valid state at reset - what value do they need to be?

I would think that anything in the range of 1.0K to 3.3K should be a suitable value.

Quote:

And beyond that (and the memory elements, of course,) are there any other components that will be necessary?

Necessary for what?

[commodorejohn]

BigDumbDinosaur wrote:

As already noted by DerTrueForce, Atmel GALs use a proprietary programming algorithm. Only a few specific programmers can successfully burn one of these devices.

Instead of the 16V8, you might want to consider the 22V10 and give yourself a little design elbow-room. Aside from having more I/O pins, it has more logic resources.

Ah, thanks to both of you for the tip. I'll have to check into this; it's been forever since I pulled out my programmer and I haven't checked the device list beyond the small handful of EPROMs/EEPROMs I've ever had to burn.

Quote:

I would think that anything in the range of 1.0K to 3.3K should be a suitable value.

3.3k was my guess as I saw it being used for pullups on bluesky's board, but as I said I'm largely a novice at the eletrical-engineering end of this stuff.

Quote:

Necessary for what?

Just having a working board that isn't going to cause the magic smoke to come out of anything. Trying to cover my bases/do the at least bare minimum of my homework, is all.

[commodorejohn]

Well, I've been toying around with looking into this whole programmable-logic thing, and I think I've come up with a suitable design. The new memory-mapper logic is intended to give a ROM window of up to 16KB at the top of memory, selectable between eight sizes (size 0 being no ROM.) The ROM is further divided into two 8KB banks which can be selected out of a standard 32KB ROM (though at any size below 16KB only the top bank will be visible.) And writing to the ROM window will write to the RAM underneath.

I worked up what I think is a valid representation of this in CUPL and I think I've got the logic sorted out. However, I'm having a heck of a time compiling and testing it in WinCupl and WinSim, which is possibly due to human error on my part, but I more think might be due to its being 1998-vintage software running on my Windows 8 work machine. I'll have to try it on my XP laptop at home tomorrow. In the meantime, if somebody wants to proofread my clumsy first attempt at this stuff, here's the source for the PLD and SI files:

MEMORY MAPPER.PLD

Code: Select all

Name     Memory mapper ;
PartNo   00 ;
Date     7/7/2017 ;
Revision 01 ;
Designer commodorejohn ;
Company  Northland Computers ;
Assembly None ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN [1..8]    = [A8..A15]         ; /* High-order CPU address lines */ 
PIN 9         = !MREQ             ; /* Memory request enable */ 
PIN 10        = !WR               ; /* Write enable */ 
PIN 11        = SZ0               ; /* ROM window size */ 
/* PIN 12     = Gnd */
PIN [13..14]  = [SZ1..SZ2]        ; /* ROM window size */ 
PIN [15..16]  = [BNKA0..BNKA1]    ; /* ROM bank A ($C000-DFFF) page select */ 
PIN [17..18]  = [BNKB0..BNKB1]    ; /* ROM bank B ($E000-FFFF) page select */ 

/* *************** OUTPUT PINS *********************/
PIN [19..20]  = [ROMA13..ROMA14]  ; /* High-order ROM address lines */ 
PIN 21        = !RAMSELA          ; /* RAM A select */ 
PIN 22        = !RAMSELB          ; /* RAM B select */ 
PIN 23        = !ROMSEL           ; /* ROM select */ 
/* PIN 24	= Vcc */

/* Fields */
FIELD ROMSIZE = [SZ0..SZ2]        ; /* ROM window size */ 
FIELD ADDRMSK = [AM8..AM13]       ; /* Bits to ignore in checking for top-of-memory */ 

/* Truth table for address mask */
TABLE ROMSIZE => ADDRMSK {
	0=>00; 1=>00; 2=>01; 3=>03;
	4=>07; 5=>0F; 6=>1F; 7=>3F;
}

/* Equations */
ROMENA        = SZ0 # SZ1 # SZ2   ; /* ROM enable only if window size is not 0 */
VARADR        = (A13 # AM13) & (A12 # AM12) & (A11 # AM11) & (A10 # AM10) & (A9 # AM9) & (A8 # AM8)    ; /* Address lines for compare, optionally forced to 1 */
TOPMEM        = ROMENA & A15 & A14 & VARADR    ; /* Top-of-memory area (inside ROM window) */ 

RAMSELA       = !A15 & MREQ       ; /* RAM A select if A15 = 0 and MREQ = true */ 
RAMSELB       = A15 & MREQ & !TOPMEM     ; /* RAM B select if A15 = 1, MREQ = true, top-of-memory = false */ 
ROMSEL        = TOPMEM & MREQ & !WR      ; /* ROM select if top-of-memory = true, MREQ = true, and WR = false */ 

ROMA13        = (BNKA0 & !A14) # (BNKB0 & A14)  ; /* Page select for ROM A13 */ 
ROMA14        = (BNKA1 & !A14) # (BNKB1 & A14)  ; /* Page select for ROM A14 */ 

MEMORY MAPPER.SI

Code: Select all

Name     Memory mapper;
PartNo   00;
Date     7/7/2017;
Revision 01;
Designer commodorejohn;
Company  Northland Computers;
Assembly None;
Location ;
Device   g22v10;


ORDER: A8, A9, A10, A11, A12, A13, A14, A15, BNKA0, BNKA1, BNKB0, BNKB1, !MREQ, !RAMSELA, !RAMSELB, ROMA13, ROMA14, !ROMSEL, SZ0, SZ1, SZ2, !WR, ADDRMSK, ROMSIZE; 


VECTORS:
/* MREQ = F for RAMA, RAMB & ROM at all sizes */
/* Test for all select lines high */

/* MREQ = F, A15 = 0 */
00000000XXXX1HHNNHXXX1NN

/* MREQ = F, A8-15 = BF, SZ0-2 = 7 */
11111101XXXX1HHNNH1111NN
/* MREQ = F, A8-15 = DF, SZ0-2 = 6 */
11111011XXXX1HHNNH0111NN
/* MREQ = F, A8-15 = EF, SZ0-2 = 5 */
11110111XXXX1HHNNH1011NN
/* MREQ = F, A8-15 = F7, SZ0-2 = 4 */
11101111XXXX1HHNNH0011NN
/* MREQ = F, A8-15 = FB, SZ0-2 = 3 */
11011111XXXX1HHNNH1101NN
/* MREQ = F, A8-15 = FD, SZ0-2 = 2 */
10111111XXXX1HHNNH0101NN
/* MREQ = F, A8-15 = FE, SZ0-2 = 1 */
01111111XXXX1HHNNH1001NN
/* MREQ = F, A8-15 = FF, SZ0-2 = 0 */
11111111XXXX1HHNNH0001NN

/* MREQ = F, A8-15 = C0, SZ0-2 = 7 */
00000011XXXX1HHNNH1111NN
/* MREQ = F, A8-15 = E0, SZ0-2 = 6 */
00000111XXXX1HHNNH0111NN
/* MREQ = F, A8-15 = F0, SZ0-2 = 5 */
00001111XXXX1HHNNH1011NN
/* MREQ = F, A8-15 = F8, SZ0-2 = 4 */
00011111XXXX1HHNNH0011NN
/* MREQ = F, A8-15 = FC, SZ0-2 = 3 */
00111111XXXX1HHNNH1101NN
/* MREQ = F, A8-15 = FE, SZ0-2 = 2 */
01111111XXXX1HHNNH0101NN
/* MREQ = F, A8-15 = FF, SZ0-2 = 1 */
11111111XXXX1HHNNH1001NN


/* MREQ = T for RAMA, RAMB & ROM at all sizes */

/* Test for RAMA low */
/* MREQ = F, A15 = 0 */
00000000XXXX0LHNNHXXX1NN

/* Test for RAMB low */
/* MREQ = T, A8-15 = BF, SZ0-2 = 7 */
11111101XXXX0HLNNH1111NN
/* MREQ = T, A8-15 = DF, SZ0-2 = 6 */
11111011XXXX0HLNNH0111NN
/* MREQ = T, A8-15 = EF, SZ0-2 = 5 */
11110111XXXX0HLNNH1011NN
/* MREQ = T, A8-15 = F7, SZ0-2 = 4 */
11101111XXXX0HLNNH0011NN
/* MREQ = T, A8-15 = FB, SZ0-2 = 3 */
11011111XXXX0HLNNH1101NN
/* MREQ = T, A8-15 = FD, SZ0-2 = 2 */
10111111XXXX0HLNNH0101NN
/* MREQ = T, A8-15 = FE, SZ0-2 = 1 */
01111111XXXX0HLNNH1001NN
/* MREQ = T, A8-15 = FF, SZ0-2 = 0 */
11111111XXXX0HLNNH0001NN

/* Test for ROM low */
/* MREQ = T, A8-15 = C0, SZ0-2 = 7 */
00000011XXXX0HHNNL1111NN
/* MREQ = T, A8-15 = E0, SZ0-2 = 6 */
00000111XXXX0HHNNL0111NN
/* MREQ = T, A8-15 = F0, SZ0-2 = 5 */
00001111XXXX0HHNNL1011NN
/* MREQ = T, A8-15 = F8, SZ0-2 = 4 */
00011111XXXX0HHNNL0011NN
/* MREQ = T, A8-15 = FC, SZ0-2 = 3 */
00111111XXXX0HHNNL1101NN
/* MREQ = T, A8-15 = FE, SZ0-2 = 2 */
01111111XXXX0HHNNL0101NN
/* MREQ = T, A8-15 = FF, SZ0-2 = 1 */
11111111XXXX0HHNNL1001NN


/* WR = T for ROM at all sizes */

/* Test for RAMB low */
/* MREQ = T, A8-15 = C0, SZ0-2 = 7 */
00000011XXXX0HLNNH1110NN
/* MREQ = T, A8-15 = E0, SZ0-2 = 6 */
00000111XXXX0HLNNH0110NN
/* MREQ = T, A8-15 = F0, SZ0-2 = 5 */
00001111XXXX0HLNNH1010NN
/* MREQ = T, A8-15 = F8, SZ0-2 = 4 */
00011111XXXX0HLNNH0010NN
/* MREQ = T, A8-15 = FC, SZ0-2 = 3 */
00111111XXXX0HLNNH1100NN
/* MREQ = T, A8-15 = FE, SZ0-2 = 2 */
01111111XXXX0HLNNH0100NN
/* MREQ = T, A8-15 = FF, SZ0-2 = 1 */
11111111XXXX0HLNNH1000NN


/* Todo: ROMA13-14 for all values of BNKA & BNKB in both banks */

[Michael]

post deleted (inappropriate context)