Looking for a fast voltage translator

[exxos]

It is safe. But only as long as your logic and code is designed to work with OE enabled constantly. In this case, it is likely that is not. Seems that the code, either by design or by mistake, doesn't expect OE permanently enabled. May be the code issues some dummy ram read transactions, or something like that?

There is the possibility of implementing an intermediate solution. Don't enable OE permanently. Enable OE only when accessing RAM, but do it at least one cycle earlier than the actual read or write cycle. This way you are guaranteed that the OE timing wouldn't be critical. If you are already doing that early enough, then it means that OE timing is not actually the problem.

The original only enabled the buffers on TTram access.. it made sense.. But on one board it doesn't work. The only way it would work is to go on the raw decode for TTram addresses. Basically speeds up OE by like 10ns as its not going via the always (CLK100) block.

The ST buffers are (or was) basically a inversion of TTram decode. So either one or the other is enabled. Plus loads of other variations.

I'm trying OE tied low.. but its doing all sorts of strange things. It was looking like a spectrum loading earlier. Keeps going into 60hz.

Just it passed TTram, STram on boot up, loaded GB6.. I ran test, it reset, logo came up, reset again, now 60hz and screen gone yellow.

Next try..

IMG_4652.JPG

It will work fine if I disable the buffers on TTram access, and the other even more problematic board will boot fine if I disable the buffers totally.

But that's the thing which doesn't make sense because nothing should really care about TTram.. TOS just sees if its there, tests later. even if TTRam was totally fried, TOS should just show XXXXXXXXXXXXXXX on boot up and if nothing is loaded into TTram, then nothing should care.. but it never plays out like that. As soon as thoe buffers are enabled, odd things start to happen..

power cycle..

IMG_4653.JPG

Then its fine again.. Now running GB6.. But I did just unplug the program at that time as well.. Very suspect at that at the moment..
But just locked up on justified VDI text..

[ijor]

The original only enabled the buffers on TTram access.. it made sense.. But on one board it doesn't work. The only way it would work is to go on the raw decode for TTram addresses. Basically speeds up OE by like 10ns as its not going via the always (CLK100) block.

I'm not sure this makes much sense. You shouldn't need to enable the DRAM buffers so early. This is DRAM, not SRAM. The actual read/write operation doesn't happen immediately. There a few cycles latency since you start accessing the DRAM until you need the data bus to be enabled.

The ST buffers are (or was) basically a inversion of TTram decode. So either one or the other is enabled. Plus loads of other variations.

May be then the problem is related to the ST buffers timing, not strictly to the DRAM output enable speed. Or at least may be that was the problem for that particular card that didn't work otherwise. But this is not much more than a guess.

I'm trying OE tied low.. but its doing all sorts of strange things. It was looking like a spectrum loading earlier. Keeps going into 60hz.

Again, this suggests that the code, may be the DRAM controller, is not designed, or not correctly implemented, to work with the buffers OE permanently enabled. It doesn't mean that tying OE low is inherently bad.

But again, even if you enable the data bus only after decoding a TTram access, you should still have plenty of time. Doesn't sound like the problem could be the chip OE speed.

[exxos]

I'm not sure this makes much sense. You shouldn't need to enable the DRAM buffers so early. This is DRAM, not SRAM. The actual read/write operation doesn't happen immediately. There a few cycles latency since you start accessing the DRAM until you need the data bus to be enabled.

Yeah true, nothing about this project has made since since day 1 :)

May be then the problem is related to the ST buffers timing, not strictly to the DRAM output enable speed. Or at least may be that was the problem for that particular card that didn't work otherwise. But this is not much more than a guess.

Its pretty-much, buffers are disabled on TTRam access or AS30 high. If AS30 goes low, and its not TTram, buffers are enabled. On 8mhz cycles nothing should really care.

Again, this suggests that the code, may be the DRAM controller, is not designed, or not correctly implemented, to work with the buffers OE permanently enabled. It doesn't mean that tying OE low is inherently bad.

I think @Badwolf used similar or the same module in the DFB1 ? But its the same problem I have all the time, that I just keep going around in circles. Like now, one board just wouldn't boot at all, had a reset fit, now its running GB6 just fine. Well ok it ran all tests then locked up.. that seems repeatable oddly.

But again, even if you enable the data bus only after decoding a TTram access, you should still have plenty of time. Doesn't sound like the problem could be the chip OE speed.

Yeah, but why does speeding it up help.. If anything it should make things worse as its likely to clash with the end of STbus cycles.

I'm looking at the 6800 module again currently. I wonder if some 8bit access is stipping up somewhere. It might explain that "Bad rom chip in E" and might explain some odd things..

But like this image..

preview.png

Unless the code is broken, its not copying the second word at all.. But the same verification loop ran from desktop, and it passes..

Its also odd that last week, TTram test would come up XXXXXXXXXXXXXXXXXXXXXXXXXXX and yet YAARTTT would work fine.. Turning caches off helped get past those issues. But still wasn't stable at desktop.

EMUTOS is unhappy also. Locked up loading GB6. When I rebooted...

IMG_4655.JPG

Why is it trying to access address 0 after a boot up ?!

Then like a couple weeks ago, I had it running like 3 days, day and night doing GB6 and YAARTTT without fail. Even back on "day 1" I was circling weird TTram issues. Then generally if I disable the TTram buffers totally, it would work better.. Just tried that now in fact, and it just locks up after it fails to copy ROM to TTram.

Its like the faults keeps moving and changing at random. Its why the last board respin I added a lot more caps and better regulators. I think it did help, but not a solution. The whole thing makes no sense :(

Its why I am still thinking this could be a odd PCB fault. Like maybe the inner layers are not good enough for the power planes. On the next revision, I doubled up on those as much as possible.. but reluctant to get those made as its only a guess.

Tried again, clear STram corruption on this bootup.. but no idea why. I thought it could be my clock switching code, but the original TF one didn't change anything either.

IMG_4656.JPG

[ijor]

But again, even if you enable the data bus only after decoding a TTram access, you should still have plenty of time. Doesn't sound like the problem could be the chip OE speed.

Yeah, but why does speeding it up help..

No idea. Could be lots of things.

But you have to investigate the reason. Fixing something, or apparently fixing something, without knowing why it didn't work before, and why it works now, is prone to be a not very reliable fix.

I'm looking at the 6800 module again currently.

May be. I really don't know. But as I said some time ago, you have to address this methodically. Throwing ideas, IMHO, is not the best approach to solve this.

Its why I am still thinking this could be a odd PCB fault. Like maybe the inner layers are not good enough for the power planes. On the next revision, I doubled up on those as much as possible.. but reluctant to get those made as its only a guess.

Not sure this is very likely. All components are CMOS, no old school TTL logic, right? How much power this is going to need? Probably not very much. With all the high speed DRAM signals, if it is a board layout issue (not saying it is), it is more likely to be a signal integrity issue than a power integrity issue. As I commented on a similar issue on other thread, it might pay to protect at least the clock signals, especially the DRAM clock, as much as possible.

But again, without a basic and methodical approach, it is mostly shooting in the dark.

[exxos]

@ijor i think you might has missed a lot of posts. I've been working though a lot methodically for about a year now. I've found issues with lots of signals and building in fixes as I find them. More recently ras cas sterm noise. Hence adding series resistance.

Cmos has faster higher switching transients, not like more steady state power draw like TTL has. Powerdraw isn't a issue. Switching transients are. For CMOS, the transient is so fast that the round trip inductance is effectively a high impedance at that frequency. On the power rails for the PLD, that's extremely bad and proven to be an issue. Most of which was addressed in the latest revision pcbs. I've improved more on the next board as well.

[ijor]

@ijor i think you might has missed a lot of posts. I've been working though a lot methodically for about a year now. I've found issues with lots of signals and building in fixes as I find them. More recently ras cas sterm noise.

Sorry, I probably used the wrong term and didn't express myself correctly.

In first place, I mostly meant about the CPLD logic, which is my main expertise, not about electrical or PCB issues. What I meant by methodical, is what I mentioned some time ago. Perform comprehensive timing analysis, run extensive simulations, try to follow rigorous synchronous design principles as much as possible. Those should be done before even programming the CPLD. Then setup software and hardware tests to verify individual sections of logic separately. Take traces with a logic analyzer and make sure they match your simulation. Etc ...

Again, as I said before, this is a lot of work, I know. But this is the correct approach.

Cmos has faster higher switching transients, not like more steady state power draw like TTL has. Powerdraw isn't a issue. Switching transients are. For CMOS, the transient is so fast that the round trip inductance is effectively a high impedance at that frequency. On the power rails for the PLD, that's extremely bad and proven to be an issue.

Ok, may be I misunderstood. But are you saying that the power rails can't deliver enough dynamic power? This CPLD is known to work fine with routed power on two layers PCB. You are using, I understand, full power planes on a four layers PCB?

[exxos]

Again, as I said before, this is a lot of work, I know. But this is the correct approach.

Yeah I agree.. Its beyond my "pay-grade" though all that is unfortunately. I've taken a lot of scope measurements to verify things are timed as I expect them to be and so far everything seems fine to me. I'd assume it was all done when the TF536 was designed in the first place. But since then I've have added stuff, who knows.. probably all sorts of issues now. But I never got the original 536 stable on my machines anyway, which is why I started this epic on designing the ST536 version. I thought it be a "simple" port, but the more I go down this road, the more complicated its all becoming. The code isn't even that complicated. But mixing in glitchy signals from the ST is one layer of chaos right from the start. I'm a n00b at verilog which isn't helping. But the more I study everything the more problems I find.

Ok, may be I misunderstood. But are you saying that the power rails can't deliver enough dynamic power? This CPLD is known to work fine with routed power on two layers PCB. You are using, I understand, full power planes on a four layers PCB?

The original regulator was a "jelly bean" type, I uprated it to something which is supposed to deal with fast transients better. Also added various capacitors as I saw all sorts of spikes on the 3.3V rail. 2 layers are used for power, and are solid. Though the inner layers are not as thick copper as top and bottom. So resistance could be a factor not just loop length.

On the original 536, the regulator was to one side of the board. The loop area from the regulator to the SDRAM and back was rather long and the SDRAM had the worst spikes on its rail. Its also why I split the 3.3V rail into "PLD power" and "SDRAM power" . Both driven on their own regulator and greatly shortens the overall loops. Plus added series resistance to stop bad ringing. All the changes seem to bring improvements. I mean there is no use trying to debug stuff if the power rail isn't the best it can be first. Which is why i've been working more on the hardware side of things as there is only so many firmware tweaks humanly possible to do.