Hi Franco, 1) Yes, this is an optimization the tools have performed. If you dig into the Xilinx manuals you can probably find some options / UCF entries to turn off this type of optimization, or at least make it less aggressive. I don't use these enough to know exactly which ones you want, but I'd start with reading about the "KEEP" and "DONT_TOUCH" attributes.
2) In my opinion this probably is detrimental, though you should keep in mind that having more "stuff" in your design is generally unhelpful too. 3) I believe if you set the vacc counters to use either DSP or fabric cores, rather than behavioural HDL (see the "implementation" tab of the counter block) this might prevent the merging of all the blocks. It's not a bad move to make large counters DSPs anyway, if you have lots of them to spare in your design. I might also be inclined to make a pblock for each vacc, with each one containing the brams and dsps associated with that accumulator. Personally, I rarely bother to constrain soft logic. Floorplanning is a bit of a dark art, and everyone has their own recipe, but if you eventually meet timing and have made notes on your methods the wiki would be a great place for them. Good luck! Jack On Tue, 23 May 2017 at 12:59 Franco <francocuro...@gmail.com> wrote: > Dear Casper community, > > > I seek your wisdom once again. I was doing floorplanning to my model > when I noticed something interesting. My model has 40 vector accumulator > blocks (simple_bram_vacc). When I opened my model in PlanAhead, I > noticed that all the BRAMs of every vacc were sharing the same single > counter implementation for addressing, instead of each vacc having its > independent counter. I understand that these two implementations are > equivalent because all the counters are equivalent and can be replaced > by a single one addressing all the BRAMs, but it makes me wonder: > > 1) Why this substitution happened? Was the Xilinx/EDK tools that tried > to do some optimization? Or it has something to do with the > simple_bram_vacc block implementation? > > 2) Isn't this implementation detrimental for routing proposes? I mean a > single counter must address 40 different BRAMs across the FPGA. (My > critical paths don't involve the counter, but they do involve a lot of > vacc BRAMs with other components). > > 3) What would you recommend me to increase the speed of my model? Force > every vacc to implement their own counter (if that's even possible)? > Group my BRAMs around or near the lonely counter? Something else? > > > As always, many thanks, > > > Franco Curotto > > -- > You received this message because you are subscribed to the Google Groups " > casper@lists.berkeley.edu" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to casper+unsubscr...@lists.berkeley.edu. > To post to this group, send email to casper@lists.berkeley.edu. > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
