Nick_K

Если уже standalone questa, ncsim и xcelium тогда уже проще и выгоднее там же и симулить. Быстрее и качественнее будет. А так для только просмотра - GTKWave. В своё время только его и юзал, вместо колупания в Вивадовском симуляторе (скриптом генерить базу и потом только смотреть)

Увы это немного не то. Это гайд как быстро сделать плату распараллелив работу между отделами. Я в своё время изучал этот мануал - для простого проекта толку 0. О для ТС действительно, укажите реальное время. И из самых простых шагов - исключить ГУЙ. Плюс без оной - можно скриптами задавать перепрошивку с таймерами/флагами, тем самым автоматизировав заливку-тесты

Немного не так. Для формарования внешней тактовой, нужно создать create_generated_clock который будет описывать отношение создаваемого клока к внутренним частотам (например в 2 раза медленнее или 1.3 и т.д.). А дальше - да, задавать задержки относительно выходного пина CK, который указать в виде -reference_pin для input/output дилеев. Что значит все? Только те, которые будут работать с этой частотой. То что будет работать на другой частоте - на своей.

-reference_pin {pin | port} Adds source and network latency of the specified reference pin to the input delay value in propagated mode. A reference pin is a leaf pin in the fanout cone of the clock source of the clock that you specify using the -clock parameter. По сути этот параметр позволяет добавить лейтенси клока, выходящего наружу, к задержке входного пина. Но Ваша трактовка также вполне правильная

А да, точно. Спасибо. Но всё равно ошибка будет значительная... В некоторых диапазонах)

Советую отзнакомится с понятием Time to Digital Converter. Обычного частотного счётя скорее всего будет недостаточно т.к. даже на 200 МГц это погрешность в ~3м Хотя если такой точности достаточно - то пожалуйста, пишите обычный счётчик

Почему же ошибаюсь?) В моём контексте "под контролем ARM'ов" имеется ввиду что если кто хочет - то может использовать и у себя, только нужно поделиться с властителем) А так берите юзайте на здоровье

А Вам если мёд, то сразу ведром))) у помаленьку-почуть. Уже хорошо что Квеста-неМоделсим. Ещё бы Хилые расчехлились на эту тему. Раньше же был у нах симулятор нормальный - чего слили?..

Насколько мне помнится Квеста более рассчитана на поддержду SystemVerilog и его фич. Не то чтобы Моделсимка не "может". Но реально ограничен. ПО крайней мере так было пару годков назад. Вроде Wishbone но это не точно. Точно не AXI, так как эта лютая хрень полностью под контролем у ARM'ов

На самом деле во многом зависит от тула. Есть тулы, которые принимают последнее декларированное значение (оверрайдят), а есть которые будут использовать самое первое. Обычно это определяется опытным путём. В любом случае лучше избегать таких ситуация и придерживаться уникального именования переменных/нетов.

А чем же так полезен оказался ActiveTCL?..

Я не сильно вникал в скрипт, да и с Ква не работал особо, но то что проект называется d44_m, а топ-левел файл build_id немного смущает. Да и при попытке билда почему-то указывается последний, хотя в самом первом скрипте Попробуйте посмотреть в этом направлении.

Я не конкретно к Вашему примеру. Скорее что лет 5 так можно было легко сделать, превратить 10К$ в металлолом. Сейчас конечно и защиты побольше и синтез-имплементация поумнее с проверками разными. Но при некоторой сноровке...

Я скажу больше - есть огромное отличие от SW и HW. При некоторой сноровке, HW может спалить продукт или превратить в кусок пластика, чего в SW не получится при любом усердии. Принципы мышления абсолютно разные, оперируемые понятыя - абсолютно разные, тип разработки тоже разный (по сути это о Вашем вопросе). Да для разработки используются одинаковые инструменты, но на этом сходство и заканчивается. SW не будет писать тестбенч для обычного счётчика, а здесь это ровная тема (особенно если нужен счётчик с пресетом и счётом на -1 значение и т.д.). Это я условно.

Из всех известных мне компаний, только одна-единственная подняла CI/CD для своих проектов. И то только лишь для того, чтобы при любых изменениях-нововведениях быть уверенными, что старые проекты не сваляться. При этом сам производитель занимаеться обновлением прошивок на поставляемых устройствах, а конечные продукты настолько плотно обмазаны тестбенчами, что даже страшно. С другой стороны оно и понятно, ребята делают медицинское оборудование. Там цена ошибки - человеческие жизни. Глобольно же на всех остальных конторах, разработка идёт по принципу "один модуль-один разработчик". Наверху всё может интегрировать системный инженер, отвечающий за проект или тестировщики. Merge-конфликты решает последний комитящий или по принципу поправить минорные нюансы, либо подходит к автору второго конфликта и решают вместе, кто правее. И в заключение ИМХО эффективный менеджмент лучше применять на программистиках. Разработка схем такого не любит, хотя издалека кажется, что занимаются одним и тем же: но это только кажется. Поинтересуйтесь как справляются с такими задачами разработчики PCB, там дляже Гит неприменим по понятным причинам. P.S. Делаем изменения в глобальных ветках (типа backend, dev и т.д.), на определённых этапах мерджим в кучу и пушим в мастер - так получаем ревизию и фриз. Фичи, проверки и т.п. каждый может гадить в своей ветке и оставить только нужное для мерджа в глобальную ветку. P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

set_max_delay delay_value [-from from_list] [-to to_list] // физическая суть - поменять сетап приёмника set_min_delay delay_value [-from from_list] [-to to_list] // физическая суть - поменять холд приёмника Увы задержки Вашего сигнала hs1, придётся вытащить руками после имплементации и настроить вручную hs2.

А можно уточнить, сколько в "попугаях" это Ваше: Если частота, допустим, 100МГц (полный цикл 10 ns), то можно двигать в диапазоне 0-5 ns. Если нужно больше - тогда уже берите отношение по негэджу. Если же частоты в единицах киллогерц - тогда так не получится скорее всего. Так как линии задержки имеют ограничения по количеству буфферов, создающих дилей. Ну и та же тема с единицами пикосекунд - обычно у буфферов задержка порядка десятков пикофекунд + линии связи. З.Ы. Если в указанных диапазонах устраивает, тогда не нужно никаких дополнительных клоков и т.п. Достаточно задать set_net_delay (set_max_delay/set_min_delay) для внутренних и set_input_delay/set_output_delay для внешних сигналов.

Очевидно же - это арифметический сдвиг, для сохранения знакового разряда (заполнять 1-цами или нулями, в зависимости от старшего бита)

По поводу набросок архитектуры и знаний. Есть такая книженцыя для разработчиков от Харрис и Харрис: Digital Design and Computer Architecture: ARM Edition: Harris, Sarah L., Harris, David: 4708364244349: Amazon.com: Books Так вот очень многие разработчики на FPGA даже имея несколько лет опыта разработки, не всегда в силах повторить всё что разжёванно и по полочкам разложенно в этой книге. Буквально. Ну или оно будет наполдоовину рабочим или рабочим но на частоте... киллогерцев. Это при том, что в общем случае, разработка и "повторение" материала книги не выходит за рамки одного кристалла ПЛИС. А если добавить ещё внешние компоненты как DDR, HDD (или даже SD), так люди годами могут заниматься разработкой только интерконнекта к периферии и всё равно не будет получаться (условно -> новый девайс, пиши сначала). И это при том, что в основном всё описано и разжёванно по разным мануалам и даташитам с видосами на Юпупе. А вот делаешь всё как говорят и не выходит... И хоть ты стреляйся. А потом оказывается, что или настройка не такая или синхронизация в PLL не включена. А вам тут прям из коробки давай "Я буду разраборщиком процысоров!!!11РасРасАдын"

Если счётчик считаев вверх и вниз с конфигурацией на лету (сигналом), то обычно это занимает х2 логики. Что часто критично в проектах. Да и не всегда нужен реверс счёта в проекте (чаще не нужен). Иногда есть более важные задачи, чем сидеть перепридумывать, как должен работать обычный счётчик. Это как с пистолетом: он должен стрелять и не играет роли какие пули там заряжены - бронебойные, фугасные или вообще холостые.

Я говорю, что нет смысла, а Вы дальше своё... Из простого ответ на поставленный вопрос: Счёт с нуля и с единицы. Инкремент, декремент. Ресетный, пресетный. Обычный счётчик и Ripple counter. Проходил по таймингам. Минимум логики (50/50 FF к комбинаторике).

Программисты, такие программисты... Нужно взять проц помощнее и памяти побольше, чтобы было где гавнокодить. Оптимизация? - нЭ не слышал... Ассемблер? - штоита? Знает ли автор, что большинство программ для МК влазят в десятки Кб (Киллобит!)? Насколько это по програмистски взять нахрапом - херяк-херяк и в продакшн. В электронике нельзя сесть и начать "программировать" на Верилог за неделю. Нужно понимать конструкции, синтезируемое подмножество, IP. А потом появятся констрейны и STA, которое будет занимать 70-80% разработки, а оставшееся это и есть описание дизайна с использщованием языка Верилог. Как вообще можно не понимая финдаментальных принципов и не поморгав простым светодиодом на самой дешёвой ПЛИС уже рвать на себе тельняшку и кричать "А разработаю свой процессор!"? Может мне кто-то обьяснить, а то я не понимаю этих программистов.

Один простой вопрос: Зачем? Зачем изобретать велосипед? Всё равно под отдельный проект будет создан свой счётчик, который будет удобнее по ряду параметров (и поэтому же Ваш счётчик не подойдёт) Есть огромная масса вариаций и топиков на тем как считать и чем. И в зависимости от нужд будет разная реализация, разрядность и входные-выходные порты. Чисто для себя можете оставить этот вариант и в процессе профессионального роста добоавлять функционал. Но всё равно скоро поймёте, что нельзя сделать мегауниверсальное решение...

И я вставлю своих 5 копеек 1. Возможно, но для этого нужно хитя-бы человека 3 с опытом разработки. Либо один супермультистаночник. Нельзя просто так взять и синтезировать микросхему. Там очень много промежуточных этапов, проверок и т.д. Без опыта и необходимых знаний, Ваша заказанная схема будет скорее всего просто нерабочей с завода. Ну или сгорит при первом включении (или вовсе от статики). Насчёт цены - вопрос спорный. Гугл вроде как делает от бесплатно, до сотен баксов, на "толстых" процессах для круга энтузиастов по 10-15 чипов. 2. Можно. Уже ответили. 3. Для подключения чего-либо, нужно разобраться в протоколе обмена данными с нужным девайсом. По сути это и есть около половины работы разработчика FPGA.

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