DSP Tools

[tbahlo]

Hey Xilinx-Community,

I'm currently developing a system, that reads a signal from an ADC and saturates an output DAC-signal "slowly" (with rise-times between 100ns to several µs) to this input value. Furthermore I want to be able to set the time constant of this saturation with a custom register.

To configure my Xilinx Virtex-4 I'm using MATLAB Simulink with the system generator for DSP. A testversion of my model should be attached.
It consists of 4 similar calculation paths, each multiplying the input value with a weight factor from a custom register, multiplying the result with the (renormed) simulation time and integrating the final result.

The Software-simulation of Simulink works quite well.
The widths of my factors seem to be ok. There are no overflows and the result looks quite like I want it to be.

Unfortunately the FPGA shows a strange behaviour, after being configured with the bitstream of this model.
Here are 2 pictures showing measurements of this behaviour.

http://dl.dropbox.com/u/19187270/no-input.jpg

this shows the output signals of all 4 paths without any input signal

http://dl.dropbox.com/u/19187270/output_signals.jpg

this shows the same with a rectangular input signal. At the middle of the pic the input-signal switched from max to min.

Even if i feed a constant signal to the Input-ADC, there are some "jumps" in the output signal, for which i have no explanation. The fact, that the output signal starts to saturate from this random new "jumpvalue" shows to me, that it's no defect of the Hardware, but that there might be a strange computation problem somewhere in the model (or at least i think so).

I believe the problem might be a multiplication of the input values with a very tiny number, so I tried 4 different ways of multiplying, as you can (hopefully) see in the model.
I thought a number that has a width of about 28 bit (the combined input signal with the weight factor) cannot be muliplied with a number of 17 bit (the renormed simulation time 10^-5), because the FPGA is only able to handle 32 bit at once. So I wanted to seperate the simulation time factor in several smaller factors.
Obviously this didn't work. Even the path with only one big factor produces the best result, but in other versions, this is not the case.

Does anyone know this problem and is able to explain it to me? I'm happy about any kind of answer.
If you need additional information, just let me know.

And... sorry for my bad english. It's obviously not my mothertongue :)

Thanks and greetings

-Thore

[austin]

t,

What does the timing report say?  Do you have sufficient slack on all paths?  Are there any paths that do not meet their timing constraint?

Did you use a timing constraint?

Did you properly constarin what needed to be constrained?

This looks like some paths are not meeting their timing, and glitches (bad data) are the results.

[tbahlo]

Hey austin,

thanks for the quick answer.

Indeed the timing report part of xflow.results showed a couple of warnings about timing constraints, that were not met.

Unfortunately I'm at home now and don't have access to the report file, but I will post the relevant parts of it as soon as possible...

the only timing "constraint" that i intentionally used was the FPGA clock setting in the System Generator config dialogue. To be honest I don't even know how to set further constraints, and I don't know what needs to be constrained. I naively thought Simulink would handle this.

Furthermore I remember to have seen an environment variable that allows "impossible timings". This should influence this model, too, I think. The exact variable name will be posted asap (if neccessary).

Assuming I'll find the path, that does not meet the timing constraints - what are my options to improve this timing. Do I just have to add some artificial delays by adding Xilinx-Delay-Blocks, or is it neccessary to reduce the FPGA clock period? I would like to avoid the latter in order to achieve a quick slope for my saturation if needed.

Greetings,

-Thore

[austin]

t,

Well, there's your problem ....

Not having timing constraints, only works in simulation (occasionally).

There is no easy way to solve the problem:  part of a properly designed system is having the correct and proper timing coinstraints, and having them all have positive slack, after subtracting off clock jitter, PLL jitter, and system jitter.

You have only completed perhaps 1/10 of the work needed to get a working, robust, design.

Welcome to our world.

[tbahlo]

Hello again.

I've checked the timings and found a lot of paths that had a slack of about -16ns.

So I increased the FPGA-clock-period from 10 ns to 30 ns and adjusted some asynchronous signals to be really parallel.

With these setting the Timing Analysis Tool didn't announce any timing errors, all timing constraints are met and there are no negative slacks any more:

All signals are completely routed.

Total REAL time to PAR completion: 22 mins 17 secs 
Total CPU time to PAR completion: 21 mins 36 secs 

Peak Memory Usage:  576 MB

Placement: Completed - No errors found.
Routing: Completed - No errors found.
Timing: Completed - No errors found.

Number of error messages: 0
Number of warning messages: 5
Number of info messages: 2

I don't want to paste the 5 warnings and the 2 info Messages, because it is a lot of text and would make this post confusing. As far as I understood these warnings, they are more or less uninteresting.

Instead of pasting the text I uploaded the xflow.log-File for further investigation:

xflow.log

(the first relevant warning starts with "WARNING:Place:851")

Unfortunately the problem with the random jumps still arises. Here are some measurements of the current model. The model itself should be attached again.

no-input

the top graph is the used input signal (none in this case), while the bottom 3 graphes are the output signal of my DAC

rectangular_Input

the same as above with a rectangular input signal

Seemingly the problem didn't arise from a timing problem, did it? Are there other possibilities, or do I still have timing problems, that i simply don't realise?

This "random jump problem" also arises in other models, that dont have a feedback in it. Am I doing something wrong fundamentally?

Thanks for any further help!

Greetings

-Thore

[austin]

Thore,

Asynchronous paths?  That sounds like a place to look.  Anything asynchronous implies that it has to be sampled at potentially the same time the data is changing, and hence will cause metastability.  One needs to provide for this (although it will never be eliminated) by using a two (or more) stage synchronizer.

Metastability is a fact:  it is never avoided when crossing asynchronous clock domains.  All you an do it lower the frequency of the occurrence by adding synchronization stages.

[tbahlo]

Maybe my formulation wasn't the best. I didn't mean that I use several different clocks/sample times.

I just realised, that one path fed back some values two clock cycles too early, so I added a 2 cycle latency.

I don't think that this produces wrong numbers randomly. The fact, that this problem still exists, while the paths are "synchronous" (in my sense) fortifies this thought.

The problem occurs even if there are no visible timing issues.

It confuses me, because I cannot find a correlation between my model and the quantity of random jumps in my output.