[Builder 1]

Я тоже работаю с видеосигналами от морских радаров. И заранее предусмотрел в проекте, чтобы FPGA выдавал тестовый видеосигнал на вход ADC со всеми положенными помехами. И если вижу на экране правильную картинку, то все окей. Кроме того, такой режим самотестирования и самодиагностики был заложен в ТЗ. Это самый очевидный пример, когда симулировать проект целиком на практике не требуется.

Не распространяйте Ваш частный случай на все ситуации. Это сродни отлаживать программу в микропроцессоре/процессоре не JTAG эмулятором а выводом в порты и ЦАП - можно, но ущербно и трудоёмко.

Я слабо представляю себе отладку Вашей методикой больших и сложных проектов, которые могут к тому-же писаться разными людьми. По сути Ваш метод предполагает разработку аппаратного окружения для тестирования, отсюда как минимум:

1) затягивание сроков разработки, т.к. настоящее тестирование начинается только после появления железа;

2) трудно контроллировать покрытие тестов;

3) окружение для тестирования может заметно усложнять систему, что неприемлемо для коммерческих проектов;

4) если проект большой/сложный/из нескольких FPGA (может быть в разных сочетаниях) - что будете делать, если будет баг, возникающий редко и хрен знает где? В xHDL это на порядок проще щемить, чем в железе. Если проект делает несколько человек, прикажете каждому дать плату, что-б тестировать проект? Или всех на одну садить?

Нет уж, увольте, я лучше 99% проекта сделаю и протестирую до того как приедет железо и в принципе не завязан на окружение - я сам могу создать любое необходимое окружение для тестирования. В любой момент разработки проекта. Хоть до прихода железа, хоть после.

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

Но это не отметает вашего подхода.

 

Зачем пользователю "идейно проникаться" тонкостями компилятора, если готовые мегафункции ADHL дают гарантированно эффективную разводку для каждой конкретного типа FPGA? Над этими мегафункциями трудились специалисты Альтеры, им и флаг в руки. А я лучше займусь прикладной сборкой из готового.

Согласен, более того, если писать адекватно, то Q конструкции VeriLog заменяет на мегафункции от Альтеры, я ничего не теряю...

 

Нет, не так ставится вопрос. Я уже писал с самого начала, что попытался использовать в своем проекте готовые корки, написанные на Verilog и получил неудовлетворительную разводку. Пришлось вникать внутрь логики и переписать эти корки на ADHL. Сразу прекрасно заработало. Из этого я делаю вывод, неквалифицированно, как в моем случае, использовать чужие модули на Verilog - невозможно. А вникать в тонкости Verilog единственно для того, чтобы править чужие модули, мне представляется неразумной тратой времени.

Если Вы пробовали VeriLog в Квартусе, а не в средах разработки/тестирования, то Вы в принципе не получаете никакого выигрыша. Всё, про что Вам говорят, действительно если проект разрабатывать/тестировать в специальных продуктах (ActivHDL/ продукты ментора и др). Я на Вашем месте сделал-бы такой-же как Вы вывод - нафигу нужно. Вся сила Verilog раскроется не на простых проектах и если проект делать в специальных средах.

[sazh 8]

Нет, не так ставится вопрос. Я уже писал с самого начала, что попытался использовать в своем проекте готовые корки, написанные на Verilog и получил неудовлетворительную разводку. Пришлось вникать внутрь логики и переписать эти корки на ADHL. Сразу прекрасно заработало. Из этого я делаю вывод, неквалифицированно, как в моем случае, использовать чужие модули на Verilog - невозможно. А вникать в тонкости Verilog единственно для того, чтобы править чужие модули, мне представляется неразумной тратой времени.

 

Ваше лукавство не знает границ. Ну какую еще неудовлетворительную разводку можно получить на базе регистра с петлей обратной связи на xor. С другой стороны то что Вы написали - никому не нужно.

Потому что не обладает унификацией не в смысле языкового подхода, а в смысле подхода к проектированию. Потому как нужен не только генератор CRC, нужен еще и чеккер. причем на базе генератора crc. Да еще и с выделением конкретной сигнатуры crc_error <= (crc_reg != 32'hc704dd7b);

Вот когда это все напишете на AHDL, тогда и увидите, какая не читаемая бредятина получилась.

И последнее. Самое главное. Для фирмы, даже Вашей - Ваш труд не имеет перспективы.

Потому что подхватить, повторить это будет некому. И не на чем.

А о коллективном подходе к работе и речи быть не может. Никому не нужен не стандартизированный язык. Это деньги на ветер.

[aprox 0]

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

1. Он предназначен только для микросхем Altera

2. Программное обеспечение подходит только фирмы Altera (насколько мне известно)

3. Описание цифровой схемы получается слишком громоздким, на мой взгляд.

 

З.Ы. Это просто мое мнение.

Присоединяюсь к вашему мнению за одним исключением. Да, язык уникален, но не мертв. Точно также жив, как и ассемблер для уникальной системы команд конкретного микроконтроллера. Но в том-то его и эффективность, что по-максимуму используется внутренняя уникальная структура FPGA! Добрые парни Алтеры освободили пользователя от необходимости знать все эти тонкости и разводить каждую трассу или CARRY-chain вручную и, одновременно, значительно приблизили процесс проектирования к уровню языка высокого уровня.

 

Да, ADHL подходит только для альтеровских FPGA. Если я ошибаюсь, то пусть меня поправят, - но в пакетах для ксайлинксов нет ничего похожего на ADHL. И поэтому ему там нашли замену в виде Verilog или VHDL. Но, согласитесь, это же не основание объявлять ADHL мертвым только потому, что в ксайлинксах преимущественно работают на другом языке.

[sazh 8]

Присоединяюсь к вашему мнению за одним исключением. Да, язык уникален, но не мертв. Точно также жив, как и ассемблер для уникальной системы команд конкретного микроконтроллера. Но в том-то его и эффективность, что по-максимуму используется внутренняя уникальная структура FPGA! Добрые парни Алтеры освободили пользователя от необходимости знать все эти тонкости и разводить каждую трассу или CARRY-chain вручную и, одновременно, значительно приблизили процесс проектирования к уровню языка высокого уровня.

 

Да, ADHL подходит только для альтеровских FPGA. Если я ошибаюсь, то пусть меня поправят, - но в пакетах для ксайлинксов нет ничего похожего на ADHL. И поэтому ему там нашли замену в виде Verilog или VHDL. Но, согласитесь, это же не основание объявлять ADHL мертвым только потому, что в ксайлинксах преимущественно работают на другом языке.

 

Да здравствует ABEL.

(Этот стон у нас песней зовется. То бурлаки идут бечевой.)

[Mahagam 0]

Но в том-то его и эффективность, что по-максимуму используется внутренняя уникальная структура FPGA!

эх какая красивая ошибка! ну просто замечательная.

простой пример: прописал я ручками на верилоге блочок памяти. писал, сдуру, шаблонами. то есть что-то типа RAMB16_S1_Sхрен его знает что там дальше. в общем - 14 бит адреса и 1 бит данных, это целиком один блочок.

но вот понадобилось мне увеличить разрядность данных в два раза, а ширину адресной шины - оставить. значит ручками правим на RAMB16_S2_... и добавляем второй блок, ну и мультиплексор на выход. а потом стукнуло в голову прописать что-то типа reg [1:0] data[16383:0] и посмотреть что там на выходе получится, а получилось хитро - два модуля RAMB16_S1 и их однобитные выводы объединились в шину. получилось и быстрее и логики меньше.

 

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

[dxp 65]

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

Ваше сравнение AHDL с ассемблером неверное. Ассемблер однозначно определяет ситуацию, там нет никаких неопределенностей, все четко детерминировано. AHDL же слишком высокоуровеневый для этого. Он такой же язык описания аппаратуры, как и Verilog c VHDL, но немногим менее абстрактный. Этим он проще, но этим же он и слабее. На сравнение с ассемблером может претендовать описание уровеня нетлиста, например, такое:

 

...
wire Add0~412_combout;
wire FinalSum[8]~105;
wire FinalSum[9]~106_combout;
wire Signal[9]~149_combout;
...
// atom is at LCFF_X21_Y11_N21
cycloneii_lcell_ff \Processor|CurrWriteAddr[22] (
    .clk(\ClkGen|PLLClkGen|altpll_component|_clk0~clkctrl_outclk ),
    .datain(\Processor|CurrWriteAddr[22]~1522_combout ),
    .sdata(\Processor|BeginWriteAddr [22]),
    .aclr(\ResetGen|q~clkctrl_outclk ),
    .sclr(gnd),
    .sload(!\Processor|RqstWr~regout ),
    .ena(\Processor|CurrWriteAddr[21]~1497_combout ),
    .devclrn(devclrn),
    .devpor(devpor),
    .regout(\Processor|CurrWriteAddr [22]));

...
// atom is at LCCOMB_X21_Y8_N10
cycloneii_lcell_comb \Processor|Add5~2081 (
// Equation(s):
// \Processor|Add5~2081_combout  = \Processor|FrameTimer [15] & !\Processor|Add5~2066  # !\Processor|FrameTimer [15] & (\Processor|Add5~2066  # GND)
// \Processor|Add5~2082  = CARRY(!\Processor|Add5~2066  # !\Processor|FrameTimer [15])

    .dataa(vcc),
    .datab(\Processor|FrameTimer [15]),
    .datac(vcc),
    .datad(vcc),
    .cin(\Processor|Add5~2066 ),
    .combout(\Processor|Add5~2081_combout ),
    .cout(\Processor|Add5~2082 ));
// synopsys translate_off
defparam \Processor|Add5~2081 .lut_mask = 16'h3C3F;
defparam \Processor|Add5~2081 .sum_lutc_input = "cin";
// synopsys translate_on
...

 

где конкретно описана ячейка (LE) со всеми сигналами и заданными локациями, т.е. местоположениями внутри ПЛИС. Вот тут описание получается однозначное и дает всегда один и тот же результат, как программа на асме. С AHDL же вы можете получать весьма разные результаты по скорости в зависимости от заполненности ПЛИС, например, что вносит элемент непредсказуемости, которого нет при использовании ассемблера. А вот на уровне нетлиста с прописанными локациями получается полная предсказуемость. Кстати, вышеприведенный код нетлиста - это Verilog. :)

 

Но в том-то его и эффективность, что по-максимуму используется внутренняя уникальная структура FPGA! Добрые парни Алтеры освободили пользователя от необходимости знать все эти тонкости и разводить каждую трассу или CARRY-chain вручную и, одновременно, значительно приблизили процесс проектирования к уровню языка высокого уровня.

Не так. Изначально AHDL появился в те времена, когда для ПЛИС фирмы Altera не было приличных синтезаторов Verilog/VHDL. Тот же Maxplus поддерживал их скорее формально, многое не умел из средств языков, а кодогенерация была неудовлетворительной. К тому же будущее этих языков в области ПЛИС было туманно. А объемы тогдашних ПЛИС были таковыми, что без полноценного моделирования (а это главный столп Verilog/VHDL) можно было вполне обойтись. Поэтому Altera создала свой язык, который был проще (прежде всего концептуально) этих двух, и для которого ей было проще создать эффективный синтезатор, тем более, что AHDL - synthesis only язык.

 

Т.е. на своем историческом этапе AHDL сыграл важную роль - благодаря простоте и высокому качеству синтеза сделал применение альтеровских ПЛИС весьма эффективным. Но в дальнейшем, по мере роста внутренних объемов ПЛИС (что позволило реализовывать на них сложные системы, а это требует уже полноценного моделирования и верификации), по мере развития синтезаторов под Verilog/VHDL, которые стали давать код, нисколько не уступающий синтезируему с AHDL (да-да, не сомневайтесь, никакие примитивы carry-chain в AHDL не дают последнему преимуществ - вас в этом пытается убедить уже достаточно много народу в течение достаточно продолжительного времени), сводит роль языка AHDL уже к исторической. Сегодня он представляет интерес скорее музейный, нежели как современного инструмента для проектирования.

[aprox 0]

Не распространяйте Ваш частный случай на все ситуации. Это сродни отлаживать программу в микропроцессоре/процессоре не JTAG эмулятором а выводом в порты и ЦАП - можно, но ущербно и трудоёмко.

Я слабо представляю себе отладку Вашей методикой больших и сложных проектов, которые могут к тому-же писаться разными людьми. По сути Ваш метод предполагает разработку аппаратного окружения для тестирования, отсюда как минимум:

1) затягивание сроков разработки, т.к. настоящее тестирование начинается только после появления железа;

2) трудно контроллировать покрытие тестов;

3) окружение для тестирования может заметно усложнять систему, что неприемлемо для коммерческих проектов;

4) если проект большой/сложный/из нескольких FPGA (может быть в разных сочетаниях) - что будете делать, если будет баг, возникающий редко и хрен знает где? В xHDL это на порядок проще щемить, чем в железе. Если проект делает несколько человек, прикажете каждому дать плату, что-б тестировать проект? Или всех на одну садить?

Работать над проектом в коллективе не пробовал, здесь вы правы. Поэтому выстроил метод, рассчитанный только на свои силы при минимальных затратах. По поводу ваших замечаний отвечу следующее:

 

по п.1. Настоящее тестирование всегда начинается только после появления железа, никакой симулятор этой ситуации не изменит.

 

по.по.2. Полное покрытие тестом устройства - это в принципе нерешаемая задача, никакой симулятор этой ситуации не изменит. Единственный выход -устранение багов в процессе сопровождения. Я свой продукт сопровождаю уже 10 лет.

 

по п.3. В моем случае все дополнительное железо для самодиагностики находится на борту устройства, по существу это системы типа LoopBack. Очень рекомендую для целей тестирования в процессе сопровождения и устранения неполадок на месте эксплуатации.

 

по п.4. Для отлова редких багов каждый модуль большого проекта заранее снабжаю ловушкой ошибок, например, как в UART. И каждый модуль имеет свой регистр статуса, из которых образуется общий статус устройства, он доступен для чтения пользователю. Hапример, для буферов FiFO не ленюсь отлавливать переполнения, для вычислительных модулей не ленюсь отлавливать переполнение сумматоров и умножителей, для входов с АЦП не ленюсь отлавливать отсутствие активности, отлов пропадания регулярных сигналов, и так далее. Короче, взял за правило- каждый мелкий модуль проекта должен отлавливать ошибки внутри себя. И в этом случае предварительная симуляция проекта целиком становится попросту излишней.

Нет уж, увольте, я лучше 99% проекта сделаю и протестирую до того как приедет железо и в принципе не завязан на окружение - я сам могу создать любое необходимое окружение для тестирования. В любой момент разработки проекта. Хоть до прихода железа, хоть после.

Позвольте сильно усомнится, что сможете создать полноценную модель окружения, адекватную реальности. Это еще никому не удавалось. Недаром в мире микроконтроллеров практически исчезли программные симуляторы. Хотя раньше, еще лет 20-ть назад, и были какие-то еще иллюзии.

Если Вы пробовали VeriLog в Квартусе, а не в средах разработки/тестирования, то Вы в принципе не получаете никакого выигрыша. Всё, про что Вам говорят, действительно если проект разрабатывать/тестировать в специальных продуктах (ActivHDL/ продукты ментора и др). Я на Вашем месте сделал-бы такой-же как Вы вывод - нафигу нужно. Вся сила Verilog раскроется не на простых проектах и если проект делать в специальных средах.

Спасибо за ценную информацию. Учту.

[andrew_b 17]

Присоединяюсь к вашему мнению за одним исключением. Да, язык уникален, но не мертв. Точно также жив,

А когда Альтера скажет: "В морг!", что вы будете делать?

[aprox 0]

Не так. Изначально AHDL появился в те времена, когда для ПЛИС фирмы Altera не было приличных синтезаторов Verilog/VHDL. Тот же Maxplus поддерживал их скорее формально, многое не умел из средств языков, а кодогенерация была неудовлетворительной. К тому же будущее этих языков в области ПЛИС было туманно. А объемы тогдашних ПЛИС были таковыми, что без полноценного моделирования (а это главный столп Verilog/VHDL) можно было вполне обойтись. Поэтому Altera создала свой язык, который был проще (прежде всего концептуально) этих двух, и для которого ей было проще создать эффективный синтезатор, тем более, что AHDL - synthesis only язык.

 

Т.е. на своем историческом этапе AHDL сыграл важную роль - благодаря простоте и высокому качеству синтеза сделал применение альтеровских ПЛИС весьма эффективным. Но в дальнейшем, по мере роста внутренних объемов ПЛИС (что позволило реализовывать на них сложные системы, а это требует уже полноценного моделирования и верификации), по мере развития синтезаторов под Verilog/VHDL, которые стали давать код, нисколько не уступающий синтезируему с AHDL (да-да, не сомневайтесь, никакие примитивы carry-chain в AHDL не дают последнему преимуществ - вас в этом пытается убедить уже достаточно много народу в течение достаточно продолжительного времени), сводит роль языка AHDL уже к исторической. Сегодня он представляет интерес скорее музейный, нежели как современного инструмента для проектирования.

Большое спасибо за историю развития языков проектирования FPGA. Убеждает. Однако, есть один момент- Verilog/VHDL для полноценного моделирования и верификации. А возможны ли они в принципе, эти полноценные моделирование и верификация? Полноценные как раз в принципе невозможны. Окончательная доводка и устранение непредвиденного все равно будет происходить в железе. Причем даже уже после сдачи продукта заказчику. Вот и спрашивается, какова цена этому моделированию и верификации.

[Mahagam 0]

по п.1. Настоящее тестирование всегда начинается только после появления железа, никакой симулятор этой ситуации не изменит.

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

 

по.по.2. Полное покрытие тестом устройства - это в принципе нерешаемая задача, никакой симулятор этой ситуации не изменит. Единственный выход -устранение багов в процессе сопровождения. Я свой продукт сопровождаю уже 10 лет.

ничего, что тестовые вектора и тестовое окружение могут рандомно генериться хоть неделю подряд? чего ж тогда все крупные конторы так свирепо развивают SystemVerilog со всякими OVM и проч?

 

по п.4. Для отлова редких багов каждый модуль большого проекта заранее снабжаю ловушкой ошибок, например, как в UART. И каждый модуль имеет свой регистр статуса, из которых образуется общий статус устройства, он доступен для чтения пользователю. Hапример, для буферов FiFO не ленюсь отлавливать переполнения, для вычислительных модулей не ленюсь отлавливать переполнение сумматоров и умножителей, для входов с АЦП не ленюсь отлавливать отсутствие активности, отлов пропадания регулярных сигналов, и так далее. Короче, взял за правило- каждый мелкий модуль проекта должен отлавливать ошибки внутри себя. И в этом случае предварительная симуляция проекта целиком становится попросту излишней.

оригинально! :a14:

первым бетатестером проекта становится заказчик! то есть звонит он через неделю и говорит - мне тут с борды сообщение пришло, типа буфер переполнился. нада чёта делать :)

а промоделировать ситуёвину что будет пи переполнении и как его избежать - не судьба?

 

Позвольте сильно усомнится, что сможете создать полноценную модель окружения, адекватную реальности. Это еще никому не удавалось. Недаром в мире микроконтроллеров практически исчезли программные симуляторы. Хотя раньше, еще лет 20-ть назад, и были какие-то еще иллюзии.

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

так что симуляция исчезла только в вашей голове.

[sazh 8]

Если Вы пробовали VeriLog в Квартусе, а не в средах разработки/тестирования, то Вы в принципе не получаете никакого выигрыша. Всё, про что Вам говорят, действительно если проект разрабатывать/тестировать в специальных продуктах (ActivHDL/ продукты ментора и др). Я на Вашем месте сделал-бы такой-же как Вы вывод - нафигу нужно. Вся сила Verilog раскроется не на простых проектах и если проект делать в специальных средах.

 

Пробовал. Синтез у Квартуса ничуть не хуже сторонних синтезаторов. И со временем все лучше.

(Это уже обсуждалось)

И симулятор тоже достойный. Но графический ввод. Что не мешает навесить на пакет сторонний.

(Все упирается в наличие навыков и знаний конкретных разработчиков)

[Builder 1]

В основном Mahagam ответил, пару мелких дополнений.

по п.1. Настоящее тестирование всегда начинается только после появления железа, никакой симулятор этой ситуации не изменит.

К тому что сказал Mahagam (на железе тестирование завершается, а не начинается), добавлю:

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

Так они ведь вообще тестируются до появления железа впринципе. Да, бывают ошибки и баг. репорты.

Но это не говорит от том что создать требуемое окружение нельзя.

Очень часто можно создать качественное окружение. Сложнее если процы снаружи есть, но это отдельный разговор.

по.по.2. Полное покрытие тестом устройства - это в принципе нерешаемая задача, никакой симулятор этой ситуации не изменит. Единственный выход -устранение багов в процессе сопровождения. Я свой продукт сопровождаю уже 10 лет.

Ну, приблизится близко можно, в вашем подходе на выходе вероятность ошибки выше.

по п.3. В моем случае все дополнительное железо для самодиагностики находится на борту устройства, по существу это системы типа LoopBack. Очень рекомендую для целей тестирования в процессе сопровождения и устранения неполадок на месте эксплуатации.

 

по п.4. Для отлова редких багов каждый модуль большого проекта заранее снабжаю ловушкой ошибок, например, как в UART. И каждый модуль имеет свой регистр статуса, из которых образуется общий статус устройства, он доступен для чтения пользователю. Hапример, для буферов FiFO не ленюсь отлавливать переполнения, для вычислительных модулей не ленюсь отлавливать переполнение сумматоров и умножителей, для входов с АЦП не ленюсь отлавливать отсутствие активности, отлов пропадания регулярных сигналов, и так далее. Короче, взял за правило- каждый мелкий модуль проекта должен отлавливать ошибки внутри себя. И в этом случае предварительная симуляция проекта целиком становится попросту излишней.

Одно другому не мешает, такие куски могут быть и в проекте на xHDL. Это не является преимуществом именно AHDL или говорить об ущербности VeriLog/VHDL.

[sazh 8]

Для отлова редких багов каждый модуль большого проекта заранее снабжаю ловушкой ошибок, например, как в UART. И каждый модуль имеет свой регистр статуса, из которых образуется общий статус устройства, он доступен для чтения пользователю. Hапример, для буферов FiFO не ленюсь отлавливать переполнения, для вычислительных модулей не ленюсь отлавливать переполнение сумматоров и умножителей

 

Что такое ловушка ошибок. На примере UART не покажите?

[Builder 1]

Пробовал. Синтез у Квартуса ничуть не хуже сторонних синтезаторов. И со временем все лучше.

(Это уже обсуждалось)

И симулятор тоже достойный. Но графический ввод. Что не мешает навесить на пакет сторонний.

(Все упирается в наличие навыков и знаний конкретных разработчиков)

Я имел ввиду то, что в квартусе IMHO нужно делать только финальный синтез/укладку.

Основной объём разработки идёт не в нём, а например ActiveHDL/Менторе - в них пишем, симуляем, тестим.

А если писать и симулять всё в квартусе, то действительно, для автора темы у Verilog не замечено преимущества перед AHDL, или скажем они минимальны. Ну, исключая конечно переносимость и потенциальную возможность уйти на нормальные среды разработки.

[jojo 0]

Все эти языки только мешают нормально работать.:) Процесс разработки похож на intrinsic'описательство в Си. В итоге половину или ресурсов, или мегаГерцев "дяде отдай".

В проектах с большим количеством микросхем это экономически заметно .

 

Первичны архитектура FPGA и place and route. :) :) Языки вторичны.

 

Вот, проектик прикрепил. Чтобы его на разные плисы перенести с максимальной частотой fmax, надо всякий раз переписать, да еще руками разместить.

test.zip