![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vakИдея состоит в построении процедурного Си-подобного языка, который бы однозначным образом компилировался в Верилог.
Язык Си часто называют высокоуровневым ассемблером. В этом есть определенная сермяжная правда: опытный программист хорошо представляет себе, в какие ассемблерные конструкции превращается Си-шный код. Нечто аналогичное хочется проделать с Верилогом.
Отличие разработки на Верилоге от традиционного программирования состоит в существенно более высоком уровне параллелизма. Система создается как некоторое количество конечных автоматов, фукнционирующих одновременно. Каждый из конечных автоматов имеет несколько десятков, реже - сотен состояний. Количество таких автоматов - тысячи и десятки тысяч.
Традиционная же программа представляет собой один конечный автомат, имеющий сотни тысяч и миллионы состояний. Каждое значение регистра адреса команды (PC) есть одно состояние конечного автомата. Иногда программа может состоять из нескольких конечных автоматов, если в ней используются потоки.
Представляется интересным проект языка — надстройки над Верилогом, позволяющего писать программы в процедурном стиле, но оставляющего свободу доступа к низкому уровню для инженера-электроника.
no subject
Date: 2007-06-21 18:26 (UTC)Большая часть аппаратуры, во-первых, таблично-реактивна (в таком состоянии по такому воздействию выдай то-то и перейди туда), во-вторых, чиста от побочных эффектов. Побочный эффект появляется при защелкивании.
В си побочные эффекты могут принимать самые причудливые формы. Поди, разберись, что оно делает. И вообще, имеет ли смысл делать a=a+2; b=b+3; в разных тактах, может, все же в одном?
Собственно, язык для HDL должен быть 1) не Тьюринг полным для простоты анализа, 2) позволять записывать реакции в табличном виде и поощрять этот вид записи и 3) иметь возможность собирать чистые функции в объекты с памятью отдельными конструкциями.
Мое мнение.
no subject
Date: 2007-06-22 20:23 (UTC)Насчет преимуществ табличного представления не готов согласиться. Несколько лет назад я разрабатывал реализацию протокола PPP для ядра FreeBSD. Все действия заданы в виде таблицы, прямо в тексте RFC. Казалось бы, куда уж проще, бери да кодируй. Нифига подобного, сил и времени на отладку ушло немеряно. Хуже того, в таблице обнаружились неочевидные ошибки: автомат попадал в тупиковые ситуации, сеанс PPP заклинивало. Выяснилось, что порядок некоторых действий спроектирован неправильно, надо было их поменять местами. Но просто поменять в таблице два элемента нельзя, от этого зависят другие элементы, и понеслось-поехало. Если бы протокол был описан в виде блок-схемы алгоритма, было бы гораздо проще.
Я странслировал вручную Plog-код светофора в Верилог, можно посмотреть здесь: http://vak.ru/doku.php/proj/verilog/tlight-v
no subject
Date: 2007-06-22 20:49 (UTC)f state inputs = (state',outputs)- один такт. Пройдясь по переходам state, получим количество тактов.Табличное представление табличному представлению рознь. Я программировал машины состояний на Паскале, Си, Тикле и Хаскеле. В Тикле я реализовал алгебраические типы и сравнение с образцом и все пошло, как по маслу, как в Хаскеле. В в последнем же вообще проблем не возникает. ;)
В Си и компании локальные переменые состояния объявлены глобально, за ними надо следить, при этом возникает желание соптимизировать, используя одну и ту же переменную в разных местах. В Хаскеле переменные надо протягивать вместе с состоянием. Это позволяет лучше проверять машины состояний.
Насчет кода верилога - это же ужас, не так ли? ;)
no subject
Date: 2007-06-24 20:41 (UTC)no subject
Date: 2007-06-24 23:29 (UTC)no subject
Date: 2007-06-25 14:32 (UTC)no subject
Date: 2007-06-25 16:04 (UTC)я сейчас его использую при создании документов, но думаю при должной сноровке его можно применить при созданиии графа програмного кода...