Gothard

В обсчем паника отменяется :) Посыпаю свою голову пеплом.... U-boot при операциях с сетевым интерфейсом производит полную его реинициализацию, и включая настройку того самого регистра sclr.GEM0_RXCLK_CTRL. При этом значение использовать MIO или EMIO определяется из board.c при вызове zynq_gem_initialize. А board.c был на базе стандартного, который шел под Xilinx ZC702, вот он и указывал, что надо использовать MIO....А регистр sclr.GEM0_RXCLK_CTRL я проверял по началу лишь до того, как U-boot чего-то сделал с интерфейсом, и на тот момент там все было правильно (спасибо FSBL не подвел). Не ожидал от него такой подставы... Теперь все ОК, топик видимо можно закрывать

Проверяю регистры процессорной части. Судя по дампу регистров MAC в него не приходило ни байта :(, что в общем не удивительно. Из документации не нашел через какой регистр определяется к чему подключен MAC - к MIO или EMIO В TRM есть пол странички по настройке GMII через EMIO - в этой полстраничке описана настройка LevelShifters и Software reset. Настройка LevelShifterов вроде бы выполнена, судя по значениям регистра. Единственное не очень мне понятный момент - в качестве Software reset там дергается FPGA_RST (то, что выводится из PS в PL в качестве пинов FCLK_RSTN[..]). Есть подозрение, что это необходимо только для корки LogiCore GMII-to-RGMII. Пока не знаю, выполняет ли это действие FSBL и насколько это критично, буду искать дальше... P.S.: Нашел, что slcr.GEM0_RCLK_CTRL выбирает не только источник синхросигнала RX, но и заодно управления и данных (тем же самым битом)... и настроен он правильно (0x11). slcr.GEM0_CLK_CTRL настроен на прием опорной частоты из EMIO, не понял только через что она туда заходит? такой ножки вроде бы не было выведено...загадка :excl: Попробовал включить loopback в gem0.netctrl - в результате пинги на себя самого прошли! (это из U-Boot), т.е. все остальное-то получается правильно настроено? Статистика по принятым пакетам/байтам адекватно отразилась. Попробовал разрешить прием пакетов с неправильной преамбулой, с плохим FCS, игнорировать RX_ER, одновременный прием и передачу в полудуплексе - в общем все, что можно было сделать, чтобы пакеты так прошли, но результата - 0... В общем теряюсь в догадках, что не так.... пошел собирать поток с loopback в плисовой части... P.P.S: С loopback в плисовой части не заработало :( Решил поменять местами ER и DV - тоже не помогло... (а вдруг Xilinx чего напутали).... Соединения проверял по схеме после раскладки потока - все подключено куда нужно... От безысходности пробую собрать поток в 2014.1, потом может и 2013.3 попробую...

Всем доброго времени суток! Пытаюсь пробросить один из Ethernet интерфейсов Zynq через PL(EMIO) на PHY (88E1512). Т.е. PHY подключен к плисовой части Zynqа, необходимо чтобы он был доступен через MAC процессорной части. Добился некоторого успеха - PHY управляется по MIIM, пакеты выдаются в сеть через PHY (на текущий момент только ARP...). Пакеты из сети в плисовую часть попадают, но такое ощущение, что в процессорную не попадают или где-то прибиваются. Наблюдаю чипскопом сигналы, которые подключены к RX процессорной части - все ок, пакеты есть, содержимое совпадает с тем, что вижу в WireShark, вот только что CRC пока не проверял. Еще немного подробностей - линк гигабитный, уже дошел до того, что пересинхронизую пакеты от PHY на внутренние 125 МГц, сформированные в плисе, те же, что используются и для выдачи TX - ситуация не меняется. Видимо не хватает какой-то магии. Плис грузится из FSBL, проверяю из U-Bootа пингами. Проект плиса в Vivado 2014.2 FSBL собирался из SDK 2013.3 по данным из Vivado (может тут нестыковочка?... но рабочий FSBL в 2014.2 у меня так и не собрался пока) Интерфейс с PHY - RGMII, используется блок, проверенный в других проектах. Буду очень благодарен за советы. Спасибо! p.s. на сигнал RX_ERR в GMII интерфейсе процессорной подается 0, но я так понимаю что с этим все должно быть ОК p.s.2: пытался в Block Design подключить IP_CORE "GMII_to_RGMII" от LogiCore к Zynq_Processing_System, он вроде бы как раз для этих целей, но Vivado выдает ошибку при генерации обертки для Block Design, поэтому не удалось проверить в такой конфигурации. p.s.3: на этой же плате есть второй PHY, который напрямую подключен к Zynq. Так вот с ним все замечательно работает. Ожидал, что в проекте Vivado переключу тот же самый MAC с внешнего PHY на EMIO, и будет достаточно только пересобрать FSBL, не меняя U-Boot (ну и плисовую часть собрать соответственно). Видимо не все так просто...

В итоге с собранным из SDK 2013.3 FSBL процессор загрузился, Hello World заработал, так что видимо с этим вопрос к Xilinxу Импортировал hardware platform, bsp и fsbl в SDK 2014.2, пересобрал, тоже все ок Правда тесты памяти получается только через JTAG запускать, из образа не стартуют, что из 2013.3, что из 2014.2.... Спасибо за советы, буду дальше двигаться. Ключики и правда не включал, включу - посмотрю что происходит. Возможно и правда дело с FATFS.

Всем доброго дня! Запускаю Zynq на плате собственной разработки, посему потребовалось собрать свой First Stage Boot Loader. Для начала решил все опробовать на пробной плате ZC702, потому что со своей платой пока что в принципе на работали, только начался процесс освоения. Вроде бы все делаю по манам / туториалам, однако цинк не стартует с собранным в SDK Boot Loaderом. Пока не понятно, что там конкретно, но в UART ничего не сыпется. Собственно как-то это немного оказалось неожиданно , что из родного инструментария, с "вшитой" поддержкой этой платы, не получилось ее запустить. Пробовал собирать в SDK 2014.2 и 2014.1, скоро попробую на более ранних версиях. Делаю так: Создаю новый Aplication Project в SDK, в качестве Hardware Platform указываю пробную плату (ZC702_hw_platform), сам проект создаю по шаблону FSBL. В результате создается BSP под платочку и проект самого FSBL, все собирается, получается ELF с загрузчиком. Никаких "особых" настроек, подстроек при создании не делаю, т.к. по моему разумению все, что нужно настроить, должно настроиться при выборе платы в качестве Hardware Platform. Собственно в манах больших манипуляций я и не заметил. Создаю образ, указываю собранный ELF в качестве bootloader, переношу образ (.bin) на SD карточку, включаю плату и ничего в консоль не вываливается... При этом, там же в SDK создаю из шаблона "Hello World", собираю образ из штатного FSBL, шедшего с платой и собранным "Hello World", и все работает - в консоли сообщения загрузчика, Hello, т.е. к сборке вроде бы претензий нет. Когда собираю образ из своего FSBL и этого же "Hello World" - молчок. Нашел/скачал пару примеров BSP и FSBL под эту же плату, для сравнения, но пока что с ними проблемы из-за версий SDK...качаю старенькие... Подскажите пожалуйста, куда можно посмотреть, что подкрутить? Может у кого-то были такие же проблемы? Поиском по форуму подобных тем не попалось, может это только я что-то не так делаю? Вот еще информация: опробовал XMD консоль, причем сразу на боевой плате. Проинициализировал систему с помощью ps7_init.tcl, собранным системой под мою плату, загрузил, собранный под нее же "Hello World" ELF, запустил, в консоль вывелось Hello World - делаю вывод, что процессорная система настроена правильно (во всяком случае для того, чтобы выводить в консоль :) ). Собрал образ, c FSBL под эту плату и Hello World (mcs), прошил QSPI флешку, все удалось. Однако при включении в консоли опять молчок (процессор настроен на загрузку с QSPI). Явно проблема со сборкой FSBL....

Вот, чего нашлось в гугле на скорую руку: http://www.sintecs.eu/download/thevenin_termination.pdf

В случае, если схема детерминированная, как у автора (во всяком случае сдвиговый регистр - точно), то результаты оценки на основании toggle-rate и моделирования должны практически совпадать, а измеренные результаты должны быть близки к этим значениям, но не превышать их IMHO. В случае согласования по схеме Тевенина все тоже детерминировано, вот только тонкости реализации ее в ППВМ могут как-то повлиять, но программа оценки как раз и должна эти тонкости учитывать. Поэтому и возникает недоумение, когда измеряешь схему, а она потребляет в два раза больше оценки. Либо есть что-то, про что не сказали, что это что-то нужно учесть, но откуда тогда это узнать? 2 Чиповод: В Xilinx XPE User Guide про toggle-rate написано вот что: Т.е. для вашей схемы как раз нужно 100% указывать, т.к. триггера у вас переключаются каждый такт, а при оценке вы использовали 50%. Если учесть, что вы упомянули, что при toggle-rate 100% XPE давал результат на 50% выше замеренного, то по этому пункту подозрения в занижении с Xilinx XPE можно снять, а вот схему Тевенина прощать рано :).

130Т с планкой памяти, не ахти какой логикой и парочкой сердесов. Там кстати уже заметно проявляется не динамическое потребление, а статическое. Хотя на толстых Virtex-5 (240) с этим даже хуже... На логике получилось всего порядка 20% от всей мощи. На статике 34%, остальное на интерфейсах (40%) и serdes(7%) P.S. это в XPE при настройке Tech Process = Maximum, Speedgrade - 2, температура - 50С (если вдруг вопросы) P.P.S. подредактировал цифры

Тоже измерял недавно потребляемую мощность и заметил отличие от расчетного значения в плане потребления интерфейсами ППВМ - в проекте используется память DDR2, ППВМ Virtex-5. Сигналы данных согласуются в ППВМ по схеме Тевенина (Vcc-[R=2Z]-DQ-[R=2Z]-Gnd), что вызывает определенный жор (стандарт сигналов - SSTL_II_T_DCI 1.8V). По расчету такое согласование на 64-х цепях должно потреблять 1Вт, с чем в общем и согласен XPE. Была возможность мерить потребление по питанию +3,3В, из которого потом получались +1,8В, требуемые для интерфейса. Так вот, при отключении согласования на 56ти цепях потребляемая мощность изменилась примерно на 1,8Вт (уже с учетом КПД DC/DC). Если интерполировать на все 64 цепи - получается согласование жрет 2Вт, что в ДВА раза больше. Откуда - пока что так и не понял. P.S. отключал согласование меняя стандарт сигналов в UCF файле и нарочно отключил только 56 из 64 (7 в каждом байте), чтобы дополнительно ничего случайно не отключилось Зато подтыкиванием резистора к цепи данных определил, что номиналы резисторов в схеме Тевенина около 150Ом, вместо ожидаемых 100 . Во всяком случае если судить по изменению напряжения на цепи при подтыкивании резистора. Но поскольку там не чистые резисторы а явно эквивалент с помощью транзисторов, то может быть, что это нормально. Но если все же там 150, то мощности жрать должно вообще около 0,65Вт. Такая вот история, пока еще не завершенная... Теперь вот думаю про Virtex-6 - у меня по расчету на ППВМ под 10Вт выходит....сколько в реальности ожидать-то?

угу

Если что - у того же robitonа есть трансформаторы 220 в 110 http://www.robiton.ru/catalog/index5.php Самый простой за 300р можно купить. Вам его точно хватит.

Касательно самого вопроса - операторы в функции выполняются последовательно. Но какая реализация в железе получится - зависит от того, что там внутри функции написано. Если в общем случае - то что-то распараллелится, что-то будет последовательным. Я так понял вы хотите последовательно посчитать CRC? Вот вариант: инициализируете регистр аккумулятора первым словом, далее - либо суммируйте на каждом такте по-словно, + в конце подсчета два такта на суммирование переносов (после первого суммирования переносов может возникнуть еще один перенос) - суммируйте на каждом такте очередное слово + перенос (1бит) прошлой операции, на последнем такте только один перенос Для первого варианта проще всего взять в аккумуляторе регистр разрядности большей чем размер самих слов, чтобы в "верхней" части (т.е. той, что за границами разрядности слова) накопилось число переносов, а в конце эту "верхнюю" часть добавить к "нижней" (при этом не забывая перед суммированием обнулить "верхнюю" часть)

У Victor® Речь была о внешнем сбросе - так, что здесь не противоречу, а вот в своем посте я действительно согрешил, каюсь: если асинхронный сброс формируется внутри схемы, то да - дальше одного триггера его лучше не пускать - поймать на следующем по клоку, и передать еще через один чтобы вероятность метастабильности поубавить (но вообще - что дальше делать -уже зависит от задачи). P.S. Основная идея поста - обратить внимание тех, кто еще не заметил какую яму себе роет. Может быть будет меньше постов на тему "почему у меня раз в час/сутки/неделю схема глючит". P.P.S. видимо опять напортачил. Действительно - для асинхронного сброса лучше просто всегда держать в голове

Согласен, ваш пример лучше :). Кстати при переносе сигналов между доменами синхронизации "ход мысли" почти такой. p.s. извиняюсь - не то процитировал... поправил

Смотря какие доки: если FPGA - то после включения возможно, что и 0, но после конфигурации там будет то, что вы укажите. Не очень понял, какая связь?