CaPpuCcino 0 15 июля, 2006 Опубликовано 15 июля, 2006 · Жалоба Про TLM не воспринимайте всерьез (конец рабочего дня, чего не напишешь сгоряча). Насколько Я знаю этот термин появляется только при упоминании об уровнях абстракции SystemC (см. ту же книгу на стр. 201). вообще-то TLM не связан жёстко с SystemC - это тоже абстракция которую можно создать на достаточно высокоуровневом языке - суть её для себя я определяю как вынесение из объектов системы механизмов связанных с передачей данных между этими объектами - т.е. в объектах системы остаётся только их основная функциональнать и они больше не заботятся как получать и посылать данные (это конечно же не сводится к простому выносу шинных операций в отдельный модуль/файл, но зачастую - к вызовам функций неких "транспортных" объектов) причина по которой мне показалось что не стоит включать в тот ряд TLM - это то что приведённый вами ряд характеризует абстракцию именно операционных но не коммуникационных объектов(т.е. объектами этих классификаций являются разные сучности - в вашем случае - операционные блоки, в случае ТЛМ - система коммуникации этих блоков) хотя ряд BCA-BFM-TLM (bus cycle accurate , bus functional model , trans. lev. model) и пересечётся с вашим рядом наверное на системном уровне т.к. системный уровень насколько я его понимаю это BEH+TLM. (однако эт уже слишком отвлечённо) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 30 августа, 2006 Опубликовано 30 августа, 2006 · Жалоба Добрый день всем! После небольшого перерыва, связанного с большим кол-ом работы, работа над сим документом будет продолжена. По мере обновления документа: новости, обсуждения и т.д. будут поститься в эту ветку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nikolascha 0 29 августа, 2009 Опубликовано 29 августа, 2009 · Жалоба Добрый день всем! После небольшого перерыва, связанного с большим кол-ом работы, работа над сим документом будет продолжена. По мере обновления документа: новости, обсуждения и т.д. будут поститься в эту ветку. Что-то жизнь показала обратное, ветка остановилась, а жаль... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Des333 0 30 августа, 2009 Опубликовано 30 августа, 2009 · Жалоба Что-то жизнь показала обратное, ветка остановилась, а жаль... des00, насколько мне не изменяет память, сейчас отдает предпочтения SV. :) Вот от такой же темы касательно V/SV(да еще учитывая опыт, приобретенный автором за эти годы) я бы не отказался. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
D-Luxe 0 17 мая, 2011 Опубликовано 17 мая, 2011 · Жалоба господа, тем кто следит за веткой я же внес большую конкретику в определения 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 18 мая, 2011 Опубликовано 18 мая, 2011 (изменено) · Жалоба Тогда в чем отличие между BEH описанием и SIM? BEH - несинтезируемая модель устройства. SIM - модули, задающие тестовые воздействия на входы устройства и проверяющие результаты работы алгоритмов тестируемых модулей. Чаще всего воздействия идут на модель и на RTL, результаты работы модели и синтезируемой схемы сравниваются. Изменено 18 мая, 2011 пользователем AndrewS6 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
D-Luxe 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба BEH - несинтезируемая модель устройства. SIM - модули, задающие тестовые воздействия на входы устройства и проверяющие результаты работы алгоритмов тестируемых модулей. Чаще всего воздействия идут на модель и на RTL, результаты работы модели и синтезируемой схемы сравниваются. Интересный подход. Не проще сразу писать RTL? Зачем писать две модели, а потом их сравнивать, если в ПЛИС ляжет синтезируемая модель? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 18 мая, 2011 Опубликовано 18 мая, 2011 · Жалоба Сравнивают не модели, а используют модель в составе теста. Чтобы получился тест, нужно к модели приделать генераторы входных воздействий и тогда можно выход модели сравнивать с выходом 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 19 мая, 2011 Опубликовано 19 мая, 2011 · Жалоба Сравнивают не модели, а используют модель в составе теста. Чтобы получился тест, нужно к модели приделать генераторы входных воздействий и тогда можно выход модели сравнивать с выходом 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 25 мая, 2011 Опубликовано 25 мая, 2011 · Жалоба Сравнивают не модели, а используют модель в составе теста. Чтобы получился тест, нужно к модели приделать генераторы входных воздействий и тогда можно выход модели сравнивать с выходом 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 26 мая, 2011 Опубликовано 26 мая, 2011 · Жалоба Тестом я обычно называю то, что требует визуально получить прямо в мозг только один бит passed/failed. Слово "testbench" я зачастую встречал рядом с неким генератором одной входной последовательности предполагающей визуальный контроль осциллограмм выходов. Тест существенно легче изготовить имея формальный ответ на вопрос "что есть правильно". Особенно в цифровом виде. Отдельно приятно, когда он выражен на уже поддерживаемом языке. Формулировка корректности схемы иногда существенно упрощается, когда есть модель всего, что между разрабатываемой логической схемой и выходами платы или устройства. Работа без моделей памяти (micron, samsung и т.п.) невообразима многим специалистам. Модель не обязана быть не синтезируемой. Ей всего лишь не обязательно быть синтезируемой, если так проще (а значит меньше шансов ошибиться). При написании модели стараюсь придерживаться подхода минимальной обработки входной информации внутри черепной коробки. Если в спецификации (или другом исходном документе) написано "1+1+1+1", то так и нужно записать, не следует писать "4". Фокусы сродни тех, что показывают некоторые знатоки препроцессора языка СИ, тут вовсе неуместны. Если обработка необходима, то её следует по возможности также внести в модель в виде отдельных фнукций и только в крайнем случае что-то обрабатывать в голове. Модель по определению проще, чем тест. Сам по себе процесс написания модели существенно облегчает изучение документации на микросхемы, с которыми приходится работать. PS: честно говоря, мне еще не доводилось писать модель микросхемы по datasheet, в котором бы не оказалось какой-нибудь неясности, неточности или неопределенности касающейся timing-ов. (ну, или сейчас такое чувство нахлынуло). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться