Особенности национальной работы - Ваши рубидии уже у кобальта во ртути
Mar. 1st, 2013
05:58 pm - Особенности национальной работы
Или "гладко было на бумаге, да забыли про овраги".
Языки описания логических схем, например, Verilog или VHDL, основаны на возможности записывать асинхронные процессы, активирующиеся по изменению значений переменных.
Например, если нужно, чтобы что-то происходило по переднему фронту сигнала clock, так и пишем: always @(posedge clock) begin ... end. Если нужно, чтобы значение переменной перевычислялось каждый раз, когда изменяется любая из переменных, входящая в выражение, пишем, например, так: assign var = expression; или так: always @* begin ... end. Здесь @* означает "если какая-нибудь из переменных, упомянутых внутри блока c целью прочитать ее значение, изменится, выполнить блок".
Теперь, допустим, у нас есть элемент асинхронной памяти, активной не по фронту, а по уровню разрешения на запись, т.е. всегда, когда сигнал разрешения на запись равен 1, реализованный как
always @*
if (write_enable) mem[address] = data; Что произойдет, если в какой-то момент write_enable равно единице, а переменная address изменится? Активируется этот процесс, и запишет текущее значение data в ячейку памяти по адресу, соответствующему новому значению переменной address. С точки зрения софтверного симулятора языка Verilog или VHDL - ровно в одну ячейку.Подумаем, как бы эта память была реализована в хардвере. Слегка упрощая, у каждой ячейки будет свой блок логических элементов, побитно сравнивающих входящий адрес с ее собственным и делающих логическое И результата сравнения c сигналом write_enable, чтобы понять, надо записывать в себя входящие данные или нет.
И если address меняется, скажем, с 1 (...001) на 2 (...010), а проводочки для разных бит чуть-чуть разной длины, то может случиться краткий миг, когда сочетание значений бит будет или ...000, или ...011, и ячейка с адресом 0 или 3 решит в себя что-нибудь записать, совершив тем самым неприемлемое самоуправство.
Бороться с этим в хардвере очень просто - достаточно перед изменением значения переменной address установить сигнал write_enable в 0, а после изменения адреса выждать время, достаточное для нивелировки разницы времени распространения сигнала по отдельным битам адреса, после чего установить write_enable в 1.
А вот бороться с непониманием этого отличия софтверной симуляции от хардвера в головах отдельных инженеров гораздо труднее. Я уже второй день мучаюсь.
Могу Вам сказать, что произийдёт с работающим на меня инженером, если он такое слепит: я его лично подвешу к потолку на крюке вдетом в самую важную часть его анатомии и заствлю съесть его диплом
Так-то просто. А с клиентом?
Edited at 2013-03-02 04:32 am (UTC)
Я довольно давно вынашиваю планы запилить свой HDL-язык с pattern matching'ом и datatyp'ами. Одна из основных идей (помимо перехода на современную систему типизации с вменяемым синтаксисом взамен устаревшей моды 80-х) — строгое соответствие языка нехитрой парадигме, которая доступна любому нормальному программисту и не сложнее, а даже, пожалуй, проще традиционных парадигм из области обычного программирования. Попробую изложить ее в одном абзаце.
Вся схема (как и каждый компонент) является просто функцией (большой арности и коарности) сигналов. Сигнал с точки зрения языка представляет собой значение некоторого типа, изоморфного бесконечному списку. При оперировании входными сигналами можно брать «текущий» элемент списка или один из «предыдущих» (на фиксированную глубину), для того чтобы сформировать значения «следущих» элементов списков выходных сигналов. Собственно, в этом и должно заключаться всё программирование. Композиция компонентов выражается как композиция функций изоморфна. Разумеется, это ограничивает множество выразимых схем — все они должны тактироваться одним клоком, который никак не дается программисту явно, а определяет понятие «текущий» и «предыдущий» в списке. (Ну еще полезно добавить ресет, который тоже задается неявно и выражается в том, что программист должен задать начальное состояние.) Как мне кажется, данная парадигма должна легко приниматься любым программистом, особенно функциональщиком. И, главное, все выразимые в ней схемы гарантированно являются синтезируемыми при некоторых естественных, встроенных в язык, ограничениях на типы и преобразования (не должно быть рекурсии и императивных циклов).
Конечно, не все полезные схемы попадают в класс выразимых. Но сложные места вроде переходов между клок-доменами можно изолировать и отдать на разработку опытному схемотехнику, который знает как минимум про код Грея.
Когда я изучал, что в мире делается в этом направлении, находил несколько интересных проектов в этом направлении. В основном попадаются погружения DSL в мощный язык типа хаскеля. Lava, ForSyDe — из этой области.
2) сравнение с образцом делали. Довольно удобно получается.
3) НО! всё портит такой ресурс, как время. Количество переключений в одном такте ограничено. Поэтому произвольная композиция работать не будет.
Если вы знаете Haskell, то просьба послать резюме на jobs@parsci.com ;)
автомобилей по дорогепакетов по сети, хоть симуляцию cmos-элементов. Вычленить из этого RTL-синтезируемое подмножество и объяснить хардверному дизайнеру, в чем оно состоит, действтельно, непросто.Придумать язык, на котором всё, что можно написать - синтезируемо, а всё несинтезируемое написать нельзя, наверное, теоретически возможно, но им вряд ли кто-нибудь в индустрии сейчас захочет пользоваться. Писать дизайн на разных уровнях детализации, а также всю тестирующую и верифицирующую обвязку к нему хочется на одном языке - именно поэтому сейчас есть System Verilog, а не SuperLog + Vera + E + черта лысого.
данная парадигма должна легко приниматься любым программистом, особенно функциональщиком
А должна легко приниматься любым хардверным дизайнером, особенно электронщиком.