Code synthesizes to one FPGA but not to another?

Hey everyone, I'm fairly new to VHDL and especially to synthesizing code to program an FPGA. For a class project, I developed a FSM that received its inputs from a ps/2 keyboard. So this project has a keyboard controller (host-receive only), a component to translate the scan-codes into appropriate actions, the FSM being controlled by those actions, and a BCD converter which is to be mapped to a 7 segment display.

Anyway, I've got to the point where my code simulates perfectly, but when testing on different FPGA boards, I get mixed results. I recently purchased a Xilinx Spartan-3E Starter Kit with a 500k gate chip. When I program my project into this board, it does nothing but go to the default state. None of the keys that are supposed to be recognized are. We also have a board that our professor loaned to us which is a Xilinx Spartan-3 with a 200k gate chip. On this one, the code functions pretty well and the keys are recognized.

My (long winded) question is, is this normal? Should code that simulates and synthesizes fine work on one FPGA and not at all on another?

thanks Jay

Reply to
Loading thread data ...

I'm by no means an expert, I've only played with the Spartan-3e starter board and no other, and I've never moved vhdl from one fpga to another. But my gut reaction is you haven't setup the constraints properly, your ps/2 connector probably isn't feeding the data in to your state machine correctly. You just need to work the problem, find out where things go wrong. Keyboard frequencies are trivial for any fpga to handle, I'd think.

Maybe your vhdl is right on the edge -- you could have an iffy construct that happens to work sometimes and not others. Consider the case that fails reliably as a godsend and use it to work the problem and maybe learn something about what not to do in the future.

Good luck.

David Ashley      
Embedded linux, device drivers, system architecture
Reply to
David Ashley

The most likely problem provided you have set up period constraints correctly is probably not dealing with what are esssentially asynchronous inputs properly. The timing out your keyboard is unlikely to bear much relationship to your internal clock. Also keyboards tend have open collector/drain driving which makes edges fairly slow and makes timing even more variable. Your design needs to account for those ensuring the data capture point you use is stable.

Other things to check are (1) That you do have a pullup on the lines in both cases, either phyiscal resistor or FPGA internal, and finally the value of those pullups in discrete components. (2) Check your keyboard does not need 5V CMOS levels. Occasionally they do and get upset by

3.3V driving or limiting by protection diodes on the FPGA. Small variations in the 3.3V supply might make one board work and the other not if it is the margin levels zone.

John Adair Enterpo> Hey everyone, I'm fairly new to VHDL and especially to synthesizing

Reply to
John Adair

I hesitate to ask a silly question, but you are completely re-compiling the code for the different board, right? That is, you are not trying to load the same .bit into both boards, right?

Do you have the part number specified correctly and have you checked the .ucf file?

I only ask because you said you are new at this...

Alan Nishioka

Reply to
Alan Nishioka

The "silly question" that occurs to me is, have you connected the inputs and outputs correctly? Device pins are connected to signal names in the user constraint file, e.g. "mydesign.ucf".

But the keyboard and display signals will be on different pins on the two boards; therefore you need two different UCF files; e.g. mydesign_s3_200.ucf and mydesign_s3e_500.ucf.

The design must be re-implemented with the appropriate UCF file to generate a bitfile for the new board. Synthesis may or may not be OK, depending on the differences between S3 and S3E. If you were merely moving between different sizes of S3, you would only have to re-run Translate/Map/Par and Gen Bitfile.

You can make a new UCF file by copying the original and changing the pin "LOC" constraints with a text editor. (The pins wired to the keyboard etc should be specified in the board's documentation)

Hope this helps.

- Brian

Reply to
Brian Drummond

I have started a page on our website to encompass some the answers on this thread for this first time FPGA build. I'm sure the page is missing lots of things so do suggest anything I should add. Page is in out TechiTips section here

formatting link

John Adair Enterpo> The most likely problem provided you have set up period constraints

Reply to
John Adair

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.