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

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

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

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

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

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

Flat | Top-Level Comments Only

From:

thesz.livejournal.com

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

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

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

From:

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/

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

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

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

From:

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), нам снова придется поменять описание схемы.

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

From:

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
Такой себе вполне законченный модуль (в верилоговском смысле). Реализация на Верилоге даст автомат примерно с двадцатью состояниями. Понимать и менять такой код довольно тяжело. Как бы реализация могла выглядеть на функциональном языке?

From:

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, и машина состояний с протаскиваемым параметром.