С вами трудно не согласится, но опираясь на свой небольшой опыт могу посоветовать составлять вопросы так, чтобы исключить возможность вранья, но все равно надо самому проверять источники, благо ИИ их сообщает.
Да конечно, ИИ ищет решение причем в заданном направлении лучше, чем совсем случайно - не даром же его столько учили, но зато отсутствует то, что можно назвать энциклопедичностью - применить имеющиеся знания из несмежных областей - слабо.
Алиса писала мне на Питоне графический редактор и там выбор решения осуществлялся по расстоянию от точки до прямой. Так каких только логических построений она не нагородила, пока я ей не посоветовал воспользоваться аналитической геометрией - и тут у нее наступило просветление. А так типичная зубрила - математика отдельно, физика отдельно. А так если задать и обговорить узкую область то и теоремы доказывает. что твой Лобачевский.
Поскольку ответ ИИ вырабатывает статистически, то вероятность получения новой гипотезы не нулевая - это как обезьяна которая может напечатать "Войну и мир" - это у Перельмана кажется было.
Ничего общего - 176ИЕ4 - счетчик с дешифратором в семи сегментный код, здесь фактически статический триггер. Семи сегментный код имеет переменное число единиц - здесь код "две единицы из N".
То, что мне знакомо - это pipeline устройства, рассмотренные в предыдущих статьях. Там эти триггеры весьма органично вписываются в идею pipeline. Счечик даже был внедрен какой-то организацией.
В данной статье рассматривалось построение pipeline счетчика, где перенос обрабатывается по принципу конвейера. В последней из указанных книг приведены примеры таких счетчиков в т.ч. и на основе понравившегося вам известного триггера, но, очевидно за недостатком места не объяснено, как они получены. Именно на этот вопрос я и попытался ответить в своей статье и на счастье получилась схема неизвестная раньше. В противном случае эта статья не увидела бы свет.
Синтез цифровых схем имеет много методов,- это как изобразительное искусство - рисовать можно разными красками, карандашами, мелками - важен результат. И если в искусстве результатом может считаться и испачканный лист бумаги или даже размалеванная стена,- в технике основной критерий - выполнение спроектированным устройством заданных функций.
В свое время основными параметрами для сравнения полученных результатов синтеза были быстродействие и сложность полученного устройства, сейчас это видимо стало не актуально и предложенный комментатором метод, наверное, имеет право на существование.
В сущности, изложенный в статье способ построения pipelint счетчика опирается на те же основания, но использует их, так сказать, на "молекулярном" уровне.
С вами трудно не согласится - действительно предложенные схемы далеки от реальной схемотехники, так - теоретические упражнения. Может это одна из причин того, что это направление не нашло применения. С другой стороны может когда-нибудь этот барьер сложности будет преодолён технологически и об этой теории вспомнят и инженеры-практики.
Я пытался объяснить построение схем регистров не претендуя на изложение общей теории, которая к тому же достаточно полно излагается в книге, на которую есть ссылки в статье. При этом меня увлекала идея проследить наследование родовых свойств, которые имелись еще в регистре, предложенном Маллером. По этому принципу и отбирались описываемые схемы.
Эти картинки не из Авт.св., а скорее из книги, на которую есть ссылки в статье, да и то не все - есть одна новая. В СССР существовала ЕСКД - единая система конструкторской документации по правилам которой и рисовались схемы. Ее, вроде, не отменяли.
Спасибо за справедливое замечание. Я действительно не знаком с указанными инструментами, но постараюсь их изучить. Что касается схем - то почти у всех входы снизу, а выходы сверху, что вполне допустимо. Замеченный вам недостаток только у первых двух, которые настолько просты, что указанный недостаток не мешает их пониманию.
Интересная информация, только непонятно почему вы этот объект называете диаграммой Мамрукова. Она, например, имеется в работах Миллера и других публикациях на эту тему.
Вот именно из-за этого "кто кого перетянет" во многих системах логических элементов (ТТЛ, например) запрещено объединять выходы в точку. В нашем случае это не позволяет описать такую схему системой логических уравнений - поэтому такое объединение впрямую запрещено Миллером при определении понятия схема. Поэтому пример, конечно, интересный, но, как говорится, из другой оперы. И спасибо за интересны комментарий!
Я ж говорил, что натяжение на куб - процедура болезненная, т.к. используется тот же принцип, что и в картах Карно: показываются только переходы в соседние состояния. Остальные (если они есть) подразумеваются, но не показываются, что бы не усложнять рисунок.
Приведенная вами диаграмма не полумодулярна относительно состояний 000 и 111, т.к в них возбуждены все три выхода, а при переходе в любое рабочее состояние (- 1 возбуждение) остается возбужденным только 1 выход, следовательно еще 1 возбужденный стал устойчивым не поменяв своего значения. Не полумодулярность этой схемы доказанный факт, не зависимо от источника, откуда она срисована.
Про симуляцию я ничего возразить не могу, могу только посоветовать, если нельзя симулировать абстрактные логические элементы имеющие задержку, попробуйте вместо КМОП симулировать ТТЛ. Дорогу осилит идущий. Или не осилит.
Да, интересно было бы посмотреть обсуждаемую осцилляцию на симуляторе. А не получилось, конечно, не из-за соотношения вероятностей переходов, а либо из-за некорректного задания начальных условий моделирования, либо из-за некорректного алгоритма работы симулятора. Например, если при обработке очередного временного среза, симулятор вычисляет значение выходов элементов модели последовательно и при этом для каждого следующего использует не параметры на начало среза, а актуальные, т.е. с учетом уже вычисленных.
В начале карьеры я наблюдал обсуждаемую осцилляцию на электронном макете, правда последовательно с каждым из трех ТТЛ инверторов были включены линии задержки, но не RC, а какие-то электромагнитные, дающие задержку в миллисекундном диапазоне с большой точностью.
Хочу обратить внимание комментатора насколько симпатичней выглядит приведенный им граф переходов, если его натянуть на координатный куб (см. рис.1 статьи). Эта косметическая операция может и болезненная, но явно не бесполезная.
Когда еще сам чего-то паял (пол века назад) - это был ТТЛ и никаких проблем, типа описанных вами, не наблюдалось. С КМОП я имел дело чисто теоретически и поэтому ничего вразумительного по их поводу не сообщу, хотя некоторые мои схемы на КМОП защищены АС СССР.
Что касается отношения к самосинхронным схемам, то мое - совпадает с вашим и я их на данном этапе рассматриваю только как объекты для хобби, ну как другие хоббисты - простые числа, например. Хотя проблема подсчета количества этих объектов меня интересовала всегда.
С вами трудно не согласится, но опираясь на свой небольшой опыт могу посоветовать составлять вопросы так, чтобы исключить возможность вранья, но все равно надо самому проверять источники, благо ИИ их сообщает.
Да конечно, ИИ ищет решение причем в заданном направлении лучше, чем совсем случайно - не даром же его столько учили, но зато отсутствует то, что можно назвать энциклопедичностью - применить имеющиеся знания из несмежных областей - слабо.
Алиса писала мне на Питоне графический редактор и там выбор решения осуществлялся по расстоянию от точки до прямой. Так каких только логических построений она не нагородила, пока я ей не посоветовал воспользоваться аналитической геометрией - и тут у нее наступило просветление. А так типичная зубрила - математика отдельно, физика отдельно. А так если задать и обговорить узкую область то и теоремы доказывает. что твой Лобачевский.
Я тоже руками связывал обеих Алис и закрыл диалог на 15 вопросе.
Поскольку ответ ИИ вырабатывает статистически, то вероятность получения новой гипотезы не нулевая - это как обезьяна которая может напечатать "Войну и мир" - это у Перельмана кажется было.
Все правильно, спасибо!
Ничего общего - 176ИЕ4 - счетчик с дешифратором в семи сегментный код, здесь фактически статический триггер. Семи сегментный код имеет переменное число единиц - здесь код "две единицы из N".
Круто!
То, что мне знакомо - это pipeline устройства, рассмотренные в предыдущих статьях. Там эти триггеры весьма органично вписываются в идею pipeline. Счечик даже был внедрен какой-то организацией.
Да, конечно, это известный способ.
Спасибо за интересный комментарий.
К сожалению мне недоступен этот материал, был бы благодарен за ссылку на него, если это возможно.
Замечу, что на упомянутое Авт. св. СССР заявка была подана в июле 1979 года, т.е. до опубликования упомянутой вами статьи.
Приведенный вами счетный триггер хорошо известен еще по популярной в свое время книге Микроэлектронные схемы цифровых устройств - Букреев И.Н., Горячев В.И., Мансуров Б.М. - 2009, а в книге Автоматное управление асинхронными процессами в ЭВМ и дискретных системах, показано как с помощью всего лишь одного элемента И-НЕ превратить эту схему в полумодулярную,- факт принадлежности ее этому классу и исследуется в вашей статье. И конечно используя известные способы соединения таких схем (в т.ч. и теорему Маллера) можно получить многоразрядный счетчик обладающий такими же свойствами, но с последовательным или параллельным переносом.
В данной статье рассматривалось построение pipeline счетчика, где перенос обрабатывается по принципу конвейера. В последней из указанных книг приведены примеры таких счетчиков в т.ч. и на основе понравившегося вам известного триггера, но, очевидно за недостатком места не объяснено, как они получены. Именно на этот вопрос я и попытался ответить в своей статье и на счастье получилась схема неизвестная раньше. В противном случае эта статья не увидела бы свет.
Спасибо за конструктивный комментарий.
Синтез цифровых схем имеет много методов,- это как изобразительное искусство - рисовать можно разными красками, карандашами, мелками - важен результат. И если в искусстве результатом может считаться и испачканный лист бумаги или даже размалеванная стена,- в технике основной критерий - выполнение спроектированным устройством заданных функций.
В свое время основными параметрами для сравнения полученных результатов синтеза были быстродействие и сложность полученного устройства, сейчас это видимо стало не актуально и предложенный комментатором метод, наверное, имеет право на существование.
В сущности, изложенный в статье способ построения pipelint счетчика опирается на те же основания, но использует их, так сказать, на "молекулярном" уровне.
С вами трудно не согласится - действительно предложенные схемы далеки от реальной схемотехники, так - теоретические упражнения. Может это одна из причин того, что это направление не нашло применения. С другой стороны может когда-нибудь этот барьер сложности будет преодолён технологически и об этой теории вспомнят и инженеры-практики.
Я пытался объяснить построение схем регистров не претендуя на изложение общей теории, которая к тому же достаточно полно излагается в книге, на которую есть ссылки в статье. При этом меня увлекала идея проследить наследование родовых свойств, которые имелись еще в регистре, предложенном Маллером. По этому принципу и отбирались описываемые схемы.
Эти картинки не из Авт.св., а скорее из книги, на которую есть ссылки в статье, да и то не все - есть одна новая. В СССР существовала ЕСКД - единая система конструкторской документации по правилам которой и рисовались схемы. Ее, вроде, не отменяли.
Спасибо за справедливое замечание. Я действительно не знаком с указанными инструментами, но постараюсь их изучить. Что касается схем - то почти у всех входы снизу, а выходы сверху, что вполне допустимо. Замеченный вам недостаток только у первых двух, которые настолько просты, что указанный недостаток не мешает их пониманию.
Интересная информация, только непонятно почему вы этот объект называете диаграммой Мамрукова. Она, например, имеется в работах Миллера и других публикациях на эту тему.
Вот именно из-за этого "кто кого перетянет" во многих системах логических элементов (ТТЛ, например) запрещено объединять выходы в точку. В нашем случае это не позволяет описать такую схему системой логических уравнений - поэтому такое объединение впрямую запрещено Миллером при определении понятия схема. Поэтому пример, конечно, интересный, но, как говорится, из другой оперы. И спасибо за интересны комментарий!
Я ж говорил, что натяжение на куб - процедура болезненная, т.к. используется тот же принцип, что и в картах Карно: показываются только переходы в соседние состояния. Остальные (если они есть) подразумеваются, но не показываются, что бы не усложнять рисунок.
Приведенная вами диаграмма не полумодулярна относительно состояний 000 и 111, т.к в них возбуждены все три выхода, а при переходе в любое рабочее состояние (- 1 возбуждение) остается возбужденным только 1 выход, следовательно еще 1 возбужденный стал устойчивым не поменяв своего значения. Не полумодулярность этой схемы доказанный факт, не зависимо от источника, откуда она срисована.
Про симуляцию я ничего возразить не могу, могу только посоветовать, если нельзя симулировать абстрактные логические элементы имеющие задержку, попробуйте вместо КМОП симулировать ТТЛ. Дорогу осилит идущий. Или не осилит.
Да, интересно было бы посмотреть обсуждаемую осцилляцию на симуляторе. А не получилось, конечно, не из-за соотношения вероятностей переходов, а либо из-за некорректного задания начальных условий моделирования, либо из-за некорректного алгоритма работы симулятора. Например, если при обработке очередного временного среза, симулятор вычисляет значение выходов элементов модели последовательно и при этом для каждого следующего использует не параметры на начало среза, а актуальные, т.е. с учетом уже вычисленных.
В начале карьеры я наблюдал обсуждаемую осцилляцию на электронном макете, правда последовательно с каждым из трех ТТЛ инверторов были включены линии задержки, но не RC, а какие-то электромагнитные, дающие задержку в миллисекундном диапазоне с большой точностью.
Хочу обратить внимание комментатора насколько симпатичней выглядит приведенный им граф переходов, если его натянуть на координатный куб (см. рис.1 статьи). Эта косметическая операция может и болезненная, но явно не бесполезная.
Спасибо за интересный комментарий!
Когда еще сам чего-то паял (пол века назад) - это был ТТЛ и никаких проблем, типа описанных вами, не наблюдалось. С КМОП я имел дело чисто теоретически и поэтому ничего вразумительного по их поводу не сообщу, хотя некоторые мои схемы на КМОП защищены АС СССР.
Что касается отношения к самосинхронным схемам, то мое - совпадает с вашим и я их на данном этапе рассматриваю только как объекты для хобби, ну как другие хоббисты - простые числа, например. Хотя проблема подсчета количества этих объектов меня интересовала всегда.
За комментарий спасибо!