Memory upgrade.. oh yeah!

[alex]

Since I was ordering parts from Digikey anyway, I thought I'd upgrade my "prehistoric" experimental hardware version 0.1 Papilio Plus so here we are, my shiny Papy now struts a 64Mbit Macronix flash and a 512Mbit x16 SRAM.

Curse you Jack for not routing that extra pin even if it was a NC on the original chip, had to use a 0.2 mm enamel wire to bring my top address bus bit back to the FPGA.
Did it work? I hear you ask, ohhh yeahhh... and what better way for the first test than to flash Bombjack and have a quick game since it test both the SRAM and the FLASH chip where the game ROMs are stored.

Hey Jack, not that I don't love the flashy gooey noob friendly Papilio Prog 2.2 but is there still an old skool, command line, Windows executable that will let me burn the bitstream to the Macronix flash?

[Jack Gassett]

Alex,

This looks great! Sorry for missing that last address line, I felt pretty stupid when I realized I missed it.

I had a feeling some people would prefer the old tools so I included a "scripts" directory in the new Papilio Loader install that is the old stuff. You can just go into the scripts directory and associate bit files with the Papilio_Programmer.bat file to have the old stuff in place.

Looks like a real nice soldering picture there!

Jack.

[alex]

Yeah I bought this cheap ass, hot air rework station off ebay as reviewed on the EEVblog

which did the job quite nicely removing the old chips, I was actually surprised the hot air took off the SRAM chip being so large with so many pins. That picture looks quite deceiving, being zoomed in, in real life that wire is hair thin. I've secured it with kapton tape from being knocked about.

About the loader, silly me! In my excitement to just get the board tested I didn't go looking in the install subdirectories. Thanks for still providing the old tools

A

[alex]

So no point starting another topic since recycling old ones is good for the environment Seeing as my experi-"mental"/prototype Papilio Plus mentioned above never saw the light of day as a product that you can buy in the shop and since I already upgraded the RAM, I figured there's no point delaying it... there's no reason to cling to any sort of compatibility with any of the very few others that have a similar prototype board. I decided to fix the one thing that most annoyed me about this board, the lack of separate upper/lower byte enables. Having those would let me access the 16 bit SRAM data bus one byte at a time and there are many advantages to that and no disadvantages.

 

So out came the crafts knife, quick slice on the PCB between RAM pins 39 and 40 cut through the thin joining PCB trace separating these pins forever. Pin 40 (/BHE) remained connected to FPGA pin 26 while pin 39 (/BLE) was now floating. Not for long, a quick solder job to connect it via some super thin wire to the spare FPGA pin 8 finally accomplished my goal. The other wire is from the earlier mod I did in this very thread, scroll up if you missed it.

 

 

The kapton tape just keeps the wires from snagging on anything. Next came the test and I went to my "go to" tester, Bombjack. I know it seems I go on an on about Bombjack, but it is perfect for testing this mod, because only the graphics ROMs are stored in the external SRAM. This means I can disable the byte lanes to the SRAM without crashing the CPU which is executing code from a ROM internal to the FPGA. Before this mod, the Bombjack code used the entire 16 bit data lane to the SRAM and just ignored the top 8 bits, wasting half the SRAM. After a quick update to the code, odd byte addresses access the bottom 8 bits of the SRAM data bus and even byte addresses access to the top of the SRAM data bus (it could have just easily been the other way around, but I have a reason for doing it this way). Wiring the SRAM "byte enables" BHE and BLE to a couple of external switches to allow me to disable each byte enable individually give us:

 

 

Both byte lanes working.

 

 

Just the LOW byte lane working

 

 

Just the high byte lane working.

 

At this point I should mention the good work that Ben did here, I don't know how I missed that at the time, but well done Ben, even if my feedback is ohh.. over a year late. What Ben has done there is provide a patch to papilio prog and a special bscan file that lets one directly upload data to the SRAM chip via JTAG. This is simply awesome! ... and no, you can't do this with a DRAM due to the refresh requirement.

 

Incidentally, initially I couldn't upload data to the SRAM using Ben's code but tracing though the components showed an interesting difference. It was in the FPGA pin assignments for the bscan file. Ben didn't provide a .ucf file with the bscan but around that time he was also working on this project and the .ucf file for that seems to have slightly different FPGA pins connecting to the SRAM pins and more interestingly he had already separate upper/lower byte enables. This sort of rung a bell and I went back to the schematic/board work I did for Jack updating the original Papilio Plus design to fix those very issues and the pinout in Ben's .ucf matched perfectly. It seems Jack produced a small batch of updated boards and Ben was the (very lucky!) recipient of one of those.

 

After fixing the .ucf for my ancient prototype and recompiling bscan I had success uploading data to the SRAM via JTAG. Yippee-ki-yay!

 

[Jack Gassett]

Looks awesome! I did make a small batch of updated boards, I think 8 boards or so. Several of the boards were reported to have problems though, I never got to the bottom of exactly what the problem was.

 

There are two new boards in the works right now... I'm not ready to release the details yet, but one of them will be a BGA board and will have lots of ddr3 memory connected to the hard memory controller of the Spartan 6. That should let us use the MIG wizard and make it easier to interface with the memory.

 

Jack.