Timmy

На VHDL своя разрешающая функция в данном случае не нужна. Тестбенч должен выдавать на шину уровень std_logic.'H', имитируя подтяжку, а все узлы(включая и тестовый) - либо 'Z', либо '0'. В приёмниках преобразовать входной сигнал с помощью TO_X01() сразу после входного пина, чтобы превратить 'H' в '1'.

Проблема в этом случае в том, что возможно ложное срабатывание, если pump будет иметь среднюю частоту 100Гц, тогда в домене 1Гц вместо меандра будет видна константа.

Если не ошибаюсь, в данном случае нужно задавать max_delay = t_period - t_setup, min_delay = t_hold, то есть (50-2) ns и 6.3 ns, если данные АЦП тактируются по DV. По клокам, скорее всего они у вас все синхронные, поэтому не должно быть exclusive groups & false path

Совесем недавно разбирали эту тему, выяснилось, что для процессов тру-двухпортовой памяти в Квартусе нельзя использовать generate. Возможно, в Симплифае тоже.

По-моему, метастабильностью называется кратковременное неустойчивое зависание выхода триггера в средней точке, вследствие нарушения setup/hold. А случай ТС называется, вроде, гонкой сигналов. То есть фронт rx бежит наперегонки с клоком, и на один триггер прибегает раньше фронта клока, на другой - позже, в результате защёлкивается в разных тактах и логика работы схемы нарушается. При этом setup/hold могут соблюдаться. Вероятность поймать ошибку при гонке сигналов гораздо выше, чем от метастабильности.

Функция "+" из std_logic_arith перегружена кучей способов, в частности она может возвращать как signed, так и std_logic_vector. Для первого сложения используется вариант signed+signed => signed, поскольку std_logic_vector не подходит ко второму сложению (std_logic_vector+signed не определено), а для второго сложения будет использован вариант signed+signed=>std_logic_Vector. А вообще лучше пользовать numeric_std, там таких вопросов не будет:).

В вашем коде неправильно то, что main_clk_cnt не засинхронизирован с медленным клоком, от сброса к сбросу устройство может работать по-разному. Следует перевести медленный клок в логику(например, с помощью двух FF и xor), защёлкнуть его на FF быстрым клоком, выделить фронт, и привязать к этому фронту фазу чтения data_mainclk. Достаточно, чтобы были правильно оконстрейнены клоки, и не была запрещена проверка путей между data_clock и clock, другие констрейны не нужны. То, что советует Maverick, тоже в принципе правильно, но для случая синхронных клоков избыточно. Это я предполагаю, что клоки выходят с одного PLL. Расхождение по фазе между ними тогда невелико, и его допустимость будет проверена при STA.

От регистрового файла не нужно 0, если правильно применять конвейер. Даже в моём вышеприведённом mica8 с двухступенчатым конвейером латентность регистрового файла 1. В первом такте/первой ступени выбирается код инструкции и номера регистров из этой инструкции подаются непосредственно на адресные входы модуля регистров, где будут защёлкнуты при смене тактов. Вскоре после начала следующего такта на выходе регистов будут необходимые значения, которые прогоняются через АЛУ, и к концу такта результат стабилизируется на входе данных записи регистрового файла. Из-за особенностей распределённой памяти удаётся обойтись двумя портами адреса, это особенно эффектно смотрится на Ксайлинксах. А у Ниоса конвейер пятиступенчатый, там целый такт выделен на выборку из регистровой памяти и защёлкивание в FF непосредственно перед АЛУ.

А если попробовать generate, причём shared variable запихнуть внутрь generate block, создавая, таким образом, индивиндуальные экземпляры mem_array для каждого модуля памяти?

Конкретно у альтеровцев, полагаю, классическая архитектура MIPS, по ней в Сети достаточно материала. А по-простому, это можно сделать так: берутся две двухпортовых M9k, порты записи объединяются, в результате оба M9k содержат одинаковую информацию. А порты чтения независимо читают первый и второй операнды. Только необходимо, чтобы память поддерживала режим "сначала пишу, потом читаю", что означает, что при совпадении адресов чтения и записи на выходе должны появиться свежезаписанные данные. Поскольку M9K такой режим не поддерживает, придётся его эмулировать при помощи внешней обвески: reg [dw-1:0]bypass; req addr_eq; always @(posedge clk)begin addr_eq <= wr_addr == rd_addr; bypass <= wr_data; end assign rd_data = addr_eq? bypass: m9k_rd_data; то есть, если адреса чтения и записи совпали, в следующем такте выход данных переключится с выхода m9k на bypass, который содержит свежие данные, которые сам m9k ещё не готов выдавать. Такую обвеску надо независимо добавить к обоим M9k, работающим у нас параллельно. Странно, что это не умеет делать Мегавизард:).

При ручной репликации регистров на все реплицированные сигналы надо повесить атрибут syn_preserve, иначе синтезатор их может оптимизировать в один регистр, из-за чего у вас, вероятно, и не стало лучше. Кроме того, 230*35 - это 8000 независимых длинных линий, которые будут зря жрать электричество и могут переполнить ресурсы интерконнекта. Лучше создать древовидную структуру, например, 16 регистровых групп к центральному блоку, и 8-16 оконечных устройств на каждую регистровую группу.

Да, можно сделать ,то что надо, на двух M9K, плюс потребуются два bypass регистра и схема обнаружения коллизий чтения/записи по одному адресу, это +30LE примерно. Так в nios2 делают, просто для пикопроцессора это чересчур, IMHO.

Для LatticeMico8 есть backend к gcc, так что компилятор Си как бы есть. Правда, я что-то не видел исходников патча для binutils, только gcc. С-компилятор там какой-то странный, он во всех моделях памяти(включая 8-битную) делает 32-битные указатели(по-крайней мере, так в мануале написано). В случае переноса на классические Циклоны, придётся хранить регистры, стек и scratchpad в одном M9K(туда же можно запихнуть и код:)), при этом один такт на инструкцию невозможен. Предполагаемый объём для клона Mico8 - 270LE.

Схема очень странная: 1)Непонятно, зачем нужен R21. Вроде бы мы стараемся создать максимальное усиление на LMV321, зачем же тогда уменьшать усиление встроенного ОУ микрофона? 2)Конденсатор на выходе микрофона может приводить к возбуждению его ОУ, тем более, что в даташите заявлен выходной импеданс целых 300 Ом на 1кГц, такой ОУ может быть очень нетолерантен к выходной ёмкости. 3)Усиление при срабатывании ограничителя остаётся на уровне 40Дб, что может приводить к уходу ОУ в насыщение, и высоким нелинейным искажениям. Про странную форму АЧХ уже сказали, но, может быть, это какая-то секретная задумка автора:).

Там всё под Латтис. pmi_rom - это корка блочной памяти в режиме ПЗУ, латентность один такт.

Правила поведения при берсте для мастера ничем не отличаются от оных при одиночном обмене(точнее, при блочном). За исключением того, что мастер выставляет уведомления о берсте на CTI. Это и есть ответ на ваш вопрос. Адрес можно инкрементировать только в ответ на ack, как обычно. И при этом не расчитывать, что ack будут держать весь берст.

У вас некоторая путаница: pipelined mode - это более новый продвинутый режим, в котором используется сигнал stall, вместо ack, тогда мастер может не ждать ack, у вас этого сигнала нет. В классическом берсте мастер может выставлять новый адрес/данные только в ответ на активный ack, в результате как минимум один такт в начале берста бесполезно теряется. Об этом такте не надо специально беспокоиться, оно само получается. Берст поддерживается в основном за счёт действий слэйва, который получает право(и использует его:)) держать активный ack непрерывно, увидев, что мастер хочет берст.

Выкладываю обещанный клон Мики8.mica8.7z Собирается под XP2 на частоте 137МГц(ну немножко медленнее, чем хвастался:)). С пикоблейзом его сравнить по частоте невозможно, так как нужна оптимизированная версия под Ксайлинкс. Думаю, что будет примерно одинаково(+-20%). Латтис по частоте удалось обогнать за счёт того, что они вообще толком не оптимизируют код. Мой дизайн эффективнее за счёт двухступенчатого конвейера. Ступени: выборка из BRAM(а это доолго); декодирование+выполнение+обратная запись. В сравнении с Picoblaze или LatticeMico8, у меня к критическому пути добавляется вторая половина АЛУ, зато убирается выборка из BRAM, так что выходит примерно то же самое. Теоретически процессор должен быть полностью совместим по командам со старым LatticeMico8, до того, как его пришили к Вишбону. Думаю, что использование 8-битных ядер с кодом более 8-16K нецелесообразно, так как площадь памяти начинает существенно превышать площадь процессора, 8-битное управление большой памятью требует извращений, а ресурсы чипа при этом используются неэффективно. Единственная причина появления монстров типа atmega128, IMHO, в том, что некоторые разработчики страдают синдромом утёнка, изучив в молодости 8051 или AVR или PIC. Всем спасибо за советы по лицензии.

В Квартус 13.0.1 поведение аналогичное. Интересно, что в этой ситуации существенно: длина имени, код буквы, или тот факт, что в "хорошей" версии имена dat_o,dat_i присутствуют в обоих модпортах? В Active HDL я иногда ловлю не менее странные глюки. В Симплифай пробовали переносить?

Какую типовую лицензию лучше на него повесить: LGPL, BSD, что-нибудь ещё?

Однажды я из любопытства и для тренировки написал за 4 дня на верилоге клон Lattice mico8(это примерно то же, что пикоблейз), когда он ещё был сам по себе. В результате у меня получилась fmax 145MHz против 85 у оригинала, меньше объём LE, и один такт на инструкцию(кроме исполняемых переходов), вместо двух. Потом посмотрел, как криво mico8 интегрировали в систему с wishbone, и энтузиазм сделать так же и опубликовать почему-то пропал:). В общем, я легко могу сделать на верилоге свободный и открытый аналог пикоблейза с улучшенной растактовкой и системой команд(по прикидке, можно, например, сделать 64 общих регистра и 4килослова кода), присобачить его мастером к AXI/Avalon, и написать на TCL ассемблер. А вот сделать под него порт binutils+gcc энтузиазма уже не хватит. Хотя можно, например, сделать точный клон mico8 под AXI, чтобы к нему подходил софт от Латтис.

Для начала, любые опереации на avalon нужно синхронизировать по клоку, связанному с ним же, то есть clk, а никак не gen_clk.

Чтобы посмотреть по шагам и брейкпойнту работу функции в симуляторе, её надо вызвать из тела какого-нибудь процесса в тестбенче. А при использовании для инициализации константы она выполняется на этапе elaboration, ещё до старта симуляции.

Давайте для начала чётко опишем задачу, а то опять получится спор ни о чём:). Пусть есть функция, вычисляющая следующую CRC32 от 32-битных данных: uint32_t next_crc(uint32_t crc, uint32_t data); Алгоритм следующий: crc = secret; for(i=0; i<ldata; i++){ crc = next_crc(crc, encrypted_data[i]); decrypted_data[i] = crc; } Работать должно правильно, найти обратные CRC для шифрования легко(только я не помню точно как это делается). Но криптостойкость такого алгоритма совсем никакая, он даже брутфорсится элементарно, а если ещё использовать особые свойства CRC... Так что смысл сего действа неясен, разве что простейшая обфускация кода.

В простейшем случае можно вставить в тестбенч модель GTP, симулирующую приёмопередатчик PHY и заставить его постоянно передавать код синхронизации(какой именно, можно в спецификации SGMII прочитать, она короткая). FPGA должен синхронизироваться и отправить запрос статуса. Если это произойдёт, с высокой вероятностью дизайн рабочий, дальше его попробовать в железе.