Перейти к содержанию
    

Помогите разобраться

TO oval.

А Вы случаем не из тех товарищей, которые продвигают на рынок продукты Mentor Graphics.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Об чем спор? )))

HDL-Designer рулез, имеет все что надо

у нас к примеру никто не возвращается к графике, а только сборка блоков (а также рулезные embedded block- текст в графике). Маленькие и средние удобочитаемые блоки пишутся на языке.

Вообщем как всегда нужно искать золотую середину. ибо када много графики глаза сойдут с ума, када много текста мозг. ))))

 

зы: я не из таких товарищей ))). ненавижу гадов за громадные цены.

Изменено пользователем vikk

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Здесь Вы не совсем поняли общую концепцию. Все блоки внутри иерархии проекта, которые можно разделить на отдельные функционально законченные блоки (управление, передача данных и т. п.), мы оформляем как блок диаграммы (block diagram), соединяя соответствующие функционально законченные блоки между собой.

 

Т.е. получаеться что при разработке топ-левела, сначала идет разработка каркаса и одновременно его самодокументация, а уже потом "пристегиваються" функции. С этим я согласен целиком и полностью.

 

Далее каждый из функционально законченных блоков описывается как одно из представлений: алгоритм (flowchart), автомат состояний (state diagram, ASM - algorithmic state machine), таблица истинности (truth table). На высоком уровне , а не на уровне триггеров или LUT! Посмотрите примеры в составе HDL Designer, может быть станет более понятно.

 

Это я и имел ввиду, говоря об уровне абстракции компонентов - функций.

Примеры HDL designera я посмотрел, но там самый примитивизм.

 

Но вот опять же не совсем понятно как описывать параллелелизм,

т.к. используя FlowChart можно описать только логику, между 2 мя регистрами, т.е. только 1 слой. (насколько я понял доку на HDL)

 

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

Придеться много писать ручками, тогда зачем графика ?. Выделять же КА в данном случае в отдельный объект и городить к нему в графике несколько АЛУ, ИМХО тоже не вариант, кроме ряби в глазах от обилия графики ничего не даст.

 

HDL Designer как ИДЕ, очень хорошая штука, но все же закладывать разработку полностью на графику я бы не стал. Алгоритмические функции я бы писал на ХДЛ. :)

 

 

ЗЫ. Я могу ошибаться из-за недостатка опыта, поэтому все выше указанное считать как мое ИМХО.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

TO oval.

А Вы случаем не из тех товарищей, которые продвигают на рынок продукты Mentor Graphics.

Нет, я не из тех "товарищей". :) Я просто достаточно давно работаю в направлении HDL проектирования. Уже давно сделал выбор в сторону Mentor'а, возможно откажусь в пользу чего-то другого, но пока альтернатив не вижу.

 

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

Не совсем согласен. Это имеет смысл даже в случае чисто HDL проектирования. У нас, например, разработчики схематики и PCB не используют Mentor. Да, действительно одиночному пользователю официально вряд-ли доступно. Согласитесь, если здраво размыслить, то если было-бы доступно, тоже бред, не в игрушки ведь играем. Mentor, как и все фирмы, работающие в этой области должны окупать проекты и получать прибыль или как??? Проблема возможности приобретения, это проблема не Mentor'а, а фирм-разработчиков и бюджета данной индустрии в стране!

 

зы: я не из таких товарищей ))). ненавижу гадов за громадные цены.

Во всем правы, кроме последней фразы. Не за что их ненавидеть. Цены соответствуют сложности выполненной работы. У них ведь тоже все хотят получать зарплату и достойную! Повторюсь, проекты должны как минимум окупаться, но чтобы им жить и развиваться нужно еще, чтобы они и прибыль приносили. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хочу добавить к описанию, которое сделал oval: я из возможностей дизайнера, точнее из способов ввода, использую только текстовые embedded block и графическое рисование SM. Flowchart и truthtable мне легче написать на верилоге, чем графически.

Еще отмечу, что hdldesigner - очень удобная оболочка для полного ведения проекта, а не только ввода - там есть контроль версий, вызовы симулятора, синтезатора и P&R, документирование, design check, поддержка командной работы ...

Мне кажется, что отличие графического представления в hdldesigner от "схемного ввода" (например в квартусе) состоит в том, что вы имеете дело не с блоками, которые заданы вам сверху (типа микросхем серии 74LS или блоков из стандартной библ.), а разбиваете схему на блоки, удобные вам и логичные с точки зрения этого проекта. Т.е. у вас элементарным блоком в графическом представлении будет достаточно сложный компонент. Раэбивку на такие компоненты вы делаете сами; интерфейс между ними должен быть ясен и прост - проект в графическом представлении становится понятным и обозримым. Я уже как-то говорил, что попробуйте написать текстом SM на сотню состояний, а через месяц вернутся к ней - не разберетесь; нарисованная же понимается и вспоминается значительно легче.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как я понил графически не пргяться!

Посоветуйте тогда компелятор котрый бы поддерживал бы PLD 16V8 при прогрмирование на VHDL?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Во всем правы, кроме последней фразы. Не за что их ненавидеть. Цены соответствуют сложности выполненной работы. У них ведь тоже все хотят получать зарплату и достойную! Повторюсь, проекты должны как минимум окупаться, но чтобы им жить и развиваться нужно еще, чтобы они и прибыль приносили.

 

Отличная программа! Но недоступная для пользователя. Но только для ненашего пользователя!:) И хрен они получат от НАС прибыль с такими ценами!! (30 тыс уе со всякими "скидками"). Нормальной средней фирме это не по карману... Интересно, много ли у них покупают? :) Хотя при более доступной цене многие бы себе взяли FPGA Advantage ОФИЦИАЛЬНО...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Здесь Вы не совсем поняли общую концепцию. Все блоки внутри иерархии проекта, которые можно разделить на отдельные функционально законченные блоки (управление, передача данных и т. п.), мы оформляем как блок диаграммы (block diagram), соединяя соответствующие функционально законченные блоки между собой.

 

Т.е. получаеться что при разработке топ-левела, сначала идет разработка каркаса и одновременно его самодокументация, а уже потом "пристегиваються" функции. С этим я согласен целиком и полностью.

Ну в общем как-то так. Если проектировать "сверху-вниз". :)

 

Но вот опять же не совсем понятно как описывать параллелелизм,

т.к. используя FlowChart можно описать только логику, между 2 мя регистрами, т.е. только 1 слой. (насколько я понял доку на HDL)

Без привязки к логике и регистрам, - один FlowChart - один HDL процесс. Параллелизм реализуется в HDL несколькими процессами, соответственно, несколькими параллельными FlowChart (concurrent flowcharts) диаграммами (несколько параллельных диаграмм FlowChart могут входить в ОДНО представление FlowChart (FlowChart view)).

 

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

Здесь нет никакой магии :) , все как в HDL: параллельные процессы, - соответственно, несколько ASM.

Каждый этап конвейера, отдельный процесс, отдельная диаграмма (ASM, State Diagram, FlowChart). Можно конечно в определенных случаях все "скомкать" в один процесс, но это не есть хорошо.

 

Придеться много писать ручками, тогда зачем графика ?. Выделять же КА в данном случае в отдельный объект и городить к нему в графике несколько АЛУ, ИМХО тоже не вариант, кроме ряби в глазах от обилия графики ничего не даст.

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

 

Алгоритмические функции я бы писал на ХДЛ. :)

Похоже здесь идет речь о классическом понятии функции типа "корень", cos, sin. Да, естественно, такого рода функции пишуться на HDL и описываются в основном в пакетах (package). Дальше используются в FlowChart и т. п.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Похоже здесь идет речь о классическом понятии функции типа "корень", cos, sin. Да, естественно, такого рода функции пишуться на HDL и описываются в основном в пакетах (package). Дальше используются в FlowChart и т. п.

 

как раз наоборот, например собираемся сделать каконить блок, например тот же рле - кодер, работающий в data packed processing системе.

 

Разбиваем этот блок на 3 блока-функции:

1. менеджер памяти данных источника.

2. Собственно РЛЕ кодер

3. основной КА, который рулит первыми двумя и занимаеться data_flow от-но системы.

 

Я бы реализовал блок-"функцию" рле кодера в одном файле в тексте, воспользовался бы двухпроцесным подходом разработчиков LEON2/LEON3 для описания блока.

Т.к. считаю что дробить сам РЛЕ кодер на составляющие (а это будет несколько регистров, компараторов, суматоров + логика) будет не есть хорошо, т.к. работать с одним файлом легче.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Отличная программа! Но недоступная для пользователя. Но только для ненашего пользователя!:) И хрен они получат от НАС прибыль с такими ценами!! (30 тыс уе со всякими "скидками").

Повторюсь, цены вполне адекватны уровню сложности САПР! Кстати, если я не ошибаюсь у них для России (СНГ) еще и большие скидки по сравнению с Англией к примеру! ;)

 

Нормальной средней фирме это не по карману...

Sorry for offtopic :) Не в обиду будет сказано, но это не "нормальная средняя фирма", пару-тройку "палаток" в деревне приносят бОльшую прибыль. Так что, это проблема рынка hightech в нашей стране.

 

Интересно, много ли у них покупают? :) Хотя при более доступной цене многие бы себе взяли FPGA Advantage ОФИЦИАЛЬНО...

Покупают, но не много. Мы вот думаем. Очевидно, что в ближайшее время бизнес Mentor в России есть и будет убыточным. ;)

 

А более доступная цена это какая? Цена не может быть ниже себестоимости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Похоже здесь идет речь о классическом понятии функции типа "корень", cos, sin. Да, естественно, такого рода функции пишуться на HDL и описываются в основном в пакетах (package). Дальше используются в FlowChart и т. п.

 

как раз наоборот, например собираемся сделать каконить блок, например тот же рле - кодер, работающий в data packed processing системе.

 

Разбиваем этот блок на 3 блока-функции:

1. менеджер памяти данных источника.

2. Собственно РЛЕ кодер

3. основной КА, который рулит первыми двумя и занимаеться data_flow от-но системы.

 

Я бы реализовал блок-"функцию" рле кодера в одном файле в тексте, воспользовался бы двухпроцесным подходом разработчиков LEON2/LEON3 для описания блока.

Т.к. считаю что дробить сам РЛЕ кодер на составляющие (а это будет несколько регистров, компараторов, суматоров + логика) будет не есть хорошо, т.к. работать с одним файлом легче.

Вообщем, сказать трудно, видимо надо рассматривать конкретную задачу. Некоторые соображения такие:

1. Не факт, что вообще нужет (или стоит выделять в отдельный блок "основной КА");

2. Можно описать алгоритм работы РЛЕ кодера двумя параллельными FlowChart (LEON, кстати не плохо написан! ;) ), один FlowChart синхронный (clocked, или sequential в терминах HDL Designer), другой - комбинационный (combinatorial). Если я правильно понял "двух процессный" подход. Если линейный алгоритм РЛЕ кодера слишком перегружен ветвлениями и/или действиями, так, что графическое представление в виде алгоритма окажется слишком большим, то есть смысл оформить отдельные участки алгоритма в виде процедур и/или функций. Процедуры и/или функции можно вынести в package, либо описать в секции Process declarations диаграммы FlowChart.

3. Очень вероятно, что дробить РЛЕ кодер далее, ниже по иерархии смысла нет.

:cheers:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне кажется, что отличие графического представления в hdldesigner от "схемного ввода" (например в квартусе) состоит в том, что вы имеете дело не с блоками, которые заданы вам сверху (типа микросхем серии 74LS или блоков из стандартной библ.), а разбиваете схему на блоки, удобные вам и логичные с точки зрения этого проекта. Т.е. у вас элементарным блоком в графическом представлении будет достаточно сложный компонент. Раэбивку на такие компоненты вы делаете сами; интерфейс между ними должен быть ясен и прост - проект в графическом представлении становится понятным и обозримым. Я уже как-то говорил, что попробуйте написать текстом SM на сотню состояний, а через месяц вернутся к ней - не разберетесь; нарисованная же понимается и вспоминается значительно легче.

 

 

Никто не помешает Вам использовать в "схемном подходе"(имеются ввиду всякие квартусы-ise-liberо :) ) вместо стандартных библиотечных блоков - написанные Вами на вхдл(или еще както полученные) супер-пупер-мега-составные модули для получения пущей наглядности. Другое дело, что в hdl designere еще много всяких полезностей скручено в одну хорошую вещь!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

oval

Собственно, "двухпроцессный метод" можно и на Verilog сделать, если использовать аналог Record - как единый Reg с последовательными define (REG0 = X; REG1 = Y + REG0; REG2 = Z + REG1 и т.д.).

Это просто более компактный метод записи.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А более доступная цена это какая? Цена не может быть ниже себестоимости.

 

Рынок - сложная штука. Цена определяется не только себестоимостью. Можно продавать 100 экземпляров за 10 уе или 1000 за 1 уе. результат по прибыли будет гдето одинаков...

Что касается цен на FPGA Adv... конечно это очень хороший продукт, и за него неплохо было бы получить хорошие деньги, да с этим я согласен. Кому он НЕОБХОДИМ(лицензионный), тот купит и за 30 тыс. а остальным и нелицензионного хватит :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

To ASN:

oval

Собственно, "двухпроцессный метод" можно и на Verilog сделать, если использовать аналог Record - как единый Reg с последовательными define (REG0 = X; REG1 = Y + REG0; REG2 = Z + REG1 и т.д.).

Это просто более компактный метод записи.

Я в Verilog не особо силен. Если можно, то объясните по подробнее Ваш вариант "двухпроцессный метода" на Verilog. Конструкция always будет использоваться одна? Среди этих двух процессов один клоковый, второй - комбинаторный. REGx - это регистры? Вы случайно не простейший конвейер имеете ввиду?

 

To Very_hard:

А более доступная цена это какая? Цена не может быть ниже себестоимости.

 

Рынок - сложная штука. Цена определяется не только себестоимостью. Можно продавать 100 экземпляров за 10 уе или 1000 за 1 уе. результат по прибыли будет гдето одинаков...

Что касается цен на FPGA Adv... конечно это очень хороший продукт, и за него неплохо было бы получить хорошие деньги, да с этим я согласен. Кому он НЕОБХОДИМ(лицензионный), тот купит и за 30 тыс. а остальным и нелицензионного хватит :)

ЧТД ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...