|
КД на проекты с ПЛИС, КД на проекты с ПЛИС кто как делает? |
|
|
|
Mar 14 2009, 09:41
|
Участник

Группа: Свой
Сообщений: 35
Регистрация: 12-12-04
Пользователь №: 1 457

|
КД на проекты с ПЛИС кто как делает? У нас на предприятии в комплект КД входит только файл sof или pof как таблица прошивки ППЗУ.Но это не обеспечивает возможность модернизации в дальнейшем. Сейчас стали говорить что надо бы оформлять еще тексты программ, алгоритмы и описание программ как на программы. Это конечно правильно для нормальных программ для микроконтроллеров и ПЭВМ, а для ПЛИС помоему затруднительно. Вот и вопрос кто как оформляет КД на ПЛИС, какие ГОСТы на это существуют?
|
|
|
|
|
Mar 14 2009, 09:58
|
Гуру
     
Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804

|
Цитата(Joker @ Mar 14 2009, 12:41)  КД на проекты с ПЛИС кто как делает? У нас на предприятии в комплект КД входит только файл sof или pof как таблица прошивки ППЗУ.Но это не обеспечивает возможность модернизации в дальнейшем. Сейчас стали говорить что надо бы оформлять еще тексты программ, алгоритмы и описание программ как на программы. Это конечно правильно для нормальных программ для микроконтроллеров и ПЭВМ, а для ПЛИС помоему затруднительно. Вот и вопрос кто как оформляет КД на ПЛИС, какие ГОСТы на это существуют? А не программа это вовсе. А если в графическом редакторе работаете, что описывать будете. И почему это не обеспечивает возможность модернизации. Замените таблицу прожига ПЗУ на другую. (чем например epc1 лучше 556РТ7). Хотите текстовое описание заложить. А что от него толку для того кто будет это разгребать, если придется. (Заложить наверно надо, но без ссылок на документы (Чтобы просто не потерять наработку)) Достаточно стандартного комплекта документов. (Инструкция по прожигу, диск, этикетка и без ссылок на пакет разработки)
|
|
|
|
|
Mar 14 2009, 10:21
|
Участник

Группа: Свой
Сообщений: 35
Регистрация: 12-12-04
Пользователь №: 1 457

|
Достаточно стандартного комплекта документов. (Инструкция по прожигу, диск, этикетка и без ссылок на пакет разработки) Мы тоже так думали и делали. Но при этом предполагается что сам проект хранится у разработчика, а разработчик - лицо безответственное (уволился, комп грохнулся,диск потерялся) и все.Далее для модернизации придется создавать новый проект.
|
|
|
|
|
Mar 14 2009, 10:34
|
Гуру
     
Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804

|
Цитата(Joker @ Mar 14 2009, 13:21)  Достаточно стандартного комплекта документов. (Инструкция по прожигу, диск, этикетка и без ссылок на пакет разработки) Мы тоже так думали и делали. Но при этом предполагается что сам проект хранится у разработчика, а разработчик - лицо безответственное (уволился, комп грохнулся,диск потерялся) и все.Далее для модернизации придется создавать новый проект. Мы - это кто. Обычно об этом один думает. Остальные ему проекты приносят. Основная проблема не в безответственных разработчиках. А в отсутствии грамотного руководителя проекта. А для модернизации все равно новый проект придется создавать. Например было 4 узла. Один в графическом редакторе на MAX+, другой на ahdl, не проверите третий на vhdl, четвертый на верилоге. Кака по мне, я б этого руководителя - барабанщика. Теперь один. все по новой.
|
|
|
|
|
Mar 14 2009, 10:47
|
Участник

Группа: Свой
Сообщений: 35
Регистрация: 12-12-04
Пользователь №: 1 457

|
Мы-это собственно те кто и делает эти проекты.(Обычно 1-4 человека на проект). Цитата А для модернизации все равно новый проект придется создавать. При наличии проекта и описания (проекта и входящих узлов) можно и разобраться и тогда новый проект создавать не нужно. Вопрос в том как это все пристегнуть к КД.
|
|
|
|
|
Mar 14 2009, 11:18
|
Знающий
   
Группа: Свой
Сообщений: 845
Регистрация: 18-10-04
Из: Pereslavl-Zalessky, Russian Federation
Пользователь №: 905

|
Зачем?
1. чтобы отвязались? формально сделать вид, что если кто-то придет "разгребать", то вот оно все есть?
Способы зависят от желания помочь или помешать потенциальному "разгребателю" и информированности того, кто принимает "документацию".
2. как облегчить жизнь пришедшему "разгребать".
Лучше всего прикладывать винчестер с полным комплектом программ, от ОС и текстового редактора до place and route. Рядом копию образа всего диска разработчика, например в true image. Вряд ли установится, но может помочь. Подробный текст как и что ставить на голый компьютер, со всеми тонкостями привязки к железу, если есть. Естественно, исходные тексты, констрейны, файлы проектов все, все, все, должны быть в нужных местах дерева файловой системы. К сожалению, даже такой винчестер не поможет студенту 5-ого курса, успешному web-программисту на perl быстренько портировать проект на новое семейство.
IMHO: Цена возможности быстро что-то поменять в старых проектах высока. Даже в своих собственных. Про них нужно помнить, нужно держать на диске старые версии среды разработки, полистывать исходные тексты. Ведь если случится нужда что-то поменять, то придется все это кому-то загружать в голову. Либо автору вспоминать, либо новичку осваивать. Думаю, что выгодно либо держать автора изо всех сил и иметь в виду, что уход автора равносилен потере возможности развивать старый проект. Либо каждый проект после завершения рассматривать как немодифицируемый и не развиваемый. Попытку вмешаться в старый проект следует рассматривать как новый проект, бюджет которого может превысить бюджет первоначального проекта.
|
|
|
|
|
Mar 14 2009, 13:32
|
Местный
  
Группа: Свой
Сообщений: 429
Регистрация: 11-08-05
Из: Санкт-Петербург
Пользователь №: 7 537

|
Коллеги, что-то вы тут сгущаете краски. Немодифицируемым и не развиваемым является только то, что "слеплено на коленке". Нормально разработанный проект с хорошей документацией еще как модифицируется и развивается! Цитата(Joker @ Mar 14 2009, 12:41)  Сейчас стали говорить что надо бы оформлять еще тексты программ, алгоритмы и описание программ как на программы. Это конечно правильно для нормальных программ для микроконтроллеров и ПЭВМ, а для ПЛИС помоему затруднительно. Для КД на ПЛИС нужно больше документов, чем для КД на программы, но это все возможно и даже правильно. Кроме того, если сначала продумать алгоритмы, способы реализации, разработать интерфейсы между блоками, временные диаграмы и написать это на бумаге, то потом и имплементировать на ПЛИС будет проще, быстрее и багов будет меньше и исправлять те, что обнаружаться, легче. Блоки написанные на языках HDL, с точки зрения КД, мало чем отличаются от программ, а то, что нарисовано схемой ( в Квартусе, например) так и прилагать как схему с описанием, интерфейсом и временными диаграммами. Неплохо бы внедрить систему контроля версий вроде CVS, Перфорса и пр. Тулы для разработки ПЛИС поддерживают большинство таких систем.
|
|
|
|
|
Mar 16 2009, 16:13
|
Участник

Группа: Участник
Сообщений: 71
Регистрация: 14-11-07
Пользователь №: 32 325

|
Цитата(Joker @ Mar 14 2009, 12:41)  КД на проекты с ПЛИС кто как делает? У нас на предприятии в комплект КД входит только файл sof или pof как таблица прошивки ППЗУ.Но это не обеспечивает возможность модернизации в дальнейшем. Сейчас стали говорить что надо бы оформлять еще тексты программ, алгоритмы и описание программ как на программы. Это конечно правильно для нормальных программ для микроконтроллеров и ПЭВМ, а для ПЛИС помоему затруднительно. Вот и вопрос кто как оформляет КД на ПЛИС, какие ГОСТы на это существуют? Я сталкивался с этим. Есть ГОСТ на оформление документации на разработки сделаные в электронном виде, т.е программы, схемы и т.д. Номера не помню, но выпуск где-то 2000 или 2001 года. Выходили еще ГОСТЫ в 2006 г. там то же говорилось про электронную документацию. Суть этих ГОСТов сводится к тому, что если исполнитель передает всю документацию в электронном виде (т.е. проект), например на DVD, то ничего оформлять по старому ГОСТУ на листочках в рамочке не надо. Только спецификации и чертежи оформляюются в рамочках по госту. Главное, чтобы был полный проект, используюя который можно было получить тот же результат. Есть специальная форма спецификации для электронных документов. А в спецификации на изделие указывают только файл прошивки. А оформлять тексты кода по старому ГОСТУ уже не надо. Правда, там есть оговорочка, что документация может выполняться в бумажном виде по согласованию сторон. С нас попросили оформить по-старому только спецификации и чертежи схем и описание проекта (описание функционирования). Мы делали описание начинки ПЛИС как описание схемы и функционирование аппаратных контроллеров, а не как описание программы.
|
|
|
|
|
Mar 17 2009, 08:41
|
Знающий
   
Группа: Админы
Сообщений: 689
Регистрация: 24-06-04
Из: South Africa
Пользователь №: 164

|
Цитата(FAE_SKV @ Mar 16 2009, 18:13)  Главное, чтобы был полный проект, используюя который можно было получить тот же результат. Вот это и есть ключевая фраза А что именно сохранять очень сильно зависит от применяемых tools, пребований к проекту (технических), требований / соглашений с заказчиком, и еще массы факторов
--------------------
"В мире есть две бесконечные вещи: Вселенная и человеческая глупость. За Вселенную, впрочем, поручиться не могу". (С)
А. Эйнштейн.
|
|
|
|
|
Mar 17 2009, 11:07
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(Kuzmi4 @ Mar 17 2009, 12:08)  И всё же - куда именно смотреть чтобы подготовить прожект на плиске к сдаче по госту ? Как я понял здесь документация готовится по договорености сторон. ГОСТа в свое время я не нашел. Ранее этот вопрос поднимался: здесьздесь 1на основе этих обсуждений(предложений, рекомендаций) я для языка VHDL (так как я на нем программирую) написал рекомендации (требования, правила) на русском языке. Сейчас я пытаюсь сам им следовать. Это по поводу описания самой цифровой схемы схемы в ПЛИС. Конечно не помешает дополнительно - описание реализуемых алгоритмов (например фильтров и т.д.), устройств (например интерфейсы связи); - структурно-функциональная схема для всего проекта с описанием (это может быть и файл верхнего уровня (sсhemathic)); - если в описании имеются директивы для синтеза - указать это отдельно (для чего, зачем); - оговорить отдльно если были использованы IP ядра, как разработчиков фирмы изготовителя программного обеспечения (Altera, Xilinx и т.д.) или стороннего производителя к которому нет VHDL/Verilog описания (имеется только netlist); - Может быть оговорить граничные частотно-временные характеристики, ограничения проекта ЗЫ. Документ я делал для себя и может некоторые ньюансы (в формулировках), ошибки(хотя, я их на сегодняшний день не вижу) имеются. Единственно чего я там не прописал так это отступы, пробелы при написании самой программы. Литература которой пользовался при написании данного документа приведена в конце. ЗЫ. ЗЫ. Предложения, рекомендации и нарекания я выслушу очень внимательно по поводу документа.
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Mar 19 2009, 07:33
|
Злополезный
   
Группа: Свой
Сообщений: 608
Регистрация: 19-06-06
Из: Russia Taganrog
Пользователь №: 18 188

|
Цитата(Maverick @ Mar 17 2009, 15:07)  P.S. P.S. Предложения, рекомендации и нарекания я выслушу очень внимательно по поводу документа. Прочитал. Документ интересный. Добавлю пару предложений (может, конечно, и бестолковых), но не найденных в документе: 1. Для сигналов входящих/выходящих в/из ПЛИС я использую префиксы IN_xxx, OUT_xxx, IO_xxx. После прохождения однонаправленных сигналов через I/O BUF, префиксы IN_ и OUT_ - отбрасываю. Для IO_ сигналов прошедших IOBUF использую суффиксы xxx_IN, xxx_OUT. (буферы ввода/вывода всегда вставляю в проект) 2. Для различных внутренних сигналов использую ряд однотипных суффиксов: _UB - UnBuffered (например, для Clock поданного на вход BUFGMX), _UL - UnLatched (например, для входных сигналов, которые должны быть защелкнуты входным IOB триггером), _L - Latched (например, для сигналов,) _FF - Falling front (применяю для выходного сигнала "детектора" фронта) _RF - Rising front (применяю для выходного сигнала "детектора" фронта) Ну например как-то так: CODE signal AAA_UL: std_logic; signal CLK: std_logic;
signal AAA: std_logic := 0; signal AAA_L: std_logic := 0; signal AAA_RF: std_logic; signal AAA_FF: std_logic;
AAA <= AAA_UL when rising_edge(CLK); AAA_L <= AAA when rising_edge(CLK);
AAA_RF <= AAA and not(AAA_L); AAA_FF <= AAA_L and not(AAA);
Единственная заметная разница моего стиля написания и вышепредложенного в названии инверсных сигналов, я вставляю _n между описанием принадлежности сигнала к группе и основным описателем сигнала: Reset -> nReset, RAM_nOE, PCI_nFrame. Мне так удобнее - а далее кому как больше нравиться. Считаю, что наиболее важным в КД является единобезобразие на протяжении всего проекта (лучше конечно во всех работах, но человек учится и потихоньку "улучшает" свои наработки, отклоняясь от первородных версий оформления).
|
|
|
|
|
Mar 19 2009, 08:38
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(Kuzmi4 @ Mar 19 2009, 11:25)  2 Maverick - а теперь вместе дружно вспомним про 20 с хвостом гигов гостов в закромах родины  Только вот кто возьмётся за их разребание ?? Смотрел их, к сожалению не нашел  Разгребать там нечего - имеется поиск и все уже структурировано.  Цитата(andrew_b @ Mar 19 2009, 12:01)  Сделайте статейку на wiki. Глядишь, и остальные подтянутся. Помогите я не знаю как это красиво написать/сделать, чтобы народ заинтерисовать Цитата(Boris_TS @ Mar 19 2009, 11:33)  Прочитал. Документ интересный. Добавлю пару предложений (может, конечно, и бестолковых), но не найденных в документе: 1. Для сигналов входящих/выходящих в/из ПЛИС я использую префиксы IN_xxx, OUT_xxx, IO_xxx. После прохождения однонаправленных сигналов через I/O BUF, префиксы IN_ и OUT_ - отбрасываю. Для IO_ сигналов прошедших IOBUF использую суффиксы xxx_IN, xxx_OUT. (буферы ввода/вывода всегда вставляю в проект) 2. Для различных внутренних сигналов использую ряд однотипных суффиксов: _UB - UnBuffered (например, для Clock поданного на вход BUFGMX), _UL - UnLatched (например, для входных сигналов, которые должны быть защелкнуты входным IOB триггером), _L - Latched (например, для сигналов,) _FF - Falling front (применяю для выходного сигнала "детектора" фронта) _RF - Rising front (применяю для выходного сигнала "детектора" фронта) Ну например как-то так: CODE signal AAA_UL: std_logic; signal CLK: std_logic;
signal AAA: std_logic := 0; signal AAA_L: std_logic := 0; signal AAA_RF: std_logic; signal AAA_FF: std_logic;
AAA <= AAA_UL when rising_edge(CLK); AAA_L <= AAA when rising_edge(CLK);
AAA_RF <= AAA and not(AAA_L); AAA_FF <= AAA_L and not(AAA);
Единственная заметная разница моего стиля написания и вышепредложенного в названии инверсных сигналов, я вставляю _n между описанием принадлежности сигнала к группе и основным описателем сигнала: Reset -> nReset, RAM_nOE, PCI_nFrame. Мне так удобнее - а далее кому как больше нравиться. Считаю, что наиболее важным в КД является единобезобразие на протяжении всего проекта (лучше конечно во всех работах, но человек учится и потихоньку "улучшает" свои наработки, отклоняясь от первородных версий оформления). Если не сложно пожалуйста, внесите в документ Ваши предложения/замечания (Как Вы их видите). ЗЫ На мой взгляд они логичные и правильные
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Aug 27 2009, 18:31
|
Местный
  
Группа: Свой
Сообщений: 376
Регистрация: 20-06-09
Из: BY
Пользователь №: 50 480

|
Цитата(andrew_b) Сделайте статейку на wiki. Глядишь, и остальные подтянутся. Страничку сделал. Закинул туда содержание доки, размещенной выше. Теперь одобренные предложения можем сохранять туда. PS: Wiki похоже глючит  Основной скрипт постоянно порт левый подставляет (:1288), и после нажатия на кнопку сохранить изменения страница повисает, но благо сохраняются изменения... но не удобно с ней работать из-за этого...
|
|
|
|
|
Oct 12 2009, 07:56
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Статья на wiki выложена. Единственная просьба не убирайте и не редактируйте раздел: Код Источники Исходный материал статьи предоставлен Денисовым Алексеем Олеговичем (электронная почта: maildenisov@gmail.com) [1] PS благодарности nikolaschaPS PS Хотелось бы что-то подобное увидеть для Verilog и/или SystemVerilog от профи
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Oct 12 2009, 08:45
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(andrew_b @ Oct 12 2009, 11:21)  Да уж... Извините, но текст ужасен. А местами напоминает автоматический перевод с английского. Я не спорю, у меня большого опыта в написании статей нет. Если Вы говорите, что текст ужасен, то предложите более коректное/лучшее написание того или иного предложения или абзаца, параграфа или всего документа. PS На мой взгляд(и некоторых других людей) статья написана хорошо, но я знаю что я человек и могу ошибаться, поэтому я его и выложил на форум, чтобы общими усилиями добиться идеала. PS PS Оценить результат работы всегда проще, чем ее сделать. Сколько людей - столько и мнений.
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Oct 12 2009, 10:13
|
Профессионал
    
Группа: Свой
Сообщений: 1 975
Регистрация: 30-12-04
Из: Воронеж
Пользователь №: 1 757

|
Цитата(Maverick @ Oct 12 2009, 12:45)  Я не спорю, у меня большого опыта в написании статей нет. Но сочинения в школе вы писали? Цитата Если Вы говорите, что текст ужасен, то предложите более коректное/лучшее написание того или иного предложения или абзаца, параграфа или всего документа. Да, там нужна суровая редактура. Короче, переписывать надо чуть менее чем всё.  А вот это Цитата 10. Старайтесь избегать использования арифметических операторов. Арифметические операторы при реализации требуют много логики и занимают большую площадь. меня вообще убило. Цифровые схемы -- это сплошная математика. Как вы собираетесь что-то делать без математических операций? Про "программу на VHDL" я уж и не говорю.
|
|
|
|
|
Oct 12 2009, 11:37
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(andrew_b @ Oct 12 2009, 13:13)  Не нравится не читай и не пользуйся! Хочешь помочь, то делай это нормально - без надсмешки и унижения. Насчет "программа" или "описание" на VHDL/Verilog была отдельная ветка и кстати однозначного там ответа не найдено. Конечно можно использовать, например для подсчета импульсов сумматор вместо счетчика, но нужно ли это? ПОКАЖИТЕ ПРИМЕР КАК НАДО ПИСАТЬ - НАПИШИТЕ ЛУЧШЕ!!! но я уверен, что кроме громких слов ничего не будет(мое мнение) PS "Не делай людям добра, не получишь зла". В очередной раз убеждаюсь в правильности этого высказывания. PS PS des00 мне помог в написании одного из первых вариантов документа. Так он помогал конструктивными замечаниями и давал предложения по исправлению ошибок/некоректностей. Ему за это отдельная БЛАГОДАРНОСТЬ!!! Вот этим человек показал свой профессионализм.
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Oct 12 2009, 12:05
|
Профессионал
    
Группа: Свой
Сообщений: 1 975
Регистрация: 30-12-04
Из: Воронеж
Пользователь №: 1 757

|
Цитата(Maverick @ Oct 12 2009, 15:37)  Не нравится не читай и не пользуйся! Ну, я так и думал... Цитата Хочешь помочь, то делай это нормально - без надсмешки и унижения. Что вы от меня хотите? Чтобы я разобрал статью по предложениям? Цитата но я уверен, что кроме громких слов ничего не будет(мое мнение) Естественно. Я ничего переписывать не буду. Для меня лично статья ничего нового и полезного не несёт.
|
|
|
|
|
Oct 12 2009, 12:15
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(andrew_b @ Oct 12 2009, 15:05)  Ну, я так и думал...
Что вы от меня хотите? Чтобы я разобрал статью по предложениям?
Естественно. Я ничего переписывать не буду. Для меня лично статья ничего нового и полезного не несёт. Я так и думал просто слова и ничего более... Подумайте может для других людей данная статья, что-то и несет нового и полезного и им(особенно начинающим) стоит помочь. Тем более люди на форуме переодически поднимают данную тематику PS Без обид.
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Oct 12 2009, 12:49
|
Знающий
   
Группа: Свой
Сообщений: 608
Регистрация: 10-07-09
Из: Дубна, Московская область
Пользователь №: 51 111

|
Цитата(Maverick @ Oct 12 2009, 16:15)  может для других людей данная статья, что-то и несет нового и полезного и им(особенно начинающим) стоит помочь. Тем более люди на форуме переодически поднимают данную тематику Думаю полезность будет в любом случае. В частных конторах нет нормоконтроля, практически в 90% делай что хочу. А вот в НИИ и на заводах, там надо вложить в документацию все что можно иначе сам не разберешь что, для чего и когда.
|
|
|
|
|
Oct 21 2009, 09:35
|
Местный
  
Группа: Свой
Сообщений: 451
Регистрация: 6-09-05
Из: Москва
Пользователь №: 8 284

|
Цитата(Maverick @ Oct 12 2009, 11:56)  Статья на wiki выложена. Единственная просьба не убирайте и не редактируйте раздел: Код Источники Исходный материал статьи предоставлен Денисовым Алексеем Олеговичем (электронная почта: maildenisov@gmail.com) [1] PS благодарности nikolaschaPS PS Хотелось бы что-то подобное увидеть для Verilog и/или SystemVerilog от профи Статья полезная. Есть ещё огромный раздел - описание конечных автоматов. Я выкладывал свой стиль описания в теме "Описание конечных автоматов". Получил много интересных ответов. Может стоит на wiki сделать страничку с формализованными описаниями автоматов ?
|
|
|
|
|
Oct 23 2009, 07:31
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(dsmv @ Oct 21 2009, 12:35)  Статья полезная. Есть ещё огромный раздел - описание конечных автоматов. Я выкладывал свой стиль описания в теме "Описание конечных автоматов". Получил много интересных ответов. Может стоит на wiki сделать страничку с формализованными описаниями автоматов ? есть на мой взгляд неплохая статейка по поводу автоматов и их реализаций. По поводу добавления на wiki странички с формализованными описаниями автоматов - я за. А по поводу подобное написать для Verilog и/или SystemVerilog как?
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Oct 23 2009, 08:16
|
Вечный ламер
     
Группа: Модераторы
Сообщений: 7 248
Регистрация: 18-03-05
Из: Томск
Пользователь №: 3 453

|
Цитата(dsmv @ Oct 21 2009, 04:35)  Может стоит на wiki сделать страничку с формализованными описаниями автоматов ? Цитата(Maverick @ Oct 23 2009, 02:31)  По поводу добавления на wiki странички с формализованными описаниями автоматов - я за. А по поводу подобное написать для Verilog и/или SystemVerilog как? ИМХО бессмысленно, соревноваться с гуру в красноречии и вывертах (неплохо пишут о КА SunBurst, Douglas Smith, RMM, Synopsys, Mentor и еще туева хуча документов) смысла не вижу, делать перевод тоже. Для V/SV описание КА идет по тем же правилам что и для VHDL, с небольшими исключениями. Если уж и делать полезную статью. то имеет смысл взять референсные КА на 20/40/60 состояний, описать их 4мя стилями и нарисовать в 2х распространенных софтах, все отладить. Привести код для оценки стиля описания и результат синтеза для оценки качества. ИМХО это будет наглядно, объективно и по делу.
--------------------
|
|
|
|
|
Oct 23 2009, 08:45
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(des00 @ Oct 23 2009, 11:16)  ИМХО бессмысленно, соревноваться с гуру в красноречии и вывертах (неплохо пишут о КА SunBurst, Douglas Smith, RMM, Synopsys, Mentor и еще туева хуча документов) смысла не вижу, делать перевод тоже. Для V/SV описание КА идет по тем же правилам что и для VHDL, с небольшими исключениями.
Если уж и делать полезную статью. то имеет смысл взять референсные КА на 20/40/60 состояний, описать их 4мя стилями и нарисовать в 2х распространенных софтах, все отладить. Привести код для оценки стиля описания и результат синтеза для оценки качества. ИМХО это будет наглядно, объективно и по делу. Вы наверное меня не правильно поняли: Вопрос был по поводу написания статьи по написанию программ на V/SV. Подобный документ Вы писали только на английском языке(хотелось бы увидеть на русском языке ссылки я давал раньше в этой ветке) То что Вы предлагаете по поводу КА было бы супер, но вот кто за это возьмется?
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|