ASN

Для OMAP есть SysLink - всё очень подробно документировано.

Alechek Цель ОКР - документация для производства (мелко-, средне- или крупносерийного неважно). Подтверждение требований ТЗ осуществляется испытанием опытных образцов. После корректировки следует изготовление установочной партии, в процессе которого выполняется адаптация изделия к производству (т.н. освоение) на заводе c выпуском дополнительной заводской документации (оплачивается отдельно). Серийное изделие не требует отладки. Возможно только настройка (и то, как правило, атоматизированная). Цель государства - не мешать работать! Не хочешь покупать дешевые изделия без техподдержки - не покупай. Это дело потребителей, государству сюда лезть нечего. САПР Altium (и однотипные от Mentor, Candence) в разы превосходит PCAD по возможностям и повышает качество изделий, позволяя сосредоточиться на разработке, а не на оформлении "по ГОСТ". Бытовой техникой, сделанной "не по ГОСТ" все прилавки завалены. Что-то не видно чтобы сделанную "по ГОСТ" аппаратуру массовый потребитель (включая западного) "с руками отрывал". Люди и время сделали свой выбор: нужен нормоконтроль (бессмысленный "вахтёр") или не нужен (и "по САПРу" сойдёт). А про ремонтопригодность мне нормоконтроллёр рассказывал :)! Про по всей видимости, он плохо защищен. Там всё нормально. Обычный брак комплектации. Включать в цикл самотестирования - удорожать оборудование.

Alechek Именно это и имелось в виду, что изделие простое: один человек в состоянии разобраться и устранить неисправность. А если в установке "подгорел" вывод FPGA, на которой реализован системный контроллер с кучей узлов ЦОС? И "подгорел" только на вход. Изделие не обеспечивает заданных характеристик, причём только в некоторых режимах. Как это выяснить без специального оборудования и тестовых образов? Конечной целью ОКР является разработка документации для изготовления: gerber и сборочный чертёж на плату, инструкция по настройке (+"прошивки"), ведомость покупных, спецификация, РЭ и ТУ. Этого достаточно для изготовления. Всё остальное стоит дополнительных денег. В том числе красивая схема "по ГОСТ", ремонтная документация и описание исходных кодов. Эти деньги закладываются в стоимость изделия. И если есть два однотипных изделия с документацией "по ГОСТ" и без с разницей в цене в 2 раза, то купят что дешевле. А потом заставят ремонтников сопровождать. Мне важно сделать грамотную схему с которой мне с ребятами будет удобней работать. И вместо "шины-кишки" по всем листам "по ГОСТ" разбить на законченные функциональные блоки-листы с удобной навигацией, пояснительными надписями и прочей дополнительной информацией. Не видел ни одного нормоконтроллёра которого это устраивало: "не по ГОСТ" и точка. У нас официально купленный Altium стали активно внедрять только после того, как мы инициативно сделали на нём изделие. До этого больше года решали "глобальный" вопрос: вот в PCAD многолистовая схема - это один файл, а в Altium - несколько. Что с этим делать? Как хранить в PDM? Так что "оборванные связи" на листе это ещё мелкая проблема. IMHO, даже думать о ней не стоит: САПР не может и всё.

Укушенный воблой В том-то и дело, что допускается, а не рекомендуется. Речь идёт о схемах электрических принципиальных на плату (ячейку, узел), а не на прибор (изделие). Много Вы видели многолистовых схем по ЕСКД, где на первом листе есть таблицы с указанием списка позиционных элементов на листах (не перечень), диаграммы с разделением листов по функциональному назначению и прочее? У западных производителей видел, удобно. Более того, в ГОСТ 2.701 п.5.7.1 указано, что "перечень элементов рекомендуется получать из неё в виде отчёта". Таким образом, Э3 в виде электронного документа должна содержать всю необходимую информацию для трассировки, монтажа и т.д. включения элементов из неё в PDM (типа Vault). Изделие, ремонтируемое в "поле", либо очень простое, либо ремонтируется заменой блоков (узлов, плат). В "поле" BGA на 1296 выводов не перепаяешь. По крайней мере, в подавляющее большинство изделий, которое встречал, имели указание, что ремонт производится на заводе-изготовителе. Уже указывал, что для ремонта существуют специальные документы. Если таких документов нет, то и нечего ремонтнику с более низкой квалификацией лезь в аппаратуру: у нас плату делает команда из нескольких схемотехников, FPGA-дизайнеров, прикладных и системных программистов. Как работает плата один человек просто физически не знает. Повторюсь, рисование "стрелок по ГОСТ" удорожает стоимость разработки и не повышает качество.

Alechek Для ремонта есть ГОСТ 2.601-2013 (Эксплуатационные документы), ГОСТ 2.602-2013 (Ремонтные документы) и ГОСТ 2.605-68 (Плакаты учебно-технические). В ГОСТе уже есть понятия "электронные документы" (на вскидку): - ГОСТ 2.051-2013 Электронные документы; - ГОСТ 2.052-2015 Электронная модель изделия. Общие положения; - ГОСТ 2.054-2013 Электронная структура изделия; - ГОСТ 2.055-2014 Электронная спецификация; - ГОСТ 2.056-2014 Электронная модель детали; - ГОСТ 2.057-2014 Электронная модель сборочной единицы; - ГОСТ 2.058-2016 Правила выполнения реквизитной части электронных конструкторских документов; И много чего другого. То есть бумажное КД уходит в прошлое. И это правильно: поддержание структуры с бумажной КД очень дорого. И, бессмысленно: уже давно проще открыть схему на ПЭВМ (или распечатать необходимые листы), чем идти к ОТД. Рисовать "стрелочки" для того, чтобы "По ГОСТ" - это бессмысленная трата ресурсов (времени и денег). Большинство изделий (схем) не ремонтируются "в поле". Как правило, схему видят (и понимают как работает) от силы 3-4 человека за всё время жизни изделия. Кстати, размещать на схеме дополнительную информацию в виде пояснительных диаграмм (осциллограммы, взаимосвязи листов) и прочее нельзя. По крайней мере, мне не попадались нормоконтроллёры, которые это пропускали.

ConstHw Дело в том, IMHO, что нет никакой проблемы языка Verilog. Принцип простой: если есть возможность получить неожиданные проблемы, то может имеет смысл просто не использовать некоторые особенности языка? В данном случае, просто следует всегда указывать размерность переменной (сигнала). И лучше это делать явно как параметр модуля: проще, понятней. Про тесты упоминалось в контексте уменьшения количества ошибок при интеграции и сокращения времени комплексной отладки. А вот пример про С/С++ малопонятный: совершенно разные языки, совершенно разные подходы к проектированию. Дело не в unit test, а в проектировании "сверху вниз". Алгоритмы на ЯВУ пишутся в разы быстрее, чем на HDL. Подход с тестированием при переходе с одного уровня иерархии к следующему просто экономит время.

Inanity IMHO, чтобы уменьшить вероятность появления таких ошибок (некорректной реализации) следует использовать testbench на всех этапах: Модель на С - тестовый стенд; RTL - тестовый стенд; Synthesis - тестовый стенд; PAR - тестовый стенд; "железо" - тестовый стенд; Конечно, трудоёмкость возрастает и время требуется. Но и итоге получаем экономию на поиске непонятных глюков. Кстати, соглашусь с уважаемым des00 - нельзя просто игнорировать warning. В моей практике было несколько неприятных ошибок, которые были результатом того, что некоторые warning просто отключили (!): формально результат компиляции нареканий не вызывает, но в "железе" появляются редкие непонятные глюки. Искали долго, пока не обратили внимание на факт отключения.

lennen Чем не многомерное созвездие? И Уолша используют в стандартах. Про многомерный базис. Вот есть созвездие 8PSK. Приняли точку (Im, Re) и получили вероятности (b0,b1,b2). Декодировали с "мягким" выходом, закодировали обратно и получили восстановленную точку (b'0, b'1, b'2). Куда её поместить на плоскость созвездия?

Dmitriyspb В том и дело, что zynq - это процессорная система у которой есть ПЛИС: можно реализовать алгоритм сначала программно, а затем аппаратно. И сравнить трудоёмкость и эффективность. Прелесть Zynq в том, что интерфейсы с СнК (шины) уже выведены в ПЛИС и не надо "колхозить" собственный механизм обмена с ЦП. А систему с ПЛИС без ЦП "поднимать", IMHO, сложнее. Да и какой смысл "осваивать" CPLD? Вопрос максимум одной недели. Если уж ТС реального хочет "прочувствовать", что такое современная ПЛИС, то, IMHO, лучше использовать удобный (хоть, несомненно, сложный) инструмент. Р.S. По моим наблюдения тех, кто начинает осваивать ПЛИС отталкивает именно то, что о момента начала "погружения" до момента результата "в железе" проходит много времени. Поэтому и рекомендую Zynq.

Beoplyer Очень полно ответил уважаемый agregat. Если есть действительно большое желание применить ПЛИС, то посмотрите в сторону Zynq: его можно использовать на первых порах просто как обычный СнК, добавляя по мере необходимости блоки на логике. А там и узнаете, чем ПЛИС хороша (и в чем hell) :).

Флюктуация ваккума Это далеко не одно и тоже. Объём программы как в исходных кодах, так и в размере битового образа - не показатель сложности ПО. А разработка на ассемблере - не показатель профессионализма. Правильный код, генерируемый компилятором с С++ для современного RISC ОМЭВМ (ARM, MIPS), практически не уступает "ручному" кодированию на ассемблере. Более того, программа на ЯВУ, написанная профессионалом, которая эффективно использует аппаратные ресурсы (DMA, кеши), с активным использованием виртуальных и callback функций будет и меньше и быстрее (зачастую в разы или даже порядки), чем та лапша, который "навалял" посредственный "крутой программист" на ассемблере. Повидал много такого. Разработка рабочего проекта на FPGA, IMHO, ближе к проектированию АРХИТЕКТУРЫ системы "в целом", требует чёткого понимания таких базовых вещей как латентность, пропускная способность, конвейер, понимания как реализуется умножение и сколько тактов требуется для записи и чтения по системной шине. И чёткого понимания ПАРАЛЛЕЛИЗМА вычислительных процессов. Много ли "программистов MCU на ассемблере" задумываются о том, сколько занимает обращение по APB по чтению? И, главное, насколько это помогает им зарабатывать деньги? А вот FPGA-дизайнер знает и контролирует это. Иначе просто не будет работать. Кстати, это тоже повышает надёжность системы. Но и удорожает прикладную систему.

Флюктуация ваккума Противоречия нет. Повторюсь: в случае с FPGA физически МЕНЬШЕ независимых переходов из состояния в состояние, чем у МПС. Поэтому вероятность критического сбоя ниже при ОДИНАКОВОЙ технологии. Разработка КАЧЕСТВЕННОЙ структуры FPGA на HDL не сложнее и не проще, чем разработка КАЧЕСТВЕННОГО программного автомата для МПС. Просто в FPGA "накуячить по-быстрому" не получиться - требуется более кропотливая работа и ПОНИМАНИЕ как работает система в целом. И дело не в том, что проектирование FPGA процесс существенно более сложный и нетривиальный, требующий более высокой квалификации и специальных более сложных способов тестирования. Дело в том, что для FPGA, как правило, "либо работает как надо, либо не работает вообще", а с МПС можно "схалявить" - "в принципе работает, но иногда чуть не так". Поэтому и дешевле. И это хорошо.

Флюктуация ваккума По надёжности и устойчивости к сбоям. IMHO, в первом приближении, любая МПС - это конечный автомат, где количество состояний (в предельном случае) определяется объёмом программы. То есть, если у ПЗУ на 2 Мбайта, а размер команды 16-бит, то имеем 1 миллион состояний. Задача - проанализировать вероятность перехода из допустимого состояния в недопустимое. Вы можете предложить методику ГАРАНТИРУЮЩУЮ отсутствие (то есть пренебрежительно низкую вероятность) в МПС такой возможности? А вот с ПЛИС это проще, потому, там количество переходов просто меньше физически: сбой в одной ячейки FPGA повлияет на строго заданное количество других. Просто потому, что не все ячейки имеют связи друг с другом (в отличии от ПЗУ). Не стоит забывать и про аппаратное дублирование. Про ...в "среднем по больнице" уровень русских FPGA-программистов - это фактически уровень студентов... предлагаю внимательно почитать форум Xilinx и Altera. И сравнить уровень вопросов с местной специализированной веткой. Для объективности оценки ДИЗАЙНЕРОВ. Грамотное применение FPGA требует от разработчика гораздо больше знаний, чем "валять код на плюсах". Поэтому и применять FPGA надо там, где это УДОБНО (просится). Потому, что оплата FPGA-дизайнера стоит ДОРОЖЕ, чем среднего программиста.

jcxz Как-то работали с профессиональным программистом: много серийных изделий (в том числе и для европейских заказчиков). Так он для DSP (TMS320C55x), где внутренняя память - ценный ресурс, выделял под стек половину внутренней памяти и размещал там просто огромные массивы и структуры. Меня это удивило и поинтересовался зачем так делают? Оказалось, что стек используется как куча с автоматическим освобождением. Типа стековой машины. Для данных, которым нужен быстрый доступ, оказалось очень удобно - нет лишнего копирования из внешней памяти во внутреннюю. Правда, структуры были достаточно "хитрые" - с выравниванием по границе массивов.

aabmail А скорость передачи высокая? Может лучше обойтись без сопровождающей тактовой вообще? Использовать что-то типа NRZI.