C# and Spartan 3 Starter Kit

Hmm...... Short answer no. It sounds like you want to use an FPGA as a microcontroller. This is normally done using the the Microblaze soft core (The Xilinx EDK). The EDK toolchain (gcc based) allows you to code in C. No one (at least that I know of) has a .net engine running on a soft CPU. I am sure its possible by porting the work done on the Mono project but this would be a waste of time. C# is more of a macro level (like VB) development tool. I (at least in my opinion) don't feel that it is a serious tool for embedded programming. Primarily because it was not designed to allow you have unprotected access to memory. No Dynamic Allocation, Garbage Collection etc!!!!. It is critical in embedded systems to be able to talk directly to hardware registers, etc. C# simply can't do this (at least not in any way that is simple and easy.

If you are still interested in just doing the work in C, get ahold of the EDK. Its not that hard to get a simple system running using the base system builder. Writing you own custom peripherals will take you alot longer if you dont know HDL.

I think you may be better off using a small 8-bit micocontroller (8051, PIC, etc). You will actually get your project done in time.

-Eli

As a former senior design project lab instructor, let me give you a few hints.

1) Make it simple. You don't have time to debug unnecessary crap. I've seen great projects that would have earned A's had they been completed

- yet get C's because the students bit off more than they could chew, and got stuck debugging unnecessary problems. This is an important skill later, as well. Nobody wants to explain that a product will ship late because some engineers "toy" broke something, and forced a long, unnecessary, and expensive debugging cycle.

2) If you don't absolutely need it - don't worry about it. That's why I asked if you really need configurable logic. FPGA's are neat, and in some cases, invaluable - but if all you are doing is controlling a serial device and an LCD - unnecessary. They add complexity, and design time, without offering much in return. On the other hand, they do allow you to do true system-on-a-chip designs. The S3 or S3E starter kits are great for this, because they are entirely self-contained. I would suggest you look at opencores.org. I am using the Plasma MIPS processor in a design of my own, and you can cross-compile with either Windows or *nix based compilers. If you have (or can get) the full Xilinx EDK, Microblaze is a very nice soft processor, and you get a full development environment.

Keep in mind, an FPGA will present an additional set of design problems on top of all the others you have. Specifically, you must make sure your design can make timing, your pin-out must match what is expected by the rest of the system, and code debugging becomes more complex than just "recompiling". You now have to generate a new bitstream, and upload it to the target everytime you make a change. (EDK helps a lot here)

3) C#, to my knowledge, is limited to a very few platforms, and as a previous poster noted, none of them are microcontrollers. I'm not anti-Microsoft, but .net was not intended for embedded computing. If you can't use a PC (running Windows) as your controller, and must use a micro, I would use C and/or assembly. It gets the job done, and you can get free cross compilers to almost any platform known to man. Yes, you can write C programs targetting Atari 400/800's and Commodore 64's if that's your thing.

4) If you are planning to graduate this Spring, I would suggest hoofing it. Debugging always takes an order of magnitude more than the initial development - no matter how careful you were in the design phase. Something about Murphy's law I think...

Finally, if you are set on using an FPGA, consider using finite state machines (FSM) instead of a full processor. You would be amazed at how much you can accomplish. I've done designs with reasonably complex user interfaces with little more than an FSM and a ROM. Your application practically screams for a well-designed FSM.

Remember, software is essentially a FSM executed on another FSM (the CPU). Any software function, including recursion, can be fully reproduced in hardware. The opposite is not true.