[CaPpuCcino 0]

подумалось мне, что, чем отвечать всякий раз на похожие вопросы, проще один раз написать статеечку и всякий раз посылать человека... сначала ознакомиться.

Статеечка посвящена методике проектирования систем на ПЛИС и вкл. в себя 3 основные раздела: Моделирование, Имплементация, Верификация.

Здесь буду выкладывать её по частям (потому как она в оригинале написана на иностранном языке, объём большой, и сразу всё перевести мне пока не удаётся, да и потенциальному читателю попроще).

 

Прошу покритиковать нещадно русскоязычный вариант в надежде, что можно будет доработать и превратить сие в более качественный продукт, на предмет:

1) т.к. статья авторская и отражает моё видение проблемы, а видеть всего я не могу, а в том что могу, могу и ошибаться, то основная критика по существу предмета;

2) русскоязычной терминологии (термины вызвавшие затруднение на предмет аналогов в русск. тех. лит. сопровождаются английск. терминами в скобках);

3) ясности изложения;

4) достаточности раскрытия затронутых тем.

 

спасибо откликнувшимся

Verification_RUS.pdf

[Serhiy_UA 1]

...Прошу покритиковать ...

 

Идея здоровая.

1. Хотел бы прочесть короткие определения (авторское толкование) понятий: Моделирование, Имплементация, Верификация.

А также их место и роль в Методике проектирования на ПЛИС.

2. А как в отношении автоматизации процессов Моделирования, Имплементации и Верификации обстоят дела в мире?

3. Русский термин (а в скобках английский) желательно использовать везде.

 

Следующие статьи приветствуются. Понятно, что коротко писать нелегко, но все же.

[Maverick_ 15]

Прошу покритиковать нещадно русскоязычный вариант в надежде, что можно будет доработать и превратить сие в более качественный продукт, на предмет:

1) т.к. статья авторская и отражает моё видение проблемы, а видеть всего я не могу, а в том что могу, могу и ошибаться, то основная критика по существу предмета;

2) русскоязычной терминологии (термины вызвавшие затруднение на предмет аналогов в русск. тех. лит. сопровождаются английск. терминами в скобках);

3) ясности изложения;

4) достаточности раскрытия затронутых тем.

 

спасибо откликнувшимся

 

На мой взгляд идея написания статьи на данную тематику хорошая.

Может быть стоит сделать типа ведения и там написать:

Описать вначале для чего вообще нужна верификация, моделирование проектов для ПЛИС, если есть осциллограф (просто еще остались люди так мыслящие). Какие есть типы моделирования для ПЛИС (функциональное, ..., POST ROUTE) и в чем их разница, какую информацию они дают. С чего начать написания Testbench и как их корректно создавать - привести какой-то алгоритм, план, пример.

Но

- может стоит как-то разрядить текст какими-то наглядными примерами, рисунками, графиками, случаями из своей практики. Текст изложения сделать как-то попроще, чтобы читать было легче.

- Не хватает более плавных переходов между главами.

 

PS Пример книги: Хоровиц П., Хилл У. "Искусство схемотехники", написанной простым языком о сложных вещах.

[ViKo 1]

Пока обнаружил существенную нехватку запятых :)

Если бы файл можно было редактировать, было бы проще указать на недостатки.

Наверное, testbench - это не совсем верификация. Верификация - удостовериться в том, что там что-то правильно. А тест может быть более "хитрым".

И это - имплемент... так сразу и не поймешь...

1. implement ['ImplImqnt] (Mueller En-Ru)

1. n.

1. n. орудие; инструмент, прибор; обыкн. pl. принадлежности, утварь; инвентарь syn.: instrument, tool, utensil

2. v.

1) выполнять, осуществлять; обеспечивать выполнение; to implement a decision - проводить постановление в жизнь

2) снабжать инструментами syn.: further

 

Еще добавлю: exhaust - истощать (так точнее, чем "упрощать")

[Maverick_ 15]

Кстати нашел статейку от iosifk. Там как раз поднимет подобную проблему

Статья

PS как я говорил про стиль написания текста, привел еще пример

[andrew_b 15]

Пока обнаружил существенную нехватку запятых :)

Да.

 

И это - имплемент... так сразу и не поймешь...

Имплементация -- это реализация.

[yes 6]

а почему в оригинале не кладете?

на немецком или коммерческие причины?

[CaPpuCcino 0]

спасибо всем, кто потратил время на прочтение и комментарии. извините, плз, что написано с ошибкам и сложноперевариваемыми предложениями.

причина первому - текст ещё не проходил редакторскую правку. ошибки исправлю.

причина второму несколько сложнее - трудно найти баланс между простым языком, и краткостью и обобщённостью изложения. если излагать простыми предложениями и иллюстрировать примерами, то боюсь текст перерастёт из формата статьи (а оригинал итак порядка 20 стр. искл. рисунки), в формат книги (а книга дело ответственное). к тому же формат изложения не предполагает подход "делай как я" - такого материала хватает. хотелось сделать "коротко обо всём", т.е. выжимки без лишних витиеватых отступлений. в этом случае приземлённые примеры отвлекают от линии изложения и не могут передать всей сложности проблемы (хотя я попробую доработать и примеры и стилистику).

а почему в оригинале не кладете?

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

 

Если бы файл можно было редактировать, было бы проще указать на недостатки.

не хочется у уважаемой публики отнимать время на редакторскую обработку моей статьи, а по принципиальным вопросам, можно вытаскивать те предложения из текста, которые вызывают нарекания и постить их сюда для обсуждения.

[Maverick_ 15]

причина второму несколько сложнее - трудно найти баланс между простым языком, и краткостью и обобщённостью изложения. если излагать простыми предложениями и иллюстрировать примерами, то боюсь текст перерастёт из формата статьи (а оригинал итак порядка 20 стр. искл. рисунки), в формат книги (а книга дело ответственное). к тому же формат изложения не предполагает подход "делай как я" - такого материала хватает. хотелось сделать "коротко обо всём", т.е. выжимки без лишних витиеватых отступлений. в этом случае приземлённые примеры отвлекают от линии изложения и не могут передать всей сложности проблемы (хотя я попробую доработать и примеры и стилистику).

Тогда боюсь Ваша статья будет рассчитана на узкий круг читателей, точно не для начинающих и новичков

PS Может стоит разбить на несколько статей, но сделать для широкого круга

[CaPpuCcino 0]

Наверное, testbench - это не совсем верификация. Верификация - удостовериться в том, что там что-то правильно. А тест может быть более "хитрым".

Еще добавлю: exhaust - истощать (так точнее, чем "упрощать")

exhaust - это полный(исчерпывающий) перебор всех комбинаций, но согласен - чтобы не вводить в заблуждение заменю на "exhaustive search"

testbench - это на мой взгляд реализация конкретной верификационной задачи, при том реализованная с помощью процедурного языка(например ХДЛ). задача верификации однако может решатся и с помощью утверждений (assertions), и это уже не тестбенч. сама верификация может быть позитивная и негативная. позитивная проверяет соблюдение требований, а негативная отвечает за поиск ошибок (об этом у меня во вступление, которое скоро выложу), поэтому с моей точ.зр. верификация более широкое понятие, чем тестбенч. А по-вашему что есть тестбенч(более хитрый это что значит)?

 

Тогда боюсь Ваша статья будет рассчитана на узкий круг читателей, точно не для начинающих и новичков

но для начинающих уже пишет iosifk, нужно же соблюдать разделение труда :). народу разве нужна ещё одна статья о базовых вещах, но написанная другими словами и другим человеком?

статья и не рассчитана для новичков. это скорее для новичков+, то есть для того, кто уже умеет что-то делать, но ещё не сложил у себя в голове общую картину мира проектирования на ПЛИС, чтобы представлять где север, а где юг. а без компаса плыть к какой-то цели достаточно затруднительно.

но я конечно же подумаю над тем как её улучшить для понимания более широким кругом читателей/листателей.

 

1. Хотел бы прочесть короткие определения (авторское толкование) понятий: Моделирование, Имплементация, Верификация.

А также их место и роль в Методике проектирования на ПЛИС.

2. А как в отношении автоматизации процессов Моделирования, Имплементации и Верификации обстоят дела в мире?

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

2)тоже скорее да, хотя конкретные тулзы не рассматриваются - думаю это слишком "обо всём", да и я половину не знаю, чтобы потом за базар ответить смог бы :)

3. Русский термин (а в скобках английский) желательно использовать везде.

ок, англ. терминологию сохраню

 

 

Может быть стоит сделать типа ведения и там написать:

Описать вначале для чего вообще нужна верификация, моделирование проектов для ПЛИС, если есть осциллограф (просто еще остались люди так мыслящие). Какие есть типы моделирования для ПЛИС (функциональное, ..., POST ROUTE) и в чем их разница, какую информацию они дают. С чего начать написания Testbench и как их корректно создавать - привести какой-то алгоритм, план, пример.

и введение и про функциональную и gate-level верификацию есть. переведу - повешу.

создание тестбенча начинается с составления верификационного плана, а дальше ведь процесс творческий, как тут алгоритм напишешь? как их корректно создавать - формализировать-то невозможно, иначе бы всё машины делали б.

 

- может стоит как-то разрядить текст какими-то наглядными примерами, рисунками, графиками, случаями из своей практики. Текст изложения сделать как-то попроще, чтобы читать было легче.

- Не хватает более плавных переходов между главами.

спасибо, попробую сдюжить

[Des333 0]

 CaPpuCcino:

 

Статью пока не читал, так как только пришел, но обязательно в скором времени ознакомлюсь.

Очень рад, что есть люди, которые что-то делают в данном направлении. Спасибо за Ваш труд!  :)

 

 

 

 

Насчет следующего высказывания немного не согласен.

 сама верификация может быть позитивная и негативная. позитивная проверяет соблюдение требований, а негативная отвечает за поиск ошибок (об этом у меня во вступление, которое скоро выложу)

 

Точнее согласен с первой частью (то есть с позитивной).

 

Определение верификации, которое написано в ГОСТ (за ГОСТ извините :) ):

3.8.4 верификация(en verification; fr verification): Подтверждение на основе представления объективных свидетельств (3.8.1) того, что установленные требования (3.1.2) были выполнены

и описание, которое дает В.В.Кулямин:

Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам

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

А вот эпитеты "позитивное" и "негативное" можно как раз применить, как мне кажется, к тестированию.

 

Буду ждать вступления с более подробным описанием.  :)

[des00 25]

2 CaPpuCcino

1. Статья поставлена с ног на голову. Ладно, упомянули про верификационный план, но зачем раскрывать его детали, до того как вы дадите понятия этим деталям.

2. Язык очень тяжелый, некоторые предложения я понял только раза с 4го. Хотя по контексту понимал о чем идет речь. Не вижу смысла в таком излишнем нагружении.

3. С разделом "Референтные модели отклика системы" не согласен в принципе, особенно с определением разницы между golden model и scoreboarding. Уровни моделирования на основе различных black/gray/white box ложаться в объяснение лучше.

4. "Таким образом динамическая верификация строится на трёх основных понятиях: стимул, отклик и покрытие." Последнее это больше предмет assertion based верификации.

 

Кстати я делал что то подобное, когда готовил курс лекций для своих коллег по современной разработке на ПЛИС. Но тот курс был полностью сделан на основе пересказа различных Гуру пропущенных через сито личного опыта %). Правда это не дало большого результата, в современную разработку на современных средствах удалось затянуть всего ~7человек %(

 

PS. я обещал вам кое какие книги глянуть, постараюсь на этих выходных.

[CaPpuCcino 0]

1. Статья поставлена с ног на голову. Ладно, упомянули про верификационный план, но зачем раскрывать его детали, до того как вы дадите понятия этим деталям.

хрена себе упомянул - там целый раздел про него написан. притом формальная методика его выработки полностью оригинальная - я пока более чёткого формализованного подхода в лит-ре не нашёл (если кто знает источник, плз, укажите) в основном похоже на интуитивное составление плана, чего стоит проверят, а что - нет.

 

можно про с ног на голову поподробней? вы предлагаете сначала давать определения, потом строить повествование? а почему вы считаете плохим подход постепенного введения терминов? или вы что-то другое имеете ввиду под головой и ногами?

 

2. Язык очень тяжелый, некоторые предложения я понял только раза с 4го. Хотя по контексту понимал о чем идет речь. Не вижу смысла в таком излишнем нагружении.

согласен. буду работать.

 

3. С разделом "Референтные модели отклика системы" не согласен в принципе, особенно с определением разницы между golden model и scoreboarding. Уровни моделирования на основе различных black/gray/white box ложаться в объяснение лучше.

с этим в принципе не согласен: голден референс суть то, что у вас есть заранее посчитанный результат, которому все сказали "одобрям". как правило то, что было написато программерами, до идеи воплотить это в железе, хотя может быть и на любой стадии моделирования до верификации.

black, white, grey - это только наблюдаемость внутренностей имплементации и написание тестбенча со знанием конкретной реализации. об этом у меня тоже есть в предшествующих главах, кот. ещё не перев. т.о. референсная модель, и модель наблюдения по сути разные вещи. еси хотите могу привести насущные примеры

 

4. "Таким образом динамическая верификация строится на трёх основных понятиях: стимул, отклик и покрытие." Последнее это больше предмет assertion based верификации.

тож не согласен. функциональное покрытие может быть реализовано не только с ABV, ABV - это только инструмент. функциональное покрытие так же может быть описано с помощью процедурных языков(что по сути и происходило до появления PSL, и происходит сейчас как только вы поднимаетесь выше cycle-accurate модели)

 

Но тот курс был полностью сделан на основе пересказа различных Гуру пропущенных через сито личного опыта

...

PS. я обещал вам кое какие книги глянуть, постараюсь на этих выходных.

этот материал тож не copy-past с различных книжек - я б таким и заниматься не стал - скучно. лит-ру как раз просил чтобы не повторятся, а отсылать к тем источникам где вопрос хорошо проработан - в общем-то в самом материале достаточно много отнесений к разным книжкам.

за лит-ру (по крайне мере за намерение :) ) - спб! :)

 

Очень рад, что есть люди, которые что-то делают в данном направлении. Спасибо за Ваш труд!  :)

...

Насчет следующего высказывания немного не согласен.

ну пока не за что, мож не пригодится никому - вон Денис уже критикует :)

 

по поводу позитивной/негативной - я в общем-то этими терминами напрямую не пользовался - просто видел такую терминологию.

но в общем есть некоторое деление по цели верификации, которое для меня очевидно:

1) проверка соответствия

2) локализация ошибок

и инструментарий там разный - это как раз к разговору о black/gray/white box и о референсных моделях

1 - это black box и golden reference

2 - всё остальное

[Des333 0]

2) локализация ошибок

Ну, вот это уже часть отладки, а не верификации.  :)

[CaPpuCcino 0]

Ну, вот это уже часть отладки, а не верификации.  :)

ну, а если так попробовать: утверждения (assertions), которые вешаются на внутрисистемный интерфейс - это верификация или отладка?

ведь, утверждения помогают локализовать ошибку, т.е. исправить её

 

в логике которую использую я ответ будет следующим: на каждом уровне абстракции спецификация на систему различна -

если изначально от системы требовалось например обработать картинку таким-то образом за такое-то время - это спецификация уровня функциональной модели. в процессе разработки вы постепенно снижаете уровень абстракции уточняя модель. и например на уровне РТЛ у вас система состоит уже из n блоков, выполняющих каждый свою функцию, соединённых интерфейсами. так вот на уровне РТЛ вы в спецификацию заносите уже требования к протоколам этих интерфейсов и какие-то мат. функции блоков. и в процессе верификации должны проверить, что эти низкоуровневые требования исполняются. но с точки зрения спецификации на уровне функциональности всей системы это будет уже отлов ошибок, а с точки зрения каждого блока - верификация его функциональности.

такие дела