BigDumbDinosaur wrote:
Using a scope alone to determine if the ROM is stumbling would be somewhat awkward, although not impossible. The logic analyzer (LA) would be more helpful in that regard. It would be profitable to get proficient with the LA if for no other reason than to observe the circuit in action and become acquainted with what is going on as the 65C816 goes about its business.
Basically, you want the LA to look at when the ROM's /OE is asserted relative to the clock cycle, as well as observe when the ROM actually drives the data bus. That will tell you at what point in the read cycle the 816 will “see” the ROM’s output Since the ROM’s /OE must not be asserted during Ø2 low to avoid data bus contention, the ROM has less than half the total Ø2 cycle to respond to /OE and drive the bus. Specifically, it has to be able to satisfy the sum of the 816's tDSR (read data setup) and tDHR (read data hold) timing specs to guarantee that the data read is reliable. If the ROM can't meet that requirement, the circuit may become unstable or may fail to boot.
It’s important to understand that the 816 reads or writes data at the fall of the clock. tDSR is a period of time that precedes the fall of Ø2 and tDHR is a period of time that will elapse after the fall of Ø2. During a read cycle, the 816 will open its data latches no more than tDSR nanoseconds before the clock falls and capture whatever is on D0-D7. Ideally, the data latches would close at the fall of the clock, but in practice they will lag the clock by a couple of nanoseconds. Hence tDHR is specified to assure D0-D7 will remain stable until the latches are closed.
Officially, tDSR and tDHR are both 10ns minimum when operating on 5 volts—note that these values are independent of the actual Ø2 rate. In practice, you can fudge those numbers to some extent, since the 816 actually performs significantly better than the data sheet would lead you to believe. The 0.6µ cores that have been in production for the last 15-or-so years are capable of operating beyond 24 MHz on 5 volts, based on extrapolation of the published FMAX vs. VDD curve. This being the case, most of the critical timing minimums appear to be about 60-70 percent of the quoted values. Ergo tDSR and tDHR would be more like 6-7ns each, which would give your ROM a little more “headroom.”
A lot to digest there, but thank you very much!
I'll dig up my LA and see what I can find!
BigDumbDinosaur wrote:
To what would you wire it? In my circuit, the 109 is used as a one-shot timer that controls the clock generator flip-flop. By itself, it wouldn’t do anything for you.
I'm sorry, I wasn't being clear. By adding the 109 I meant wiring it up according to your POC v2.0 schematic, given that this arrangement seems to work well for you.
BigDumbDinosaur wrote:
The 28L92 will function in a system running at 14 MHz—at least in my POC units, but timing can be touchy at that point. If you can, you should arrange both ROM and I/O accesses (other than the 65C22) to be wait-stated. You really need a more sophisticated clock generation setup to successfully implement wait-states via clock-stretching.
Yes, I'll try to generate a separate /WSE so it can be used to wait-state accesses to the 28L92 as well. I thought I'd spent all available pins on the 22V10, but looking over it again I should be able to ditch at least one of the address lines going into it to free up another output.
BigDumbDinosaur wrote:
Ultimately, the efficiency of your glue logic will set a hard limit on performance. That you have the entire 16-bit address bus wired to the CPLD makes me wonder just how well this will work at double-digit clock rates.
I don't currently have 16 address lines wired to the PLD, only 10 (A10..19) - though, like I eluded to above, I could remove a couple of those as well.
But why would this have any effect on how well the setup works at higher clock speeds? I thought having _all_ glue logic in a PLD was actually advantageous as it would introduce a minimum of logic delay compared to chaining several discrete units? I'm using a PLD rated at 7.5ns input-to-output.
BigDumbDinosaur wrote:
One more thing...RAM and ROM generally perform best if /CS os asserted before /OE or /WE (RAM) are asserted. In other words, your glue logic should assert the appropriate /CS as soon as the 816 indicates it has a valid address on the data bus. That gives the selected device about one-half of Ø2 low to come out of catatonia and get ready for access.
Sticking with my single 22V10 PLD, /CS's, /OE and /WE will be output at the same time. Are you saying I should consider delaying the latter two a tiny bit? I don't see anything like that in your CPLD-based POC v2.0 schematic (I'm looking at one dated 2021/06/29).
Last question: I see you're applying a 2.2k pull-up on all the outputs of the 1504 CPLD - is that good practice on all PLD's in general or just this one in particular?