Комментарии 27
Запретить бы картинки печатных плат от нейросетей. Я пытался понять, что это за плата.
tangnano 9k
Запретить - это цензура. Так нельзя, а то пострадает свобода. А как можно? Можно поставить реостат, который ограничивает доступ нейросети к энергии. Человек пишет параграф текста. Если в этом параграфе есть смысл - это увеличивает сопротивление реостата на 10%. Думаю, что я уже подвинул ползунок реостата на середину. Или у кого-то сомнения, в том, что про "сумматор" пишет не нейросеть?
Ваше упрямство достойно лучшего применения. Вы хотите использовать ключи, а по сути отдельные транзисторы? Пожалуйста. Вот относительно хорошая схема сумматора на транзисторах
https://patents.s3.yandex.net/RU2164036C2_20010310.pdf
Переделайте её так, чтобы вместо pMOS и nMOS транзисторов был ключи. Перед этим найдите в схеме два элемента 2ИЛИ-НЕ и инвертор. Потом уже можете почитать описание патента и найти там формулу XOR3 для суммы. Интереснее посмотреть на формулу для переноса, которая после минимизации должна дать MAJ3. В качестве упражнения, можете задать эту схему на уровне транзисторов в Verilog, ведь этот уровень самый низкий. И здесь приходит разочарование. Все эти действия нужны только для того, чтобы научиться их выполнять, в FPGA нет доступа ни к отдельным транзисторам, ни к отдельным ключам. Есть набор примитивов - LUT, MUX, XOR, FF, конкретные названия приведены в файлах производителя. Эти названия используются для программирования "в примитивах" под названием instantiation. После того, как Вы это поймете, попробуйте соединить два LUT одного блока крест-накрест. Получилось? А могло и не получиться. Всё зависит от возможностей коммутатора (switchbox, PIP). Verilog не позволяет управлять коммутатором вручную, нужно что-то специальное. Этим специальным для Xilinx FPGA является язык XDL. Другие производители такой роскоши не предоставляют.
Вообще складывается впечатление, что данная плата живёт какой-то своей жизнью
Просто то, что вы пытаетесь сделать врядли может быть сделано вообще. И оно фактически работает совсем не так как вы думаете. Вы думаете, что что-то там оптимизируете используя логические элементы типа not, xor,bufif1, а фактически компилятор всё равно всё это упаковывает в LUTы как сможет.
То что делаю я - как раз работает без сбоев. А вот аналоги других, с той же таблицей истинности (всего три входа и два выхода) - дают сбои на испытательном стенде. И при меньшей нагрузке на плату, некоторые решения других - работали, так что Вы всё перепутали. Для людей я оставлял текст, что отвечу на вопросы, но вот вы просто все искажаете действительный порядок вещей, поэтому тоже это отметить надо.
У меня следующее предложение.
1) Вы в своем проекте выключаете Gowin Analizer Oscilloscope если он у Вас включен.
2) Компилируете проект
3) Смотрите Resource Usage Report на вкладке Process -> Synthesize -> Synthesis Report и делаете скриншот. Выкладываете его сюда. И вместе посмотрим на него. Я почему-то абсолютно уверен, что компилятор выбросил почти всё из Вашего проекта и оставил с десяток LUTов которые никак не описывают задуманное Вами.. Если я прав, то Ваш проект не делает то, что Вы хотите. Вам только кажется, что он это делает.
Зря думаете, что я этого не делал, просто после того как чужие сумматоры начали сбоить - я решил не прикреплять скриншоты вообще (поэхтому и сделал всего один - при сборке проекта с моим сумматором), о которых вы говорите, потому что тема публикации по сумматору, а не Gowin EDA.
Скриншот лежит в теле публикации под спойлером - найдите слова
" И вот теперь, как и обещал я выкладываю скриншот ", впрочем, могу и тут
. Читайте свойства файла - там дата модификации файла, создание - это уже как копирование на носители (если что - у меня убунта, но думаю что все ОС читают свойства файлов одинаково). Не забывайте, что проект скомпилирован с файлом GOA и прочими необходимыми для работы с gowin_analyzer_oscilloscope , поэтому увеличен. Если интересуют именно по коду и синтезу - это отдельный вопрос. Подождите воскресенья, я готовлю материал, но теперь учту уже и потребности сомневающихся.
Скриншот с включенным GOA не имеет смысла, так как теперь не понятно сколько же на самом деле занимает в ПЛИС именно Ваш проект - а именно это был мой вопрос и поэтому я специально попросил выключить GOA. Я думаю, что все эти ресурсы, которые показывает сейчас Resource Usage Summary в основном занимает именно GOA. Да, GOA обязательно занимает в ПЛИС ресурсы к сожалению.
Но обязательно учтите, что те сигналы, которые вы исследуете с помощью GOA обязательно нужно вывести на какие-то пины FPGA. В противном случае выключая GOA вы "обнулите" проект - он перестанет вообще хоть что-то делать, а занимаемых ресурсов будет ноль.
С точки зрения компилятора он должен создать "черный ящик", который обрабатывает входные сигналы ПЛИС и выдает логичускую функцию (зависящую от входных сигналов) на выходные пины ПЛИС. Входных сигналов у Вас по видимому нет? Вы же используете внутренний генератор OSC. Если и выходных сигналов ПЛИС не будет определено, то с точки зрения компилятора и логических функций нет вообще и тогда можно вообще ничего не делать.
Поэтому обязательно проект должен выдавать какие-то сигналы на выход.
Философский оффтоп. Когда-то М.Л. Цетлин придумал термин "целесообразное поведение". На предыдущем витке искусственного интеллекта целесообразное поведение описали математически. Представим теперь, что кто-то взял нейросеть и решил её обучить на наследии Черномырдина. Потом, в качестве не гумманитарного (и не гуманного) эксперимента эту нейросеть заставили написать про "сумматор". Как Черномырдин должен реагировать на просьбы? А на конструктивную критику? Какое поведение для Черномырдина является целесообразным?
Я не помню, но скорее всего это результат анализа с отключенным GOA. В субботу проверю. Вроде как отключал файл GOA. Вообще в субботу уже будет новый материал и публикация, только уже с расчетами, потому что теперь к этому всему готов триггер около транзисторного уровня. Буду тестировать все на транзисторном буфере TRI и на bufif1, и сумматор свой и триггер, там действительно будет интересно смотреть анализ схем. В воскресенье вы уже увидите публикацию в лучшем виде и гораздо интереснее, и уже со всеми цифрами, мне например было неинтересно, но один участник как то случайно занизил скорость моего сумматора в 10 000 раз, если осцилятор не достигает частоты гигагерца, пришлось посчитать самому, цифры интересные. Ещё публикация будет интересной потому, что я не буду отвлекаться на составление схем по чужим идеям и домыслам, поясню в воскресенье.
Ваш скриншот точно с включенным GOA.
У вас в исходном тексте verilog, который вы привели в статье нет ни одного настоящего триггера, только RS защелки. А на скриншоте есть DFF триггера (те которые работают по CLK тактовой частоты, то что вы не любите и хотите избавиться от тактирования своей асинхронной логикой) аж 272 штуки. Еще обращайте внимание, сколько встроенной памяти использует проект. К сожалению на скриншоте этого раздела Resource Usage не видно. GOA использует память. А ваш проект нет.
Вы поймите, как работает GOA. Есть проект пользователя, который описывает логику работы нужную пользователю (вашу логику). Если пользователь хочет посмотреть какие-то сигналы в GOA, то в проект принудительно добавляется еще GOA логика+память для захвата сигналов, которые вы хотите посмотреть. Это вообще-то влечет последствия:
1) суммарно весь проект занимает больше ресурсов (дополнительно регистры, LUTы, память)
2) компилятор вынужден трассировать гораздо больше сигналов между логическими элементами FPGA. Может измениться врема прохождения сигналов между логическими элементами LUT.
Для асинхронной логики теоретически изменение времени прохождения сигнала между элементами может оказаться критическим. Хотя, насколько я понимаю, теоретически создатели асинхронных схем стараются делать "самосинхронизирующиеся схемы". Но я честно не понимаю, как это можно сделать. Но я просто хочу, чтоб вы тщательнее проводили свои эксперименты и не занимались самообманом.
Тщательнее смотрите, как работает проект. Если к примеру вы делаете счетчик - так выведите его старшие разряды на светодиоды, чтобы глазами увидеть идет двоичный счет или нет.
Вы пишите про следующие ваши эксприменты на "транзисторном уровне". В FPGA такого нет. Вся логика, которую вы напишите с применением TRI и bufif1 будет упакована компилятором в LUTы. Не обманывайте себя.
Тщательнее смотрите, как работает проект. Если к примеру вы делаете счетчик - так выведите его старшие разряды на светодиоды, чтобы глазами увидеть идет двоичный счет или нет.
уже делал в прошлых публикациях - тут https://habr.com/ru/articles/854562/, никакого самообмана, тем более есть проще способ, которым теперь я и пользуюсь всегда (так как с ним нет необходимости создания файла с распиновкой) - изменить количество любых элементов или вообще закомментировать строку кода или несколько, так что насчёт самообмана не ко мне. По поводу того, что мой проект типа вообще не компилируется - прежде чем подобное заявлять, прежде напишите номер строки, которую мне заблокировать, после чего результат тестбенча останется прежним. И вообще способ комментирования строки или блока строк, или нескольких, а так-же изменения количества циклов, содержания строк - один из самых эффективных при поиске ошибки, если что. Светодиоды полезны для проверки работоспособности собственных триггеров, светодиоды для этого эффективнее тестбенчей. Вы пишите про следующие ваши эксприменты на "транзисторном уровне". В FPGA такого нет. Вся логика, которую вы напишите с применением TRI и bufif1 будет упакована компилятором в LUTы. Не обманывайте себя.
Практика покажет. Я вообще полагаю, что скорее всего будет использован один и тот-же примитив, тот который эффективнее, а синтаксис разный ещё бывает для поддержки версий, если что. Так что причина одинаковых результатов, без подробного изучения - может остаться нераскрытой. Либо, для её выяснения - нужно будет связываться с разработчиком. Поэтому на этот счёт я вообще ничего заявлять не стану.
Удачи.
Вот
https://disk.yandex.ru/d/5YzCZjNCEK0lWQ
Это проект для Gowin IDE в котором установлен ваш код взятый прямиком из этой статьи после "Код всего проекта под спойлером ".
В этом проекте модуль топ это модуль верхнего уровня. В него я установил ваш
TestSummators test(
.out(LED[0]),
.outTime(LED[1]),
.outOsc(LED[2])
);
Выходы вывел на светодиоды.
После компиляции (которая пишет очень много предупреждений о том, что инстансы вычищены из-за оптимизации, is swept in optimizing) я в синтезатора отчете вижу используемые ресурсы (нет GAO):
Как видите, конкретно TestSummators который приведен в этой вашей статье видимо делает очень мало или не делает ничего. Слишком мало занятых ресурсов для логики где generate использует цикл 200 итераций для установки инстансов summatorChane.
Таким образом, либо
1) вы ошибочно привели в статье какой-то другой нерабочий код, либо, что было бы хуже
2) вы сами используете этот код и сильно заблуждаетесь в его работоспособности.
В него я установил ваш
TestSummators test(
.out(LED[0]),
.outTime(LED[1]),
.outOsc(LED[2])
);
Не приписывайте мне свои эксперименты, я никогда не додумался-бы вывести на светодиод даже задержанный сигнал с осцилятора. Это не ко мне.
Как и с остальным. Я так понимаю, что вы даже не пробовали примеры с светодиодами, что находятся по ссылкам на сайте разработчиков и сообщества?
Или я ошибаюсь? Если ошибаюсь, то зачем вы подключаете светодиод к генератору тактов? Хоть и поделенных, но не настолько, чтобы он заработал. Вы в курсе что на плате инвертированные порты светодиодов?
То, что код занимает столько-то, это не ко мне, а к разработчику вопрос. У меня тоже этот код занимает мало, на обоих компьютерах, но это работает. Всегда можно посмотреть во вьювер на результат синтеза. Да там не 700, а 1400 сумматоров даже. Хотя раньше может было и 700, я постоянно увеличиваю нагрузку на плату, пока она не даст сбой. Анализ проекта не всегда выдаёт точный анализ. Я пробовал разные варианты и всё работает. Светодиод вообще и не будет скорее всего работать от таких частот и к своим опытам меня прошу не привлекать и не отнимать на них моё время.
На убунте не запускается не осцилоскоп, ни, следовательно осцилятор. У меня для этих целей миникомпютер. Сейчас посмотрю сколько занимает проект в в окнах. В окнах те-же 23 лута. Но то, что это работает - вне сомнений. А вот ваши диоды и не должны работать - сначала ознакомьтес с примерами и найдите информацию, что они инвертированные. Кроме того, чтобы их подключить нужно ещё использовать Floor Planer, но они от высокой частоты вряд-ли заработают, им нужен или триггер или сигнал типа reg.
Пожалуйста послушайте. Мне не важно, что будет отображаться на светодиодах и будет ли отображаться вообще. Это чисто формальная необходимость вывести из FPGA все выходы исследуемого модуля с целью не допустить, чтобы компилятор выбросил из схемы всю логику, которая создает выходной сигнал.
Этим экспериментом я хочу показать Вам сколько реально занимает Ваш проект в ПЛИС. И видимо почти нисколько. Компилятор практически все выбросил и видимо у него были на это основания - оптимизация логики.
Это то, что я хочу вам объяснить - как работает компилятор для ПЛИС.
Интересно какой отчёт даст Yosys после компиляции того же самого кода. Скорей всего для оптимизации Gowin использует ABC, как и Yosys. Тем временем появился другой (русскоязычный :) оптимизатор
Код выкладываю - ничего не скрываю. Значит вопросы все должны быть адресованы к разработчику платы. Чтобы вводить хоть кого-то в заблуждение - мне нужно что либо скрыть, но у меня всё открыто и доступно для понимания. Часто отвечать не могу, так как мало времени и много задач по его эффективному использованию. Всё в чем есть причина для моих обвинений - это только в том, что у меня всё открыто, а так как это не преступление, то понятно что меня попытаются обвинять даже в грехах разработчика. В следующих публикациях я буду выкладывать больше технической информации, но почти уверен, что буду так же виноват только потому, что делаю это я а не вы, и кроме того - я один, а вас - много. В таких случаях поведения стоит обращаться, для его понимания, к сериалам о дикой природе, в данном случае наверное лучше о обитателях пустынь.
Вся логика, которую вы напишите с применением TRI и bufif1 будет упакована компилятором в LUTы. Не обманывайте себя.
Тут вот один ньанс есть - упакована будет именно элементарная двочиная логика. Вы не замечаете с своими компаньонами, что как-то слишком явно обобщаете уровни? Не находите странным называть элементарную двоичную логику и уравнения - одним уровнем? Разве уравнения функционируют сами по себе? Я сталкиваюсь с трудностями, помимо флейма, поэтому будьте добры.
Тщательнее смотрите
в свою очередь
https://habr.com/ru/articles/866816/#comment_27693988
тоже тщательнее оперировать информацией.
Я обещаю тщательнее проверять результаты, и если обнаружу то, чего быть не должно - уведомить читателя. Цифр я пока, кстати, никаких не приводил по быстродействию, только сравнения - и уж в этом, думаю, ошибки скорее нет, хотя всё может быть. Ах впрочем - а почему вы не напишите людям, о недорабтках среды, которые предлагают её в качестве импортозамещения? В моём коде ошибок нет. Вы этого не заметеили? Почему вы считаете, что мне нельзя проводить на основе свободной среды какие-то исследования, потому что она видите-ли что-то некорректно делает, а другим её можно использовать в качестве товара для импортозамещения и обучения?
В моём коде ошибок нет.
Я прошу прощения, но что вы называете "ошибкой"? Ошибки бывают разные же. Синтаксических ошибок нет. Логических ошибок? Честно сказать я даже не знаю, что конкретно вы пытаетесь реализовать. Если бы в начале Вашей статьи было написано "сейчас мы реализуем это, будет работать так-то", то можно было что-то понять.
По этой причине я даже не критикую содержание проекта и я даже не критикую "асинхронные схемы".
Я рассматриваю ваш проект чисто формально: написано много кода через generate/endgenerate - скомпилировалось в мало LUT - значит не работает так как было задумано.
Почему вы считаете, что есть "недоработки среды"? Компилятор делает то, что должен делать - оптимизацию. Вы можете скомпилировать свой проект в среде Quartus для альтеровского чипа и уверен будет так же.
И да, для микросхем Gowin есть opensource компилятор https://habr.com/ru/articles/808291/. И я абсолютно уверен, что он сделает то же самое - выбросит ненужную логику.
Вы предупреждения компилятора читаете?
module summatorChane (input in, output out);
Trs (,,nil0);
summator s1(nil0,nil0,in,,out1);
summator s2(nil0,out1,nil0,,out2);
summator s3(out2,nil0,nil0,,out3);
У Вас у защелки входы не подключены, а её выход используется. Вы какой сигнал ожидаете на выходе? Конечно такую логику компилятор выкинет. У него других вариантов нет.
У Вас у защелки входы не подключены, а её выход используется. Вы какой сигнал ожидаете на выходе?
Вообще это стабильно давало раньше на выходе сигнал нуля, так как значение на вход не подаётся. Пытался сделать иначе, но как-то не получалось. Попробую. Спасибо за подсказку. с константами проблемно как-то ...долго синтез происходит...И не думал как-то, что компилятор просто может отбросить... У меня компилятор аутировать начинает, если я напишу такое
wire a = 0; Поэтому использовал триггер с защёлки. Всегда смотрел на синтезируемую схему - всё на месте, ну значит откомпилировал как надо - думал я. А как так получается - схема синтезирована соответственно коду, а что-то выброшено? Результат синтеза всегда во вьювере, и он именно и служит для того, чтобы посмотреть что сделал компилятор. Такой вопрос как - схема прорисована во вьювере полностью, согласно коду, я смотрю вьювер - синтез прошёл удачно, а оказывается вообще ничего нету? Хорошо, попробую объявить константу в топ модуле. Видимо для компилятора сложно когда не в топовом. Завтра попробую.
Компилятор всегда выбросит все, что может заранее посчитать.
Если вы напишите
wire [7:0]a; assign a=55;
wire [7:0]b; assign b=1;
wire [7:0]r; assign r=a+b;
Компилятор сразу посчитает, что r=56 и никакого сумматора в итоге не будет. Оптимизация она такая. И это правильно, так и должно быть.
Вот если бы входы сумматора шли из входных сигналов топ модуля, тогда у компилятора нет возможности заранее посчитать и придется оставить все как есть. И второе - если результат нигде не используется и не идет на выходные пины ПЛИС, его так же можно не считать, никому это не нужно. Это тоже будет выброшено.
Оптимизация она такая. И это правильно, так и должно быть.
Неужели? Какая неожиданность! А раз компилятор всё посчитал заранее и такой уимный, то почему с одним экземпляром сумматора результат компиляции на плате работает наормально, а с другим, потом (при увеличении делителя генерируемой схемой частоты) даёт сбой? Всё то-же самое - всё то, что посчитал заранее компилятор - выкинул экземпляры, у которых одни и те-же порты, одна и та-же таблица истинности. Тогда что вдруг становится не правильным в работе правильного компилятора? Что тогда вдруг идёт не так, раз всё заранее посчитано? Вам этот факт не стал заметным прежде чем предъявить мне обвинение в введении окружающих в заблуждениет на таком зыбком основании? Конечно я не рассматриваю обвинение серьёзно, ровно как и защиту компилятора. Получается что если всё глючит и сбоит - так и должно быть! Нет, так быть не должно, и раз уж компилятолор посчитал что всё посчитал - то он и должен выполнить это с одним и тем-же результатом и без сбоев, так как работа сумматоров во всех случаях в данном пректе всегда одинаковая, меняются только их схемы, а таблица истинности и пины - остаются прежними.
1) я не знаю, какую функциональность вы хотите реализовать, из вашей статьи это увы не понятно. Я хочу лишь указать на недостатки в методике вашего проектирования.
2) как вы определяете, что ваш проект работает? Если вы используете GAO, то надеюсь понимаете, как он работает. С помощью GAO нельзя достоверно рассматривать сигналы, которые не тактируются частотой GAO.
Сумматор доработан - добавлено два буфера для задержки, чтобы не возникало в процессе обработки данных ошибки (кратковременная была). Теперь стало видно во что компилирует это компилятор, но на этом не стал зацикливаться (всё равно скоро узнается его фактическая скорость (отдельно сумматора компилируется в два лута)) - главное что компилятор обрабатывает и понимает теперь всё верно. И дело тут не в оказываемом давлении, а просто в последующих шагах - затестил свои новые регистры https://www.cyberforum.ru/blogs/223907/8763.html . Тоже разобраться надо. А сумматоры были доработы в рамках вот этого готовящегося проекта
https://www.cyberforum.ru/blogs/223907/8781.html , коотрый на днях будет уже готов. К сожалению ничего не смог сделать с сокращением регистра - будет компилироваться тоже в два лута. Только сейчас один буфер немного не там (в зиппапке для Logisim один буфер расположен неудачно для компилятора - не стал исправлять, всё пока делается), а стоит так, чтобы на выход переноса выходили только примитивы bufif1, только так компилятор что-то начал распознавать и думаю что это верный путь так делать.
Реализация на плате
https://www.cyberforum.ru/blogs/223907/8822.html . К воскресенью приготовлю нормальный материал.
Небольшая доработка двухлинейного сумматора и счётчика испытательного стенда для сумматоров