Yuris

Во первых, в корегенераторе в окне генерации xilinx MIG есть кнопки User Guide и MCB User Guide, по нажатии на которую открываются ug416 и ug388. Это и есть вменяемые гайды. Для понимания работы MCB читать ug388. Во вторых, по делу, генерить можно в двух режимах - axi и без него. Если нет процессора, то лучше генерить без axi. В этом случае лепится native mig wrapper с простым внутренним интерфейсом. На этапе сборки корки нужно выбрать количество внутренних портов (максимум 6), их ширину (32/64) и направление(rd/wr). Для доступа к памяти через каждый порт интерфейса имеются: фифо команд глубиной 4 и фифо данных глубиной 64, ну и весь набор необходимых флагов. Упрощенный алгоритм записи: в фифо данных толкаются данные, потом в фифо команд толкается команда записи и их объем и мониторится флаг empty фифо данных. По необходимости повторить. Алгоритм чтения: сначала посылается команда чтения и необходимый объем, потом опять таки мониторится empty фифо данных, по готовности читаем данные из фифо. Понятное дело, для оптимизации пропускной способности требуется написать грамотный автомат управления, подобрать объем берстов и т.п. Если хочется сделать быстро welcome to EDK.

Хороший совет был посчитать Setup/Hold для начала. Использование констрейнтов OFFSET OUT и OFFSET IN (RTFM) поможет понять по отчетам какие временные соотношения клоков/данных вы реально имеете на выходах/входах данных. Может оказаться, что в выходном интерфейсе клок skew по разным битам данных достаточно большой. И входную задержку по клоку на приемной стороне придется точно рассчитывать с учетом этого валидного окна данных. Еще стоит почитать XAPP1064, там есть приложение с примерами-исходниками по использованию IDELAY, ISERDES.

Приветствую. Помимо 256-разрядного ключа требуется задавать AES Initial Vector. Тогда будет повторяемость nky. Но мы поступили иначе - при первом запуске Generate Programming File вообще не задавали ни ключа, ни вектора, позволили процессу создать nky файл, слегка модифицировали его (запараноились:) и в последующей сборке подсовывали в качестве параметра не ключ с вектором (ключи пустые), а уже готовый nky-файл. Полученный таким образом новый битстрим грузится без проблем. Не забываем установить параметр Encrypt Key Select в значение eFuse. И, да, для прошивки eFuse Impact-у требуется Platform Cable USB II. С другими не работает.

Верно только первое, работает на семерке, на скорости не больше 1,5МГц

В копилку всеобщих знаний... Не совсем для начинающих, но, внезапно выяснилось, что для доступа к регистрам eFUSE (Spartan6, Virtex6) не то, что LPT-кабель, но и фирменный Platform Cable USB (DLC9G) не подходит. Для срочного криптования FPGA пришлось в самый распоследний момент за очень неслабые деньги заказывать Platform Cable USB II (HW-USB-II-G). Вот такая хитрая преемственность продуктов Xilinx. Я уж молчу про российских диллеров-барыг, торгующих в два конца...

Апгрейд до 13.2 ничего не дал. Случай редкий, писать багрепот в xilinx, скорее всего, не буду. Workaround - запись только по тем адресам из которых будет осуществляться чтение, соответственно адрес чтения всегда занимает LSBs примитива. Тема закрыта, всем спасибо.

Ну, так и писали бы "макрос" :( зачем язык-то ломать. Это очередной workaround, имеющий одно преимущество - библиотечный примитив это практически гарантированный и 99% предсказуемый результат. Всё, закрываем тему, а то уже флейм пошел. Будет результат по сути, отпишусь.

Сленг хорош, когда собеседники в теме, не затруднит раскрыть указанный выше "термин"?

Рад бы с этим согласиться, но найдите ошибку в приведенном мной исходнике, скажите, что именно написано неправильно, и какие такие настройки оптимизации синтезатора могут ПРИНЦИПИАЛЬНО ИСПОРТИТЬ ЛОГИКУ работы кода??? И, да, для очистки совести данный код был помещен в отдельный исходник под который был создан абсолютно новый проект с абсолютно дефолтными настройками. Результат тот же.

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

Согласен, конструкция спорная, но никак не объясняет описанной ошибки. Впрочем могу ответить зачем. Для ускорения работы алгоритма, реализованы несколько однотипных вычислителей, коэффициенты для вычислителей хранятся в памяти, вычислители работают по конвееру, результат работы предыдущего вычислителя формирует адрес чтения памяти текущего вычислителя, поэтому память в каждом канале физически индивидуальная, хоть и имеет одинаковое содержимое. Кроме того, первый вычислитель считывает данные всего по двум адресам, второй по четырем, и т.д. Чтобы не заморачиваться с описанием памяти разного размера для каждого вычислителя и писать только используемый объем, была написана универсальная конструкция, с подстановкой фиксированной маски на адрес чтения. С точки зрения ресурсов утяжеления никакого нет, т.к. в любом случае используется примитив распределенной памяти целиком. В итоге получилась описанная в теме ситуация, выйти из которой удалось именно тем способом от которого изначально хотелось уйти.

Доброго времени суток всем! На днях столкнулся с весьма неприятным случаем ошибочной работы синтезатора XST. Итак, имеем небольшую распределенную память с классическим описанием на Verilog, в которой младшая часть шины адреса чтения задана константой, адрес записи - полный. В результате синтезатор XST (ISE 12.3) осуществил не совсем адекватную оптимизацию именно этой постоянной части сигналов адреса чтения, со смещением переменной части в сторону младших разрядов. Собственно, сначала, не заработало железо в этой части, потом в ход пошла тяжелая артиллерия в виде чипскопа, только после чего я удосужился посмотреть RTL schematic и FPGA editor. Теперь веселые картинки. 1. Исходный код (упростил до безобразия и вынес в отдельный файл, чтобы исключить влияние остального кода, хитрый инит, для того, чтобы посмотреть как он будет выглядеть в FPGA editor, забегая вперед, выглядит как надо, т.е. никаких внутренних адресных смещений в LUT нет, да и быть не может) module top( input clk1, input mem_we, input [3:0] mem_waddr, input [7:0] mem_wdat, input clk2, input [1:0] mem_raddr_ext, output [7:0] mem_rdat_o ); (* ram_style = "distributed" *) reg [7:0] mem [15:0]; initial begin mem[0]=8'h0; mem[1]=8'hff; mem[2]=8'hff; mem[3]=8'hff; mem[4]=8'hff; mem[5]=8'hff; mem[6]=8'hff; mem[7]=8'hff; mem[8]=8'h0; mem[9]=8'hff; mem[10]=8'hff; mem[11]=8'hff; mem[8]=8'hff; mem[13]=8'hff; mem[14]=8'hff; mem[15]=8'hff; end always @(posedge clk1) if(mem_we) begin mem[mem_waddr[3:0]] <= mem_wdat[7:0]; end wire [3:0] mem_raddr={mem_raddr_ext[1:0], 2'h2}; reg [7:0] mem_rdat=8'h0; always @(posedge clk2) mem_rdat<=mem[mem_raddr]; assign mem_rdat_o=mem_rdat; endmodule Скриншот RTL (куда подевались младшие биты на шине addrB???) Скриншот FPGA editor (опять же, где младшие биты адреса??? Верхний LUT (WR) честно использует все биты адреса, нижний (RD) только два бита внешнего адреса чтения в младшей части адреса LUT) Предвосхищая вопрос, а что будет, если константу переместить в верхнюю часть адреса, отвечу, что все будет хорошо, проверено. Ну, и собственно, вопрос, кто косячит? Я плохо знаю синтаксис Verilog и неправильно описываю distributed RAM, или, таки, XST не прав?

Solved. Надо было немножко подождать с вопросом, VladimirB, вы не ошиблись, косяк 12.2 и обещание исправить в 12.3, плюс имеется workaround. http://www.xilinx.com/support/answers/37733.htm

Спасибо. Ну, у нас не настолько все запущено, проект по логике, памяти и ДСП занимает примерно 85% lx16 и живет больше чем на 100МГц, а не работает только DCM. Но и болезней от 11.5, версия 12.2 не вылечила, так что безболезненно можно ждать новых релизов: )

Собственно произошел subj. По результатам исследования оказалось, что неожиданно "пропал" сигнал PROGDONE (всегда low после загрузки FPGA, и никакой реакции на перепрограммирование) примитива DCM_CLKGEN, при этом LOCKED поднимается в HIGH и всегда формируется дефолтная частота. Может кто сталкивался с подобным. Буду признателен за наводки. Проект сборки 11.5 был полноценно работоспособным, в том числе в части синтезатора частот, пересобирался в новой версии для учета обновлений MIG. Фрагмент кода установки примитива: DCM_CLKGEN #(.CLKFXDV_DIVIDE (2), .CLKFX_DIVIDE (2), .CLKFX_MULTIPLY (2), .SPREAD_SPECTRUM ("NONE"), .STARTUP_WAIT ("FALSE"), .CLKIN_PERIOD (18.5185), .CLKFX_MD_MAX (1.000)) dcm_clkgen_inst // Input clock (.CLKIN (clk_ibufg), // Output clocks .CLKFX (clkfx), .CLKFX180 (), .CLKFXDV (), // Ports for dynamic reconfiguration .PROGCLK (prog_clk), .PROGDATA (prog_data), .PROGEN (prog_en), .PROGDONE (prog_done), // Other control and status signals .FREEZEDCM (1'b0), .LOCKED (dcm0_locked), .STATUS (), .RST (rst_i)); P.S.: оно бы конечно у xilinx надо спрашивать, но решил начать отсюда. Xilinx Answer Record про такие случаи не знает. Errata на чип тоже.