Hi, Andrew, On Feb 13, 2013, at 11:27 PM, Andrew Martens wrote:
> Hi Dave > >> It would be good to add an optional "Latency" parameter to the Shared BRAM >> block > > This is on a (rather long) list of library upgrades we are keen on here > in SA. I just looked into this and discovered that the "bram_block" pcore is a Xilinx provided one and surprisingly it seems NOT to support the optional output registers or, equivalently, latency! I think to provide a latency feature (to take advantage of the BRAM's optional output registers) we will need to create our own variant of this pcore. > Other BRAM related things are; > * distributed RAM implementation option (for small, 32 bit BRAMs) > * configurable initial values These would be nice to have, but IMHO not so critical as fixing this timing albatross. > Not sure when we will get to them and would love it if others could help > out. Same here! :-) > >> 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. I think just setting the latency to 2 (or more) on the relevant Xilinx BRAM blocks would help. I'm not sure where a separate "BRAM to multiplier latency" parameter would be used/applicable. Dave
