[des00 25]

9 hours ago, HardRock said:

Интернет есть, изучил книги, в том числе цикл статей от iosifk. Делаю как "должно быть", но оно не работает. Для меня это выглядит как глюк.

Либо есть какие-то неявные ограничения, либо какой-то момент упустил.

 

Использую Quartus Prime 19.11 Lite, синтезирую под Cyclone IV EP4CE6E22C8, язык SystemVerilog HDL.

Вы прочитали даже не букварь, а просто посмотрели на чужие буквы. Ответы на все ваши вопросы по языку, находятся в стандарте. Который читается как книга, с кучей примеров за 2-3 дня. А если не читается, то благодаря каталогизации, любой вопрос находится за 5 минут. Ответы на ваши вопросы по организации находятся в книгах "Курс молодого бойца" и библия "HDL Chip design". Книги с кодом, картинками и хорошим текстом. Но нет, вы узнаете все это на форуме, работая в слепую, без моделирования, используюя квартус и осцил...удачи вам на этом пути, надеюсь не надоест другим форумчанам читать вам стандарт.

[haker_fox 61]

11 hours ago, des00 said:

и библия "HDL Chip design"

Простите, Вы Эту книгу имеете в виду? Спасибо!

[des00 25]

46 minutes ago, haker_fox said:

Простите, Вы Эту книгу имеете в виду? Спасибо!

да, она очень старая, но прописные истины там, актуальны и в настоящее время)

[HardRock 0]

Всётаки использовать один буфер для одновременной отправки / приёма бит - не лучшее решение. Оно работает, но если в принимаемых данных выставлен старший бит, то этот бит появится в эфире передачи после отправки последнего бита. Это не работу не влияет, но на осциллографе или логическом анализаторе выглядит криво + всётаки может нарушить состояние принимающей стороны в теории. Так что лучше делать классически - два буфера.

Такой вопрос - как заставить компилятор использовать память, а не реализовывать её?

Раньше когда объявлял массив, компилятор помещал блок контроллера памяти в схему.

Потом объявил не пакованные структуры и массив из этих структур, компилятор начал реализовывать.

Изменено 22 апреля, 2020 пользователем HardRock

[nice_vladi 1]

Ну хотя бы квартусовским симулятором воспользуйтесь. Неужели не раздражает тратить время на постоянную пересборку проекта и тыканье щупами осцилла?) Это же огромное количество времени на помойку, причем безо всякой пользы.

[HardRock 0]

 

1 час назад, nice_vladi сказал:

Ну хотя бы квартусовским симулятором воспользуйтесь. Неужели не раздражает тратить время на постоянную пересборку проекта и тыканье щупами осцилла?) Это же огромное количество времени на помойку, причем безо всякой пользы.

Считаю это малоэффективным :)

Чтобы симулировать обмен данных по SPI со своим программным протоколом, который постоянно дорабатываю нужно во первых написать и поддерживать передающую часть, как-то убедиться что она работает корректно (наверно написать тесты на неё, а потом тесты на тесты, и тесты на тесты, рискуя уйти в бесконечную рекурсию). Потом нужно симулировать источник данных с его аппаратным протоколом, симулировать приемник данных с его аппаратным протоколом.

Короче куча работы ради работы без практического результата 

У меня комп мощный, синтез проекта (сейчас чуть более 1200 логических блоков) занимает в пределах 15 секунд. Ещё пару секунд ткнуть на кнопку "Start" в программаторе. Остальное железо подключено, его состояние выводится и абы что оно хавать или выдавать не будет т.к. заведомо надёжное. Плюс сразу пишу С++ API для взаимодействия с FPGA.

Использую выводы FPGA чтобы дублировать туда интересующие сигналы для осциллографа.

Изменено 22 апреля, 2020 пользователем HardRock

[one_eight_seven 6]

25 minutes ago, HardRock said:

Считаю это малоэффективным :)

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

[Maverick_ 15]

4 hours ago, HardRock said:

Всётаки использовать один буфер для одновременной отправки / приёма бит - не лучшее решение. Оно работает, но если в принимаемых данных выставлен старший бит, то этот бит появится в эфире передачи после отправки последнего бита. Это не работу не влияет, но на осциллографе или логическом анализаторе выглядит криво + всётаки может нарушить состояние принимающей стороны в теории. Так что лучше делать классически - два буфера.

Такой вопрос - как заставить компилятор использовать память, а не реализовывать её?

Раньше когда объявлял массив, компилятор помещал блок контроллера памяти в схему.

Потом объявил не пакованные структуры и массив из этих структур, компилятор начал реализовывать.

Так Вы можете реализовать в одной памяти: например старшая половина памяти для приема данных, младшая для отправки.

Идеально конечно два буфера размером на 1 пакет данных

Чтобы синтезатор увидел Болочную память нужно ее корректно описать - в template имются примеры

[iosifk 3]

28 минут назад, HardRock сказал:

Считаю это малоэффективным :)

Чтобы симулировать обмен данных по SPI ....

Только не пишите потом, что я злорадствую или куражусь. Нет! Просто у нас несовпадение жизненных целей.

Есть такое определение: процесс, который ведется ради самого процесса называется игра. 

Так вот, профессионал ведет свою деятельность ради зарплаты, а потому он вынужден вести разработку в минимальные сроки, но при этом он обязан использовать те приемы работы, которые приняты в промышленности. А вот любитель ведет свою деятельность по совсем другим правилам. Ему нет необходимости экономить время. И он не обязан все работы делать по правилам. 

Теперь смотрим "показания", которые давал ТС. Там нет ни одного слова "научиться". А есть только  "хочу ШИМ + SPI + парсер команд". И более ничего. Именно поэтому полное отрицание нормальной для разработчиков технологии. Абсолютно дикое расходование времени. Наверняка многие согласятся, что ШИМ + SPI + парсер команд не должно занять более 1-3 дней. А по факту прошло 6 дней и половины еще нет. Но зато то, что для  профессионала скучная сермяга, то для игруна - подвиг! И здесь подвиг уже есть.

Так что советы "как надо делать" в этой теме не помогут никак. Я уже пытался объяснять еще 16-го, но меня ТС не услышал. Тут лучший способ - это приведите для ТС готовые куски кода. И как только подвиг станет еще "круче", так и ТС прекратит писать свои вопросы.. Ну, либо мы увидим "развлекуху" еще на 10 страницах...

[HardRock 0]

2 часа назад, Maverick_ сказал:

Так Вы можете реализовать в одной памяти: например старшая половина памяти для приема данных, младшая для отправки.

Именно о таком варианте писал. Старший бит передаётся, одновременно с этим принимается младший и буфер сдвигается. Проблема в том что между байтами есть пауза, при этом сессия не закрывается (SS поднят), соответственно старший бит оказывается на выходе и если старший бит в буфере оказывается 1, то эта 1-ка соответственно выскакивает в эфир на несколько клоков. Занулить сразу буфер нельзя, только на следующем клоке. 

Поэтому да, лучше два буфера. Буфер отправки оказывается пустым и на выходе всегда ноль между байтами.

 

2 часа назад, Maverick_ сказал:

Чтобы синтезатор увидел Болочную память нужно ее корректно описать - в template имются примеры

Спасибо! Посмотрел. Судя по всему нужно вставлять эту реализацию. Если просто объявить массив скажем 

reg [7:0] memory[10]

то компилятор сам вставляет SYNC_RAM.

Если сделать массив структур

typedef struct {
  reg [7:0] data; 
} Data;

Data memory[10];

То происходит реализация.

 

2 часа назад, iosifk сказал:

Только не пишите потом, что я злорадствую или куражусь. Нет! Просто у нас несовпадение жизненных целей.

Есть такое определение: процесс, который ведется ради самого процесса называется игра. 

Так вот, профессионал ведет свою деятельность ради зарплаты, а потому он вынужден вести разработку в минимальные сроки, но при этом он обязан использовать те приемы работы, которые приняты в промышленности. А вот любитель ведет свою деятельность по совсем другим правилам. Ему нет необходимости экономить время. И он не обязан все работы делать по правилам. 

Глубоко копаете :)

Мне нравятся ваши рассуждения о подходах в работе и хобби, когда нужно быстро когда нет, и я считаю их правильными. Однако, предлагаемое их применение вызывает логическое противоречие или двойные стандарты.

С одной стороны вы говорите что если делать "коммерческую" железку то нужно сделать её быстро, нет смысла экономить на чипах, заниматься вылизыванием кода и тп, с другой стороны говорите что не одобряете "подход некоторых начальников - давайте жарить, а масло потом поднесут" (с) Конечно, сначала проект нужно продумать на много шагов вперёд чтобы потом не было мучительно больно добавлять новые функции или что-то в нём менять, но и этап старта  должен иметь разумные трудозатраты. Тут много факторов, например цена ошибки в продукте. Если она способна привести к катастрофе и серьезному ущербу, то да, наверно стоит сильно минимизировать этот риск тестами. Если нет - то может быть разумнее запустить ракету со сварщиками на борту чтобы они в полёте доварили недостающие детали? А тем временем на земле все увидят что "оно полетело" и закажут ещё десяток таких ракет с новыми функциями :) Ну и в целом всех разработчиков можно поделить на две крайности: человек-процесс и человек-результат. Первый - это настоящий программист-перфекционист, которому нравится сам процесс и мало интересует когда появится результат. Второму нужно быстро собрать нечто хоть из г. и палок что решает конкретную задачу. Оба способны сделать проект, только у первого это будет долго и качественно, у второго быстро и криво-косо. А истина как всегда где-то посередине :) Как считаете?

2 часа назад, iosifk сказал:

Теперь смотрим "показания", которые давал ТС. Там нет ни одного слова "научиться". А есть только  "хочу ШИМ + SPI + парсер команд". И более ничего. Именно поэтому полное отрицание нормальной для разработчиков технологии. Абсолютно дикое расходование времени. Наверняка многие согласятся, что ШИМ + SPI + парсер команд не должно занять более 1-3 дней. А по факту прошло 6 дней и половины еще нет. Но зато то, что для  профессионала скучная сермяга, то для игруна - подвиг! И здесь подвиг уже есть.

На самом деле уже всё есть: SPI слейв, PWM энкодер, PWM декодер, архитектура проекта, которая позволяет легко расширять протокол обмена по SPI и добавлять новые блоки. Осталось доделать коммутацию всего этого на ножки плиса в зависимости от настроек, передаваемых по SPI. И потом в планах сделать SBUS декодер / экодер (вариация на тему UART), который будет ещё одним блоком в общей архитектуре. И всё это работает с настоящим железом.  Занимаюсь этим не фулл-тайм, а в свободное время, это железка для моего хобби, однако имеет хороший коммерческий потенциал среди таких же хоббистов, но это не является целью разработки, а скорее бонус.

 

2 часа назад, iosifk сказал:

Так что советы "как надо делать" в этой теме не помогут никак. Я уже пытался объяснять еще 16-го, но меня ТС не услышал. Тут лучший способ - это приведите для ТС готовые куски кода. И как только подвиг станет еще "круче", так и ТС прекратит писать свои вопросы.. Ну, либо мы увидим "развлекуху" еще на 10 страницах...

Не нужны готовые куски кода, их полно на opencores, да и просто в интернете. Интересуют подходы и методы, как в ПЛИСах делать стоит, а как нет, а так же различные нюансы. Например к какой книге описано что Qartus Prime не синтезирует static переменные или почему массив структур автоматом не заменяется на SYNC_MEM и как сделать чтобы использовалась память, что более правильно и освободит место в чипе.

Изменено 22 апреля, 2020 пользователем HardRock

[Plain 195]

8 минут назад, HardRock сказал:

лучше два буфера

Если транзита данных нет, то это уже никакой не SPI, а просто абстрактный последовательный интерфейс.

[Leka 0]

8 hours ago, HardRock said:

У меня комп мощный, синтез проекта (сейчас чуть более 1200 логических блоков) занимает в пределах 15 секунд. Ещё пару секунд ткнуть на кнопку "Start" в программаторе.

Битстрим через 15 секунд? Хотелось бы подробностей. Удивило, тк число ядер и тп вроде сильно влияет на скорость получения битстрима, а частота ядер давно уже принципиально не растет. Или это в 19 версии Квартуса ускорилось?  

6 hours ago, HardRock said:

reg [7:0] memory[10]

Не понял, зачем делать такие мелкие буфера. Это ПЛИС, а не процессор - проще гонять потоки через длинные регистры в 80 бит и тп. А в декодере команд выделять нужные битовые поля.

 

6 hours ago, HardRock said:

Интересуют подходы и методы, как в ПЛИСах делать стоит, а как нет, а так же различные нюансы.

Не встречал книг, где основной упор делается на синтез, а не на верификацию, и где четко разделяются синтезируемые и несинтезируемые конструкции.

Изменено 22 апреля, 2020 пользователем Leka

[HardRock 0]

2 часа назад, Leka сказал:

Битстрим через 15 секунд? Хотелось бы подробностей. Удивило, тк число ядер и тп вроде сильно влияет на скорость получения битстрима, а частота ядер давно уже принципиально не растет. Или это в 19 версии Квартуса ускорилось?  

Не знаю как относительно других, не с чем сравнивать. 

i7-7700K 4.2GHz, 16GB RAM, SATA3 SSD, Ubuntu 18.04.

В настройках стоит использовать все доступные ядра, но больше 4 вроде не использует. Нужно будет попробовать вручную задать, кстати. 

2 часа назад, Leka сказал:

Не понял, зачем делать такие мелкие буфера. Это ПЛИС, а не процессор - проще гонять потоки через длинные регистры в 80 бит и тп. А в декодере команд выделять нужные битовые поля.

Ну это для примера, а по сути так и получается. То что гоняется по SPI - это не 1 в 1 то что лежит внутри. Гонять удобно байты, а хранить как есть. Объем сейчас где-то пару сотен байт, но это ещё не все.

Хотя может пока и не стоит заморачиваться, пусть реализует, место есть :) 

Если я правильно понимаю, то использование встроенной памяти это больше оптимизация чтобы высвободить место под функционал? 

[RobFPGA 30]

Приветствую!

3 hours ago, Leka said:

Не понял, зачем делать такие мелкие буфера. Это ПЛИС, а не процессор - проще гонять потоки через длинные регистры в 80 бит и тп. А в декодере команд выделять нужные битовые поля.

Основная философия в FPGA - "не откладывай на потом то что можно сделать сейчас"   
Если есть возможность обрабатывать во время приема байт-за байтом - то зачем откладывать это в длинный (80 бит)  ящик чтобы потом опять лазить по нему мультиплексорами?  

Удачи! Rob.

[Nick_K 0]

10 hours ago, Leka said:

Не встречал книг, где основной упор делается на синтез, а не на верификацию, и где четко разделяются синтезируемые и несинтезируемые конструкции.

Или плохо искали или не искали вовсе. Полно книг где основная задача именно синтезировать. И на VHDL и на Verilog и на SystemVerilog.

А по синтезируемым и несинтезируемым конструкциям у каждого производителя полжен быть вот такой документ с чёткими пояснениями и поддержкой (ниже 202-й страницы).