Huge increase in resources from 5.0-r2 to current master

[stffrdhrn]

Found when building de0_nano-multicore. The design no longer fits on the de0_nano cyclone IV. It used to be 18210 logic cells no it has increased to 46111 logic cells.

BEFORE

$ fusesoc build ::de0_nano-multicore:1.0

...
INFO: Preparing ::mor1kx:5.0-r2
...


Info (21057): Implemented 19257 device resources after synthesis - the final resource count might be different
    Info (21058): Implemented 7 input pins
    Info (21059): Implemented 26 output pins
    Info (21060): Implemented 24 bidirectional pins
    Info (21061): Implemented 18210 logic cells
    Info (21064): Implemented 976 RAM segments
    Info (21065): Implemented 1 PLLs
    Info (21062): Implemented 12 DSP elements

NOW

Info (21057): Implemented 46990 device resources after synthesis - the final resource count might be different
    Info (21058): Implemented 7 input pins
    Info (21059): Implemented 26 output pins
    Info (21060): Implemented 24 bidirectional pins
    Info (21061): Implemented 46111 logic cells
    Info (21064): Implemented 808 RAM segments
    Info (21065): Implemented 1 PLLs
    Info (21062): Implemented 12 DSP elements

[stffrdhrn]

Note, I see the number of ram segments has gone down. I am guessing that synthesis is failing to infer ram due to some changes and is using logic cells instead.

[imphil]

That's pretty annoying, but inferring primitives in various tools is always a error-prone game. The problem is that Synopsys DC gives an error (not a warning) and fails to synthesize the mor1kx design with the two blocks.

I'd take the following path:

1. Try to find a solution which infers the right blocks and works on Synopsys DC. Could you double-check what Verilog code template the Xilinx and Altera suggest to generate a single-clock true dual-port RAM? (For Xilinx its UG901)
2. If 1 doesn't work out with reasonable effort: Revert true_dpram: Use a single sequential block #63 for now to get back to the previous state where FPGA targets are working well, and follow up with a more flexible solution to pick a different SRAM implementation depending on the implementation target.

[stffrdhrn]

Thanks for the feedback. I didn't realize it's an error. I'll try to see if I can get synopsys DC and reproduce it. Ill try to go with option 1.

…

On Thu, Jan 3, 2019, 7:44 PM Philipp Wagner ***@***.*** wrote: That's pretty annoying, but inferring primitives in various tools is always a error-prone game. The problem is that Synopsys DC gives an error (not a warning) and fails to synthesize the mor1kx design with the two blocks. I'd take the following path: 1. Try to find a solution which infers the right blocks *and* works on Synopsys DC. Could you double-check what Verilog code template the Xilinx and Altera suggest to generate a single-clock true dual-port RAM? (For Xilinx its UG901) 2. Revert #63 <#63> for now to get back to the previous state where FPGA targets are working well, and follow up with a more flexible solution to pick a different SRAM implementation depending on the implementation target. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACSvn8HQQn0XdvElpABIt2YSfUoyTOx1ks5u_d8IgaJpZM4ZnNxX> .

[stffrdhrn]

Hello, I am not sure if I found the most formal documentation. But it seems the differences are these:

Altera: http://www.gstitt.ece.ufl.edu/courses/spring10/eel4712/lectures/vhdl/qts_qii51007.pdf
Xilinx: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug901-vivado-synthesis.pdf

On Xilinx there are 2 blocks with 2 separate clocks, on Altera/Intel they have 2 blocks but only require a single clock.

Let me try with 2 clocks into the top level true dual port ram module and see if it causes Atera issues. If its works ok, then I hope it will work on Synopsys DC. However, I checked and I cannot get a copy of Synopsys DC.

[imphil]

The Xilinx example is dual-clock, our module has only a single clock, so the examples are more or less identical. Since the FPGA tools seem to insist on the coding with two blocks we probably need to to go option 2. So for now please simply back out #63 and I'll look into a more permanent solution once I find time for it (not in the next couple of weeks though). This should at least unblock FPGA work.

[stffrdhrn]

I tried with the 2 clock xilinx example in quartus and it works fine. I will go with that. Perhaps after I merge it you can test in synopsys DC when you have time?

…

On Thu, Jan 3, 2019 at 10:35 PM Philipp Wagner ***@***.***> wrote: The Xilinx example is dual-clock, our module has only a single clock, so the examples are more or less identical. Since the FPGA tools seem to insist on the coding with two blocks we probably need to to go option 2. So for now please simply back out #63 <#63> and I'll look into a more permanent solution once I find time for it (not in the next couple of weeks though). This should at least unblock FPGA work. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACSvn5huKtYLUNJoe4DeZt-p0GJPZgoVks5u_gcMgaJpZM4ZnNxX> .

[stffrdhrn]

Will close for now. Let's open another issue if synopsys DC fails with the new code.