Doka 1 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба Приветствую! Хотелось бы собрать в одном месте информацию по техникам борьбы с неразводимостью проекта в Vivado, Есть конкретный кейс, большой проект на VU13P специфика которого в том, что ядра, которые реализованы пересекаются друг с другом (например одно ядро использует 90% из всех DSP на конкретном SLR, а другое - 80% RAM SLR, а третье - половину всех LUT SLR). Репорт о роутинге: Spoiler Phase 7 Route finalize Router Utilization Summary Global Vertical Routing Utilization = 36.6048 % Global Horizontal Routing Utilization = 41.0523 % Routable Net Status* *Does not include unroutable nets such as driverless and loadless. Run report_route_status for detailed report. Number of Failed Nets = 0 Number of Unrouted Nets = 0 Number of Partially Routed Nets = 0 Number of Node Overlaps = 8 Congestion Report North Dir 16x16 Area, Max Cong = 85.4607%, Congestion bounded by tiles (Lower Left Tile -> Upper Right Tile): INT_X48Y800 -> INT_X63Y815 INT_X48Y799 -> INT_X63Y814 INT_X48Y798 -> INT_X63Y813 INT_X48Y801 -> INT_X63Y816 INT_X49Y800 -> INT_X64Y815 South Dir 16x16 Area, Max Cong = 86.3837%, Congestion bounded by tiles (Lower Left Tile -> Upper Right Tile): INT_X80Y624 -> INT_X95Y639 INT_X80Y623 -> INT_X95Y638 INT_X80Y622 -> INT_X95Y637 INT_X80Y621 -> INT_X95Y636 INT_X80Y620 -> INT_X95Y635 East Dir 16x16 Area, Max Cong = 88.4878%, Congestion bounded by tiles (Lower Left Tile -> Upper Right Tile): INT_X80Y672 -> INT_X95Y687 INT_X80Y640 -> INT_X95Y655 INT_X80Y624 -> INT_X95Y639 INT_X80Y671 -> INT_X95Y686 INT_X80Y639 -> INT_X95Y654 West Dir 32x32 Area, Max Cong = 85.3713%, Congestion bounded by tiles (Lower Left Tile -> Upper Right Tile): INT_X80Y568 -> INT_X111Y599 INT_X80Y567 -> INT_X111Y598 INT_X81Y570 -> INT_X112Y601 INT_X81Y569 -> INT_X112Y600 INT_X81Y568 -> INT_X112Y599 ------------------------------ Reporting congestion hotspots ------------------------------ Direction: North ---------------- Congested clusters found at Level 4 Effective congestion level: 4 Aspect Ratio: 1 Sparse Ratio: 1 Direction: South ---------------- Congested clusters found at Level 3 Effective congestion level: 5 Aspect Ratio: 0.4 Sparse Ratio: 1.25 Direction: East ---------------- Congested clusters found at Level 3 Effective congestion level: 5 Aspect Ratio: 0.2 Sparse Ratio: 1.875 Direction: West ---------------- Congested clusters found at Level 4 Effective congestion level: 5 Aspect Ratio: 0.666667 Sparse Ratio: 1.5 Phase 7 Route finalize | Checksum: 15f0897ad Time (s): cpu = 15:41:48 ; elapsed = 04:23:26 . Memory (MB): peak = 30538.500 ; gain = 5110.973 ; free physical = 15565 ; free virtual = 54647 Phase 8 Verifying routed nets CRITICAL WARNING: [Route 35-162] 16 signals failed to route due to routing congestion. Please run report_route_status to get a full summary of the design's routing. Below is a list of the top 10 physical nodes with signal overlaps and up to 5 of the signals that were contending for this node resource: Resolution: Run report_route_status to get a full summary of the design's routing. To find the areas of the congestion, use the route congestion Metrics in the Device View and check the logfile for the Congestion Report. 1. Tile Name: INT_X92Y697 Node: NN12_BEG4 Overlapping Nets: 2 core0_u0/unit0_u0/unit0_sliced_pipeline/final_pipeline_slr1[27].ch_final_round_slr1/dout_reg1__5/P[29] core1_u0/rndP/rndP[5].P/swP/sw[1018] 2. Tile Name: INT_X87Y680 Node: NN2_E_BEG2 Overlapping Nets: 2 core2_u0/unit1_u0/f2_2/xl[32] core2_u0/unit1_u0/f0_2_pipeline_1/st_reg[51][255]_0[81] 3. Tile Name: INT_X82Y718 Node: EE4_W_BEG5 Overlapping Nets: 2 core1_u0/rndP/rndP[5].P/swP/sw[156] core2_u0/unit1_u0/f1_2/expander2_out4_genblk[9].expander2_out4_pipeline/st_reg[1][31]_0 4. Tile Name: INT_X91Y698 Node: INT_NODE_IMUX_44_INT_OUT0 Overlapping Nets: 2 core1_u0/rndP/rndP[4].P/mx/dout[343] core1_u0/rndP/rndP[4].P/mx/dout[342] 5. Tile Name: INT_X94Y709 Node: INT_NODE_SDQ_27_INT_OUT0 Overlapping Nets: 2 core1_u0/rndP/rndP[4].P/mx/dout[444] core0_u0/unit0_u0/unit0_sliced_pipeline/final_pipeline_slr1[28].ch_final_round_slr1/p_0_out[649] 6. Tile Name: INT_X84Y687 Node: INT_NODE_SDQ_86_INT_OUT1 Overlapping Nets: 2 core2_u0/unit1_u0/f2_2/xh[42] core2_u0/unit1_u0/f1_2/f1_expander2_13/v2[53] 7. Tile Name: INT_X86Y696 Node: INT_NODE_SDQ_19_INT_OUT1 Overlapping Nets: 2 core2_u0/unit1_u0/f2_2/xl[58] core2_u0/unit1_u0/f1_2/f1_expander2_13/t1_reg[1]__0[32] 8. Tile Name: INT_X98Y703 Node: INT_NODE_SDQ_78_INT_OUT0 Overlapping Nets: 2 core1_u0/rndP/rndP[5].P/mx/dout_reg[1023]_0[613] core1_u0/rndP/rndP[5].P/swP/sw[586] Verification failed Phase 8 Verifying routed nets | Checksum: 15f0897ad Time (s): cpu = 15:41:57 ; elapsed = 04:23:35 . Memory (MB): peak = 30538.500 ; gain = 5110.973 ; free physical = 15532 ; free virtual = 54614 CRITICAL WARNING: [Route 35-2] Design is not legally routed. There are 8 node overlaps. Resolution: Run report_design_analysis -congestion and -complexity to find potential sources of congestion in the areas where nets are not fully routed and review UG906 for design closure techniques. степень утилизации: Spoiler +----------------------------+--------+--------+--------+--------+--------+--------+--------+--------+ | Site Type | SLR0 | SLR1 | SLR2 | SLR3 | SLR0 % | SLR1 % | SLR2 % | SLR3 % | +----------------------------+--------+--------+--------+--------+--------+--------+--------+--------+ | CLB | 51798 | 52168 | 45983 | 52097 | 95.92 | 96.61 | 85.15 | 96.48 | | CLBL | 28108 | 28164 | 24780 | 28182 | 96.00 | 96.19 | 84.63 | 96.25 | | CLBM | 23690 | 24004 | 21203 | 23915 | 95.83 | 97.10 | 85.77 | 96.74 | | CLB LUTs | 336367 | 343240 | 276808 | 341927 | 77.86 | 79.45 | 64.08 | 79.15 | | LUT as Logic | 325611 | 317090 | 250880 | 330439 | 75.37 | 73.40 | 58.07 | 76.49 | | using O5 output only | 7 | 117 | 30 | 118 | <0.01 | 0.03 | <0.01 | 0.03 | | using O6 output only | 271361 | 252503 | 187645 | 177455 | 62.82 | 58.45 | 43.44 | 41.08 | | using O5 and O6 | 54243 | 64470 | 63205 | 152866 | 12.56 | 14.92 | 14.63 | 35.39 | | LUT as Memory | 10756 | 26150 | 25928 | 11488 | 5.44 | 13.22 | 13.11 | 5.81 | | LUT as Distributed RAM | 0 | 0 | 0 | 0 | 0.00 | 0.00 | 0.00 | 0.00 | | LUT as Shift Register | 10756 | 26150 | 25928 | 11488 | 5.44 | 13.22 | 13.11 | 5.81 | | using O5 output only | 0 | 1 | 6 | 0 | 0.00 | <0.01 | <0.01 | 0.00 | | using O6 output only | 6468 | 7330 | 9450 | 3584 | 3.27 | 3.71 | 4.78 | 1.81 | | using O5 and O6 | 4288 | 18819 | 16472 | 7904 | 2.17 | 9.52 | 8.33 | 4.00 | | CLB Registers | 233571 | 353489 | 273074 | 386467 | 27.03 | 40.91 | 31.61 | 44.73 | | CARRY8 | 11126 | 4096 | 4672 | 9020 | 20.60 | 7.59 | 8.65 | 16.70 | | F7 Muxes | 35840 | 57123 | 27648 | 0 | 16.59 | 26.45 | 12.80 | 0.00 | | F8 Muxes | 17920 | 28534 | 13824 | 0 | 16.59 | 26.42 | 12.80 | 0.00 | | F9 Muxes | 0 | 0 | 0 | 0 | 0.00 | 0.00 | 0.00 | 0.00 | | Block RAM Tile | 608 | 338.5 | 448 | 432 | 90.48 | 50.37 | 66.67 | 64.29 | | RAMB36/FIFO | 0 | 0 | 0 | 0 | 0.00 | 0.00 | 0.00 | 0.00 | | RAMB18 | 1216 | 677 | 896 | 864 | 90.48 | 50.37 | 66.67 | 64.29 | | RAMB18E2 only | 1216 | 677 | 896 | 864 | 90.48 | 50.37 | 66.67 | 64.29 | | URAM | 0 | 0 | 0 | 0 | 0.00 | 0.00 | 0.00 | 0.00 | | DSPs | 789 | 2560 | 2560 | 1536 | 25.68 | 83.33 | 83.33 | 50.00 | | PLL | 0 | 0 | 0 | 0 | 0.00 | 0.00 | 0.00 | 0.00 | | MMCM | 0 | 0 | 0 | 0 | 0.00 | 0.00 | 0.00 | 0.00 | | Unique Control Sets | 1 | 1 | 1 | 1 | <0.01 | <0.01 | <0.01 | <0.01 | +----------------------------+--------+--------+--------+--------+--------+--------+--------+--------+ Собственно репорт рекомендует попробовать: report_design_analysis -congestion report_design_analysis -complexity и штудировать UG906 report_design_analysis -complexity: Spoiler +-------------------+---------------+------+----------------+-----------------+-------------+---------------+---------------+---------------+---------------+---------------+------------+------+------+--------+------+ | Instance | Module | Rent | Average Fanout | Total Instances | LUT1 | LUT2 | LUT3 | LUT4 | LUT5 | LUT6 | Memory LUT | DSP | RAMB | MUXF | URAM | +-------------------+---------------+------+----------------+-----------------+-------------+---------------+---------------+---------------+---------------+---------------+------------+------+------+--------+------+ | (top) | main_pipeline | 0.59 | 2.41 | 3150349 | 13408(0.9%) | 371534(23.8%) | 325536(20.9%) | 215662(13.8%) | 162849(10.4%) | 469815(30.1%) | 121805 | 7445 | 3653 | 180889 | 0 | | core10___xxxx_u0 | core10___xxxx | 0.60 | 1.88 | 205350 | 281(0.4%) | 3730(5.7%) | 32220(49.4%) | 15786(24.2%) | 4650(7.1%) | 8563(13.1%) | 9750 | 0 | 0 | 0 | 0 | | core2_xx_u0 | core2_xxxx | 0.70 | 1.67 | 210208 | 4252(6.6%) | 22757(35.6%) | 17565(27.5%) | 18813(29.4%) | 1(0.0%) | 592(0.9%) | 42400 | 0 | 0 | 0 | 0 | | core0____xxxx_u0 | core0____xxxx | 0.00 | 1.47 | 546811 | 251(0.1%) | 106496(50.0%) | 106240(49.9%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0 | 6656 | 0 | 0 | 0 | | core3_xxxx_u0 | core3__xxxx | 0.75 | 3.81 | 229776 | 0(0.0%) | 7231(5.3%) | 592(0.4%) | 6903(5.1%) | 28292(20.9%) | 92358(68.2%) | 512 | 0 | 1216 | 53760 | 0 | | core4_xxxx_u0 | core4__xxxx | 0.76 | 3.27 | 263854 | 106(0.1%) | 33136(24.3%) | 5344(3.9%) | 5953(4.4%) | 8597(6.3%) | 83233(61.0%) | 24872 | 0 | 228 | 47995 | 0 | | core1___xxxx_u0 | core1___xxxx | 0.61 | 3.94 | 326319 | 53(0.0%) | 11863(5.4%) | 10775(4.9%) | 16185(7.3%) | 29023(13.1%) | 153771(69.4%) | 512 | 0 | 1760 | 41472 | 0 | | core5_xxxx_u0 | core5___xxxx | -^ | 3.06 | 232233 | 35(0.0%) | 13389(9.2%) | 30558(21.0%) | 40533(27.9%) | 22477(15.5%) | 38428(26.4%) | 5539 | 0 | 0 | 0 | 0 | | core6_xxxx_u0 | core6___xxxx | 0.81 | 2.84 | 248804 | 19(0.0%) | 21763(13.6%) | 21516(13.4%) | 85187(53.2%) | 21120(13.2%) | 10624(6.6%) | 1024 | 0 | 0 | 0 | 0 | | core7_xxxx_u0 | core7___xxxx | -^ | 2.13 | 155332 | 0(0.0%) | 0(0.0%) | 73402(90.2%) | 458(0.6%) | 7486(9.2%) | 0(0.0%) | 0 | 0 | 0 | 0 | 0 | | core8_xxxx_u0 | core8___xxxx | 0.89 | 3.33 | 191090 | 217(0.2%) | 16701(17.0%) | 4749(4.8%) | 6257(6.4%) | 8635(8.8%) | 61483(62.7%) | 10347 | 0 | 449 | 37662 | 0 | | core9_xxxx_u0 | core9___xxxx | 0.50 | 1.99 | 230790 | 2839(2.9%) | 46692(47.1%) | 4284(4.3%) | 14015(14.1%) | 19806(20.0%) | 11421(11.5%) | 8993 | 789 | 0 | 0 | 0 | | core11_xxxx_u0 | core11___xxxx | 0.71 | 1.59 | 196006 | 5222(5.8%) | 82815(91.8%) | 0(0.0%) | 1024(1.1%) | 512(0.6%) | 641(0.7%) | 11264 | 0 | 0 | 0 | 0 | | slr_cross_u10 | slr_cross | 0.00 | 1.00 | 2048 | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0 | 0 | 0 | 0 | 0 | | slr_cross_u2 | slr_cross_0 | 0.00 | 7.75 | 2048 | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0 | 0 | 0 | 0 | 0 | | slr_cross_u6 | slr_cross_1 | 0.00 | 1.00 | 2048 | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0 | 0 | 0 | 0 | 0 | | slr_cross_u9 | slr_cross_2 | 0.00 | 1.00 | 2048 | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0(0.0%) | 0 | 0 | 0 | 0 | 0 | | cc3_xxxx_u0 | cc3_xxxx | 0.71 | 2.36 | 105584 | 133(0.3%) | 4961(10.1%) | 18291(37.4%) | 4548(9.3%) | 12250(25.1%) | 8701(17.8%) | 6592 | 0 | 0 | 0 | 0 | +-------------------+---------------+------+----------------+-----------------+-------------+---------------+---------------+---------------+---------------+---------------+------------+------+------+--------+------+ report_design_analysis -congestion: Spoiler 1. Placer Final Level Congestion Reporting ------------------------------------------ +-----------+-------+------------+----------------------------------+------------------------------+---------------+---------------+-----+--------+------+------+------+------+------+-------+-----+ | Direction | Level | Congestion | Window | Cell Names | Combined LUTs | Avg LUT Input | LUT | LUTRAM | Flop | MUXF | RAMB | URAM | DSP | CARRY | SRL | +-----------+-------+------------+----------------------------------+------------------------------+---------------+---------------+-----+--------+------+------+------+------+------+-------+-----+ | North | 6 | 101% | (CLEL_R_X71Y625,CLEL_R_X101Y688) | core3_u0/core3_u0/f1_2(37%) | 10% | 2.708 | 59% | 0% | 66% | 0% | 100% | 0% | 86% | 37% | 63% | | East | 5 | 124% | (CLEL_R_X41Y383,CLEL_R_X56Y414) | core5_xxxx_u0(71%) | 0% | 2.573 | 61% | 0% | 62% | 0% | 0% | NA | 100% | 26% | 13% | | South | 6 | 102% | (CLEM_X33Y755,CLEM_X63Y818) | core7_xxxx_u0(53%) | 16% | 2.982 | 76% | 0% | 43% | 0% | 100% | NA | 89% | 32% | 15% | | West | 5 | 125% | (CLEL_L_X86Y568,CLEM_X101Y599) | core3_u0/core3_u0/f1_1(64%) | 6% | 2.989 | 63% | 0% | 75% | 1% | 100% | 0% | 81% | 45% | 65% | +-----------+-------+------------+----------------------------------+------------------------------+---------------+---------------+-----+--------+------+------+------+------+------+-------+-----+ Какие выводы из этого всего напрашиваются: 1. Отключение LUT combining (если допустимо) 2. Использование ограничений по -max_fanout 3. opt_design -directive ExploreArea 4. place_design -directive AltSpreadLogic_medium или place_design -directive AltSpreadLogic_high 5. route_design -directive AlternateCLBRouting 6. phys_opt_design -directive AggressiveExplore (под вопросом) 7. Понижение частоты дизайна (если возможно) Итого, с помощью некоторых из приведенных способов удалось число пересечений свести от восьми к двум, поэтому интересно дополнить этот список, чтобы продолжить эксперименты. что еще можно попробовать? ------------------------ upd: 8. Синтезировать с оверконстрейном по частоте и ретаймингом (но поскольку это не ASIC, то работает только в определенном диапазоне частот), а разводить на фактической частоте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TRILLER 0 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба На мой взгляд, есть лишь единственный способ надёжно водить большие проекты на 400-500 МГц: закладывать подобную сложность ещё на этапе написания исходников и с чётким осознанием маршрута проектирования. Все остальное - это монетка при любом изменении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба Приветствую! При высоких процентах использования ресурсов роутинг та еще головная боль. Поэтому кроме всего вами перечисленного остается вариант танцев с "бубном" - анализ крит. мест, фиксация отдельных примитивов/блоков дизайна на кристалле, поиск конфигурации в которой вероятность успешного P&R максимальна. Обычно несколько итераций приводит к пониманию что наиболее критично влияет на воспроизводимость P&R. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба 11 minutes ago, TRILLER said: На мой взгляд, есть лишь единственный способ надёжно водить большие проекты на 400-500 МГц: закладывать подобную сложность ещё на этапе написания исходников и с чётким осознанием маршрута проектирования. А что вы подразумеваете под этой фразой? Можете привести примерный маршрут проектирования? Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexadmin 0 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба Перевожу на русский. "закладывать подобную сложность ещё на этапе " - взять кристалл побольше ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tpeck 0 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба 1 hour ago, Doka said: Хотелось бы собрать в одном месте информацию по техникам борьбы с неразводимостью проекта в Vivado, Вот в ISE была замечена такая особенность, что качество P&R зависит от частоты. Грубо до 200 МГц, разводит так, а после 200 разводит сяк. Собственно, на низких частотах могли сходится одни узлы, а на высоких совсем другие. Есть ли такая особенность в Vivade? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Doka 1 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба 34 minutes ago, Tpeck said: качество P&R зависит от частоты. точно. добавил 8й пункт Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 21 марта, 2019 Опубликовано 21 марта, 2019 · Жалоба Приветствую! 2 hours ago, Tpeck said: что качество P&R зависит от частоты (constraint) Было бы странно если бы это было не так. 3 hours ago, Doka said: 8. Синтезировать с оверконстрейном по частоте и ретаймингом (но поскольку это не ASIC, то работает только в определенном диапазоне частот), а разводить на фактической частоте. Синтез с оверконстрейном смысла не имеет - только хуже сделает. Тем более в Vivado - как мне кажется синтез идет вообще без времянки а лишь затем грузятся констрейны и запускается некая post-synthesis оптимизация. IMHO основной упор в Vivado сделан на physical synthesis во время P&R. При плотном заполнении по ресурсам проблемы P&R другого рода. Так как модули могут занимать всю площадь то алгоритм place легко может попасть в локальный минимум функции оптимизации при начальном размещении. Особенно в сильно-связанных дизайнах. Поэтому надо ручками помогать ограничивая начальный "полет фантазии" и вырисовывая структуру на кристалле в соответствии с data-flow. Ну или заниматься интерактивным рукоприкладством во время P&R - сделали начальное P&R (с разными вариантами оптимизаций). Посмотрели где затык. Сделали unroute,unplace проблемной части. И по новой до-разместили/до-развели. Полученный результат зафиксили и используем как референс для следующего P&R. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 22 марта, 2019 Опубликовано 22 марта, 2019 · Жалоба ИМХО, зря в вивадо убрали seed. А еще частное. вивдо очень странно разводит артикс 200ку после заполнения 75%. из-за H образной архитектуры чипа, он порой такие финты выбрасывает, что диву даешься. И да, при определенных размерах составных модулей, ручное позиционирование там плохо работает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 22 марта, 2019 Опубликовано 22 марта, 2019 · Жалоба 4 часа назад, des00 сказал: ИМХО, зря в вивадо убрали seed. Когда-то слушал докладчика из Xilinx, который утвержал, что seed больше не нужен, т.к. Вивадо в отличие от ISE при оптимизации находит глобальный минимум, а не падает в локальный. Однако, практика применения показывает, что это скорее всего не так :) Бывает, достаточно изменить значение какой-нибудь константы (например, номер версии или дату, хе-хе), чтобы получить -0.3нс слака, там где раньше был ноль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 27 22 марта, 2019 Опубликовано 22 марта, 2019 · Жалоба Приветствую. 4 minutes ago, Flood said: Когда-то слушал докладчика из Xilinx, который утвержал, что seed больше не нужен, т.к. Вивадо в отличие от ISE при оптимизации находит глобальный минимум, а не падает в локальный. Увы нахождение глобального минимума это NP полная задача и для современных FPGA это недостижимая перспектива. Да в Vivado поменяли алгоритм P&R и в сравнении с ISE он действительно более предсказуем и размещает более компактно чем ISE. Но зависимость от начальных условий ни куда не исчезла. IMHO поэтому Xilinx и развивает инструменты интерактивного P&R. Удачи! Rob. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 22 марта, 2019 Опубликовано 22 марта, 2019 · Жалоба 31 минуту назад, RobFPGA сказал: Да в Vivado поменяли алгоритм P&R и в сравнении с ISE он действительно более предсказуем и размещает более компактно чем ISE. Но зависимость от начальных условий ни куда не исчезла. IMHO поэтому Xilinx и развивает инструменты интерактивного P&R. А есть в вивадо какой-нибудь аналог сида? Я обычно держу несколько стратегий сборки - как правило, одна да сработает. Но это приводит к значительным потерям времени - из-за сложных стратегий. Тогда как на деле хватило бы запуска обычной стратегии с разными начальными условиями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 22 марта, 2019 Опубликовано 22 марта, 2019 · Жалоба 1 hour ago, Flood said: А есть в вивадо какой-нибудь аналог сида? Я обычно держу несколько стратегий сборки - как правило, одна да сработает. Но это приводит к значительным потерям времени - из-за сложных стратегий. Тогда как на деле хватило бы запуска обычной стратегии с разными начальными условиями. я фанауты кручу. стратегии сильно по времени разнятся, а так 400-512 несколько точек и получается) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 22 марта, 2019 Опубликовано 22 марта, 2019 · Жалоба 1 час назад, des00 сказал: я фанауты кручу. стратегии сильно по времени разнятся, а так 400-512 несколько точек и получается) О! Вот это метод! :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fguy 4 23 марта, 2019 Опубликовано 23 марта, 2019 · Жалоба On 3/22/2019 at 5:50 AM, des00 said: А еще частное. вивдо очень странно разводит артикс 200ку после заполнения 75%. из-за H образной архитектуры чипа, он порой такие финты выбрасывает, что диву даешься. И да, при определенных размерах составных модулей, ручное позиционирование там плохо работает. Еще и разные версии его разводят по разному. Давеча переразводил проект - по лютам около 60% - в 2018.2 разводится за пару часов и с оптимизацией и без, а 2018.3 с оптимизацией на роуте в 4м пункте уходит в задумье более чем на час до вывода первой строки с оверлапами (тыщ 30) - чем кончиться ждать не стал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
