Many warnings for Synthesis and implementation of FPGA

[jmadsenee]

Hi All,

When running the Synthesis in Vivado for the original (straight from github) fpga project, I get 314 warnings. When running the Implementation I get 134 warnings and 1 critical warning. Is this normal? Have I done something wrong? I am new to fpgas and wanted to try generating a bitstream with the original code before trying to make changes...

Any help would be appreciated.

John

[Nils Roos]

Hi John,

Warning messages in their hundreds are normal for the red_pitaya project. Actually they can be in their thousands, but Vivado out-of-the-box is configured to stop at 100 repetitions. A slight timing violation on a small number of signals is also normal, which I assume accounts for the critical warning. Go ahead and build the bitstream, convert it with promgen - unless you have the patched xdevcfg in use - and try it out.

[jmadsenee]

Doesn't that bother anyone? Is that normal for all fpga projects?

[pavel]

Hi John,

Apparently, the timing problems bother the Red Pitaya developers. In the devel branch of the Red Pitaya repository, most of the timing problems are already fixed. So, hopefully, there won't be any timing problem in the next release.

When I've seen all these warnings for the fist time, it bothered me to the point that I stopped using the FPGA configuration from the Red Pitaya developers and spent some time learning how to use Xilinx Vivado in a more optimal way.

For my projects, I'm using a mixture of Tcl, Xilinx IP cores and custom IP cores written in Verilog. For the Xilinx Zynq system, I find this approach more efficient than writing everything in Verilog. Here are a few links describing this approach:

http://www.xilinx.com/support/documenta ... erview.pdf
http://www.xilinx.com/support/documenta ... ado-ip.pdf
https://wiki.trenz-electronic.de/displa ... vado+Blink
http://pavel-demin.github.io/red-pitaya ... d-blinker/

Cheers,

Pavel

[Nils Roos]

Yeah, the timing violations bothered me too, but they can be fixed by getting rid of some superfluous stuff in the original code.

Unlike Pavel, I didn't feel the need to redo the whole from scratch - though I am impressed with his results. I just examined all the warnings and decided I can live with them.

[jmadsenee]

I, too, am impressed with pavel's approach, although it is beyond me right now... Nils, when you say superfluous code, so you mean like, "I don't need the pid, so I removed it," or removing redundant statements? Regarding superfluous statements, specifically referencing the top scope module, in the write data to ram section, why do they break up the code into several different always @(posedge adc_clk_i) sections? I realize it may help to break it up logically sometimes, but it looks like several could be put together and still make the same sense... Why not group together all the things that adc_rst_do resets, instead of so many if-else statements?

Sorry if these are dumb questions, but I am a noobie to fpgas....

[Nils Roos]

when you say superfluous code, so you mean like, "I don't need the pid, so I removed it," or removing redundant statements?

Specifically, I meant red_pitaya_test.v and red_pitaya_daisy_test.v, plus the connections to these modules. The former is just a power sink for board tests and the latter is an inter-RedPitaya-communication test. I left all functionality used by apps intact.

why do they break up the code into several different always @(posedge adc_clk_i) sections? I realize it may help to break it up logically sometimes, but it looks like several could be put together and still make the same sense... Why not group together all the things that adc_rst_do resets, instead of so many if-else statements?

I'd guess the reasons are a mixture of personal preference, best practices, and tradition. I can offer some rationalizations on top of that:

• State updates of one register must happen under mutually exclusive and logically complete conditions, so it makes sense to group if's etc. by affected register. You can quickly see if there is an unhandled condition or a logical overlap that way. (There is some leeway to the rule, but that's another topic)
• Separating the logic in that way emphasizes the parallel nature of the operations. Programmers might be tempted to interpret the logic sequentially otherwise.

[pavel]

Out of curiosity, I've checked the timing problems that bothered me the most.

Here they are:

- line 102 in red_pitaya_dfilt1.v (two adders with a multiplier):
assign r3_sum = $signed({r2_reg,25'h0}) + $signed({r3_reg,25'h0}) - $signed(aa_mult[41-1:0]);

This filter is used in the red_pitaya_scope module.

- lines 214-215 in red_pitaya_analog.v.

These two are actually easy to "fix" by replacing dac_rst with 1'b0.

Actually, these timing problems are also present in the devel branch.

[Nils Roos]

I found that the filter was not a problem when synthesis was done with Vivado 2013.3 .

Only 2014.1 and later did strange things there - and by that I mean implementing the adder with a long carry chain instead of using a dsp slice as Vivado 2013.3 did. That was what caused the timing violation.

If you prefix the reg r3_reg declaration with "(* use_dsp48="yes" *)", Vivado will use a dsp slice again and the timing is ok.

Code: Select all

(* use_dsp48="yes" *) reg  [ 23-1: 0] r3_reg    ;

assign aa_mult = $signed(r3_reg) * $signed(cfg_aa_r);
assign r3_sum  = $signed({r2_reg,25'h0}) + $signed({r3_reg,25'h0}) - $signed(aa_mult[41-1:0]);

[pavel]

Hi Nils,

Thanks a lot for this hint about "use_dsp48"! I would have never guessed that it was that easy to fix.

I applied the two fixes (added (* use_dsp48="yes" *), and replaced dac_rst with 1'b0) and it solved all the other timing problems.

With these two fixes applied, zero critical warnings with RedPitaya 0.92 and Vivado 2015.1.

Cheers,

Pavel