Перейти к содержанию
    

aXe61

Участник
  • Постов

    9
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о aXe61

  • День рождения 16.04.1986

Контакты

  • Сайт
    Array
  • ICQ
    Array
  1. Хех, точно, чтож снимаю шляпу - я не догадался. Вопрос в тему кто-нибудь знает способ отключить в квесте/моделсиме отбрасывание ведущих нулей? Очень мешает когда нужно определить разрядность выводимого значения.
  2. Спасибо большое за помощь. Я почему-то был уверен, что дело не в типах и единица преобразуется в бит, поэтому даже проверять конструкции j+1'b1, j+1'b2 не стал. После совета решил таки попробовать и вуаля - заработало правильно. Если подумать, то действительно одна переменная расширилась до 32 бит, стоило догадаться, что дело в типе. Только вот непонятно почему расширяется только одна переменная, ведь с плюсом их две. Пробовал {j+3,j+2} все равно расширяется только левая... З.Ы.: Спасибо за ссылку, тоже очень полезная информация
  3. Тип переменной j - bit, в SystemVerilog насколько я знаю тип целочисленного слагаемого приводится к типу переменной. К тому же если Вы обратите внимание на конкатенацию {j+1, j, j-1}, то увидите, что нулями дополнился не j+1, а j-1. Я забыл упомянуть, что пробовал сделать конкатенацию {j+1, j} и она сработала правильно: 5857. пробовал, я об этом уже писал: Механизм преобразования типов есть. Надо будет в свободное время поэкспериментировать с ним на эту тему. Сейчас же получилось решить проблему введением трех независимых инкрементируемых переменных. За синтаксис в предпоследнем предложении предыдущего поста прошу прощения :) Пытался количество мыслей на целый абзац свести в одно предложение :))
  4. Использую QuestaSim 6.4c для верификации на SystemVerilog. Для формирования 24-битного данного сделал конкатенацию трех 8-битных, точнее одного, его же +1 и его же +2, и получил совершенно неожиданный результат - вместо 24-битного значение оказалось 48-битным. Компилятор по неизвестной мне причине расширил нулями область между вторым и третьим числом, т.е. сделали {59,58,57} и получили вместо 595857 значение 590000005857. Код выглядит так: bit [7:0] j = 'h57; bit [23:0] CLI_DATA[]; for(int i = 86; i < size_x*size_y; i++ ) begin CLI_DATA[i] = {j+2, j+1, j}; p_sequencer.ovm_report_info(get_type_name(), $psprintf ("CLI_DATA[i] = %0h, i = %0d", CLI_DATA[i], i), OVM_NONE); p_sequencer.ovm_report_info(get_type_name(), $psprintf ("{j+2, j+1, j} = %0h", {j+2, j+1, j}), OVM_NONE); j+=3; end Результат: То, что данные обрезались это понятно, но вот почему они дополнились нулями - вот это вопрос. Решил сначала что компилятор косячит с порядком действий, заключил j+1 и j+2 в скобки - не помогло. Попробовал присвоить результат j+2 другой переменной и делать с ней конкатенацию - то же самое. После попробовал сделать другие варианты конкатенации и увидел интересную особенность при {j, j, j} результат 575757, а при {j+2, j+1} 5900000058, то же самое и при j+3 и более. Решил выйти из ситуации по-другому, раз +2 не работает, сделаем -1. Результат: CLI_DATA = 56, i = 86, {j+1, j, j-1} = 585700000056. В общем и тут не удалось. Попробовал сделать еще один независимый от этого инкремент с полной уверенностью, что это поможет, но проблема не решилась, т.е. трабл не в переменной, а в самой конкатенации... Подскажите, мб я что-то делаю неправильно?
  5. Не получив ответы на свои вопросы, начал искать их в мануалах. Перепробовал все возможные методы оптимизации и дебаг-режимы. Пробовал убирать все ассерты, ничего не помогло. После всего этого решил пойти на крайние меры: оставил от всего тестбенча только подачу данных на DUT. Убрал всё чтение, все мониторы, скорбоард, сохранение каких-либо данных, ассерты, вывод на печать, в общем всё. Осталась голая подача данных на VHDL описание. В результате за то же время теста (420us) получил вместо 3960Мб занятой памяти 3920Мб, то есть всего 1% (!!!) экономии. Причем тут тогда тестбенч? Видимо спасение только в 64-битной квесте под 64-битным Линуксом. Ускорители за тучу американских рублей не предлагать...
  6. Покопался повнимательнее по мануалам и в Questa SV/AFV Reference Manual нашел информацию по уровням оптимизации. Так вот написано, что доступно 4 уровня оптимизации: -O0 | -O1 | -O4 | -O5 -O0 Минимальная оптимизация. Режим для дебага. -О1 "Некоторая оптимизация" (дословно some optimisation). Опциональная. Больше ничего не сказано... догадайтесь то биж сами... -О4 Бо'льшая часть оптимизаций. Это режим по умолчанию, если включена оптимизация. Ну и соответственно максимальная оптимизация -О5. Оптимизирует циклы и отменяет присваивание переменных, если они дальше нигде не используются. О режиме -О3 ничего не нашел, Вы наверное имели в виду -О5? И еще вопрос появился: при memory-profilling-е Вы какой аргумент для +acc используете?
  7. Фифошки написаны с использованием стандартных альтеровских мегафункций dcfifo. # ** Error: (vlog-1902) Option "-O3" is either unknown, requires an argument, or was given with a bad argument. -O4 и -O5 работают нормально, но эффекта не заметил, плотно конечно с секундомером не тестировал, но на глаз эффекта нет... в мануале к квесте не нашел инфы об уровнях оптимизации. Не подскажете где о них подробнее почитать? По поводу профайлера: перед моделированием, точнее в начале моделирования перед стартом скриптов, включил профайлинг памяти. Тест пошел ооочень медленно (чтоб время сэкономить можно было выбрать ключ для профайлера +fileonly=<filename>, но при этом квеста вылетала с интернал эррором), вчера за час до ухода с работы включил, сегодня утром, чтобы посмотреть результаты нажал break. Вместо результатов увидел Questa exiting with code 211. Internal program error. Данный глюк наблюдается в 6.4с (6.5b установили только позавчера и пока только на локальные машины, на серве еще нет). Запустил профайлинг памяти на 6.5b уже у себя и на более простом проекте (составная часть тестируемого мной). Глюк ушел, однако в списке Ranked и Design Units вижу единственное имя занимающее всю память - NoCallStack. С профайлером раньше не работал, так что есть подозрение что что-то делаю не так, хотя вроде все по мануалу... Профайлинг по производительности особой информации мне не дал, в общем лик по-ходу придется выявлять методом, который Вы мне для ассёртов предлагали - закомментил/измерил... Плин, только где взять столько времени...
  8. В первую очередь спасибо всем за ответы. Теперь по-порядку: Кхм, извиняюсь, забыл пометить, Win2003 на сервере Enterprise x64 Edition. А памяти, как я уже говорил 16Гб, вот только квеста-то 32-битная и рушится на 4х Гб Спасибо за совет. Если ничего не поможет установлю под VMWare линуху и там попробую Тестбенч старался оптимизировать по максимуму, когда использую динамические массивы не доверяю все автомату, а чищу память вручную. К сожалению это проблема ко мне отношения не имеет, т.к. я использую не очереди, а динамические массивы. Вот-вот! именно! Ясно, значит займусь поиском лика. Профайлер конечно жутко замедляет моделирование, но похоже другого выхода у меня нет В тестбенче пользуюсь только типом с двумя состояниями bit. DUT написан на VHDL, да и изменения я в него разумеется не могу вносить. Интересно, а поподробнее можно? Использую. Я так понимаю опять же профайлер поможет в нахождении?
  9. Столкнулся с проблемой в QuestaSim (я использую версии 6.4с и 6.5b). Я верифицирую при помощи OVM достаточно большой проект, в составе которого 8 контроллеров МАС и в каждом из них много фифошек. То что моделирование идет достаточно долго конечно плохо, но я готов с этим мириться, но вот есть другая проблема. Через 20 минут тестирования на стационарной машине (Core Duo, 2GB RAM, WinXP 32bit) от нехватки оперативной памяти рушится GUI квесты, то есть в списке процессов моделирование еще идет, но посмотреть чем же там занимается vsim.exe уже не удастся. Происходит это после того, как используемая Квестой оперативка переваливает за 2Гб. На CAD-сервере (16Gb RAM, Win2003 Server) несмотря на мои ожидания, Квеста тоже рушится, но уже при пересечении порога в 4Гб, и этого все еще не достаточно для того чтобы обеспечить достаточный процент проверки проекта. Насколько я понял, это происходит из-за того, что Квеста хранит содержимое всех блоков памяти моделируемого устройства за все моменты времени, при том что, насколько я понимаю, для моделирования достаточно хранить только содержимое в текущий момент. Пробовал перед началом моделирования прописать nolog -all, времянки нет (а собсно чего еще ждать wlf же и есть wave log file, но все же...), а оперативной памяти используется столько же. Перелопатил кучу Квестовских мануалов по этому поводу, но ничего дельного не нашел. Может кто-нибудь сталкивался с подобной проблемой и подскажет как отключить эту баго-фичу? Разумеется если я прав и причина в неэкономном отношении Квесты к оперативной памяти, однако другого предположения о том, куда можно угрохать столько оперативки, у меня нет. Заранее спасибо.
×
×
  • Создать...