@Btomdyi

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

Реализация. Собственно, я нашла две реализации этого узла. Первый - на двух 555СП1, не требующий пояснения. Второй - на дискретной логике. Последний вариант получился очень громоздок в плане "до 13 корпусов дискретной логики типа инверторов и 2И-НЕ", так что и он не подошел. Возможно есть еще варианты, попроще?

На МК реализовать нельзя - сказывается дискретность обработки контроллером команд, т.е. заданная комбинация на шине может появиться и пропасть в произвольное время, контроллер на высоких частотах шины просто не успеет отработать и сглючит.Применять более быстрый МК мне кажется - перебор.Частота адресной шины до 10-15 Мгц.
Еще думала про ПЛИС, но с ними не работала. А вообще не хотелось бы забивать гвозди микроскопом.

Помогите пожалуйста.

0

@tyzord66

Есть люди, заинтересованные в коммерческом продвижении проекта. Непосредственно в разработке они не участвовали, но поддерживали проект финансово. Публикуемые фото прошу воспринимать не как рекламу , а как лабораторный макет для отладки софта, собственно так оно и есть. Обсуждался вопрос передачи сигнала, и я привел пример из собственного опыта. Если кто то из сообщества пожелает заняться подобной разработкой без колебания помогу, отвечу на вопросы, поделюсь даташитами и материалами, которыми пользовался при проектировке.
PS: схемы секретом не являются.

0

@tyzord66

я вас прекрасно понял;) а стробироваться они должны по тактовому генератору, который стоит рядом с самой плис. соблюдайте правила приличия и никаких проблем со "слишком быстрой реакцией" плис не будет;)
Отдельное тактирование это идеальный вариант, но проблему звона он не решит. Если Вы имеете ввиду организацию цифрового фильтра, то его частота должна на пару порядков превышать исследуемый сигнал, в данном случае это не возможно. Устройство питается от автономного источника, поэтому вопрос потребления был не на последнем месте, в данной реализации ПЛИС потребляет всего около 45мА.

0

@Ymk

tyzord66, FYI, только тактирование позволяет делать на fpga стабильно работающие схемы. почитайте каких-нить правильных книжек что ли. это не идеальный вариант, а чуть ли не единственно правильный. фильтры тут вовсе не при чем.

0

@tyzord66

Ну, а я разве спорю с этим :)
Я лишь пытаюсь намекнуть, что амплитуда «звона» может пересекать пороговые уровни 0/1 и на выходе формирователя внутри ПЛИС один звонящий импульс превратится в серию импульсов, и поди потом угадай сколько их на самом деле на входе. И не важно какое у тебя там тактирование.

PS: ридер у меня построен не на FPGA а на CPLD, хорошо видно на фото :)

0

@Btomdyi

Ух сколько информации! Насчет шины действительно есть некоторые вопросы. Как рассчитать минимальную длину шины при всех прочих равных на определенной(10-15мгц) частоте?

Что,если шина будет длиннее двух метров, на небольшом расстоянии от "хоста" который задает адрес будут сосредоточены быстрые устройства, а чуть подалее (макс.расстояние надо уточнить) более медленные - как это отразится в виде глюков? Ориентировочно,медленнодействующие устройства выносим на 6 метров(50-100шт),ближе к хосту массивчик из такого же числа быстрых устройств."Медленные" - частота шины адреса 180 кГц, "быстрые" - те же 15 Мгц.

И придется ли в этом случае периодически ставить развязывающие буфера вдоль шины для уменьшения помех,гуляющим по шине(ВЧ помехи наведенные, иголки)?

Последовательный интерфейс не пойдет по условию задачи. Никаких хитрых FPGA,CPLD и прочих штук, к-рые не реализуются на ИС малой степени интеграции.

0

@Ymk

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

0

@mzw

По идее нужно ставить что-то типа контроллера шины - по крайней мере контролировать готовность устройств к обмену.
То есть, когда на устройство (медленное, быстрое) приходит сигнал выборки (совместно сигнал адреса и чтения/записи), это устройство должно выставить сигнал неготовности и держать его до тех пор, пока данные не будут обработаны. Это очень хорошо описано в литературе о микропроцессорных системах, например, на 8080, 8085, Z80 - в них это используется очень часто.
И, для повышения помехоустойчивости, использовать синхронный обмен данными - то есть иметь еще одну линию с синхроимпульсами, и все операции производить только по их фронтам. Это позволит устранить эффект гонки фронтов.
Наверное, имеет смысл почитать литературу по шинам (системным нигистралям), например, по Multibus.
http://ru.wikipedia.org/wiki/%D0%A8%D0% ... 5%D1%80%29

0

@tyzord66

Т.е. надо было позвонить провайдеру , арендующему транспортер на спутнике и попросить снизить битрэйт? :)
Иначе говоря, если я правильно понял, I2C, SPI, JTAG… - «это наиглупейшие идеи»?
В конце 80х начале 90х мне довелось заниматься обслуживанием и ремонтом ЕС1060 и БЭСМ-6/7, это те, что залы занимали. Интерфейсные кабели составляли десятки метров, передавались как данные так и синхронизация, и ничего – ракеты в космос запускали. Если синхросигналы правильно сформированы и согласованы, то с тактированием от источника никаких проблем не будет.
Тактирующий вход отличается от любого другого только меньшим кол-вом PIAсов от входа ПЛИС до входов синхронизации защелок, больше ни чем. В FPGA есть возможность в процессе компиляции проекта двигать ячейки внутри чипа с целью добиться нужных «времянок», в CPLD такой возможности нет – приходится прибегать к хитростям, как, например, подавать синхру на пин для этого не предназначенный.

0

@Ymk

tyzord66, вы не обижайтесь только, но в голове у вас КАША. SPI и прочие интерфейсы - хорошие вещи, но если вы их делаете концептуально неправильно - вы ССЗБ. поищите, кстати, грамотные реализации spi, не асинхронные как делаете вы (я теперь точно знаю, что вы сделаете неправильно;)), а синхронные. почитайте, наконец, про метастабильность и согласование разных time domain. вот когда вы это прочувствуете, вы поймете и все то, что я советовал выше.

0

@tyzord66

Нет желания спорить, пусть будет КАША :) . Вот с одного технического форума:

"Ведь как стоит вопрос в техническом споре? Можно так сделать или нельзя? Если у двух людей по конкретному техническому вопросу имеется противоположное мнение, то по крайней мере, один из них имеет не адекватное представление о предмете спора. Можно, конечно, сыпать расчетами, ссылками, цитатами и мнениями, но все это будет только косвенные доказательства. Прямым доказательством может быть только работающее оборудование"

Свое работающее устройство я Вам показал.

0

@Ymk

а еще вы рассказали о "слишком быстрой плис". примем это тоже за факт. я сам с плис работал очень мало, но немного ковырял + есть немало знакомых, плотно работающих с ними. так вот от них я это очень часто слышал - долой асинхронщину! потому что подгоняешь, работает, но проект совсем не поддерживаемый, т.к. что-то поменял, все перекомпилилось и привет, мути с новыми задержками.
я не просто повторяю чьи-то слова, я вам конкретно говорю: почитайте про метастабильность и time domains, когда вам это станет понятно, станет понятно и все, с чем я тут с вами спорю.

а сетовать на "но оно же работает!!11" - глуповато. работает, но это подгонка на глаз;) к тому же, работать _может_ нестабильно.

0

@Ymk

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

0

@tyzord66

Ymk, не фабрикуйте факты!
Опыта я набирался не с виртуальной, а реальной логикой.
Ждем Вашего "стабильного" и "подогнанного НЕ на глаз" устройства, а пока это только колебания воздуха.

0

@Ymk

а я жду, когда вы прочитаете и выскажете свое мнение по поводу метастабильности. это наоборот не виртуальная, а самая реальная логика. хотите шаманить - шаманьте, дело ваше:)

0

@tyzord66

Значит дискуссия стихийно продолжается :). Не буду утверждать, только предположу, исходя из – «time domains», «…что-то поменял, все перекомпилилось…», «…отлаживать баги (подгонять на глаз).», для Вас не существует иного способа синтезировать цифровое устройство кроме как описать его с помощью Hordware Dessription Language. Великий соблазн любого программиста овладеть навыками электронщика не вникая в электротехнические тонкости путем программного описания алгоритма. И если им все таки удается осознать, что в отличии от классической программы в xHDL/Verilig все «процедуры» выполняются одновременно, то некоторые понятия как метастабильность для них становятся настоящим откровением. Рсчет временнЫх характеристик «переходных процессов в КС» производится параллельно с синтезом самой КС. ПЛИС так же как и вариации HDL существовали не всегда. Синтез цифровых схем производился решением систем логических уравнений, минимизацией переключательных функций КНФ/ДНФ и Диаграмм Вейча. Метод не самый быстрый, зато четко представляет схему и время распространения сигнала! Это по поводу метастабильности и других переходных процессов. Если Вы предполагаете, что можно четверть века работать с цифровыми схемами и не представлять как функционирует триггер ….!? Господа, здесь классный форум, есть чему поучиться, не взирая на опыт, много толковых людей, но меньше всего хотелось обсуждать прописные истины.

0

@Ymk

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

но у меня до сих пор ощущение, что про согласование time domains в плис вы нихрена не вкурили. если бы вкурили (вникая в электротехнические тонкости, блджад), дальнейшего бы вопроса не возникло.

0

@tyzord66

Я не могу понять, чего Вы добиваетесь? ОТКУДА? ГДЕ Вы взяли фразу "слишком быстрой реакции плис"? Покажите где я на это сетую! ? Я уже Вам сказал «НЕ ФАБРИКУЙТЕ ФАКТЫ», Вы это видели? О чем это говорит?
Разговаривают два мужика, подходит незнакомец, долго стоит молча слушает, вдруг изрекает:-«Ой, не морочьте мне голову», разворачивается, уходит. :)
О метастабильности я Вам рассказал, а с time domains разбирайтесь сами. Все, точка.

0

@Ymk

вот как все было:
звон-звон-звон, скоростная плис...
опять звон-звон-звон, скоростная плис...
и тут вы поддерживаете эту идею со звоном, ни разу от вас не было слышно идеи, как правильно спроектировать схему, чтобы от звона избавиться. вы с этим звоном (ака скоростная плис) согласились, не сказали, как этого можно (нужно) избежать.
это тоже интересный момент. хорошая схема в плис (вся!!!) ДОЛЖНА тактироваться отдельным своим генератором, а вот строб с тюнера (внешний!) НЕ должен поступать на вход триггера внутри плис, это и есть асинхронщина. тогда у вас и будет дребезг (ака звон-звон-звон), гонки и все что угодно. и вы можете шаманить с задержками и еще городить хз какой огород. работать будет, но это будет слабо поддерживаемый продукт, такой же как написанная прошивка на ассемблере с грязными хаками "а вот как я могу!" или "о, а вот так вроде не глючит О_о".

tyzord66 писал(а): я-то с ними разобрался, а вот вы...

хотите конструктива - рисуйте сигнал, обсудим.

0

@tyzord66

звон-звон-звон, скоростная плис...
опять звон-звон-звон, скоростная плис...

Ага, так значит слова таки были не мои.

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

Вот в этом месте Вы и «передернули» :)

Ymk"] тогда у вас и будет дребезг (ака звон-звон-звон), гонки и все что угодно. и вы можете шаманить с задержками и еще городить хз какой огород.[/QUOTE]

Вы очень хлопотный собеседник, поэтому перейдем к конкретике. По этой ссылке - http://www.sm.bmstu.ru/sm5/n4/oba/gl1.html находится статья, чтоб не было разночтений, конкретно по CPLD семейства MAX. Т.к. у Вас проблема с простым прочтением поста на форуме, не буду перенапрягать Ваше внимания и процитирую фрагмент (из этой статьи) :)

«Кроме того, можно задать режим пониженной скорости переключения ЭВВ (Slew Rate Control), что позволяет снизить “звон" от высокой скорости переключения, правда ценой 5нс задержки.»

Извините, вынужден перефразировать – для снижения «звона» искусственно затягивается фронт на 5nS. Речь идет о внутренних связях в самой ПЛИС, которыми ,казалось, можно было бы и пренебречь из-за ничтожно малых емкостей. А теперь представьте себе гигантских размеров внешний шлейф.

Ymk"]хотите конструктива - рисуйте сигнал, обсудим.[/QUOTE]

Вся информация о сигнале - http://www.google.ru/url?sa=t&rct=j&q=e ... CA&cad=rjt
По прежнему жду Вашего рабочего варианта, предъявите – поговорим на равных , а пока…

0

@Ymk

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

далее, про семейство MAX я в курсе, и даже немного баловался с ними. и про slew-rate в курсе, только я вам в отличии от хз какой статьи процитирую даташит:
т.е. это относится ТОЛЬКО к выходному сигналу, каким боком это связано с нашим спором, где мы обсуждаем, как правильно работать со входами?

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

0