1. Какой способ разработки Вы используете?

[ViKo 1]

Это - стандартные сигналы строчной, кадровой и филдовой синхронизации.

В видео-related модулях часто пишут вместо hsync,vsync,fsync просто h,v,f - это как бы общепринятое сокращение.

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

[bogaev_roman 0]

А почему вариант со скудной информацией (описание не соответствует реализации-не дополнена новыми вставками, не проведены изменения) не рассматривается? Это на 90% рабочая ситуация.

Эта бумажка и есть то, что потом войдёт в новую доку. Но потом...

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

[sazh 3]

Эта бумажка

 

нигде не прописана. А значит и корректироваться будет по остаточному принципу. В соответствии с пристрастиями конкретного разработчика.

Не документ это для сдачи устройства.

Конкретный пример из чужого проекта

adc_2dac_continius adc_2dac_inst(.clk20(clk), .reset(reset), .dac_low(wire_dac_low), .dac_high(wire_dac_high), .adc(adc),
    .sclk(sclk), .csn_adc(csn_adc), .csn_dac_low(csn_dac_low), .csn_dac_high(csn_dac_high), .sdata(sdata));

 

Меня не напрягает, я знаю что и для чего.

Но это не документ, который надо предъявлять.

[Мур 1]

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

Итерационный процесс создания проекта, над которым работают несколько человек предполагает несколько этапов возврата к документации. Раз в неделю. А в основное время тесный контакт вживую....

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

[bogaev_roman 0]

Итерационный процесс создания проекта, над которым работают несколько человек предполагает несколько этапов возврата к документации. Раз в неделю. А в основное время тесный контакт вживую....

Хорошее выражение, итерационный процесс, работаю с ним уже долгое время. Делается это так: есть ТЗ, рисуется общая структурная схема, разбивается на несколько кусков, которые и раздаются трудникам. Трудники смотрят на общие интерфейсы и обговаривают между собой условия и времянки. Все это заносится также в документ. После автономной верификации проект собирает один человек и начинается совместная верификация. Если произошел сбой, то определяется в каком куске проекта и отдается на отладку труднику и он меняет только СВОЙ кусок, общая топовая документация остается неизменной. Если произошел сбой в интерфейсе, то нужно переделывать кусок, а не интерфейс. Где я здесь хоть раз возратился к начальной документации (вроде бы процесс проетирования практически завершен на данном этапе)?

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

Это уловка только для простых проектов, представьте что будет, если в проекте заняты 20 человек и каждый будет обговаривать интерфейсы "междусобой". И объясните следующее: зачем мне нужно заглядывать в процессе работы в блоки, которые делает другой человек, если с ним идет стыковка только по интерфейсам?

PS// Я еще вот чего понять не могу, грамотный RTL - это комментарии разработчика, описание различных хитрых конструкций, что где зачем и почему. Все это не заносится в документацию, где я эти комментарии в схематике буду крепить?

PSS// Схематик уже практически умер на уровне разработки, также как и AHDL. Начинают отставать даже старые стандарты verilog/vhdl по сравнению с systemverilog/systemC (в том смысле что новые стандарты поддерживают больше возможностей). Пора уже уходить от стереотипов и следить за временем, я, например, уже сейчас задумываюсь о том, что если постонно не следить за развитием и не перейти на использование system, то через несколько лет меня потеснят молодые разработчики (если только крупным начальником не буду :) ) со знанием всего нового и особожденного от мусора.

Изменено 19 мая, 2011 пользователем bogaev_roman

[Мур 1]

Конкретный пример из чужого проекта

 

А если их(модулей) много? и они на нескольких страницах...

[Kosta 0]

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

 

Лишней информация не бывает. Важно сколько времени уходит постороннему на усвоение. Какую бумажку он возьмёт в первую очередь?

 

Не надо менять разработчиков раз в неделю (месяц) :) - главное стиль и комментарии, и... как не банально контроль за соблюдением порядка в оных. Из опыта скажу - незаменимые появляются из недостатков в управлении и подборе кадров, в смысле низкой квалифакации преимущественно первого. Не верите - спросите любого программиста на C/C++ итп, из больших открытых проектов, вот костыль-схематик, на мой взгляд, это возврат даже не прошлый век, а в 30-40 годы, к лампам... Другое дело расписать блоки и их интерфейсы, и поддерживать порядок в этом хозяйстве, схематик тут не поможет. Мое убеждение насчет чистого схематика - его предел масштабы CPLD и несложных интерфейсов, хотя никто не мешает сделать и что-то посерьезнее, как в 50е никто не мешал делать компы на лампах. Но мы ведь за прогресс? Если так - нужно осваивать новые уровни абстракции, Verilog, VHDL. SуstemC,- его со временем - он пока не популярен, но дело идет к тому, что возможно, он подвинет VHDL & Verilog.

 

Итерационный процесс создания проекта, над которым работают несколько человек предполагает несколько этапов возврата к документации. Раз в неделю. А в основное время тесный контакт вживую....

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

 

Хмм, странно, кто этот "любой"? это руководитель? или разработчики HDL? которые настолько суровы и молчаливы, что кроме как нарисовать на бумаге никак не выходит?

--

Лично я голсовал за VHDL, с таким же успехом это мог быть и Verilog - принципиальной разницы между ними, для FPGA, не обнаруживаю.

[Мур 1]

Не надо менять разработчиков раз в неделю (месяц) :) - главное стиль и комментарии, и... как не банально контроль за соблюдением порядка в оных. Из опыта скажу - незаменимые появляются из недостатков в управлении и подборе кадров, в смысле низкой квалифакации преимущественно первого. Не верите - спросите любого программиста на C/C++ итп, из больших открытых проектов, вот костыль-схематик, на мой взгляд, это возврат даже не прошлый век, а в 30-40 годы, к лампам... Другое дело расписать блоки и их интерфейсы, и поддерживать порядок в этом хозяйстве, схематик тут не поможет. Мое убеждение насчет чистого схематика - его предел масштабы CPLD и несложных интерфейсов, хотя никто не мешает сделать и что-то посерьезнее, как в 50е никто не мешал делать компы на лампах. Но мы ведь за прогресс? Если так - нужно осваивать новые уровни абстракции, Verilog, VHDL. SуstemC,- его со временем - он пока не популярен, но дело идет к тому, что возможно, он подвинет VHDL & Verilog.

Всё вы правильно говорите. Теоретически... Я уже тут рассказывал, что есть конторы которые работают только в схематике. Это бред. Аналогично другая крайность. Тотальный HDL тоже неудобен в восприятии посторонними. Я за компромисс. Каждый удобен на своём уровне....

Хмм, странно, кто этот "любой"? это руководитель? или разработчики HDL? которые настолько суровы и молчаливы, что кроме как нарисовать на бумаге никак не выходит?

--

Лично я голсовал за VHDL, с таким же успехом это мог быть и Verilog - принципиальной разницы между ними, для FPGA, не обнаруживаю.

Разработчик конечно. На бумаге сразу видишь всё. В коде отдельные шнурки(сигналы) которые по отдельности продёргиваешь, чтобы увидеть что с чем соеденено. Где входы-выходы..

 

[VladimirB 1]

Всё вы правильно говорите. Теоретически... Я уже тут рассказывал, что есть конторы которые работают только в схематике. Это бред. Аналогично другая крайность. Тотальный HDL тоже неудобен в восприятии посторонними. Я за компромисс. Каждый удобен на своём уровне....

ИМХО некрасиво нарисованный другим человеком схематик, с непроименованными цепями, открытый в ISE более неудобен в восприятии чем самый запутанный HDL (там хоть цепи проименованы). А если придерживаться определённых правил при оформлении - то топлевел из HDL даст +500 в пулю и -100 с горы по сравнению со схематиком.

 

И неужели >85% которые используют HDL, не могут разглядеть преимуществ схематика, а 4% их увидели.

 

П.С. Помоему тема свелась к холивару Myp против HDL в топ-левеле.

 

 

 

[warrior-2001 0]

Тема изначально попахивала холиваром.

Дело в том, что о HDL понятие имеют всё. А говоря о "Схемотехническом вводе" все понимают что-то своё.

Исключительно в качестве информации - схема, сделанная в квартусе и схема, сделанная в HDL Designer - это две разные схемы. Во втором случае мы имеем комментарии в графике, правильные имена сигналов, цветовое и схемотехническое выделение цепей, СФ-блоков и их групп. Ввод информации в табличном виде и в виде управляющих автоматов и прочее . И всё это в любой момент конвертировать в hdl файл.

Так что ознакомившись лишь с 2 САПР я бы не стал утверждать, что схемотехника - это плохо. Более того, я знаю несколько крупных и авторитетных ВУЗов, студенты которых имеют неплохую базовую подготовку как на уровне hdl, так и на уровне схемотехники.

[Tue 0]

Уже много лет для разработки проектов ПЛИС любой сложности использую Simulink + Simulink HDL Coder

Обладает всеми плюсами схематика:

 

1) наглядность и связанная с ней простота понимания что куда идет (особенно хорошо это заметно в проектировании автоматов в StateFlow)

 

2) "Языконезависимость". В том смысле, что если придется встраиваться в команду разработчиков, которая привыкла к какому-либо одному из языков VHDL или Verilog - нет проблем, указывается кодеру язык и в путь

 

3) Сосредоточенность именно на функциональном уровне (алгоритмы, потоки данных). Пожалуй самый важный плюс.

 

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

Также например при разработке конечных автоматов и запуске моделирования Симулинк указывает и предупреждает о "мертвых" ветках и можно своевременно внести исправления. Много уже готовых блоков от простых и рутинных блоков, таких как ОЗУ, счетчики, LookUp Tables до более сложных.

 

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

Моделирование большого проекта в Симулинке быстрее моделирования RTL. При большом проекте иногда хочется посмотреть как будет вести себя контроллер/блок/узел когда через него будет прокачиваться 100, 1000, 10000 пакетов/транзаций/кадров. В таком случае помогает либо высокий уровень абстракции, либо когда собрана детализированная модель, готовая к синтезу в ПЛИС - в таком случае очень помогает Real Time WorkShop, который компилирует модель (а часто бывает, что модель состоит из большого количества подмоделей) в исполняемый exe-файл, который выполняется уже в 10-100 раз быстрее моделирования в Симулинке. Вообщем для сооружения тестового окружения для тестирования проекта очень много возможностей. Причем тестировать можно и чей-либо чужой vhdl/verilog-код, загнав его в ModelSim и использовать EDA Link for ModelSim.

 

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

 

Из минусов можно отметить следующее:

 

1) В любой ПЛИС есть специализированные блоки, такие как PLL, двуклоковое ОЗУ, двунаправленные выводы. В Симулинке этого нет. Но как показывает моя практика это не сильно мешает да и подключение таких блоков происходит уже на самой последней стадии проектирования проекта ПЛИС.

 

2) Небольшое кол-во инженеров, работающих в этой среде и в этой методологии.

 

 

Этот путь проектирования сейчас называют ESL и думаю за ним будущее. Проекты все сложнее и сложнее, скроки сжимаются. А такой путь позволяет проекты той же сложности разрабатывать быстрее, а более сложные проекты за то же время, что и менее сложный при "традиционном" способе проектирования.

[Mig&L 0]

А какова эффективность использования ресурсов кристалла при схемотехническом вводе поекта против "языкового"? И личного опыта , при необходимости "ужать" проект - переход на схемотехнику.

[Мур 1]

А какова эффективность использования ресурсов кристалла при схемотехническом вводе поекта против "языкового"? И личного опыта , при необходимости "ужать" проект - переход на схемотехнику.

Разница есть(имеется ввиду ISE)! И не в пользу схематика. Никаких триггеров и логики! Только модули! Если применять без этого ограничения в оценке предельной частоты вы обязательно получите заниженные цифры. Поэтому я и пишу всю мелочевку в HDL. Синтезатор на это реагирует лучше. Я тут уже об этом сравнении писал в цифрах.

 

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

 

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

[_sda 0]

Verilog,verilog....

У меня вот студент ввёл в модуль новую переменную,а объявить её забыл.Потом целый день искал почему модуль перестал работать. ISE даже не ругнулся. На VHDL такие номера не проходят.

[sazh 3]

Verilog,verilog....

У меня вот студент ввёл в модуль новую переменную,а объявить её забыл.Потом целый день искал почему модуль перестал работать. ISE даже не ругнулся. На VHDL такие номера не проходят.

 

В железо ввел переменную, потом в тексте "программы" ошибку искал.

VHDL не поможет, если на птичьем языке общаться. Только незнание усугубит.