Nick_K

А чем же так полезен оказался 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 и выдавать на внутренний анализатор.