FPGA: strange behaviour between conditions and registers

[Pierre_F]

hi! I'm working on a big project on FPGA and now, during validation phase I experience a lot of compilation problems + code regression.

First of all I validated a primary part of the code last month. the validation succeed and the FPGA was 70% full

now the FPGA is 99% and the code previously validated doesn't work anymore.

It made me wasting a lot of time to debug and I understood something->

My code contains plenty of those condition structures below. it's a simple conditioned writing, and the condition is switching fast at 100kHz (and reading as fast somewhere else)

 

for light unitary test, it works well, but inside my complete program, it doesn't work anymore: If I put an indicator at the input of the feedback node and pull it up in the RT device as a probe, I notice the value is forced to zero wherehas it supposed (as you see above) to either maintain (false) or increment (true)

I remember I had a similar problem previously (this topic) and decided to remove as most as those kind of conditions by this:

now it works better: the value is not forced to zero anymore

have you ever encountered this behaviour? How is it possible to have some programming tips to avoid this inconvenience?

thanks in advance

[wiebe@CARYA]

A lot of things can go wrong when using a tested unit in a complete program.

Without seeing the tests and the program, there's no way to tell why the tests work and the program doesn't.

Does your FPGA has a loop? Or do you start it repeatedly on the RT? That would reset the feedback node...

Note that for speed of execution, the select is just as fast as the case, on an FPGA.

Are you sure the control update in the case is triggered at all? Because it seems to me that even if the value in the feedback node is 0, the control would be 1 (as you increment the 0). Make sure the control value is updated, for instance by setting it's default value to some random number (-1). Instead of wiring the FB value, wire a constant to it. If it stays -1, either the control update isn't working, or the True case isn't fired.

[Terry_ALE]

There are various debugging techniques such as adding counters or latches to see how things change on the fly.  DMA FIFOs can be used to bitpack values (state) of a loop on each cycle and send it back to the host.

You do not give us enough context in your post.  Need more info on the issue.

From your other link, can you use the Handshaking mode for the DMA FIFO?  If available it is more intuitive than using Timeout which is a reverse logic approach.

[Intaris]

I presume you're not using SCTLs (Single-cycle timed loops)?

These give you a much better efficiency of the fabric IIRC.

Otherwise, as others say, a lot more detail is required. LUT %? Register %, BRAM % DSP % ?