Plog - язык для програмируемой логики

[vak]

Идея состоит в построении процедурного Си-подобного языка, который бы однозначным образом компилировался в Верилог.

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

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

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

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

Comments

[spamsink]

System Verilog?

[vak]

Систем Верилог - он всё-таки Верилог, но только намного сложнее. Как PL/I по отношению к Фортрану. Не лежит душа к таким верблюдам...

[thesz.livejournal.com]

Так себе идея.

Например, почему Си?

Что делать, когда надо три бита и больше не надо?

Параллельный стиль не так уж и плох или труден, я в Хаскеле им пользуюсь сплошь и рядом. В HDL надо повысить уровень проверки типов, станет проще.

[vak]

Я смотрел функциональные HDL-языки - забавно, но слишком далеко от практической применимости. В процедурном подходе есть два варианта: Си или Ада. Выбран Си (точнее, Limbo), поскольку он, во-первых, ближе к Верилогу, а во-вторых, находится в мэйнстриме: Си++, Java, ObjC, C#, D и так далее.

Если надо ровно три бита - есть тип Bit[3]. А вот как быть, если нужен знаковый бит, это пока вопрос.

Инженеры-электроники ничего не знают про типы. Они живут в терминах сигналов, фронтов, задержек.

[thesz.livejournal.com]

"Слишком далеко от практической применимости" - это что означает? Как мерялось расстояние? Что нужно - оказаться в мейнстриме или решить задачу?

Попробуйте положить Bit[3] на Си, получите Верилог.

Инженеры-электронщики от этого мучаются. Не далее, как вчера товарищ рассказал о своих мучениях, у него reset, на вход подается resetn. Он два дня искал, ему пришлось заниматься самогипнозом "у меня все правильно." И у всех сигналов есть определенный смысл, которых, по=хорошему, надо выразить в типах. Фронты и задержки появятся потом, когда будет этап оптимизации и отладки.

[vak]

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

Я смотрел:
Atom - http://funhdl.org/wiki/doku.php/atom
HDCaml - http://funhdl.org/wiki/doku.php/hdcaml
Hydra - http://www.dcs.gla.ac.uk/~jtod/Hydra/
Lava - http://raintown.org/lava/

Действительно забавно, но пока не вижу, в чём кайф.

Из Си никак Верилог не получится, дело не в типах. Может быть надо уточнить - я имею в виду синтез, а не симуляцию.

Мне нравится идея типизации сигналов. Но не хватает фантазии представить, как это могло бы выглядеть. Скажем, на примере того же светофора?

[thesz.livejournal.com]

"При отсутствии явных преимуществ" - это кто, опять же, оценивал? Меньшее количество ошибок - не преимущество? Легкость компиляции - не преимущество?

"Действительно забавно" - это как понимать? Судя по всему, что-то понравилось, что конкретно? С моей точки зрения важной частью Лавы и Hydra является корректность результатов "по построению." Сразу по грамматике автомата, да еще и грамматика видна в самом коде.

"Не вижу в чем кайф" - какой кайф нужен? Если нужно, чтобы в области дизайна заработали программисты без переучивания, то это невозможно. Если нужно, чтобы программисты заработали лучше без переучивания, это также невозможно.

Насчет типизации сигналов. На примере того же ресета. Отдельный сигнал мы описываем следующим полифморфным типом:

data UXWire w = U | X | W w
data UWire w = U | W w

-- где-то в дебрях кода
data ResetSignal = Reset | NormalWork
data ResetSignalN = ResetN | NormalWorkN
-- и код, передаваемый по проводам:
type ResetWire = UWire ResetSignal

Мы нигде не перепутаем Reset и ResetN. Их надо явно преобразовывать. Если у нас поменялся тип провода и он не может больше содержать неопределенных значений (X, мы перешли к синтезируемому RTL), нам снова придется поменять описание схемы.

Если нужен пример со светофором, прошу объяснить.

[vak]

Оценка личная персональная, интуитивная. Есть реальные проекты, есть живые люди, которые их делают. Меньшее количество ошибок - бесспорное преимущество. И тем не менее, народ не переходит массово, скажем, на Аду вместо C++.

Понравилось, что меньшим количеством кода можно описать более сложные вещи. А кайфа нет, потому что ясность кода при этом страдает. Известно, что при разработке читать код приходится в десятки раз чаще, чем писать. Меньше ясность - больше трудоёмкость - длинее сроки - больше ошибок.

Для тренировки "на кошечках" я придумал проект светофора для пешеходного перехода:
http://vak.ru/doku.php/proj/verilog/plog#%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82_%D0%BF%D0%B5%D1%88%D0%B5%D1%85%D0%BE%D0%B4%D0%BD%D0%BE%D0%B3%D0%BE_%D1%81%D0%B2%D0%B5%D1%82%D0%BE%D1%84%D0%BE%D1%80%D0%B0
Такой себе вполне законченный модуль (в верилоговском смысле). Реализация на Верилоге даст автомат примерно с двадцатью состояниями. Понимать и менять такой код довольно тяжело. Как бы реализация могла выглядеть на функциональном языке?

[thesz.livejournal.com]

data RoadLightStates =
        PassAuto
    |   ReadyingStopAuto { time :: Int }
    |   AutoWarned { time :: Int }
    |   PassWalkers { time :: Int }
    |   ReadyingWalkersStop { time :: Int }
    |   ReadyingAutoPass { time :: Int }

data Button = Pressed | NotPressed

data Lights =
    Lights { red :: Bool, yellow :: Bool, green :: Bool, stop :: Bool, walk :: Bool}

defLights = Lights False False False False False

wait3sec samestate nextstate time
    | time > timeout3sec = nextstate
    | otherwise = samestate

blink time = ((time / blinkcount) % 2) /= 0

roadlight PassAuto NotPressed = (PassAuto,defLights { green = True, stop = True })
roadlight PassAuto Pressed = (ReadyingStopAuto {
         autoGreenBlinkCount = Int, time = Int }
        ,defLights { green = True, stop = True })
roadlight (ReadyingStopAuto time} _ =
    (nextState,defLights {green = blinked, stop = True})
    where
        nextState = wait3sec
            (ReadyingStopAuto (time+1))
            (AutoWarned { time = 0 })
            time
        blinked = blink time
roadlight (AutoWarned time) _ =
    (nextState,defLights { yellow = True, stop = True)
    where
         nextState = wait3sec
              (AutoWarned { time = time+1})
              (PassWalkers { time = 0 })
              time
roadlight (PassWalkers time) _ =
    (nextState,defLights { red = True, walk = True })
    where
        nextState
            | time > timeout30sec = ReadyingAutoPass { time = 0}
            | otherwise = PassWalkers { time = time + 1 }
roadlight (ReadyingAutoPass time) _ =
     (nextState,defLights { red = True, yellow = True, walk = blink time})
     where
         nextState
             | time > timeout1sec = PassAuto
             | otherwise = ReadyingAutoPass ({ time = time+1 }

-- Для симуляции: воткнем это в защелку.
roadlightCircuit buttonPresses = loopS (PassAuto) roadlight buttonPresses

Там есть ашипка, но ее легко исправить.

Вот в таком табличном стиле все и пишется. Тут и параллельное вычисление в секции where, и машина состояний с протаскиваемым параметром.

[vak]

Спасибо! Буду изучать. Я не особый знаток Наскеля, так что это займет некоторое время. :)

[thesz.livejournal.com]

Всегда пожалуйста. ;)

[vak]

Ближе всего к моей идее находятся FPGA-C (http://sourceforge.net/projects/fpgac) и Transmogrifier C (http://www.eecg.toronto.edu/RESEARCH/tmcc/tmcc/). Только они компилируют сразу в нетлист, а мне кажется более разумным выдавать читабельный Верилог-код.

[thesz.livejournal.com]

Понятно, что.

Все равно непонятно, зачем.

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

[vak]

Как ни странно, переход с Верилога на Систем-Си даёт чуть ли не десятикратное ускорение разработок. По данным западных обзоров. Правда, имеется в виду моделирование, но один хрен. И дело, мне кажется, в том, что последовательное мышление проще для человека, чем параллельное. Алгоритм умножения в столбик проходят во втором классе: делай это, потом то, пока не получишь то-то. А потоки и семафоры - предмет отдельного изучения в университете.

Для синтеза VHDL ничем не лучше Верилога, вся его мощь нацелена на моделирование. Синтезируемые подмножества того и другого взаимно однозначно конвертируются.

Цель кратко формулируется как создание простого и практичного компилируемого языка для RTL-архитектуры. По аналогии с Си для фон-Неймановской архитертуры.

[thesz.livejournal.com]

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

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

В си побочные эффекты могут принимать самые причудливые формы. Поди, разберись, что оно делает. И вообще, имеет ли смысл делать a=a+2; b=b+3; в разных тактах, может, все же в одном?

Собственно, язык для HDL должен быть 1) не Тьюринг полным для простоты анализа, 2) позволять записывать реакции в табличном виде и поощрять этот вид записи и 3) иметь возможность собирать чистые функции в объекты с памятью отдельными конструкциями.

Мое мнение.

[vak]

Конечно, несколько не конфликтующих регистровых пересылок надо делать в одном такте. Для разбивки кода на такты я ввёл явные метки синхронизации. Фишка ф том, что разработчики желают по коду видеть, сколько тактов требуется при выполнении.

Насчет преимуществ табличного представления не готов согласиться. Несколько лет назад я разрабатывал реализацию протокола PPP для ядра FreeBSD. Все действия заданы в виде таблицы, прямо в тексте RFC. Казалось бы, куда уж проще, бери да кодируй. Нифига подобного, сил и времени на отладку ушло немеряно. Хуже того, в таблице обнаружились неочевидные ошибки: автомат попадал в тупиковые ситуации, сеанс PPP заклинивало. Выяснилось, что порядок некоторых действий спроектирован неправильно, надо было их поменять местами. Но просто поменять в таблице два элемента нельзя, от этого зависят другие элементы, и понеслось-поехало. Если бы протокол был описан в виде блок-схемы алгоритма, было бы гораздо проще.

Я странслировал вручную Plog-код светофора в Верилог, можно посмотреть здесь: http://vak.ru/doku.php/proj/verilog/tlight-v

[thesz.livejournal.com]

f state inputs = (state',outputs) - один такт. Пройдясь по переходам state, получим количество тактов.

Табличное представление табличному представлению рознь. Я программировал машины состояний на Паскале, Си, Тикле и Хаскеле. В Тикле я реализовал алгебраические типы и сравнение с образцом и все пошло, как по маслу, как в Хаскеле. В в последнем же вообще проблем не возникает. ;)

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

Насчет кода верилога - это же ужас, не так ли? ;)

[vak]

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

[microtrigger.livejournal.com]

а как на счет создания графа программы по таблице переходов?

[vak]

Существует много средств для визуализации графов, но как-то они не прижились массово в программировании. Всё-таки текстовое представление программы пока еще практичнее.

[microtrigger.livejournal.com]

очень рекомендую обратить внимание на этот проект Graphviz v2.12 http://www.graphviz.org/ Генерация блок схем и графов.
я сейчас его использую при создании документов, но думаю при должной сноровке его можно применить при созданиии графа програмного кода...

КА технология

[microtrigger.livejournal.com]

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

[vak]

Любопытно бы взглянуть.

[microtrigger.livejournal.com]

http://www.softcraft.ru/auto.shtml#ka - вот начальный материал.
щас кстати автор симавор в коде готовит, обещал скоро предоставить описание по его модели) я ему на днях ссылку скинул)