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