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

[Мур 1]

А можете показать какой-нибудь кусок Вашего проекта, выполненный в схематике?

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

Уже приводил...

http://electronix.ru/forum/index.php?showt...st&p=922559

bmp.bmp

[Мур 1]

На верилоге "наворотить" сдуру нельзя. Потому что разработчик _вынужден_ давать уникальные имена каждому проводу и компоненту. "Забыть" просто не получится. Это дисциплинирует.

В графике я ,в строгом смысле этого слова, не работаю. Я пишу документацию к проекту. Отличие здесь в том, что мои "картинки" не являются синтезируемыми, это - просто картинки. На которых,

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

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

 

З Ы ИМХО все эти визарды-шмизарды для создания автоматов состояний из картинок - туфта полная и замануха производителей сред проектирования. Также как и в случае топ левела до опредлённого уровня сложности

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

Какая прелесть! Именно так!...

Ждём 3D - редактор - шмизард....

 

Получается, что вы тоже, работаете в графике. Кроме MS Visio, существуют специльно приспособленные для этого среды, например HDL Designer, в котором кроме схематика имеются блок-схемы алгоритма и графы автоматов. При этом генерируется код в выбранном языке, выполняется навигация между кодом и графикой, апдейт по иерархии, свяэь с модельсимом.

Можно ссылочку на это чудо?

[slawikg 0]

Можно ссылочку на это чудо?

 

http://www.mentor.com/products/fpga/hdl_de...esigner_series/

 

[Мур 1]

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

 

Ребят, научите, как быстрее воспринимать HDL-комутации?

В схематике понятно. Слева вход,справа выход.

В коде описания интерфейсов сгрупированы отдельно от соединений. Утомляет продёргивание линий соединений между компонентами. Соединения выяснил,-что выход? Опять назад по поиску.... Пока не нарисуешь на листочке интересное место успеха не будет. Я понимаю, есть разные люди. Одни легко графику читают, другие больше аналитики(всё по-полочкам).

...Может подсветка какая с запоминанием последних просмотров?

[Maverick_ 15]

В схематике понятно. Слева вход,справа выход.

В коде описания интерфейсов сгрупированы отдельно от соединений. Утомляет продёргивание линий соединений между компонентами. Соединения выяснил,-что выход? Опять назад по поиску.... Пока не нарисуешь на листочке интересное место успеха не будет.

полностью согласен :)

Сам так делаю...

[des00 25]

Утомляет продёргивание линий соединений между компонентами.

меня не утомляет, уже писал что топ на 30-50 модулей собираю за день %)

 

ЗЫ. без ошибок естественно

[sazh 8]

что выход

 

В имени цепи (in_data, out_data).

Графику читать в топе - глухое дело.

Особенно когда зрение на старости лет садится.

По моим наблюдениям - молодежь вообще графику не воспринимает.

[Мур 1]

В имени цепи (in_data, out_data).

Графику читать в топе - глухое дело.

Особенно когда зрение на старости лет садится.

По моим наблюдениям - молодежь вообще графику не воспринимает.

В чужом, наспех написаном коде, нервы надо иметь-канаты!

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

 

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

 

Моё понимание таково, что схематик нужен, но не такой как в ISE.....

[sazh 8]

Тот листик бумаги, что остаётся на столе и есть та графика, что нужна.

 

А кому он нужен, кроме конкретного разработчика.

Мне кроме ТЗ и полного комплекта документов по ЕСКД, эта графика не нужна.

А вот на базе этих документов уже все равно - в каком виде подан конкретный проект.

[Bad0512 2]

Ребят, научите, как быстрее воспринимать HDL-комутации?

В схематике понятно. Слева вход,справа выход.

В коде описания интерфейсов сгрупированы отдельно от соединений. Утомляет продёргивание линий соединений между компонентами. Соединения выяснил,-что выход? Опять назад по поиску.... Пока не нарисуешь на листочке интересное место успеха не будет. Я понимаю, есть разные люди. Одни легко графику читают, другие больше аналитики(всё по-полочкам).

...Может подсветка какая с запоминанием последних просмотров?

1. Имя сигнала может содержать добавочную информацию. (Уже говорили об этом).

2. По умолчанию сначала в компоненте объявляем входные порты, потом выходные порты. Между этми группами вставляем пустую строчку (так глаз легче цепляется).Например :

module strict(
    input                     clk,
     
    input                    h,
    input                    v,
    input                    f,
    input     [9:0]         ydata,
    input     [9:0]         cbcrdata,
     
    output                    ho,
    output                    vo,
    output                    fo,
    output     [9:0]         ydata_out,
    output     [9:0]         cbcrdata_out
    );

3.Когда вставляем очередной экземпляр модуля, естественно поглядываем в его (модуля) описание, смотрим заголовок, объявление портов,

по-другому весьма сложно отличить вход от выхода.

[ViKo 1]

Имена должны быть информативными. Не

input h,

input v,

input f,

А - ... (?)

[Мур 1]

А кому он нужен, кроме конкретного разработчика.

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

Мне кроме ТЗ и полного комплекта документов по ЕСКД, эта графика не нужна.

А вот на базе этих документов уже все равно - в каком виде подан конкретный проект.

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

[bogaev_roman 0]

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

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

[Мур 1]

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

 

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

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

[Bad0512 2]

Имена должны быть информативными. Не

 

А - ... (?)

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

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