Hi Dave > It would be good to add an optional "Latency" parameter to the Shared BRAM > block and allow the user to select "1" (current value that does not use the > BRAMs optional output register) or "2" (new value that does use the BRAM's > optional output register). I think this would help ROACH2 designs meet > timing more easily. I will look at this in more detail to see how involved > it would be to add this feature. Once added, I think we'll want to set the > default to 2. It would also be good to make sure the PPC side of the shared > BRAM also uses the optional output registers.
This is on a (rather long) list of library upgrades we are keen on here in SA. Other BRAM related things are; * distributed RAM implementation option (for small, 32 bit BRAMs) * configurable initial values Not sure when we will get to them and would love it if others could help out. > I think we should also be recommending that regular (i.e. non-yellow) BRAM > blocks be set to a latency of 2 at a minimum. Maybe we are already? > This also seems like an issue for ROACH as well (though the smaller chip > seems faster to cross so maybe not so important as on ROACH2?). The majority of timing problems I have run across in ROACH are BRAM to multiplier paths. BRAM followed by logic often seems ok. Maybe a separate 'BRAM to multiplier latency' parameter with a default of 2? Would that be worth the effort? Probably not but worth looking at. Cheers Andrew
