Re: [casper] Help with PlanAhead

2017-05-25 Thread Franco 
I actually didn't know that tool existed! I am trying to meet timing 
constraints, and I'm actually very close to do so, so I'm definitely 
gonna try smartxplorer. Thanks for the advise!


Franco


On 25/05/17 15:24, Michael D'Cruze wrote:

Hi Franco,

Just curious, but have you considered using SmartXplorer to assist in getting 
your design to meet timing, if this is the eventual goal? Usually I find that 
with a medium or large design, if I can adjust the latencies in Simulink to get 
within a timing score of, say, 1, then running smartxplorer on those 
netlist files usually finishes off the job. It can take a very, very long time 
though since it is a brute-force method. Most jobs for me complete within about 
24hrs, however the largest design I ever tried took a full week...

Good luck
Michael

-Original Message-
From: Franco [mailto:francocuro...@gmail.com]
Sent: 23 May 2017 20:59
To: Casper Lists
Subject: [casper] Help with PlanAhead

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.

Re: [casper] Help with PlanAhead

2017-05-25 Thread Franco 

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 > 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.

RE: [casper] Help with PlanAhead

2017-05-25 Thread Michael D'Cruze 
Hi Franco,

Just curious, but have you considered using SmartXplorer to assist in getting 
your design to meet timing, if this is the eventual goal? Usually I find that 
with a medium or large design, if I can adjust the latencies in Simulink to get 
within a timing score of, say, 1, then running smartxplorer on those 
netlist files usually finishes off the job. It can take a very, very long time 
though since it is a brute-force method. Most jobs for me complete within about 
24hrs, however the largest design I ever tried took a full week...

Good luck
Michael

-Original Message-
From: Franco [mailto:francocuro...@gmail.com] 
Sent: 23 May 2017 20:59
To: Casper Lists
Subject: [casper] Help with PlanAhead

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.

Re: [casper] Help with PlanAhead

2017-05-25 Thread Jack Hickish 
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  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.