Need assistance with an FPGA based project.

You state four requirements. The first requirement is more of a hardware issue than anything else. You don't say if you have to build the hardware or if you can use or may even already have a prototyping board with a Spartan 3 on it. I assume you can buy or have available a suitable prototyping board.

The second requirement simply means that you need to learn VHDL. I have found that learning an HDL involves two parts. The first is learning the language itself, which is not really similar to learning a programming language. The second is learning to design hardware in effective ways using the language. Both of these would be much easier in a VHDL class. Are you taking a VHDL class? If not, I suggest that you find some tutorials and start learning. Practice with small examples and work your way up to a larger project like this one. Also, try not to get too complicated with the features that you use. You will do much better to use the straight forward features and leave the more complex ones for later, after you have completed your project.

The third requirement is the one you need to deal with first. I suggest that you create a written description of everything the Pacman game does in a heirarchical document. You will use this as a template for designing your machine. The clearer this document is written, the easier it will be to design the machine. Next you should translate this description of the machine to a design of registers and logic. This can be done in an informal manner. Translating this to VHDL will create the formal version of the hardware.

The fourth requirement will dictate how much of the design you will actually be able to complete. I suggest that you plan your design efforts to get some functionality working initially and add details as you procede. This will provide for a partly working version if you don't complete the design by the end of the 15 weeks.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

May I suggest that you use a readily-available CPU core. It's a tall order to ask that in 15 weeks you learn VHDL and implement a full CPU core as well as the surrounding logic.

Are you looking at copying the arcade machine behaviour verbatum? Or is a functional equivalent sufficient? For the former, you'll need to study and understand the game schematics completely. For the latter, you'll need to understand the function of the components in the game (tiles, sprites, etc) and come up with your own designs for those.

Obviously you need to choose a game. A Z80-based game is probably the easiest as a fnuctional opencore is available (grab the version from fpgaarcade.com). As for the game, well, Pacman has been done to death!

You will probably be limited by the amount of ROM/RAM available as well. If you choose your direction and CPU I might be able to give you some suggestions on which games would be suitable.

You *should* have fun doing this! Good luck!

Regards,

--
|              Mark McDougall                | "Electrical Engineers do it
|                    |   with less resistance!"

Hi, your situation reminds me of my own experience about video game design that I had last year. You are doing your third year in computer engineering and i suppose that you have an idea what behavioral, structural and RTL means. First, because of the fact that you are alone doing a project of this complexity and on top of that, having a time constraint will not make things easy. The reasonable thing to do is to plan your time, based most probably on a weekly schedule.

When we were doing our nintendo video game, we spent 1/3 of the time searching for the right and reliable information, 1/3 of the time debugging the system and the remaining 1/3 of the time, doing documentation. At the end, it was so complex, that we spent like a couple of weeks not sleeping (or having very little sleep). We were 7 doing the project. OK, 1/3 of the time was spent looking around, mostly on the net for the appropriate information, because for us, nobody had did it before (and we didnt want to plagiate anything!) and also, documention for it was erronous and scarce. It was really challenging to find the right source of information, that could be trusted. Once this was done, the task of writting down CLEAR AND CONSISE specification started. It was decided to break (or partitioned) the system in modules (SOC based on modular design XILINX ). This would be appropriate for a team based approach, but in your case, I guess that you should start writting the specs for the most important part of the computer system; the CPU.

CPU is tricky because in 14 weeks, you're gonna need to turn your choice towards an already made and tested free core module. It is tricky because you are going to have to do with specs that have been done by somebody else. OK, here is a clearer explanation. The CPU that you could get on the net would be written so as to "behave operation-wise" like the, say original Z80. It gets very problematic when you have to couple slow memories with those cloned VHDL CPU, cause the timing characteristics (did you take a computer architecture or microprocessor design class??) are not guaranteed to be compatible. Most of the time there is no problem with the interface but that's the weak point in the sysetm at this point. It would be wise to know by heart the difference in timing between the two cpus, (VHDL Off-shelf on the net core, and original Z80). This will save you a lot of time and head-aches! Know what your system consists of, and its weak points and try to find solutions for those. Also, be aware of the fact that if you consider to use on-chip, free-to-use SRAM your system will be synchronous...

Our NES on a chip (INES) had exotic clock frequencies, 5.37MHZ,

3.58MHZ, 1.79MHZ, 60HZ. Now building those clock domains in FPGA technologies can be tideous and challenging. You need to find the right balance and solve the "equation" while using limited resources provided by the spartan 3 chip.

Up to now, I only talked about gathering information, dividing the work and knowing the limitation. The hardest part is still to come. Once all infos about the system is known, you need to focus on coding the system. As said earlier, divide and conquer is one of the most suitable approach for doing such project. At this point you should have your working CPU and some memory unit.

1) CPU 2) Memory unit

--- test the two systems with some basic clock unit

From experience, behavioral test benches are good if you have a really fast computer, but again, if you have a demo FPGA spartan 3 board, why not dump the design right away on the hardware. You might want at this time to double check your pin assignment constrains and if you have any clock constrains.

CPU and memory are simple to test... some bubble sorting algorigthm might provide you with enough proof that your system is indeed working.

The next block that you should focus on is the video system. Write your specifications very clearly. How many colors should it display, what about the resolution. Are you driving a computer/lcd screen or a tv. Tv screens are somewhat easier to work with, because of the fact that it fits naturally the original design. But if you wanna make your design compatible with modern technologies, then you better give this block some attention.

Learn what's a sprite, what's a character, how the screen is organized in tiles, where do you use the 5.38MHZ clock (NTSC system), how to generate hsync and vsync. OK, at this point let me warn you. One of the challenge that we had was to couple the video interface of the Nintendo with something like a SVGA screen or LCD panel. The pacman system was designed to be used with 60HZ TV screen. This was so in our case and we did need to use something called a frame buffer...

The last block that should be approached is the sound unit, if you intend to provide the system with sound. The sound system would ressemble more something like a programmable square wave. That's not bad to design, from description (again clear specification).

Last touchs includes glue logic for memory interfacing and clock generations. Note that the order of the block, starting from

CPU->MEMORY->VIDEO->SOUND is important.

Its hard to test the video and sound without an appropriate CPU. Again success will come iff you have a good schedule.

Dont underestimate your debugging cycle! This is the hardest part of the whole project. Debugging kills and I really advise you to do things methodically. Get yourself a good logic analyzer from the lab (we had a TLA713). Learn how to use it and its nice triggering sequences. And prepare yourself to spend nites infront of it.

This message is getting long, so im gonna cut short here. There's still alot to say about designing something of this magnitude but again, the secret is in

getting the right time table getting the right information + specs getting the right instruments

im pretty much sure ive forgot a couple of other things but if i remember anything, well im just gonna post it here!

good luck with "pacman" and make it successful.

ja

I disagree here. You can get a basic tilemap and sprite system running without a CPU. In fact, the design will build *much* faster without a CPU. We had both tilemap and sprites going before we hooked it up to a CPU.

Honestly, I don't think you've got much hope of completing this project single-handedly in 15 weeks, especially if your scope of work is anything near what Jacques has outlined.

I would like to note, however, that the NES is reasonably more complex than the early arcade games. In fact, if you want to forego the tilemap/sprite system then go for something like Space Invaders, which is a simple monochrome bitmap.

At least as a prototype, you could grab a dev board with VGA output and the opencore Z80 and just get the video going. Even before you worry about getting a CPU in there, I'd suggest you run Space Invaders on the debug build of MAME, halt it mid-game and dump the screen RAM to a file, convert it to intel hex, and load it into an internal (FPGA) memory block. Then work on the video until you can see the correct display (keep a screenshot from MAME at the time of your dump).

Once your video works, you can bolt on the CPU with the appropriate memory map and run the SI ROMS - and you should see the game running?!? If you start the other way around, and see nothing, you have no idea whether the fault lies in the CPU, the memory map, or the video!!!

If you wanted to go further, you could develop a simple tilemap component - 8x8 and 2bpp should cover most of the early games. Go back to MAME and grab another video RAM dump of, say Pacman, and start again, without CPU. When you get that going, dump your CPU again and do a

16x16, 2bpp sprite system. etc.

I've found this the best approach for this type of project.

Regards, Mark

Hi Mark,

True that the design and testing cycle will be faster without designing a CPU and interfacing, but later, if you ever consider to run it along side of an actual processor, you might face problem with interfacing.

actually the design of our "ppu" started sometime after having done sound, cpu and memory. But the thing is that we needed a CPU model to test the video unit. It make sense to start with the CPU and have it running. Its not imperative to have it, it would be more fun to start with the video, but watch out for complication with the cpu-video interface sometime futher down the line. That was our mistake and im just stating it here. I dont know how complex the pacman video system is, but the process of designing the 6502 CPU helped us understand and hence design a PPU which was based on a "datapath-controller" approach. This methodology is somewhat general and variations which applies to something more specific is needed, in the case of pacman for example. In our case we also had a sound unit that was hard to test without a CPU.

Anyways, I really enjoyed our project and yes, it took us a hell out of time to complete it! I believe that with good planification and tools, you can achieve what you want in the time allocated. Just hurry up and start the project!!!

good luck and have fun

ja

It would be nutty to build a CPU to do this! You'll never want to look at another counter, but this game can be done almost completely with ounters. -S

CPU.