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

Димыч

Свой
  • Постов

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

  • Посещение

Сообщения, опубликованные Димыч


  1. По большому счету, достаточно децимального номера для точной классификации изделия.

    У нас название изделий производилось от примитивного ( БПК - блок преобразования координат ) и до ников, типа "Бейсур", "Салгир", "Андога"..

     

    ГОСТ 2.104-68, ГОСТ 2.201-80

    Не ВПК, а противоположная отрасль ;)

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

     

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

    Поэтому для не-гос.проектов сделали свой классификатор, в котором шифруем код проекта. Инжеры же, всенда ещё и дают модулям сокращённый ник с идетнефикатором проекта номером версии, например MDMonitor2.1.

     

     

  2. Затачивалось под Altera Quartus, версия записывается в MIF-файл, который д.б. в проекте. Скрипт и readme в прикреплении.

    С другими вариантами вывода (в константы-параметры и т.п.) тоже можно сделать.

     

     

    version_autogen_mif.zip

  3. 1. Код и все средства разработки находятся на сервере. Это во многом избавляет от человеческого фактора "у него все хорошо, а вот у тебя с ошибками".

     

    2. Для каждого проекта есть только 1 маршрут проектирования, 1 набор значений переменных окружения и 1 комплект скриптов для запуска средств синтеза, симуляции и т.п. Если lint выдает ошибки при анализе RTL, то двигаться дальше и, например, синтезировать или симулировать этот код смысла не имеет. Все согласно диаграмме из статьи.

     

    Всё по уму, да.

    1. То есть программист/разработчик работает на сервере со своей рабочей станции, пользуясь средствами удалённого доступа (RDC, TeamViewer, PcAnyNaher и т.п.)? Если на этом сервере висит несколько пользователей, то как быть с производительностью? И при каком количестве однотипных спецов в команде такой подход выгоден (технически и экономически)?

     

    2. Да, иначе трудно представить. Также (уже пару лет назад) столкнулись с проблемой: разработчик проводил первичный запуск и проверку прошивок/функционала на "своём" локальном наборе скриптов (хотя полностью изжить это не удалось :( ), а тестеры и внедренцы - на другом, лежащем на сервере. И постоянно возникали ситуации, в которых звучала фраза "Ну у меня же всё работает!"

     

    P.S. Витиеватость - зло, по моему убеждению. Хорошо помню день, в году так 2000-м, когда мой коллега ;) посмотрев на моё описание какого-то мелкого модуля на Verilog'е, сказал (очень тактично): "Дмитрий, чтобы написать или понять эту конструкцию, надо быть или семи пядей во лбу или чего-то недопонимать в HDL". Собственно, я до сих пор благодарен за эти слова.

     

  4. См. Verilog linting tool

    Из свободных

    Verilator

     

    Из платных

    Cadence HAL

    Atrenta Spyglass

    Synopsys Leda

     

    Спасибо! Выходит, не там искал..

    Начал с изучения Verilator'а - но пока далеко в этом не продвинулся. Зато набрёл на толстую статью от Эриксона (вложено) про Spyglass и сравнением с Leda. 80 страниц, где на часть моих вопросов сразу есть ответы.

    Немного почитал в других источниках про Spyglass и - заочно - он стал мне интересен, но также будет интересен вопрос цены. Если она будет приемлема, то можно и познакомиться вплотную.

     

    ув. Fat Robot, скажите - у Вас в компании такие средства применяются? И как строится процесс работы с кодом?

     

     

     

    ...

    Вообще, если вы взялись контролировать качество RTL описания ваших дизайнеров, то начните со своего свода правил.

    Не обязательно брать что-то готовое. Мы вот надергали из разных источников и составили свой внутрикорпоротивный свод правил.

    ...

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

     

    очень содержательный ответ, спасибо!

     

    Определённый кодекс правил мы тоже сделали. Но, очевидно, ещё далеко не полный, хотя и пришлось пересмотреть десятка два подобных корпоративных сводов (от Cisco и т.д.). Ситуация усугубляется тем, что HDL программистов в отделе "раз-два и обчёлся" а организовывать их работу приходится человеку, который с FPGA/ASIC никогда не имел дела. По сути уже столкнулись с тем, что написано много "кормящего кода", а процесс "нужно сделать всё, как надо" буксует по многим причинам, в том числе и личностным. Сидеть за спиной у ХДЛ-программиста и контролировать его код - в итоге просто некому.

    Но, возвращаясь к своду правил. Да, действительно, это лишь часть процесса (или маршрута - так вернее). Как сделать так, чтобы разработчик (в попытках сделать всё быстрее) не отходил от них? Опять же у наших коллег "Си-шарпников" для этого есть автоматизированные барьеры, привязанные к Jira (и т.п.), которые просто не дадут зарелизить/за-коммитить проект, если там нарушены заданные правила. Конкретно их инструменты мне использовать не удалось :) Тем не менее, в любом случае чёткий организационный подход необходим.

     

    HDL_code_analysis_of_ASICs_in_mobile_systems.pdf

  5. Доброго времени суток!

     

    В коллективе из нескольких HDL-программистов назревает необходимость реализовать процесс, который принято называть Code Review.

    Для программистов, пишущих на C++, C#, etc., имеются достаточно обширный набор софтовых инструментов, помогающих отделять зёрна от плевел ещё до того, как глаз "ревьювера" упал на монитор с инспектируемым кодом.

    Для HDL (Verilog, например) ничего подобного найти не удалось (по крайней мере, сходу). Выходит, что остаётся использовать лишь определённые организационные правила/механизмы. И релизить прошивки/библиотеки только после прохождения через заданный бизнес-процесс.

     

    Есть ли хороший, зарекомендовавший себя, опыт коллег, присутствующих здесь? Крайне интересно поделиться и обсудить проверенные подходы и решения.

     

    Спасибо!

  6. Интересует привезти плату и получить снимок на диске или USB флэшке. Отдельно готовы заплатить за описание снимка. Хочется предъявить монтажникам ...

     

    Если ещё не нашли - пишите в личку :)

  7. Доброго дня,

     

    буду рад сотрудничеству со специалистом по трассировке ПП.

     

    Необходимо сделать:

     

    трассировка ПП, на которой:

     

    Cyclone V GX

    FX3

    трансивер EQCOLOGIC

    DDR3 (1 чип, 16 бит)

    Питание...

     

    Контроль импеданса и выравнивание - нужны.

     

    Схемы и проект в Альтиуме.

     

    Жду в личке.

     

    с уважением,

    Дмитрий

     

  8. Добрый день,

     

    у кого-либо из коллег есть опыт использования "стандартного" PCI-E WiFi-модуля (что используются в ноутбуках-планшетах) для построения моста WiFi в своих устройствах.

     

    Нужно "прокачивать" достаточно большие объёмы, поэтому существующие мосты с UART или SDIO не подходят.

    В разрабатываемой системе есть ПЛИС с соответствующими ресурсами (высокоскоростной приёмопередатчик, на котором делается физ. уровень PCI-E).

    Вопрос в том, насколько всю поддержку "выше" (что на PC делает драйвер устройства) потянет ПЛИС?

     

    спасибо!

     

    Пример использования:

    ntx-w.jpg

     

  9. Есть две схемы - 8 листов А3 и 1 лист А3. Всё это в Altium Designer.

    Их нужно переделать (перерисовать) в соответствии с требованиями ЕСКД.

    Также скорректировать перечни элементов (типа U15 -> DD15 и т.п.)

     

    Работа разовая, но в перспективе будут повторные аналогичные запросы.

     

    С уважением,

    Дмитрий

     

  10. Для формальных отчётов готовили документацию по ПП на электронных носителях, руководствуюясь ГОСТ 2.123-93. Особых проблем не возникало.

     

    А готовить массу документов на бумаге... Как минимум, неуважительно к экологии нашей планеты.

    Кроме того, наша недостаточно гибкая система стандартизации приводит к тому, что мы на десятилетия отстали от тех же штатов. Небольшая компания Space-X за 10 лет сделала то, к чему мы шли 40 лет, да вот так и не пришли.

     

     

  11. Заказывали печатные платы и монтаж (покупка компонентов по нашему BOM) 6/8-слойных плат (с контролем импеданса) вот здесь (Китай):

     

     

    email: [email protected] (james zhao)

    skype: xingdapcbsales6

     

    Да, такая контора в Китае далеко не одна. Но с этими работали, всё было в сроки.

     

    Кому интересно, могу скинуть видео-фото с их фабрики - поснимал, когда был в Шеньжене.

     

     

  12. Спасибо!

    А вот подумалось, что не так легко изменить в рамках стандартного техпроцесса.

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

  13. Добрый день,

     

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

    Поцесс CMOS 0,6мкм.

     

    Сейчас нам делают прибор с толщиной пассивации 600 нм. По определённым причинам актуально увеличить эту толщину.

     

    спасибо!

  14. Архитектура разрисована.

    USB3.0 (Cypress), Cyclone 5, DDR3, конфиг. EEPROM, PHY 3ГГц, и ещё по мелочам.

    Библиотеку проекта нужно сгенерить полную - с паттернами.

    Среда - Altium Designer. Можно, впрочем, сделать и в OrCAD, потом перегнать в Altium. Но это уже детали.

     

    Плату разводить и микропрограмму писать не нужно.

     

    Бюджет оговорим, но очевидно напрямую зависит от объективно затраченного времени.

     

  15. Хороша ложка к обеду, конечно же :) Но, может быть, будет полезно кому-либо из аудитории:

     

    http://isgcameras.com/support-iq-gige.php

     

    Производитель камер выложил в открытый доступ стандартов GigEVision, GenICam. Так же кое-какой софт и примеры,

     

  16. Доброго дня,

     

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

     

    Спасибо заранее за советы :)

     

  17. .....и единиц выбраны в обатном соответствии с вероятностями их возникновения.

     

    ....

     

    для случая "маркер начала" - данные - кс - "маркер окончания" (без поля длины) получается какая-то неочевидная машина состояний для приема.

     

    1. да :) данные в канале могут быть сэмплами изображения, а могут быть данными прошивки (для режима DFU).

     

    2. поле длины есть - машине проще

     

     

     

    Задача далеко не тривиальная.

     

    Вот вам парочка посредственных 4-х байтовых:

    0xEDE2ED1D

    0xB8B7B848

     

    по крайней мере, определённое количество статей по родственным проблематикам я уже нашёл за сегодняшний вечер. Спасибо!

     

  18. А если синхрослово встретится в теле пакета? Трагедия?

     

    Нет, не трагедия. Весь поток данных парсингу не подвержен. Проверяется ещё стоп-маркер и КС.

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

     

    для этого в потоке синхрослова заменяют какой-нибудь спец. фигней.

     

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

     

    да, например можно применить байт-стаффинг. Но это уже парсинг всего протокола, что на данный момент для программиста(т.е. для программы) на ПК будет слишком ресурсно.

     

    То же можно сказать и о xxx-модеме :)

     

    Но, в любом случае, спасибо за соображения

     

  19. Доброго дня!

     

    Имеется, в общем-то, тривиальная задача:

    подобрать синхрослово для канала передачи данных. Данные передаются кадрами различной длины, не скремблированы и никак не кодированы. Минимальная длина слова - DWORD (4 байта).

     

    Знаком с кодами Баркера/Уиларда, но, может быть, у кого-то есть частный пример под похожую задачу? :)

     

    Заранее спасибо!

     

  20. Написано большей частью верно. Вот только не написано самого основного - про отладку проектов, особенно больших. Посмотрите у меня на сайте, в статьях "Краткий Курс", о том как отлаживать, как подгружать в тестбенч данные из файлов и как данные выводить на монитор...

    И еще. В русском, термина "схематик" - нет! Это жаргон!

    Спасибо за комментарий и подсказку "где копать ещё" :)

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

     

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

     

    с уважением,

    Д.

  21. HDL_vs_SCH.rtf

     

    Всем доброго времени суток!

     

    Вчера, для аргументирования перехода со схемного ввода на HDL (для коллег), набросал небольшой документ. :) - во вложении.

     

    Если есть комментарии - велкам :)

     

     

×
×
  • Создать...