|
|
Oldring> С++ шаблоны - это пример средства, с использованием
Oldring> которого _очень легко_ написать программу, в которой
Oldring> никто не сможет разобраться, даже автор.:)) Про ассемблер можно сказать почти тоже самое. Один неглупый человек
сказал: "Связность, читаемость и надежность программы гораздо больше зависит от
программиста, чем от языка на котором он пишет. Хороший язык помогает в этом,
плохой мешает, но не более того."Могучее средство предполагает и соответствующую ответственность. Шаблоны -
мощное средство, поэтому пользоваться ими надо обдуманно и осторожно. Лично мне
в них не нравится только излишне многословный и запутанный синтаксис. Но на
уровне идей и реализации все нормально.Oldring> "Синтезатор SystemC обязан понимать полную спецификацию
Oldring> языка" - а что такое эта самая пресловутаю "полная спецификация
Oldring> языка"? С++? Тогда - это утопия.Та, которая определена Стандартом. Никакой утопии нет. Понимать
спецификацию языка и поддерживать на уровне синтеза - согласитесь, две большие
разницы! Синтезатор должен понимать все языковые конструкции хотя бы для того,
чтобы найти во входном описании то, что подлежит синтезу, ругнувшись на то, что
не подлежит. Если я напишуalways @(posedge clk) #10 a <= ~a;
то синтезатор это, ессно, не будет синтезировать и выдаст сообщение, что
задержки являются несинтезируемыми. Но чтобы сообщить об этом, синтезатор
должен _понимать_ спецификацию языка.Oldring> Не случайно синтезаторы VHDL понимают только очень узкое подмножество
Oldring> VHDL.Не "понимают", а поддерживают на уровне синтеза.
Oldring> Так как синтез железа - это не исполнение программы,
Oldring> а трансляция её в совершенно другую вычислительную модель.Естественно, с этим никто не спорит.
Oldring> Будь Вы разработчиком синтезатора - Вам вряд-ли удастся
Oldring> оттранслировать в железо, скажем operator new. Да и
Oldring> указатели вообще.В том виде, как они используются в программной модели - да. Но это и не
нужно. Во-первых, нужно определить, какую функцию эти сущности несут в железе.
Во-вторых, определить ограничения. Например, что есть указатель? Указатель в
программе - объект, содержащий адрес другого объекта. Для каких целей? Для
целей косвенного обращения. Имеется ли в железе подобное косвенное обращение?
Имеется, но есть ограничения. Первое ограничение на использование указателя -
он должен быть проинициализирован на этапе синтеза валидным значением. Второе -
это значение должно быть либо известно при синтезе, либо входить в множество
известных опять же на этапе синтеза. В итоге при синтезе получится что-то вроде
того, что получается с помощью HDL'ной конструкции case.Другой пример - память. Память есть в железе? Есть. Адресоваться к ней с
помощью указателя удобно? Удобно. Адресная арифметика при работе с памятью
нужна? Нужна.Что касается new, то и тут не следует понимать буквально, что внутри той же
ПЛИСки, например, будет на рантайме происходить выделение ресурсов. Для new
достаточно ввести ограничение, что он может использоваться только при создании
объектов со static storage duration и в конструкторах таких объектов. Вопрос: а
нафига он вообще тогда? Ответ: для более гибкой поддержки реализации описания
программным путем.Oldring> И не забывайте про проблему остановки.
Не понял, что имеется в виду.
Oldring> И Вы уверены, что синтезаторы SystemC работают именно
Oldring> на уровне препроцессированного кода? Я ничего подобного
Oldring> не помню - когда знакомился с SystemC в документации
Oldring> опоминались только макросы.Я не только мануалы почитал, но в исходных текстах мельком покопался. Там
мне попалась куча кода на С++ с наследованием в том числе. Например, многие
объекты определены как классы-потомки от класса sc_module, который, в свою
очередь, является производным от sc_object. Что-то мне подсказывает, что
синтезатор должен работать на этом уровне, а не на уровне препроцессора. Одним
из этого "что-то" является, например, тот факт, что многие объекты-сигналы
определятся не через препроцессор, а напрямую: sc_bit - класс; или sc_bv-
шаблон для определения вектора сигналов. Т.е. препроцессором тут и не пахнет.
Как же все это реализуется, если синтезатор не лезет глубже препроцессора?Oldring> В конце концов, разработчики синтезатора никому ничего не обязаны.
Oldring> Гораздо проще
Oldring> свой препроцессор написать, выделяющий декларации SystemC,
Oldring> чем отслеживать наследование.Это, конечно, проще, только на препроцессоре далеко не уедешь. Если бы все
упиралось в препроцессор, то проще уж было бы взять не С++, а С, который сам по
себе гораздо проще.Oldring> Действительно, синтезируемые подмножества VHDL и Verilog
Oldring> появились именно как подмножества языков для моделирования
Oldring> железа. Но заметьте, пожалуйста, что с самого начала
Oldring> эти языки были рассчитаны именно на моделирование железа.Насчет VHDL не скажу, а Верилог создавался для моделирования систем. А уж
какие это будут системы, вопрос второй.Oldring> Т. е. на моделирование большого количества мелких параллельных
Oldring> процессов. С С++ ситуация совершенно другая. В С++ _нет
Oldring> вообще_ параллельных процессов.А никто и не говорит, что С++ - HDL. Речь не про С++, а про SystemC,
который, повторяю, вообще не язык, а средство для описания в том числе и
параллельных процессов. Разница лишь в том, что в одном случае (в Verilog/VHDL)
средства встроены в язык, в другом они вынесены во внешнюю библиотеку. Этот
подход идет от С, наследуется С++, как более гибкий.Oldring> Думаю, любое описание железа будет двухуровневым. На
Oldring> верхнем уровне нужно описать структуру системы с параллельными
Oldring> интерфейсами между компонентами. На нижнем уровне приходится
Oldring> описывать с использованием иерархических, т. е. последовательных
Oldring> конструкций изменение состояния компонента при изменении
Oldring> входных сигналов. Что дает для этого описания использование
Oldring> именно С++?Все, что требуется, и дает. Последовательность операторов в нем есть, так
сказать, нативно - т.е. то, что делается у Verilog внутри always-блоков, у VHDL
внутри process-блоков. А параллельность обеспечивается с помощью классов,
вынесенных в библиотеку. Компилятор, воспринимая входное описание, должен
соорудить что-то наподобие многозадачной ОС, где каждый параллельно исполняемый
блок - процесс. А синтезатор должен сгенерить функционально такую же систему в
железе. Понятно, что не забываем про ограничения, вследствие которых
синтезируемая часть SystemC значительно меньше полной.
Oldring> По поводу отсутствия инкапсуляции в Верилоге - так может
Oldring> быть, вам попробовать VHDL?Благодарствуйте, не хочу никого задеть, но от VHDL меня слегка тошнит. По
двум причинам - многословность синтаксиса и дебильная (другого слова не
подберу, извините) строгость типов. Я не против сильной типизации, но,
перефразируя, "типизация должна быть максимально сильной, но не более". В VHDL,
имхо, с этим переборщили. Такая типизация напоминает квартиру, где на каждой
внутренней двери замок и все двери заперты. И чтобы зайти куда угодно, надо
сначала отпирать дверь. И так каждый раз... В своей квартире я предпочитаю
внутренние двери вообще держать открытыми и закрывать их только когда это
действительно необходимо. И эту необходимость я желаю определять сам, а не
поручать это тупой программе (какой бы умной она не была, она все равно тупая
:)Oldring> Правда, я плохо представляю, чем инкапсуляция в случае железа
Oldring> отличается от разбиения
Oldring> на компоненты, взаимодействующие через хорошо формализованные
Oldring> интерфейсы - но, по крайней мере, возможность описывать
Oldring> подтипы и структуры в VHDL должно сильно облегчить проектирование
Oldring> таких интерфейсов.В целом да, VHDL вполне реализует идею инкапсуляции. Вопрос в удобстве
реализации. На Верилоге ведь тоже можно лепить модуль на каждый чих, только
пользоваться этим не слишком-то удобно.К тому же, инкапсуляция - одно из... Только из-за нее сыр-бор разводить,
конечно, не стОит. Но есть еще, как говорится, до кучи всякого.
E-mail: 
info@telesys.ru
