Цитата(Vic1 @ Nov 24 2005, 16:01)

Locas, может поясните - зачем Вам такая упрощенная модель RS- триггера? Где она будет использоваться?
Могу.
Собственно проектированием цифровых схем я не занимаюсь. Хотя было время. Оттуда этот триггер и появился. Тем не менее, мне не часто, но приходится моделировать работу цифровых схем и тогда я использую свои наработки, которые я "таская за собой"

тестирую часто этой простой задачкой.
Мои "наработки" - это параллельное ядро, в котором все процессы автоматы. Я прото так программирую. Все. Раньше программировал железо, потом АСУ ТП, бугалтерию и все-все. Сейчас опять есть вариант возврата к железу (см. мои мольбы по поводу CodeWarrior).
Т.е. для меня сейчас RS-триггер это достаточно объективный тест моих средств на правильное моделирование параллелизма. Любого. И здесь цифровые схемы подходят больше всего. Ведь, каждый элемент - это параллельный процесс.
На RS-триггере я отточил и свою теорию. Точнее ее расширение, связанное с параллельными автоматами. И здесь я столнулся со странностями, что в нанешнем преподавании триггер дают в корне не правильно. Выше я писал по поводу ее таблицы истинности. Я знаю только один источник, где он рассмотрен близко к тому, как рассматриваю я.
RS-триггер и реальная система, на котрой я могу оценить справедливость своей параллельной модели. Если формальные результаты совпадают с реальными, то ... "что еще надо для хорошей жизни"

До последнего времени все совпадало кроме этой самой генерации. Одни ее отвергали напрочь, не поясняя при этом почему. Другие просто отмалчивались. А мой триггер ... упорно генерировал. Меня это тоже нервировало, пока я не разобрался, что есть разные типы задержек (почерпнул из VHDL). Теперь все "хоккей": я знаю почему он генерировал, знаю почему не генерировал, знаю когда может генерировать

Собственно зачем я тогда затеял весь разговор т.к. все уже знаю? Во-первых, конечно хочется чтобы это знали и другие

Знали, что современное образование "вешает лапшу", говоря про запрещеные состояния, что триггно устанавливается в неопределенное состояние и т.д. и т.п. Т.к. знаю как все это опровергнуть на формальном уровне (т.е. математически).
Знаю, что триггером можно проверять любые другие средства моделирования цифровых схем на уровне логики (вентили - это все же отдельная история). И вот здесь мне хотелось бы собрать информацию, о его моделировании в других системах. Т.е. четко знать где он генерирует, а где, возможно, и нет. Собственно в данной ситуации это, может быть, и есть основная цель затеянного разговора, т.к. лично я не могу такую работу сделать. Просто потому что не работаю с теми или иными средствами. Ну а тем, кто работает, надеюсь, не составит большого труда такою проверку - моделирование RS-триггера сделать. Т.е. примерно так, как это сделал SM. Только вот его результаты пока еще не очень меня устраивают. Во-первых, не нужен такой детальный уровень моделирования (транзисторный), во-вторых, - разнобой, как Вы видите в результах. То генерирует, то нет.
Причем он должен (или я так полагаю) генерировать в любой ситуации, если элементы его абсолютно одинаковы: в математических формулах нет "паразитных емкостей", "тепловых шумов" и т.п. Если их, конечно, не ввести туда сознательно (что и делал SM). Но так этого и не нужно делать. На том уровне, который обычно дается он в преподавании все ограничивается 0, 1 и задержка, которую обычно забывают, как забывают, что триггер - это КА, а не комбинационная схема. Это важно. Важно для понимания работы триггера.
И очень важно понимание триггера, как маленькой, но очень хитрой параллельной системы. Которая как дискретная и детерминированная система должна вести себя однозначно. Но обычно с программистами на эту тему говорить тяжело. Для них электроника, даже цифровая, - чума. Хотя вот недавно попалась на глаза очень интересная книжка Алгоритмы: проектировани и анализ. Она для програмистов. Там рассматриваются сортирующие сети и арифметические схемы. Но все это, так сказать, цифровые схемы без обратных связей. Там триггер не сделаешь. Но программистам, думаю, доказать это будет сложно. Если только не сунуть под нос триггер. Лучше если в форме модели. Лучше, если в разных системах моделирования. Тут чем больше независимых источников с одинаковыми результатами работы, тем больше доверия к этим результатам.
По мои предположениям триггер должен генерировать везде. Вот в этом и хочется убедиться. Но, конечно, только достаточно идеальный триггер. Но даже этот идеальный триггер должен как можно ближе объяснять работу реального триггера. А не так как оно есть сейчас. Эта жутко безобразная таблица истинности с запрещенными состояниями. Она сейчас прямо выводит меня из себя (шучу, конечно)

Вот так длинно о такой "короткой" схеме. Но на мой взгяд очень важной. Оттого и такое мое многословие...

Наверное, проще взять и смоделировать

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