zomg

Здравствуйте! Требуется подключить микросхему статической памяти QDRII SRAM к ПЛИС Stratix-II (EP2S60F484I4). Память должна работать на частоте 240 МГц, шина данных 18-разрядная. Прочитал в Startix-II handbook (vol. 2, section II, 3 раздел), что для максимальной производительности тактовый сигнал CQ, CQ# от памяти нужно подключить к ножкам DQS, DQSn (DLL-based реализация). Проблема в том, что DQS отвечает за группу DQ ножек. Если верить таблице 3-3, ПЛИС EP2S60 в 484-м корпусе поддерживает 4 группы по x8/x9 ножек DQ. Но надо одну группу x18, потому что шина данных у памяти 18-разрядная. Как лучше поступить? Использовать две группы x8/x9, но для этого придется завести одну пару CQ, CQ# на две пары DQS, DQSn, не опасно ли это на частоте 240 МГц. Или перейти на EP2S60 в корпусе 672. В таблице 3-4 показано, что в non-DQS mode EP2S60 в 484 корпусе поддерживает три группы x16/x18. Но что такое non-DQS mode и подойдет ли он мне?

2 Shamil: а как следующая запись наложится, если я имел ввиду конвейер ?

Я так понимаю, что строб wr_stb формируется по срезу CS_n и WR_n. Тогда: 1. Строб wr_stb в качестве clock enable использовать можно. При неактивном CE триггер не перейдет в метастабильное состояние. 2. Нехороший подход 3. Делаете два регистра: по стробу wr_stb один защелкивает ADDR, другой DATA. На следующий такт в соответствии с полученным ADDR формируете строб (clock enable) на нужный регистр и записываете в него полученные DATA.

Создаете проект моделсима, подключаете в него файлы со скриптами. В списке файлов проекта выбираете нужный скрипт, правая кнопка мыши, execute.

Я имею ввиду, что длительность полупериода меандра 12,5 / 2 = 6,25 микросекунд, а Вы делаете опрос каждые 5 микросекунд. Все будет съезжать! Если меандр не привязан к клоку, то при защелкивании меандра триггером могут возникать метастабильные состояния. Я в этом не разбираюсь, но рекомендуется поставить два триггера последовательно. По поводу наводок. Возможно следует сделать подобно приемнику UART: берем несколько отсчетов и путем голосования определяем уровень сигнала. Если выяснили, что уровень изменился, значит поймали фронт или срез. Странно, такого быть не должно. :05:

Я собрал проект, действительно, триггеры на счетчик выделены. Наверное не привязан. Sprite, почему Вы так редко опрашиваете меандр - каждые 5 микросекунд. Период меандра 12,5 микросекунд. Может быть почаще надо его опрашивать, чтобы выделить фронт и срез?

Еще раз повторяю: variable не будет на выходе триггера, то есть элемента памяти. Как вы себе представляете счетчик без триггеров? По ENABLE = 0 я так понимаю будет асинхронный сброс?

Variable никогда не будут на выходе триггера, замените их на signal. Ваш счетчик i как-то умудряется считать без элементов памяти.

А если так попробовать? В данном случае размер массива можно задавать через generic. Разрядность элементов массива константа, но можно ввести новый тип с другой разрядностью элементов. Только я не проверял, работает такая штука или нет. type sig_array is array (natural range <>) of std_logic_vector(15 downto 0); entity example is generic ( NUM : natural := 128; ); port ( clk : in std_logic; rst : in std_logic; input : in sig_array(0 to NUM-1); ); end example;

Наконец-то разобрался с ошибками CRC. Оказывается причиной этих ошибок был не шум, а мои косяки в контроллере. Спасибо Eugenius за помощь! Скорость записи винта HDD выросла до 129 МБ/сек, скорость чтения такая же. Режим последовательной записи/чтения, команды DMA, 40 КБ на одну команду. SSD Crucial C300 CTFDDAC256MAG-1G1 в тех же условиях выдал 200 МБ/сек на запись и, странно, 170 МБ/сек на чтение.

vicg Вы проверяете на прошивке XAPP870? В этой прошивке все время на устройство передается R_RDY. Если устройство не отвечает кадром после установки соединения, значит, возможно, этот кадр не предусмотрен в данном HDD. :laughing: Мой HDD отвечает этой сигнатурой (правильнее сказать кадром), причем первое dword C38276B9, а в XAPP870 схитрили и написали C28276B9. Если проверить контрольную сумму CRC, то должно быть 3. То есть значение регистра ER = 0x01. После сброса или выполнения команды EXECUTE DEVICE DIAGNOSTIC регистр ER содержит диагностический код. В данном случае 0x01 говорит: Device 0 passed, Device 1 passed or not present.

Выделенные жирным цифры показывают разные вещи. После синтеза: Number of Slice LUTs: 87661 out of 150720 58% - число таблиц LUT, то есть логики Number of Slice Registers: 99196 out of 301440 32% - число D-триггеров После имплементации: Number of Slice LUTs: 76,802 out of 150,720 50% Number of Slice Registers: 99,196 out of 301,440 32% Number of occupied Slices: 28,140 out of 37,680 74% Имплементатор даже оптимизировал проект, в результате сэкономил LUTы. При имплементации LUTы раскидываются по слайсам. Один Slice в Virtex-6 содержит 4 LUT и 4 (или 6, не помню) D-триггеров. На практике трудно раскидать LUTы по слайсам компактно и тем более так, чтобы сохранить связи и выполнить временные требования.

Попробуй в Notepad++ зайти в меню Опции\Определение стилей, в панели Язык выбрать Ruby и в поле "Новое расширение" вписать ucf. Редактировать файл с констреинтами станет даже приятно.

Очень интересно, а какая у Вас получилась средняя скорость записи в одном канале? У Вас реализован режим FPDMA? Связываться с реализацией FPDMA я не стал. Пробовал несколько раз записать на HDD блок данных (счетчик) размером 10 ГБ командами DMA по 40 КБ. В процессе записи считал команды, на которые был получен ответ от устройства с ошибкой CRC. Команда с ошибкой CRC повторялась еще раз. Получил в результате, что скорость варьировалась от 60 до 75 МБ/сек, причем чем больше ошибок CRC, тем меньше скорость. Получилось в лучшем случае на каждые 3 МБ приходится одна команда с ошибкой CRC, то есть еще чаще, чем у Вас Чтение с устройства еще не проверял. Ну а причиной ошибок CRC является шум. По ALIGN: устройство может отправить его в любое время, даже может попасть в информационное поле кадра. Значит также можно поступать и с HDD. Последовательность HOLD, CONT, ALIGN в теле кадра я придумал. Не могу понять причину такого поведения: иногда после того, как соединение с устройством установлено, в ответ на все команды записи устройство отвечает ошибками CRC. Потом вообще зависнет все. Делаю сброс, после переподключения команды проходят нормально, связь стабильная по крайней мере несколько часов, больше не проверял. Удачное или неудачное соединение происходит случайно.

Простейший пример касательно ПЛИС: представьте себе дерево из трех сумматоров, где нижний сумматор складывает содержимое двух верхних сумматоров. Пускай на выходе последнего сумматора стоит регистр для запоминания значения. Дерево сумматоров - это комбинационная схема, дающая задержку. Может быть так, что при выбранной частоте тактирования, из-за задержки в комбинационной схеме, не будут выполняться время установки или время удержания для триггера. То есть задержка настолько большая, что триггер, работая на своей тактовой частоте, переключается, когда данные еще не готовы. Триггер даже может перейти в метастабильное состояние. Но в промежуток между верхними и нижним сумматорами можно добавить регистры. Комбинационная схема разбивается пополам, задержка уменьшается, следовательно, можно повысить тактовую частоту. Результат появится на такт позже, но это ерунда :) Для ПЛИС рекомендую всегда придерживаться такого принципа, потому что, если посмотреть на устройство логической ячейки в FPGA, то там каждая таблица LUT (она же комбинационный элемент) снабжается D-триггером.