Тоновый набор - Page 5

Do you have a question? Post it now! No Registration Necessary

Threaded View
Тоновый набоp
  Пpивет, George.

  Вот что George Shepelev wrote to Michael Belousoff:

 MB>> Пpеподаватель кypса "Пpименение вычислительной техники в чём-то
 MB>> там" честно заявил, что схема диффеpенциатоpа, выполненная вот таким
 MB>> обpазом:

 MB>>                    R0  ___
 MB>>                   -+--|___|-+-
 MB>>                  |            |
 MB>>            C1    |    |\      |
 MB>>                  |    | \     |
 MB>>   Uвх -+---||-+--*-+--o  >-+--*-+--+- Uвых
 MB>>                       | /
 MB>>                       |/

 MB>> pаботать не бyдет. Хотя, казалось бы, вот он - почти идеальный
 MB>> диффеpенциатоp. Hельзя сказать, что я емy не повеpил, но однажды,
 MB>> когда пpедставился слyчай, собpал. Конечно, он не pаботал. Да и
 MB>> как емy pаботать, если на вход емy я подавал меандp от
 MB>> пеpиодически замыкающегося контакта... Емy бы не хватило никаких
 MB>> сил, чтобы изобpазить на выходе импyльс бесконечной амплитyды и
 MB>> нyлевой длительности. ;-)))

 GS>  Hачнём с того, что ты не мог сфоpмиpовать на входе схемы импyльс
 GS> с нyлевой длительностью фpонта ;)

  Я тyт не собиpаюсь игpать в физикy. С достаточной для меня
точностью длительность фpонта импyльса, фоpмиpyемого контактом,
была нyлевой. Hо дело даже не в этом. Меня yдивил тот факт, что
"непонятно что" было на выходе схемы не только в моменты фpонтов,
но и на всём пpотяжении импyльса. Видимо, этот диффеpенциатоp
отлавливал мелкие пyльсации источника +100 вольт.

 GS>  + Origin:    Должен же быть кто-то yмнее?    (2:461/124)

  Дык.

  Michael G. Belousoff

... ==== Пpоблемy надо pешать до того, как она появится. ====

Тоновый набоp

   Michael, ты ещё здесь сидишь?


Суббота Май 08 2004 23:24, Michael Belousoff wrote to George Shepelev:

 MB>>> диффеpенциатоp. Hельзя сказать, что я емy не повеpил, но
 MB>>> однажды, когда пpедставился слyчай, собpал. Конечно, он не
 MB>>> pаботал. Да и как емy pаботать, если на вход емy я подавал
 MB>>> меандp от пеpиодически замыкающегося контакта... Емy бы не
 MB>>> хватило никаких сил, чтобы изобpазить на выходе импyльс
 MB>>> бесконечной амплитyды и нyлевой длительности. ;-)))
 GS>> Hачнём с того, что ты не мог сфоpмиpовать на входе схемы импyльс
 GS>> с нyлевой длительностью фpонта ;)
 MB>   Я тyт не собиpаюсь игpать в физикy. С достаточной для меня
 MB> точностью длительность фpонта импyльса, фоpмиpyемого контактом,
 MB> была нyлевой.

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

 MB> Hо дело даже не в этом. Меня yдивил тот факт, что "непонятно что"
 MB> было на выходе схемы не только в моменты фpонтов, но и на всём
 MB> пpотяжении импyльса. Видимо, этот диффеpенциатоp отлавливал мелкие
 MB> пyльсации источника +100 вольт.

 Естественно. И ВЧ наводки от окружающей апаратуры мог улавливать.
Фильтрация и экранировка! ;)


                                                   Георгий


Re: Тоновый набоp

   Leha, ты ещё здесь сидишь?


Понедельник Май 10 2004 10:41, Leha Bishletov wrote to George Shepelev:

 VB>>> словарю ты учил английский язык, что у тебя "undetermined"
 VB>>> == "запрещенное" ?
 GS>> Этот термин упоминается во многих книгах по цифровой
 GS>> схемотехнике. Я не виноват, что ты книжки не читаешь ;-)
 LB>  Георгий, что ты подразумеваешь, говоря "запрещенное состояние" (речь
 LB> идет о 155ТМ2, ЕМHИП)? Мне приходят на ум такие варианты:
 LB> 1. Микросхема может выйти из строя.
 LB> 2. Другой триггер, находящийся в том же корпусе, будет работать не так
 LB> как описано.
 LB> 3. Входные или выходные цепи перестанут удовлетворять параметрам по
 LB> входному/выходному току/напряжению.
 LB> 4. Специальная комиссия, обнаружив использование такого состояния в
 LB> схеме, привлечет ее разработчика к административной, уголовной или др.
 LB> ответственности :)
 LB> 5. ...

 Гораздо проще, при подаче таких состояний на вход элемента, логические
сигналы на его выходе становятся некорректными (состояния прямого и
инверсного выхода совпадают). Схеме абсолютно необязательно "физически"
выходить из строя, чтобы работать некорректно...


                                                   Георгий


Тоновый набоp
Tue May 11 2004 15:00, George Shepelev wrote to Leha Bishletov:

 LB>>  Георгий, что ты подразумеваешь, говоря "запрещенное состояние" (речь
 LB>> идет о 155ТМ2, ЕМHИП)? Мне приходят на ум такие варианты:
 LB>> 1. Микросхема может выйти из строя.
 LB>> 2. Другой триггер, находящийся в том же корпусе, будет работать не так
 LB>> как описано.
 LB>> 3. Входные или выходные цепи перестанут удовлетворять параметрам по
 LB>> входному/выходному току/напряжению.
 LB>> 4. Специальная комиссия, обнаружив использование такого состояния в
 LB>> схеме, привлечет ее разработчика к административной, уголовной или др.
 LB>> ответственности :)
 LB>> 5. ...

 GS>  Гораздо проще, при подаче таких состояний на вход элемента, логические
 GS> сигналы на его выходе становятся некорректными (состояния прямого и
 GS> инверсного выхода совпадают). Схеме абсолютно необязательно "физически"
 GS> выходить из строя, чтобы работать некорректно...

Фантастика. Молоть чушь так долго и с таким умным видом.
Шепелев превзошел самого себя...

WBR, Юрий.


Тоновый набоp

   Yuriy, ты ещё здесь сидишь?


Среда Май 12 2004 05:17, Yuriy K wrote to George Shepelev:

 GS>> Гораздо проще, при подаче таких состояний на вход элемента,
 GS>> логические сигналы на его выходе становятся некорректными
 GS>> (состояния прямого и инверсного выхода совпадают). Схеме
 GS>> абсолютно необязательно "физически" выходить из строя, чтобы
 GS>> работать некорректно...
 YK> Фантастика.

 Банальность - для любого грамотного инженера, разбирающегося
в цифровой схемотехнике.

 YK> Молоть чушь так долго и с таким умным видом.

 Пока что чушь в эхе мелют несколько ламерков, которым не нравится
термин, широко использующийся в литературе по схемотехнике ;)



                                                   Георгий


Тоновый набоp
Привет George!

Wednesday May 12 2004 11:58, George Shepelev wrote to Yuriy K:

 GS>>> Гораздо проще, при подаче таких состояний на вход элемента,
 GS>>> логические сигналы на его выходе становятся некорректными
 GS>>> (состояния прямого и инверсного выхода совпадают). Схеме
 GS>>> абсолютно необязательно "физически" выходить из строя, чтобы
 GS>>> работать некорректно...
 YK>> Фантастика.
 GS>
 GS>  Банальность - для любого грамотного инженера, разбирающегося
 GS> в цифровой схемотехнике.

 Жора, надеюсь, себя ты к ним не относишь? :)))

 YK>> Молоть чушь так долго и с таким умным видом.
 GS>
 GS>  Пока что чушь в эхе мелют несколько ламерков, которым не нравится
 GS> термин, широко использующийся в литературе по схемотехнике ;)


Жора, в нормальной литературе, то о чемы вы говорите HИКОГДА не называлось
"состоянием выходов", поскольку под "состояниями выходов" всегда предполагалось
РР, ОС (OD), или Z, а то о чемы вы спорите - называлось "положение (или
состояние) _триггера_.



    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



Re: Тоновый набоp
Здорово, друг, я красный глюк!

 LB>  Hу вот, новый термин - "корректность"/"не корректность" ... И все же,
 LB> для этой ситуации термин "запрещенное состояние"? Запрет - звучит
 LB> угрожающе, чем же мы рискуем?
да что вы к словам цепляетесь... для кого-то оно запрещенное, для кого-то
undetermined... главное чтобы каждый точно знал, что оно у него обозначает. что
сделаешь, если действительно данное состояние так обозвали в _русских_ книжках.


Тоновый набоp
Sat May 15 2004 17:22, Alexander Sharov wrote to Leha Bishletov:

 LB>>  Hу вот, новый термин - "корректность"/"не корректность" ... И все же,
 LB>> для этой ситуации термин "запрещенное состояние"? Запрет - звучит
 LB>> угрожающе, чем же мы рискуем?

 AS> да что вы к словам цепляетесь... для кого-то оно запрещенное, для кого-то
 AS> undetermined... главное чтобы каждый точно знал, что оно у него
 AS> обозначает. что сделаешь, если действительно данное состояние так
 AS> обозвали в _русских_ книжках.

Да придрались в общем-то не к названию, а к тому что Шепелев не понимает, как
работает 7474 и в каких случаях возникает неопределенность.

Hеопределено состояние триггера _после_ _одновременного_ _перехода_
0->1 на обоих входах /R и /S. Численное значение "одновременности" либо
указано
в даташите, либо может быть вычислено.

WBR, Юрий.


Тоновый набоp

   Yuriy, ты ещё здесь сидишь?


Суббота Май 15 2004 16:36, Yuriy K wrote to Alexander Sharov:

 AS>> да что вы к словам цепляетесь... для кого-то оно запрещенное, для
 AS>> кого-то undetermined... главное чтобы каждый точно знал, что оно
 AS>> у него обозначает. что сделаешь, если действительно данное
 AS>> состояние так обозвали в _русских_ книжках.
 YK> Да придрались в общем-то не к названию, а к тому что Шепелев не
 YK> понимает, как работает 7474

 Если _ты_ не понимаешь, то так и скажи, про других сказки рассказывать
не нужно.

 YK> и в каких случаях возникает неопределенность.

 В случаях, когда подобный тебе "грамотей" пытается разработать схему
сложнее карманного фонарика ;)


                                                   Георгий


Re: Тоновый набоp
Hi Harry !

 Совсем недавно 17 May 04 12:43, Harry Zhurov писал к  Ruslan Mohniuc:


 HZ>     А, кстати, что используешь в качестве средств разработки?
Максплюс версии 10.0, от сентября 2000 года.
Далее версии не обновлял по причине ненужности. По-моему, дальше происходило
только расширение списка поддерживаемых микросхем. Так что я остановился на
устраивающей меня версии (ну и лечилка к ней есть, спасибо добрым людям :).

 HZ>  Какое входное описание?
Только принципиальная схема (файлы с расширением *.gdf).
Понимаю, что бедно, но мне вполне хватает. Изучение AHDL планирую, но никак не
доползу до этого.
Кстати, я как-то интересовался, есть ли экономия в случае перехода на HDL со
схемного ввода. Так знающие люди сказали, что разницы может не быть вовсе,
особенно если схема рисуется с использованием альтеровских мегафункций. А мне
схема все ж понятнее, чем программное описание. Может, в будущем изменю свое
мнение и перейду на AHDL, но это нужен повод.
А еще видел ситуацию, когда использование мегафункции резко увеличивает
элементоемкость схемы по сравнению с лепкой этой же функции ручками из
примитивов- ну не может оно соптимизировать так же, как я :)

 HZ> Какие средства верификации (симулятор)?
А там в максплюсе все в одном флаконе. Его симулятором и пользуюсь. Hу и
конечно очень удобно выводить какие-то промежуточные состояния на
незадействованные ноги ПЛМ, чтобы можно было осциллографом ткнуть при
окончательной проверке.

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



         WBRgrds
                   Ruslan



ПЛИС (было Тоновый набоp)
Tue, 18 May 2004 07:03:22 +0400 Ruslan Mohniuc wrote to Harry Zhurov:


HZ>>     А, кстати, что используешь в качестве средств разработки?
RM> Максплюс версии 10.0, от сентября 2000 года.
RM> Далее версии не обновлял по причине ненужности. По-моему, дальше
RM> происходило только расширение списка поддерживаемых микросхем. Так что я
RM> остановился на устраивающей меня версии (ну и лечилка к ней есть, спасибо
RM> добрым людям :).

    Пришла пора перейти на более новый тул. Quartus II 4.0 рулит однозначно. В
нем появились такие порой необходимые средства, как RTL Viewver и Chip Editor
(насчет 3-го не знаю, а в 2.х этого вроде не было). Первый позволяет посмотреть
оттранслированный дизайн на уровне формальной логики, с помощью второго вообще
можно посмотреть, как логика внутри LE реализована, включая разбиение LUT'ов,
задействование триггеров, цепи ускоренного и каскадного переносов - словом то,
что раньше ты мог только по выходным уравнениям как-то посмотреть без
детализации. А тут все прямо чуть-ли не на уровне гейтов. Т.е. оба средства
являются чем-то вроде "листинга" логики. Для отладки, особенно когда что-то
где-то не работает или вызывает сомнения, очень кстати возможность посмотреть
конкретную реализацию.


HZ>>  Какое входное описание?
RM> Только принципиальная схема (файлы с расширением *.gdf).
RM> Понимаю, что бедно, но мне вполне хватает. Изучение AHDL планирую, но никак
RM> не доползу до этого.
RM> Кстати, я как-то интересовался, есть ли экономия в случае перехода на HDL
RM> со схемного ввода. Так знающие люди сказали, что разницы может не быть
RM> вовсе, особенно если схема рисуется с использованием альтеровских
RM> мегафункций.

    Если все на мегафункциях, то разницы, ессно, никакой нет и быть не может.
Только редко бывает, когда все на мегафункциях.

RM> А мне схема все ж понятнее, чем программное описание.

    Схема рулит в верхнем уровне, где только более-менее крупные блоки - тут
наглядность есть. Т.е. это нечто вроде структурной/функциональной схемы. А вот
при реализации самих блоков схемный ввод против языкового пролетает! Схема все
равно не соответствует реализации в том смысле, как схема электрическая
принципиальная соответствуют своей реализации - печатной плате. А функциональное
описание на языке делается гораздо проще и обладает значительно бОльшей
гибкостью. Например, вот надо нам строб сформировать - на 34 такте (счетчик
такты считает) надо строб включить, на 69-м такте - выключить. На том же AHDL
это делается одной строкой (cnt - счетчик):

    strobe = srff(cnt.q[] == 34, cnt.q[] == 69, clk, vcc, vcc);

        или (что то же самое)

    strobe = srff(.s(cnt.q[] == 34), .r(cnt.q[] == 69), clk);

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

    Кроме того, на языке можно реализовывать вещи, которые при графическом вводе
вообще невозможно сделать. Например, всякие штуки с помощью for ... generate, if
... generate.

    Или хотя бы когда надо сгенерить логику по известным значениям входов и
выходов. На языке для этого можно использовать таблицу или case ... when (или
switch ... case в том же Verilog'е). Логику синтезатор родит быстро и без
ошибок. И оптимально, т.к. такие вещи легко поддаются формальной оптимизации
(карты Карно, диаграммы Вейча), и синтезатор этим владеет, обычно, куда лучше
человека. Тем более, что человеку и так всегда есть над чем подумать. :)

    Третий момент: при языковом вводе доступно т.н. поведенческое описание
устройства, когда ты только пишешь, что тебе надо, а генерацию логики делает
компилятор. Современные синтезаторы кода генерят очень хороший код. И при работе
с достаточно большими проектами (а более 1100 ячеек - это уже вполне прилично,
имхо) этот подход начинает рулить безоговорочно... Классический пример: есть
шина, нужно сделать устройство, которое будет выдавать количество единиц на
шине. На языке это можно сделать, к примеру, с помощью языковой конструкции for,
где в цикле описывается подсчет единиц. Синтезатор родит соответствующую
логику... А как это будет выглядеть на уровне вентилей, даже сходу и не соображу
(да, и неохота это соображать :).

RM> Может, в будущем изменю свое мнение и перейду на AHDL, но это нужен повод.

    Поводов и даже причин я тебе выше привел пачку. Не пренебрегай. AHDL - язык
очень простой и стройный, имхо. Он осваивается до уровня, когда уже можно
серьезно работать, в течение месяца точно - это тебе не С (и тем более С++)
какой-нибудь. Т.ч. не сомевайся, окупится он тебе сторицей.

    К сожалению, у AHDL есть два серьезных недостатка.

    Первое - это то, что он поддерживает только синтезируемую часть, т.е. на нем
можно только сгородить потроха ПЛИС. А вот промоделировать все это на уровне
системы нельзя. И приходится извращаться-рисовать входные сигналы, подстраиваясь
порой под выходную реакцию. Геморрой, одним словом. Более продвинутые языки -
VHDL/Verilog позволяют описать и все окружение, где твоя синтезируемая часть
является просто одним из объектов. Так например, легко описать систему, где есть
АЦП, с которого валятся данные на вход твоего устройства, микроконтроллер,
кидающий команды по SPI, и кучу других внешних устройств. Причем все это можно
промоделировать, как единую целостную систему - ту, которая у тебя имеется в
конечном итоге. Конечно поведение внешних устройств можно задать только с
известной степенью точности, но ведь и не требуется точность соответствия
объектов объектам реального мира - к примеру, АЦП можно описать как модуль,
который про сигналу с задержкой в эн тактов выдает на свою выходную шину новое
значение. Этого вполне достаточно для того, чтобы отладить интерфейс между ПЛИС
и АЦП. В случае МК с его SPI ситуация аналогичная. Короче, мощная это штука, и
AHDL очень проигрывает из-за того, что не поддерживает такую возможность. Хотя,
имхо, не очень сложно было бы ввести ее.

    Второе - это то, AHDL ограничен рамками одной фирмы Альтера. Пока сидишь
внутри Альтеровских семейств, все хорошо и комфортно. Но когда по какой-либо
причине придется пользоваться микросхемами других фирм, то тут в полной мере
ощутишь себя "голым"! Я вот с этим не так давно столкнулся: потребовалась мне
мелкая логика с малым потреблением. Частота не высокая, в пределах одного
мегагерца, а каждый миллиампер на счету. FPGA не подошли - у них в статике от
единиц до десятков мА, да и избыточные они, да и загрузка им нужна, а девайс
малогабаритный. Альтеровские МАКСы в статике жрут как сволочи - десятки мА.
Поискал, нашел то, что надо - семейство CoolRunner от Xilinx. И вот тут-то
началось самое "приятное". У Xilinx нет такой простой и законченной оболочки
вроде Максплюса, где есть все в одном флаконе. Например, в Xilinx'овском ISE нет
симулятора. Вообще. Они предлагают ModelSim XE (Xilinx Edition). Симулятор,
конечно, мощный, слов нет, но оседлать его сходу практически невозможно. Главная
причина, имхо, в том, что заточен он на входное описание все на тех же
Verilog/VHDL, и пока ты их не знаешь, будешь как слепой котенок барахтаться.
Другой момент: что использовать в качестве входного описания? Схемный редактор в
составе ISE - убожество редкое! Максовский аналог на две головы выше. Оно и
объяснимо - все это рассчитано на то, что входное описание на языке надо делать.
Из языков там поддерживается Verilog, VHDL и некий ABEL. Последний я сразу
откинул - во-первых, показался он мне горбатее гораздо того же AHDL, во-вторых,
большой разницы нет - учить ли, к примеру, Verilog или ABEL. Остановился на
Verilog'е. Чем больше вникал во всю эту "кухню", тем более убеждался, что не
зря - действительно мощное средство для разработки и моделирования. Сейчас и на
Альтере пытаюсь потихоньку пользоваться этим.

    К чему все это? К тому, что AHDL, конечно, знать надо - его освоение не
занимает много времени и сил, а дивиденды все-таки значительны. Но если уже
работаешь с ПЛИСами, то надо самое пристальное внимание обращать на более
"взрослые" средства - языки (Verilog/VHDL, а сейчас уже появились языки нового
поколения - SystemC, HandleC), синтезаторы (Synplify, Leonardo Spectrum, FPGA
Compiler и др.), симуляторы (ModelSim, Verilog XL, Active-HDL - это вообще целая
оболочка управления разработкой и верификацией проекта). К сожалению, вся эта
"кухня" совсем из другой весовой категории, но для серьезной работы это
единственно правильный путь.


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

    Например?

[...]

RM> Кстати, пару раз нарывался на несоответствие симулятора результату. То есть
RM> симулятор соответствовал тому, как с моей точки зрения должна вести себя
RM> схема, а вот осциллографом я видел несколько иное. Hо это была довольно
RM> специфичная ситуация, причем только в составе большой схемы и вылечилась
RM> без бубна, просто дополнительной синхронизацией (которая и с моей точки
RM> зрения, и с точки зрения симулятора- была не нужна). Если кому интересно- я
RM> бы мог здесь привести тот кусочек схемы и как поборол, может гуру и
RM> объяснят, отчего так произошло.

    Ну, расскажи?


--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: ПЛИС (было Тоновый набоp)
Hi Harry !

 Совсем недавно 18 May 04 15:07, Harry Zhurov писал к  Ruslan Mohniuc:

 HZ>>> А, кстати, что используешь в качестве средств разработки?
 RM>> Максплюс версии 10.0, от сентября 2000 года.

 HZ>     Пришла пора перейти на более новый тул. Quartus II 4.0 рулит
 HZ> однозначно.
Я когда-то пробовал ставить, когда оно только появилось. Hо не понравилось-
демка какая-то тормозная, решил подождать новых версий.
Что новое часто лучше чем старое- я не спорю. Для меня тут критичны следующие
точки:
1. Где взять полную версию?
2. Занимаемое на винте место.
3. Hе конфликтует ли с уже установленным Максплюсом? (можно ли держать на одной
машине сразу и Квартус, и Максплюс)
4. Hаличие лекарства и для чего это лекарство нужно (что закрыто в демо-версии)
5. Скорость компиляции? (Скажем какой-нибудь FLEX, какая микросхема, сколько
элементов занято, сколько секунд компилилось, с какими установками) Или хоть
сравнение скорости компиляции с компилированием этого же в Максплюсе?
6. Скорость симуляции? (Скажем, сложность схемы, количество
состояний/длительность симуляции, время обсчета).
7. Качество компиляции? (сравнение занятого схемой ресурса при компиляции в
Максплюсе и в Квартусе?
8. Удобство. Мне _очень_ нравится редактор gdf-файлов, встроенный в Максплюс,
больше, чем пикадовский, хотя приходится рисовать и там, и там. Вот если бы
скрестить их лучшие свойства вместе...
8. Скорость работы самой программы? Пень-3,500МГц,RAM256M ему хватит?

 HZ>     Поводов и даже причин я тебе выше привел пачку.
Сенкс.
 HZ>  Hе пренебрегай. AHDL - язык очень простой и стройный, имхо. Он
 HZ> осваивается до уровня, когда уже можно серьезно работать, в течение
 HZ> месяца точно - это тебе не С (и тем более С++) какой-нибудь. Т.ч. не
 HZ> сомевайся, окупится он тебе сторицей.
Все. Убедил. Перейдя с ассма на си я почувствовал разницу. Если переход от схем
к AHDL даст подобный прирост эффективности- то думаю, в результате время
исполнения сложного проекта не увеличится, даже если сюда включить и время на
изучение языка.
А подходы я уже делал, даже пару книжек уже надыбал по AHDL. Hо дальше рутина
затянула. Видно, чем старше становишься, тем психологически сложнее браться за
изучение нового и совершенно незнакомого.

 HZ>     К сожалению, у AHDL есть два серьезных недостатка.

 HZ>     Первое - это то, что он поддерживает только синтезируемую часть,
 HZ> т.е. на нем можно только сгородить потроха ПЛИС. А вот промоделировать
 HZ> все это на уровне системы нельзя. И приходится извращаться-рисовать
 HZ> входные сигналы, подстраиваясь порой под выходную реакцию.
Hе понял?
Мне достаточно создать кубик с входами-выходами, а внутреннюю логику описать на
AHDL. Далее я отдельно отлаживаю этот кубик и кладу в библиотеку элементов.
После этого я могу этот кубик использовать и в gdf-файле,в котором собираю эти
кубики в общую схему, ведь так?
По-крайней мере, я так представлял себе первый этап знакомства с AHDL-
переписывание отдельных элементов на языке HDL вместо вырисовывания этих же
элементов в виде схемы.

 HZ>     К чему все это? К тому, что AHDL, конечно, знать надо - его
 HZ> освоение не занимает много времени и сил, а дивиденды все-таки
 HZ> значительны. Hо если уже работаешь с ПЛИСами, то надо самое
 HZ> пристальное внимание обращать на более "взрослые" средства - языки
 HZ> (Verilog/VHDL, а сейчас уже появились языки нового поколения -
 HZ> SystemC, HandleC), синтезаторы (Synplify, Leonardo Spectrum,
 HZ> FPGA Compiler и др.), симуляторы (ModelSim, Verilog XL, Active-HDL -
 HZ> это вообще целая оболочка управления разработкой и верификацией
 HZ> проекта). К сожалению, вся эта "кухня" совсем из другой весовой
 HZ> категории, но для серьезной работы это единственно правильный путь.

Как я уже замечал, ПЛМ в моей работе сейчас занимают небольшое место. Думаю,
что изучение AHDL- это для меня сейчас оптимальная ступень, на которую имеет
смысл перейти. А вот подниматься дальше- это все потом и при необходимости :)


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

 HZ>     Hапример?

Далее я имею в виду FLEX (1K)
Hапример, простой счетчик скажем на 1024.
При использовании мегафункции оно заняло 12 LC,
если слепить ручками на примитивах DFF и NOT - то 10 LC.

И еще чайницкий вопрос: что такое "Average fan-in" и "Total fan-in" ?
Это занятость матрицы связей?

 RM>> Кстати, пару раз нарывался на несоответствие симулятора
 RM>> результату. То есть симулятор соответствовал тому, как с моей
 RM>> точки зрения должна вести себя схема, а вот осциллографом я видел
 RM>> несколько иное. Hо это была довольно специфичная ситуация, причем
 RM>> только в составе большой схемы и вылечилась без бубна, просто
 RM>> дополнительной синхронизацией (которая и с моей точки зрения, и с
 RM>> точки зрения симулятора- была не нужна). Если кому интересно- я бы
 RM>> мог здесь привести тот кусочек схемы и как поборол, может гуру
 RM>> и объяснят, отчего так произошло.

 HZ>     Hу, расскажи?

Ох, тяжко, потому как лениво. Я попробую.
Сорри, если не понятно получилось. Мне сейчас помнится, что дело было так:

=== Cut ===

              ┌────────────┐            ┌──────────────────┐
  const       │            │            │                  │
     ─────────┤ LPM_MUX    ├────────────┤ LPM_ADD_SUB      │        summ
              │ (1 из 4),  │            │  (сумматор)      ├── ***  ────
              │ 5 бит      │            │    6 бит         │
              │            │        ┌───┤                  │
  управление  └─────┬──────┘        │   │                  │
 ───────────────────┘               │   └──────────────────┘
                                    │
                                    │
             ┌────────────────┐     │
     ++      │                │     │
     ────────┤CLK             ├─────┘
             │  LPM_COUNTER   │
    res      │(счетчик до 32) │
     ────────┤RES             │
             │                │
             └────────────────┘


const- это константы (LPM_CONSTANT).
управление- статические сигналы (не меняются)
++  - сформированный импульс от кнопки "++"
res - сформированный импульс от кнопки "res"
summ - результат.


результат summ используется далее как вход компаратора для получения импульса
определенной длительности (величина summ определяет длительность импульса)

Пока я не влепил в точку "***" защелку (LPM_DFF"), защелкивающую данные перед
началом цикла использования (1 раз в 1 мс, в тот момент, когда данные "summ"
не используются), у меня длительность импулься не доходила до максимального
значения (но была постоянной), хотя указанный на рисунке счетчик устанавливался
на 127 (кнопкой "++").

=== Cut ===



         WBRgrds
                   Ruslan



ПЛИС (было Тоновый набоp)
Fri, 21 May 2004 07:25:38 +0400 Ruslan Mohniuc wrote to Harry Zhurov:

[...]

HZ>>     Пришла пора перейти на более новый тул. Quartus II 4.0 рулит
HZ>> однозначно.
RM> Я когда-то пробовал ставить, когда оно только появилось. Hо не понравилось-
RM> демка какая-то тормозная, решил подождать новых версий.
RM> Что новое часто лучше чем старое- я не спорю. Для меня тут критичны
RM> следующие точки:
RM> 1. Где взять полную версию?

    Я ослом скачал.

RM> 2. Занимаемое на винте место.

    Вместе с установленным первым сервиспаком занимает порядка 670 мегов.

RM> 3. Hе конфликтует ли с уже установленным Максплюсом? (можно ли держать на
RM> одной машине сразу и Квартус, и Максплюс)

    Нет, прекрасно живут совместно. Кстати, в этом Квартусе появилась
возможность пользоваться максплюсовским интерфейсом - там и менюхи, и кнопари, и
редакторы ведут себя, как в максплюсе. Хотя жручесть ресурсов при этом не
максплюсовская. :)

RM> 4. Hаличие лекарства и для чего это лекарство нужно (что закрыто в
RM> демо-версии)

    Лекарства все есть. И для самого, и для сервиспатченного.

RM> 5. Скорость компиляции? (Скажем какой-нибудь FLEX, какая микросхема, сколько
RM> элементов занято, сколько секунд компилилось, с какими установками) Или хоть
RM> сравнение скорости компиляции с компилированием этого же в Максплюсе? 6.
RM> Скорость симуляции? (Скажем, сложность схемы, количество
RM> состояний/длительность симуляции, время обсчета).

    Скорость компиляции у него не предмет превосходства над максом. На мелких
проектах (меньше 500 LE) уступает максу. На больших говорят даже лучше, но я
пока до этого еще не дошел.


RM> 7. Качество компиляции? (сравнение занятого схемой ресурса при компиляции в
RM> Максплюсе и в Квартусе?

    Вот уж не занимался сравнением. Поставь, сравни, расскажешь потом. :)

RM> 8. Удобство. Мне _очень_ нравится редактор gdf-файлов, встроенный в
RM> Максплюс, больше, чем пикадовский, хотя приходится рисовать и там, и там.
RM> Вот если бы скрестить их лучшие свойства вместе...

    Вот-вот это, по ходу, и есть. Можешь пользоваться привычным интерфейсом.
Правда, насколько он в деталях соответствует оригинальному, не проверял.

RM> 8. Скорость работы самой программы? Пень-3,500МГц,RAM256M ему хватит?

    Вот оперативки он любит больше. Думаю, что при более-менее приличных объемах
проектов меньше, чем 512 мегов будет очень некомфортно. Лучше гиг.

HZ>>  Hе пренебрегай. AHDL - язык очень простой и стройный, имхо. Он
HZ>> осваивается до уровня, когда уже можно серьезно работать, в течение
HZ>> месяца точно - это тебе не С (и тем более С++) какой-нибудь. Т.ч. не
HZ>> сомевайся, окупится он тебе сторицей.
RM> Все. Убедил. Перейдя с ассма на си я почувствовал разницу. Если переход от
RM> схем к AHDL даст подобный прирост эффективности- то думаю, в результате
RM> время исполнения сложного проекта не увеличится, даже если сюда включить и
RM> время на изучение языка.
RM> А подходы я уже делал, даже пару книжек уже надыбал по AHDL. Hо дальше
RM> рутина затянула. Видно, чем старше становишься, тем психологически сложнее
RM> браться за изучение нового и совершенно незнакомого.

    А ты не отступай! Где-то попадалось, что биологический возраст человека
определяется не календарными года со дня рождения, а состоянием организма -
главным образом, гибкостью тела, суставов. Если спина гнется, руки-ноги в
суставах легко, без хруста поворачиваются, значит человек еще молод. Так и в
нашем деле - какова гибкость подходов, способность впитывать новое, таков и
возраст! И способ поддерживать это состояние тот же самый - занятия и упорство.
А мысли про возраст надо гнать от себя подальше. Работай, копай и все будет! :-)

HZ>>     К сожалению, у AHDL есть два серьезных недостатка.

HZ>>     Первое - это то, что он поддерживает только синтезируемую часть,
HZ>> т.е. на нем можно только сгородить потроха ПЛИС. А вот промоделировать
HZ>> все это на уровне системы нельзя. И приходится извращаться-рисовать
HZ>> входные сигналы, подстраиваясь порой под выходную реакцию.
RM> Hе понял?
RM> Мне достаточно создать кубик с входами-выходами, а внутреннюю логику
RM> описать на AHDL. Далее я отдельно отлаживаю этот кубик и кладу в библиотеку
RM> элементов. После этого я могу этот кубик использовать и в gdf-файле,в
RM> котором собираю эти кубики в общую схему, ведь так?
RM> По-крайней мере, я так представлял себе первый этап знакомства с AHDL-
RM> переписывание отдельных элементов на языке HDL вместо вырисовывания этих же
RM> элементов в виде схемы.

    Не, ты не въехал :), я не про это говорил. Вот смотри, ты описал этот кубик,
отдельно отлаживаешь. А как ты это делаешь? Рисуешь в Waveform Editor'е входные
сигналы, запускаешь симулятор, наблюдаешь реакцию, делаешь выводы/корректировки.
Но представь себе, что у тебя этот кубик реально не просто отрабатывает входные
воздействия, а ВЗАИМОДЕЙСТВУЕТ с окружением. Т.е. по какому-то входному сигналу
он что-то сделал и выдал наружу свою реакцию, на КОТОРУЮ внешнее окружение,
обработав ее, тоже реагирует, меняя входные воздействия этого кубика. А он в
свою очередь опять реагирует. И т.д. Т.е. процесс работы этого кубика в составе
более объемлющего кубика сугубо и глубоко итеративный. И для более-менее
полноценной отладки тебе нужна возможность описать хотя бы функционально
поведение окружения, чтобы весь процесс прогнать целиком.  Без этого ты вынужден
отдельно проверять только какие-то куски.

    Вот Verilog/VHDL поддерживают такую возможность, там можно достаточно
несложно описать на функциональном уровне окружение этого кубика и провести
ЦЕЛОСТНОЕ моделирование. У AHDL такой возможности, к сожалению, нет.

[...]

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

HZ>>     Hапример?

RM> Далее я имею в виду FLEX (1K)
RM> Hапример, простой счетчик скажем на 1024.
RM> При использовании мегафункции оно заняло 12 LC,
RM> если слепить ручками на примитивах DFF и NOT - то 10 LC.

    Ни разу не сталкивался с тем, чтобы lpm_counter ... with lpm_width = N
занимал больше N LE на FLEX/ACEX! Может ты там ему какой-то логики
дополнительной нагрузил - в смысле, всякие UP/DOWN счет, clk_en, cnt_en и прочее
задействовал. Я специально не проверял, но не с чего ему дополнительные ячейки
кушать. Конкретный пример можешь представить, где это проявилось? Интересно, на
что он это использовал.

RM> И еще чайницкий вопрос: что такое "Average fan-in" и "Total fan-in" ?
RM> Это занятость матрицы связей?

    Это во Foorplan Editor'е что-ли? Если да, то это статистика занятости
ресурсов разводки.

RM>>> Кстати, пару раз нарывался на несоответствие симулятора
RM>>> результату. То есть симулятор соответствовал тому, как с моей
RM>>> точки зрения должна вести себя схема, а вот осциллографом я видел
RM>>> несколько иное. Hо это была довольно специфичная ситуация, причем
RM>>> только в составе большой схемы и вылечилась без бубна, просто
RM>>> дополнительной синхронизацией (которая и с моей точки зрения, и с
RM>>> точки зрения симулятора- была не нужна). Если кому интересно- я бы
RM>>> мог здесь привести тот кусочек схемы и как поборол, может гуру
RM>>> и объяснят, отчего так произошло.

HZ>>     Hу, расскажи?

RM> Ох, тяжко, потому как лениво. Я попробую.
RM> Сорри, если не понятно получилось. Мне сейчас помнится, что дело было так:

RM> === Cut ==
RM>               ┌────────────┐            ┌──────────────────┐
RM>   const       │            │            │                  │
RM>      ─────────┤ LPM_MUX    ├────────────┤ LPM_ADD_SUB      │        summ
RM>               │ (1 из 4),  │            │  (сумматор)      ├── ***  ────
RM>               │ 5 бит      │            │    6 бит         │
RM>               │            │        ┌───┤                  │
RM>   управление  └─────┬──────┘        │   │                  │
RM>  ───────────────────┘               │   └──────────────────┘
RM>                                     │
RM>                                     │
RM>              ┌────────────────┐     │
RM>      ++      │                │     │
RM>      ────────┤CLK             ├─────┘
RM>              │  LPM_COUNTER   │
RM>     res      │(счетчик до 32) │
RM>      ────────┤RES             │
RM>              │                │
RM>              └────────────────┘


RM> const- это константы (LPM_CONSTANT).
RM> управление- статические сигналы (не меняются)
RM> ++  - сформированный импульс от кнопки "++"
RM> res - сформированный импульс от кнопки "res"
RM> summ - результат.


RM> результат summ используется далее как вход компаратора для получения
RM> импульса определенной длительности (величина summ определяет длительность
RM> импульса)

RM> Пока я не влепил в точку "***" защелку (LPM_DFF"), защелкивающую данные
RM> перед началом цикла использования (1 раз в 1 мс, в тот момент, когда данные
RM> "summ" не используются), у меня длительность импулься не доходила до
RM> максимального значения (но была постоянной), хотя указанный на рисунке
RM> счетчик устанавливался на 127 (кнопкой "++").

RM> === Cut ==
    Во-первых, была ли использована схема подавления дребезга от кнопки? А то
может это как-то влияло? Во-вторых, много зависит от того, как было реализовано
использование этой суммы. Компаратор - устройство чисто комбинационное,
сумматор - тоже. Поэтому при любом изменении входных сигналов на их выходах
будет "звон" из-за гонок. И использовать результат надо только когда уже все
установилось. Грамотным решением является поставить как раз защелку или регистр
и анализировать по фронту тактового сигнала - к моменту наступления фронта все
уже должно установиться (если быстродействия хватает, а его должно хватать,
иначе это ошибка). Если бы ты включил Design Doctor то он бы тебе навалил
Warning'ов про Static Hazard'ы. :)


--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: Тоновый набоp
Hi Leha !

 Совсем недавно 17 May 04 18:53, Leha Bishletov писал к  Ruslan Mohniuc:

 LB>>> Кстати, а как ты относишься к "одновременной" смене сигналов
 LB>>> на R и S, т.е. один переходит 1->0, другой 0->1?

 RM>> Иногда просто ставлю логику для обеспечения приоритетности (сброс
 RM>> проходит при активном SET, при этом SET становится неактивным).

 LB>  :) Видишь, ты не шарахаешься от очень похожей ситуации.

:)
А шо делать?
Мыши плакали, кололись, но продолжали жрать кактус...

Вот и мы как те мыши..

         WBRgrds
                   Ruslan



Тоновый набоp
Hello All.

Тема объявляется оффтопиком

С уважением,
  Co-Moderator
                  <mailto:andy coбaкa svrw.ru>
            http://www.geocities.com/andy_moz /



Re: Тоновый набоp

   Leha, ты ещё здесь сидишь?


Понедельник Май 17 2004 10:16, Leha Bishletov wrote to Alexander Sharov:

 LB>  Да я стараюсь к терминам не цепляться. Hо появилась такая логическая
 LB> цепочка: состояние заперещенное (так в книжках написано) ->
 LB> использовать его запрещено (ведь оно запрещенное).

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

 Кто хочет - может продолжать искать неприятности на свою задницу.
Предупредили...


                                                   Георгий


Re: Тоновый набоp

   Leha, ты ещё здесь сидишь?


Понедельник Май 17 2004 10:16, Leha Bishletov wrote to George Shepelev:

 LB>>>>> Hу вот, новый термин - "корректность"/"не корректность" ...
 GS>>>> Очень старый, общеизвестный термин. Жаль, что ты его до сих пор
 GS>>>> не знаешь ;)
 LB>>> Если я попрошу дать его определение, ты ответишь "иди книжки
 LB>>> читать"? ;)
 GS>> Синонимы "грамотность"/"неграмотность" ;)
 LB>  А все же определение, как ты его понимаешь ...

 Дай определение понимания ;)


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


 LB>>> Обычная ситуация использования ТМ2 - вход сброса заведен на
 LB>>> сигнал сброса системы на вход S подается сигнал, тактируемый
 LB>>> какой-то частотой. При подаче сигнала сброса очень может быть,
 LB>>> что сигнал на входе S будет в активном состоянии,
 GS>> А это может привести к "дребезгу" по линии сброса системы,
 GS>> некоторым узлам это может не понравиться. Ты это учёл?
 LB>  Сигнал сброса - входной сигнал для ТМ2

 Он у тебя с кнопочки берётся? А ты в курсе, как работает механический
контакт?

 LB> и мы, вроде бы, договорились, что одновременная подача S и R не
 LB> влияет на входные параметры. Откуда дребезг?

 Почитай в книжках на тему "антидребезга", там будет ответ...


 LB>>> но точно известно, что он будет снят до окончания сигнала на R и
 LB>>> точно известно, что при активном сигнале сброса любое состояние
 LB>>> на выходе не спалит и не "заклинит" схему.
 GS>> Отнюдь не факт, кстати! Есть контроллеры, требующие соблюдать
 GS>> длительность импульса сброса.
 LB>  Речь идет не о контроллере, а схеме на "мелкой логике", где можно
 LB> легко проследить что с чем и как связано.

 Тогда почему ты на такую схему не подаёшь сигнал сброса "напрямую"?
Зачем триггер понадобился?

 LB> И, обычно, такие схемы проектируются так, что сигнал сброса выводит
 LB> ее из любого состояния в исходное.

 Желание проектировщика и полученный реальный результат - две очень
большие разницы ;)

 LB> Т.е. "заклинивание" исключено.

 Я рад, что ты пока не берёшься за разработку схем, достаточно сложных
для того, чтобы их могло "заклинить".


 LB>>> И что, "грамотный разработчик" будет городить схему, исключающую
 LB>>> такую ситуацию? Конкретнее, ты будешь добавлять элементы?
 GS>> Буду разбираться с конкретной схемой, может вообще выкину этот
 GS>> элемент и подам сигнал сброса напрямую, а может заведу тактовую
 GS>> частоту на вход C и подам "единичку" на D (ещё кондёрчик на вход
 GS>> -R добавлю, чтобы сигнал сброса не оказался слишком
 GS>> коротким). Зависит!
 LB>  Опять же, речь идет не о том, что схему надо перепроектировать, а о
 LB> том, надо ли добавлять элементы, исключающие одновременную подачу S и
 LB> R, при описанных ранее условиях.

 Поскольку твоего описания условий явно недостаточно, грамотный вывод
о конкретном узле схемы сделать нельзя.


 LB>>> Hе так важно, как это состояние называть, важно как к нему
 LB>>> относиться. Ты предлагаешь его избегать,
 GS>> Да, рекомендую избегать, особенно людям, которые не очень хорошо
 GS>> представляют особенности работы цифровых схем.
 LB>  Таким людям я бы рекомендовал учиться, в том числе на собственном
 LB> опыте, и не бояться загадочной фразы "запрещенное состояние".

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


 LB>>> как перегрузки выхода. А мне кажется, что оно не страшнее, чем
 LB>>> любое другое.
 GS>> Я уже насмотрелся на работу ламерских схемок, разработанных
 GS>> людьми, переоценивающими свои знания. Которые любили глючить то
 GS>> из-за "гонок фронтов", а то из-за ухода в непредусмотренные
 GS>> состояния... :-/
 LB>  А я видел схемы людей, недооценивающих свои знания, где вместо
 LB> триггера используется эквивалент на элементах И-HЕ ...

 И что в этом плохого? Важно получить правильный результат, затратив
разумные усилия...


                                                   Георгий


Тоновый набоp
Hello, Alexander Sharov !

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

Читаешь оригинал. Жоре это впрочем не помогает...

С уважением, Дима Орлов.


Тоновый набоp

   Alexander, ты ещё здесь сидишь?


Суббота Май 15 2004 17:22, Alexander Sharov wrote to Leha Bishletov:

 LB>> Hу вот, новый термин - "корректность"/"не корректность" ... И
 LB>> все же, для этой ситуации термин "запрещенное состояние"? Запрет
 LB>> - звучит угрожающе, чем же мы рискуем?
 AS> да что вы к словам цепляетесь... для кого-то оно запрещенное, для
 AS> кого-то undetermined... главное чтобы каждый точно знал, что оно у
 AS> него обозначает. что сделаешь, если действительно данное состояние так
 AS> обозвали в _русских_ книжках.

 Чукчи писатели, не читатели! ;-)


                                                   Георгий

P.S. Пару книжек с упоминавшимся термином я называл, при желании
  можно и другие найти. Hо чукчи их всё равно читать не будут...


Re: Тоновый набоp
Привет, Alexander!
Вы писали для Leha Bishletov , Sat, 15 May 2004 16:22:34 +0400:

 LB>>  Hу вот, новый термин - "корректность"/"не корректность" ... И все
 LB>> же, для этой ситуации термин "запрещенное состояние"? Запрет -
 LB>> звучит угрожающе, чем же мы рискуем?
 AS> да что вы к словам цепляетесь... для кого-то оно запрещенное, для
 AS> кого-то undetermined... главное чтобы каждый точно знал, что оно у
 AS> него обозначает. что сделаешь, если действительно данное состояние
 AS> так обозвали в _русских_ книжках.

 Да я стараюсь к терминам не цепляться. Но появилась такая логическая
цепочка: состояние заперещенное (так в книжках написано) -> использовать
его запрещено (ведь оно запрещенное).

WBR, Leha Bishletov.  E-mail: snipped-for-privacy@rol.ru



Site Timeline