So I ordered my first batch of printed circuitboards today. It's sort of a bummer because SNES pcbs are a little bit thinner than the standard issue pcbs. This means I pretty much couldn't use any of the online specials for cheap pcbs. Also, the FPGA has pretty tiny half mm pitch on the pins, so that is just another extra crazy requirement.
On the upside, since I had to do a special custom order anyway, I made the PCBs have blue soldermask instead of the standard green. That's right, blue PCB, totally awesome.
People are telling me that I won't be able to solder something with such thin pitch. I don't really know if I can either. I guess we'll see when I get the boards in next week.
Thursday, February 26, 2009
Saturday, February 7, 2009
SRAM vs. SDRAM
So apparently I misread the digikey catalog and the biggest reasonable sram is something like 2mbytes (not big enough!) and it's kind of expensive at 13$ per chip. I guess I can put like 3 of them on the cart to support the largest possible game, but it would be cool if I could use the much cheaper SDRAM ($5 for 8mbyte).
The DE2 board that i' m using has 8mbyte of sdram on it already, which is more than I need, but I'm unsure about the timing. The datasheet shows the whole situation to be pretty dicey. SNES FastROM needs 120ns response time. In the worst case, the SDRAM could be in the middle of a REFRESH (60ns), then it needs an ACTIVE (row select) and the full CAS delay (column select), and finally a PRECHARGE before the next command. The datasheet shows tRC (active->active cycle time) as 60ns. I'm not sure abuot how accurate that number is, because you don't neccessarily need a precharge if you do a refresh, but no matter what, it's cutting it extremely close (60ns+60ns = 120ns). I would want some slack time for the controller logic.
The original copier devices had problems with FastROM games, which leads me to believe that it's sort of a hard problem. Part of the issue for me is that I haven't actually written an SDRAM controller core, I've been messing around with a few random ones that I've found. If I needed to make some shady optimizations, I'd have to probably end up writing a lot of the stuff from scratch. Another option might be to use 2 SDRAMs, this way if one is refreshing, I can fall back to the other one. The logic for this would be tricky, and I would need to make my own board just to test anything, so I'm not that keen on it. At least not for a first pass...
I would do it, but I'm not sure I have time. I graduate at the end of this semester, and then I won't have access to this sweet lab. Just getting the basic SDRAM test code working has been a huge ordeal for me. The timing is really tight, and my original code took some (bad) liberties in clocking logic. In the interest of getting my own board semi-working, I think I will just use expensive SRAM for now. Now to finish the design...
The DE2 board that i' m using has 8mbyte of sdram on it already, which is more than I need, but I'm unsure about the timing. The datasheet shows the whole situation to be pretty dicey. SNES FastROM needs 120ns response time. In the worst case, the SDRAM could be in the middle of a REFRESH (60ns), then it needs an ACTIVE (row select) and the full CAS delay (column select), and finally a PRECHARGE before the next command. The datasheet shows tRC (active->active cycle time) as 60ns. I'm not sure abuot how accurate that number is, because you don't neccessarily need a precharge if you do a refresh, but no matter what, it's cutting it extremely close (60ns+60ns = 120ns). I would want some slack time for the controller logic.
The original copier devices had problems with FastROM games, which leads me to believe that it's sort of a hard problem. Part of the issue for me is that I haven't actually written an SDRAM controller core, I've been messing around with a few random ones that I've found. If I needed to make some shady optimizations, I'd have to probably end up writing a lot of the stuff from scratch. Another option might be to use 2 SDRAMs, this way if one is refreshing, I can fall back to the other one. The logic for this would be tricky, and I would need to make my own board just to test anything, so I'm not that keen on it. At least not for a first pass...
I would do it, but I'm not sure I have time. I graduate at the end of this semester, and then I won't have access to this sweet lab. Just getting the basic SDRAM test code working has been a huge ordeal for me. The timing is really tight, and my original code took some (bad) liberties in clocking logic. In the interest of getting my own board semi-working, I think I will just use expensive SRAM for now. Now to finish the design...
Subscribe to:
Posts (Atom)