alexadmin

Можно взять кристалл в котором есть внутренние z-буферы. Только, боюсь, они еще в прошлом веке закончились...

Теоретически можно, на практике кроме схемотехники потребуется еще много пост-обработки с калибровкой из-за немного разных характеристик используемых АЦП. Вообще говоря, современные высокоскоростные АЦП так и делаются - внутри одной микросхемы собрано несколько АЦП и небольшой компьютер, обсчитывающий результат.

Как раз вчера читал заметку из совсем другого мира - как работая из под рута в линуксе можно загубить материнку таким же образом, записав куда не надо.

Погода фиговая, метель. Частоту jtag поменьше сделать. Ну и проверить, что кристалл все-таки правильный выбран.

А что, правда моделсим на Вин 8.1 не работает (в примечании указано только 8.0)?

По моим давним воспоминаниям .mif должен лежать в каталоге скомпилированной библиотеки моделсима, а не в верхнем каталоге проекта.

IORD_ALTERA_AVALON_PIO_DATA в любом случае вернет uint32. Если у вас актуальный только один бит, то накладывайте на результат маску 0x1, в старших битах может оказаться произвольное значение.

А если самим ISE синтезировать, не пробовали?

Меня сейчас растопчут ногами, но я давно уже махнул рукой на временной анализ I/O для взаимодействия с АЦП/ЦАП. Ибо гарантированной работоспособности так толком добиться и не смог. Где-то тут на форуме были мои страдания на эту тему. Вместо этого делаю регулируемую задержку в пине и выбираю оптимальное значение задержки путем натурных испытаний (или кручу фазу клока PLL как альтернативный вариант.

На самом деле вопрос тот еще. С системной точки зрения один клок - безусловно проще и меньше рисков на "функциональном" уровне. Дальше же начинаются всякие "но". Если проект большой и сложный, то единый клок (да еще большей частоты, чем минимально необходим) гуляющий по всему кристаллу может стать проблемой в плане производительности. Недаром в современных кристаллах стали появляться клоковые цепи не только глобальные, но и разделенные по регионам. Так что если какие-то части проекта можно уложить в отдельный регион кристалла и использовать региональный клок - это плюс. Понятное дело, что если кристалл простенький только с общими глобальными клоками, то выбор намного упрощается ;) В общем стоит смотреть по используемому кристаллу и нагрузке как по ресурсам, так и по требуемой частоте.

Я может странную вещь скажу, но задавать счетчика как integer можно и вовсе не используя numeric_std.

Правильно! К чему это старье. Даешь numeric_std_unsigned и numeric_std_signed ! ;)

Через столько версий чразу вряд ли получится. Там и интерфейсы могли поменяться, если кристаллы разные совсем труба. Я из 11 в 14 как-то таскал и то проблемы были, что-то проще оказалось с нуля перегенерить. Вариант на любителя - посnавить несколько версий ISE и попробовать последовательно 8 => 10 => 12 => 14 ;)

Вот, один из предыдущих результатов сборки. Это небольшой набор регистров, прикрученных к микроблэйзу. Paths for end point prj2_hw_test_top_i/prj_top_i/inst_external_interface/mem_data_29_7 (SLICE_X75Y73.CE), 50 paths -------------------------------------------------------------------------------- Slack (setup path): -0.505ns (requirement - (data path - clock path skew + uncertainty)) Source: prj2_hw_test_top_i/prj_top_i/inst_mbcore/U0/iomodule_0/IO_Address_29 (FF) Destination: prj2_hw_test_top_i/prj_top_i/inst_external_interface/mem_data_29_7 (FF) Requirement: 6.510ns Data Path Delay: 6.755ns (Levels of Logic = 4) Clock Path Skew: -0.132ns (1.496 - 1.628) Source Clock: w_clk_153m6k rising at 0.000ns Destination Clock: w_clk_153m6k rising at 6.510ns Clock Uncertainty: 0.128ns Clock Uncertainty: 0.128ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.070ns Discrete Jitter (DJ): 0.245ns Phase Error (PE): 0.000ns Maximum Data Path at Slow Process Corner: prj2_hw_test_top_i/prj_top_i/inst_mbcore/U0/iomodule_0/IO_Address_29 to prj2_hw_test_top_i/prj_top_i/inst_external_interface/mem_data_29_7 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- SLICE_X42Y165.CQ Tcko 0.337 prj2_hw_test_top_i/prj_top_i/io_address<29> prj2_hw_test_top_i/prj_top_i/inst_mbcore/U0/iomodule_0/IO_Address_29 SLICE_X45Y163.D2 net (fanout=1) 0.726 prj2_hw_test_top_i/prj_top_i/io_address<29> SLICE_X45Y163.D Tilo 0.068 prj2_hw_test_top_i/prj_top_i/inst_mbcore/U0/iomodule_0/lmb_abus_Q<3> prj2_hw_test_top_i/prj_top_i/inst_mbaddr_decode/PWR_98_o_io_address[31]_equal_5_o<31>13 SLICE_X43Y156.C6 net (fanout=5) 0.570 prj2_hw_test_top_i/prj_top_i/inst_mbaddr_decode/PWR_98_o_io_address[31]_equal_5_o<31>13 SLICE_X43Y156.C Tilo 0.068 prj2_hw_test_top_i/prj_top_i/inst_mbaddr_decode/PWR_98_o_io_address[31]_equal_5_o<31>2 prj2_hw_test_top_i/prj_top_i/inst_mbaddr_decode/PWR_98_o_io_address[31]_equal_5_o<31>2 SLICE_X57Y151.C4 net (fanout=4) 0.796 prj2_hw_test_top_i/prj_top_i/inst_mbaddr_decode/PWR_98_o_io_address[31]_equal_5_o<31>2 SLICE_X57Y151.C Tilo 0.068 prj2_hw_test_top_i/prj_top_i/inst_dsp_subsystem/inst_cfr_top/inst_fir_ich/delay_line_44<11> prj2_hw_test_top_i/prj_top_i/extif_ce SLICE_X73Y76.D6 net (fanout=4) 3.186 prj2_hw_test_top_i/prj_top_i/extif_ce SLICE_X73Y76.D Tilo 0.068 prj2_hw_test_top_i/prj_top_i/inst_dsp_subsystem/inst_cal_estimate/inst_delay_estimate/inst_reorder_a_re/tmp_array_0<0> prj2_hw_test_top_i/prj_top_i/inst_external_interface/_n0434_inv11 SLICE_X75Y73.CE net (fanout=18) 0.550 prj2_hw_test_top_i/prj_top_i/inst_external_interface/_n0434_inv1 SLICE_X75Y73.CLK Tceck 0.318 prj2_hw_test_top_i/extif_reg_out_i<471> prj2_hw_test_top_i/prj_top_i/inst_external_interface/mem_data_29_7 ------------------------------------------------- --------------------------- Total 6.755ns (0.927ns logic, 5.828ns route) (13.7% logic, 86.3% route) PS Кстати, а спойлер в сообщении никак не вставить, никто не в курсе?

Есть проект под Virtex 6, не то, чтобы очень большой, порядка 50000 триггеров и лутов (около 40-50% емкости кристалла), основная частота 150 МГц. Со временем (добавление небольшого функционала) начинает все хуже и хуже разводится. Причем может один раз развестить без всяких проблем, а в другой полностью сливает по таймингам. Картина при этом удивительна. Самые критические пути выглядят как 1нс на логику и 6-7нс на рутинг, т.е. соотношение 15/85% примерно. При этом соответсвующие блоки лежат за пол-кристалла друг от друга, линии трассировки относительно прямые, так что все относительно честно. То есть явно лажает плэйсер. Основное время компиляции (2 часа из 2,5) при этом занимает процедура Map, в рамках которой у Xilinx теперь происходит и Placement. Настройки крутил всяческие, разницы особой нет (если поотключать разные оптимизации, то становится совсем плохо). Единственное, что не смог сделать - установить Global Optimization в разделе Map. В этом случае вываливаются тысячи ошибок типа "MapLib:821 - LUT6 symbol **** has an equation that uses input pin I0, which has no connected signal...." Пытался порисовать pblock-и, но стабильного результата все равно нет - что-то где-то да вылезает... В какой-то момент было ощущение, что если сделать clean project и собирать полностью с нуля, то собирается, но увы, не вышло... В общем "поговорите со мной люди" (ц), а то совсем непонятно куда двигаться.

Никто мне на форуме хилинкса не отвечает, попробую тут... Есть система на базе ядра Microblaze MCS, в нее "из коробки" встроен блок I/O Module, экспортирующий шину I/O bus (по сути axi-lite, как я понимаю). Шина эта замаплена на часть адресного пространства микроблэйза (0xc0000000 и выше). Туда приделаны пользовательские регистры. Из программы все прекрасно читается-пишется, претензий нет. Но если я пытаюсь обратиться к тем же адресам в процессе отладки (через окно Memory среды разработки) - фиг, там сплошные нули. Приделал Chipscope - транзакция туда просто не приходит. Более того, попытался посмотреть содержимое конфигурационных регистров самого I/O Module - и там нули. Это вообще как, что-то глючит или встроенный отладчик процессора имеет доступ только к оперативной памяти программы, но не к прочим адресам? Сам больше с ниосом знаком - там таких проблем не было... Ну и вопрос в воздух - какого хрена отладка постоянно отваливается, так что несколько шагов по программе делаешь и дебагер подвисает? Программа самая тупая, никаких прерываний, таймеров, только пользовательский ввод-вывод. PS Использую ISE 14.7, кристалл Virtex6.

Я бы рекомендовал копать в сторону моделирования: запустить синхронно две модели (нетлист после синтеза), сравнить результаты. Постараться локализовать различие в поведении.

Тогда (в общем случае) все должно делаться "из коробки". Параметры клоков наследуются из настроек dcm, дальше проверяются временным анализатором. Главное - не забыть про это место, когда клоки станут приходить из разных мест

Кратные - это еще не синхронные. Строгая связь между клоками есть?

Это делается прямо в ц-коде: #include <fcntl.h> ... fcntl(0,F_SETFL,O_NONBLOCK); fcntl(1,F_SETFL,O_NONBLOCK); fcntl(2,F_SETFL,O_NONBLOCK);

Присмотрелся к картинкам. reset - он у вас активным 0 сделан ведь? byteena - он вам совсем не нужен. Если уж делать, то почему он стоит раным 3? для 32-разрядной шины он должен быть тогда уж 0xf. Но лучше убрать.

Единственная здравая мысль, приходящая в голову, что если вы не хотите использовать процессор, то шина авалон вам не особо нужна и проще написать за 30 минут свой собственный spi (или взять готовый) с более простым управлением.

Как-то мутно. С одной стороны и раньше было I/O assignment analysis [before compilation], с другой стороны в особо сложных случаях эта процедура по времени работы была сравнима с рутингом.

А для Ultrascale'а генератор MIG не расширили? А то в прошлой версии там даже создавать пресеты памяти было нельзя.

1 нс проходила? Это на каком кристалле? Значит пора на 1 пс менять...