And here's a picture of the bottom of the board, with the 1.2V regulator, and the bypass caps. Light brown = 0.1 uF, dark brown = 10 uF. The 3 caps at the bottom are under the SRAM.

Thanks for sharing that 12mA wave in your earlier post...

Interesting, only 3 bypass caps for your asynchronous SRAM.

There are 12 separate VDD-VSS pairs in the Synchronous RAM I'm using, which should tell any designer the stress the engineers put in the importance of bypassing this device. Which, knowing this, I still try to get away with as much as I can due to the confidence I have with my power distribution!

EDIT: In my design I put provisions for 2 bypass caps on each VDD-VSS pair "just in case", especially since there was room for this in the layout. I've noticed in designs by DigilenInc that they have some caps in parallel, so it can't be just a simple addition of capacitor values? or can it?

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

My RAM only has 2 VDD-VSS pairs, both in the middle of the device, on opposite sides, so I put a cap under each pair. I don't think there's a benefit to adding any more.

Of course, I haven't run any real stress tests yet.

No, the idea is that you use 2 caps of different value, each offering a low impedance path to ground, but at different frequencies. Combined, the low impedance path has a wider frequency range.

I've always wondered about this, just to clarify...

So the multiple bypass caps of different values in parallel are like multiple notch filters bypassing at their different frequencies? and it is not a simple addition of capacitance?

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

That's more-or-less right, because each one is like a capacitor and inductor (and a little resistance) in series.

_________________
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?

Excellent Garth, thanks for your expert input. You clearly excel in this area of board design!

I must retreat now into my 65Org16.b software and drink much coffee.

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

And of course, the inductance is also dependant on the board layout. For instance, I have my caps at the bottom, which adds a extra little inductance from the via. And TQFP packaging also adds more inductance than BGA (probably more than the vias).

Aiming in the dark here, but for the 2 bypass values that will be in parallel on each SyncRAM VDD-VSS pair of power pins, I think .1uF in parallel with .001uF should be most effective for close to 100MHz operation?

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

_________________
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 you put the vias in the pads, or really close, they'll wick the solder paste during automated assembly. It won't make a mess, but it'll make for a very dry joint, as most of the solder will end up in the hole. Also, 2 lead components, like small caps may get pulled towards the other pad to the point where they tombstone, or don't make any contact at all.

For practical purposes, I mostly use 0603, and then I pick 0.1 uF, 50V, X7R types for bypassing. These are quite cheap (about $15 for a reel of 4000). While 0402 may be better, their small size makes them a bit more impractical for hand assembly. It's easy to get bigger capacitance in 0603, but with the higher prices, it doesn't make it attractive to sprinkle a board with those. So, that's why I settle on 0.1 uF as a good compromise, and add a few 10uF/10V here and there.

@ElEctric_EyE, another thing to keep in mind is that a lower drive strength reduces instantaneous power consumption by the output drivers when switching multiple output pins at the same time. So, it's better to minimize drive strength, as long as the edges don't become so slow that they mess up the timing. But if you still have, say, 6 ns of timing budget, an extra 1 ns delay from a softer edge won't hurt, but it will help current spikes, and will make optimal bypass cap selection and placement less of an issue.

Of course, we can only control the drive strength of the FPGA, not the SRAM.

By the way, can you explain how you implemented your IODELAY ? I started reading the Xilinx documentation a little better, and started some experiments of my own. For instance, I had assumed there was only an output delay, but I saw that I was wrong about that, and that you can also apply an input delay, or even both input & output delays on the tri-state signals. Given that, an input delay applied to the data signals would seem most appropriate.

Here's a scope image from the SRAM interface. I have an input delay, but based on some experiments, it should be close to zero, so I might as well take it out.

Every division is 10 ns, which is about 1 clock cycle. As you can see, I generate 1 cycle OE pulse (top trace), which results in a edge on a data output D0 from SRAM, after about 6-7 ns, well within the max access time of 10 ns according to datasheet.

On the bottom trace, you can see how the FPGA reads the data, and outputs it on a GPIO pin. Round trip propagation delays from FPGA Q -> SRAM -> FPGA D look like they're about 5 ns, so with a 100 MHz clock, you can grab the data in the middle by just waiting 2 clocks, without any extra IODELAY. It's probably not much different on your board.

I've not figured out how to implement it yet. I've read that one can do it 1 of 2 ways. Either through a .UCF constraints file, or a special comment right before the 'module' declaration. I sort of gave up on the IODELAY since I couldn't figure it out. The progress I've made has been without IODELAY and using my own code for bi-directional comm. from/to the SyncRAM to the FPGA, very simple code but the RTL looked correct. In learning Verilog, the representative RTL schematic seems to be the bottom line to see if the code has been inferred correctly.

I'm about to put this board though a more stringent test very soon. Clearing screens, reading repetitive data and modifying it with a logic values and writing it back is not a real test...
I'm 1 step away from plotting 8x8 pixel characters anywhere within the 640x480 display RAM, then reading that data and replotting it. But I also am focusing on getting the cpu back up to 100MHz...

I had saved that project file immediately when I was successful with a 25MHz pixel clock at 100MHz cpu clock. The only thing that made it unsuccessful immediately afterwards was adding another blockRAM for the character ROM and the address decoding. Time for me to go 1 step backward, then hopefully 2 steps forward. I plan to use 1 blockRAM for zero & stack page at the bottom of memory, video ram starting right in the middle, and the OS and Character ROM at the top of the 4GB memory map.

A 100Mhz .b '6502type' core has always been my goal. I will strive to keep this speed and will go to great lengths to maintain it. This is where the .b core might start to morph, if all that is left to maintain speed is to start trimming address modes.

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

Thanks for the time your put into researching that info Garth! I will thoroughly check them out... Should be information to consider for the final PVB board design.

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