6502.org

That was it! I put IBUF back in too.

Now how do I get a nice clean pic from your testbench like you've shown earlier? There are some interesting video artifacts I need some clues on how to get rid of.
I ran ISim, after I commented out $recordfile, $recordvars. ISE didn't like those.

Does it also complain about '$fwrite()' and friends ? If not, check if there's a 0000.ppm made somewhere. If so, that should be an image of the first frame. It's in .ppm (portable pixmap format), but any decent graphics viewer should be able to open it.

I don't see $fwrite anywhere in the tb.v file...
I forgot this is reading from RAM too, so it's not going to work unless the verilog model takes into account the random nature of data after power-up?

$fwrite is on line 51 and 58, and SRAM modules don't usually randomize the contents. You can do this yourself, though. Either read the SRAM from a file, or write the contents in 'initial' block from the test bench.

Here's what I did for the Micron SDRAM on the previous board:

I forgot to ask, since one is able to program the FPGA with/without any of the 2 PROMs present. Were you programming the FPGA direct?

Yes, I always programmed it directly. I'll try programming a PROM later, and see if that works. Did you already verify that it works ? Without a jumper, does it load the first or second ?

Edit: tried programming both PROMs, and pushing the button. Nothing happens.

One of the first things I did was to make sure I got the numbering of the PROMs correct.
After reading the datasheet of the tinylogic 2x1 MUX, it says all inputs have Schmitt triggers so I would assume if you don't have a jumper to pull-up or pull-down the select pin it would naturally/reliably go to GND which selects the #2 PROM. I tried it and it seems this is so.

Unfortunately you've sllghtly misinterpreted what a Schmitt trigger does, EE. It can resolve a noisey or slowly-changing input into a crisp, valid 1 or 0 result, but it doesn't replace a pullup/pulldown. Sounds like you need to add a pulldown; otherwise you have a high-impedance input that's left floating.

If there's some contamination or other stray resistance on the PCB then the input might float high (or low) by itself. It's not reliable, of course. A floating input can also turn your circuit into something resembling a Random Number Generator

http://en.wikipedia.org/wiki/Schmitt_trigger

cheers
Jeff

Thanks for clarifying Dr.Jeff. I think I've read about using one as a random number generator in another thread in the hardware section. PaulF's comment there...
I guess the jumper is mandatory then. I think Arlet was trying to get away with a working board, using absolute minimum parts.

It's more like I just didn't know how the board is supposed to work, so I'm just guessing.

Oh ok... I thought I did a good job explaining the workings in the head post. Check where the word 'design' is in boldface. I do need to update it though, because it does not talk about the 4 programmable switches that's been added but it's accurate.

You're using something like fig 2-2 from UG380, but with the two PROMs chained together, and the two DO outputs going into a mux to the FPGA DIN ?

I just checked, and I don't even see a clock.

Correct, similar. Except my setup goes Connector->PROM1->PROM2->FPGA. You don't mean TCK? That's there...
EDIT: Sec, I see what you mean...

It's there. Pin 70 of the FPGA to pin 3 of PROM1, then it snakes through/around the JTAG connector before it goes to PROM2.

I mean, I don't see it wiggle on the scope when I press the button or power up the board.

I see 2MHz square wave for just about 1sec.

I guess that's the part of the FPGA that's cooked or the pin isn't soldered? Strange. You don't even need that signal when you're programming the FPGA direct without a PROM. I would think it should still output the clock though...