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> объяснят, отчего так произошло.
Ну, расскажи?