Джеймс

Ну на таких форумах люди как бы сказать.. комплектуют большие системы. А автор обращается к разработчикам, что верно. Абсолютно! Ничего себе.. Да, например министерство культуры.. Или, гораздо ближе к делу - пример "T-платформ".

Вы помните, как было у Булгакова? "Есть нужно уметь.... Нужно не только знать, что съесть, но и когда и как. ... И что при этом говорить. " Как думал ТС? Так и рассуждал! Ну а что SPI Clock? Обычный клок! Как и любой другой. Счетчик на нем тоже будет работать, всё просто. А то, что у такого счетчика с таким clock-ом даже reset корректно не сделать (и это заметьте не SRAM FPGA!) так об этом мы пока не задумываемся (а сброса в проекте и до сих пор нет). Конечно, автору нужен clock-бридж (особенно если он захочет довести частоту SPI до 100MHz). Ну давайте ещё 11 страниц обсуждать clock-бриджи. Вместо того чтобы объяснить, как сделать просто и правильно. На этом моё участие в этой дискуссии закончено.

Так какой вариант проекта вы в итоге использовали? C тактированием от clock 50MHz или с тактированием от SPI_CLK ?

> Решением этой проблемы возможно будет создание модуля (асинхронного SPI) не привязанного к частоте 50МГц (по советам Plain и Leka). > Уточню и повторюсь. C такой формулировкой "ТЗ" (использование только SPI_CLK) это невозможно Если кто-то будет делать 100MHz SPI slave, полагаясь только на частоту SPI_CLK, диагноз будет тот же самый

Нереально, и это еще бОльший костыль чем удвоитель частоты Одна оговорка - в терминах разработки для ПЛИС это вообще не clock

Ладно, в целом нормально. Хотя reset-а все равно нет, но я уже понял, что вас не додавить. Кстати, вы уже наверное почувствовали разницу между "стабильно работает" и "работает, если полапать незанятые пины". Вот то-то и оно. Теперь по стилю.. Знаете, - можно писать стихи без глаголов, а у вас в коде совсем нет ELSE-ов. Может они и правда здесь не нужны, но мне кажется причина в чем-то другом. Взять например этот фрагмент: always @(posedge i_core_clk) begin if(clk_pos && !cs_2) counter <= counter + 1'd1; if(cs_neg) counter <= 3'd0; end Очевидно же, что приоритет обнуления счетчика должен быть выше, - то есть код должен выглядеть вот так: always @(posedge i_core_clk) begin if(cs_neg) counter[2:0] <= 3'd0; else if (clk_pos && !cs_2) counter[2:0] <= counter[2:0] + 3'd1; end Это как минимум улучшает понимание, даже если эти события во времени и не пересекаются никогда. Далее, снова эта ваша привычка, зачем засунули sr_rx и rx_flag под один always ?? always @(posedge i_core_clk) begin if(clk_pos && !cs_2) sr_rx[7:0] <= {sr_rx[6:0], i_mosi}; end Всё! Дальше пошел другой always. always @(posedge i_core_clk) begin здесь только формирование rx_flag !!! end и так далее Теперь по вашей проблеме. Сейчас нет времени разбираться хватит ли 50MHz чтобы принимать на частоте SPI 18MHz. Но я так понял, вы в это уперлись. Была бы PLL - поставили бы PLL. Но её нет. Сделать-то на самом деле можно - собирайте 4 бита в одном регистре (по нечетным значениям счетчика counter) и 4 бита в другом регистре по четным значениям счетчика counter. Соответствующие стробики будут наезжать на следующий такт SCLK, но это не страшно - в параллель будут работать два "плеча". Но если так делать не хотите, предлагаю довольно некрасивый hack. Сделать удвоитель частоты на логике. Тогда получите 100 MHz тактовую частоту (не меандр, короткие импульсы). Как сделать - по ссылке (см. Удвоитель частоты). Автор удвоителя - Peter Alfke https://tqfp.org/fpga/shest-prostyh-asinhronnyh-histrostey.html

Этот рабочий код можете выложить? ("В синхронном варианте ... только частота не максимальная, а 9МГц.") Вместе с тестбенчем, естественно

C тем что не "костыль" уже вроде должны разобраться. Но мне есть еще что добавить. Дело в том, что код для ПЛИС/ASIC не может существовать как некая абстракция. Этот код- хороший, этот код - плохой. Код еще должен учитывать особенности архитектуры семейства, использование трассировочных ресурсов и так далее.

Нет, вы к сожалению путаете терминологию. Советую почитать классическую статью http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_Resets.pdf Статья относительно большая, поэтому можете сразу посмотреть, чем отличается Рисунок 3 от Рисунка 4. Ну и в 6 разделе речь идет как раз про синхронизатор для асинхронного reset-а. Ну и ДА, сlock ("чистый" clock!) должен "накрывать" cигнал асинхронного сброса. И сниматься естественно в подходящее время ("the reset release, also called reset removal") P.S Автору это пока не надо, у него другие проблемы, - до этих он еще не дошел

Советовать в плане сброса тут к сожалению нечего - у Автора везде используется "стробированный" SPI-clock, поэтому тактовая частота сигнал сброса "не накроет". То есть всё та же алхимия и поиски философского камня

@Leka Извините, вопрос совсем не по теме. А Вы "в команде" занимаетесь FPGA-разработкой или один?

> Да пробовал я reset на 44 pin! Те же яйца, только в профиль. Не в этом дело. > Ну и в каком случае вы говорили то, что соответствует действительности? Но ответа на этот вопрос не требуется - все и так понятно. Продолжайте искать "философский камень" (=читерский совет, который заставит работать ваш код на живую нитку).

Так что же не выложили код и не написали - вот, глядите, тоже не работает! В общем есть сильное сомнение, в том что именно вы делали. Вам нужно выполнить как минимум два совета, которые вам были даны: 1) Привести весь код к виду: always @(posedge i_core_clk or negedge i_rst) begin ... И никаких negedge и никаких or posedge SS !! 2) Не надо все в одну кучу смешивать. Пока вы начинающий, придерживайтесь правила: один регистровый объект (например, counter, clk_flag) - один always блок. Иногда можно ему в компанию добавить что-то очень близко связанное функционально, но у вас тут вроде не тот случай. Если вы надеялись что-то оптимизировать, собирая все под одной крышей - вы заблуждались. Синтезатор все равно рассматривает вначале все сущности по отдельности и лишь потом сопоставляет их функции и пытается что-то скомбинировать. Ваша первейшая задача - научиться писать ясный, незапутанный код, который работает понятным образом. П. 2 это был совет ув. Raven Без этого ваш "быдло-код" (ваши собственные слова) никто как видите даже не хочет анализировать. После того, как приведете проект к человеческому виду, вы скорее всего столкнетесь с тем, что не сможете принимать данные от SPI 18 МГц, имея частоту 50 МГц. Если бы было другое семейство, вы бы могли задействовать PLL. Но у вас к сожалению нет PLL. Но решение будет - после выполнения означенных пунктов. А может и догадаетесь. P.S Я естественно уверен, что ничего этого вы делать не будете

Гвозди бы делать из этих людей.. (крепче бы не было в мире гвоздей)

Книгу-то нашли? @Alexey87 Нашли книгу?