alexadmin

Там и правда ставится 1 нс. Не потому, что хотят именно 1 нс, а потому, что 1 нс - заведомо не пройдет в современной фпга, вылезет красный слак и все всполошатся, поднимут задницу и опишут/обконстрэйнят клок-кроссинг нормально.

Это же Xilinx! :-) Все для фронта, все для победы людей.

Оно, конечно, да. Но если пол-года ищут людей на вакансию, то нужно что-то менять...

Вообще-то это стандартный шаблон квартуса. Тут у синтезатора крышу сносит, как я понимаю, на предмет многомерности массива.

А если вместо for loop сделать generate снаружи процесса?

Асинхронщина какая-нибудь. Внутри замысловато перемежаются posedge и negedge двух клоков, причем один взят с триггера-делителя... Если тайминг аналайзер говорит, что все хорошо, то можно, конечно поверить, но я бы был начеку. Или сброс асинхронный приходит откуда-нибудь из логики не подсинхронизированный к клоку.

Вот такое делал http://opencores.org/project,highload. Параметры подбирать по потребностям. Основная идея - разбить проект на много параметризированных модулей, с одним единственным гигантского размера синтезаторы плохо справляются.

По моим воспоминаниям у xilinx поведенческие модели фифо вели себя абы как - чтобы добиться похожего на правду потактного поведения приходилось генерить structutal модели.

Лучше тест запустить и секундомером померять. Ассемблерные команды не учтут задержку памяти и влияние кэша. Вообще, если кэш есть - я бы оставил первый вариант. edren_baton, поставьте аппаратный тамер и проверьте - дел на 10 минут.

Они, собственно, сами же на вопрос в доках и отвечают: не подтверждают, т.к. трансиверы как минимум не умеют spread-spectrum clock. Если пошаманить, то приемник должен уметь цепляться за такой клок, а вот выдавать такой сам передатчик не умеет. Рассказываю дальше: в самом первом сообщении писал, что у меня в упор не хочет работать IBERT на плате, хоть убейся. Добрался, наконец, до другой платы, попробовал на ней - работает. Зато мой рабочий проект работает еще хуже. [обсценная лексика пропущена]. Начинаю грешить на качество клоков, но как их вывести на чистую воду - пока непонятно.

В смысле вот это? Ага. Но на практике я такой ситуации пока не наблюдал...

Да, это есть. Увы, там по умолчанию уже стоит 1000. Пробовал увеличить - без разницы...

Плата самопадельная, что вносит некоторые опасения. Клоки идут с PLL TI CDC62005. От нее же тактируется много всего еще, в том числе Serial RapidIO 5.0Gbps на той же FPGA (и вроде работает). Да, использую встроенный FSM для сброса. Изначально рисовал на бумажке по юзергайду, хотел сделать сам - но в итоге то, что генерирует встроенный контроллер совпало с моими представлениями. Вот с терминацией вопрос хороший оказался. Я стал уже сам смотреть и выяснилось, что схему делали из общих соображений, поставив разделительные конденсаторы по 100 нФ на приемной линии. А в sata просят не более 12 нф, причем ставят с обеих сторон и на приемник и на передатчик. Сейчас коллеги думают как быть... Но у меня сомнения в том, что это корень проблемы... На счет править руками настройки визарда - пока только RXCDR_CFG, больше не накопал ничего. Остальное либо вещи функциональные, которые вроде и не надо трогать, либо настолько невнятные, что остается только 2^n комбинаций перебирать. Может порекомендуете, какого рода настройки вам пришлось править?

Буферы включены. Со сбросом вроде честно - непосредственно при работе с трансивером MMCM не используется, задействована только частота, приходящая прямо с GTX (linespeed/20, и usrclk и usrclk2 - одинаковая). Впрочем MMCM тоже ставить пробовал (естественно задействуя его lock для сброса) - без разницы.

Занимаюсь сейчас SATA на плате с Kintex7 и уперся в некоторый тупик - поведение трансивера меняется от ресета к ресету и, чаще всего, не обеспечивает нормальной работы. Сгенерирован стандартный пример на 3 ГБит/с с минимумом изменений, для процедуры сброса используется встроенный контроллер, т.е. снаружи сброс подается только сигналом soft_reset. Далее я наблюдаю происходящее после сброса, ориентируясь главным образом на признак rxnotintable, говорящий об ошибке на нижнем уровне при 10b/8b-декодировании внутри трансивера (ну и заодно rxdisperr). Я вижу что: 1. Иногда (1 случай из 20) все работает нормально, правда с периодом в минуту-пять-полчаса может проскочить одиночная ошибка (тоже ведь не нормально или как?) 2. В большинстве случаев после прохождения процедур OOB начинают сыпаться ошибки (сразу или через некоторое время). При этом alignment обычно проходит, а вот дальше уже все тухло. От случая к случаю ошибки могут вылезать или длинными периодами, или быть перманентными (например каждое четвертое принятое слово - с ошибкой). Будь это моя собственная логика, я бы списал на асинхронщину, клоки/сбросы и т.п. Ну тут все происходит внутри адской коробочки и как быть непонятно. На данный момент я успел проверит следующее: 1. Тупой тест с PRBS на базе готового примера через loopback-кабель проходит - то есть линия сама по себе целая. IBERT тест к сожалению запустить не удается. По невыясненным причинам вивада говорит, то debug-ядра внутри проекта нет (или клока нет). Хотя берется готовый пример,а клок тот же, что и в рабочем проекте. 2. Был найден AR# 53364 с указанием какие параметры задавать RX CDR для разных протоколов. Ни к каким видимым эффектам не привело. 3. Поигрался с разными режимами эквалайзера, впрочем не особо понимая их внутреннюю физику. Опять-таки видимого результата нет. 4. Естественно попробовал разные кабели и несколько жестких дисков. 5. Тайминги в проекте вроде как проходят, но даже если бы не проходили - это все снаружи, а проблемы начинаются непосредственно с приема внутри трансивера. 6. Кое где были упоминания про длительную настройку эквалайзера, которая может мешать начальной процедуре установления соединения. Возможно, но по крайней мере по ее окончании я должен получать из линии символы без ошибок - а сыпятся rxnotintable. Может кто-то боролся с похожими проблемами и может навести на след проблемы?

Могу пропиарить свой небольшой проектик, полгода назад делал с той же целью. Хотел обновление залить, но что-то у меня их сайт отваливается сейчас. http://opencores.org/project,highload,Overview

Грязный хак, не входящий в фициальные language templates, но работающий, и у Xilinx и у Altera, насколько я помню: process(clk, arst) if rising_edge(clk) then q0 <= a; q1 <= b; end if; if arst = '1' then q0 <= '0'; end if; end process; Впрочем сам так делать боюсь :)

Да, в итоге пришел примерно к тому же. Но раньше-то по крайней мере был отдельный проект Core-генератора, в котором все это и делалось, а теперь, получается, нужно хранить отдельный вивадовский проект для всех ядер. Как-то совсем задумчиво...

Вожусь сейчас с реализацией SATA для Kintex7. У Xilinx есть рекомендация AR#53364 установить для трансивера параметр RXCDR_CFG в определенное значение, отличное от дефолтного. Если я правильно уловил мысль, делать это надо руками и возник вопрос - а как же это реализуется технически? Указанный параметр назначается на самом нижнем уровне. Он есть, во первых, в одном из снегерированных vhdl файлов, относящихся к внутренностям ip-ядра, а так же в edif-нетлисте, лежащем внутри .dcp - файла (по факту - zip-архив). Возникают вопросы: 1) Откуда же, собственно, происходит сборка компонета - из vhdl или edif (dcp)? 2) Как заставить виваду пересобрать эту часть проекта (т.е. что можно из временных файлов удалить, а что оставить) 3) Как после пересборки проекта убедиться, что были использованы новые параметры? В schematic viewer я этих данных не смог найти, а логи-репорты, содержащие искомую комбинацию RXCDR_CFG относятся к моменту генерации самого ядра, а не всей сборки проекта. Может кто занимался подобной задачей? PS DRP нет и подключаться к нему весьма нетривиально в имеющемся окружении...

Настройка триггеров ILA (бывший Chipscope). Есть столбец с именем сигнала. Есть со сравниваемым значением. Тыкаешь в ячейку второго столбца - поля ввода не появляется. Вместо него вылезает маленькое окошечко. В котором задается в виде трех разных полей ввода тип сравнения (==, /=, > и т.д.), система счисления, непосредственно значение. Вроде все здорово в теории, но когда постоянно вместо одного щелчка мышью приходится делать два, да еще периодически промахиваясь - начинаешь закипать. Что мешало сделать 4 столбца как у всех нормальных людей?

Там нюанс был - инициализация. Даже не память, а просто rom. Не шмогла ;-) Core Generator, к его чести, всего минут за 50 справлялся с таким же блоком... entity conf_rom is port ( clka : in STD_LOGIC; douta : out STD_LOGIC_VECTOR ( 7 downto 0 ); addra : in STD_LOGIC_VECTOR ( 19 downto 0 ) ); end conf_rom; architecture autogen of conf_rom is type rom_type is array (0 to 949999) of std_logic_vector (7 downto 0); signal ROM : rom_type:= ( X"00", X"0c", ..... X"00", X"00", X"00", others => X"00"); begin process (clka) begin if rising_edge(clka) then douta <= ROM(to_integer(unsigned(addra))); end if; end process; end autogen;

Строчки на hdl зайлинксу вообще противопоказаны. Пробовал еще на ise делать память примерно на 1Мб (ну очень надо было, а кристалл позволял) - синтезировало больше суток, так и не закончило...

Продолжу марафон. Почему генерация какого-то жалкого блок-рама на 2048 бит из ip-компонента занимает 3 минуты?

Вы NDA подписывали? Или товарищу майору подписку давали?

По очереди. Есть арбитраж, настраивается через arbitration shares - сколько подряд транзакций может выполнить каждое устройство.