GAYVER

делаю пример по описанию. ввиду полного отсутствия понимания принципов работы сдк, софт часть выполнялась в режиме обезьяны. платы для отладки нет. после всех манипуляций надо запустить моделирование. собственно вопрос - как правильно портировать назад в виваду все для этого необходимое? как я понимаю это должен быть элф-файл, в котором будет лежать все что нужно, включая содержимое внутренней памяти (подключенной по ЛМВ). сейчас при запуске моделирования из вивады, в памяти микроблейза лежит одна константа по нулевому адресу. сам микроблейз шарашит по кругу чтение инструкций по адресам 0-4-8. поиском по папке проекта находится несколкьо элф-файлов . из папки .sdk: Section Data: .vectors.reset [00000000] 00 00 00 b0 50 00 08 b8 .vectors.sw_exception [00000000] 00 00 00 b0 00 0e 08 b8 .vectors.interrupt [00000000] 00 00 00 b0 ac 11 08 b8 .vectors.hw_exception [00000000] 00 00 00 b0 7c 03 08 b8 .text [00000000] 00 00 00 b0 60 23 a0 31 00 00 00 b0 b8 20 40 30 [00000010] 00 00 00 b0 78 2f 20 30 00 00 00 b0 60 02 f4 b9 [00000020] 00 00 00 80 00 00 00 b0 6c 04 f4 b9 00 00 a3 30 [00000030] 00 00 00 b8 00 00 00 b0 60 23 a0 30 00 00 00 b0 .init [00000000] f0 ff 21 30 00 08 e0 d9 ff ff 60 31 02 c8 0b 94 [00000010] 00 00 60 31 00 c8 0b 94 ff ff 00 b0 50 e6 f4 b9 [00000020] 00 00 00 80 ff ff 00 b0 d0 f1 f4 b9 00 00 00 80 [00000030] 00 08 e0 c9 08 00 0f b6 10 00 21 30 .fini [00000000] f0 ff 21 30 00 08 e0 d9 ff ff 00 b0 44 e5 f4 b9 [00000010] 00 00 00 80 00 08 e0 c9 08 00 0f b6 10 00 21 30 .ctors [00000000] ff ff ff ff 00 00 00 00 .dtors [00000000] ff ff ff ff 00 00 00 00 .rodata [00000000] 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 21 21 0a [00000010] 0d 00 00 00 78 67 70 69 6f 2e 63 00 78 67 70 69 [00000020] 6f 5f 73 69 6e 69 74 2e 63 00 00 00 30 31 32 33 [00000030] 34 35 36 37 38 39 41 42 43 44 45 46 00 00 00 00 .data [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000020] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .sdata .sbss .debug_frame [00000000] 0c 00 00 00 ff ff ff ff 03 00 01 7f 0f 0c 01 00 [00000010] 24 00 00 00 00 00 00 00 5c 0e 00 00 24 01 00 00 [00000020] 04 04 00 00 00 0e 28 04 08 00 00 00 8f 28 93 04 [00000030] 04 04 00 00 00 0d 13 00 .debug_info [00000000] 48 0a 00 00 04 00 00 00 00 00 04 01 54 aa 00 00 [00000010] 0c 58 8e 00 00 79 76 00 00 00 00 00 00 00 00 00 [00000020] 00 00 00 00 00 00 00 00 00 02 01 06 ce c0 00 00 [00000030] 02 01 08 87 1d 00 00 02 02 05 76 53 00 00 02 02 .debug_abbrev [00000000] 01 11 01 25 0e 13 0b 03 0e 1b 0e 55 17 11 01 10 [00000010] 17 99 42 17 00 00 02 24 00 0b 0b 3e 0b 03 0e 00 [00000020] 00 03 16 00 03 0e 3a 0b 3b 0b 39 0b 49 13 00 00 [00000030] 04 24 00 0b 0b 3e 0b 03 08 00 00 05 16 00 03 08 .debug_aranges [00000000] 1c 00 00 00 02 00 00 00 00 00 04 00 00 00 00 00 [00000010] 5c 0e 00 00 24 01 00 00 00 00 00 00 00 00 00 00 [00000020] 1c 00 00 00 02 00 4c 0a 00 00 04 00 00 00 00 00 [00000030] 80 03 00 00 a8 00 00 00 00 00 00 00 00 00 00 00 .debug_ranges [00000000] 5c 0e 00 00 80 0f 00 00 00 00 00 00 00 00 00 00 .debug_macro [00000000] 04 00 02 00 00 00 00 07 c5 01 00 00 03 00 01 03 [00000010] 01 0c 07 4d 08 00 00 04 03 02 0b 05 7a 5c 2c 00 [00000020] 00 03 82 01 04 05 36 66 81 00 00 03 3c 0d 03 09 [00000030] 0e 05 0a 0f 62 00 00 03 0c 02 05 06 2e ad 00 00 .debug_line [00000000] 5b 04 00 00 04 00 d3 03 00 00 01 01 01 f6 f2 0d [00000010] 00 01 01 01 01 00 00 00 01 00 00 01 2e 2e 2f 2e [00000020] 2e 2f 6d 69 63 72 6f 62 6c 61 7a 65 5f 6c 65 73 [00000030] 73 6f 6e 5f 31 5f 62 73 70 2f 6d 69 63 72 6f 62 .debug_str [00000000] 5f 6f 6e 5f 65 78 69 74 5f 61 72 67 73 5f 70 74 [00000010] 72 00 58 50 41 52 5f 4d 49 43 52 4f 42 4c 41 5a [00000020] 45 5f 4d 5f 41 58 49 5f 44 43 5f 45 58 43 4c 55 [00000030] 53 49 56 45 5f 41 43 43 45 53 53 20 30 00 49 6e .symtab [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 01 00 [00000020] 00 00 00 00 08 00 00 00 00 00 00 00 03 00 02 00 [00000030] 00 00 00 00 10 00 00 00 00 00 00 00 03 00 03 00 .strtab [00000000] 00 64 3a 2f 77 6f 72 6b 2f 73 6f 66 74 2f 76 69 [00000010] 76 61 64 6f 2f 32 30 31 39 2e 31 2f 73 64 6b 2f [00000020] 32 30 31 39 2e 31 2f 67 6e 75 2f 6d 69 63 72 6f [00000030] 62 6c 61 7a 65 2f 6e 74 2f 62 69 6e 2f 2e 2e 2f .shstrtab [00000000] 00 2e 73 79 6d 74 61 62 00 2e 73 74 72 74 61 62 [00000010] 00 2e 73 68 73 74 72 74 61 62 00 2e 76 65 63 74 [00000020] 6f 72 73 2e 72 65 73 65 74 00 2e 76 65 63 74 6f [00000030] 72 73 2e 73 77 5f 65 78 63 65 70 74 69 6f 6e 00 Segment Data: Segment # 0 [00000000] 00 00 00 b0 50 00 08 b8 00 00 00 b0 00 0e 08 b8 [00000010] 00 00 00 b0 ac 11 08 b8 00 00 00 00 00 00 00 00 [00000020] 00 00 00 b0 7c 03 08 b8 Segment # 1 [00000000] 00 00 00 b0 60 23 a0 31 00 00 00 b0 b8 20 40 30 [00000010] 00 00 00 b0 78 2f 20 30 00 00 00 b0 60 02 f4 b9 [00000020] 00 00 00 80 00 00 00 b0 6c 04 f4 b9 00 00 a3 30 [00000030] 00 00 00 b8 00 00 00 b0 60 23 a0 30 00 00 00 b0 Segment # 2 [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000020] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 из папки .src: Section Data: .boot [00000000] 00 00 00 b8 .text .data .shstrtab [00000000] 00 2e 73 79 6d 74 61 62 00 2e 73 74 72 74 61 62 [00000010] 00 2e 73 68 73 74 72 74 61 62 00 2e 62 6f 6f 74 [00000020] 00 2e 74 65 78 74 00 2e 64 61 74 61 00 2e 62 73 [00000030] 73 00 .symtab [00000000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00000010] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 01 00 [00000020] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 02 00 [00000030] 00 00 00 00 00 00 00 00 00 00 00 00 03 00 03 00 .strtab [00000000] 00 5f 62 6f 6f 74 00 Segment Data: Segment # 0 Segment # 1 Segment # 2 [00000000] 00 00 00 b8 собственно при моделировании по нулевому адресу в памяти лежит только значение "b8000000", остальное нули и как я понимаю - подсосался не тот файл... зы есть ли в природе русскоязычные обучалки по СДК? сейчас стоит вопрос по последовательности действий при дебаге без платы, и интересно посмотреть на сишный код, сконвертированный в команды микроблейза

1 - в каком конкретно разделе обозначена связь RLAST-RVALID-RREADY? конкретно по тактам - "этот сигнал может выставляться раньше/позже этого сигнала" или "должны выставляться одновременно", итд. я не нашел. 2 - оба модуля - ИП ядра хилинха, что исключает какую-либо МОЮ вольную трактовку

Поэтому при соединении интерконнекта и мастеров-слэйвов, соответствующие входы/выходы этого канала были заземлены. Неопределенку рожает сам интерконнект. От транзакции к транзакции в пределах одного слэйва, при этом, он переходит. Влиять на арбитраж, повторюсь, BRESP не должен был. И пока меня эта неопределенка не касалась, и все функционировало как и должно было - я в нее не влазил :). Сейчас буду ковырять - кто ее там делает... зы таки да, тупанул - надо было сразу делать все как надо, а не постепенно наращивая функционал, по мере отладки предыдущего ззы еще было замечено интересное в связке интерконнект/конвертер протокола акси лайт (хилинховые корки). В качестве слэйва для интерконнекта выступает конвертер, за которым стоит конЕчный слэйв. В последней передаче по чтению, конвертер выставляет сначала RLAST, и на следующем такте данные и RVALID. А интерконнект заканчивает передачу увидев RLAST. И то ли интерконнект не ловит связку RLAST=1 && RVALID=1, то ли конвертер не одновременно их выставляет... Кто некорректно работает - не понятно. В спецификации не вспомню явных требований на этот счет

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

Слэйвы не отвечают по BRESP. его дергает только интерконнект при ошибке адресации. Система действительно не полный round-robin. Второй мастер с приоритетом 1, первый с нулевым (участвующем в round-robin). Но обращение везде идет от первого мастера. Второй никак не задействован. Транзакции, по идее, завершаются корректно - несколько подряд к одному слэйву вполне себе проходят. Причем чтение-запись - что записали, то и проверочно вычитали надо будет действительно попробовать убрать готовность на мастере во время чтения

не знаю как понятней объяснить :). 1 - РРЭДИ на выходе корки не реагирует на изменение РРЭДИ на ее входе. И на скрине это видно - на мастере он вздергивается в 1 только на момент чтения, слэйву же выходит все время единица. За исключением непонятного перепада в ноль при первом обращении... 2 - залипает, скорее всего, арбитр адресов. Потому как не происходит переключения канала на другого слэйва. Карта, кусок ТБ и результат ниже //========================================================= //0号主机写任务 task task_m0_w(input [31:0] addr_start); begin addr_start_0 = addr_start; en_w_0 = '1; #PERIOD; en_w_0 = '0; #400; end endtask //========================================================= //0еЏ·дё»жњєиЇ»д»»еЉЎ task task_m0_r(input [31:0] addr_start); begin addr_start_0 = addr_start; en_r_0 = '1; #PERIOD; en_r_0 = '0; #400; end endtask ........................................... initial begin //е¤ЌдЅЌ&初始化 task_init; #200; task_m0_w(32'h0800_0011); task_m0_r(32'h0800_0011); #200; task_m0_w(32'h0800_0011); task_m0_r(32'h0800_0011); #200; task_m0_w(32'h1000_0011); task_m0_r(32'h1000_0011); #400; $stop; end механизм отлова ошибок генерится автоматом, если в системе более одного мастер интерфейса (слэйва) и явно не указано обратное ( C_RANGE_CHECK принудительно не установлен в 0). к тому же где то в глубинах корки: assign mi_awvalid = aa_mi_awtarget_hot & {C_NUM_MASTER_SLOTS+1{mi_awvalid_en}}; assign mi_awready_mux = |(aa_mi_awtarget_hot & mi_awready); assign M_AXI_AWVALID = mi_awvalid[0+:C_NUM_MASTER_SLOTS]; // Slot C_NUM_MASTER_SLOTS+1 is the error handler assign mi_awready[0+:C_NUM_MASTER_SLOTS] = M_AXI_AWREADY; assign sa_wm_awvalid = aa_mi_awtarget_hot & {C_NUM_MASTER_SLOTS+1{sa_wm_awvalid_en}}; assign sa_wm_awready_mux = |(aa_mi_awtarget_hot & sa_wm_awready); ------------------------------------------------------------------------------------------------------------ за наводку на хилинховые мастера-слэфвы спасибо. сначала хотел по-хорошему взять уже имеющиеся наши модули, но потом плюнул на их подгонку и взял рыбу с гитхаба :)

Моделирую данную айпишку. Настройки по минимуму - в режиме SAMD, без буферов, фифошек, регистров, разных регионов, итд итп. В конфигурации 2 мастера/4 слэйва. Один из слэйвов с переходом на акси лайт. Пока столкнулся с 2 моментами: 1. После начального сброса RREADY внутри кроссбара на мастер интерфейсе (к слэйвам) устанавливается в единицу. При этом на слэйв интерфейсах (со стороны мастеров) этот сигнал стоит в нуле, как и задается в модели. В процессе работы рэдик к слэйву все время стоит в единице, хотя мастер держит его в нуле и поднимает только на момент чтения 2. Зависает запись при обращении к следующему слэйву. В тестбенче последовательно идут циклы записи/чтения от каждого мастера к каждому слэйву. При этом последовательное обращение к одному и тому же слэйву проходит без сбоев. Как только меняется адрес - в интерконнект приходит адрес с валидом, из интреконнекта валид к слэйвам не выходит. При этом все адреса верные и ошибок декодирования нет собственно - кто виноват и что делать? ковырять на модели ксайлинксовскую корку XBARa с его функциями и генерациями - желания нет от слова совсем... может кто уже сталкивался с подобными ситуациями? зы В первом случае ситуация, в принципе, соответствует протоколу (транзакция может начинаться с рэди-валидом на мастере/слэйве в любых комбинациях) и все выруливается при написании слэйва. Хоть и не хотелось бы подстраиваться под эту "вещь в себе" (интерконнект), а иметь возможность задавать все настрйоки самому. И чтобы ее поведение соответствовало задаваемым воздействиям... на скринах в общем случае должна быть видна ситуация с рэдиком со стороны мастера со стороны слэйва

Помню что несколько лет назад натыкался на подобное обсуждение (может даже и сам его создавал :)), но через поиск его не нашел. Собственно задача - как при описании портов устройства автоматически сгенерить несколько экземпляров одного и того же интерфйеса, используя дженерик-параметр? Насколько помню старое обсуждение - на ВХДЛе этого нельзя было сделать. Ну кроме как объединить одноименные порты в одну шину и разделить потом на нижележащие устройства. Но такой вариант мне не подходит. А вот на верилоге что то подобное можно было провернуть... Но с верилогом пока знаком очень плохо и на скорую руку гугл ничего не подсказал. Поэтому буду благодарен за примеры :) зы если использовать интрефейсы в системверилоге, то как параметризировать объявление портов модуля на топ-лвл?

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

пипец, вчера 2 раза по всем настройкам прошелся... вот прям сверху вниз по всем вкладкам... удалить тему или пусть весит?

Ситуация. На ИСЕ пользовался моделсимом 10.4с. При переходе на виваду дошли руки до моделирования и при компиле библиотек посыпались ошибки. Беглый просмотр интернета сказал что моделсим слишком старый. Заимел МС 2019.4, поставил рядом с 10.4, либы скомпились, ошибок нет. Но при старте симуляции запускается МС 10.4... В моделсим.ини в папке с либами МС2019, прописана версия 10.4, и ниже все пути библиотек - к папке с либами 2019.4. При открытии диалога компиляции библиотек по умолчанию выскакивает путь к старому симулятору - МС10.4. Подозреваю что в настройках вивады где-то залипла версия 10.4. Указать явный путь к симулятору нигде нельзя ()как это было раньше в ИСЕ в отдельной менюшке). Единственное место выбора - при компиляции библиотек. Но залипуха именно там и происходит...

а если у слэйва объем, допустим 256К? если это большая память?

день добрый. на время карантина встала задача пересмотреть нашу внутреннюю чебурашку, обозванную системной шиной АКСИ4 лайт, и привести ее в соответствие протоколу. Под наши задачи протокол должен быть АКСИ4. пробежался по спецификации и возникли вопросы... 1. такая штука как AWREGION/ARREGION. со своим английским плохо понял этот пункт. если на одной физической шине организована несколько логических с перекрывающимися адресными пространствами, то получается что это поле жестко заданный идентификатор логического интерфейса. который проставляется каждому мастеру на стадии проектирования системы. таким образом мастера с одним мдентификатором образуют один "мемори мап". слэйвы же в этих нескольких мапах могут пересекаться, и задача интерконнекта во-первых состыковать выставляемые мастерами адреса с реальными адресами конкретного слэйва, во-вторых коммутировать ответы слэйва в нужную зону к своему мастеру. правильно я понимаю суть? а, и почему именно 4КБ? "The 4-bits of region identifier allows up to sixteen different regions to be uniquely identified. The region identifier provides a decode of higher order address bits. The region identifier must remain constant within a 4kbyte address space" 2. как организуется буферизация с "Bufferable (B) bit, ARCACHE[0] and AWCACHE[0]"? это единый стек по каналу, в который сваливаются запросы от всех мастеров вперемешку? или буферы для каждого слэйва в отдельности, в которые интерконнект рассовывает уже отсортированные запросы? 3. кэширование нам не нужно, но для общего развития... что означает возможность объединять транзакции записи при кэшиировани? правильно я понимаю что при обращении на запись по определенному адресу интерконнект может пробежаться по кэшу, и если в нем присутствует запись по этому адресу - заменить данные в более раннем запросе на данные из более позднего, и более поздний запрос вообще "удалить" не "обрабатывая" (добавляя в очередь)? 4. как организуется стыковка конвееров по адресам-данным? • the slave can wait for AWVALID or WVALID, or both, before asserting AWREADY • the slave can wait for AWVALID or WVALID, or both, before asserting WREADY получается что и адрес может быть принят раньше данных и данные могут быть приняты раньше адреса. если слэйв поддерживает этот механизм, то получается что у слэйва должен быть буфер, в который запихивается опережающий канал. какой глубины буфер? под максимально допустимый размер пакета в 1024 бита? плюс логика на выбор источника записи - буфер или напрямую шина. а если учесть что это должен уметь каждый слэйв - не слишком ли это ресурсоемко получается? 5. как вообще грамотно организовать интерконнект, чтобы не просадить производительность? это получается один огромный коммутатор... арбитр мастеров на входе, для каждого слэйва в зависимости от битов AWCACHE коммутация буфер/шина, плюс всякие эксклюзивные и приоритетные доступы... попытался посмотреть как делают интерконнект другие. с нулевым результатом - нашел только одну раскодированную корку в которой нифига не понял :).

без явного указания после сброса не может быть неопределенки. будет либо 0 либо 1. а вот какое конкретно значение из этих двух - неизвестно. и если у вас схема критична к начальному состоянию, то могут возникнуть сбои в логике работы. например где то в схеме используется признак "счетчик достиг порога". по которому запускается какой то процесс. если при начальной инициализации этот сигнал "признака" выставится в начальное состояние равное 1, то у вас схема сразу отработает там, где не должна была. "собьет" какие то данные, заставит лишний раз сработать какой то другой счетчик, итд итп. при отладке это не сложно отловить, но на это будет тратиться время. поэтому все критичные сигналы лучше сразу при объявлении явно инициализировать нужным значением.

что значит "Резистор в размере 10%"? обозначение мощности? какое это значение в ваттах? куда конкретно втыкается обратная связь? точка между резистором и конденсатором? ps 1N4148 подойдет?

в упрощенном виде дано: датчик потока YF-S201, китайских дешманский блок питания за 150р, собранная схема "выпрямителя", твердотельное реле (которым управляет "выпрямитель"), проточный нагреватель (включаемый твердотелкой). проблема: на пороге включения происходит "дребезг" - реле постоянно срабатывает/отключается не соображу - как от него избавиться? в плисинах от дребезга кнопок применяют цепочку триггеров на входной сигнал. но тут то не разовый выброс, а постоянное мельтешение зы в микроэлектронике - полный ноль. рассчитать схему не в состоянии. прочитать и то "со словарем"

железячник, накидывая код, примерно понимает как его разложит синтезатор. сколько это будет лутов и триггеров, сколько слоев логики, уложится ли это в требования к быстродействию и объему проекта или нет, какие его ждут неприятности в последствии и куда надо будет смотреть, если что то не заработает. программист приблизительно что то понимая пишет код и отдает его на откуп синтезатору, рассчитывая что он по заданным ему параметрам что то соберет. косяк в том, что настраивать синтезатор программист не умеет :). да и сама эта шайтан машина работает далеко не идеально и постоянно выеживается, выдавая не то что должен был выдать. например запись сумматора Х=А + В + Р(перенос), это не то же самое что Х=В+А+Р (или Х=А+Р+В - уже не помню :)). эти записи синтезатор разложит по-разному

вроде так. счет вверх-вниз по выбору. по желанию ненужные варианты выпиливаются. сигналы в капсе - внешние порты вашего устройства (если счетчик это отдельный блок). если просто код процесса внутри большого устройства - то они вырабатываются где тов другом месте architecture Behavioral of counter is signal ct, INCR :std_logic_vector(19 downto 0):=(others=>'0'); signal res_ct, CE_CT, init_ct :std_logic; signal res_ct_m2d, res_ct_md :std_logic; signal INCR_SELECT, direct_count :std_logic; constant const_v1 :std_logic_vector(19 downto 0):="00000000000000000001"; constant const_v2 :std_logic_vector(19 downto 0):="00000000000000000010"; constant CONST_INIT :std_logic_vector(19 downto 0):="11111000000111001110"; --значние -1 от нужного, т.к. счет с/до нуля BEGIN pr_ct:process(CLK) begin if CLK'event and CLK='1' then --если у вас срабатываение счетчика 1 раз на 3 такта, то условие сброса, выработанное на предпоследнем такте "выравнивается" по срабатыванию --если счетчик срабатывает на каждом такте частоты, то ничего выравнивать не надо if res_ct='1' then res_ct<='0' after 100 ps; elsif direct_count='0' and CE_CT='1' and ct=CONST_INIT then res_ct_m2d<='1' after 100 ps; elsif direct_count='1' and CE_CT='1' and ct=const_v1 then res_ct_m2d<='1' after 100 ps; else res_ct_m2d<=res_ct_m2d after 100 ps; end if; res_ct_md<=res_ct_m2d after 100 ps; res_ct<=res_ct_md after 100 ps; --условие на выработку СЕ счетчика if INCR_SELECT='1' then incr<=const_v1 after 100 ps; else incr<=const_v2 after 100 ps; end if; if res_ct='1' and direct_count='0' then ct<=(others=>'0') after 100 ps; elsif (res_ct='1' and direct_count='1') or INIT_CT='1' then ct<=CONST_INIT after 100 ps; elsif CE_CT='1' and direct_count='0' then ct<=ct+incr after 100 ps; elsif CE_CT='1' and direct_count='1' then ct<=ct-incr after 100 ps; else ct<=ct after 100 ps; end if; end if;--clk END.

да, мажоритарка очень бы пригодилась когда я пару лет назад делал модуль автоматической подстройки данных, принимаемых от АЦП - там калибровка и при пуске проводилась и в процессе работы, если требовалась :). но то ли я тогда за нее не знал, то ли не помнил. хотя диплом бакалавра делался в похожей области - нечеткая логика. если память не изменяет, там работа велась с вероятностями нахождения сигнала в заданном состоянии

УПД 2 родилось предположение - что может изменяться от прошивки к прошивке в данной ситуации (при всех прочих равных). Не автоподстройка ли это фазы на ПЛЛ-ях/ДЦМ-ах? она происходит автоматически при каждой подаче питания на устройство. но как это может быть связано с тем, что на первой плате от прошивки к прошивке все стабильно. и на второй плате так же стабильно, но только 3 пары из 4 возможных УПД 3 еще одна догадка по поводу попадания от запуска к запуску только в 2 положения из 8 возможных. произвольное попадание в любое из положений при ранних опытах скорее всего было из-за того что во время этих опытов стенд НЕ синхронизировался от меня, а работал от своего кварца. получалась произвольная расфазировка наших опорных частот, возможные "ошибки" из-за допусков на кварцах. в итоге получали рандомное выставление асинхронного сигнала стендом относительно платы. при нормальной синхронизации все ок - расфазировка если есть, то стабильная. 2 положения асинхрнного У0 обусловлены внутренней логикой его выработки можно попробовать использовать мажоритарную логику для определения подлинности У0. по идее это должно исключить возможные метастабильные состояния этого сигнала, от которого стартует вся внутренняя логика. но что то мне подсказывает что дело не в этом...

вот, что еще торкнуло. на второй плате 90% косячных срабатываний. с разбежкой шаг влево, шаг вправо. это значит что все время "компенсируется" одна и та же (две одних и тех же) неправильная константа. всего их 8 штук. это значит что в 90% случаев фронт У0 приходит в одно и то же место (в 2 места :)). при том что оператор запускает обмен в произвольный момент времени. но этого же не может быть чтобы стабильно из 100 опытов в 90 было 2 значения из 8. собранная статистика прошлых запусков это подтверждает - распределение довольно случайное. какие мысли могут быть по этому поводу?

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

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

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