![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Язык Plog: проект пешеходного светофора
В качестве примера рассмотрим проект светофора для пешеходного перехода. Имеем следующее оборудование:
- светофор для автомобилей, три сигнала: красный, желтый, зеленый
- светофор для пешеходов, два сигнала: стойте, идите
- кнопка запроса на переход для пешехода
- служебная кнопка сброса светофора в исходное состояние
- генератор импульсов, задающий время
Проектируемый модуль имеет три входа и пять выходов:
________ rst ---| |--- red clk ---| |--- yellow | |--- green | | button ---| |--- stop | |--- walk |______|Фазы светофора:
- Зеленый для автомобилей, “стойте” для пешеходов. Обычное состояние при отсутствии пешеходов.
- Мигает зеленый для автомобилей, горит “стойте” для пешеходов. Включается через некоторое время (не более 30 секунд) после нажатия кнопки запроса. Длится три секунды.
- Жёлтый для автомобилей, “стойте” для пешеходов. Длится три секунды.
- Красный для автомобилей, “идите” для пешеходов. Длится десять секунд.
- Красный для автомобилей, мигает “идите” для пешеходов. Длится три секунды.
- Жёлтый+красный для автомобилей, “стойте” для пешеходов. Длится одну секунду.
“Примерная” реализация светофора на языке Plog приведена здксь: http://vak.ru/doku.php/proj/verilog/tlight-plog
Спецификация языка еще не готова, пока только образец кода. После компиляции должен получиться примерно такой код на Верилоге: http://vak.ru/doku.php/proj/verilog/tlight-v
Можно видеть, как компилятор создает набор состояний и переходов конечного автомата.
no subject
no subject
Мелочи всё это. Мне сейчас надо саму концепцию застолбить. И проверить на вшивость.
no subject
no subject
Интересная ссылочка, спасибо. Но всё же прав Столлман, гнать надо все эти софтовые патенты. Слава богу, Европе хватило ума их запретить.
no subject
no subject
no subject
no subject
За книжки действительно премного благодарен, юзаю и наслаждаюсь. Паттерсон и Хеннеси - просто прелесть.
Ну, ты себя так сильно не укоряй, этот вирус я не от тебя подхватил. Насчет инфернальности не знаю, Ефремова ниасилил, слишком много букаф. :)
Но есть какая-то такая фишка, которая передается от человека к человеку, помимо слов и идей. Мистическое шило в заднице. :)
no subject
Сравни с моим Хаскельным. И в verilog переводится один в один, и записано короче. И понятней. И проверяемей - я даже могу проверить недостижимые состояния. Более того, гибче - нет явных delay. К тому же у тебя непонятно, что выполняется в один такт, что в несколько. ;)
no subject
Врубился в код, но никак мне не кажется твой вариант более понятным. Не то полушарие работает? :)
no subject
no subject
no subject
В твоем коде как раз не видно, что сколько времени выполняется. "Синхроны" спрятаны в delay, в котором, похоже, ошибка. ;)
no subject
И ошибку в delay() не вижу. Вроде всё как задумано.
Чтобы понимать время выполнения, надо для каждой процедуры держать в голове количество тактов. Вызов процедур фактически выполняется как макроподстановка. Надо еще подумать, нужны ли функции, возвращающие результат.
no subject
Если по синхронизации, то она в delay стоит вне цикла (ошибка). Если по точке с запятой, то несколько присвоений подряд (а начале цикла) будут выполнятся излишне медленно (ошибка в другом месте, зато в delay все правильно;).
Если не будет функций, возвращающих результат, то это вообще - туши свет. ;)
no subject
С функциями возникает интересный вопрос. Предположим, имеется пара функций a() и b(), каждая из которых вычисляется за несколько тактов. При выполнении c := a() + b() обе функции можно было бы вычислять одновременно. Что делать с побочными эффектами функций, типа изменения внешних сигналов? Или забить, пусть юзер сам решает?
Потом, если можно функции выполнять одновременно, надо бы и для процедур такое разрешить.
no subject
На какое расстояние распространяется окраска? Кто и как за этим будет следить?
В функциях есть побочные эффекты. Великолепно. ;)
А что будет, если a() выполняется за N тактов, а b() за M?
x+y за сколько тактов выполняется? А x+y+z? А sum(arr,1,M)? А в большой программе кто ответственен за самый длинный такт (за критическую цепочку)?
Сравни с подходом с функциями с изменением состояний.
Функции чистые. Состояния явные. Побочные эффекты явные. Длительность выполнения всегда один такт. Ясно, кто содержит критическую цепочку.
Выбор за вами. ;)
no subject
Если функции в одном выражении выполняются за разное количество тактов, придется хранить более ранний результат в промежуточном регистре.
Функциональный подход мне нравится. Но я лично не рискну двигаться в эту сторону, не моё это болото... :/
no subject
no subject
a <= @(posedge clk) b. И написал для этого специальный препроцессор VITO. Но это полумера всё-же. Макроассемблеры тоже были полезны в своё время, но вымерли как динозавры.no subject
Оператор
a <= @(posedge clk) bпридумывать не надо - он в стандартном языке легален.no subject