[des00 25]

Добрый день!

 

Предистория обсуждения.

Сделал я проект - генератор конечных автоматов с собственного ассемблера -> Verilog. Описание в атаче.

Использовал его в нескольких проектах, остался доволен легкостью описания и легкостью отладки автоматов. (реализовывал автоматы ~30 - 50 состояний).

 

Для ясности пример описания автомата на ассемблере

  call WaitData, 0; // №1 
  call TestHeader, cAccLoadSampleBuffer;  // №2
  if   (Crc16Zero & !CntZero)  call SkipFrm 
  elif (Crc16Zero &  CntZero) jump PreSync  
  else                                   jump Hunt, FrmIsDone; // №3

 

Теперь сам предмет обсуждения.

По описанию генерируется автомат мура и описание автомата идет как "состояние = выход", при чем этот выход может быть как комбинационным (логика декодирования регистра состояния), так и регистровым (логика декодирования следующего состояния + регистр) и самое главное по времени этот выход однозначно (!!!) привязан к состоянию по ассемблерному коду.

 

Т.е. на примере кода сигнал cAccLoadSampleBuffer будет == 1 в тот момент когда в регистре состояния будет состояние №2 (если судить по этому кусочку кода). При чем в независимости от того, с какого

выхода я сниму данный сигнал.

 

Назовем такое кодирование автомата "прозрачным" кодированием.

 

Но тут мне попалась задача где использование такой концепции (автомата Мура) дает меньше гибкости и большее кол-во состояний чем при использовании автомата Мили. И я раздумываю вот над какой модификацией КА:

 

Отказаться от "прозрачного" кодирования в пользу честного описания. Т.е. в кодировании "состояние = выход" это описывает комбинационный, однозначно привязанный к текущему состоянию по времени выход. Потом это пропускается через регистр и если снимать выход с регистра он будет задержан на 1 такт относительно состояния, к которому он должен быть привязан.

 

В этом случае будет удобнее описывать вот такие выходы

 

  if   (Crc16Zero & !CntZero)  call SkipFrm,    0;
  elif (Crc16Zero &  CntZero) jump PreSync,  IdleFrameDone;
  else                                   jump Hunt,       SSF;

 

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

 

Сейчас же описание вот такой ситуации происходит следующим образом

  if   (Crc16Zero & !CntZero)  call SkipFrm 
  elif (Crc16Zero &  CntZero) jump PreSync  
  else                                   jump Hunt, FrmIsDone;
...............
assign IdleFrameDone = FrmIsDone & Crc16Zero & CntZero; 
assign SSF                 = FrmIsDone & !Сrc16Zero;

 

При этом "держать" в голове сдвиг сигнала на 1 такт не нужно (но нужно держать условия) + такие ситуации достаточно редки и ценой такого удобства описания будет потеря "прозрачности" описания.

(т.к. смешивать в одном коде оба вида присвоения у меня нет желания, хотя это возможно, если придумаете красивую мненомнику описания :) )

 

Как вы думаете стоит ли вводить такую модернизацию и ваше обоснование подобной модернизации?

 

Спасибо за потраченное на этот пост время.

 

Денис.

Documentation.txt

[Voloshchenko 0]

Как вы думаете....

Хочу уточнить, Ваш транслятор (компилер) с ассемблера в HDL? Соблюдаются ли после трансляции правильные правила синтеза конечных автоматов этого типа на языке HDL? Да и какие, собственно, правила построения конечных автоматов Вы здесь используете? Есть ли ссылки? Это коммерческое мероприятие?

Проблема интересная, интересен и способ ее решения....

[des00 25]

Хочу уточнить, Ваш транслятор (компилер) с ассемблера в HDL? Соблюдаются ли после трансляции правильные правила синтеза конечных автоматов этого типа на языке HDL? Да и какие, собственно, правила построения конечных автоматов Вы здесь используете? Есть ли ссылки? Это коммерческое мероприятие?

Проблема интересная, интересен и способ ее решения....

 

Добрый день!

 

Транслятор выполняет трансляцию описанного алгоритма в модуль на Verilog-е. Генерируемые результаты работы смотрите в приложении. Это 3 различных описания КА вот с таким описанием :

 

  `define test0 nop 
const
  cAccNop        = 0x0; 
  cAccLoad       = 0x1; 
  cAccShift      = 0x2; 
  cAccClr        = 0x3; 
  Ack = 0x04;
  Done = 0x08;    
endconst 

branch
    a = br1;
        c = br0;
    b = br12;
endbranch   

begin
idle : 
if (a & !b) nop
elif (c) jump idle
else 
Wait, cAccNop;
nop, cAccLoad + Ack;
r: test0, cAccClr; 
r_r: nop, 0 / cAccShift; ////// comment 
r_rr: wait, Done;
end

 

Соблюдаются ли после трансляции правильные правила синтеза конечных автоматов этого типа на языке HDL?

 

Правильность правил создания КА можете проверить сами. Со стороны своего текущего ХДЛ ного опыта я полагаю что ошибок в описании КА нет. Разрядности портов выходов, переходов, регистра состояния подсчитывается точно. Да и синтезаторы ругаются только на неиспользуемые регистровые выходы.

 

Да и какие, собственно, правила построения конечных автоматов Вы здесь используете? Есть ли ссылки?

 

Насколько я понимаю предоставленные верилог файлы показывают использование классического 3-х процессного описания КА. С той лишь только разницей что в формировании выходов используется не 1 процесс, а 3. Почему, думаю будет понятно из верилог файлов.

 

Вы правильно убрали свою заметку про микропрограммный автомат (каюсь вчера прочитал, но времени отвечать не было), это точно не он :). Это инструмент для простой и быстрой разработки КА.

 

Это коммерческое мероприятие?

 

Нет. Проект изначально планировался как открытый. Сейчас решаю где разместить исходные коды. Пока у меня 3 варианта:

1. opencores (придеться адаптироваться к CVS).

2. ru_embedded (нужно будет поднять trac)

3. Сайт моего друга с уже поднятым trac :).

 

Можете предложить другие варианты.

Наиболее оптимальные варианты 2 и 3, т.к. у загашнике еще пара опенсорсов (контроллеры памятей, МПА приведенный в нормальный вид и т.д.)

Создание собственного сайта не рассматривается, т.к. во всем что касается web я чайник, да и времени на изучение сего нет.

 

Если кто хочет попробывать скажите, я выложу исходники в этой теме. Надеюсь что у вас стоит интерпретатор питона версии не ниже 2.4.

 

Что касается моей выгоды то она есть : изучение языка Python. Лицензия проекта Free for use.

Поделиться мне не жалко.

 

Спасибо за ваше участие! Извините что не ответил вчера.

 

ЗЫ. Инструмент макросов был введен для облегчения возможности описания систем с АЛУ + КА. Этакий супер микро проц получается. :)

 

ЗЗЫ. Насчет вопроса про выходы, я придумал как сохранить концепцию "прозрачного" описания и не держать в голове сигналы условий, а возложить сию работу на генератор.

 

о как класно, просматривая выложенные файлы нашел очипятнку, в питоновском шаблоне генерации КА. Не правильная иницилизация выходов во время ресета (вместо 4'h0 было 3'h0).

Спасибо форуму !! Файлы заменил.

test_cmp.v

test_cmp.vhd

test_cnt.v

test_n.v

test_onehot.v

[Postoroniy_V 0]

:a14:

Лихо продвинулись! выкладывать всё равно куда. главное выложить :)

 

 

з.ы. :bb-offtopic: я так понял у вас работа связана как то с GFP(F/T) :) так или не так?

[des00 25]

Лихо продвинулись! выкладывать всё равно куда. главное выложить :)

 

Вопрос решается, скоро будет выложен на сайте. :)

 

з.ы. :bb-offtopic: я так понял у вас работа связана как то с GFP(F/T) :) так или не так?

 

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

ITU-T G.7041/Y.1303 Generic framing procedure (GFP) для передачи кадров из асинхронных потоков через синхронный канал.

[iosifk 3]

Добрый день!

 

Предистория обсуждения.

Сделал я проект - генератор конечных автоматов с собственного ассемблера -> Verilog. Описание в атаче.

Использовал его в нескольких проектах, остался доволен легкостью описания и легкостью отладки автоматов. (реализовывал автоматы ~30 - 50 состояний).

 

Денис.

 

Денис, я вспомнил, куда Вам надо написать - Долинскому М.С. (Михаил Семенович Долинский[email protected] Математический факультет, Гомельский государственный университет

им. Ф.Скорины, Гомель, Беларусь)

Они делали свой собственный HLCCAD и Winter

Вот кусок из статьи одного из его коллег:

"Для осуществления идеи проектирования цифровых электронных схем в виде МПА предприняты следующие шаги:

- рассмотрены различные подходы к реализации цифровых схем с помощью микропрограммного автомата;

- определена базовая версия языка микропрограммных автоматов (MPDL);

- реализована поддержка языка универсальным отладчиком WINTER с множеством возможностей отладки;

- реализован ассемблер программ, написанных на MPDL;

- реализована модель виртуального процессора микропрограммных автоматов для систем HLCCAD и Winter.

- реализована первая версия синтезатора схем по микропрограмме. Получаемая схема настроена на максимальное быстродействие МПА.

"

 

Ну и приевет ему...

Удачи!

[CaPpuCcino 0]

dear des,

подскажите, плз, какой литературой пользовались (если пользовались).

/библиография по Питону не всчёт/

спасибо

(кстати конструкции типа if-else это уже не мета-ассемблер, а высокоуровневое программирование, традиционный ассемблер как правило может обеспечить ток бинарное ветвление, а это ограничение на автомат, либо нужно делать макроанализ, но это так лирика; вообще конечно проект интересный - надо помозговать, однако есть кое-какие сомнения: так например, по-моему, хорошо бы пользоваться какими-нить приёмами позволяющими разбивать сложные конструкции условных операторов, чтобы иметь возможность добавлять дополнительные вершины АС в случае если есть какие-нить ограничения по тактовой частоте, а сложные условия приводят к росту задержки на комб. логике).

[des00 25]

подскажите, плз, какой литературой пользовались (если пользовались).

 

Хелпом + примерами скачеными с сети + портал питон программистов.

 

http://python.com.ua

http://python.com.ua/ru/articles/Python/

 

вообще конечно проект интересный - надо помозговать

 

Вопрос размещения в сети исходников решен, сейчас идет работа над дизайном. На следующей неделе исходники будут выложены в SVN при trac и доступны для скачивания. Кому не терпится уже сейчас посмотреть последнюю 3-ю версию (описание в приложении) пишите вышлю проект, но со скомпилированными питон модулями.

 

однако есть кое-какие сомнения: так например, по-моему, хорошо бы пользоваться какими-нить приёмами позволяющими разбивать сложные конструкции условных операторов, чтобы иметь возможность добавлять дополнительные вершины АС в случае если есть какие-нить ограничения по тактовой частоте, а сложные условия приводят к росту задержки на комб. логике).

 

Хмм изначально проект задумывался как инструмент перевода одного описания в другое. Мне проще представлять последовательные алгоритмы описанные как программа.

Пробывал пользоваться всякими графическими генераторами КА, не понравилось. Думаю что я не один.

 

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

 

синтезаторы достаточно хорошо оптимизируют КА описанные в общем, реализационно независимом виде (тот же квартус с оптимизировал у меня КА на 28 состояний со стеком возврата на 224 МГц на кулоне 2 8ке(при требуемых 200)), так зачем отбирать у них хлеб ? :)

 

на 3 ей версии я планирую остановиться, т.к. получилось достаточно удобно. Хотя подумываю о введении команды вида wait N, где N кол-во тактов (состояние + счетчик), что бы просто кодировать всякие выравнивающие задержки.

 

Может быть есть еще пожелания, критика с удовольствием выслушаю? :)

Documentation.txt

[CaPpuCcino 0]

Хелпом + примерами скачеными с сети + портал питон программистов.

питон как раз НЕ интересует, интересует теория (если была)

[Gorby 6]

Вообще я приветствую идею метапрограммирования.

Это удобно, не пухнет голова и быстро получается.

 

Только зачем во избежание использования одного ассемблера (Верилога) пользуем свежеизобретенный ассемблер же?

 

Нативным для обсуждаемой области есть представление КА в виде направленного графа состояний. Рисунок такой с зелеными кружочками и переходами между ними. На нем как раз очень НАГЛЯДНО видна вся функциональность проектируемого автомата. Ни на секунду не поверю, что автомат на 50 состояний на вашем метаассемблере понятен еще кому-то, кроме автора (а через месяц и он не вспомнит).

 

Но оказывается, "все украдено до нас" (с). В Актив ХДЛ есть приложение, в котором рисуешь КА "как в книжке", возможна вложенность КА. А потом нажатием одной кнопки получаем исходник на VHDL. Понятно, что есть много параметров настройки. Вот про Верилог не скажу - мне не нужен был. В конце концов, есть конверторы. И голова.

 

Если и делать, то прогу такого уровня (хоть отдаленно). Понятно, один человек такое не потянет даже за деньги. Про бесплатно молчу.

 

Автору топика - спасибо, что готов поделиться плодом своих усилий.

Наверное, у каждого из нас есть несколько самописных "утилит". Но это не значит, что всем они нужны.

[des00 25]

питон как раз НЕ интересует, интересует теория (если была)

 

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

 

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

 

 

Только зачем во избежание использования одного ассемблера (Верилога) пользуем свежеизобретенный ассемблер же?

 

Нативным для обсуждаемой области есть представление КА в виде направленного графа состояний. Рисунок такой с зелеными кружочками и переходами между ними. На нем как раз очень НАГЛЯДНО видна вся функциональность проектируемого автомата. Ни на секунду не поверю, что автомат на 50 состояний на вашем метаассемблере понятен еще кому-то, кроме автора (а через месяц и он не вспомнит).

 

Но оказывается, "все украдено до нас" (с). В Актив ХДЛ есть приложение, в котором рисуешь КА "как в книжке", возможна вложенность КА. А потом нажатием одной кнопки получаем исходник на VHDL. Понятно, что есть много параметров настройки. Вот про Верилог не скажу - мне не нужен был. В конце концов, есть конверторы. И голова.

 

Спасибо за ваше замечание, вы абсолютно правы. Но согласитесь что все КА по сути являют собой набор 3-х псевдокомманд (назовем их так) nop, jump, wait (тот же jump, но пусть будет).

 

Эти команды можно описывать как угодно: на уровне структурного хдл, ртл хдл, бехавор ртл, в графике, взять проц и наваять прогу на С/С++. (все указано в порядке возрастания уровня описания).

 

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

 

Но временные затраты на разработку, модернизацию и самое главное отладку КА у этих методов совершенно различны, причем ошибки могут быть как языковые (не сильно страшно), правильные по хдл очипятки и функциональные (намного хуже).

 

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

 

Честно пробывал 3 раза начать рисовать КА как в альдеке, так и в хдл дезайнере но не пошло. Скорее всего потому что мне воспринимать последовательный код, для последовательного алгоритма, проще чем графический.

 

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

 

Проблема модифиации КА решается вставкой пары nop ов в критическое место. Получается может быть не всегда ресурсовыгодно, но быстро и просто.

 

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

 

Насчет вспомнить что делает автомат через год вот пример кода автомата, который приложен в релизе со скомпилированным 2.5 питоном :

begin
DecodeWrite : 
    if   (TxEnable          & !TxStartOccured & !TxBusy)      jump WriteInitProcess   , cMuxWbWrite;
    elif (TxStartOccured    & !TxLengthZero   & !TxFifoFull)  jump WriteDataProcess   , cMuxWbWrite;
    else                                                      jump DecodeRead         , cMuxWbWrite;
DecodeRead :     
    if   (RxEnable          & !RxStartOccured & !RxBusy)      jump ReadInitProcess    , cMuxWbRead;
    elif (RxStartOccured    & !RxFifoEmpty   )                jump ReadDataProcess    , cMuxWbRead;
    else                                                      jump DecodeWrite        , cMuxWbRead;
//-----------------------------------------------------------------------
// init all counters and init transmitter      
//-----------------------------------------------------------------------
WriteInitProcess :
    jump DecodeRead  , cSetTxInit;
//-----------------------------------------------------------------------
// Wishbone read & analyze, tx fifo write, tx counter decrement
//-----------------------------------------------------------------------
WriteDataProcess : 
    if      (WbAck & !WbErr) jump DecodeRead     , cWbRead + cTxLengthDec + cTxFifoWrite;  
    elif    (WbErr & !WbAck) jump DecodeRead     , cWbRead + cSetTxAbort;
    else                     wait                , cWbRead;    
//-----------------------------------------------------------------------
// init counters & receiver enable 
//-----------------------------------------------------------------------
ReadInitProcess :
    jump DecodeWrite , cSetRxInit; 
//-----------------------------------------------------------------------
// Wishbone write & analyze, rx fifo read
//-----------------------------------------------------------------------
ReadDataProcess : 
    nop, cRxFifoRead;   // this tick is used for capture wishbone data
    if      (WbAck & !WbErr)  jump DecodeWrite    , cWbWrite + cRxLengthInc;
    elif    (WbErr & !WbAck)  jump DecodeWrite    , cWbWrite + cSetRxAbort; 
    else                      wait                , cWbWrite;
//-----------------------------------------------------------------------
end

 

комменты + описание IP достаточно что бы не тратить много времени на восстановление в памяти что там и куда.

 

В приложении архив 7z. переименованный в txt. иначе файл не приатачивался. pyc файлы собраны 2.5 питоном. батник do.bat запускает тестовый проект, приложено что бы убедиться что генератор работает.

 

Спасибо за диалог!

release3_0.txt

[CaPpuCcino 0]

Честно пробывал 3 раза начать рисовать КА как в альдеке, так и в хдл дезайнере но не пошло. Скорее всего потому что мне воспринимать последовательный код, для последовательного алгоритма, проще чем графический.

то же самое. не люблю я эти графити.

[lotorev 0]

то же самое. не люблю я эти графити.

 

более того

1) конкретно актив хдл 7.2 сп2 конкретно для верилога генерирует кривой код: в настройках можно выбрать non-blocking, or blocking - так вот эти blocking ИЛИ non-blocking присваивания он (активхдл) будет писать в ОБОИХ always для регистров и для логики, что есть неправильно. у mentor можно для всех трёх блоков always задать независимые конфигурации.

2) поддержку для enum SystemVerilog они похоже не собираются добавлять.

[dxp 53]

2) поддержку для enum SystemVerilog они похоже не собираются добавлять.

enum там, вроде, есть. Там нет структур, С-типов, интерфейсов и прочего. Но все это есть в Ривьере. :) На основании этого можно полагать, что в следующих версиях Active все это появится.

[Apast 0]

enum там, вроде, есть. Там нет структур, С-типов, интерфейсов и прочего. Но все это есть в Ривьере. :) На основании этого можно полагать, что в следующих версиях Active все это появится.

Немного не в тему, но есть вопрос, кто то пользовался Ривьерой? На сколько она отлична от ActivHDL, на сколько я понимаю это что то типа ModelSim т.е. только моделирование, но зато (по их информации) вроде побыстрее ActivHDL. Так это или нет.