Golikov

А ну это простая, это SPI который идет младшим битом вперед и на каждые 8 бит данных в начале добавляется нулевой бит и в конце единичный. Как старт и стоп. Собственно все отличия от классического SPI перечисленный, стартовый-стоповый бит и обратный порядок передачи. единственное надо узнать может ли микруха жить без клока в паузах передачи, может ли она сама инициировать передачу данных обратно? Бывает что ей надо уметь без запроса отдавать данные и тогда приходиться делать чуть сложнее, клок идет всегда, а посылки на него синхронизируются. При этом прием работает независимо от передачи (его может инициализировать слейв), и надо просто ждать стартового символа, провала линии в ноль, после чего начинать прием 8 бит, и пропускать дополнительный стоповый. П.С. да еще отличие от SPI в потенциальной возможности обмена без участия мастера. П.П.С. Ну да невнимательно посмотрел сразу SCLK - System clock input for serial I/O and all internal logic. Она на это клоке принимает, передает и сама живет от него же. Тогда он должен быть всегда и нужны независимые приемник-передатчик.

вам никто не мешает вставлять блоки руками туда куда вам надо. А настройки с авто передвинуть на запрещено. еще есть ключики для верилога (* use_dsp48 = "YES" *) ставиться на куски кода где надо дсп воткнуть. возможно для vhdl тоже что-то подобное есть. вроде все также https://www.xilinx.com/support/answers/54778.html вот там есть по стилям памяти. Где то можно найти весь список и управлять процессом чуть лучше. Но полный контроль это руками размещать ДСП блоки. Другое дело зачем? Ведь он сам начнет пихать логику, когда ДСП кончится, или подменять операции ДСП блоками когда кончится логика. Чтобы уложится в частоту и размер. Какая вам разница как решена задача, если она решена?

ну очевидно в формате посылки. USART может потребовать стартового и стопового бита для синхронизации, в отличии от SPI который для этого использует чипселект. ИМХО. Плюс есть злобные форматы усарта, где на каждый бит по 390 клоков должно быть. УСАРТ слишком широкое понятие...

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

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

можно было и по переднему фронту. Так времянке даже легче будет, на распространение сигнала будет 1 такт, а не половина. Сигнал так же попадет под анализ синтезатора. Второй триггер в цепочке синхронизации нужен для защиты от мета-стабильности. Один триггер который щелкает входной сигнал может быть в состоянии 0, 1, или Х - это если неудачно попал фронт. Это состояние рано или поздно свалиться к 1 или 0. И беда что остальные участники схемы смотрят на это состояние и по разному его видят, кто-то может его принять за 0, а кто-то за 1. Поэтому ставят второй триггер, чтобы он принял какое-то решение единолично, а остальные уже работали от него. Вероятность поймать мета-стабильность сильно меньше чем вероятность поймать гонку в исходном примере, поэтому все и заработало. Но природу не обманешь, когда-то и это стрельнет, так что лучше все же 2 триггера.

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

этап симуляции нигде не пропустили?

И видать в настройках квартуса он как раз по умолчанию включен. А в ISE/Plan-ahead по умолчанию выключен. Или как то так... в целом не важно, главное что оно есть.

возможно в альтере по умолчанию включен именно безопасный автомат, потому и others уже учтен изначально.

Книжек не пишу, но тут могу рассказать в чем дело. Когда вы добавляете это состояние вы здорово увеличиваете схему. Например, у вас есть автомат в режиме оне-хот из 3 бит. Ваши допустимые состояния 001, 010, 100. При штатной работе он в других режимах не бывает. Но как только вы добавите default (others) вы сразу добавляете обработку всех остальных комбинаций 011, 101, 110, 111, 000. Причем уже левых, невозможных, состояний больше чем рабочих. И чем длиннее состояние, тем больше перевес. А дальше у разных фирм разная концепция оптимизации. Допустим ксалинкс без явного указания делать безопасные автоматы выкидывает default, если в ходе работы нет переходов в состояние описанное в дефолте. А при указании использовать безопасное кодирование, сам добавляет default, даже если его не было. Альтера действует иначе, и состояние дефолт по умолчанию не выкидывает, но вроде как и сама не добавляет. Переходы в оне-хот автомате это снять единичку в одном бите и поставить в другом. Лично нарывался на ошибку где из-за гонки сигналов единичка снималась, а другая не ставилась. Состояние становилось 0, и автомат вис. И на альтере за счет дефалта работа восстанавливалась, а на ксалинксе умирало насмерть. Поэтому теперь всегда стараюсь делать дефалт хотя бы с 1 рабочим состоянием под ним (чтобы автомат не повис навсегда и не оптимизировалось как ненужное), а также обязательно добавляю индикацию перехода в это состояние, чтобы понимать что где-то есть ошибка. Без этого выше описанная проблема не была длительное время обнаружена на альтере. это просто не верное решение проблемы%) На самом деле эта задача решается через FIFO. Данные в него поступают на частоте работы схемы. Внутри фифо делается пересинхронизация на частоту работы SPI. И данные с FIFO выходят на частоте SPI с управляющими сигналами на той же частоте. И в итоге у вас просто задержка начала передачи, а не снижение скорости. В обратную сторону, для принятых данных тоже FIFO, но с обратным частотным переходом. Либо просто делают буферный регистр данные в который можно положить пока выдается прошлое значение, фактически то же фифо, но на 1 значение. Вся пересинхронизация идет пока SPI выдает данные и когда SPI готово у него уже есть данные и сигнал старта. Принятые данные также кладутся в буферный регистр, во время приема следующего байта их можно спокойно пересинхронизовав забрать.

Охх... Сейчас я вам скажу в чем ваша беда, вы наверное имеете программную практику. В описании железа надо понимать следующее, когда вы пишите : if(condition) then a <= b; c <= d; e <= f; end if; вы пишите 3 независимых ифа, на самом деле вы написали if(condition) then a <= b; end if; if(condition) then c <= d; end if; if(condition) then e <= f; end if; И надо понимать что эти 3 условия проверяются в разных частях кристалла, то есть в разное время, то есть там реально 3 схемы каждая проверяет свое значение condition, свою копию. Вы думаете что это происходит в один момент, потому что это все по фронту клока, но клок в разных частях схемы происходит в разное время. За синхронными сигналами следит синтезатор, чтобы они дошли до всех частей в то же время что и клок (это упрощенно, но смысл тот же). И создается ощущение что все произошло одновременно. А вот для асинхронных сигналов все не так, за ними никто не следит. Вы ошибочно смотрите на свое единое условие и думаете если одно сработало, то и другие тоже, а для асинхронных сигналов может сработать только часть условий, более того, даже счетчик состоящий из нескольких бит, порождает условие для каждого бита. И в результате если схема собралась что все участники условия лежат рядом, вы получаете рабочий вариант, разница времени прихода очень мала, и попасть на один и не попасть на другой приемник трудно. Но потом что-то меняется участники условий разъезжаются и вероятность того что одно сработает, а другое нет начинает расти. Это не мета-стабильность, это так называемые гонки сигналов, но смысл тот же. Когда вы асинхронный сигнал пропускаете через 2 триггера, он сразу попадает под надзор синтезатор и тот позаботиться чтобы он дошел в тот же клок ко всем приемникам. Осознайте эту штуку и сразу станет легче. вид автомата на схемах реально странный, не знаю почему оно сначала было так, а стало сяк. Могу только предположить что есть какая-то неопределенность со знаком числа. Но как бы то там ни было в нем нет случайной составляющей. Он бы либо работал всегда, либо не работал бы никогда. Любые такие ошибки они алгоритмически определены и должны были повторяться из раза в раз. А вот асинхронный сигнал который может допустим переводить состояние, но при это не менять счетчик (потому что до него не успел добежать), вот он как раз вносит элемент случайности, попадет он в интервал или нет. Так что уверяю вас с описание все боле менее, проблемы с асинхронщиной. кстати даже смена состояния в которой участвует асинхронный сигнал может пройти не так, часть битов поменяют свое значение, а часть нет. Поэтому могут возникнуть состояния которые на самом деле по логике невозможны. Добавьте default в кейз, с индикацией ошибки и переходом в идле, это и правило хорошего тона, да и нужная штука. Тем более что у вас альтера, и она по умолчанию это не оптимизирует.

В случае serial флешек, ксалинкс всеяден, работает на самом стандартном протоколе, с параллельными не знаю, но вроде бы тоже ему все равно кто делает флеш, главное чтобы протокол был стандартный.

Он должен быть синхронизированн только в очень плохо написанных SPI, в которых работа идет в слейве по основному клоку, а не по клоку SPI. В противном случае гарантированные сетапы и холды выдерживаются протоколом (ну и схемотехникой, конечно). Если что-то работает стабильно, а временами ломается - проблема не в стиле описания, а в мета-стабильнтости или гонках сигналов. Как я вижу из описания у вас вроде как SPI мастер на половинной частоте основного клока. Вопросы вызывает сигнал StartCmd - откуда он берется? Если он внешний или с кнопочки то его надо синхронизовать, а то и защитить от дребезга. Потому что огромный шанс что у вас пол автомата переходит в передачу-прием, а половина остается в старом состоянии. Так же имеет смысл проверить разрядности счетчика. Ну и попробовать снизить частоту, может просто реально слишком быстро для вышей платы. В целом описание популярное, не очень хорошее, но для маленьких автоматов вполне годное.

альтера макс десятый с флешкой внутри.

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

process(clk) ... when state_fin_wait_1 => .... elsif unsigned(session_ack_num) = unsigned(tosend_seq_num)+1 then .... tosend_seq_num <= std_logic_vector(unsigned(tosend_seq_num) + 1); send_packets: process(clk) ... tosend_seq_num <= tosend_seq_num_next; трудно открыть в блокноте и посмотреть где у вас идет присвоение в эту переменную? Пофиг среде что у вас процесс от одного клока, 2 процес блока - значит 2 источника сигнала.

так если у вас не 1 такт, то лучше обрабатывать маленькими порциями. 100 за 1 такт - долго, 10 за 1 такт быстрее, причем значительно, а за следующий вам из 10 ответов опять надо будет выбрать 1. То есть 1 по 100 меняем на 2 по 10, и получаем сильный прирост. можно собирать очереди прерываний с метками времени, и потом их сливать в один поток в порядке приоритетов...

ну хорошо бы еще плис назвать:) спросите гугл quartus examine, выпадет куча вопросов как это сделать и будут перечислены серии для которых это сделать нельзя

возможно стоит защита от чтения.

Как это делают все остальные. Выпускать более совершенные продукты пока они копируют старые. По другому никак. А так можно делать: Залить программу в память ПЛИС и поставить батарейку(аккумулятор) на время бездействия прибора. Прошивки физически нет во флеше, считать ее неоткуда Залить прошивку в шифрованном виде и использовать механизмы FPGA Залить прошивку в шифрованном виде и поставить внешнюю CPLD/CPU с защитой для ее расшифровки Можно взять цпу с батарейным доменом в котором хранить ключи шифрования и ножкой уничтожения данных, залить все компаундом. Все вопрос вашего уровня паранои, но реально работает только первый вариант. Надо поставлять не прибор, а сервис и развитие. Стандартные методы защиты достаточно усложняют жизнь пиратам и дают вам время на разработку. А если у вас что-то мелкое, то и возится не будут даже.

можно чтобы блок выставлял адрес если 1 вбок или 0, если нет единички и адреса все по ИЛИ соединить. то есть снизу единичка, если прерывание есть, то на выход адрес и 1, и вверх 0, если прерывания нет, то на выход адрес 0 и 0, и вверх 1. И все модули соединяем друг за другом. Адреса по ИЛИ. АСК по И со вторым выходом.

ну у вас это tosend_seq_num в 2 процессах под клоком. Ни ксалинкс ни альтера тут не причем. Либо исходник не верный, либо вы его творчески поправили не понимая что делаете. Нельзя один сигнал в 2 местах присваивать, уберите присвоение и все наладится....

ну да с наиболее приоритетного конца соединить их через мультиплексор. Если прерывание горит, то выход вбок, если нет, то выход на следующий блок. Подать единичку, она "добежит" до самого первого прерывания, и выйдет в бок. Дальше на все прерывания подать АСК объединенный по & с вышедшей единичкой. Ну и общий 1 хот дешифратор в адрес.

почему нельзя выбирать за такт из нескольких блоков?