01-09-2018 02:49 AM
Hello, I am a recently minted electronic engineer, currently working on a project derived from Simulink through SysGen.
After implementation, the attached document (Timing Report) represents what we are getting in terms of timing report.
When facing such a huge malfunction, what kind of procedures should I start adopting?
01-09-2018 03:26 AM
01-09-2018 06:34 AM
I am currently in the process of dividing the project into smaller unit, and getting them analyzed and synthesized one by one.
At one point, around half the chain, my timing starts to be violated (albeit much more lightly than before).
I attach here the new report, hoping i've understood what you suggested.
I feel like I need synchronized inputs on that block which gives slack errors?
01-09-2018 08:05 AM
I am not familiar with simulink, so I don't know how to advise you directly, but the issue is with architecture. Regardless of the tool you are using you need to architect a solution. Generally this means deciding what needs to be done in each clock cycle. In your example you are attempting to do an immense amount of computation in one clock cycle - it just doesn't work that way.
You need to architect a design that breaks the computation you need to do into smaller chunks, where each chunk is done on a consecutive clock cycle - you need to pipeline the design. In many computationally intensive design, this is relatively straight forward - you can take many clocks to perform the computation you need. However, if your computation has any amount of feedback (where the result of one operation becomes the input to the next), then pipelining becomes a problem.
Ultimately it is up to you to design (architect) a system that can perform the computations you need in the right number of clock cycles, and you then need to describe that architecture to some tool (be it RTL directly, or through another tool like simulink). But unless you do so, you will not succeed. It also needs to be pointed out that not all ideas are implementable at a given performance; if your design has tons of computation with a feedback path, then there is an inherent limit to how fast it can run.
Finally, there are other problems with your design. The check_design shows tons of flip-flops that are clocked by the output of other flip-flops. This is very bad design practice - all clocks in your design should come from clocking resources; clock buffers driven either by clock capable pins or clock modifying blocks (PLL/MMCM). Locally generated clocks like we are seeing here can create all kinds of problems...
01-09-2018 11:46 PM - edited 01-09-2018 11:47 PM
At Simulink level, we design the Whole architecture by using macro-blocks (the most in-depth we can go, it is Register, but for example you cannot ever insert latches explicitly).
The flip flops you are likely seeing, are derived by Vivado.
Currently we are using a different kind of approach to the transfer of the whole architecture to Vivado.
We have divided the architecture into smaller block, and even the timing issues have become far less Dangerous and prevalent, compared to the previous stages.
I am attaching here the current state of timing report.
There are still failing paths, but , correct me if I am wrong, most of the negative slack comes from the IP of CLOCKING WIZARD. Is that possible? It seems very very strange.
01-09-2018 11:55 PM
01-10-2018 12:10 AM
Oh, I see. My worst negative slack is now -0.9ns, compared to a clock of 5ns (200MHz from the clocking wizard).
I have some paths which are 12 logical levels... I have read your responses in other topics, and I feel like such a situation might be improved by modifying the logic and lightening the amount of logic levels?
Is it correct for me to check the procedures indicated in UG906? pages 117 and following?
01-10-2018 12:24 AM