Assuming that the pblock is not overlapping with any other pblocks, and
that you have not constrained any other resources in the pblock, I have
used 99% of the resources in a pblock (simply made it as small as
possible). The trouble comes into play when there are resources which
are not in the pblock, but also somehow constrained in the region.
If my errors are especially egregious, I'll often relax my timing
constraints, try to close timing at a lower speed, and then increase the
goal once it becomes more reasonable. The tools really do not handle
failing constraints miserably very well.
Cheers,
-Ryan
On 11/09/2015 07:40 AM, Amit Bansod wrote:
Hi Ryan,
I could get rid of those errors but the tool had hard time in placing
with huge setup timing errors. How much utilization is good to set on
p-blocks ?
Currently, I had 60-70% for different components.
Cheers,
Amit
On 05-Nov-15 9:46 AM, Ryan Monroe wrote:
Hi Amit,
FYI, I am CC'ing the CASPER list on all of these emails, so that they
can be searchable for people in the future.
The placements I gave you were for my personal design, and may not work
for yours. When choosing pblock size, be sure to look at the pblock
utilization in planahead. odds are that you had either
1. a pblock which was outright too small for the components placed
within (tools error out almost instantly)
2. multiple overlapping pblocks, in such a way that it's impossible to
satisfy both constraints simultaneously (tools error out after much
longer). pblock statistics don't help with this one, but you can bash
it out by hand with more difficulty.
look at the error from line 327-561 on your report. this indicates the
constraints which caused the issue, as well as some of the components
involved. that's a good place to start!
--Ryan
On 11/05/2015 12:20 AM, aban...@mpifr-bonn.mpg.de wrote:
Hi Ryan,
I tried to place the 10gbe pblocks as you suggested. Unfortunately,
the tool was unable to place all components. The pblock statistics
were more than enough. Do you know how to avoid this problem ? The
tool took long time to give out errors (~11 hrs).
I have enclosed the map report.
Regards,
Amit
On 04.11.2015 09:37, Ryan Monroe wrote:
np! the 10gbe core wasn't really intended to run at fast clock
rates. Be sure to constrain it to the east-ish side of the chip, this
is almost either a
1. device utilization issue (you are trying to do too much stuff on
the chip), or
2. placement issue (probably this)-- the tools are terrible at
placing things in the right spots
Send me any questions you have, but I'm pretty busy and reserve the
right to be bad about answering ;-)
--Ryan
On 11/04/2015 12:32 AM, Amit Bansod wrote:
Hi Ryan,
Thanks a lot! I will give this a try!
Cheers,
Amit
On 04-Nov-15 9:31 AM, Ryan Monroe wrote:
Dear Amit,
Please consider my memo 50 on the CASPER list: "Performance
optimization
for Virtex 6 CASPER designs" [1]
As it turns out, I have a design open right now, which must close 8
10gbe cores at 312.5 mhz. Attached is an image of where I placed my
tge_tx_inst and tge_rx_inst pblocks, which I hope will be helpful for
you. Wish I had time to do more for you, but such is life :-/
Cheers!
--Ryan Monroe
[1] https://casper.berkeley.edu/wiki/Memos
On 11/04/2015 12:17 AM, aban...@mpifr-bonn.mpg.de wrote:
Dear All,
I am getting following timing errors on 10GbE yellow blocks which
I am
finding it hard to get rid off. I am running my design at 200 MHz. I
have given the device utilization summary if it is useful. I have
also
enclosed the files.
Best Regards,
Amit
Timing Errors:
Timing constraint: PERIOD analysis for net
"d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/
mmcm_clkout1" derived from PERIOD analysis for net
"d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/
adc_clk_div" derived from NET
"d_codd_64ch_2_P0_ADC_asiaa_adc5g/d_codd_64ch_2_P0_ADC_asiaa_adc5g/adc_clk"
PERIOD = 2.5 ns HIGH 50%; multiplied by 2.00 to 5 nS and duty
cycle
corrected to HIGH 2.500 nS
For more information, see Period Analysis in the Timing Closure
User
Guide (UG612).
1594959 paths analyzed, 343705 endpoints analyzed, 63 failing
endpoints
63 timing errors detected. (63 setup errors, 0 hold errors, 0
component switching limit errors)
Minimum period is 5.727ns.
Slack: -0.727ns (requirement - (data path - clock
path skew + uncertainty))
Source:
d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/app_tx_validR
(FF)
Destination:
d_codd_64ch_2_10G_10GBE2_gbe00/d_codd_64ch_2_10G_10GBE2_gbe00/tge_tx_inst/tx_packet_fifo_inst/BU2/U0/grf.rf/mem/gbm.gbmg.gbmga.ngecc.bmg/blk_mem_generator/valid.cstr/ramloop[1].ram.r/v5_noinit.ram/SDP.SINGLE_PRIM36.TDP
(RAM)
Requirement: 5.000ns
Data Path Delay: 5.721ns (Levels of Logic = 1)
Clock Path
