topor_topor
-
Постов
535 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные topor_topor
-
-
Hozier я во всём этом новичок, так что я не особо пока понимаю структуру Cadence IC. Что такое дизайн кит? Использовать буду не в коммерческих целях.
А вы цифровым или аналоговым дизайном хотите заниматься?
Для Cadence Encounter достаточно TECH.LEF, CELLS LIB\LEF, CapTbl вот и весб кит....
---
Интересно знать на будущее, что хорошего в этом X-Fab?
-
Здравствуйте!
У Альтеры есть пример ( http://quartushelp.altera.com/14.1/master....rated_clock.htm ) как задать клок, полученный из исходного делением на 2.
# Create a clock and a divide-by-2 generated clock
create_clock -period 10 [get_ports clk]
create_generated_clock -divide_by 2 -source [get_ports clk] -name clkdiv [get_registers clkdiv]
Аргумент о котором вы спрашиваете в команде create_generated_clock означает то место откуда этот клок выходит (его root) - т.е конкретный пин, а не регистр вцелом (можно задать с FF.C а можно с FF.Q)
Вам надо чёто наподобие get_pins (непомню как это в Квартусе но точно есть :))
-
И самое сложное - это спроектировать узел, обрабатывающий сигнал ошибки.
С Вами полностью согласен.
Хочу только добавить, что кроме логико-умозрительного доказательства способности системы противостоять сбоям и отказам, необходимы есчё и убедительные метрики фолт-кавереджа, полученные в соответствующем симуляторе "сбоев".
Только тогда можно утверждать что "вотч дог и троирование" действительно помогло.
-
Как еще увеличить надежность проекта?
Возможно ли сделать какой то монитор целостности загруженной прошивки не применяя внешние схемы?
Еще по поводу реализации резервирования (мажорирования) в пределах ПЛИС... Вручную это реализовать как то муторно и сложновато.
1) Чтобы увеличить надёжность нужно иметь модель отказов.
Вы от чего защищаться будете: механического отказа пина ПЛИС, выхода напряжения питания вне пределов (STA упадёт), ошибок логики, SEU Mitigation ...?
До сих пор я только слышал - "Данных нет, но от всего"
тут начинать надо с внятно-разжовано-дохотчивого ТЗ (DO-254), качественной верификации на всех этапах (в т.ч. симуляций с имитацией SEU итд ), ну и конечно структурной защитой от сбоя (watch dog итд), так и защитой селов ПЛИС (TMR).
Но придумывать защиты не имея модели отказов - нет смысла... ну защитились вы от SEU вероятность которого 10-6, а у вас пин клока отвалится или осцилятор выйдет за пределы и всё....
Вот у Хilinx много про SEU Mitigation Multi-Level SEU Mitigation Solution
2) Про прошивку Built-In Configuration SEU Detection
3) По поводу TMR, у xilinx есть TMRTool но вам его не дадут :)
-
-
Добрый день уважаемые математики.
Задача такая.
Есть безконечная последовательность 0 и 1.
Части последовательности на некоторых участках взвимосвязаны (случайным образом или циклично повторяются) но строго отличны от других участков.
Мы можем анализировать (запомнить) только часть последовательности биты с bit[new] до bit[N]
Задача - предсказать значение бита bit[new].
Разработать алгоритм предсказания.
Найти алгоритм определения минимально требуемой N (анализируя последовательность на лету или хотябы имея несколько записанных "аналогичных" тестовых последовательностей)
Возможно это уже известная задача. Подскажите что почитать по теме.
Сам не математик, прошу пояснять на пальцах как для инженера :)
-
Вот поэтому надо делать так, как Вы говорите, чтобы прикрыть свою ж. - чтобы все, что документировано (100% функционала), было протестировано на соответствие этой документации. А что не документировано - это проблемы тех, кто использовал это изделие в своем изделии.
как тонко сказано "что документировано"
можно ведь записать - "команды ADD, SUB, OR, AND"
а можно и - "команды ADD, SUB, OR, AND и любые их комбинации в т. ч. при возникновении прерываний итд."
и здуру не написать - код кавередж 100%, фанкшинал кавередж FSM 100%, ATPG кавередж 99% итд.
прикрывать ж. - тонкая наука :)
-
Если речь про новые разработки (а это как раз она), то испытания будут производиться на соответствие документации заказчика (или производителя, если он сам себе заказчик), а вот уже стандарты, в каких климатических условиях испытывать, при каких ускорениях, каких прочих воздействиях, какой MTBF, и т.д. - вот это все жестко есть.
То есть, какой там код коверейдж, никого не интересует. Да и слов таких они не знают. А вот функциональное покрытие на соответствие тому, что документировано и при каких условиях документировано - это да, должно быть 100%.
...ОК... хотя... ка-то мелковато....
я считаю что изделие не просто должно сработать в заданных физических условиях но и разрабатываться на каждом шаге правильным способом и расчитываться по правильной методике итд...
ну покажет тест шо оно 175С выдерживает... а какой был при этом функциональный кавередж теста? мож всего 10%...что значит только 10% функционала при 175С рабочее.....
-
Он был вполне однозначно описан в первых же постах...
Кто может внятно расказать какие есть стандарты, чтобы отечественные "заказчики" приняли изделия?
Можно ли сдать цифру без необходимого фанкшинал\код кавереджа, без 100% ATPG кавереджа на производстве, при проектировании несертифицированными тулзами, при отсутствии компилятора своей разработки и т.п
-
А как это связано с "особенностями работы"? Сертификаты выдают по результатам кучи испытаний, на соответствие документации производителя, и прочим нормативным документам, а был ли там какой-то "оригинал", или не было, никого не трогает.
Это вопрос к автору - какие есть сертификаты.
Ну и вопрос целевого рынка заказчика.. ну и насколько далеко собирается продавать это производитель...
Насколько я знаю, у супостатов фиг сертификат получиш на прошивку ПЛИС, если она сделана не сертифицированной тулзой.... Тоже и компиляторов софта касается... Какие отечественные стандарты заказчиков - хз
-
Если этот прибор, готовый, например, летающий и взрывающийся, то никто ни в какой в суд не подаст. Что там предъявить можно? Только, если топология скопирована 1:1. А тут, явно нет. Если же какой-то дядя накапает в атмел, что на заводе №1234 программируют не-атмеловские камни софтом атмела... Ну понятно, куда служба безопасности отправит всех этих атмеловцев, а дядю-доносчика, тем более.
Насчет функционального бага в копии - так как раз, в данном случае, это совершенно не важно. Будет описан в документации как "особенность работы", т.е. фича. Ну и заодно от атмела отмазаться можно - это уже не копия :) :), это, как интел с АМД. Сначала второй у первого систему команд спер, потом первый у второго 64-битную, и ничего.
проклятые супостаты такие тулзы имеют (да хоть Conformal)...
они по топологии транзисторного уровня могу функциональность сверить - т.е. соответствие архитектуре подтвердить
там когда до суда дойдёт - всё есть чё надо
А если летать будет и взрываться...
То есть ли у автора сертификаты DO-256, ну или хоть ASIL...или хоть отечественных эквивалентов есть?
Или теперешним "заказчикам" это пофиг? Тогда обязательно что-то пойдёт не так.....и Будет описан в документации за 100 000$ добытая "особенность работы" :)))
да тут даже не в этом дело - положим произошла невостановимая ошибка памяти при чтении инструкции, что может АВР в такой ситуации сделать: толькоперелогиниться:) перегрузиться и опанькиа сертифицировать _правильная_ контора может что угодно
ну не наю.... если "то что летает" пару секунд без управлен ия может полетать...то лана....
Главное жить километров на 500 подальше от места старта :)
ну если вопрос в корупционной составляющей взаимоотношений с конторой которая унитаз как спейс чип сертифицирует и купит на 100 000 000$...то надо не на этом форуме наверное спрашивать...
-
Было бы интересно понаблюдать суд (тут, в РФ, так как речь-то не про экспорт, явно) между атмелом и нашим ОПК :) :) :)
если ограничить свой рынок только своей квартирой то ваще всё пофиг :) - тайна личной жизни так сказать.
Если кто хочет эту микросхему в прибор поставить и выйти на мировой рынок, то при "стуке" от добрых людей в Атмел - суд и штраф
Если военным - хз. А вдруг в копии функциональный баг какой а автор не сном не духом... копияже, а не своя мысль... А спейс сертификация это не блины печь....
Ябы на месте вояк не взял, ато опять чёто пойдёт не так....
-
Вопрос насколько я понимаю в том, что может получиться ситуация с клонами альтеровской MAX7000S от атмела, когда они были совместимы на уровне прошивок. Закончилось насколько я знаю судами и атмелу настучали по рукам за это. Другими словами, на софте атмела, можно лицензионно чисто программировать только под чипы атмела, если в лицензии не оговорено другое.
Но почему бы атмел и не санировать :)
есть GCC для AVR
-
Ни кто ни чего ни у кого не спер и не купил. Создана модель функционального аналога AVRки. Ручками написана на верилоге, отлажена, верифицирована и реализована на кристалле. Вся документация в свободном доступе.
Смысла придумывать свою архитектуру, среду разработки и прочие мелочевки нет.
...проверяю, доступна ли AVR архитектура для комерческого использования... в том числе создания аналогов...
насколько я знаю, архитектура то обычно открыта, но свои функциональные аналоги нельзя делать...
При наличии такой "копии" внутри прибора и выходе на уржуйский рынок - суд и штраф. Хотя, если рынок только военные и все патентные права нафик то...
-
Приветствую всех заглянувших.
Вот думаем на своем заводе наладить выпуск новых МК - функциональных аналогов AVR, но в керамическом корпусе - для военных, космотавтов, военных космонавтов и иже с ними. Собственно, наладить выпуск не проблема, но хотелось бы что бы изделие пользовалось спросом. Сейчас выпускаются и продаются аналоги ATmega8535 и ATmega128.
Есть соображение взяться за AT90USB или AT90PWM. Также рассматриваются варианты выпуска чего-нибудь из серии Tiny или Xmega.
В общем, хотелось бы выслушать мнения разработчиков. Какой МК будет востребован?
...интересная постановка вопроса...
1) А вы чё RTL AVR купили у Атмела?
Лицензия есть?
2) Если купили RTL - то вот и ответ - выпускать то что есть, но для разных условий эксплуатации... если кому оригинального Атмела мало или цену меньше поставить....
Правда свои бекенд прийдётся делать...
3) Если это "спёртая" IP то тогда то что местные военные и купят, закрыв глаза на патентную чистоту.
Хотя как у вояк сертефицировать "бессознателтьно содранный код" даж не знаю....особенно если сам компилятор и т.д. не контролируеш и не можеш делать...
4) Если ваши возможности вообще безграничны - создайте свою архитектуру, компиляторы под неё ну и мелочёвку (дебагеры, RTL). Это имеет смысл обсудить.
-
И я бы пока не увлекался различными вариантами моделирования. Достаточно поведенческое моделирование по RTL коду и собственно проверка в железе, можну с помощью Signaltap/Chipscope. Это дольше, но пока для вас будет нагляднее. Если код работает логически (в Modelsim все ок), а в Signaltap вы видите проблемы/несоответствия, значит есть какие-то аппаратные/имплементационные/физические косяки. Что бы их моделировать, нужно знать какие они бывают, а лучше всего это понимается на железе в живую. Потратите больше времени (аппаратная отладка все таки), но при этом разберетесь. А уже потом можно пробовать облегчать себе жизнь моделирование пост-синтез, пост-фиттер. Как то так :laughing:
ябы так сказал...
обычно отличие Post-Implementation Timing от железа не наблюдается
-
2Torpeda: Да я пока пытаюсь во всем разобраться, чтоб ожидания совпадали с реальностью, так сказать. А то потом глюки повылазят, задолбаюсь отлаживать.
А режимы эти значат вроде как простую вещь: Behavioral - симуляция на уровне RTL, Post-Synthesis - симуляция на уровне синтезированного проекта, Post-Implementation - симуляция на уровне реализации с учетом особенностей железа. Ну и timing - значит учет задержек распространения сигнала в логике (а в Post-Implementation еще и с учетом задержек в роутинге) По крайней мере я так понимаю.
Но что именно в данной ситуации приводит к разным результатам...
ОК Это всё равно что сказать - Названиями отличаются. А смысл в них какой?
Чем уровень синтезированного проекта (Post-Synthesis) отличается от RTL? Логика в них идентичная описана...
Чем реализация "с учетом особенностей железа" (Post-Implementation) отличается от уровня синтезированного проекта (Post-Synthesis)? Что там за "особенности появились"?
Просто без ответа на эти вопросы дальше пытаться решить проблему "со странными результатами симуляций" не выйдет.....
В чём корень проблемы отличия разных симуляций ответа нет...вы сейчас какие-то синхронизаторы, задержки, else добавляете в надежде, что "неизвестная" проблема самоустраниться...
с таким-же успехом можно и в бубен постучать...
Я вот пока вижу только проблему в интерпретации результатов
-
В Post-Implementation Functional снова все глухо на выходах...
Что не так с моим кодом и как его переделать так, чтобы в любой симуляции он работал правильно?
И что это за выбросы на выходах в Implementation? это артефакт симуляции, или надо ставить дополнительные регистры на выходы? (хотя вроде они там и так стоят...)
Тут скорее вопрос в том, чем отличаются и зачем существуют Behavioral, Post-Synthesis Functional, Post-Synthesis Timing, Post-Implementation Functional и Post-Implementation Timing
Вот вам зачем все 5 понадобились? Только потому что они есть?
-
Я правильно понимаю, что проблема в том, что между регистрами counter[2] и counter[17] слишком много логики, в следствии чего на этом отрезке схемы происходит временная задержка распространения сигналов?
Чтобы правильно понять надо сгенерить правильный тайминг репорт, который и показывает весь путь данных (от тригера источника к тригеру получателю) и клока.
Там всё и видно от чего и почему (толи много гейтов, толи нагрузка линии большая)
Не могу понять что здесь написано:In addition to clock skew due to static differences in the clock latency from the clock source to each clocked register, no clock signal is perfectly periodic, so that the clock period or clock cycle time varies even at a single component, and this variation is known as clock Jitter.
И как объяснить картинку в моем предыдущем посте? Мне кажется она неверна
1) да, жизнь она неидеальна...
Вот вы какие параметры реальных источников клока знаете (что такое скважность, девиация частоты, джитер... и от каких параметров условий эксплуатации оно зависит....)?
2) Skew - это характеристика клокового дерева (что такое это дерево думаю понятно), т.е. разница задержек путей распространения
Она есчё зараза и от PVT (process voltage temperature) зависит...
3) Вопрос знатокам
Как учесть "неидеальности клока" и их зависимость от условий эксплуатации при "правильной" имплементации проекта, а не чтобы "на коленке заработало"?
-
PADI_DEL --- 1.063 36.PAD to 36.PADDI clk
ROUTE 2 1.038 36.PADDI to R25C2C.CLK clk_c
REG_DEL --- 0.404 R25C2C.CLK to R25C2C.Q0 SLICE_0
Короче, усё у полном у порядке!
Похоже.... А SDC ваша тулза не пишет?
---
У квартуса таки не впорядке....
generated_clock с выхода делителя начинает отсчёт с НУЛЕВОЙ source_latency, если он create_clock
Тайминги считает как будто оба на одной частоте.
Если задать как положено - create_generated_clock, то в репорте generated_clock тоже с выхода делителя начинает отсчёт но с НЕНУЛЕВОЙ source_latency
Ну и тайминги считает как один быстрый а второй медленее.
---
Автоматическое распознавание чегото + констрейны по умолчанию = ЗЛО
-
Он должен был туда и derive_clocks записать. Видимо, вопрос опций. А Synplify + Diamond все это делают сами молча и по умолчанию.
Именно как create_generated_clock создаёт с root=CLK, и с такойже частотой как и root ?
Интересно...Quartus вот протупил....
А как оно generated_clock к глобальному клоковому дереву подключает? или не подключает....
-
Вот именно, что про энкаунтер, он тут не причем. Предупреждать надо, что в оффтопик уходим. С этим я спорить не буду, так там и есть. Синопсис DC/ICC/Astro тоже не распознает. И то, там есть set_propagate_clock для этого (кажется, или derive_clocks, плохо помню)
Но мы то говорим про FPGA, а там это беспрекословное правило для всех (известных мне) PAR-тулов. Да и синтезаторы тоже generated clock-и сами вытаскивают и автораспространяют, и квартус, и синплифай.
проверил в квартусе.
Он распознал 2 клока но....
В SDC записал 2 create_clock от CLK пина и соответственно от FF.Q делителя
Это означает что таки квартус лепит асинхронщину ибо... insertion_delay делёного клока начинает отсчёт с FF.Q, а не CLK пина!
Нам-же надо именно generated_clock от FF.Q и create_clock от CLK
-
2) в корне неверно, так как и синтез, и PAR сам видит все сгенерированные клоки, и без доп. SDC-описаний считает их клоками тех же частот, что и генерирующая сторона, но сдвинутых по времени на какое-то значение, определяемое физическими задержками генерации и разводки. И, соответственно, корректирует длины путей между этими клоками, и по сетапам, и по холдам. Дополнительные констрейны нужны только в том случае, если необходимо указать, что сгенерированный клок имеет другую частоту, нежели сторона, его сгенерировавшая.
1) без доп. SDC-описаний тул видит все тригеры висящие на выходе FF.Q generated_clock как unconstrained
Собственно, всё чего нет в SDC - unconstrained
2) Я уже про констрейны для правильного построяния клок-три молчу в этом случае
Таким образом, ничего автоматически не происходит.
PS. Это я правда в Encounter проверил...
Как минимум от входных пинов FPGA тулза автоматически распознаёт клоки и даже назначение на пины предлагает, а вот generated_clock я не уверен.....
опять-же, функция автораспознавания некоторых тулзов не есть общее правило...
-
Где Вы тут нашли асинхронную систему? Сами придумали?
хмм.....
1) этот случай абсолютно тривиальный и синхронный по сути но...
2) автор его сделал на generated_clock и при этом тулзе не описал SDC констрейнами, как результат - получил асинхронную
Как тестировать разработанную электронику и встраиваемое ПО?
в Управление проектами
Опубликовано · Пожаловаться
Интересная тема. Хотелось-бы уточнить и расширить
1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
----
Ну а после всего этого можно поговорить и о том какой и где "тестер" нужен.
На одном этапе нужно доказать что всё спроектировано безглюков и работает, а на другом - что спаянная плата соответствует Э3...
То как описано у автора топика похоже на последнее....
----
Есть и универсальное решение PXI Platform ... если денег не жалко....