Reading from FPGA Issue

Hi Isaac,

Your problem is almost impossible to be solved from remote. You say that it is working well in simulation. Do you mean functional simulation (i.e. pure VHDL code) or back-annotated simulation (i.e. simulation of the synthesized design including estimated delays etc.)?

Are you also sure that you meet all timing parameters when accessing the RAM?

Absolutely! VHDL coding style might have heavy impact on the result. To give an example effect I once encountered with Synopsys: When you have a clocked process with asynchronous reset and a couple of registers inside, and you forget to include one signal in the reset clause, then Synopsys created a register where the output is feed back and is ORed at the input. As a result, once the register turns to '1', it can never turn to '0' again. But in functional simulation you do not see that effect (exept from the fact that the register is not initialized during reset).

That's another reason why it is important to simulate the synthesized design.

Regards, Mario

Without seeing your code it is not possible to make an exact diagnosis (maybe I couldn't even if I did see it), but I do have suggestions. Any signal that is an input to the FPGA synchronous logic should be internally synchronized with the logic's clock using 2 d flip-flops. The bus data need not be synchronized in this manner if the transfer logic (handshake) is synchronized. The read operation should have some sort of handshake to ensure that the output data is stable before it is read and that the FPGA logic "knows" when new data is requested. Does PCI protocol involve a handshake? If so, have you implemented it on the FPGA side?

A typical handshake would be: The reader asserts data_request; the FPGA logic puts the data on the bus and asserts data_ready. The reader sees data_ready, reads the data, and unasserts data_request (this lets the FPGA logic know that the data has been read and it unasserts data_ready and). There are a number of variations on this, but without some sort of handshake it is quite likely that there will be missed data, multiple reads of the same data, etc.

Charles

--------------------

------------------------------------------------------------------- Here is the Case Statement which I am using, in this you will see different signal which I am using in differnt process which I haven't included .

process1: process (CLK_2X) begin if RISING_EDGE(CLK_2X) then state paritycheck

Here is the Case Statement which I am using, in this you will see