TimeQuest reporting paths between multiple LPM Divides

[Altera_Forum]

Hi,  

 I'm using the latest version of Quartus (12.1 with sp1) and a number of LPM dividers in a Cyclone 3 FPGA design (plus other LPMs, RAMs, PLLs, VHDL modules, etc.,). The dividers in question all have the same clock but are in different modules with completely different phasing (divide is started by different events). Numerators and denominators for different dividers come from different places.  Quartus synthesis gives warning and information but completes successfully.  However in the Worst-Case Timing Paths results I get reports of timing issues between RAMs of one divider and the pipeline registers of another even if they are in different data paths. It's easy enough to get rid of them using set_false_path in the .sdc constraint file but my question is why is TimeQuest finding these data paths which appear to me to be non-existant?  An example of this is-  entity_ir:comp_ir|sp_09:divide_resp|lpm_divide:lpm_divide_component|lpm_divide_8kr:auto_generated|sign_div_unsign_6sh:divider|alt_u_div_plg:divider|altshift_taps:DFFQuotient_rtl_1|shift_taps_a1q:auto_generated|altsyncram_mh81:altsyncram2|ram_block3a7 to entity_ir:comp_ir|e_hist:hist|e_plat_div:c_plat_div|lpm_divide:LPM_DIVIDE_component|lpm_divide_n2s:auto_generated|sign_div_unsign_lai:divider|alt_u_div_rtf:divider|DFFStage[182]  My first posting on the Altera Forum (normally able to resolve issues myself or use the Altera support), any comments on things I've not got right gratefully received.

[Altera_Forum]

Sounds like a bug at first sight. Did you try to locate the said path in the gate level (post mapping) netlist viewer?

[Altera_Forum]

--- Quote Start ---  Sounds like a bug at first sight. Did you try to locate the said path in the gate level (post mapping) netlist viewer?  --- Quote End ---    I've just had a look and (in a 48k LE design) can not really trace the path from one component to the other or really make sense of what the netlist is showing me.  I've tried a Forum search without result. To explain a little further I have about 6 LPM_dividers in the design with various other LPM elements and VHDL modules between them but no direct routes, I get paths between some of the dividers. I was really hoping that someone had seen this happen before or knew what the divider structure was. I'm wondering if there is some common element between the dividers that they are all using.

[Altera_Forum]

alt_shift_taps is a shift register built out of RAM. Quartus synthesis can merge multiple shift registers that are the same length and same clock domain, into a single altshift_taps. The problem is that the memory can only have one logical name, so it gets the name of one of the shift registers. I'm not sure if that's what's occuring, but could be it.  

a) Assignments -> Settings -> Analysis & Synthesis -> More Settings -> Allow Shift Register Merging Across Hierarchies = Off. This is a relatively new setting, and before it was available, another workaround I've previously used is: b) Create a partition on one(or both) of the hierarchies. Since there is no synthesis across hierarchies, it stops that from occurring. If this isn't it, there's a decent change item b) will fix it anyway. (The other one to turn off is under the same menu but More Settings -> Remove Duplicate Registers. Registers with the same behavior can get merged across hierarchies. I often recommend turning this off regardless, especially a high-speed desigin. You might get something silly like a toggle register that gets merged across multiple hierarchies, and now it pulls them all in together. My assumption is its the altshift_tap based on the name though...)

[Altera_Forum]

--- Quote Start ---  alt_shift_taps is a shift register built out of RAM. Quartus synthesis can merge multiple shift registers that are the same length and same clock domain, into a single altshift_taps. The problem is that the memory can only have one logical name, so it gets the name of one of the shift registers. I'm not sure if that's what's occuring, but could be it.  a) Assignments -> Settings -> Analysis & Synthesis -> More Settings -> Allow Shift Register Merging Across Hierarchies = Off. This is a relatively new setting, and before it was available, another workaround I've previously used is: b) Create a partition on one(or both) of the hierarchies. Since there is no synthesis across hierarchies, it stops that from occurring. If this isn't it, there's a decent change item b) will fix it anyway. (The other one to turn off is under the same menu but More Settings -> Remove Duplicate Registers. Registers with the same behavior can get merged across hierarchies. I often recommend turning this off regardless, especially a high-speed desigin. You might get something silly like a toggle register that gets merged across multiple hierarchies, and now it pulls them all in together. My assumption is its the altshift_tap based on the name though...)  --- Quote End ---    Sounds like a good possibility, looking in the Project Navigator only one of the 6 dividers uses a RAM block (863 bits in 9 x M9Ks) so it is possible that the rest is shared between the other dividers, presumably for the pipe-lining. I'll try the assignment setting, thanks. Doesn't the limit of 2 read/write ports on an M9K limit the sharing to two modules though?

[Altera_Forum]

Rather reminds me of a laptop pcb. Some of the instabilities were finally found to be caused by the parallel port parity and the cpu bus parity being connected together because they'd been given the same name! can't have helped the board routing either.

[Altera_Forum]

Merging altshift_taps doesn't require any more ports no matter how many you merge. At the basic level, altshift_taps is a memory with a free-running read and write counter offset by the shift register length. So let's say a shift register is 8 bits wide and 40 bits long. The write pointer would start at 40, the read pointer at 0, and they would just go. (I think the offset is a little less than 40 to account for latency, but that's the basic idea). All reads and writes are 8 bits. Now let's merge it with another shift register that is 8-bits wide and 40 long. No extra ports are needed, just the memory width is increased to 16, with half the inputs/outputs making up one shift register and the other half making up the other. But still only one read pointer and one write pointer.

[Altera_Forum]

--- Quote Start ---  Merging altshift_taps doesn't require any more ports no matter how many you merge. At the basic level, altshift_taps is a memory with a free-running read and write counter offset by the shift register length. So let's say a shift register is 8 bits wide and 40 bits long. The write pointer would start at 40, the read pointer at 0, and they would just go. (I think the offset is a little less than 40 to account for latency, but that's the basic idea). All reads and writes are 8 bits. Now let's merge it with another shift register that is 8-bits wide and 40 long. No extra ports are needed, just the memory width is increased to 16, with half the inputs/outputs making up one shift register and the other half making up the other. But still only one read pointer and one write pointer.  --- Quote End ---    OK so basically what you are saying is expand the memory width rather than use extra ports. Leads me back to my original problem of how does TimeQuest report routes between dividers, if the buses are segmented as you describe then there would be no routeing for this share as different RAM bits would go to different dividers.

[Altera_Forum]

I can't say for the specific case. Note that one other case I've seen RAMs shared is when it's two single port RAMs can be merged into one dual-port RAM block. In that case though, I'm pretty sure the fitter has complete flexibility to merge and unmerge them to meet timing, so I've never seen it cause timing issues. (I t hink they maintain seperate logical names too, so you wouldn't even notice it like you are, so that's probably not it). 

There is no "divider RAM" merging algorithm, so you'll need to dig in and see what exactly is being merged and try to figure out why, or see if you can manually prevent it from occurring. Were you able to try the partitions?  Also, are you sure the merging is what's causing worse timing? (That is probably hard to diagnose without stopping it from happening and comparing).