Вы можете сами провести простой эксперимент прямо сейчас и прямо дома (если у вас есть дома игровой ПК типа Ryzen).
Просто запустите майнинг Monero на ПК.
Заработать не заработаете, но обогреть бесплатно комнату сможете. В том смысле, что стоимость потраченного электричества может быть компенсирована намайнеными монетами. Я это уже считал. И это можно посчитать на whattomine.com
ПК c Ryzen 9. Хэшрейт 25К/сек, 330Вт, Стоимость электричества 7.3руб/кватчас
Получится даже капелька выгоды и много бесплатного тепла.
1) я не знаю, какую функциональность вы хотите реализовать, из вашей статьи это увы не понятно. Я хочу лишь указать на недостатки в методике вашего проектирования.
2) как вы определяете, что ваш проект работает? Если вы используете GAO, то надеюсь понимаете, как он работает. С помощью GAO нельзя достоверно рассматривать сигналы, которые не тактируются частотой GAO.
Компилятор всегда выбросит все, что может заранее посчитать.
Если вы напишите
wire [7:0]a; assign a=55;
wire [7:0]b; assign b=1;
wire [7:0]r; assign r=a+b;
Компилятор сразу посчитает, что r=56 и никакого сумматора в итоге не будет. Оптимизация она такая. И это правильно, так и должно быть.
Вот если бы входы сумматора шли из входных сигналов топ модуля, тогда у компилятора нет возможности заранее посчитать и придется оставить все как есть. И второе - если результат нигде не используется и не идет на выходные пины ПЛИС, его так же можно не считать, никому это не нужно. Это тоже будет выброшено.
Я прошу прощения, но что вы называете "ошибкой"? Ошибки бывают разные же. Синтаксических ошибок нет. Логических ошибок? Честно сказать я даже не знаю, что конкретно вы пытаетесь реализовать. Если бы в начале Вашей статьи было написано "сейчас мы реализуем это, будет работать так-то", то можно было что-то понять.
По этой причине я даже не критикую содержание проекта и я даже не критикую "асинхронные схемы".
Я рассматриваю ваш проект чисто формально: написано много кода через generate/endgenerate - скомпилировалось в мало LUT - значит не работает так как было задумано.
Почему вы считаете, что есть "недоработки среды"? Компилятор делает то, что должен делать - оптимизацию. Вы можете скомпилировать свой проект в среде Quartus для альтеровского чипа и уверен будет так же.
И да, для микросхем Gowin есть opensource компилятор https://habr.com/ru/articles/808291/. И я абсолютно уверен, что он сделает то же самое - выбросит ненужную логику.
У Вас у защелки входы не подключены, а её выход используется. Вы какой сигнал ожидаете на выходе? Конечно такую логику компилятор выкинет. У него других вариантов нет.
Вы прежде всего вводите в заблуждение себя. Я пытаюсь помочь Вам освободиться от иллюлюзий, но вы к сожалению даже не пытаетесь услышать, что Вам говорят.
Пожалуйста послушайте. Мне не важно, что будет отображаться на светодиодах и будет ли отображаться вообще. Это чисто формальная необходимость вывести из FPGA все выходы исследуемого модуля с целью не допустить, чтобы компилятор выбросил из схемы всю логику, которая создает выходной сигнал.
Этим экспериментом я хочу показать Вам сколько реально занимает Ваш проект в ПЛИС. И видимо почти нисколько. Компилятор практически все выбросил и видимо у него были на это основания - оптимизация логики.
Это то, что я хочу вам объяснить - как работает компилятор для ПЛИС.
После компиляции (которая пишет очень много предупреждений о том, что инстансы вычищены из-за оптимизации, is swept in optimizing) я в синтезатора отчете вижу используемые ресурсы (нет GAO):
Как видите, конкретно TestSummators который приведен в этой вашей статье видимо делает очень мало или не делает ничего. Слишком мало занятых ресурсов для логики где generate использует цикл 200 итераций для установки инстансов summatorChane.
Таким образом, либо
1) вы ошибочно привели в статье какой-то другой нерабочий код, либо, что было бы хуже
2) вы сами используете этот код и сильно заблуждаетесь в его работоспособности.
У вас в исходном тексте verilog, который вы привели в статье нет ни одного настоящего триггера, только RS защелки. А на скриншоте есть DFF триггера (те которые работают по CLK тактовой частоты, то что вы не любите и хотите избавиться от тактирования своей асинхронной логикой) аж 272 штуки. Еще обращайте внимание, сколько встроенной памяти использует проект. К сожалению на скриншоте этого раздела Resource Usage не видно. GOA использует память. А ваш проект нет.
Вы поймите, как работает GOA. Есть проект пользователя, который описывает логику работы нужную пользователю (вашу логику). Если пользователь хочет посмотреть какие-то сигналы в GOA, то в проект принудительно добавляется еще GOA логика+память для захвата сигналов, которые вы хотите посмотреть. Это вообще-то влечет последствия:
1) суммарно весь проект занимает больше ресурсов (дополнительно регистры, LUTы, память)
2) компилятор вынужден трассировать гораздо больше сигналов между логическими элементами FPGA. Может измениться врема прохождения сигналов между логическими элементами LUT.
Для асинхронной логики теоретически изменение времени прохождения сигнала между элементами может оказаться критическим. Хотя, насколько я понимаю, теоретически создатели асинхронных схем стараются делать "самосинхронизирующиеся схемы". Но я честно не понимаю, как это можно сделать. Но я просто хочу, чтоб вы тщательнее проводили свои эксперименты и не занимались самообманом.
Тщательнее смотрите, как работает проект. Если к примеру вы делаете счетчик - так выведите его старшие разряды на светодиоды, чтобы глазами увидеть идет двоичный счет или нет.
Вы пишите про следующие ваши эксприменты на "транзисторном уровне". В FPGA такого нет. Вся логика, которую вы напишите с применением TRI и bufif1 будет упакована компилятором в LUTы. Не обманывайте себя.
Скриншот с включенным GOA не имеет смысла, так как теперь не понятно сколько же на самом деле занимает в ПЛИС именно Ваш проект - а именно это был мой вопрос и поэтому я специально попросил выключить GOA. Я думаю, что все эти ресурсы, которые показывает сейчас Resource Usage Summary в основном занимает именно GOA. Да, GOA обязательно занимает в ПЛИС ресурсы к сожалению.
Но обязательно учтите, что те сигналы, которые вы исследуете с помощью GOA обязательно нужно вывести на какие-то пины FPGA. В противном случае выключая GOA вы "обнулите" проект - он перестанет вообще хоть что-то делать, а занимаемых ресурсов будет ноль.
С точки зрения компилятора он должен создать "черный ящик", который обрабатывает входные сигналы ПЛИС и выдает логичускую функцию (зависящую от входных сигналов) на выходные пины ПЛИС. Входных сигналов у Вас по видимому нет? Вы же используете внутренний генератор OSC. Если и выходных сигналов ПЛИС не будет определено, то с точки зрения компилятора и логических функций нет вообще и тогда можно вообще ничего не делать.
Поэтому обязательно проект должен выдавать какие-то сигналы на выход.
1) Вы в своем проекте выключаете Gowin Analizer Oscilloscope если он у Вас включен.
2) Компилируете проект
3) Смотрите Resource Usage Report на вкладке Process -> Synthesize -> Synthesis Report и делаете скриншот. Выкладываете его сюда. И вместе посмотрим на него. Я почему-то абсолютно уверен, что компилятор выбросил почти всё из Вашего проекта и оставил с десяток LUTов которые никак не описывают задуманное Вами.. Если я прав, то Ваш проект не делает то, что Вы хотите. Вам только кажется, что он это делает.
Вообще складывается впечатление, что данная плата живёт какой-то своей жизнью
Просто то, что вы пытаетесь сделать врядли может быть сделано вообще. И оно фактически работает совсем не так как вы думаете. Вы думаете, что что-то там оптимизируете используя логические элементы типа not, xor,bufif1, а фактически компилятор всё равно всё это упаковывает в LUTы как сможет.
Что насчёт интернета, который на 85% (или больше) состоит из цифрового мусора?
Даже "нужные" сайты типа github могут хранить несчетное число цифрового мусора. Это сотни и тысячи форков разных проектов с минимальными изменениями и своими добавленными багами. Или ПО, которое выглядит рабочим, а на самом деле уже давно нет (например использует библиотеки, которые уже не поддерживаются, или АПИ используемых библиотек изменилось и проект просто нельзя собрать).
Мне уже разъяснили. Как я понял, это трюк ПЛИСоводов. Ограничить сигнал с АЦП до -127 не допуская значения -128 (saturation). В этом случае при перемножении никогда не возникнет переполнение и действительно можно снизить разрядность входного сигнала на один бит, а значит далее сэкономить ресурсы в CIC фильтре.
Если ООО работает по УСН Д-Р, при выплате дивидендов единственному учредителю какие еще налоги платятся, кроме НДФЛ? Налог на прибыль? Есть смысл выплатить дивидендами или проще зарплатой? Где меньше налоги?
Причём баг этот наблюдается что в Windows, что в Linux, и побеждается одним и тем‑же способом, надеемся, что разработчики победят его тоже.
Обычно, когда думаешь, что где-то в компиляторе баг, то скорее всего это не баг, а собственное непонимание происходящего.
У Вас в проекте какой модуль является модулем самого верхнего уровня?
Например, это pprobe1
Если вы к выходу этого модуля из модуля подключаете какой-то сигнал, то какой-то конкретный вывод микросхемы FPGA станет выходом этого сигнала. Вы можете либо сами назначить номер вывода микросхемы, либо компилятор выберет вывод произвольным образом (посмотрите отчет фиттера, какие выводы используются). А если вы не делаете присвоения выходу модуля, то вообще-то компилятор вправе вообще выбросить всю эту логику. У вас от выбрасывания этой логики спасает только GAO - внутрисхемный отладчик (который вы почему-то называете тестбенчем). Отключите отладчик и ваш проект станет занимать ноль ресурсов, абсолютно всё будет выброшено компилятором.
И еще замечание по поводу GAO. Вы захватываете сигналы на частоте oscout, правильно? Вы понимаете, что таким способом можно увидеть только процессы, которые как минимум в 2 раза ниже по частоте, чем oscout?
Посчитаем - тактовая частота платы 27 МГц, она увеличивается осцилятором в 100 раз, получается 2700 МГц или 2.7ГГц
Откуда вы такое взяли? Вы используете компонент Gowin_osc? Так это встроенный в FPGA генератор. Во-первых, он никак не связан с тактовой частотой платы. У него фиксированная частота (около 210 или 250МГц зависит от типа микросхемы) и умножать он не может. Может только делить. Например, на 100.
За уголь надо платить, а стоимость электричества компенсируется намайненными монетами.
Вы можете сами провести простой эксперимент прямо сейчас и прямо дома (если у вас есть дома игровой ПК типа Ryzen).
Просто запустите майнинг Monero на ПК.
Заработать не заработаете, но обогреть бесплатно комнату сможете. В том смысле, что стоимость потраченного электричества может быть компенсирована намайнеными монетами. Я это уже считал. И это можно посчитать на whattomine.com
ПК c Ryzen 9. Хэшрейт 25К/сек, 330Вт, Стоимость электричества 7.3руб/кватчас
Получится даже капелька выгоды и много бесплатного тепла.
Без которых не будет работать всякое российское ПО типа личный кабинет налогоплательщика юр лица и прочее.
1) я не знаю, какую функциональность вы хотите реализовать, из вашей статьи это увы не понятно. Я хочу лишь указать на недостатки в методике вашего проектирования.
2) как вы определяете, что ваш проект работает? Если вы используете GAO, то надеюсь понимаете, как он работает. С помощью GAO нельзя достоверно рассматривать сигналы, которые не тактируются частотой GAO.
Компилятор всегда выбросит все, что может заранее посчитать.
Если вы напишите
wire [7:0]a; assign a=55;
wire [7:0]b; assign b=1;
wire [7:0]r; assign r=a+b;
Компилятор сразу посчитает, что r=56 и никакого сумматора в итоге не будет. Оптимизация она такая. И это правильно, так и должно быть.
Вот если бы входы сумматора шли из входных сигналов топ модуля, тогда у компилятора нет возможности заранее посчитать и придется оставить все как есть. И второе - если результат нигде не используется и не идет на выходные пины ПЛИС, его так же можно не считать, никому это не нужно. Это тоже будет выброшено.
В моём коде ошибок нет.
Я прошу прощения, но что вы называете "ошибкой"? Ошибки бывают разные же. Синтаксических ошибок нет. Логических ошибок? Честно сказать я даже не знаю, что конкретно вы пытаетесь реализовать. Если бы в начале Вашей статьи было написано "сейчас мы реализуем это, будет работать так-то", то можно было что-то понять.
По этой причине я даже не критикую содержание проекта и я даже не критикую "асинхронные схемы".
Я рассматриваю ваш проект чисто формально: написано много кода через 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);
У Вас у защелки входы не подключены, а её выход используется. Вы какой сигнал ожидаете на выходе? Конечно такую логику компилятор выкинет. У него других вариантов нет.
Чтобы вводить хоть кого-то в заблуждение..Вы прежде всего вводите в заблуждение себя. Я пытаюсь помочь Вам освободиться от иллюлюзий, но вы к сожалению даже не пытаетесь услышать, что Вам говорят.
Пожалуйста послушайте. Мне не важно, что будет отображаться на светодиодах и будет ли отображаться вообще. Это чисто формальная необходимость вывести из FPGA все выходы исследуемого модуля с целью не допустить, чтобы компилятор выбросил из схемы всю логику, которая создает выходной сигнал.
Этим экспериментом я хочу показать Вам сколько реально занимает Ваш проект в ПЛИС. И видимо почти нисколько. Компилятор практически все выбросил и видимо у него были на это основания - оптимизация логики.
Это то, что я хочу вам объяснить - как работает компилятор для ПЛИС.
Вот
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) вы сами используете этот код и сильно заблуждаетесь в его работоспособности.
Ваш скриншот точно с включенным GOA.
У вас в исходном тексте verilog, который вы привели в статье нет ни одного настоящего триггера, только RS защелки. А на скриншоте есть DFF триггера (те которые работают по CLK тактовой частоты, то что вы не любите и хотите избавиться от тактирования своей асинхронной логикой) аж 272 штуки. Еще обращайте внимание, сколько встроенной памяти использует проект. К сожалению на скриншоте этого раздела Resource Usage не видно. GOA использует память. А ваш проект нет.
Вы поймите, как работает GOA. Есть проект пользователя, который описывает логику работы нужную пользователю (вашу логику). Если пользователь хочет посмотреть какие-то сигналы в GOA, то в проект принудительно добавляется еще GOA логика+память для захвата сигналов, которые вы хотите посмотреть. Это вообще-то влечет последствия:
1) суммарно весь проект занимает больше ресурсов (дополнительно регистры, LUTы, память)
2) компилятор вынужден трассировать гораздо больше сигналов между логическими элементами FPGA. Может измениться врема прохождения сигналов между логическими элементами LUT.
Для асинхронной логики теоретически изменение времени прохождения сигнала между элементами может оказаться критическим. Хотя, насколько я понимаю, теоретически создатели асинхронных схем стараются делать "самосинхронизирующиеся схемы". Но я честно не понимаю, как это можно сделать. Но я просто хочу, чтоб вы тщательнее проводили свои эксперименты и не занимались самообманом.
Тщательнее смотрите, как работает проект. Если к примеру вы делаете счетчик - так выведите его старшие разряды на светодиоды, чтобы глазами увидеть идет двоичный счет или нет.
Вы пишите про следующие ваши эксприменты на "транзисторном уровне". В FPGA такого нет. Вся логика, которую вы напишите с применением TRI и bufif1 будет упакована компилятором в LUTы. Не обманывайте себя.
Скриншот с включенным GOA не имеет смысла, так как теперь не понятно сколько же на самом деле занимает в ПЛИС именно Ваш проект - а именно это был мой вопрос и поэтому я специально попросил выключить GOA. Я думаю, что все эти ресурсы, которые показывает сейчас Resource Usage Summary в основном занимает именно GOA. Да, GOA обязательно занимает в ПЛИС ресурсы к сожалению.
Но обязательно учтите, что те сигналы, которые вы исследуете с помощью GOA обязательно нужно вывести на какие-то пины FPGA. В противном случае выключая GOA вы "обнулите" проект - он перестанет вообще хоть что-то делать, а занимаемых ресурсов будет ноль.
С точки зрения компилятора он должен создать "черный ящик", который обрабатывает входные сигналы ПЛИС и выдает логичускую функцию (зависящую от входных сигналов) на выходные пины ПЛИС. Входных сигналов у Вас по видимому нет? Вы же используете внутренний генератор OSC. Если и выходных сигналов ПЛИС не будет определено, то с точки зрения компилятора и логических функций нет вообще и тогда можно вообще ничего не делать.
Поэтому обязательно проект должен выдавать какие-то сигналы на выход.
У меня следующее предложение.
1) Вы в своем проекте выключаете Gowin Analizer Oscilloscope если он у Вас включен.
2) Компилируете проект
3) Смотрите Resource Usage Report на вкладке Process -> Synthesize -> Synthesis Report и делаете скриншот. Выкладываете его сюда. И вместе посмотрим на него. Я почему-то абсолютно уверен, что компилятор выбросил почти всё из Вашего проекта и оставил с десяток LUTов которые никак не описывают задуманное Вами.. Если я прав, то Ваш проект не делает то, что Вы хотите. Вам только кажется, что он это делает.
Вообще складывается впечатление, что данная плата живёт какой-то своей жизнью
Просто то, что вы пытаетесь сделать врядли может быть сделано вообще. И оно фактически работает совсем не так как вы думаете. Вы думаете, что что-то там оптимизируете используя логические элементы типа not, xor,bufif1, а фактически компилятор всё равно всё это упаковывает в LUTы как сможет.
Что насчёт интернета, который на 85% (или больше) состоит из цифрового мусора?
Даже "нужные" сайты типа github могут хранить несчетное число цифрового мусора. Это сотни и тысячи форков разных проектов с минимальными изменениями и своими добавленными багами. Или ПО, которое выглядит рабочим, а на самом деле уже давно нет (например использует библиотеки, которые уже не поддерживаются, или АПИ используемых библиотек изменилось и проект просто нельзя собрать).
Мне уже разъяснили. Как я понял, это трюк ПЛИСоводов. Ограничить сигнал с АЦП до -127 не допуская значения -128 (saturation). В этом случае при перемножении никогда не возникнет переполнение и действительно можно снизить разрядность входного сигнала на один бит, а значит далее сэкономить ресурсы в CIC фильтре.
Правильно я понял?
Вы правы.
Я уже раздумываю, как улучшить эту часть проекта.
Если ООО работает по УСН Д-Р, при выплате дивидендов единственному учредителю какие еще налоги платятся, кроме НДФЛ? Налог на прибыль? Есть смысл выплатить дивидендами или проще зарплатой? Где меньше налоги?
Хм.. а почему?
Причём баг этот наблюдается что в Windows, что в Linux, и побеждается одним и тем‑же способом, надеемся, что разработчики победят его тоже.Обычно, когда думаешь, что где-то в компиляторе баг, то скорее всего это не баг, а собственное непонимание происходящего.
У Вас в проекте какой модуль является модулем самого верхнего уровня?
Например, это
pprobe1Если вы к выходу этого модуля из модуля подключаете какой-то сигнал, то какой-то конкретный вывод микросхемы FPGA станет выходом этого сигнала. Вы можете либо сами назначить номер вывода микросхемы, либо компилятор выберет вывод произвольным образом (посмотрите отчет фиттера, какие выводы используются). А если вы не делаете присвоения выходу модуля, то вообще-то компилятор вправе вообще выбросить всю эту логику. У вас от выбрасывания этой логики спасает только GAO - внутрисхемный отладчик (который вы почему-то называете тестбенчем). Отключите отладчик и ваш проект станет занимать ноль ресурсов, абсолютно всё будет выброшено компилятором.
И еще замечание по поводу GAO. Вы захватываете сигналы на частоте oscout, правильно? Вы понимаете, что таким способом можно увидеть только процессы, которые как минимум в 2 раза ниже по частоте, чем oscout?
Посчитаем - тактовая частота платы 27 МГц, она увеличивается осцилятором в 100 раз, получается 2700 МГц или 2.7ГГцОткуда вы такое взяли?
Вы используете компонент Gowin_osc? Так это встроенный в FPGA генератор. Во-первых, он никак не связан с тактовой частотой платы. У него фиксированная частота (около 210 или 250МГц зависит от типа микросхемы) и умножать он не может. Может только делить. Например, на 100.
Это написано в документации на микросхемы Gowin https://cdn.gowinsemi.com.cn/UG286E.pdf
На странице 104.