Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
|
Well, I’m behind the eight ball on updating this topic, but do have progress to report.
POC V1.4 is assembled to a point where I can run a NOP ROM in it and look at what is going on in the circuit. Succinctly stated, it goes at 15 MHz, is unstable at 16 MHz, and blows at 20 MHz. So 15MHz appears to be the Ø2 “ceiling” with this design. Disappointing, needless to say, but something of value always seems to come out of failure.
Also, I made an interesting discovery involving power delivery to the unit, which I’ll get to before diving into the clock contretemps.
Here again are the schematic and PCB layout for the unit:
Attachment:
File comment: POC V1.4 Schematic
pocv140.pdf [377.59 KiB]
Downloaded 57 times
Attachment:
File comment: POC V1.4 PCB
poc_v14_pcb.gif [ 411.99 KiB | Viewed 124659 times ]
First the power discovery...
As can be seen on the PCB layout, power is applied to the unit through a Berg connector, a standard part on 3-1/2" floppy disk drives. Given its original application, one would expect it can easily handle the current required to run a POC unit. So I had not given it any thought in that respect, since the POC version on which I started using it, V1.2, works, as does V1.3.
As I was analyzing the Ø2 ceiling problem, I decided to poke around a bit with the DMM to see how VCC looked. At the power supply’s output, I got 5.09 volts under load. However, at pin 1 of the Berg connector, which is where 5 volts comes in, I got 4.90 volts. Granted, a loss of 190 millivolts in itself isn’t earth-shaking, but all my timing calculations assumed everything is powered at 5 volts. So the thought had occurred that the Ø2 ceiling was due to the hardware running at slightly reduced voltage, which I’m now reasonably certain is not the case.
While contemplating this little discovery, I decided to find out where the loss was. The power supply with which I’m testing doesn’t have a Berg plug, just the usual Molex type you see plugged into parallel-interface hard drives. To make the connection to the POC unit, I’m using a commercially-made Molex-to-Berg adapter, which is nothing more than a Molex male connected to a Berg female through about 4 inches (102mm) of what appears to be 22 gauge wire. It is in that adapter where those 190 millivolts are disappearing.
As for a cause, V1.4 has a 22V10 GAL to handle most of the glue logic. GALs tend to be power hogs and thanks to the GAL, substantially more current is being drawn through the Molex-to-Berg adapter than with the older POC units. Ergo some voltage loss. In a bit of irony, POC V1.0 and V1.1 both had Molex receptacles for the power supply connection. I replaced that item with the Berg connector to save PCB space and also because every time I go to unplug a Molex connector it becomes a struggle for my old, tired hands. 
Meanwhile, back to the Ø2 ceiling. Below is an annotated logic analyzer trace of V1.4 coming up at 15 MHz:
Attachment:
File comment: POC V1.4 Boot @ 15 MHz
poc_v14_boot_15mhz.jpg [ 1.57 MiB | Viewed 124659 times ]
At that speed, everything appears to be copacetic, and in fact, periodic sampling of bus activity showed that the 65C816 was merrily working its way through a loop full of NOPs.
Now, here is another trace, this one of V1.4 coming up at 20 MHz:
Attachment:
File comment: POC V1.4 Boot @ 20 MHz
poc_v14_boot_20mhz.jpg [ 1.68 MiB | Viewed 124659 times ]
This time, the train goes into the ditch as soon as the MPU places the reset vector address ($00FFFC) on the bus. The 74AC163 counter fails to react in time to /WSE (wait-state enable) being asserted and Ø2 continues to run at full speed for another cycle. The ROM can’t keep up, the MPU gets a garbage address and it’s all down hill after that. Adding to the fun, the AC163 does finally respond to /WSE during the low phase of the next clock cycle, definitely a case of locking the barn doors after the cows have wandered off.
As a harbinger of things to come, note system behavior when the spurious ROM select occurs as the MPU is going through initialization following the clearing of reset (three cycles after reset clears). The AC163’s behavior is identical to what happens when the MPU is finally ready. Clearly there is a timing issue involving the AC163 and how quickly it can react when /WSE is asserted. My analysis may be off to some degree and I fully expect attempts to shoot big holes in it.  But, here goes...
POC V1.2 was the first unit in which I used the AC163 as a clock source. You may recall that it was an exact adaption of Jeff’s clock-stretching circuit described here (in fact, he built the module for me). V1.2 was stable at 20 MHz, although a more detailed look at things now indicates the AC163 I used in that unit was punching well above its weight class. In any case, there was no extended RAM in that unit, which made the glue logic less complex than later units, with a correspondingly-reduced prop delay. The glue logic could assert /WSE more rapidly, which when combined with an AC163 running substantially better than specs, made it work.
According to the AC163 data sheet, tsu, which is the required setup time for the A through D inputs before the clock input goes high, is 4.4ns minimum, operating on 5 volts and anywhere within the commercial temperature range. That is, as long as an A-D input is stable at least 4.4ns before the rise of the clock, things will work. That timing margin seems manageable until you consider that tsu is relative to the 40 MHz oscillator driving the clock input. In other words, the 4.4ns minimum is relative to the 12.5ns half-cycle period of the oscillator. At that speed, the timing margin available to satisfy tsu would be 12.5 - 4.4 or 8.1ns. So at first blush, it would appear things ought to work.
In this application, the AC163’s B input is controlled by /WSE, the latter which is generated by the GAL. The GAL I’m using, a Microchip ATF22V10C, is rated at 7.5ns tpd pin-to-pin. All logic in the GAL is combinatorial, so the worst-case prop delay from when the MPU does something until the GAL’s outputs reflect the change will be 7.5ns. That would seem to be within the previously-quoted 8.1ns margin available to meet tsu. However, here comes the “gotcha”...several of them, actually. 
The MPU is running at 20 MHz, not 40, which means the GAL is reacting to events that occupy two oscillator cycles, not one. That 8.1ns margin I earlier mentioned is relative to the 40 MHz half-cycle period, which is 12.5ns. The Ø2 half-cycle period is 25ns, which effectively makes the 8.1ns look like 4.05ns for timing purposes. The GAL can’t respond in 4ns, so it is unable to assert /WSE quickly enough to meet the tsu deadline.
Above, I said there were several “gotchas.” The other one, which appears to be the final nail in the coffin, is the AC163’s tpd, which is the prop time from when the (oscillator) clock goes high until a change is seen at any Q output. The worst-case for tpd running on 5 volts is 9.4ns. The logic analyzer says the AC163 in V1.4 is running right around 6ns—“punching above its weight class.” Hence a Ø2 phase change lags an oscillator cycle by a more-or-less constant 6ns, which further messes up timing.
Given what I’ve learned from this, I’m less confident in the synchronous counter method of generating a stretchable clock, at least in a circuit that is intended to run faster than 15 MHz. The logic analyzer traces show that while the GAL can quickly assert /WSE in response to the address on the bus, the timing is too skewed relative to the oscillator to be reliable at high speeds. At 15 MHz, the GAL in V1.4 takes only 4ns from the time the MPU drives the address bus until /WSE is asserted. Unfortunately, that looks like 8ns from the perspective of the AC163, since its timing is slaved to the oscillator’s signal, not Ø2. The 6ns skew from the oscillator to Ø2 aggravates the situation by making it look like 14ns to the AC163. Hence the results.
It looks like it’s back to the metaphoric drawing board. 
_________________ x86? We ain't got no x86. We don't NEED no stinking x86!
Last edited by BigDumbDinosaur on Mon Nov 06, 2023 12:30 pm, edited 2 times in total.
|
|
Login
Register
FAQ
Search
