Looking for a fast voltage translator

[exxos]

This has been driving me nuts..

The original TF536 buffer is a SN74CB3T3245PW (but EOL now) . Problem is, its enable/disable is a bit to slow at 8ns (yes really)

The ones I went to are TI SN74CBTLV3245APWR Faster at 6.4ns, but the oops, not 5V tolerant.

So ideally I need something along those lines bought 5ns or faster, which seems impossible :roll:

Other chips have a direction control or dual supply but not having much luck that way either. Direction control I suppose could be possible that it was wise to RW directly, I think RW asserts before AS.. So it shouldn't delay things I think...

It's a bit of a conundrum because the buses are basically multiplex between the ST side bus (5v) and the 3.3V bus on the SDRAM. So the SDRAM buffers always end up seeing 5V from the bus or CPU (im assuming the CPU has week pullups to 5V) But either way, the ROM is there 5V anyway..

Basically needs some sort of solution that can do voltage translation 3.3 V <> 5V and have a very fast propagation and output enable delay.. Propagation delay of the current chips is <1ns so thats fine, but the OE needs to be at most 5ns... I don't think such thing exists :(


EDIT:
Maybe someone can confirm the CPU can use 3.3V pullups on the databus, maybe it will be simpler if I put the voltage translator on the 16bit bus, and moved the 030 databus to 3.3V only, wire it direct to the SDRAM via 3.3v fast buffers (no translation) ..

EDIT2:
Actually I think SDRAM isolates its own databus anyway ? Otherwise it would be impossible to link it direct to a databus without isolation buffers ?
If the CPU databus can be pulled up to 3.3V then other than the ROM, have the whole 536 databus 3.3V, and put the translation on the 16bit buffer for the 5N ST bus.. would seem a lot easier to do it all that way. :shrug:

[Badwolf]

EDIT: maybe someone can confirm the CPU can use 3.3V pullups on the databus, maybe it will be simpler if I put the voltage translator on the 16bit bus, and moved the 030 databus to 3.3V only, wire it direct to the SDRAM via 3.3v fast buffers (no translation) ..

Not sure I follow this. You can pull the databus to whatever voltage you like within the 0-5V range, but the CPU will drive the data lines high when it needs to (5V!) so translation is always required.

Why is 8ns too slow on an ~60ns cycle?

I don't even disable the buffer chips on DFB1. The DQM lines are perfectly cromulent.

BW

[exxos]

Not sure I follow this. You can pull the databus to whatever voltage you like within the 0-5V range, but the CPU will drive the data lines high when it needs to (5V!) so translation is always required.

Yeah that's what I was asking, does the CPU actually drive a logic high to 5v.. Well that's that idea at the window then really....

Why is 8ns too slow on an ~60ns cycle?

Good question, no idea.. The board which doesn't work as 8ns OE, the board which does work has 6ns OE. BUT, I moved the OE timing to a faster logic path and it seems to behave better (but not the board with 8ns buffers) . So basically making OE faster by about 10ns. For some reason that seems to work. At least so far.

The board which still doesn't work, I would have to change the chips to prove the point.. But then I won't have a board of slower chips to experiment with without swapping them back again :roll: but that's probably my only next valid move now..

I don't even disable the buffer chips on DFB1. The DQM lines are perfectly cromulent.

If I don't disable then it doesn't boot up at all.

[Badwolf]

If I don't disable then it doesn't boot up at all.

It sounds like you've got other issues then & are chasing ghosts here. You should be able to tie it open.

https://github.com/dh219/DFB/blob/main/ ... 1r5.v#L232

BW

[ijor]

Basically needs some sort of solution that can do voltage translation 3.3 V <> 5V and have a very fast propagation and output enable delay.. Propagation delay of the current chips is <1ns so thats fine, but the OE needs to be at most 5ns... I don't think such thing exists :(

Without schematics (may be you could post a logic diagram?) is a bit of a guess, but ...
Are you sure you need OE control at all? If your concern is the DRAM chips driving constantly the data bus, they don't. DRAM drive the bus only when accessing it.

(im assuming the CPU has week pullups to 5V)

Nope, no pull ups.

Maybe someone can confirm the CPU can use 3.3V pullups on the databus, maybe it will be simpler if I put the voltage translator on the 16bit bus, and moved the 030 databus to 3.3V only, wire it direct to the SDRAM via 3.3v fast buffers (no translation) ..

Why you would need pull ups on the data bus? If you are thinking that the CPU output is open drain, it is not. The CPU will actively drive the data bus when writing using totem pole drivers.

If I don't disable then it doesn't boot up at all.

That suggests there might be a bug, or a problem in the CPLD code, then.

[exxos]

You should be able to tie it open.

About a year ago I did enable it all the time and it seemed to work.. But wasn't sure it was a good idea? ..But last week when I was trying it it would not boot up at all..

I just tried it again now it seems to be booting.. Passed TT and STram test then the monitor went into 60hz and locked up.

[exxos]

Without schematics (may be you could post a logic diagram?) is a bit of a guess, but ...

99% the same as the TF536 schematics.

Are you sure you need OE control at all? If your concern is the DRAM chips driving constantly the data bus, they don't. DRAM drive the bus only when accessing it.

Last time I thought about it I somehow convince myself that it wasn't a good idea to have it enabled all the time. I did actually do this on the firmware last year but decided against it but cannot remember why now.

Like I just posted in reply to bad Wolf, it malfunctions if OE isn't used.

That suggests there might be a bug, or a problem in the CPLD code, then.

Maybe, but I haven't yet been able to discover what, I mean my code isn't that much different than the original anyway. Though I couldn't get the original TF536 stable, which was why I started down this rabbithole in the first place :(

But if you guys are convinced that OE is safe enabled all the time, I will do that and take it from there.

[Badwolf]

But if you guys are convinced that OE is safe enabled all the time, I will do that and take it from there.

I am and I would. It reduces your variables.

BW

[exxos]

I am and I would. It reduces your variables.

:2k2:

Now I've just found out that if the JTAG connection is loose, it causes the thing to crash.. I wonder how many times i've been victim to that so far :roll:

[ijor]

But if you guys are convinced that OE is safe enabled all the time, I will do that and take it from there.

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.