If there's nothing driving it at that voltage, the capacitance would have held it at the last driven voltage.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Curious. Perhaps more decoupling is a good idea. However, I have many of these boards running without obvious problems. Perhaps that issue causes the 45MHz speed limit...

It looks very suspiciously steady at 2V after the initial transient. Definitely slowing down the works...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Yes, but the last driven voltage is either 0V or 3.3V, and then you'd expect a slow (dis)charge curve away from that. Now, I get this rather abrupt and stable transition to 2V.

I suspect what happens is that the output driver is switched off during the transition.

This is a combinatorial output, so there's unpredictable timing between the 'di' and 'we' changes. I don't think it's affecting performance.

Generally, you should use registered outputs so all your outputs change cleanly and synchronously.

which is why I don't think it's a high-impedance phenomenon. There's probably bus contention.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

If it's a bus contention, it wouldn't change so dramatically when I touch the pin with my finger (see capture)

Ah yes, that's definitely different.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I've seen this crazy pattern before, but I can't remember what it's related to. It looks like an artifact (produced by the scope), as it is a chopped up sine (or similar) wave, much like a Fresnel lens. Definitely seen it before...

I'll take a look. DI bus is a large OR gate that ors in a bunch of inputs that are generally registered, but in case of the SRAM I suppose they are not. I am not sure how to register SRAM output without incurring further slowdowns.

Could it be some kind of metastability that resolves itself? I should probably enable pulldowns on the SRAM input pins.

There are a couple of other possibilities I will check into.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

That's one of the coolest-looking scope waveforms I've ever seen! I forgot to look before posting ... is this a
'working' circuit?

Mike

My take on this: the short discontinuities are the real action where the 6502 core is writing to the data bus. The intermediate wavy parts are when the bus is in hi-Z state, and my finger charges/discharges the bus capacitance.

The fact that it doesn't look the same is because the bus driver is switched off just in the middle of a transition (because it's mixing a bunch of combinatorial outputs together)

The SRAM module does flop in the data:


The initial 'xin' combinational assignment simply activates the tri-state circuit inside the BUFG. The 'always' clause afterward flops in either 'xin' or 0 (to allow final OR circuit to work). Oh, wait, the output is not flopped, but it goes to the SRAM, which is asynchronous...


The SRAM data lines in the .ucf files do not pull down, and they should. I am sure that is the issue. I don't have a scope fast enough to check, but I will create a new bitstream and post it ASAP.

I am working on cleaning up the build environment (it is somewhat convoluted) and will post a buildable verilog system with a Makefile as soon as I can. The intent is a completely open system, of course.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I'm talking about this part, that drives the databus:

di = CPU_DO, and we = CPU_WE. Both DO and WE enable signals are combinatorial outputs of the CPU module.

Here is the new bitstream, same as 003 but with pulldowns enabled on the SRAM databus interface.


Arlet, if you have a few minutes, could you check if this bitstream exhibits the same behaviour against 003? My scope is way too slow.

Thanks for your help.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Funny thing - I had certainly meant to pull down the lines, the comment even says so... Lost in the shuffle.

EDITED I thought it ran at 60MHz, but no.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

This is what it looks like now. It's getting pulled down, as you'd expect. But it's only a cosmetic thing. There's no problem with weird voltages if nobody's reading the data.

LED is blinking faster too.