Значит так. Прогресс есть, а именно какой:
Собрал систему под Cyclone III: cpu, onchip_mem(128Kb), jtag_uart. И где то на 3,7ms был получена ответ от jtag_uart (Запускалась тестовая программа Hello World). Это радует, но не синмает общей проблемы - а именно необходимости симуляции более сложной системы для проверки своего компонента.
Для этого я как понимаю нужно разобраться как заставить программу загружаться из памяти DDR. Для того проекта проверял - при выполнении mem_init_install файл ddr_sdram.dat обновляется. Но вот почему не работает при симуляции - остается загадкой.

Еще раз проверил, уже с DDR-контроллером. Все работает (см. аттач)!
Скорее всего, Вы просто не дожидаетесь начала вывода в JTAG UART.


Вопрос - какой размер кода у вас получается? Попробуйте его сократить до минимума. Вы какую версию драйверов используете - полную или сокращенную? Использование сокращенной версии позволяет сжать код раз в несколько.
Если Вы используете полную версию драйверов, то для себя еще раз попробуйте оценить, сколько времени будет выполняться startup-код - у Вас весьма изрядный объем памяти, в ней есть сегмент BSS, в стартапе он заполняется нулями - сколько это потребует времени??)

Также проверьте "железную" сторону :
- какая опция симуляции установлена для JTAG_UART? - у меня выдача ASCII
- какая опция калибровки для режима симуляции установлена для контроллера DDR? - у меня Skip Calibration
- на какой тактовой частоте работает ниос? - у меня 100 МГц, ядро Standard.
В моем примере выдача в JTAG_UART начинается примерно на сорок шестой микросекунде от начала моделирования.


ModelSim никакой отсебятины в проект не вносит - что Вы ему подсовываете, то он и показывает.
Так что косяк я бы искал или в Вашем аппаратном проекте, или в Вашем ниосовском коде.

А никто не сталкивался с

Что собственно с ним делать ?

До этого работал с 8.1сп1 - проблем не было вообсче, сейчас переполз на 10.0сп1 в симуляции сопц выскакивает такой варнинг.. На альтерафоруме нашёл упоминание такого варнинга, привязанное к timescale, но у меня она везьде 1ns/1ps..

Размер кода, если оценивать по размеру файла памяти - 234 Kбайта (это е код hello_world, а тестовая программа для перефирийного компонента). Версия драйверов - полная. Поддержка C++ отключена. По поводу аремени оценки - не знаю как оценить, был бы признателен на ссылку на соответствующую литературу.



JTAG_UARY - так же выдача в ASCII.
Частота процессора - 100Мгц.
У DDR стояла калиброка - Quick Calibration.
По поводу времени выдачи - вечра ставил сумуляцию на 30 милесекунд - вывода через jtag не было. Сейчас

Это же можно опупеть от ожидания, пока 234 килобайта кода отсимулируются! Причем львиная доля этого кода, я подозреваю, это стартап.


Какую, нахрен, литературу!
Смотрите размер области BSS, смотрите, сколько времени нужно за запись одного слова в DDR SDRAM, умножайте первое на второе, и получите время заливки BSS нулями.


Это еще плюс десяток миллисекунд.

Урезал код путем использования укророченной версии драйверов, newC lib, отключение C++ до 54Кб. Так же отключил калибровку DDR. Но всё равно через 55ms ответа от jtag_uart не последовало (часов 10 продолжалась симуляция).
Ответ на 45us мне кажется чем-то нереальным.
Еще вопрос - посмотрел дизайн на Cyclone II на котором симулировалось всё. Там размер файла ddr.dat - 257Кб. Но выполнение тестовой программы начиналось на 410us.

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

54 кб - это тоже не мало. У меня объем кода 528 байт. А весь код состоит из




Так весь вопрос в том и есть, а что эта программа делает???


+100 !!!

Переместив в Linker'е код программы в onchip memory и используя скоращенные версии библиотек и драйверов удалось добиться начала работы тестовой программы на 49us. Но если в Linker'е указать всё класть в память ddr (в предыдущем случае в ddr лежал только heap - в драйвере периферийного устройства используется динамическое выделение памяти), то время реакции много увеличивается, и повторяется пролема обсуждаемая выше. Это вероятно связано с большим временем доступа к ddr контроллеру в режиме симуляции.
По поводу выигрыга от такой симуляции - посмотреть как ведет себя компонент во взаимодействии со всей системой, потому что когда я пытаюсь запустить на тестовой плате, на часть тестов я получаю муру, а не результаты.


Абсолютно то же самое, что и тестовая программа, которую я запускаю на Cyclone III дизайне