myq

Коллеги, пост был в феврале 2018 ) Вакансия уже не актуальна.

Привет! Не совсем понял разницу между п.2 и п.3. Я делал так: Большой модуль, который занимает несколько SLR - не привязан ни к чему. В нём заведены некие партишены, которые я точно знаю, в какой SLR их положить. Для этих партишенов заведены pblock'и размером с SLR. В большом модуле между партишенами используются SLR Crossing Register Slices для AXIS-интерфейсов, и самописные модули slr_cross для forward-only интерфейсов. На сегодняшний день оптимальный переход между SLR'ами - это 4 триггера: обычный -> Laguna_TX -> Laguna_RX-> обычный.

В команду очень не хватает FPGA/ASIC RTL-инженеров. Проект новый, legacy кода нет. Необходимо знать максимально из списка: Verilog/SV (VHDL тоже пойдёт, если готовы быстро переучиться) AXI4-Stream / Avalon-ST AXI3/AXI4/whatever DDR IP Core (Xilinx MIG) PCIe Endpoint Stream data processing Используем Git, Confluence, Jira. Синтез - Vivado. Симулятор - по желанию. Можно брать модуль и разрабатывать его как black-box, можно тесно взаимодействовать. Можно tb писать, можно не писать - напишут другие. Нам требуется максимальная утилизация FPGA. Максимальные частоты, максимально памяти, вычислений, DDR и PCIe bandwidth. Если вы - ASIC RTL-инженер, вы тоже подходите. Вы можете взять часть работы, которая не зависит от платформы (fpga vendor/asic), а через некоторое время появятся задачи для ASIC Design Engineer. У нас отличный офис, топовые development kits (Virtex Ultrascale+, Zynq MPSoC). Работа в офисе - да. Место - Москва, Волгоградский пр-т, около м. Текстильщики. Возможность удалёнки - сейчас уточняется. ДМС, чай/кофе - да. Печенек нет - вредно. Если вы - мидл/профи - вы нам подходите, найдём подходящую часть задачи. Если вы - джуниор, который желает быстро и многому научиться - тоже найдём задачи. Зарплатная вилка официально не объявлена, любая разумная цифра - обсуждаема. mike-fpga@ яндекс.ру

Выглядит, вроде, нормально. Тут каждая функция необратима. Только нет смысла усложнять. Просто SHA m раз. m равно общему числу хэширований в вашей схеме, примерно n*n / 2 (арифм. прогрессия).

Да, была такая проблема, решил оставить на потом. Хорошее решение!

Задача по большей части решилась, при условии, что в домене удвоенной частоты писать не if (clk), а if (tff) а tff - переключается каждый такт по удвоенной частоте. т.е. tff равен либо clk либо ~clk, но это обычный триггер, а не клок. Проект собрался с clk_x2 = 714 MHz на Ultrascale+ (период 1.4ns). Без Post-route PhysOpt - -0.02ns, PhysOpt вывел слаки в плюс.

Добрый день, коллеги. Основная логика работает на базовой частоте, а небольшая выделенная часть, например, BlockRAM - на удвоенной или утроенной. Как это лучше реализовать, если учесть, что [высокая] частота BRAM близка к максимальной для данного ПЛИСа. Про идею можно почитать тут: https://cpufpga.files.wordpress.com/2016/04...s_isca_2016.pdf слайд 74 https://www.xilinx.com/support/answers/68595.html http://citeseerx.ist.psu.edu/viewdoc/downl...p1&type=pdf Вопросы/требования: 1) оба клока (clk, clk_x2) должны быть выходами PLL или необязательно? 2) надо обойтись без синхронизаторов и async fifo 3) надо ли дополнительно констрейнить или САПР сам правильно всё понимает? По клокам, я предполагаю, что снаружи надо генерить более высокую частоту с низким джиттером (т.е. clk_xN), а внутри - делить её уже на N. Как достоверно определять 1-й такт из N? always @ (posedge clk_xN) begin if (clk) blablabla; end - выглядит не очень, и тут надо знать точно как соотносятся моменты перепада clk и clk_xN.

https://s24.postimg.org/a1pa8bo51/vivado_bu...39-50_small.png

Подтверждаю. Не цепляет опции "-generic" в Runs, не видит некоторые корки (некоторые - видит). У меня -generic и -verilog_define задают опции сборки. Например пишет: IP-ядро такое-то не найдено. На самом деле в проеке оно есть, САПР считает, что оно в проект не входит (т.к. это определяется -generic и -verilog_define, а он их игнорирует). Простой какой-нибудь счётчик V2017.1 собрать может. Мой проект - нет.

Коллеги, а у вас нет проблем с лицензией?

Проблема уже не важна, но комментарии ценны. )

Так я же в начале написал, что у меня была долгая дискуссия с одним рук-лем проекта, по asic'ам. И он утверждал, что async dcfifo - штука в asic'е ненадёжная, и что надо писать проверяющий модуль снаружи. Чем меня здорово удивил.

Ответ на 1й вопрос в 1м посте: Да, с двумя независимыми клоками. На что это ещё похоже? Не понял, поясните. Спасибокэп.

Согласен с доводами, считаю ваш ответ -- "достаточно" :) В старые и не очень времена у обоих вендоров было много косяков. С DDR-контроллером, PLLями, трансиверами, да бог знает с чем ещё, возможно и с FIFO. Я вот нашёл Sim-Syn mismatch для Xilinx FIFO последних версий (годичной давности). Но в целом я про то, надо ли вводить доп. контроль или нет. Прихожу к выводу, что нет.

Лексика не понравилась. Resync - правильно, Reclock - допустимо, Retact - это уже какой-то язык с Брайтон-Бич ("Вам чиз как - послайсить или целым писом?" - отвратно же). И потом они утонули, обсуждая изобретённый автором велосипед вместо кода Грея. То ли он про него не знает, то ли знает и не применяет, не охото в это погружаться. Это как начать решать систему уравнений и погрязнуть в дискуссиях о формуле дискриминанта. "Запись в FIFO одновременно со сбросом...." - а нафига расставлять себе грабли и потом удивляться... Надо просто аккуратно писать код. p.s. Надо читать знаменитые 2 pdf от Клиффорда Саммингса, вот код на примере его статей: http://subversion.assembla.com/svn/ecpe-29...ll_async_fifo.v Так вот, мой вопрос - этого достаточно для ASIC, или надо что-то ещё. Мой визави утверждает, что _недостаточно_, и надо мониторить FIFO на предмет дублирования и пропадания данных на выходе. Моё короткое мнение - это чушь собачья, т.к. FIFO - это не трёхрегистровый синхронизатор.

Привет, коллеги. Возникла в уменя дискуссия с ASIC'овцем про Async FIFO. Утверждает, что стандартного Async dual clock FIFO c счётчиками Грея и синхронизаторами недостаточно для стабильной работы. Моё мнение - достаточно, а если что, надо брать более длинные синхронизаторы. Что посоветуете, где правда? Речь, разумеется, не идёт про rad grade и всё такое.

Почитайте нашего коллегу с форума http://www.kit-e.ru/articles/plis/2010_10_54.php А вообще - это команда, использовать которую *нельзя*. Надо сетфальспасить только конкретные пути. Это приходит с опытом, поэтому убеждать не буду.

del

nCE ‾‾‾‾‾\______________________/‾‾‾‾‾ nOE ‾‾‾‾‾‾‾‾‾‾\___________/‾‾‾‾‾‾‾‾‾‾‾‾ ADDR XXXXX a__d__d__r__e__s__s XXXXXX DATA ZZZZZZZZZZ d__a__t__a ZZZZZZZZZZZ Получается, что задача - довести сигналы до мультиплексоров, которые определяют, что подать на data_out; и чем меньше общая задержка от пина nOE, nCE, ADDR то появления чего-то на DATA, тем лучше. И, вроде как, регистр во входном пине ситуацию не улучшит. Хотя может упростить констрейны.

Не используются. Ставил просто регистры, не в пинах, не помогало. Надо бы попробовать, через быстрый clk.

Коллеги, вопрос в тему. Ситуация. Используется асинхронный интерфейс (addr, nOE, nWE, nCE, bidir data) для связи с процессором. "Частота" асинхронного интерфейса - около 133 мгц, вроде немного, но много проблем. Работаю с 2мя разными процессорами, у них чуть разные диаграммы на этом интерфейсе. Состояние, !nCE && !nWE держится примерно 2.5 периода этих 133 мгц, т.е. 18ns, т.е. чуть более, чем дофига для нашего xilinx 7 series (скорости - "-2" (mid) и "-1" (slow)). Когда resource usage небольшой, всё работает и без констрейнов. Ещё бы, за 18 наносекунд-то. Когда resource usage достигает >90% разводка через раз, то плохая, то очень плохая, без констрейнов не работает. После долгих мучений остановился на куче set_max_delay от входных пинов до триггеров такого плана: set_max_delay 9.500 -datapath_only -from [get_ports ADDR] -to [get_pins {my_top_level/requested_wr_addr_reg[*]/D}] И так - от всех пинов, включая nCE, nWE, nOE, кроме DATA (почему DATA не попала в констрейны, сейчас не помню, уже год прошёл). 9.5ns получилось экспериментально. Меньше - тайминги фэйлят. Помогло, но мне не кажется это не совсем верный способ. Можно кто знает лучше?

Для "хазинщины" и поклонников теорий заговора и Овертона есть другие профессиональные сайты в домене .ws, не будем их тут рекламировать. А для специалистов - хорошая новость. И да, .bit-файлы они тоже принимают. Это облако - отличная штука. Там можно попробовать свой проект, если нет девкита, можно пользоватья Amazon EC2 (elastic cloud) по прямому назначению, демпфировать нагрузку на выч. ресурсы, или, используя спотовый аукцион, считать на fpga что-то долгое по небольшим ценам, когда облако не загружено. (правда, не уверен, что спотовый аукцион будет доступен для инстансов этого типа). В-общем это ещё один хороший способ заработать денег для инженеров нашего круга, способ "вырасти" для маленьких, но удачных компаний.

Нет, при открытии IP Parameter Editor (для FP-DSP блока), в самом началее грузится QSys, потом, после нажатия кнопки "Close", окно QSys превращается в IP Parameter Editor. По крайне мере у меня на Ubuntu 16.04 так.

Добрый день, коллеги. Меня не было в мире Альтеры 3 года, с 2013 по 2016 и я заметил изменения. А расскажите, если не сложно, что произошло в 2014, про пропажу удобного, на мой взгляд, MegaWizard'а, и про "заставить всех запускать QSys" вместо него. У меня куча вопросов, есть какая-то pdf'ка или описание этого процесса перехода к QSys'у? Зачем (концептуально) запихали мегавизард в кусис? Это нормально, что при тыкании на ip-ядро в квартусе, надо каждый раз долго (5-7 секунд) ждать, пока загрузится кусис? Или можно как-то ускорить, чтобы он не загружался каждый раз? Есть ли штуки типа "Generate Example" в Vivado для сложных ip-ядер типа MIG (DDR controller), PCIe, 10Gig Eth? Погуглил, но краткого документа/видео на тему "MegaWizard - to QSys" не нашёл. Upd. Генерилку example'ов нашёл.

Решение нашлось. Надо взять файлы: crti.o crtn.o libc.a libc.so в убунте 14.04 из каталога /usr/lib/x86_64-linux-gnu и положить их в убунте 16.04 в какой-то новый каталог, я положил рядом с квестой в /opt/mentor/ld_library. Перед запуском квесты выполнять команду: export LIBRARY_PATH=/opt/mentor/ld_library я добавлю эту команду в свой алиас в .bashrc: alias questa='export LM_LICENSE_FILE=/opt/mentor/mentor.dat; export LIBRARY_PATH=/opt/mentor/ld_library; rm -rf work; rm transcript; rm modelsim.ini; vsim &' можно вместо алиаса добавить в башрц, только тогда лучше так: export LIBRARY_PATH="/opt/mentor/ld_library:$LIBRARY_PATH"