Dimidrol

Приветствую. Ответ на ваш вопрос есть по ссылке. https://www.xilinx.com/support/answers/51616.html В архиве проект сделанный в ISE. Из него должно стать все понятно, такт на процессор 125 МГц приходит с внешней MMCM. Там еще есть модуль - регистровая прослойка GMII (gmii_sync.v), без нее тоже работать не будет.

Как вариант - сохранить список сигналов в TCL скрипте (Ctrl-C - Ctlr-V) и вызывать этот скрипт в начале симуляции. А вообще, раньше был другой маршрут в Active HDL, там сигналы не сбрасывались.

Да, где ядра нет, там выставлена единица. Причем есть экземпляр с единственным выставленным битом, и это бит 7. И да, одноядерных 045 с завода не выпускают. Партии по закупке разные, не думаю что LOT ID совпадает. Но! Важная информация. Ядро само по себе не лочится. Если убрать несколько проверок в коде загрузчика и в драйверах BSP, то программа на втором ядре все-равно выполняется. Т.е. самое неприятное после выставления бита, это то, что в SDK не будет возможности отладки данного ядра, т.к. судя по всему дебагер делает собственную проверку на одноядерность, вычитывая значение вышеуказанного регистра на ходу. И как предположение, возможно таким образом можно использовать кристаллы, официально выпущенные с одним ядром, как двухядерные. Но это еще предстоит узнать.

Думаю, следует поделится некоторой информацией в продолжение данной темы. Редко, но у нас начали появляться новые платы с обрубленным вторым ядром. Повторное гугление привело на форум хилых, где у людей такая проблема также случалась. Оказывается, что ядро может пропадать, если зашить FUSE бит в регистре FUSE_CNTL под номером 7. В документации описания на этот бит нет, но на форуме упоминается. Тем на форуме много, вот одна из них. А вот далее самое интересное - по данным с сайта хилых, рандомная запись FUSE-битов может происходить из-за нарушения последовательности подачи и снятия напряжений питания, тактов и сброса POR_B. Поэтому предостерегаю и советую проверить данные в регистре 0xF800D010, и при наличии выставленных FUSE задуматься о проверке условий из AR# 65240 Но что еще более интересное, мы условия эти проверили и на первый взгляд, нарушений не выявили. Поэтому сейчас в некотором замешательстве.

attribute S: string; attribute S of clk_ad_rx : signal is "TRUE";

Может вам имеет смысл воспользоваться SoftwareSerial.h если вам последовательных портов не хватает? А 8266 не забыли, что c питанием 3.3В, может принимающее устройство 5В?

Вот это правильно. Не пойму к чему все эти рассуждения о CORDIC сейчас. Цифровое ядро ЦВС любой производительности влезает в современную ПЛИС со свистом. И тут никто не упоминал еще, что ЦАПы скоростные принимают сразу N (N>1) выборок за такт, поэтому само ядро должно уметь считать сразу N последовательных выборок, что в принципе, грубо, равносильно увеличению количества ресурсов ПЛИС в N раз. И все-равно это не является проблемой.

Можно попробовать стравнить ниже по ссылкам. Но на ПЛИС веселее LUT-based ЦВС делать, а если уж нужных ресурсов не остается, то делать CORDIC на логических ячейках. https://www.xilinx.com/support/documentation/ip_documentation/ru/dds-compiler.html https://www.xilinx.com/support/documentation/ip_documentation/ru/cordic.html

А в чем вопрос-то заключается? QPLL это, утрированно, внешняя, менее шумная замена CPLL. Поэтому CPLL в GTX отключаете, а вместо него подключаете QPLL (gtxe2_common). Если нужно разные скорости на прием и передачу, то внутри GTX настраиваете соответствующие делители, они задаются отдельно на прием и передачу. В целом, работа с QPLL ничем не отличается от работы с CPLL, кроме того, что QPLL нужно инстанцировать отдельно, ну и одной QPLL можно сразу целый QUAD запитать.

Не совсем. Если Impact и Vivado Hardware Manager использовать одновременно, то начинаются глюки с программатором. Просто не нужно запускать их вместе. В остальном все нормально.

А что скажите про GeoS-5M, хуже или лучше предложенных выше?

Закачал на FTP /upload/DOC/Medtronic/ Прошивки позже обещали подогнать.

https://vk.com/id465735632 Ярославль, оплата ИП (безнал)

Под 6 Спартан конечно нужно в ISE работать. Из Vivado ничего перенести не получится. И вам из XPS не обязательно прошивать. Скорее даже вредно.

Проще всего собрать полноценный Microblaze в Block Design. Он бдует таким же по размерам, при должных настройках. Ядро IOBus присутствует в списке и его можно подключить по шине LMB. На выходе получаем тот же микроконтроллер, только более гибко конфигурируемый.

Microblaze в ISE конфигурируется в Xilinx Platform Studio (XPS), как и всегда было. То, что вы показываете (Microblaze Microcontroller System - MCS) это обрубок Микроблейза с минимальной периферией, упакованный в IP CoreGen. Это разные сущности и необходимо их разделять.

Здравый смысл подсказывает, что MB в этой системе лишний.

https://www.mathworks.com/help/matlab/getting-started-with-matlab.html?s_tid=CRUX_lftnav Второе предложение первого абзаца.

Такой? http://dialsmt.ru/equipment/ustanovka_komponentov/avtomaticheskiy_ustanovshchik_b800_nautilus_/

О чем в общем-то спор? На YouTube есть официальный канал Xilinx. Там и можно послушать как произносится носителями это название. Забегая вперёд, скажу, что произношение ближе к Зайлинкс.

Мы пробовали. К этому ядру констрейнты не работают из коробки у нас. Приходится допиливать. В даташитах вроде описано все логично, но не работает. Я тоже с этим бился долго.

Возможно там динамическое считывание, чтобы ноги контроллера сэкономить.

Ну ахинея же. Какое дублирование? Не дублируются сдвинутые коды. Правильное выражение - 2^12*16

Что касается LFSR, он просто по совоей природе "сдвигового регистра" генерирует последовательности де Брёйна. Я вам предложил лишь частный способ нахождения расположения отверстий, по которым может работать такой экодер. Какая именно последовательность применена на вашей ленте узнать не представляется возможным, хотя бы потому, что нужно увидеть все дырки, а не только часть. В статье упоминается формула для расчета теоретически возможного количества уникальных последовательностей, там получаются очень большие числа! Естественно они не все могут быть сгенерированы LFSR, это я уже увидел, проверяя другие последовательности, которые были выложены здесь. Вероятно, табличный способ определения смещения энкодера тут самый простой, но с LFSR можно и перебором, если скорость не важна сильно.

Вы как раз в этом моменте не разобрались. Я не предлагаю использовать уменьшенное количество оптопар. Я предлагаю всего лишь метод генерировать последовательность дырок на ленте, которая удовлетворяет условию уникальности кода при сдвиге окна на один бит. Количество оптопар равняется длине регистра сдвига. Размер последовательности таких кодов является максимально возможным, и перекрывает все двоичные коды для каждого конкретного размера окна (кроме ноля). Но это частный случай, всего лишь. В общем случае, по-научному называются такие последовательности - последовательности де Брёйна. https://ru.wikipedia.org/wiki/Последовательность_де_Брёйна