Здравствуйте. Хочу поделиться опытом того, как хотел решить некоторые вопросы с помощью AI, решения которых мне необходимы для работы над одним из проектов, но... не тут‑то было. А делаю я между делом симулятор жидкой и газообразной среды, взаимодействующей с движущимися и неподвижными твердотельными объектами. Симулятор в свою очередь мне нужен для создания другого прикладного ПО, как 3D мэйкеру или просто самодельщику, потому что коммерческие решения не всегда удовлетворяют, порой острые, потребности. Затею опроса AI пришлось оставить, так как то‑ли AI ошибся, то‑ли физика (не физическая реальность) не учитывает всех возможных моментов — мне осталось непонятным. Итак я просто приведу диалог, и скажу, что никого не отговариваю от использования AI, так как сам обращаюсь к нему чаще и чаще, причём от самых разных разработчиков, и уж в чём он хорош — так это в офисных вопросах: ПО, работа с ПО, любые бумажные дела и вопросы, тут ему равных нет. Но, тут столкнулся молот с наковальней.

Привет Хабр. Разумеется я не последовал рекомендациям нейросети, как и не стал её обременять подробностями задачи, потому что имею опыт некоторый опыт в алгоритмизации и хочу его увеличить. Не могу сказать что и в этот раз это что‑то сногсшибательное, но новичку можно ознакомится чтобы знать как ориентировать своё мышление в решении подобных задач конвейерной обработки данных. Публикация будет отражать именно суть решения задачи, и не более, чтобы не усложнять теорией. И под спойлером предыстория и ещё немного интересного по ссылкам, так или иначе связанного с публикацией. Единственное что хочется отметить в превью, что главный скил ведения уникальных проектов — умение оптимально и экономично свзывать в единую сеть (планировать) все необходимые опорные вершины (а они могут быть очень разными, даже если не говорить о самой своей жизни, то можно сказать о симуляторе жизни) проекта необходимые для его развития и разработки. Почему в названии «трек» — потому что это беглый обзор ряда решений, с основным в конце. Это более полезный трек для новичков, специалисты (но из материала в сети следует что не все) наверняка знакомы с подобными трюками. Если не смущает такая круговерть — можете читать (тут по ссылке есть отступление на геометрическое изыскание по вычислению угла на сетке координат по точкам, формулы там не верны скорее всего, так как их писала LM, у меня не было на них пока времени — теперь будет, но решение верное).

Здравствуйте. Со времени той, не очень удачной публикации прошло много времени, за которое у меня многое изменилось, поэтому переработка материала немного подзадержалась. Скажу сразу, что это пока выполнено только в симуляторе Logisim Evolution, и проект полностью готов в Gowin 1.9.11, но пока я не знаю как отключать оптимизацию модулей, поэтому битстрима пока нет, но код выложу. Почему я решился на публикацию - потому что к "железному" OnKeyUp прибавился такой-же антидребезг. В симуляторе работает, но в битстрим пока не реализовано. Как только выяснится что у разработчика уровень демократичности (свобода действий пользователя и документация) достаточен - битстрим будет здесь с немного переработанной публикацией. А пока - только в симуляторе, для полного ознакомления с схемой он необходим, но можно и через код под спойлером в конце.

Это один из моих интересных опытов связанных с физикой, когда я увлечённо редактировал модельку , закончил её, и даже напечатал и установил на плату, причём всё это я делал не имея конечного понятия как я подтвержу факт наличия полезного эффекта. И выкручиваться - соображать о методе подтверждения пришлось уже когда всё было собрано. Общее представление было - "колдунчики", их используют в парусном спорте, в основном на олимпийских классах яхт, так как там требуется постоянный мониторинг эффективности использования паруса. Возможно мой опыт кому-то окажется полезным. Этот опыт мной был сделан давно, но тогда я ещё как-то на Хабре не писал особо. И вот пока делаю передышку с архитектурами - решил выложить тут. Возможно кто-то сочтёт это фальсификацией или неточным, но скажу тогда, что каждый может проверить сам так, как ему будет угодно. Как ни странно - мини ПК этот я совсем забросил, сосредоточившись на FPGA, но не в этом суть. Скажу сразу - что видео мне далось трудно, было не удобно снимать его одной рукой, при этом второй делать всё остальное, поэтому если у кого раздражительность на плохой монтаж и такую же аппаратуру с условиями, предупреждаю сразу - лучше не смотрите и не читайте, берегите нервы.

С чего стоит начать, с того, что IDE у меня пока Gowin 1.9.9.03 Education. Но если кто-то захочет посмотреть только файл Logisim Evolution, то для него это значения не имеет. Свободное время я как мог отдал этой работе, не забывая при этом отдыхать, без этого вообще никак. Исправил сделал доработку полного сумматора, отладил проект асинхронного счётчика в Logisim Evolution v3.9.0. Плата всё та же - Tang nano 9k. Все проекты в Zip папках. Это всё та-же асинхронная логика, тактирование тут применяется собственного изготовления и действует как замена сигнала согласования. И плюс своя версия языкового описания в структурном виде схем на базовых логических элементах (символы могут быть заменены на более визуабельные, просто на настоящий момент передать смысл описания и для чего оно такое и как это можно использовать). Всё ещё предположительно Fast триггеры и регистры (проект триггера архивирован). Если вам ещё не надоело читать - прошу далее, в конце ждёт видео (и ссылка на видео с рутуба) с работающим асинхронным шестнадцатиразрядным счётчиком на базе сумматоров и регистров. Если кому нужны доказательства, как оказалось, то все проекты в архивах по предоставленным в публикации ссылкам. Кроме того- публикация ничего не доказывает, это просто описание проделанных мною работ, часть которой является вполне успешной, а часть - не очень, но направление асинхронной логики интересное и мало исследованное.

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

В этот разрезультатом стал двухлинейный сумматор. Намучался с ним достаточно — не одну неделю разрабатывал, в процессе какие только монстры не получались, но итогом вполне удовлетворён. Внушает надежды, что на его базе модно создать асинхронный триггер, который вообще будет в корне отличаться от предшественников. Объективных тестбенчей в сравнениях произвести не удалось по непонятным причинам — сначала они получились, но вечером следующего дня картина тестбенчей в корне изменилась, попробовал обойти трудности надстройкой над тестовой схемой — но увы, сигнал почему‑то не отслеживается. Буду искать ошибки пару вечеров, а пока просто расскажу о том как собственно всё обстоит. Приступил сразу после предшествующих публикаций, разумеется всё в свободное время, пару недель вечеров было потрачено на попытки сократить цепь звеньев, потому как было ясно, что последовательная цепь лучше чем имеется на настоящий момент не получится. И вот однажды начиркал на клочке бумаги основу, а потом доработал в симуляторе. Получилось это, постил тут

Речь пойдёт всё так‑же о асинхронной логике. Похоже, что тут никто и никого не ждал... к такому выводу можно прийти, если посмотреть на сравнения, в сети и материалах, по части синхронной и асинхронной логики, и на фактические цифры, ну и на традиционную забагованность (в частности Gowin EDA) в таких нужных местах как массивы, впрочем эта забагованность вполне победима посредством небольшого «шаманства», об этом будет тоже. Приходится делать «двухшаговые » публикации, потому что если свалить всё в прошлую — то это вряд ли станет всё читабельным, а одного шага явно мало для полноценной публикации, особенно на фоне борьбы с чужими багами. Если не лень читать новые «приключения» в асинхронном, и не только, мире — то пожалуйста.

В естественной среде (в реальном мире), на асинхронной логике построено всё, и даже жизнь. Пытаться повторить последнее на FPGA разумеется можно только в виде игры, но и её пока что не будет. Хотя публикация имеет место быть, теперь с удвоенным объёмом материала, так как мне нельзя писать чаще раза в неделю, то я решил вторую публикацию включить сюда, материал которой мной планировался в статье "Асинхронные триггеры: цена стиля, и не каждая логика решения раскрывает суть решаемой ей задачи." Всё это - мой небольшой опыт работы с FPGA, который свидетельствует в пользу того, что материал распространённый ранее в сети, по части асинхронной логики, не то что не точный — а не соответствует естественному порядку вещей в действительности, это было‑бы можно объяснять специфичностью FPGA, но никакой такой специфичности на самом деле нет, не было, и вряд‑ли когда будет, поэтому пусть тот материал остаётся сам по себе, и рассматривать его далее, как минимум тут, не стоит. Итак поехали

Асинхронные триггеры: цена стиля, и не каждая логика решения раскрывает суть решаемой ей задачи.

Нет согласующих резисторов в FPGA - что мешает реализовать целый ряд схем, но зато есть чем заменить их для цифрового сигнала внутри таких схем. Пытался найти в сети альтернативу согласующему резистору для применения внутри синтезируемой схемы, поисковик выдал скромный результат поиска, содержанием которого оказалось ничего по существу - категоричное нет на всех форумах, и иногда что-то близкое, но моей задачи не решающее. Да и собственно в схеме развёрнуты две задачи - некоторый кэш нового типа и механизм управления таким кэшем, по сути - часть процессора нового типа.

Тут нужно много вникать. И если Вы не верите IDE Logisim Evolution - можете просто пройти мимо и не принимать тут изложенный материал во что-то нужное и полезное. Тем более что это в общем-то работа новичка, который просто развивает свой проект и взгляды в новых областях, сталкивается с новыми задачами и решает их новыми способами.

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

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

Сразу говорю, что роль памяти в данной схеме играют SR триггеры предполагаемого FPGA и процедура заполнения любого числа цепи ячеек (или даже одной) выполняется за два рабочих такта проектируемого процессора, независимо от числа выбранных ячеек. Над этой задачкой пришлось немного пломать голову, и нужно было понять что такое управляемый буфер (в данном случае это для Logisim Evolution).

После того, как составил рабочую схему кэша мостов, для работы процессора в режиме без счётчика команд, приступил к схеме управления кэшом мостов. Кэш мостов - это кэш обеспечивающий выполнение команд без счётчика команд, и позволяющий выполнять только команды в обозначенных ячейках памяти. По сути управление кэшем мостов сводится к мгновенному заполнению групп выбранных ячеек. И вот для того чтобы обеспечить бесперебойную работу управляемых буферов в сложной цепи (множество ячеек и множество источников сигнала) пришлось пойти на Хитрость с ИСКЛЮЧАЮЩИМ ИЛИ.

Триггеры группы Last - нижний ряд триггеров на данном изображении, служит для обозначения последнего триггера данной группы для конкретной ячейки, в который запишется единица и заблокирует прохождение сигнала по верхнему проводнику, через который подряд записывается единица в сами эти ячейки памяти механизма управления кэшем мостов - в триггеры группы Memo (незаконченное слово, так как по сути всё это является устройством для управления памятью, а не ей самой).

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

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

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

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

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

Не рассчитываю собрать много плюсов, рассчитываю собрать вычислительную машину своей архитектуры, с своей ОС и процессорами собственной архитектуры. Многие наверное задались-бы вопросом - в чём логика, когда IT отрасль так развита. Давайте посмотрим кому она развита..., хотя нет, скажу только что решил что будет так тогда, когда в общем-то думал как конвейеры своего GPU пристраивать к вычислительной машине, и хотел назвать конвейеры эти - препроцессорами. Проверил термин и обнаружил, что термин пропроцессор занят под название программы. Подумал - ну хорошо, раз одни уже называют чёрное белым, то самое время создавать другое пространство, где такой необходимости попробовать избежать и создать что-то такое, где граблей валяться под ногами будет поменьше.

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

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

Здравствуйте. Есть желание поделиться опытом организации циклов. Не ожидайте что это прямо такая лекция от специалиста, это просто то, чем я мог-бы поделиться интересным на данном этапе в рамках проекта. Из прошлой публикации по ссылкам можено перейти на код, не блещущий глянцем, но зато матовый оттенок ассемблера там имел место быть по следующим причинам:

для доведения до глянца алгоритма генератора нужно было иметь точное представление формул, а их у меня не было, и формулы расчётов буквально отлаживались в отладчике - искались ошибки, после обнаружения таковых автоматического тестировщика, и формулы для отладки движка генератора карт ещё при этом и растасовывались по коду, для сокращения числа их применения, ну или их частей - такое тоже было. Почему я не использовал case тоже можно объяснить достаточно просто : в конечно счёте применение ассемблера имело место - ознакомится с требуемым его функционалом как можно больше, наработать навык и потом применить. Конечно это не бог весть какое достижение, но тем не менее "рабочая камера" движка генератора карт преобразилась с такого вида

Данная публикация служит пояснительным материалом к предыдущей, а так-же самостоятельной для тех, кто читает по данной теме мои публикации впервые.

Сначала о том, каким алгоритмом я планирую заменить в своих работах свёрточные нейросети. Чтобы это работало быстро - нужны карты трассировок. Линии трассировок на карте расположены параллельно под определённым углом на каждой карте - так и происходит условная поляризация. Генератор карт работает быстро и генерирует он карты трассировок направленных прямыми линиями, обрыв каждой линии он отмечает в данных. То-есть сначала запускатеся генератор карт и генерирует картинку, данная анимация существенно отличается от работы генератора и показывает только его ТЗ - в каждом пикселе карты записать координаты следующего пиксела и обозначить в данных окончание каждой линии. Изображения я взял небольшие, но тем не менее файлы анимации достаточно увесистые. Допустим что обрабатываемые изображения будет 7*7 пикселов, а карт трассировок всего четыре, тогда ТЗ генератора примерно будет выглядеть так, но на самом деле его алгоритм намного сложнее и работает на много быстрее - он ничего практически не считает и выдает большие объёмы данных автоматически, но об этом позже, а пока так чисто визуально

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