ATF1504 logic help needed

[GlennSmith]

Hello all,
This will, I hope, turn into a "Doh !" moment - but I'm currently stuck with what should have been simple logic inside an ATF1504.
I need to set the scene : I'm working on my 65816/Pico2 prototype - a spin-off from the original RP6502_Picocomputer. The Pico2 has been reworked to not stumble over the bank address moments when the clock is low, and has the full 32-byte vectors area for the 65816. Address decoding is done in the ATF1504, it is also capturing the bank address and setting external pins that correspond to each 64k bank (from 0 to 7). So far, so good.

I'm using the 'trick' that I discussed with BDD in a post about the ATF750C chip : pass PHI2 through an internal F/F and use it to latch the bank address : using the (short) propagation delay to get the BA a short while after PHI2 falls. Here's what I did to make it work : (CUPL language)

Code: Select all

PINNODE 45 = BA;

... some other logic...

BA.ck = CLK;
BA.d = !CLK;

/* Bank address decode */
Banks.le = BA.io;  /* .io is the O/P of the F/F : should add a small prop delay */
BNK0.l = Data:'b' 000;
... and so-on for banks 2..7

This works quite well, I'm latching the bank address very early during PHI2 low. Here's a picture of it working : (RIA is the Pico2)

The Pico2 is emulating the boot rom, selected in the region $FFC0..$FFFF (in bank zero). You can see the vector addr. and the first opcode.

Now to my question : You can see that RIA is being de-selected when PHI2 is high :how do I maintain my latch contents during PHI2 high, and only relatch the bank address at the next falling adge of PHI2 ?
Thanks, in advance !
(edit : modified the question for more clarity (hopefully))

[Yuri]

GlennSmith wrote:

Now to my question : how do I maintain my latch contents during PHI2 high, and only relatch the bank address at the next falling adge of PHI2 ?
Thanks, in advance !

If I'm understanding you correctly then it sounds like you would want to remove the use of the .LE and .L options and do away with a buried pinnode.

E.g. (using 84-pin 1504):

Code: Select all

/* Input */
PIN 2 = CLK;
PIN [4..6,8..12] = DBA[7..0];

/* Output */
PIN [15..18,20..22,24] = BA[7..0];
PIN [25,27..31,33,34] = D[7..0];

BA.clk = !clk;
BA.d = dba;

D.clk = clk;
D.d = dba;

I'm not entirely clear on how the LE and L options work, sure someone else would be able to comment more on that. The devices I have are 7.5ns and have worked well for my VGA circuit, haven't gotten around to building a 65816 build just yet to test the address latching there though.

Good luck!

[GlennSmith]

Yuri wrote:

If I'm understanding you correctly then it sounds like you would want to remove the use of the .LE and .L options and do away with a buried pinnode.
I'm not entirely clear on how the LE and L options work, sure someone else would be able to comment more on that. The devices I have are 7.5ns and have worked well for my VGA circuit, haven't gotten around to building a 65816 build just yet to test the address latching there though.

Well AFAIK the latch operators should enable a standard latch circuit, like a 74xx573 :

TI wrote:

When the latch enable (LE) signal is high, the Q outputs follow the data inputs. When LE is low, the Q outputs are latched at the logic levels of the inputs.

So, I went back to basics instead of trying to be clever, and reverted to the 'standard' approach which is to just latch on !CLK. This gives :

Latching with !CLK

Which shows that the bank output is latched during CLK high, but those little glitches become more and more of a problem as the PHI2 frequency increases. At 7MHz the picture is (sorry BDD, colored screen capture) :

... and at 7MHz

Which is becoming rather messy. Which is why I was looking to slightly delay the latch signal. I'll keep playing !
(Although I've started to have problems with 'unlocking' my ATF1504s that I programmed, 'cos I disable the JTAG pins to use them as I/O. (Used 43 of the 44 available pins )

[BigDumbDinosaur]

Code: Select all

pinnode   = extram;                  /* extended address latch   */
extram.LE = PHI1;                    /* open bank latch          */
extram.L  = PHI1 & D0;               /* capture A16 on clock low */
A16       = extram;                  /* synthesized A16          */

[GlennSmith]

Thanks, BDD, but IIRC you're providing your PHI1 from the outside, and it is a slightly delayed (ie the propagation delay through a gate) version of PHI2.
I didn't want to have to add other glue logic, but it's becoming a ridiculous position to maintain because :

• Your solution works

• I still have one unused pin to exploit

• The pico2 (it's already generating PHI2) could actually also generate a slightly delayed PHI1

-OR-

• Use a tiny, single 7400 gate, hidden underneath the board - perhaps no one would notice

[Yuri]

GlennSmith wrote:

Thanks, BDD, but IIRC you're providing your PHI1 from the outside, and it is a slightly delayed (ie the propagation delay through a gate) version of PHI2.

IDK, something about using the Pico to generate a clock would be weird; I guess it could be interesting if you're using the Pico as a debugger tho.

That being said, you could run the clock through the 1504 and then generate the inverted/non-inverted clock signals, but then the 1504 apparently doesn't produce CMOS voltage swings (see many a BDD post about this.)

Another option would be to feed the clock to a 74HC74 which would give you a pretty close to accurate PHI1 and PHI2 output; all be it divided by two.

A third option would be to use two XORs on the same 74HC86 package. For the few I've tested this gave me almost the same delay; though your millage may vary.

[GlennSmith]

Yuri wrote:

IDK, something about using the Pico to generate a clock would be weird; I guess it could be interesting if you're using the Pico as a debugger tho.

Sorry, but you've missed the point. This is a setup whereby the Pico2 is hosting many system functions (file I/O, KBD, UART, and more) and provides CLK and boot functions by 'spoon feeding' the 65xx processor. This leaves almost the full 64Kb (obviously even more on the '816) free for the 65xx. An API interface of 32bytes is used to access all the bells & whistles and many actions, like reading a file, happen so fast that you don't need to slow the 65xx clock : the pico is doing DMA transfers behind the scenes. I can tolerate some extra glue logic besides the CPLD (or - although the real estate costs $$$ for the PC fab - go to a 84-pin 1504) but I would have liked to find the *neat* solution within the CPLD - especially as it has LOTS of spare gates at the moment.
But thanks for your input and ideas.

[BigDumbDinosaur]

GlennSmith wrote:

Thanks, BDD, but IIRC you're providing your PHI1 from the outside, and it is a slightly delayed (ie the propagation delay through a gate) version of PHI2.
I didn't want to have to add other glue logic, but it's becoming a ridiculous position to maintain because :

• Your solution works

• I still have one unused pin to exploit

• The pico2 (it's already generating PHI2) could actually also generate a slightly delayed PHI1

-OR-

• Use a tiny, single 7400 gate, hidden underneath the board - perhaps no one would notice

How about:

Code: Select all

pinnode   = extram;                  /* extended address latch   */
extram.LE = !PHI2;                   /* open bank latch          */
extram.L  = !PHI2 & D0;              /* capture A16 on clock low */
A16       = extram;                  /* synthesized A16          */

I’m assuming you are providing your CPLD with the Ø2 clock.  An internal inversion inserts almost no prop delay.

[BigDumbDinosaur]

Yuri wrote:

IDK, something about using the Pico to generate a clock would be weird; I guess it could be interesting if you're using the Pico as a debugger tho.

That being said, you could run the clock through the 1504 and then generate the inverted/non-inverted clock signals, but then the 1504 apparently doesn't produce CMOS voltage swings (see many a BDD post about this.)

Correct.

The 1504’s outputs will marginally reach solid CMOS logic-one territory, but that’s under essentially open circuit conditions.  My testing has indicated that any kind of loading will pull VOH down and violate the MPU’s requirement that the clock reach at least VCC × 0.8 during the high phase.  Although CMOS inputs themselves generate virtually no static loading, the transition from logic zero to logic one will see loading due to parasitic capacitance being charged, plus some loading produced by the CMOS input as the voltage climbs toward VCC.  The problem is that the signal’s transition rate will slow before reaching the VCC × 0.8 and likely violate the requirement that clock input transition time not exceed 5 nanoseconds.

In a 65C816 system, the most foolproof way to generate Ø1 and Ø2 and keep them (almost) exactly 180° out of phase is by running the oscillator’s output through a 74AC74 flop and picking up the two clocks at Q and /Q.  I insert some series resistance, typically 120 ohms, into the signals to damp ringing.

The 816 has some tolerance for less-than-ideal clock quality, but not a lot...and that tolerance deteriorates the faster you run it.  I see no upside to tempting the devil with off-the-wall clock generation methods.

[GlennSmith]

@BDD : Thanks for your proposed alternative, I'll try it as soon as I manage to unlock one of my previous tries in order to reprogram them...

BigDumbDinosaur wrote:

I see no upside to tempting the devil with off-the-wall clock generation methods.

Really the only upside for using the Pico to generate the clock is that it is easy to program the speed - the on-board monitor allows the speed to be changed on the fly. Once all of this is proven, I'll probably stick to one speed in the end. I'm thinking, however, of changing the way the clock is generated (ie double the speed) in order to use the F/F method to generate the two clock phases. All of the Picos internal synchronization with PHI2 is done via the PIO engines, they don't care where the clock comes from.
BTW, I didn't think to say that all of this is currently running at 3.3v so no level-shifting required.