Тщательнее смотрите, как работает проект. Если к примеру вы делаете счетчик - так выведите его старшие разряды на светодиоды, чтобы глазами увидеть идет двоичный счет или нет.
уже делал в прошлых публикациях - тут https://habr.com/ru/articles/854562/, никакого самообмана, тем более есть проще способ, которым теперь я и пользуюсь всегда (так как с ним нет необходимости создания файла с распиновкой) - изменить количество любых элементов или вообще закомментировать строку кода или несколько, так что насчёт самообмана не ко мне. По поводу того, что мой проект типа вообще не компилируется - прежде чем подобное заявлять, прежде напишите номер строки, которую мне заблокировать, после чего результат тестбенча останется прежним. И вообще способ комментирования строки или блока строк, или нескольких, а так-же изменения количества циклов, содержания строк - один из самых эффективных при поиске ошибки, если что. Светодиоды полезны для проверки работоспособности собственных триггеров, светодиоды для этого эффективнее тестбенчей. Вы пишите про следующие ваши эксприменты на "транзисторном уровне". В FPGA такого нет. Вся логика, которую вы напишите с применением TRI и bufif1 будет упакована компилятором в LUTы. Не обманывайте себя.
Практика покажет. Я вообще полагаю, что скорее всего будет использован один и тот-же примитив, тот который эффективнее, а синтаксис разный ещё бывает для поддержки версий, если что. Так что причина одинаковых результатов, без подробного изучения - может остаться нераскрытой. Либо, для её выяснения - нужно будет связываться с разработчиком. Поэтому на этот счёт я вообще ничего заявлять не стану.
Я не помню, но скорее всего это результат анализа с отключенным GOA. В субботу проверю. Вроде как отключал файл GOA. Вообще в субботу уже будет новый материал и публикация, только уже с расчетами, потому что теперь к этому всему готов триггер около транзисторного уровня. Буду тестировать все на транзисторном буфере TRI и на bufif1, и сумматор свой и триггер, там действительно будет интересно смотреть анализ схем. В воскресенье вы уже увидите публикацию в лучшем виде и гораздо интереснее, и уже со всеми цифрами, мне например было неинтересно, но один участник как то случайно занизил скорость моего сумматора в 10 000 раз, если осцилятор не достигает частоты гигагерца, пришлось посчитать самому, цифры интересные. Ещё публикация будет интересной потому, что я не буду отвлекаться на составление схем по чужим идеям и домыслам, поясню в воскресенье.
Зря думаете, что я этого не делал, просто после того как чужие сумматоры начали сбоить - я решил не прикреплять скриншоты вообще (поэхтому и сделал всего один - при сборке проекта с моим сумматором), о которых вы говорите, потому что тема публикации по сумматору, а не Gowin EDA.
Скриншот лежит в теле публикации под спойлером - найдите слова
" И вот теперь, как и обещал я выкладываю скриншот ", впрочем, могу и тут
. Читайте свойства файла - там дата модификации файла, создание - это уже как копирование на носители (если что - у меня убунта, но думаю что все ОС читают свойства файлов одинаково). Не забывайте, что проект скомпилирован с файлом GOA и прочими необходимыми для работы с gowin_analyzer_oscilloscope , поэтому увеличен. Если интересуют именно по коду и синтезу - это отдельный вопрос. Подождите воскресенья, я готовлю материал, но теперь учту уже и потребности сомневающихся.
То что делаю я - как раз работает без сбоев. А вот аналоги других, с той же таблицей истинности (всего три входа и два выхода) - дают сбои на испытательном стенде. И при меньшей нагрузке на плату, некоторые решения других - работали, так что Вы всё перепутали. Для людей я оставлял текст, что отвечу на вопросы, но вот вы просто все искажаете действительный порядок вещей, поэтому тоже это отметить надо.
. Никаких XOR3. А вот когда я уже буду делать на его базе триггер - тогда уже адаптирую уравнения под удобное применение, а до того вообще не надо было, как и до вот этого
В воскресенье ради интереса потестирую.
Уравнения конечно применю, но только когда начну триггер создавать на базе сумматора, и то уравнения адаптированные будут, в том виде, когда они дают вот такой разультат
они вообще не нужны, разве что голову поморочить тому кто их знает. А вот адаптировать - будет полезным, так как много там (в методах уравнений) вещей интересных. А пока что - не применялось мной в программировании и схемотехнике.
Для выхода суммы в Вашей схеме после минимизации НЕ получилось ожидаемое XOR3.
Это вовсе не означает что в моей схеме ошибка.
Доверять можно и нужно уравнениям.
А никто и не говорил что им не доверяет, просто я знаю что описание схемы в структурном виде так и синтезирует схему, такой, какая она есть, и мне это и нужно.
Это самый низкий уровень программирования. Относится ли он к структурному стилю Verilog или нет - не важно, а важно то, что это точная настройка.
Нет это важно. Я не делаю проект для FPGA, я делаю свою архитектуру, поэтому это важно, и в данном случае для меня и является самым низким уровнем программирования - именно описание в структурном виде на уровне винтелей (переходить к уровню транзисторов не вижу смысла, хотя и этот вид немного у меня присутствует в виде электронных ключей или так называемых буферов трёх состояний), которое я смогу переносить на любую плату любого производителя - раз, и которое при синтезе не изменит первоначальной схемы - два.
Кроме того, тот уровень, о котором Вы говорите не является самым низким, никак, так как самый низкий вероятно будет верхний в следующем списке, приведено из книги
В общем случае язык Verilog позволяет выполнять описание проектов на следующих уровнях:
транзисторов;
вентилей;
логических уравнений;
регистровых передач (register transfer level- RTL);
поведенческом (behaviorial);
структурном (системном).
Так вот всё что я сделал - назвал стиль описания видом описания (структурный стиль описания и структурный уровень - не одно и то же), поскольку предпочтения тут не при чём и вопрос чисто технический. Вид описания у меня структурный, а уровень - вентильный. Так что Ваша помощь далеко таковой не является, не нужно никого вводить в заблуждение.
Вы не обратили на это внимания.
Я не обращаю внимание на малозначимые моменты (лучше сосредоточить внимание на ключевых местах), я достаточно внимательно отслеживаю поток ваших сообщений. Вам не нужно мне "помгать", лучше помогите (без кавычек) своим ближним. Мне помогут книги, как и в этот раз.
Да, я не знал о том, что можно прикреплять картинки.
Не только об этом. Причём даже с нескольких раз Вы не перестаёте не знать.
Потому что я нашёл ошибку в Вашей схеме и исправил её.
В моей схеме нет никакой ошибки, она проверена в симуляторе и на самом FPGA, про ошибку это ваши фантазии и за них разумеется никаких спасибо Вы не дождётесь. Моя схема как была без ошибки до вашего появления - так и осталась без неё, никто вам не давал доступа к редактированию моей публикации тем более схемы. Я жду от вас именно того, на что вы заявляете с своими уравнениями, и при этом прошу учитывать вас вот этот ваш комментарий
Во что компилируются условные обозначения элементов этой схемы, в LUT или в элемент XOR с мультиплексором 2:1?
, который даёт понять. что вы не знаете что и во что компилирует компилятор. Доношу до Вас в очередной раз, в надежде быть услышанным : структурный вид описания (схему) компилятор не переделывает никак при синтезе, и синтезирует её именно в том виде - в виде схемы, со всеми теми элементами и проводами, как она описана (схема в тектстовом виде), в то время, как все другие виды описания компилятор уже переводит на язык описания схем при синтезе, причём переводит согласно логике в него заложенной разработчиками, в то время как структурное описание остаётся однозначным и не искажается и не изменяется никак (какой схема была до синтеза - такой она останется и после, без каких либо изменений).
Заранее спасибо за понимание, если конечно оно возможно вообще, в Вашем случае.
В заголовке появилось слово "надёжный".Что ж, проверим. Как? Минимизацией.Обозначим a=term2; c=term1; b=intransfer;Тогда два элемента XOR это - d=a^b; e=a^c;Что такое маленькие треугольнички?Буферы с выходом в третье состояние? Нет.Их нельзя соединять по выходу. Это ключи.А значит имеем два мультиплексора,которые дают sum=!be+be; carry=!da+dc;Минимизируем и получаемsum = !a*c+a*!c; carry = a*b+a*c+b*c;Перенос правильный, сумма - неправильная.Как исправить?Вот так: d=a^b; e=!(a^b); sum=!c*d+c*e; carry=!d*a+d*c;И чем это лучше встроенного сумматораd=a^b; sum=d^c; carry=!d*a+d*c ???
Раз уж вы говорите о чем-то конкретном, то и опишите это в том-же виде стиле , на который заявляете, и повторите в симуляторе. Поэтому будьте добры - не надо заявлять, что нечто с крышею это тоже дом. Да у него есть крыша, но много чего не подтверждено, и нет уверенности что с первым паводком это не уплывёт как шалаш, как любят говорить о таких видах описания - "не известно во что это изложит компилятор". Это не мои слова - "неизвестно во что это откомпилирует компилятор", причём говорилось это именно о структурном виде описания, который ккомпилятор компилирует как раз именно точь в точь элемент к элементу, а провод к проводу. К тому-же ваши называния полноценного симулятора аниматором вообще не располагают доверять вам на слово. И именно поэтому я ещё и проверю вашу схему в симуляторе сам. Как только вы предоставите схему. Надеюсь, что симулятор вы назвали аниматором по ошибке, поэтому жду от вас схемы. На словах знаете - все мастаки, а как дела касается, так всё - оказывается не работает. Минусы не надо ставить - нужна рабочая схема, и желательно в симуляторе, и желательно чтобы материал был в том виде, как и у меня (анимированный), чтобы сразу все видели о чём вы говорите. А ваши слова не надежны, со слов ваших же коллег - "неизвестно во что это откомпилирует компилятор".
Всё это делает Вашу схему избыточной, а правильнее сказать, бессмысленной.
я сделал рабочую схему.
Сумматор с минимальной задержкой получится, если ...
Я нисколько не мешаю сделать это другим. Извините, у меня не так много времени, чтобы проверять чужие работы, которыми, к тому же, я даже не планирую воспользоваться.
Мной двигала идея скорости работы, а не простоты. Тут нужно проводить тестбенчи. Их мне удалось провести только один раз , пока что, потом всё как с поломанным телефоном. Перевод в состояние Z , насколько мне известно, например у электронного ключа, состоящего всего из одного транзистора и имеющего точно такую таблицу истинности как у логического элемента bufif1, то же самое что состояние "закрыто", то есть задержка - время рассасывания заряда базы биполярного транзистора- если используются они. Вообще не хотелось бы заниматься гипотезами, на фоне отсутствия хорошей литературы, могущей дать быстро нужный ответ, поэтому лучше практика. Не берусь утверждать любую точку зрения, потому что даже вся литература, мной приобретенная, включая искусство схемотехники - однозначного ответа не даст, всё не перечитал, но "ключевые" моменты изучил все в каждой. Поэтому предпочитаю говорить о практике с точки зрения именно практической. Тест бенчи будут, возможно на выходных я просто проведу их для всех логических элементов, но вот в целостности платы уверенности нет пока что, поэтому я не смогу дать быстро нужный ответ на замечание. У меня нет никакой абсолютной уверенности, мной движет только личный опыт решения разных задач и желание создания процессора своей архитектуры (стоит отметить, что например на поиск решения для альтернативы сверхточных нейросетей у меня ушло не мало времени-годы, но вдохновляла важность задачи, да и самих таковых), публикация не носит характера туториала. Поэтому это всё, что пока что могу.
С стандартными реализациями я знаком, и если вы переходили по ссылке что давал я, и даже по той, что дали мне вы - вы должны были увидеть схему (она есть тут - выглядит как паравоз), которую я тоже сравнивал на быстродействие с своей (вообще я две версии с своей сравнивал), и там где нет инвертора тоже, и это в семь раз медленнее моего (как минимум схема без инвертора, с инвертором схема ещё медленнее, а у меня задача разбита на две параллельных). А знаете почему? Потому что схема не последовательная. Вы сами пишите комментарии не читая чужих материалов. Что касается меня, то с гуглом я дружу вполне, схему по вашей же ссылке не читали только вы сами, я читал. О расточительности я сужу по быстродействию. К тому-же у меня всего два логических элемента кроме двух инверторов, и они - параллельно подключены, образуя две линии.
И у меня - всё получилось. Мнения вашего круга мне зорошо известны, его члены сами в сети и в радиожурналах часто отмечались, высказывая их. То что я не дулаю публикации - не значит что у меня ничего не получилось, просто на базе части своего сумматора я пытаюсь создать RS триггер асинхронный. Если создание триггера окажется слишком тяжёлым - то вероятно я выложу сумматор отдельной публикацией, если не завтра, то послезавтра, с тестбенчами (без инвертора в семь раз медленнее, а стнадартный - он же по вашей ссылке, но с инверторами - и того больше). Так что вы можете сильно не стараться с уничижениями, я просто пытаюсь потратить свои вечера на новый триггер, который будет ещё быстрее, ну или должен быть, так как не факт что он у меня получится.
То что у меня не получилось - я слушу со времени создания своего генератора карт, который почти в квадрат числа (где числом описывается объём работы при расчётоах карты) превосходит по быстродействию традиционный алгоритм, который мне предлагали, заявляя что мой никогда не заработает. Но увы - он заработал, и тогда заявлявшие заявили следующее - "это ТЗ тупое - карты не эффективны", ну разумеется, для котого-то и книги - ерунда, и учебники, тут убеждать бесполезно в обратном ваш круг. Так что я знаком не только с мнениями вашего круга, но и с его деятельностью в обществе. Очень хорошо знаком.
Спасибо за подсказку, но поблема в том, что баг есть, и представлений схемы при его возникновении не два, а три (с уточнением того, что нормальное представление возникает только если создать ненужный выход с модуля и кинуть на него провод, который всё портит), и если сделать тестбенч баганутого компиляцией кода, то он работает, но со скоростью в два раза меньшей чем при нормальной компиляции. Я это всегда упоминал. Сделал как вы советуете - да, это работает, но баг - остаётся, если не поступить как я описывал. Прошу прощения, но могу отвечать только раз в сутки, и к тому-же сильно занят.
Я его ещё не описывал на языке программирования, поэтому не знаю во что он компилируется, тем более он мной описываться будет по готовой схеме и в структурном виде, поэтому скомпилируется в то, что вы видите на схеме в анимированной симуляции. Да , модуль выполняющий функцию сумматора есть, но он не такой как этот. Сумматор протестирован на работоспособность в симуляторе. По части размытого определения , одинакового быстродействия и всего остального скажу, что тест бенчи выложу на выходных и многословным не буду. Скажу только что знаю наверняка - я делаю схемы в структурном виде описания. Преимущественно это так.
Учёные - это те кто делают открытия, а обнаруживают - те кто хотели бы ими стать, в данном ракурсе последних стоит отнести к списку "не думали", а в ракурсе отрезка времени оного опыта - не будут и в будущем, так как удовлетворены чином даваемым им молвой.
Ещё вчера дполнил публикацию. Всё будет сделано точно так-же как и до этого, потому что это проверано было и ранее, пол-года назад, на совсем другом коде и без осцилятора - баг был, просто как его обойти придумал только недавно, так как и времени-то особо не было тоже. Ничего сложного, спасибо за рекомндации, может кому-то помогут. Ваша помощь наверняка кому-то нужна.
У триггеров есть вход и есть сброс, иначе никаких полных циклов-бы не было. Меня больше интересует теперь тайминг сброса. Что касается мнений про баг - я всё сказал, строка номер 19 всё меняет, компилятору не хватает абстрактного "взгляда" на синтезируемую схему, привязка массива проводов к выходу (даже если он не нужен )позволяет исправить проблему. Если кто-то знает причину более точно - попробуйте, я сделал как считал нужным согласно своей логике и это решило проблему. На эксперименты и проверки рекомендуемые со стороны - у меня к сожалению нет времени. Но тем не менее - всем спасибо.
Могу сказать только, что с АЛУ я выложу тестбенчи сброса цепи таких триггеров, только это не простая задача, так как в отличии от установки значения единицы - прийдётся задействовать цепи логических элементов, высчитывать их скорость, и только потом вычислять скорость сброса триггера. Проблема в том, что прийдётся лепить пары элементов NOT , или одиночными XOR (в общем тут подумать надо, скорее вообще эхлемент AND или жлектпонный ключ bufif), между триггерами, высчитать их скорость (наверное всё-же отдельной цепью), и потом сделать новую цепь для вычисления скорости сброса, или попробовать одной новой цепью всё.
Всё будет через пару-тройку часов. Могу сказать одно - мой успех меня опечаливает. Почему? Потому что цифры неожиданные, хоть и верные, слишком несерьёзно относился и не ожидал что так можно. Второй фактор - в то время, как кто-то пиарится на альтернативах западным FPGA - мне приходится побеждать баги в средах разработки, которые они не стесняются рекомендовать российским пользователям для обучения. Я не думаю, что они не знали - мне не понятно: они хотят денег за свои победы над багами, или не совершили ещё ни одной...всё это уныло. Ну запись я не стану конечно делать в таком жанре - просто приведу баг (а он достаточно серьёзный, с таким я не осмелился бы рекомендовать среду для обучения в российских вузах), и то как он нейтрализуется. Ну и цифры. А следующим уже (через один) - будет АЛУ нового типа и его тестбенчи (тут я не уверен что у меня получится успешный АЛУ, но всё-же на фоне асинхронной логики просматриваются иные архитектуры, поэтому всё может быть).
уже делал в прошлых публикациях - тут https://habr.com/ru/articles/854562/, никакого самообмана, тем более есть проще способ, которым теперь я и пользуюсь всегда (так как с ним нет необходимости создания файла с распиновкой) - изменить количество любых элементов или вообще закомментировать строку кода или несколько, так что насчёт самообмана не ко мне. По поводу того, что мой проект типа вообще не компилируется - прежде чем подобное заявлять, прежде напишите номер строки, которую мне заблокировать, после чего результат тестбенча останется прежним. И вообще способ комментирования строки или блока строк, или нескольких, а так-же изменения количества циклов, содержания строк - один из самых эффективных при поиске ошибки, если что. Светодиоды полезны для проверки работоспособности собственных триггеров, светодиоды для этого эффективнее тестбенчей. Вы пишите про следующие ваши эксприменты на "транзисторном уровне". В FPGA такого нет. Вся логика, которую вы напишите с применением TRI и bufif1 будет упакована компилятором в LUTы. Не обманывайте себя.
Практика покажет. Я вообще полагаю, что скорее всего будет использован один и тот-же примитив, тот который эффективнее, а синтаксис разный ещё бывает для поддержки версий, если что. Так что причина одинаковых результатов, без подробного изучения - может остаться нераскрытой. Либо, для её выяснения - нужно будет связываться с разработчиком. Поэтому на этот счёт я вообще ничего заявлять не стану.
Удачи.
Я не помню, но скорее всего это результат анализа с отключенным GOA. В субботу проверю. Вроде как отключал файл GOA. Вообще в субботу уже будет новый материал и публикация, только уже с расчетами, потому что теперь к этому всему готов триггер около транзисторного уровня. Буду тестировать все на транзисторном буфере TRI и на bufif1, и сумматор свой и триггер, там действительно будет интересно смотреть анализ схем. В воскресенье вы уже увидите публикацию в лучшем виде и гораздо интереснее, и уже со всеми цифрами, мне например было неинтересно, но один участник как то случайно занизил скорость моего сумматора в 10 000 раз, если осцилятор не достигает частоты гигагерца, пришлось посчитать самому, цифры интересные. Ещё публикация будет интересной потому, что я не буду отвлекаться на составление схем по чужим идеям и домыслам, поясню в воскресенье.
Зря думаете, что я этого не делал, просто после того как чужие сумматоры начали сбоить - я решил не прикреплять скриншоты вообще (поэхтому и сделал всего один - при сборке проекта с моим сумматором), о которых вы говорите, потому что тема публикации по сумматору, а не Gowin EDA.
Скриншот лежит в теле публикации под спойлером - найдите слова
" И вот теперь, как и обещал я выкладываю скриншот ", впрочем, могу и тут
. Читайте свойства файла - там дата модификации файла, создание - это уже как копирование на носители (если что - у меня убунта, но думаю что все ОС читают свойства файлов одинаково). Не забывайте, что проект скомпилирован с файлом GOA и прочими необходимыми для работы с gowin_analyzer_oscilloscope , поэтому увеличен. Если интересуют именно по коду и синтезу - это отдельный вопрос. Подождите воскресенья, я готовлю материал, но теперь учту уже и потребности сомневающихся.
То что делаю я - как раз работает без сбоев. А вот аналоги других, с той же таблицей истинности (всего три входа и два выхода) - дают сбои на испытательном стенде. И при меньшей нагрузке на плату, некоторые решения других - работали, так что Вы всё перепутали. Для людей я оставлял текст, что отвечу на вопросы, но вот вы просто все искажаете действительный порядок вещей, поэтому тоже это отметить надо.
tangnano 9k
Естесственное сокращение сумматора
https://www.cyberforum.ru/blogs/223907/blog8733.html
. Никаких XOR3. А вот когда я уже буду делать на его базе триггер - тогда уже адаптирую уравнения под удобное применение, а до того вообще не надо было, как и до вот этого
В воскресенье ради интереса потестирую.
Уравнения конечно применю, но только когда начну триггер создавать на базе сумматора, и то уравнения адаптированные будут, в том виде, когда они дают вот такой разультат
https://habr.com/ru/articles/862214/#comment_27630546
они вообще не нужны, разве что голову поморочить тому кто их знает. А вот адаптировать - будет полезным, так как много там (в методах уравнений) вещей интересных. А пока что - не применялось мной в программировании и схемотехнике.
Это вовсе не означает что в моей схеме ошибка.
А никто и не говорил что им не доверяет, просто я знаю что описание схемы в структурном виде так и синтезирует схему, такой, какая она есть, и мне это и нужно.
Нет это важно. Я не делаю проект для FPGA, я делаю свою архитектуру, поэтому это важно, и в данном случае для меня и является самым низким уровнем программирования - именно описание в структурном виде на уровне винтелей (переходить к уровню транзисторов не вижу смысла, хотя и этот вид немного у меня присутствует в виде электронных ключей или так называемых буферов трёх состояний), которое я смогу переносить на любую плату любого производителя - раз, и которое при синтезе не изменит первоначальной схемы - два.
Кроме того, тот уровень, о котором Вы говорите не является самым низким, никак, так как самый низкий вероятно будет верхний в следующем списке, приведено из книги
Так вот всё что я сделал - назвал стиль описания видом описания (структурный стиль описания и структурный уровень - не одно и то же), поскольку предпочтения тут не при чём и вопрос чисто технический. Вид описания у меня структурный, а уровень - вентильный. Так что Ваша помощь далеко таковой не является, не нужно никого вводить в заблуждение.
Я не обращаю внимание на малозначимые моменты (лучше сосредоточить внимание на ключевых местах), я достаточно внимательно отслеживаю поток ваших сообщений. Вам не нужно мне "помгать", лучше помогите (без кавычек) своим ближним. Мне помогут книги, как и в этот раз.
Не только об этом. Причём даже с нескольких раз Вы не перестаёте не знать.
В моей схеме нет никакой ошибки, она проверена в симуляторе и на самом FPGA, про ошибку это ваши фантазии и за них разумеется никаких спасибо Вы не дождётесь. Моя схема как была без ошибки до вашего появления - так и осталась без неё, никто вам не давал доступа к редактированию моей публикации тем более схемы. Я жду от вас именно того, на что вы заявляете с своими уравнениями, и при этом прошу учитывать вас вот этот ваш комментарий
https://habr.com/ru/articles/857444/comments/#comment_27568180
, который даёт понять. что вы не знаете что и во что компилирует компилятор. Доношу до Вас в очередной раз, в надежде быть услышанным : структурный вид описания (схему) компилятор не переделывает никак при синтезе, и синтезирует её именно в том виде - в виде схемы, со всеми теми элементами и проводами, как она описана (схема в тектстовом виде), в то время, как все другие виды описания компилятор уже переводит на язык описания схем при синтезе, причём переводит согласно логике в него заложенной разработчиками, в то время как структурное описание остаётся однозначным и не искажается и не изменяется никак (какой схема была до синтеза - такой она останется и после, без каких либо изменений).
Заранее спасибо за понимание, если конечно оно возможно вообще, в Вашем случае.
Раз уж вы говорите о чем-то конкретном, то и опишите это в том-же виде
стиле, на который заявляете, и повторите в симуляторе. Поэтому будьте добры - не надо заявлять, что нечто с крышею это тоже дом. Да у него есть крыша, но много чего не подтверждено, и нет уверенности что с первым паводком это не уплывёт как шалаш, как любят говорить о таких видах описания - "не известно во что это изложит компилятор". Это не мои слова - "неизвестно во что это откомпилирует компилятор", причём говорилось это именно о структурном виде описания, который ккомпилятор компилирует как раз именно точь в точь элемент к элементу, а провод к проводу. К тому-же ваши называния полноценного симулятора аниматором вообще не располагают доверять вам на слово. И именно поэтому я ещё и проверю вашу схему в симуляторе сам. Как только вы предоставите схему. Надеюсь, что симулятор вы назвали аниматором по ошибке, поэтому жду от вас схемы. На словах знаете - все мастаки, а как дела касается, так всё - оказывается не работает. Минусы не надо ставить - нужна рабочая схема, и желательно в симуляторе, и желательно чтобы материал был в том виде, как и у меня (анимированный), чтобы сразу все видели о чём вы говорите. А ваши слова не надежны, со слов ваших же коллег - "неизвестно во что это откомпилирует компилятор".я сделал рабочую схему.
Я нисколько не мешаю сделать это другим. Извините, у меня не так много времени, чтобы проверять чужие работы, которыми, к тому же, я даже не планирую воспользоваться.
Мной двигала идея скорости работы, а не простоты. Тут нужно проводить тестбенчи. Их мне удалось провести только один раз , пока что, потом всё как с поломанным телефоном. Перевод в состояние Z , насколько мне известно, например у электронного ключа, состоящего всего из одного транзистора и имеющего точно такую таблицу истинности как у логического элемента bufif1, то же самое что состояние "закрыто", то есть задержка - время рассасывания заряда базы биполярного транзистора- если используются они. Вообще не хотелось бы заниматься гипотезами, на фоне отсутствия хорошей литературы, могущей дать быстро нужный ответ, поэтому лучше практика. Не берусь утверждать любую точку зрения, потому что даже вся литература, мной приобретенная, включая искусство схемотехники - однозначного ответа не даст, всё не перечитал, но "ключевые" моменты изучил все в каждой. Поэтому предпочитаю говорить о практике с точки зрения именно практической. Тест бенчи будут, возможно на выходных я просто проведу их для всех логических элементов, но вот в целостности платы уверенности нет пока что, поэтому я не смогу дать быстро нужный ответ на замечание. У меня нет никакой абсолютной уверенности, мной движет только личный опыт решения разных задач и желание создания процессора своей архитектуры (стоит отметить, что например на поиск решения для альтернативы сверхточных нейросетей у меня ушло не мало времени-годы, но вдохновляла важность задачи, да и самих таковых), публикация не носит характера туториала. Поэтому это всё, что пока что могу.
С стандартными реализациями я знаком, и если вы переходили по ссылке что давал я, и даже по той, что дали мне вы - вы должны были увидеть схему (она есть тут - выглядит как паравоз), которую я тоже сравнивал на быстродействие с своей (вообще я две версии с своей сравнивал), и там где нет инвертора тоже, и это в семь раз медленнее моего (как минимум схема без инвертора, с инвертором схема ещё медленнее, а у меня задача разбита на две параллельных). А знаете почему? Потому что схема не последовательная. Вы сами пишите комментарии не читая чужих материалов. Что касается меня, то с гуглом я дружу вполне, схему по вашей же ссылке не читали только вы сами, я читал. О расточительности я сужу по быстродействию. К тому-же у меня всего два логических элемента кроме двух инверторов, и они - параллельно подключены, образуя две линии.
И у меня - всё получилось. Мнения вашего круга мне зорошо известны, его члены сами в сети и в радиожурналах часто отмечались, высказывая их. То что я не дулаю публикации - не значит что у меня ничего не получилось, просто на базе части своего сумматора я пытаюсь создать RS триггер асинхронный. Если создание триггера окажется слишком тяжёлым - то вероятно я выложу сумматор отдельной публикацией, если не завтра, то послезавтра, с тестбенчами (без инвертора в семь раз медленнее, а стнадартный - он же по вашей ссылке, но с инверторами - и того больше). Так что вы можете сильно не стараться с уничижениями, я просто пытаюсь потратить свои вечера на новый триггер, который будет ещё быстрее, ну или должен быть, так как не факт что он у меня получится.
То что у меня не получилось - я слушу со времени создания своего генератора карт, который почти в квадрат числа (где числом описывается объём работы при расчётоах карты) превосходит по быстродействию традиционный алгоритм, который мне предлагали, заявляя что мой никогда не заработает. Но увы - он заработал, и тогда заявлявшие заявили следующее - "это ТЗ тупое - карты не эффективны", ну разумеется, для котого-то и книги - ерунда, и учебники, тут убеждать бесполезно в обратном ваш круг. Так что я знаком не только с мнениями вашего круга, но и с его деятельностью в обществе. Очень хорошо знаком.
Прошу прощения, мой сумматор тут https://www.cyberforum.ru/blogs/223907/blog8718.html
. В воскресенье выложу тестбенчи базовых логических элементов и сумматоров.
Спасибо за подсказку, но поблема в том, что баг есть, и представлений схемы при его возникновении не два, а три (с уточнением того, что нормальное представление возникает только если создать ненужный выход с модуля и кинуть на него провод, который всё портит), и если сделать тестбенч баганутого компиляцией кода, то он работает, но со скоростью в два раза меньшей чем при нормальной компиляции. Я это всегда упоминал. Сделал как вы советуете - да, это работает, но баг - остаётся, если не поступить как я описывал. Прошу прощения, но могу отвечать только раз в сутки, и к тому-же сильно занят.
Я его ещё не описывал на языке программирования, поэтому не знаю во что он компилируется, тем более он мной описываться будет по готовой схеме и в структурном виде, поэтому скомпилируется в то, что вы видите на схеме в анимированной симуляции. Да , модуль выполняющий функцию сумматора есть, но он не такой как этот. Сумматор протестирован на работоспособность в симуляторе. По части размытого определения , одинакового быстродействия и всего остального скажу, что тест бенчи выложу на выходных и многословным не буду. Скажу только что знаю наверняка - я делаю схемы в структурном виде описания. Преимущественно это так.
Доделал сегодня сумматор https://www.cyberforum.ru/blogs/223907/blog8715.html .
На следующей неделе будет готова публикация по тестбенчам всех логических элементов и асинхронных триггеров на сброс.
И собственно, сумматора.
Учёные - это те кто делают открытия, а обнаруживают - те кто хотели бы ими стать, в данном ракурсе последних стоит отнести к списку "не думали", а в ракурсе отрезка времени оного опыта - не будут и в будущем, так как удовлетворены чином даваемым им молвой.
Ещё вчера дполнил публикацию. Всё будет сделано точно так-же как и до этого, потому что это проверано было и ранее, пол-года назад, на совсем другом коде и без осцилятора - баг был, просто как его обойти придумал только недавно, так как и времени-то особо не было тоже. Ничего сложного, спасибо за рекомндации, может кому-то помогут. Ваша помощь наверняка кому-то нужна.
У триггеров есть вход и есть сброс, иначе никаких полных циклов-бы не было. Меня больше интересует теперь тайминг сброса. Что касается мнений про баг - я всё сказал, строка номер 19 всё меняет, компилятору не хватает абстрактного "взгляда" на синтезируемую схему, привязка массива проводов к выходу (даже если он не нужен )позволяет исправить проблему. Если кто-то знает причину более точно - попробуйте, я сделал как считал нужным согласно своей логике и это решило проблему. На эксперименты и проверки рекомендуемые со стороны - у меня к сожалению нет времени. Но тем не менее - всем спасибо.
Могу сказать только, что с АЛУ я выложу тестбенчи сброса цепи таких триггеров, только это не простая задача, так как в отличии от установки значения единицы - прийдётся задействовать цепи логических элементов, высчитывать их скорость, и только потом вычислять скорость сброса триггера. Проблема в том, что прийдётся лепить пары элементов NOT , или одиночными XOR (в общем тут подумать надо, скорее вообще эхлемент AND или жлектпонный ключ bufif), между триггерами, высчитать их скорость (наверное всё-же отдельной цепью), и потом сделать новую цепь для вычисления скорости сброса, или попробовать одной новой цепью всё.
Всё будет через пару-тройку часов. Могу сказать одно - мой успех меня опечаливает. Почему? Потому что цифры неожиданные, хоть и верные, слишком несерьёзно относился и не ожидал что так можно. Второй фактор - в то время, как кто-то пиарится на альтернативах западным FPGA - мне приходится побеждать баги в средах разработки, которые они не стесняются рекомендовать российским пользователям для обучения. Я не думаю, что они не знали - мне не понятно: они хотят денег за свои победы над багами, или не совершили ещё ни одной...всё это уныло. Ну запись я не стану конечно делать в таком жанре - просто приведу баг (а он достаточно серьёзный, с таким я не осмелился бы рекомендовать среду для обучения в российских вузах), и то как он нейтрализуется. Ну и цифры. А следующим уже (через один) - будет АЛУ нового типа и его тестбенчи (тут я не уверен что у меня получится успешный АЛУ, но всё-же на фоне асинхронной логики просматриваются иные архитектуры, поэтому всё может быть).