[yes 8]

в книжке VMM

Transaction-Level Interfaces

Completion and Response Models

 

примеры на мой взгляд бессмысленны и незакончены - к чему это, зачем - ХЗ и так всюду

 

this.in_chan.peek(tr);

tr.notify.indicate(vmm_data::STARTED);

...

tr.notify.indicate(vmm_data::ENDED, ...);

this.in_chan.get(tr);

 

полного примера более-менее осмысленного тестбенча (не FIFO и не APB, а хотя бы AHB или какого-либо недетерменированного протокола) я так и не нашел.

 

------------

 

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

но хотелось бы понять, как это делать объектами VMM

[des00 25]

в книжке VMM

Transaction-Level Interfaces

Completion and Response Models

 

примеры на мой взгляд бессмысленны и незакончены - к чему это, зачем - ХЗ и так всюду

 

this.in_chan.peek(tr);

tr.notify.indicate(vmm_data::STARTED);

...

tr.notify.indicate(vmm_data::ENDED, ...);

this.in_chan.get(tr);

 

полного примера более-менее осмысленного тестбенча (не FIFO и не APB, а хотя бы AHB или какого-либо недетерменированного протокола) я так и не нашел.

 

------------

 

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

но хотелось бы понять, как это делать объектами VMM

 

хмм, не могу понять что именно вам не понятно.

 

посмотрите на каналы в OVM User Guide, там достаточно понятно описано. Квалификаторы STARTED/ENDED ставятся для индикации состояния транзакции, это нужно для разбора "завалов" если что то не работает. Если они вам не нужны, их можно не ставить. в OVM это ставиться автоматом при вызове соответствующих макросов.

[SM 0]

каналы в OVM User Guide

OVM != VMM

[des00 25]

OVM != VMM

 

это я в курсе, но подходы к организации и синхронизации каналов те же самые.

[yes 8]

это я в курсе, но подходы к организации и синхронизации каналов те же самые.

 

подходы всюду одинаковые, интересно как раз какие функции/мемберы надо использовать

ковырять код или доксигеновскую доку http://www.intelligentdv.com/documents/dox....0.1/index.html нет желания и времени

[des00 25]

подходы всюду одинаковые, интересно как раз какие функции/мемберы надо использовать

ковырять код или доксигеновскую доку http://www.intelligentdv.com/documents/dox....0.1/index.html нет желания и времени

 

зачем там то, принципы описаны в OVM_UserGuide -> Connecting the Driver and Sequencer -> Basic Sequencer and Driver Interaction. Генератор должен родить транзакцию, поставить ее в канал, приемник взять транзакцию и во время ее прибить. Как это сделать именно в VMM вы написали, в OVM это делается автоматом. Потому мне и не понятен ваш вопрос %)

[yes 8]

зачем там то, принципы описаны в OVM_UserGuide -> Connecting the Driver and Sequencer -> Basic Sequencer and Driver Interaction. Генератор должен родить транзакцию, поставить ее в канал, приемник взять транзакцию и во время ее прибить. Как это сделать именно в VMM вы написали, в OVM это делается автоматом. Потому мне и не понятен ваш вопрос %)

 

самое примитивное усложнение - шина с разделенным командным циклом и циклом передачи данных, при этом транзактор должен брать две транзакции за раз (одновременно)

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

 

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

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

в книжке по VMM-у есть целая глава посвященная каналам, но мне не понятно как на практике эти абстрактные методологические рассуждения и "рулесы" применять

[des00 25]

самое примитивное усложнение - шина с разделенным командным циклом и циклом передачи данных, при этом транзактор должен брать две транзакции за раз (одновременно)

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

 

зачем две то ? ИМХО это потенциальный геморой. Между драйвером и генератором есть транзакции записи/чтения, Все. Все вопросы шинной архитектуры (подозреваю AXI однако) должны решаться на уровне драйвера!!! Что мешает завести в драйвере очереди/индексируемые очереди и развалить его на нужное количество фаз. Подобное я делал, никаких проблем %)

 

 

в книжке по VMM-у есть целая глава посвященная каналам, но мне не понятно как на практике эти абстрактные методологические рассуждения и "рулесы" применять

 

тут я подсказать не могу, не читал

[yes 8]

зачем две то ? ИМХО это потенциальный геморой. Между драйвером и генератором есть транзакции записи/чтения, Все. Все вопросы шинной архитектуры (подозреваю AXI однако) должны решаться на уровне драйвера!!! Что мешает завести в драйвере очереди/индексируемые очереди и развалить его на нужное количество фаз. Подобное я делал, никаких проблем %)

 

в общем случае N :)

 

есть просто транзакция - чтение или запись, определено в ней самой

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

тут пока порядок не нарушается, то есть никакого аут-оф-ордер

 

собственно вопрос в синронизации (может atomic_gen я выбрал не правильно, хотя вроде без разницы) этого входного канала и механизма передачи(проверки) результата работы dut-a

 

наверно я перечитался книжкой по VMM-у - нужно отдохнуть

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

 

вобщем буду пока считать, что с VMM не вышло, буду пользовать SV mailbox-ы.

да и vmm_log мне не понравился