[CaPpuCcino 0]

Про TLM не воспринимайте всерьез (конец рабочего дня, чего не напишешь сгоряча). Насколько Я знаю этот термин появляется только при упоминании об уровнях абстракции SystemC (см. ту же книгу на стр. 201).

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

причина по которой мне показалось что не стоит включать в тот ряд TLM - это то что приведённый вами ряд характеризует абстракцию именно операционных но не коммуникационных объектов(т.е. объектами этих классификаций являются разные сучности - в вашем случае - операционные блоки, в случае ТЛМ - система коммуникации этих блоков) хотя ряд BCA-BFM-TLM (bus cycle accurate , bus functional model , trans. lev. model) и пересечётся с вашим рядом наверное на системном уровне т.к. системный уровень насколько я его понимаю это BEH+TLM.

(однако эт уже слишком отвлечённо)

[des00 25]

Добрый день всем!

После небольшого перерыва, связанного с большим кол-ом работы,

работа над сим документом будет продолжена.

По мере обновления документа: новости, обсуждения и т.д. будут поститься в эту ветку.

[nikolascha 0]

Добрый день всем!

После небольшого перерыва, связанного с большим кол-ом работы,

работа над сим документом будет продолжена.

По мере обновления документа: новости, обсуждения и т.д. будут поститься в эту ветку.

Что-то жизнь показала обратное, ветка остановилась, а жаль...

[Des333 0]

Что-то жизнь показала обратное, ветка остановилась, а жаль...

des00, насколько мне не изменяет память, сейчас отдает предпочтения SV.  :)

 

 

 

 

 

Вот от такой же темы касательно V/SV(да еще учитывая опыт, приобретенный автором за эти годы) я бы не отказался. 

[D-Luxe 0]

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

 

Jul 4 2006, 09:58

 

Conventions

 

RTL: Register Transfer Level. This document mean, that RTL is coding style which is using for synthesis purposes. This code can contain processes with sensitivity list or processes without sensitivity list with single level of ”wait until” expression. This code can be synthesizable via synthesizer.

 

BEH : Behavioral code. This document mean, that BEH is coding style which is using for functional testing purposes only. This code can contain multi level hierarchy of ”wait until” expression and use any techniques for process’s synchronization. This code may not be synthesizable via synthesizer.

 

SIM : Test benches, test code and resources for simulation and verification.

 

вы спорите об старых соглащениях. Интересно можно ли выложить новый файл в замен старого.

Тогда в чем отличие между BEH описанием и SIM?

[AndrewS6 0]

Тогда в чем отличие между BEH описанием и SIM?

BEH - несинтезируемая модель устройства.

SIM - модули, задающие тестовые воздействия на входы устройства и проверяющие результаты работы алгоритмов тестируемых модулей. Чаще всего воздействия идут на модель и на RTL, результаты работы модели и синтезируемой схемы сравниваются.

Изменено 18 мая, 2011 пользователем AndrewS6

[D-Luxe 0]

BEH - несинтезируемая модель устройства.

SIM - модули, задающие тестовые воздействия на входы устройства и проверяющие результаты работы алгоритмов тестируемых модулей. Чаще всего воздействия идут на модель и на RTL, результаты работы модели и синтезируемой схемы сравниваются.

Интересный подход. Не проще сразу писать RTL? Зачем писать две модели, а потом их сравнивать, если в ПЛИС ляжет синтезируемая модель?

[Shtirlits 0]

Сравнивают не модели, а используют модель в составе теста.

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

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

 

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

 

Если на пальцах объяснять, то при написании RTL без тестов вы как бы говорите, что хотите сделать именно то, что сделали. Или сделали именно то, что хотели. Или в крайнем случае что именно вы хотели сделать знаете только вы, так как эта информация вышла за пределы мозга только в одном виде - в виде RTL. При этом она смешалась с информацией о том, как именно вы это сделали, что за архитектура, возможности средств разработки и т.п. кучей информации, не имеющей к задаче отношения. Понять по этой каше где проходит граница между правильным и глючным кодом формально никто не может.

Разработчик RTL без тестов и моделей ведет себя как Хан Соло, герой Star Wars, чем вызывает желание повторять реплики Леи.

 

c3po: This is suicide! There's nowhere to go.

Solo: There. That looks pretty good.

Leia: What looks pretty good?

Solo:Yeah. That'll do nicely.

c3po:Excuse me, ma'am, but where are we going?

Leia: I hope you know what you're doing.

© Empire strikes back

 

Если есть модель, то уже можно представить себе ситуацию, когда кто-то сможет ответить на вопрос "эквивалентны ли модель и RTL?" И для этого не нужен автор модели.

 

Впрочем, даже модель не обязательна, достаточно тестов.

 

PS: люди бывают разные. некоторые спокойно переносят сбои софта и железа, некоторые нет.

[Maverick_ 15]

Сравнивают не модели, а используют модель в составе теста.

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

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

 

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

 

Если на пальцах объяснять, то при написании RTL без тестов вы как бы говорите, что хотите сделать именно то, что сделали. Или сделали именно то, что хотели. Или в крайнем случае что именно вы хотели сделать знаете только вы, так как эта информация вышла за пределы мозга только в одном виде - в виде RTL. При этом она смешалась с информацией о том, как именно вы это сделали, что за архитектура, возможности средств разработки и т.п. кучей информации, не имеющей к задаче отношения. Понять по этой каше где проходит граница между правильным и глючным кодом формально никто не может.

Разработчик RTL без тестов и моделей ведет себя как Хан Соло, герой Star Wars, чем вызывает желание повторять реплики Леи.

 

c3po: This is suicide! There's nowhere to go.

Solo: There. That looks pretty good.

Leia: What looks pretty good?

Solo:Yeah. That'll do nicely.

c3po:Excuse me, ma'am, but where are we going?

Leia: I hope you know what you're doing.

© Empire strikes back

 

Если есть модель, то уже можно представить себе ситуацию, когда кто-то сможет ответить на вопрос "эквивалентны ли модель и RTL?" И для этого не нужен автор модели.

 

Впрочем, даже модель не обязательна, достаточно тестов.

По моему, еще модель относительно легче пишется, чем RTL описание.

А вот сделать хороший тест с покрытием хотя бы 99,9% тяжелее и этим должны заниматься другие люди - тестеры

Иногда написание хорошего теста сопоставимо с написанием RTL модели/описания, а иногда даже тяжелее...

[D-Luxe 0]

Сравнивают не модели, а используют модель в составе теста.

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

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

 

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

 

Если на пальцах объяснять, то при написании RTL без тестов вы как бы говорите, что хотите сделать именно то, что сделали. Или сделали именно то, что хотели. Или в крайнем случае что именно вы хотели сделать знаете только вы, так как эта информация вышла за пределы мозга только в одном виде - в виде RTL. При этом она смешалась с информацией о том, как именно вы это сделали, что за архитектура, возможности средств разработки и т.п. кучей информации, не имеющей к задаче отношения. Понять по этой каше где проходит граница между правильным и глючным кодом формально никто не может.

Разработчик RTL без тестов и моделей ведет себя как Хан Соло, герой Star Wars, чем вызывает желание повторять реплики Леи.

 

c3po: This is suicide! There's nowhere to go.

Solo: There. That looks pretty good.

Leia: What looks pretty good?

Solo:Yeah. That'll do nicely.

c3po:Excuse me, ma'am, but where are we going?

Leia: I hope you know what you're doing.

© Empire strikes back

 

Если есть модель, то уже можно представить себе ситуацию, когда кто-то сможет ответить на вопрос "эквивалентны ли модель и RTL?" И для этого не нужен автор модели.

 

Впрочем, даже модель не обязательна, достаточно тестов.

 

PS: люди бывают разные. некоторые спокойно переносят сбои софта и железа, некоторые нет.

Под тестом вы понимаете TestBench?

 

Если я все правильно понял, то сначала пишется несинтезируемая модель, она фактически является своего рода ТЗ. После пишется RTL, и пишется тестбенч, который задает тестовые вектора на обе модели и результаты моделирования сравниваются.

[Shtirlits 0]

Тестом я обычно называю то, что требует визуально получить прямо в мозг только один бит passed/failed.

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

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

Формулировка корректности схемы иногда существенно упрощается, когда есть модель всего, что между разрабатываемой логической схемой и выходами платы или устройства. Работа без моделей памяти (micron, samsung и т.п.) невообразима многим специалистам.

 

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

При написании модели стараюсь придерживаться подхода минимальной обработки входной информации внутри черепной коробки. Если в спецификации (или другом исходном документе) написано "1+1+1+1", то так и нужно записать, не следует писать "4". Фокусы сродни тех, что показывают некоторые знатоки препроцессора языка СИ, тут вовсе неуместны. Если обработка необходима, то её следует по возможности также внести в модель в виде отдельных фнукций и только в крайнем случае что-то обрабатывать в голове.

 

Модель по определению проще, чем тест.

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

 

PS: честно говоря, мне еще не доводилось писать модель микросхемы по datasheet, в котором бы не оказалось какой-нибудь неясности, неточности или неопределенности касающейся timing-ов. (ну, или сейчас такое чувство нахлынуло).