0

I've been having the same problem for months now. I have a quite heavy FPGA design (60% LUTs on a spartan 6) and every time I want to add a feature, it breaks all the existing features.

For instance, one of my main feature is a decoding block which reads instructions, decodes the data and answers back if everything passed. If I add a simple new feature like a LED driver (basically only 6 LEDs directly driven by the FPGA), then it breaks the decoding block (some instructions are no more supported) whereas those two blocks aren't related in any case except with the reset and clock trees.

I am using Xilinx ISE 14.7 , I've checked every path and have no timing violation (anyway I'm only working @ 60MHz).

Did that already happen to anyone? Is there a way to detect from where comes this issue?

NB: I already solved this same issue several times by adding more flexibility (delaying some critical signals by one or several clock cycles) and it comes back each time I add something new.

A. Kieffer
  • 372
  • 2
  • 13
  • Do you get this behaviour in your RTL simulation? – Matthew Taylor Jun 14 '18 at 13:19
  • 1
    If you have no timing issues combined with 'flaky' behavior, maybe you have meta-stability problems. By the 60% is not heavy, I have run reliably designs at 80%. – Oldfart Jun 14 '18 at 14:00
  • @ MatthewTaylor I simulated all blocks separately and have no problem regarding the behavior. @ Oldfart if this was a meta-stability issue, shouldn't it be impacting a specific part of the design and not random "unrelated" entities like it does? – A. Kieffer Jun 14 '18 at 14:10
  • 2
    I can only guess, using the very little, information you have provided. It depends on what is all in your design. Having timing issues after re-routing raises with me the suspicion that your design is not 100% synchronous. e.g. If you use the same, possible flawed, method to interface to each block. – Oldfart Jun 14 '18 at 17:56
  • Do you use register balancing (XST option)? I experienced that using register balancing in multi-clock system might not be the best idea. Or at least you should avoid register balancing at clock domain boundaries by setting attributes. – Juergen Jun 15 '18 at 05:26
  • You know an FPGA is a made from silicon. So you should watch out with you *heavy* design, you might break the die. ;) But ontopic: up to 80% is actually quite common for an FPGA (after that routing becomes very difficult.) In industry: if you have 60%, your not effectively using your FPGA and maybe should choose a smaller one. – JHBonarius Jun 15 '18 at 06:57
  • If your 60% filled FPGA design running at 60MHz in a Spartan 6 breaks if you add a simple component, there's probably a timing closure issue. Have you constrained your design properly? Do you have multiple clock domains/clock domain crossings? Do you have warnings for inferred latches? It can be 100's of things. You're giving us very little information. – JHBonarius Jun 15 '18 at 06:59
  • 1
    Have you read all "Warning" from your compilation tool ? There could be a lot of them but the answer can probably be there. – grorel Jun 15 '18 at 07:38
  • Thanks for all your comments. Actually I'm taking over the work of a peer and he didn't leave a lot of info regarding his work. The design is definitely not all synchronous and I said "heavy" because I couldn't share all the design with you. Anyway, I would have used a smaller FPGA if I had to choose. All the warnings I get are related to FF trimmed during compilation... I will check the register balancing. – A. Kieffer Jun 15 '18 at 08:13

0 Answers0