Dear all, I believe that I have resolved this problem: The OPB bus connects many components which never talk directly to each other. Since the timing analysis is static, the tools are unaware of this fact-- many of these paths are false. I strongly believe that the paths in question, for instance, are all false. Anyone who sees a similar issue might resolve the problem by adding constraints similar to these:
timespec ts_false_path0 = FROM "sbs_v8_pfx_XSG_core_config/sbs_v8_pfx_XSG_core_config/sbs_v8_pfx_x0/*" TO "*tig*" TIG; timespec ts_false_path1 = FROM "sbs_v8_pfx_*/tge_rx_inst/rx_cpu_enabled.cpu_rx_buffer/BU2/U0/blk_mem_generator/valid.cstr/ramloop*.ram.r/v*_noinit.ram/*" THRU "*OPB*" TO "sbs_v8_pfx_freqrespo_lut*_spec_cal?_?_ramblk/sbs_v8_pfx_freqrespo_lut*_spec_cal?_?_ramblk/ramb36e*" TIG; timespec ts_false_path2 = FROM "sbs_v8_pfx_*/arp_cache_inst/BU2/U0/blk_mem_generator/valid.cstr/ramloop*.ram.r/v*_init.ram/TRUE_DP.SIMPLE_PRIM18.ram*" THRU "*OPB*" TO "sbs_v8_pfx_freqrespo_lut*_spec_cal?_?_ramblk/sbs_v8_pfx_freqrespo_lut*_spec_cal?_?_ramblk/ramb36e*" TIG; In addition, I got two very useful replies to this answer; while both were private, I received permission to post them publicly. I am doing so, so that others can have the answer if this comes up David George Feb 23 (7 days ago) to me Hi Ryan. > Hey David! This is an excellent suggestion, and now that you mention it, > when I closed timing on a subsection of my design, epb_clk errors went away. > Good to think about! I'll attempt to close timing on that domain first, and > then apply epb_clk constraints. Ok good - thats what I would have expected. The tools will spend all the effort on the 'impossible' logic path and leave the easy ones unattended; hence the easy ones pollute the results. The trick is to identify the ones which the compiler spent effort on. These ones will have low values for routes etc. Figuring out timing is a dark art. > Another idea, it seems that it's just one (32-bit wide) net being bussed > everywhere, I might be able to mitigate the problem by sending several > mis-behaving bits over the global clock nets ;-) Only problem, is that we > can only use 12 bits in each clock region, which is pretty limiting for this > purpose... At 67 MHz the EPB bus shouldn't really be a problem, though I'll bet there is room for improvement, but that comes at the cost of changing something that has remained unmoved for a while and is well proven. > Mind if I include your responses in an email to the whole casper group? > That way, the next one to have this problem can just search the archives! Thats fine. > Thanks for the help! No problem; the issue caught my eye three times ;) Cheers, David Russ McWhirter <[email protected]> Feb 23 (7 days ago) to me Hi Ryan, I have had timing closure issues for our Roach firmware and used an inelegant solution. It is possible to set the PPC to add cycles to the external bus transactions. This can be done in uboot but doesn't survive a reboot. We eventually added it to the kernel build. I don't really recommend it since it relies on extra timing constraints in the fpga that could be hard to get right. In our case, a timing constraint was added to the fpga bus signals to reflect the larger setup and hold time. One of my settings for example was: setidcr 0x012 0x0011 0x1000380 The details are in page 578, PPC440EPx/GRx Embedded Processor Revision 1.15 – September 22, 2008 Preliminary User’s Manual Hope you find a better solution. On Mon, Feb 23, 2015 at 2:47 AM, Ryan Monroe <[email protected]> wrote: > [pardon the triple-post, if that happened; I appear to have mailing list > issues] > > Hey all, > > I'm designing a FX correlator on ROACH2 boards, which is targeting a user > clock rate of 312.5 MHz. However, I see TONS of failures similar to the > one posted below (see image) > > It appears that there is a super-high fanout bus which connects all the > registers and shared-memories on the processor side. I tried mitigating > this by minimizing the number of yellow blocks, but this only made the > problem worse. > > We might be able to add a cycle of latency to this bus, resolving the > timing error and making my day. Anyone have the experience to know how to > do this? Or another way to resolve the issue? I'm all out of ideas on my > end > > Thanks in advance! > > Image: https://dl.dropboxusercontent.com/u/2832602/epb_timing_fail.png > > --Ryan > >
