I think I want to keep my 8 bit NMOS core compatible with the original, but maybe I'll make a fork with the changes.

My machines were not 100% yet in order to verify testing yesterday, but I am closer and I will update my 65Org16.b fork as soon as I can verify, which shouldn't be too much longer.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Machines still not 100%, but I made the modifications to ABSX and INDY states and it works great! I was able to easily test STB($xxxx),y for video memory fill and it is noticeably faster. I updated the .b core on Github.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Arlet, what would be a good way to connect a SRAM, such as K6R1008V1C-10? Here is the write cycle timing...

I am not sure what would happen if WE is held low while address changes.

Have you ever hooked up an external SRAM to your core?

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

Enso, if you check the accompanying table, it says that the Address Setup time and the Data Hold time are both zero. So, a write cycle is simply Address+WE+Data all valid at the same time for one cycle.

Now, the big question: what happens when you keep WE low for multiple cycles ? I have never tried this myself. At first I assumed it was not allowed, so I always put a read or an idle cycle in after a write. But I did once find a design where somebody had actually kept WE low, and apparently without problems.

My theory is that it should be possible, as long as all address lines change within a very short interval. I figure that in an async SRAM, a glitch on the address lines will cause the wrong cell to be charged. However, since the SRAM cell is built from a pair of inverters, there's a certain amount of charge you have to move before it will flip, and moving that charge will take some time. That's what the datasheet refers to as the write cycle time, which is spec'ed at 10 ns. Of course, the 10 ns is a conservative number, and 5 ns may be enough time to flip the inverter. However, it is unlikely that less than 1 ns would be sufficient. And if you only move 10% of the charge, and then stop, the inverters will quickly restore the previous charge, so there's no residual effect that can build up over time.

So, I think it would be safe to keep WE low for multiple cycles, as long as you make sure there's not too much difference in address line traces.

Edit: Here's an old SRAM controller I once used on my core. It still has an extra idle cycle after each write to deassert WE.

Scary, isn't it? I guess I'll have to try a few things.

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

It's simple enough to try. If it doesn't work reliably, you could always insert an extra idle cycle.

If it does work, you can add some IODELAY to half the address lines, and see how much skew you can introduce before things break. That should give you an idea of the safety margin.

I am somewhat perplexed by the write timing of the async SRAMs. For reading, it makes sense - whatever is on the address bus goes in, whatever comes out is the result. For writing, there has to be either an internal state machine (which makes no sense as there is no clock), or a fixed delay after the write edge (which makes no sense for slower operation). It really makes sense the the WE edge is necessary. Sorry, I am off-topic.

Arlet, is it true that the whole issue of back-to-back writes can be avoided by putting page 1 into an internal BRAM?

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

For writes, there's no internal state machine, or a fixed delay. An SRAM cell is like a teeter totter. It is stable in two positions. Now, image the entire device is a row of teeter totters. Some are flipped one way, others in another.

When the WE is asserted it means that you push on one of the teeter totters. The address bits determine which one. Actually flipping one takes quite a bit of power, and some time. Now, image you hold WE, while you change the address quickly. The effect will be like running past a row of teeter totters, pushing down on all of them while you run, and finally stopping in front of the correct one and pushing for a full cycle.

As long as you run fast enough, and only push on them briefly, they will just bounce back. Only the one where you wait for a minimum time while you push will actually flip. The problem is of course that the datasheet doesn't spec how long that time is.


For my core, in it's current version, yes. But it's fairly easy to add some intelligence to the SRAM memory controller so that it will force a read or idle state after each write. This won't affect read-after-read, or read-after-write timing, so it's not going to hurt performance for those common cases.

I once came across the idea that async RAMs do derive a series of internal clock edges, self-timed and triggered from changes on the address pins. I don't know if that makes any difference or not: in both cases the idea is to move the addresses quickly and all together. The idea of writing without a strobe seems a bit dubious to me: might work out well enough in a hobby context.
Cheers
Ed

SRAM does seem to work as the stack page, with double writes.

Confirmed (preliminary) on 6502 playground running at 35MHz.

Runs a monitor, 3-4 surbroutine calls deep.

PS: more inline with the thread topic, using one BRAM only, Arlet's core runs at 100MHz on an XC3S700AN, speed grade 5.

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

Hmm, I think I was wrong about the SRAM working. After cleaning up the verilog, I am unable to get any subroutine calls to work if page 1 is mapped to the SRAM. I will do more testing after installing a proper monitor to make sure the SRAM is really working.

EDIT: The calls work, but the returns don't work, actually.

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

bc6502 likely can break 50 Mhz.
Although I haven't actually tested the core at that high a speed, it should easily break 50 MHz, if the toolset timings are accurate. This is on a Spartan 6 FPGA. Of course once built into a larger system, the timings slow down.

Timing Summary:
---------------
Speed Grade: -3

Minimum period: 8.484ns (Maximum Frequency: 117.866MHz)
Minimum input arrival time before clock: 8.459ns
Maximum output required time after clock: 10.235ns
Maximum combinational path delay: 10.759ns

_________________
http://www.finitron.ca

Thanks Rob - I've started to populate the table in the head post. It's still far from complete.
Cheers
Ed