Перейти к содержанию
Поиск
    

SergeyF

Свой
 Профиль  Обзор контента

  • Постов

    345

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные SergeyF

  1. Опубликовано · Пожаловаться

    Спасибо!

    Добавлю к маршруту, что:

    1. Отдельно пришлось добавить присутствующую в списке libpng12-0:i386 - https://packages.ubuntu.com/xenial/i386/libpng12-0/download (для 64 разрядов ее приходится добавлять при установке Quartus - https://packages.ubuntu.com/xenial/amd64/libpng12-0/download).

    2. Проверка версии ядра в скрипте запуска modelsim/ase/vsim дает путь к неправильной папке, надо написать vco="linux" ;; вместо vco="linux_rh60" ;;

    Это Mint 19.1 (Ubuntu 18.04 LTS)

  2. Опубликовано · Пожаловаться

    Выкладываю проект, может кто глянет, а то я прям в замешательствеtem.zip. Рукописный кусок только заготовка, решил сразу попробовать прикрепит к QSYS, проверить что ошибок нет, а ошибки появились.

    Что-то Вы намудрили с обращением к регистру и разрядностями почти всего. Если хотите разрядность шины модуля 8 бит, то BE не нужны.

    А лучше сделайте разрядность интерфейса модуля 32, отдельные байты выбирайте BE, учтите, что avalon сама базовую часть адреса вычитает и выставляет адрес в разрядности интерфейса. Пример на базе Вашего компонента прикрепил, у меня ошибок при компиляции нет.

    tem.zip

  3. Опубликовано · Пожаловаться

    Проверка показала, что данные в DDR3 бьются по черному. Проблема оказалась в констрейнах. ISE втихоря игнорировал констрейн на глобальный клок системы. После того как констрейн подтянулся - полтергейст сразу пропал.

    У меня сейчас работает, но можно немного подробнее рассказать о том, как "констрейн подтянулся" и в чем проявлялось игнорирование констрейна, как это стало понятно? Так как, видимо, причина действительно в этом - у меня стоит SDR и, похоже, глючило от него. Полечилось экспериментами с разными сочетаниями настроек контроллера памяти и калибровкой.

  4. Опубликовано · Пожаловаться

    Не совсем понятно, какая конкретно ошибка возникает.

     

    Я делаю все нужные для периферийных модулей системы на кристалле ядра coregenом в одном проекте .cgp. Размещаю его в отдельной папке в pcores. Мне так удобнее, так как эти модули используются сразу несколькими периферийными модулями. Естественно, с путями все прописываю в .pao модулей. При этом EDK компилирует модуль нормально (generate netlist).

     

    Для нормальной сборки в ISE в Translate Properties в macro search path указываю

    C:/Xilinx/Projects/test_pcores_module_loop/system/implementation|C:/Xilinx/Projects/test_pcores_module_loop/system/pcores/coregen

    чтобы находились ngc файлы для сгенерированных coregen модулей. Это в версии 12.2.

     

  5. Опубликовано · Пожаловаться

    Возникло у Вас прерывание от контроллера Ethernet lxt971a, пошли в прерывание, а затем возникло от таймера. Куда идти надо? Стек заполняется ожидающими прерываниями, далее переполнение со всеми вытекающими отсюда последствиями. Таймер же у Вас не минутный, чтобы успеть все прошагать? Я как-то так представляю.

    А причем тут стек? Пусть таймер 10000 раз прокрутится и выставит запрос. Контроллер прерываний его обработает и выставит запрос на вход прерывания процессора. Он всего один (одноразрядный). Не буферируется. Просто внешние прерывания пропадают, так как ядро стоит. Я выполняю инструкцию - попадаю в обработчик прерывания. И пусть буфер контроллера Ethernet выставит тоже запрос - если я занимаюсь single-stepping, то это моя проблема - обеспечить, чтобы у него не переполнился буфер. Значит организую поток данных так, чтобы пакеты посылались "дозированно" или вообще выдерну разъем. А даже если я собью работу контроллера Ethernet, ядро все равно не должно перескакивать на неправильную инструкцию.

     

  6. Опубликовано · Пожаловаться

    Немного не понятен ход отладки.

    Я генерирую один раз аппаратную прошивку (somename.bit) и это долго. Далее с помощью SDK заливаю в FPGA. Софт из SDK заливается напрямую в FPGA. Если вы меняете каждый раз аппаратную конфигурацию, то отлаживаться на измененной платформе и с непрерывно меняющейся программой, IMHO, невозможно, так как нет постоянной составляющей в отладке.

    Я представил себе маршрут с созданием простенькой системы, тестированием, потом включением кэшей, тестированием, потом дополнением SDRAM, включением XCL, дополнением модулями-источниками прерываний, и все это тоже постепенно.

     

    Без оптимизации не работает, после оптимизации код стал меньше и быстрее и заработал. Делаем вывод о времени выполнения.

    Хорошо бы, да я рано радовался - оно все равно заглючило.

     

    Отлаживаться пошагово при работающих прерываниях, на мой взгляд, дело неэффективное или безнадёжное. Каждая команда сопровождается trap instruction и все времена нарушены. Запросто в исключение можно попасть (бывало такое).

    Во всех нормальных эмуляторах, с которыми я работал, при возникновении активного запроса прерывания вылетаешь прямо в пошаге в обработчик прерывания, если источник активизируется... :( Это же не монитор, а встроенный в ядро внутрисхемный эмулятор. Если внешний компонент на шине (тот же таймер, который считает и не знает, что там с процессором) выставил запрос прерывания, ядро должно запустить на выполнение обработчик. Я не прав?

  7. Опубликовано · Пожаловаться

    Как вы решили эту проблему? Где храните эти значения?

    А чем не устраивает вариант с реализацией на 16 параллельно работающих умножителях? Так как умножаем на константу (alpha^i в каждом модуле), они будут весьма компактны. В статье Hahno Lee на стр. 289 формула (3) раскладывается по схеме Горнера и становится понятно, как получается модуль расчета синдрома на рис. 3а на стр. 290.

  8. Опубликовано · Пожаловаться

    Странно мне сие.

    Куда там девать 2 дня?

    У меня от нажатия generate netlist до получения прошивки проходит 30 минут. Плюс прогнать софт на разных уровнях оптимизации и разных кусках кода, так как я не понимаю, где проблема и могу пропустить. Итого - час на итерацию в одной конфигурации аппаратуры минимум.

  9. Опубликовано · Пожаловаться

    Собрать систему, добавляя по кусочкам с нуля и найти баг, с учетом времени компиляции... это мне два дня надо убить. Если ничего не поможет, видимо, придется сделать так.

     

    Sergey'F, у Вас прерывания используются? У меня что-то похожее было при наличии работающих прерываний . А времени на выполнение прерываний хватает?

    Да, используются. В порядке снижения приоритета: таймер, контроллер Ethernet lxt971a, debug unit, параллельный порт.

    По моим прикидкам и исходя из того, что при run работает, должно времени на обработку прерываний хватать. Посмотрю повнимательнее. А как это может влиять?

     

    Выяснил вот еще: это было при отключенной оптимизации -o0. Включил -o2 - заработало. У человека рядом в другом коде, в другом цикле аналогично было. Но меня это не радует.

  10. Опубликовано · Пожаловаться

    Постоянно сталкиваюсь с проблемой при отладке софта через меню Debug под Microblaze через Platform Cable USB. Версия - ISE и EDK 12.2 с патчами.

     

    Вариантов поведения по сути два. Первый - неправильное исполнение кода (пример ниже). Второй - вылет с нормальной инструкции в обработчик исключения неверной инструкции. Проблемы возникают как в пошаге, так и при запуске на исполнение до точки останова.

     

    По неправильному исполнению кода наиболее наглядно - простой цикл. 

    int i;
int *p;
int data[4];
...
for (i=0; i<4; i++) p[i]=data[i];
...

    При запуске в режиме отладки не изменяется счетчик цикла, причем при прохождении в пошаге по окну дизассемблера прыгает в начало цикла с инструкции сохранения.

     

    Пробовал разные аппаратные конфигурации - отключал в ядре Writeback в кэше данных, играл другими параметрами.

    Играл с софтом - включал и не включал кеш - эффект один. Стека простейшей программе хватает. Прогнал тест внешней памяти - проходит. Размещал программу и во внешней, и во внутренней памяти - то же.

    И по быстродействию вроде бы проходит (смотрел отчет), хоть я и не спец в констрейнах Xilinx.

     

    Запускаю неконтролируемое отладчиком исполнение через Run - система работает нормально.

     

    Нет ли идей, в какую сторону копать, что у Xilinx почитать? Может, приоритеты прерываний как-то надо поставить правильно, XCL на SDRAM отключить и все пустить через один канал, или с кэшем еще как-то поколдовать?

  11. Опубликовано · Пожаловаться

    Мне кажется, что стоит рассмотреть работу EMIF в синхронном режиме и регистр на выходе этого дерева мультиплексоров. Все входные сигналы EMIF тоже синхронизировать. Задержка чтения получится 2 такта.

     

    После этого будет проблема с OE, он медленно идет от TMS, потом через ПЛИС и до буферов. Можно в таком случае попробовать его не использовать, а эмулировать внутри ПЛИС из чипселекта и сигнала чтения/записи.

     

     

  12. Опубликовано · Пожаловаться

    тогда тем более, смотрим Step Ibm.1 требуется t умножений для дельта, шаг Step Ibm.2 2*t умножений на локатор и так для t локаторов. По моим расчетам двумя умножителями, на все, за 2*t тактов не обойтись. Я что то упускаю ?

    Конечно, умножителей там во всем решателе БМ больше. В таблице 1 внизу приведено. Я сделал все почти как в fig.1-fig.3, но ввел дополнительный регистр на выходе дерева сложений перед модулем Control (fig.2) и сделал модуль PE (fig.3) на одном умножителе и большем количестве мультиплексоров, чтобы работал за два такта. За счет этого, если посмотреть таблицу 1 на странице 650, у меня получилось 2t+2 умножителей и больше мультиплексоров, чем в iBM(Blahut), меньший критический путь, но 6t тактов на решение. Я не говорю, что сделал лучше - просто нашел некоторую устраивавшую меня точку по объему, частоте и времени решения.

  14. Опубликовано · Пожаловаться

    хммм, что бы за 2t операций найти локатор, нужно t умножителей. полином значений это результат перемножения полинома локаторов и синдромов. Зачем нужно 16 тактов ? вы делаете это на отдельном умножителе ?

    Я делал по статье

    Dilip V. Sarwate, Naresh R. Shanbhag "High-Speed Architectures for Reed–Solomon Decoders" IEEE TRANSACTIONS ON VLSI, VOL. 9, NO. 5, OCTOBER 2001

    и другим, на которую в этой работе ссылаются.

     

    Использовал базовый iBM. В нем сначала считаются локаторы lambda за 2t итераций, а потом ошибки omega за t итераций. На итерациях расчета локаторов (2t итераций) рассчитывается lamba(r + 1) = gamma® *lambda®-delta®*beta® для каждого локатора lambda. Что требует двух умножителей.

     

    Так как мне не нужно было спешить, я разложил итерацию на два такта для использования одного умножителя в модуле, который в той статье называется PE. Теперь думаю, почему 48, а не 40 - будет время, подниму проект. Получилось быстрее последовательного Евклида, но медленнее любой из приведенных в статье реализаций БМ. Но зато и по объему что-то среднее между Евклидом и их реализациями БМ. :)

     

  15. Опубликовано · Пожаловаться

    Берусь предположить, что число тактов равно 2t, где t число исправляемых ошибок, если использовался модифицированный, безинверсный БМА (RiBM)

    Не совсем. Я его разложил по тактам для уменьшения числа умножителей, поэтому 48 тактов для t=8. 2t=16, сначала первый этап решения (нахождение локаторов) 32 такта, потом второй этап - нахождение значений ошибок 16 тактов.

  16. Опубликовано · Пожаловаться

    хмм, вроде в этой реализации это есть. Укороченные коды реализованы красиво, но ценой задержки на блок (реверсивный поиск ченя) )))

    В той версии, что я декриптовал и с которой экспериментировал, если подавались сначала меньший кадр укороченного кода, потом больший кадр, ему требовался перерыв после большего кадра величиной в разность кадров (декодер выставляет флаг занятости и не принимает входные данные).

     

    У меня можно слать непрерывным потоком блоки длины от 65(можно подкрутить и меньше, до 48, но смысла нет) до 255, причем задержка меньше, чем у Альтеры - первый символ блока появляется на выходе через 54 такта после того, как принят последний его символ на входе. Можно сделать и меньшую латентность - но балансируя между быстродействием, латентностью и объемом ресурсов я сделал реализацию БМ за 48 тактов.

  17. Опубликовано · Пожаловаться

    неее, верхний это еще цветочки. а вот auk_rs_mem_atl это жесть или auk_rs_bms_atl особенно секция

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

     

  18. Опубликовано · Пожаловаться

    Писали его задней ногой блин !!!!

    Именно так. :) Когда я прочитал их верхний уровень (все модули уже были сделаны и отлажены) - реально расстроился, подумал, что не успею сделать. Потом плюнул и сделал свой с нуля за день.

  20. Опубликовано · Пожаловаться

    Verilog,verilog....

    У меня вот студент ввёл в модуль новую переменную,а объявить её забыл.Потом целый день искал почему модуль перестал работать. ISE даже не ругнулся. На VHDL такие номера не проходят.

    Это потому что студенты Warning не любят читать. Их только Error останавливает. :) Молодые, горячие - что делать. :)

  21. Опубликовано · Пожаловаться

    Клоки у Вас получились такие, как Вы написали. :)

    Почитайте вот это про ddr: http://www.altera.com/literature/an/an433.pdf.

    Мне кажется, что лучше написать как там - отдельно для переднего и заднего фронта. А то мне как-то Ваши +6.2...-6.2 не нравятся. Глубже вникать сейчас, к сожалению, времени нет.

     

  25. Опубликовано · Пожаловаться

    Он синхронный и тактируется дифф. клоком. Но сама микросхема через I2C позволяет выбирать фазу клока для защелкивания данных

    с шагом период/16 (9.3/16=0.58 нс.). Мой модуль работает на 216Мгц, вместе с данными от меня идут 2 клока в противофазе с частотой 108МГц каждый. Чтобы не

    загружать PLL (по ним уже дифицит) я решил все включая клоки сделать как одну большую шину с выровненными задержками.

    Соответственно меня устраивает skew<(4.6нс-1.2нс), 4.6 - период 216МГц, 1.2нс - запас в 2 шага выбора фазы.

    Итого 3.4 нс.

    Бегло проглядел даташит. У Вас режим 2x pixel rate? Т.е. защелкивание данных идет по положительным фронтам?

    А как Вы делаете выходной ТИ 108МГц? Делите на триггере 216МГц? Можно, конечно, но тогда триггер, формирующий частоту, тоже надо разместить в ЭВВ (Квартус справится).

    Но у Cyclone III 2-4 ФАПЧ, и у каждого 5 выходов. Неужели у ФАПЧ, который формирует частоту 216МГц, нет ни одного свободного выхода? Сконфигурировать этот выход на 108МГц и вытащить наружу. Фазу подвинуть как надо. Можно даже 2 выхода ФАПЧ задействовать на 108МГц - один будет синфазным 216МГц и защелкивать на 108МГц данные изнутри в ЭВВ, а второй будет сдвинут относительно него на сколько надо и выходить наружу.

    В Вашем интерфейсе период 9.3, сетап и холд у микросхемы по 0.5 нс. IMHO, можно все вытянуть с окном в 8.3 нс. Настройки требований прописать в Таймквест (с такой задачей справится даже Classic TA с параметрами Output Maximum Delay и Output Minimum Delay). Если Вы читали блог des00, то такой сложности задача для синхронных интерфейсов там была рассмотрена.

×
×
  • Создать...