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

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-файлов, встроенный в Максплюс, больше, чем пикадовский, хотя приходится рисовать и там, и там. Вот если бы скрестить их лучшие свойства вместе...
  9. Скорость работы самой программы? Пень-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

Reply to
Ruslan Mohniuc
Loading thread data ...

Hello George.

19 May 04 23:01, you wrote to Eugene Gavruk: GS> Вторник Май 18 2004 13:57, Eugene Gavruk wrote to Leha Bishletov:

EG>> Кстати, мне приходилось видеть схемы, где сброс в 0 - нулем на R, а EG>> установка в 1 - одновременной подачей на D и C импульса. Вот это, EG>> по-моему - дурной тон,

GS> Хуже. Это саботаж ;)

Особенно если учесть что большинство триггеров в такой схеме запишут 0, а не 1...

Vladimir

Reply to
Vladimir V. Teplouhov

Hello, All !

Vladimir V Teplouhov писал к George Shepelev:

[skipped]

Вот это будет цирк...

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

Reply to
Dima Orlov

Hello Vladimir!

21 May 04 09:18, you wrote to George Shepelev:

EG>>> R, а установка в 1 - одновременной подачей на D и C импульса. EG>>> Вот это, по-моему - дурной тон, GS>> Хуже. Это саботаж ;) VT> Особенно если учесть что большинство триггеров в такой VT> схеме запишут 0, а не 1... Судя по логической схеме, в этой ситуации запишется 1 - потому что на тот элемент 3И-HЕ в потрохах, на который подходит D, подходит и C. Hо лучше не рисковать, и я всегда ставлю хоть какую-то задержку на C.

Anatoly

Reply to
Anatoly Mashanov

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'ы. :)

Reply to
Harry Zhurov

Hello Dima.

21 May 04 23:01, you wrote to Vladimir V Teplouhov: DO> Vladimir V Teplouhov писал к George Shepelev:

DO> [skipped]

DO> Вот это будет цирк...

А ты уже и вазелин приготовил и очередь занял? :)

Vladimir PS Ты мне и в соседней эхе поднадоел, так что можешь не напрашиваться, ты мне тут не интересен...

Reply to
Vladimir V. Teplouhov

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

Суббота Май 22 2004 10:05, Anatoly Mashanov wrote to Vladimir V. Teplouhov:

EG>>>> R, а установка в 1 - одновременной подачей на D и C импульса. EG>>>> Вот это, по-моему - дурной тон, GS>>> Хуже. Это саботаж ;) VT>> Особенно если учесть что большинство триггеров в такой VT>> схеме запишут 0, а не 1... AM> Судя по логической схеме, в этой ситуации запишется 1 - потому что на AM> тот элемент 3И-HЕ в потрохах, на который подходит D, подходит и C. Hо AM> лучше не рисковать, и я всегда ставлю хоть какую-то задержку на C.

Хотя куда проще и надёжнее завести на D "единицу" и не мучиться ;)

Георгий

Reply to
George Shepelev

Hello Anatoly.

22 May 04 10:05, you wrote to me: AM> 21 May 04 09:18, you wrote to George Shepelev:

EG>>>> R, а установка в 1 - одновременной подачей на D и C импульса. EG>>>> Вот это, по-моему - дурной тон, GS>>> Хуже. Это саботаж ;) VT>> Особенно если учесть что большинство триггеров в такой VT>> схеме запишут 0, а не 1... AM> Судя по логической схеме, в этой ситуации запишется 1 - потому что на тот AM> элемент 3И-HЕ в потрохах, на который подходит D, подходит и C. AM> Hо лучше не рисковать, и я всегда ставлю хоть какую-то задержку на C.

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

Vladimir

Reply to
Vladimir V. Teplouhov

Hi Harry !

Извиняюсь, что так небыстро отвечаю. Hавалилось много, а тут хочется вдумчиво ответить :)

Совсем недавно 22 May 04 11:47, Harry Zhurov писал к Ruslan Mohniuc:

HZ>>> Пришла пора перейти на более новый тул. Quartus II 4.0 рулит HZ>>> однозначно. RM>> 1. Где взять полную версию?

HZ> Я ослом скачал. Хм... Вопрос совсем чайника: что это такое? Я кроме Регета ничего не использовал. Hу да ладно. Выясню точный адрес и попрошу скачать. Hе диалапом же тянуть :)

RM>> 2. Занимаемое на винте место. HZ> Вместе с установленным первым сервиспаком занимает порядка 670 HZ> мегов. Фигня.

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

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

RM>> 4. Hаличие лекарства и для чего это лекарство нужно (что закрыто в RM>> демо-версии) HZ> Лекарства все есть. И для самого, и для сервиспатченного. ОК. если в эху нельзя, то может мне на exeplus(гав)mail.ru ? Хотя появление подобного в эхе явно положительно отразится на количестве желающих попробовать сей продукт :)

RM>> 5. Скорость компиляции? HZ> Скорость компиляции у него не предмет превосходства над максом. Hа HZ> мелких проектах (меньше 500 LE) уступает максу. Hа больших говорят HZ> даже лучше, но я пока до этого еще не дошел. Я ж говорю, потерплю. Как поставлю квартус- конечно, проверю. О результатах сообщу.

RM>> 7. Качество компиляции? (сравнение занятого схемой ресурса при RM>> компиляции в Максплюсе и в Квартусе? HZ> Вот уж не занимался сравнением. Поставь, сравни, расскажешь HZ> потом. Угу.

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

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

RM>> 8. Скорость работы самой программы? Пень-3,500МГц,RAM256M ему RM>> хватит? HZ> Вот оперативки он любит больше. Думаю, что при более-менее HZ> приличных объемах проектов меньше, чем 512 мегов будет очень HZ> некомфортно. Лучше гиг. Hу, я в свое время на 16 мегабайт EPF8452 и FLEX10K10 на первом пне крутил. Хотя по документации Максплюса памяти требуется больше. :) Hо ведь работало. Уж не знаю, во сколько раз медленнее варианта с идеальной конфигурацией железа :)

RM>> подходы я уже делал, даже пару книжек уже надыбал по AHDL. Hо RM>> дальше рутина затянула. Видно, чем старше становишься, тем RM>> психологически сложнее браться за изучение нового и совершенно RM>> незнакомого.

HZ> А ты не отступай! HZ> Так и в нашем деле - какова гибкость подходов, способность впитывать HZ> новое, таков и возраст! И способ поддерживать это состояние тот же HZ> самый - занятия и упорство. А мысли про возраст надо гнать от себя HZ> подальше. Работай, копай и все будет! :-) У меня тут есть знакомый, который более чем в два раза старше меня. Так человек в 70 лет начал разбираться с ПИКами и писать программы на ассме. :) И ведь неплохо получается (программы достаточно сложные прикладного характера, это покруче просто кнопочек-светодиодов :) Вот что значит старая школа! Hам до такой гибкости и способности впитывания нового еще расти и расти!

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

HZ> Hе, ты не въехал :), я не про это говорил. Вот смотри, ты описал HZ> этот кубик, отдельно отлаживаешь. А как ты это делаешь? Рисуешь в HZ> Waveform Editor'е входные сигналы, запускаешь симулятор, наблюдаешь HZ> реакцию, делаешь выводы/корректировки. Угу.

HZ> Hо представь себе, что у тебя этот кубик реально не просто HZ> отрабатывает входные воздействия, а ВЗАИМОДЕЙСТВУЕТ с окружением. Hе, не представляю.

HZ> Т.е. по какому-то входному сигналу он что-то сделал и выдал наружу HZ> свою реакцию, на КОТОРУЮ внешнее окружение, обработав ее, тоже HZ> реагирует, меняя входные воздействия этого кубика. То есть можно подключить к выходам кубика входы матмодели внешнего объекта, выходы матмодели объекта завести на входы кубика?

HZ> А он в свою очередь опять реагирует. И т.д. Т.е. процесс HZ> работы этого кубика в составе более объемлющего кубика сугубо и HZ> глубоко итеративный. Для меня звучит как сказка. Я ж говорю- не те книжки читаю. :)

HZ> И для более-менее полноценной отладки тебе нужна HZ> возможность описать хотя бы функционально поведение окружения, чтобы HZ> весь процесс прогнать целиком. Кстати, да. Хорошая матмодель- отдельная задача. И наверняка бывает, что построение матмодели внешнего объекта сложнее самой отлаживаемой части.

HZ> Без этого ты вынужден отдельно проверять только какие-то куски. Угу. Так по кускам и кручусь.

HZ> Вот Verilog/VHDL поддерживают такую возможность, там можно HZ> достаточно несложно описать на функциональном уровне окружение этого HZ> кубика и провести ЦЕЛОСТHОЕ моделирование. У AHDL такой возможности, к HZ> сожалению, нет. Да и ладно. Для меня это- отсутствие тех возможностей, о наличии которых никогда не подозревал. :) Так что я не знаю, сколько теряю.

А у AHDL принципиально нет возможности таких включений или это можно, но значительно тяжелее, чем в VHDL ?

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

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

Какую часть rpt-файла привести? не весь же :)

** DEVICE SUMMARY ** Chip/ Input Output Bidir Memory Memory LCs POF Device Pins Pins Pins Bits % Utilized LCs % Utilized

cnt1 EP1K10TC100-1 1 1 0 0 0 % 12 2 %

User Pins: 1 1 0

** BURIED LOGIC ** Primitive Code FBK OUT FBK DFFE + 1 0 2 DFFE + 3 0 1 DFFE + 2 0 2 DFFE + 1 0 3 DFFE + 3 0 1 DFFE + 2 0 2 DFFE + 1 0 3 DFFE + 0 0 4 AND2 4 0 4 AND2 4 0 3 DFFE + 3 1 0 DFFE + 2 0 1

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

HZ> Это во Foorplan Editor'е что-ли? Если да, то это статистика HZ> занятости ресурсов разводки. Hе, это в *.rpt- файле. У меня были случаи, когда этот ресурс заканчивался раньше, чем сами логические ячейки.

RM>>>> Кстати, пару раз нарывался на несоответствие симулятора RM>>>> результату.

HZ> Во-первых, была ли использована схема подавления дребезга от HZ> кнопки? Hу, я ж не сказал, что это вообще сигнал снаружи. Просто выдрал часть внутренней схемы и для простоты восприятия сформированные сигналы назвал "кнопками". Так что конечно никакого дребезга. И иголкам неоткуда взятся.

HZ> Во-вторых, много зависит от того, как было реализовано использование HZ> этой суммы. Компаратор - устройство чисто комбинационное, сумматор - HZ> тоже. Поэтому при любом изменении входных сигналов на их выходах HZ> будет "звон" из-за гонок. И использовать результат надо только когда HZ> уже все установилось. HZ> Грамотным решением является поставить как раз защелку или регистр и HZ> анализировать по фронту тактового сигнала - к моменту наступления HZ> фронта все уже должно установиться (если быстродействия хватает, а его HZ> должно хватать, иначе это ошибка). Да, я тоже решил, что где-то что-то внутри шумит. Меня смутило то, что симулятор это не показал. Хотя всякие иголки и промежуточные состояния (вроде наносекундных изменений величины на выходе счетчика при переключении триггеров) он как правило показывает.

HZ> Если бы ты включил Design Doctor то HZ> он бы тебе навалил Warning'ов про Static Hazard'ы. :) Да, это выключено. Попробую.

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

Привет Ruslan!

Monday May 31 2004 10:18, Ruslan Mohniuc wrote to Harry Zhurov:

HZ>>>> Пришла пора перейти на более новый тул. Quartus II 4.0 рулит HZ>>>> однозначно. RM>>> 1. Где взять полную версию? RM>

HZ>> Я ослом скачал. RM>

RM> Хм... Вопрос совсем чайника: что это такое?

e-Donkey

RM> Я кроме Регета ничего не использовал.

Это совершенно разные вещи - Регет/Вампир/Гетрайт - это просто файлотаскалки, а e-Donkey/e-Mule/etc. - это р2р сети.

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

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

formatting link
,
formatting link
, ftp://altor.sytes.net

Reply to
Alexander Torres

Mon, 31 May 2004 09:18:25 +0400 Ruslan Mohniuc wrote to Harry Zhurov:

HZ>>>> Пришла пора перейти на более новый тул. Quartus II 4.0 рулит HZ>>>> однозначно. RM>>> 1. Где взять полную версию?

HZ>> Я ослом скачал. RM> Хм... Вопрос совсем чайника: что это такое? Я кроме Регета ничего не RM> использовал.

Это есть такой способ обмена файлами между машинами, подключенными к инету. По сути дела, это, своего рода сеть. Ее так и называют на жаргоне: "Ослиная сеть". И есть соответствующая программа для работы в этой сети. Называется eDonkey. Или более новый вариант eMule. В сети есть пачка серверов, они служат для поиска. А сами файлы лежат физически на машинах. Когда тебе надо что-то найти, скачать, запускаешь поиск, сервер вываливает пачку ссылок на разные машины. По мере загруженности канала, приоритетов и прочего требуемый файл качается с разной скоростью. Скорость невелика, скачивание может растянуться на несколько дней/недель. Зато там есть то, чего просто так в инете не найдешь, как не ищи. У себя на машине тоже нужно расшарить какие-то файлы, чтобы другие чуваки тоже могли качать. Если никому ничего не отдавать, то это скажется на твоем рейтинге и тебе тоже будут хуже отдавать. Вроде так. Хотя я не очень замечаю какую-то корреляцию. Реально файл скачивается из разных источников. Чем больше источников, тем, обычно, быстрее скачается файл. Лучше всего качаются фильмы. Программы специального назначения - такие, как САПРы, качаются не очень хорошо. Квартус, например, доился почти недели три. Зато сдоился! :) И не веб, полный.

RM> Hу да ладно. Выясню точный адрес и попрошу скачать. Hе диалапом же тянуть RM> :)

:) Нет там точного адреса.

[...]

HZ>> Лекарства все есть. И для самого, и для сервиспатченного. RM> ОК. RM> если в эху нельзя, то может мне на exeplus(гав)mail.ru ? RM> Хотя появление подобного в эхе явно положительно отразится на количестве RM> желающих попробовать сей продукт :)

Ты сначала добудь пакет, потом обращайся. А то может статься, что к тому времени уже следующая версия выйдет или сервиспак, и лекарство сегодняшнее тогда будет без надобности. Главное, ты знаешь, если что, где взять.

[...]

HZ>> Т.е. по какому-то входному сигналу он что-то сделал и выдал наружу HZ>> свою реакцию, на КОТОРУЮ внешнее окружение, обработав ее, тоже HZ>> реагирует, меняя входные воздействия этого кубика. RM> То есть можно подключить к выходам кубика входы матмодели внешнего объекта, RM> выходы матмодели объекта завести на входы кубика?

Да.

HZ>> А он в свою очередь опять реагирует. И т.д. Т.е. процесс HZ>> работы этого кубика в составе более объемлющего кубика сугубо и HZ>> глубоко итеративный. RM> Для меня звучит как сказка. Я ж говорю- не те книжки читаю. :)

HZ>> И для более-менее полноценной отладки тебе нужна HZ>> возможность описать хотя бы функционально поведение окружения, чтобы HZ>> весь процесс прогнать целиком. RM> Кстати, да. Хорошая матмодель- отдельная задача. И наверняка бывает, что RM> построение матмодели внешнего объекта сложнее самой отлаживаемой части.

Все определяется точностью соответствия. Если на уровне п-н переходов описывать, то это, конечно, вилы. А если на функциональном уровне, то вполне себе приемлемо. А чаще на функциональном и достаточно - входные стимулы-то ты рисуешь исходя из функциональности системы. А тут рисовать ничего не надо, окружение само все сигналы, какие надо, сформирует. Тебе надо только описать поведение на функциональном уровне. Для более специальных случаев можно найти модели. Например, для той же памяти производители оной специально поставляют модель. С времянками. Т.е. можно процесс работы ПЛИС с памятью промоделировать.

HZ>> Вот Verilog/VHDL поддерживают такую возможность, там можно HZ>> достаточно несложно описать на функциональном уровне окружение этого HZ>> кубика и провести ЦЕЛОСТHОЕ моделирование. У AHDL такой возможности, к HZ>> сожалению, нет. RM> Да и ладно. Для меня это- отсутствие тех возможностей, о наличии которых RM> никогда не подозревал. :) Так что я не знаю, сколько теряю.

RM> А у AHDL принципиально нет возможности таких включений или это можно, но RM> значительно тяжелее, чем в VHDL ?

AFAIK, принципиально нет! :(( И оба пакета (Максплюс и Квартус) позволяют моделировать только то, что внутрь ПЛИСки помещается, т.к. только синтезируемую часть. Можно, конечно, извратиться - для моделирования (хотя бы функционального) взять указать толстенную ПЛИСину, где помимо синтезируемой части описать еще и окружение. Но, по мне, изврат этот не стОит того, когда есть более правильный путь.

[...]

RM>>>>> Кстати, пару раз нарывался на несоответствие симулятора RM>>>>> результату.

HZ>> Во-первых, была ли использована схема подавления дребезга от HZ>> кнопки? RM> Hу, я ж не сказал, что это вообще сигнал снаружи. Просто выдрал часть RM> внутренней схемы и для простоты восприятия сформированные сигналы назвал RM> "кнопками". Так что конечно никакого дребезга.

Ну, я ж не знал... :) Сказано, что кнопки, вот и подумалось.

RM> И иголкам неоткуда взятся.

А вот это не факт! Иголки не только от дребезга возникают, а, главным образом, из-за гонок. Это, в общем-то, нормальное явление и основной способ борьбы с ним - грамотный синхронный дизайн (особенно в FPGA, которые, пользуясь терминологией той же Альтеры, register rich).

HZ>> Во-вторых, много зависит от того, как было реализовано использование HZ>> этой суммы. Компаратор - устройство чисто комбинационное, сумматор - HZ>> тоже. Поэтому при любом изменении входных сигналов на их выходах HZ>> будет "звон" из-за гонок. И использовать результат надо только когда HZ>> уже все установилось. HZ>> Грамотным решением является поставить как раз защелку или регистр и HZ>> анализировать по фронту тактового сигнала - к моменту наступления HZ>> фронта все уже должно установиться (если быстродействия хватает, а его HZ>> должно хватать, иначе это ошибка). RM> Да, я тоже решил, что где-то что-то внутри шумит. RM> Меня смутило то, что симулятор это не показал. Хотя всякие иголки и RM> промежуточные состояния (вроде наносекундных изменений величины на выходе RM> счетчика при переключении триггеров) он как правило показывает.

Да, он показывает. Но он показывает исходя из заданной модели со своими времянками. А в реальном чипе эти времянки могут быть чуть другими и, кроме того, они меняются от температуры, напряжения питания и прочего. Т.ч. то, что он показывает - это скорее характеристическая картина, а не точная. Это повод и причина задуматься о возможных последствиях игнорирования мер по предотвращению влияния гонок. В общем случае надо проектировать так, чтобы исключить влияние гонок вообще - тогда различие в "иголках" не будет играть роли.

HZ>> Если бы ты включил Design Doctor то HZ>> он бы тебе навалил Warning'ов про Static Hazard'ы. :) RM> Да, это выключено. Попробую.

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

Reply to
Harry Zhurov

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

Понедельник Май 31 2004 10:18, Ruslan Mohniuc wrote to Harry Zhurov:

RM>>> 1. Где взять полную версию? HZ>> Я ослом скачал. RM> Хм... Вопрос совсем чайника: что это такое? Я кроме Регета ничего не RM> использовал.

А придётся, для пиринговых сетей другой софт нужен...

Георгий

Reply to
George Shepelev

Мужики! ЗАПРЕЩЕННОЕ состояние - это состояние ВХОДОВ (комбинация, которая недопустима на входах у-ва). НЕОПРЕДЕЛЕННОЕ состояние - это состояние ВЫХОДОВ. Трактуется как произвольное состояние выхода (выходов), либо по уровню (амплитуде), либо по лог. уровню (1 или 0). И НИКОГДА и НИГДЕ в СЕРЬЕЗНОЙ литературе эти два понятия не отождествлялись. Ибо нельзя запретить состояние выхода. А уж если разработчик не знает (у него НЕОПРЕДЕЛЕННОЕ) состояние входов, то.....

Желающий слышать - услышат, а слепой не увидит.

"George Shepelev" snipped-for-privacy@f124.n.z2.fidonet.org>

сообщил/сообщила в новостях следующее: news: snipped-for-privacy@f124.n.z2.ftn...

не

же

Reply to
Alex

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.