Jump to content

    

Дружить с синтезатором стоит ?

Я не понял. Синхронизатор и есть те самые пара триггеров.

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

 

Share this post


Link to post
Share on other sites

Я склонен считать казус с избыточностью глюком ISE.

В RTL я не нашел разницы...

Share this post


Link to post
Share on other sites

Ради интереса прогнал отдельно именно этот (ранее описанный) модуль приёмника и убедился, что избыточность в коде разнит показатель предельной частоты на 30 МГц! Лишняя команда улучшает показатель. Или это глюк ISE?

Share this post


Link to post
Share on other sites

Так как строчка cntime <= (0=>'1',others=>'0'); в исходном тексте присутствует в обеих частях конструкции IF, то её смело можно вынести из под условия устранив зависимость от бита cntbit(9). Что и делает синтезатор, выбрасывая напрочь ненужный cntbit начиная с первого бита (если не ошибаюсь).

В результате в состоянии "pusk" сигнал cntime засисит только от cntime(7) и r_next.

Если строчку с комментарием --!!!! Super speed!!!! убрать, то добавится зависимость от бита cntbit(9), не всречающаяся ни где больше.

Чтобы убедиться, что удаление строчки с комментарием усложняет схему не требуется знание конкретной архитектуры.

 

PS: Пролистал тему и не нашел ответа, если что извиняюсь за невнимательность.

 

Share this post


Link to post
Share on other sites
Так как строчка cntime <= (0=>'1',others=>'0'); в исходном тексте присутствует в обеих частях конструкции IF, то её смело можно вынести из под условия устранив зависимость от бита cntbit(9). Что и делает синтезатор, выбрасывая напрочь ненужный cntbit начиная с первого бита (если не ошибаюсь).

В результате в состоянии "pusk" сигнал cntime засисит только от cntime(7) и r_next.

Если строчку с комментарием --!!!! Super speed!!!! убрать, то добавится зависимость от бита cntbit(9), не всречающаяся ни где больше.

Чтобы убедиться, что удаление строчки с комментарием усложняет схему не требуется знание конкретной архитектуры.

 

PS: Пролистал тему и не нашел ответа, если что извиняюсь за невнимательность.

Действительно!...

 

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

Share this post


Link to post
Share on other sites

Вообще-то, поведение схемы меняется. И тесты должны были это обнаружить.

Перенесение шаманских методов экстримального программирования на электронику не одобряю.

Share this post


Link to post
Share on other sites
Вообще-то, поведение схемы меняется. И тесты должны были это обнаружить.

Перенесение шаманских методов экстримального программирования на электронику не одобряю.

:laughing:

Вы не поняли... В данном случае такой трюк(или ваш) выводит часть операций из под контроля лишней логики, чем и обеспечивается повышение скорости.

Это требует более тщательной проработки диаграммы состояний и переходов между ними. Всего-лишь! А когда счёт идёт на грани требований,- это может стать единственным способом резко поднять быстродействие.

Жаль, что для вас это вроде шаманства! Тут есть рациональное зерно... :1111493779:

Share this post


Link to post
Share on other sites

Таки да, я ничего не понял.

Какая логика была лишней и что обеспечивает повышение быстродействия?

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

 

 

Share this post


Link to post
Share on other sites
Таки да, я ничего не понял.

Какая логика была лишней и что обеспечивает повышение быстродействия?

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

Таки да, вы ничего не поняли...

Если бы вы были внимательны(и я тоже!), то всё началось с лишней команды, которую я решил убрать. В итоге показатель быстродействия резко упал.

Посмотрите, в следующем состоянии автомата эта операция будет совершена.

Благодаря вашей находке (нет никакой неожиданности!) мы можем вывести за лишнее IF эту строку, но только если оставить эту лишнюю строку по логике на месте(а синтезатор это сделает за нас!)

Когда пишешь автомат не стоит наворачивать условия для строгого выполнения, если это не нарушает общую логику автомата. Главное,- достижение цели. Только самое необходимое!

 

Кстати, у меня была подобная ситуация в Кактусе, когда я убрал установку в исходное состояние счётчика, которое в динамике никогда не наступало. Это мне резко помогло! Это было важно только для моделирования...

==================

Теперь можно говорить о методе избыточности. Имеет смысл посмотреть на свой код с точки зрения,- "а что будет если" данное условие не будет таким строгим, как вначале, и некоторые логические требования(определится!) не противоречат выполнению автомата. Да в конце концов, - может что-то не достижимо в динамике поведения вообще!

Edited by Мур

Share this post


Link to post
Share on other sites
.... Главное,- достижение цели. Только самое необходимое!

Есть соблазн действовать в манере последовательного программирования, когда резервируется в микроконтроллере переменная для счётчиков на все случаи жизни проекта. В итоге для микроконтроллера экономится память.

 

Для параллельного программирования, чтобы иметь предельные скорости проекта, такой подход есть ошибка. Стоит под каждый счётчик на функцию в автомате резервировать свой счётчик. Это съедает аппаратный рессурс, но не губит скорость работы. Если он один,-он мгновенно обрастает кучей логики предустановок и дешифраторов состояния.

Я не прав?

Я специально пишу об этом, чтобы забывали об опыте последовательного программирования.

Edited by Мур

Share this post


Link to post
Share on other sites

Вынужденный разрабатывать железо мозг программиста сильно опухает, но рано или поздно лопается,

а на его месте выростает мозг разработчика программно-аппаратных систем.

Радикально ускорить процесс выработки новых критериев можно разглядывая результат в fpga-editor / chip planner

 

Share this post


Link to post
Share on other sites
Вынужденный разрабатывать железо мозг программиста сильно опухает, но рано или поздно лопается,

а на его месте выростает мозг разработчика программно-аппаратных систем.

Радикально ускорить процесс выработки новых критериев можно разглядывая результат в fpga-editor / chip planner

:rolleyes:

В моём случае можно говорить о возвращении в профессию. Я как раз цифровик, 25 лет работающий с контроллерами. Так что мне легко копаться в железе, хоть и на экране монитора....

Поскольку возможности синтезаторов сильно отличаются, только опыт поможет предсказывать во что данный синтезатор переводит HDL-конструции. И вообще, возможна ли синтезабельность?

Share this post


Link to post
Share on other sites

Синтезабельность зависит от микросхемы и немного от стервозности синтезатора.

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

Для этого в документации на синтезаторы есть шаблоны на всех языках, применение которых вызывает inferring разнообразных полезных конструкций.

Вот над placer-ом глумиться - занятно.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this