_Desh_

Да. Иногда наши заказчики пишут в ТТЗ "температура хранения и транспортирования". По ГОСТ РВ 20.57.306 предельная - это фактически температура, при которой изделие находится в выключенном состоянии. Производитель разрешает применить ЭРИ в данном режиме и вместе со своей приемкой сообщил нам об этом официальным письмом. Только нашей приемке это побоку.

Тут я должен извиниться и поправить вводную. Рабочая на компонент равна предельной на компонент и равна минус 60. Рабочая на прибор равна минус 50. Предельная на прибор равна минус 65. Не проходит по цифрам на предельной.

Осталось только изобрести такой элемент питания, который проработает 100 лет, чтобы в нужный момент прибор проснулся, и дело в шляпе.

Спасибо за ответ. Пока такие мысли: 1. Официальная переписка со стандартизаторами это в любом случае надолго. 2. По пункту 10.10 получается, что мы должны были применить в изделии меры защиты, т.е. что-то вроде термостатирования, тогда ничего ни с кем согласовывать не надо. Более того, получается, что мы должны использовать термостатирование вообще во всех изделиях, для которых требования по климатике соответствуют исполнению УХЛ по ГОСТ РВ 20.39.304 (минус 65)!? Вроде такое обычно для защиты от перегрева делают? А если наоборот, то надо делать подогрев? 3. Провести при испытаниях измерения температуры в данной конкретной точке внутри прибора и попробовать доказать, что там нет минус 65? Но там наверняка будет именно минус 65, прибор-то выключен. Интересно мнение сообщества по данному вопросу. Наверняка я не первый, не десятый и даже не сотый разработчик, у кого возникли такие вопросы. У нас что, вся наземная военная электроника с термостатами работает?

Вопрос возник в связи с отказом изделия на периодических испытаниях. Сразу оговорюсь, что отказ произошел не на климатике (испытание на предельную пониженную температуру минус 65 изделие успешно выдержало), а на виброиспытаниях. Но само по себе это не значит, что температура здесь не при чем. ВП подняло все, что можно и обнаружило следующее несоответствие - по ГОСТ РВ 20.39.304 (требования), ГОСТ РВ 20.57.306 (методы контроля) мы обязаны выдерживать изделие при минус 65, а отказавший элемент схемы по ТУ и ОТУ должен обеспечивать рабочую температуру только минус 60, про предельную температуру или температуру при транспортировании в ТУ ни слова. В принципе, производитель по нашему официальному запросу гарантирует работоспособность при минус 65, но военные боятся брать на себя ответственность и ушли в глухой отказ - типа не соответствует и точка. В принципе, подавляющее большинство ЭРИ (по крайней мере из перечня МОП/ЭКБ), что резисторы, что микросхемы, что соединители, обеспечивают по своим ТУ только минус 60. Помогите, пожалуйста, прояснить для себя (ну и впоследствии для нашего ВП), с чего вдруг взялась разница в 5 градусов и как теперь с ней быть? Может быть хотя бы укажете направление, в каких ГОСТах искать обоснование. P.S. Это еще хорошо, что наши военные МОП не читали, и про остальные ЭРИ пока не знают.

Спасибо, помогло. Тогда такой еще вопрос. В самом начале, при добавлении компонентов на плату цепь была подключена ко всем выводам с одинаковым номером. Но потом, в процессе размещения, корректировки схемы и т.п. получилось только одно соединение. Подскажите, пожалуйста, из-за чего такое могло произойти?

Подскажите, пожалуйста, почему Altium не подключает цепь ко всем пинам с одинаковым дезигнатором, а только к одному?

Спасибо, получилось.

Спасибо. Тогда такой вопрос: если 3D-модель сделать вытягиванием из посадочного места, пойдет?

Ситуация приведена на скриншоте. Можно было бы подвинуть микросхемы поближе друг к другу, но тогда Altium считает это ошибкой (Collision). Есть ли правило или настройка, позволящая проигнорировать это нарушение? Можно ли "обрезать" пустые места по углам футпринта?

Большое спасибо! Проблема решена :)

Библиотека altera_mf подключена. Остальные для функциональной симуляции нужны?

Хочу просимулировать конструкцию из пары самописных модулей и мегафункции scfifo. Исходники компилируются без замечаний, но при запуске симуляции Modelsim выдает ошибку: Loading buffer.fifo # ** Error: (vsim-3043) D:/Altera/Quartus91/modelsim_ase/examples/work/buffer/fifo.v(93): Unresolved reference to 'scfifo_component' in scfifo_component.add_ram_output_register. # Region: /buffer_tb/buffer_component/fifo_component # ** Error: (vsim-3043) D:/Altera/Quartus91/modelsim_ase/examples/work/buffer/fifo.v(94): Unresolved reference to 'scfifo_component' in scfifo_component.almost_full_value. # Region: /buffer_tb/buffer_component/fifo_component Таких ошибок - сколько параметров у scfifo. А вот строки, на которые он ругается: scfifo scfifo_component(тут входы/выходы); defparam scfifo_component.add_ram_output_register = "ON", scfifo_component.almost_full_value = 1280, ... ... и так далее. Теряюсь в догадках. Что я делаю не так?

В общем, отписываюсь по поводу своей проблемы - дело оказалось в программаторе USB Blaster. Взял (самодельный!) ByteBlaster II (который через LPT) и все заработало, как и должно. Вот такая вот загогулина.

1) и 2) - генератор рабочий (если верить осциллографу), тактовый вход задан правильно (потому что проект все-таки работает, если загружать его из EPCS или Quartus Programmer'ом). Другой платы нет, а вот другой проект вчера проверял разработчик платы (я ее использую только как отладочную) - все нормально, в смысле если опять же грузить через EPCS, в Eclipse проверить не получится - проект сделан в Nios II IDE 9.0. Если будет время, попробую накатить сервис пак - вдруг поможет...

Eclipse неправильно считывает параметры зашитого в ПЛИС проекта. Для данной платы есть готовый, абсолютно точно рабочий проект. Я точно знаю, что в этом проекте есть процессор Nios, JTAG UART, system ID. Во-первых, не считывается название процессора. Во-вторых, неверно определяется тип ядра (должно быть, как я понял, 1, 2 или 3, а показывает -1). В-третьих, не находит JTAG UART. Последнее - всегда, вне зависимости от проекта, зашитого в плату, пишет, что реальный system ID - 0xffffffff, хотя базовый адрес компонента System ID Peripheral, базовый адрес памяти определяет верно. Если бы такое наблюдалось только с моим проектом, я бы согласился, что дело или в аппаратной части, или в моих кривых руках. Но с чужим проектом все проще - включается питание, проект загружается из EPCS и плата работает. Моего вмешательства в данном случае - один щелчок тумблером и запуск Eclipse. Вывод - проблема именно в Eclipse, возможно в драйвере USB Blaster. Как считаете, поможет ли переустановка или переход на более новую версию?

В общем, решил я попробовать сделать все то же самое, только в Nios II IDE. При попытке прошиться из-под него выдавались такие же ошибки... пока я случайно (после чтения темы http://electronix.ru/forum/index.php?showtopic=103410) не заметил, что после компиляции программы IDE (и, видимо, Eclipse тоже) записывает в папку с аппаратным проектом файл onchip_memory.hex. Когда я после очередной неудачной попытки лез в Quartus, что-нибудь менял и перекомпилировал, он подцеплял этот файл, и генерировал .sof уже с прошивкой Nios. Получается, что после конфигурации ПЛИС через Quartus Programmer в устройство уже была залита рабочая программа! А я, следуя инструкциям Альтеры, пытался прошить .elf в уже работающее устройство. Может, дело в этом? В любом случае, если следовать совету Stewart Little из упомянутой темы и загружать проект только через Quartus Programmer, то все работает. Уважаемые naliwator, Stewart Little, Копейкин, большое спасибо за советы! Правда, теперь непонятно, как дебажить программу без Eclipse или IDE.

Попробовал делать то же самое через Nios II IDE. Во время компиляции программы он кладет файл onchip_memory.hex в папку с проектом аппаратной части. И вот, во время перекомпиляции аппаратной части Quartus выводит предупреждение: Warning: Width of data items in "onchip_memory.hex" is greater than the memory width. Wrapping data items to subsequent addresses. Какая настройка за это отвечает, и как избавиться от этой ошибки? Может быть поэтому при прошивке и возникает ошибка Verify failed between address 0x1000 and 0x148B?

У меня в версии 9.1 такого пункта не было. Создал его вручную, в окне Create a new Make target в поле Target Name прописал mem_init, в поле Make Target прописал mem_init_generate. В поддиректории ..\mem_init создался файл .hex, но файла с расширением .qip нет. Подскажите, пожалуйста, в чем ошибка?

SOPC. Использую Altera Complete Design Suite 9.1.

1. Нажимал много раз, остается так же, как и на скриншоте, т.е. пустота. 2. JTAG Debug используется, подключен одновременно к data_master и instruction_master. 3. Много раз уже проверял, перекомпилировал, перегенерировал, создавал проект заново...

В окне Nios II Elf Section Properties название процессора соответствует файлу .sopcinfo. Тогда почему в окне Run Configurations > Target Connection написано The expected CPU name does not match the selected target CPU name? И почему в поле Processors > Name пусто? В ПЛИС при этом прошит .sof файл с правильной системой. Для той программы, которую я собираюсь прошить, и килобайта достаточно (специально сделал простейшую вещь, чтобы побыстрее). Никаких предупреждений или ошибок при компиляции Eclipse не выдавал, так что, думаю, дело не в этом. Для примеров наверняка нужна отладочная плата? У меня ее нет и не будет. Если получится завтра какой-нибудь готовый проект запустить на доступной мне плате, то попробую. Да, кстати. На той плате, с которой я упражняюсь, стоит EPCS с прошитым в ней другим проектом. Я пытаюсь на лету зашивать в ПЛИС свой .sof файл через JTAG, а затем и .elf, чтобы не трогать старую прошивку. Так ведь и нужно делать?

При заданных 80 МГц в отчете Fmax = 87 MHz, при заданных 64 МГц Fmax = 73 MHz.

При загрузке ELF файла я включил настройки Ignore mismatched system ID, Ignore mismatched timestamp ID. До этого я только симулировал проекты в моделсиме, причем все работало. В железе - да, первая система.

Версия 9.1. Пробовал понизить рабочую частоту до 64 МГц, перегенерировал систему, не помогло. Описание системы прилагается. Уточнил сообщение об ошибке: Verify failed between address 0x1000 and 0x148B. Память onchip_memory_instr находится по адресу 0х1000-0x1FFF. Убрал из программы обращение к JTAG UART, вроде что-то поменялось. Теперь ошибка другая: Downloading 00001000 ( 0%) Downloaded 1KB in 0.0s Verifying 00001000 ( 0%) Verified OK Starting processor at address 0x00001020 /cygdrive/d/Altera/Quartus91/nios2eds/bin/nios2-download: line 595: 2152 Hangup nios2-gdb-server --cable 'USB-Blaster [uSB-0]' --device 1 --instance 0 --sidp N/A --id N/A --timestamp N/A --accept-bad-sysid --go --tcpport none --write-pid /cygdrive/d/Altera/Quartus91/User/Erofeev/simple/software/simple/nios2-download.pid /cygdrive/d/Altera/Quartus91/User/simple/software/simple/simple.elf.srec cpu.html summary.html