0
\$\begingroup\$

I just finished to write a pretty complete design on ISE 14.7 targetting a Virtex7 device. The behavioural simulation (on Isim) takes a while but works perfectly.

Therefore, I tried to move to the next step adding a Time Constraint by double clicking on my top module -> User Constraints -> Create Timing Constraints in the ISE interface. This action triggered the synthesis and it's now more than 24 hours that ISE is trying to "Optimize" one of my module.

I don't mind about letting the program running for other 24 or 48 hours but I am suspecting that something is wrong with my design ... I know that it might be pretty eavy since I use many logic cores instances but I am afraid it doesn't justify the delay for the synthesis.

My design can be found at the following link: https://dl.dropboxusercontent.com/u/12734577/fourier_QAM_modulator.zip

Does anyone have an idea about how to solve my problem ?

I thank you in advance,

Best regards

Edit:

For posteriority, the full code is available here; details and explanations can be found in the paper.

\$\endgroup\$
  • \$\begingroup\$ Divide and conquer... delete bits until it synths fast (minutes), then reverse the last deletion. Try synth of that module on its own. I've seen ISE take absurdly long to compile a lookup table : long enough that I tried an assertion for each entry, you could see the assertions slow down as it used some quadratic-in-time algorithm and the loop counter increased... \$\endgroup\$ – Brian Drummond Sep 6 '15 at 19:05
  • \$\begingroup\$ How many main memory has your machine? Does it swap? \$\endgroup\$ – Paebbels Sep 6 '15 at 19:31
  • \$\begingroup\$ Why are you using ISE? Vivado have a better synthesizer for 7-series. \$\endgroup\$ – David Quiñones Sep 7 '15 at 9:18
  • \$\begingroup\$ Thank you for all your comments. The divide and conquer technique indeed helped me to solve the problem. My machine has only 4GB of RAM and becomes extremely hot every time I try to run ISE, it's surely part of the problem. I would love to use Vivado but it's unfortunately not free.... \$\endgroup\$ – asonnino Sep 7 '15 at 9:49
0
\$\begingroup\$

I think You may using 32 navigator on 64-bit system. Just recompile it on 64 project navigator. It makes much difference.

\$\endgroup\$
  • \$\begingroup\$ Harsha, this question was from 3 years ago, and the OP posted an answer stating that the issue was solved. Also, while there may be some merit in your reply (64-bit may be faster), there is nothing in the original question which suggests that the OP is using 32-bit, or that the problem would go away by switching to 64-bit. \$\endgroup\$ – Blair Fonville Jun 15 '18 at 23:40
2
\$\begingroup\$

I finally solved my problem and I post my answer here for futur generations.

Consistently to the advice of Brian Drummond, I created a small testbench for each module of my system and I ran the synthesis as well as the post-synthesis simulation on each on of them. Everything was working fine, none of the synthesis were taking an excessive amount of time.

Subsequently, since my device contains a large number of loops, I have made the following modifications: - removing some input/output pins by using serialisation instead - configuring the IP cores to use DSP instead of the fabric

My design could finally synthesise after a large amount of time.

I hope this may help someone else

\$\endgroup\$
  • \$\begingroup\$ I'm currently encountering a similar problem - could you possibly elaborate on what you mean by using the large number of loops working better with "DSP?" compared to "fabric?" Thank! \$\endgroup\$ – davidhood2 Mar 19 '16 at 17:07
  • \$\begingroup\$ Actually it really depends : using DSP is often faster but the amount of effort required for rooting may cause the synthesis to take too long. Therefore I suggest you to check both options (Fabric and DSP) with a smaller testbench and then increase the size of the loop step by step. \$\endgroup\$ – asonnino Mar 21 '16 at 9:07
  • \$\begingroup\$ Anyway, don't forget to check the mount of In and Out pins required by your system. One of the causes of my problem was I was using too much of them which was very expensive during the rooting operation (again, I suggest to check with a small amount and then increase it to see what happens). \$\endgroup\$ – asonnino Mar 21 '16 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.