[SOLVED] Simulation ! = Real Word

Hi
I am experiencing bad times with my project with a spartan 3A XC3S200A fpga. What happens is that the project works perfectly in simulation (ISIM) but when programming the fpga the result is not entirely expected.
Works for a while and then completely blocks. I'm suspicious that exist delays in the propagation of signals which are not seen in Simulation, but I don´t have the tools to do debugg in real time.

I'm on the right track? Is there any documentation or tutorial to check this problem?

I think the problem is the programmed code. What kind of signals should I consider for review?

I have signals that are being generated in various stages of state machines and then used as RSTs or ECs for counters and the clock is the same for both FSM and Counters. These signals are considered to be asynchronous or synchronous?

PS: I'm using a Xula200 module and ISE Design Suit 14.3

The first question is is the design fully synchronous? if not, why not? Fully synchronous means debugging this thing will be much easier and you wont be prone to timing issues if you got it through timing analysis.

If it is synchronous, the fact you say it "blocks" probably means your testbench isnt good enough. Have you covered all cases? Is the testbench fully self checking? have to done constrained random testing? Have you tested for failure rather than success?

ok i´m goingo to do new simlutations test. this time for failure.

I have an assynchronous RST switch i you can see in the image.

https://obrazki.elektroda.pl/9133271300_1369833097.png

I cant really see anything in that image, the text is all blured.
Async reset is not a problem as long as it comes from a synchronous source. But why do that when you could make the reset synchronous?

Obvious question: did you make a constraint for your clock? Is your design up to speed?

From now on my edge detectors will be called detector_de_flanco. That has a nice ring to it.

At any rate: it is real easy to make a design + a testbench where you get a mismatch. In fact, it takes some care to make your design + testbench in such a way that what you simulate resembles what you get in real hardware. Short version: your post tells us nothing than that you ran into something pretty common, a simulation/hardware mismatch.

As for "These signals are considered to be asynchronous or synchronous?" ... there is no way for us to know. If you neatly registered those signals and didn't mess up the clock & didn't create latches somehow, then yes it should be synchronous. If however you did something creative then it could very well be async.

After synthesis you can see what kind of hardware is being generated. In ISE you can do "View RTL Schematic" and "View Technology Schematic". That should give you a clue on the sync/async question.

People. My code doesn´t give me any assincronous/latches/clock enable warnings. Only signals that aren´t being used. I have attached a better picture.
It's now non-stop working

All Synchronous signal stand according to the following form:

process (<Clock>)
begin
***
*** if (<Clock> 'event and <Clock> = '1') then
****** if <sync_reset> = '1 'then
********* <statements>;
****** else
********* <statements>;
****** end if;
*** end if;
end process;


only the RESET signal is asynchronous and stand to the following form:

process (<Clock>, <async_reset>)
begin
*** if <async_reset> = '1 'then
****** <statements>;
*** elsif (<Clock> 'event and <Clock> = '1') then
****** if <sync_reset> = '1 'then
********* <statements>;
****** else
********* <statements>;
****** end if;
*** end if;
end process;

all assynchronous signals come before the instruction (<Clock> 'event and <Clock> = '1') because they do not depend on the clock. That's how I learned!

For the solution i just had to put a missing constrain on the clock in the .ucf file:
NET CLK PERIOD = 50;
I need to learn more this constrains things...

Thanks everyone for the tips

PS: I´m in the mood to drink an ICE-TEA

The fact you have a clock generator is somnething you will want to change in the future. Generating clocks is not very reliable, is prone to failures and its hard to do timing analysis on them. Its much safer to generate clock enables instead and run everything at the system clock rate.

Yes, i´m aware that.
I was to redo the entire managment clock with the DCM module but it would lose some time to familiarize myself with it and have to move on.
Your idea sounds good too, but I ended up going to my mediated change a module already made ​​in one of the book's examples FPGA_Prototyping_by_VHDL_Examples.

Tks

I was to redo the entire managment clock with the DCM module but it would lose some time to familiarize myself with it and have to move on.

Click to expand...

All clocks in your design have rather low frequency. That's no job for a DCM or PLL. The divided clocks should be implemented as clock enables instead so that all registers in the design are clocked with the same clock.

Besides timing issues with generated clocks, two asynchronous pitfalls should be considered:
- an asynchronous reset should be released synchronous to clock
- external signals ("echo" is the only one in your design) should be double registered before they are processed in the synchronous network. Otherwise the network can fall into unexpected states when the signal edge coincides with the clock edge.

In fact the DCM only allow to divide the clock to a maximum of 16. My bord work with 12MHz, so the mimimum would be 750KHz. not enought to get 1HZ and so on!
The RESET signal is drive by an external switch and no debounce add to it because is working, is reseting the sistem. Is an external signal too.

I´m going to put registers in those asynchronous signals, but why put two registers instead of one?one was not enough? although the FPGA as milions of resources isn't a waste a logic?

Look up "metastability"...

IIRC, DCM/PLL can only output a frequency of at least a few MHz, so you cant go lower than that. Clock enables it is then....