Thanks for the feedback Jack!
On 25/05/17 13:46, Jack Hickish wrote:
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
<mailto: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
<mailto: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
<mailto:casper%2bunsubscr...@lists.berkeley.edu>.
To post to this group, send email to casper@lists.berkeley.edu
<mailto: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.
