sazh 8 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба TO oval. А Вы случаем не из тех товарищей, которые продвигают на рынок продукты Mentor Graphics. Ведь все это имеет смысл только при сквозном проектировании, затрагивая и продукты разводки печатной платы и т.д. Все это может и хорошо, но вряд ли доступно не только одиночному пользователю, а даже фирме разработчику по стоимости, обучению и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ChinasFanat 0 3 марта, 2006 Опубликовано 3 марта, 2006 (изменено) · Жалоба Об чем спор? ))) HDL-Designer рулез, имеет все что надо у нас к примеру никто не возвращается к графике, а только сборка блоков (а также рулезные embedded block- текст в графике). Маленькие и средние удобочитаемые блоки пишутся на языке. Вообщем как всегда нужно искать золотую середину. ибо када много графики глаза сойдут с ума, када много текста мозг. )))) зы: я не из таких товарищей ))). ненавижу гадов за громадные цены. Изменено 3 марта, 2006 пользователем vikk Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Здесь Вы не совсем поняли общую концепцию. Все блоки внутри иерархии проекта, которые можно разделить на отдельные функционально законченные блоки (управление, передача данных и т. п.), мы оформляем как блок диаграммы (block diagram), соединяя соответствующие функционально законченные блоки между собой. Т.е. получаеться что при разработке топ-левела, сначала идет разработка каркаса и одновременно его самодокументация, а уже потом "пристегиваються" функции. С этим я согласен целиком и полностью. Далее каждый из функционально законченных блоков описывается как одно из представлений: алгоритм (flowchart), автомат состояний (state diagram, ASM - algorithmic state machine), таблица истинности (truth table). На высоком уровне , а не на уровне триггеров или LUT! Посмотрите примеры в составе HDL Designer, может быть станет более понятно. Это я и имел ввиду, говоря об уровне абстракции компонентов - функций. Примеры HDL designera я посмотрел, но там самый примитивизм. Но вот опять же не совсем понятно как описывать параллелелизм, т.к. используя FlowChart можно описать только логику, между 2 мя регистрами, т.е. только 1 слой. (насколько я понял доку на HDL) используя ASM, действительно можно очень просто описать последовательный алгоритм работы, но как быть если обработка данных и условий распаралелена и конвееризирована ? Придеться много писать ручками, тогда зачем графика ?. Выделять же КА в данном случае в отдельный объект и городить к нему в графике несколько АЛУ, ИМХО тоже не вариант, кроме ряби в глазах от обилия графики ничего не даст. HDL Designer как ИДЕ, очень хорошая штука, но все же закладывать разработку полностью на графику я бы не стал. Алгоритмические функции я бы писал на ХДЛ. :) ЗЫ. Я могу ошибаться из-за недостатка опыта, поэтому все выше указанное считать как мое ИМХО. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба TO oval. А Вы случаем не из тех товарищей, которые продвигают на рынок продукты Mentor Graphics. Нет, я не из тех "товарищей". :) Я просто достаточно давно работаю в направлении HDL проектирования. Уже давно сделал выбор в сторону Mentor'а, возможно откажусь в пользу чего-то другого, но пока альтернатив не вижу. Ведь все это имеет смысл только при сквозном проектировании, затрагивая и продукты разводки печатной платы и т.д. Все это может и хорошо, но вряд ли доступно не только одиночному пользователю, а даже фирме разработчику по стоимости, обучению и т.д. Не совсем согласен. Это имеет смысл даже в случае чисто HDL проектирования. У нас, например, разработчики схематики и PCB не используют Mentor. Да, действительно одиночному пользователю официально вряд-ли доступно. Согласитесь, если здраво размыслить, то если было-бы доступно, тоже бред, не в игрушки ведь играем. Mentor, как и все фирмы, работающие в этой области должны окупать проекты и получать прибыль или как??? Проблема возможности приобретения, это проблема не Mentor'а, а фирм-разработчиков и бюджета данной индустрии в стране! зы: я не из таких товарищей ))). ненавижу гадов за громадные цены. Во всем правы, кроме последней фразы. Не за что их ненавидеть. Цены соответствуют сложности выполненной работы. У них ведь тоже все хотят получать зарплату и достойную! Повторюсь, проекты должны как минимум окупаться, но чтобы им жить и развиваться нужно еще, чтобы они и прибыль приносили. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gate 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Хочу добавить к описанию, которое сделал oval: я из возможностей дизайнера, точнее из способов ввода, использую только текстовые embedded block и графическое рисование SM. Flowchart и truthtable мне легче написать на верилоге, чем графически. Еще отмечу, что hdldesigner - очень удобная оболочка для полного ведения проекта, а не только ввода - там есть контроль версий, вызовы симулятора, синтезатора и P&R, документирование, design check, поддержка командной работы ... Мне кажется, что отличие графического представления в hdldesigner от "схемного ввода" (например в квартусе) состоит в том, что вы имеете дело не с блоками, которые заданы вам сверху (типа микросхем серии 74LS или блоков из стандартной библ.), а разбиваете схему на блоки, удобные вам и логичные с точки зрения этого проекта. Т.е. у вас элементарным блоком в графическом представлении будет достаточно сложный компонент. Раэбивку на такие компоненты вы делаете сами; интерфейс между ними должен быть ясен и прост - проект в графическом представлении становится понятным и обозримым. Я уже как-то говорил, что попробуйте написать текстом SM на сотню состояний, а через месяц вернутся к ней - не разберетесь; нарисованная же понимается и вспоминается значительно легче. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Muxamor 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Как я понил графически не пргяться! Посоветуйте тогда компелятор котрый бы поддерживал бы PLD 16V8 при прогрмирование на VHDL? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Very_hard 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Во всем правы, кроме последней фразы. Не за что их ненавидеть. Цены соответствуют сложности выполненной работы. У них ведь тоже все хотят получать зарплату и достойную! Повторюсь, проекты должны как минимум окупаться, но чтобы им жить и развиваться нужно еще, чтобы они и прибыль приносили. Отличная программа! Но недоступная для пользователя. Но только для ненашего пользователя!:) И хрен они получат от НАС прибыль с такими ценами!! (30 тыс уе со всякими "скидками"). Нормальной средней фирме это не по карману... Интересно, много ли у них покупают? :) Хотя при более доступной цене многие бы себе взяли FPGA Advantage ОФИЦИАЛЬНО... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Здесь Вы не совсем поняли общую концепцию. Все блоки внутри иерархии проекта, которые можно разделить на отдельные функционально законченные блоки (управление, передача данных и т. п.), мы оформляем как блок диаграммы (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 и т. п. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Похоже здесь идет речь о классическом понятии функции типа "корень", cos, sin. Да, естественно, такого рода функции пишуться на HDL и описываются в основном в пакетах (package). Дальше используются в FlowChart и т. п. как раз наоборот, например собираемся сделать каконить блок, например тот же рле - кодер, работающий в data packed processing системе. Разбиваем этот блок на 3 блока-функции: 1. менеджер памяти данных источника. 2. Собственно РЛЕ кодер 3. основной КА, который рулит первыми двумя и занимаеться data_flow от-но системы. Я бы реализовал блок-"функцию" рле кодера в одном файле в тексте, воспользовался бы двухпроцесным подходом разработчиков LEON2/LEON3 для описания блока. Т.к. считаю что дробить сам РЛЕ кодер на составляющие (а это будет несколько регистров, компараторов, суматоров + логика) будет не есть хорошо, т.к. работать с одним файлом легче. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Отличная программа! Но недоступная для пользователя. Но только для ненашего пользователя!:) И хрен они получат от НАС прибыль с такими ценами!! (30 тыс уе со всякими "скидками"). Повторюсь, цены вполне адекватны уровню сложности САПР! Кстати, если я не ошибаюсь у них для России (СНГ) еще и большие скидки по сравнению с Англией к примеру! ;) Нормальной средней фирме это не по карману... Sorry for offtopic :) Не в обиду будет сказано, но это не "нормальная средняя фирма", пару-тройку "палаток" в деревне приносят бОльшую прибыль. Так что, это проблема рынка hightech в нашей стране. Интересно, много ли у них покупают? :) Хотя при более доступной цене многие бы себе взяли FPGA Advantage ОФИЦИАЛЬНО... Покупают, но не много. Мы вот думаем. Очевидно, что в ближайшее время бизнес Mentor в России есть и будет убыточным. ;) А более доступная цена это какая? Цена не может быть ниже себестоимости. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Похоже здесь идет речь о классическом понятии функции типа "корень", 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: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Very_hard 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба Мне кажется, что отличие графического представления в hdldesigner от "схемного ввода" (например в квартусе) состоит в том, что вы имеете дело не с блоками, которые заданы вам сверху (типа микросхем серии 74LS или блоков из стандартной библ.), а разбиваете схему на блоки, удобные вам и логичные с точки зрения этого проекта. Т.е. у вас элементарным блоком в графическом представлении будет достаточно сложный компонент. Раэбивку на такие компоненты вы делаете сами; интерфейс между ними должен быть ясен и прост - проект в графическом представлении становится понятным и обозримым. Я уже как-то говорил, что попробуйте написать текстом SM на сотню состояний, а через месяц вернутся к ней - не разберетесь; нарисованная же понимается и вспоминается значительно легче. Никто не помешает Вам использовать в "схемном подходе"(имеются ввиду всякие квартусы-ise-liberо :) ) вместо стандартных библиотечных блоков - написанные Вами на вхдл(или еще както полученные) супер-пупер-мега-составные модули для получения пущей наглядности. Другое дело, что в hdl designere еще много всяких полезностей скручено в одну хорошую вещь! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ASN 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба oval Собственно, "двухпроцессный метод" можно и на Verilog сделать, если использовать аналог Record - как единый Reg с последовательными define (REG0 = X; REG1 = Y + REG0; REG2 = Z + REG1 и т.д.). Это просто более компактный метод записи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Very_hard 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба А более доступная цена это какая? Цена не может быть ниже себестоимости. Рынок - сложная штука. Цена определяется не только себестоимостью. Можно продавать 100 экземпляров за 10 уе или 1000 за 1 уе. результат по прибыли будет гдето одинаков... Что касается цен на FPGA Adv... конечно это очень хороший продукт, и за него неплохо было бы получить хорошие деньги, да с этим я согласен. Кому он НЕОБХОДИМ(лицензионный), тот купит и за 30 тыс. а остальным и нелицензионного хватит :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 3 марта, 2006 Опубликовано 3 марта, 2006 · Жалоба 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 тыс. а остальным и нелицензионного хватит :) ЧТД ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться