Всем привет!

задача такая, надо по SPI slave передать данные размером 32+64+6*32 бита и контрольная сумма (итого 37-38 байт)

SPI - slave, на частоте сравнимой с основным клоком, потому асинхронный, синхронизация по CS

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

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

В результате у меня получается такая схема:

SPI - передатчик, которому надо на вход выставить 8 битное данные, а он их выдавит асинхронно на выход. Он сигналом отмечает как забрал данные, и внешняя схема может выставлять следующие данные.

FIFO сделал параллельное, которое засасывает сразу всю посылку. Сделал его не одним фифо на (32+64+6*32) бит, а поставил 1+2+6 32 битных отдельных FIFO.

И вот теперь самое интересное. Надо как -то данные с выхода FIFO перепихать на вход SPI передатчика. И что-то у меня ничего умнее чем огромный мультиплексор на 9 8-битных слов в одно не получается. А еще по ходу перещелкивания он будет подсчитывать контрольную сумму, и добавить ее в конце, то есть мультиплексор 10-11 в 1. Ресурсы не жмут, но как-то не красиво выходит, может кто предложит какое-то более изящное решение?


Может 90 битный SPI будет более правильным решением?

А зачем такой изврат? Нужно сделать один отдельный FIFO на 18 слов, причем, 32-х битных.

Если там 37-38 байт, то сделать FIFO на байт, так, 128-256, и обычный 8-битный SPI... Ну или 64-128 16-битных слов... Или... Что-то там очень много проблем придумано из ниоткуда.

возможность параметризовать, сейчас 32+64+6*32, а завтра 8*32, или 2*32+64+6*32, каждый раз генерить новое фифо - муторно. Ноэто не главное, конечно можно было бы просто сразу сделать FIFO 90 бит. Это не решает основной задачи, как эти 90 бит оптимально перепихать в 8 выход SPI


как отсекать целую посылку, если мастер решил в середине утомиться и бросить принимать ее, надо ее всю целиком выкинуть, и быть готовым отдавать следующую. Если всю посылку 9 байт, повернуть в последовательную, то надо будет определять когда конец, и делать дополнительно вычитывалку оставшихся байт

выкинуть фифо и сделать многобуферный регистровый файл (например 4/8D) с памятью тегов и шириной слова данных 8 бит.

Вам не знакомо такое явление, как регистр сдвига с параллельной загрузкой?

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

ЗЫ. многобуферный регистровый файл, позволит просто добавить перезапрос пакета если вдруг потребуется

А как это вообще по SPI можно отследить? По тому, что он поднял CS? Так сделайте FIFO не 8(16,32)-битное, а 9 (17, 33) битное, где старший бит показывает конец посылки - чтобы автомат мог пропустить ненужные данные до конца.

я иногда задаю "детские" вопросы, но сейчас не этот случай


а теги зачем?
Фактически вы предлагает заменить FIFO на память, такой некий кеш, правильно я понимаю, сохранять строчками и вычитывать словами. И самому следить за последовательностью.


то есть все сходятся на том что надо делать 90 битный сдвиговый регистр и не придумывать? Если так то его можно и наружу выдавливать побитово, вместо того чтобы по 8 бит сдвигать и в SPI пихать.



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


в 90 битном сдвиговом регистре смущает времянка. Ведь чем больше бит, тем больше времени надо чтобы они все разом присвоились. А если он еще и сдвигаться будет по 8 бит...

Не все, конечно. Я бы сделал на трех счетчиках (два - 7-ми разрядных и один - 3-х разрядный), двух регистровых файлах (на 38 байт каждый) и на регистре сдвига на 8 бит.

Бред какой то... Чем больше бит, тем все они за один такт и присвоятся - тем времени меньше, но ресурсов больше. Чем меньше бит, тем больше тактов надо, чтобы их обработать, пропуская их по очереди.


Да, если времени достаточно, чтобы, пока мастер заново не активирует CS, пропустить старые данные.
Можно сделать FIFO шириной 9*4=36 бит, где каждый из байтов может быть помечен как крайний в пакете. Можно сделать два FIFO - в одном данные, во втором - длины пакетов. И пропускать сразу весь пакет, зная длину. Но, уже, придется делать свое описание FIFO, а не пользоваться готовыми IP, чтобы уметь пропускать сразу N данных, а не считывать их по одному.

То есть, если надо принимать решение за 1 такт, я бы применил ОЗУ, шириной кратное тому, чему кратны пакеты - то есть, если они всегда имеют целое число 8-битных байт - то 8-битное, если целое число 16-битных - то 16-битное, и т.д., и второе ОЗУ, работающее в режиме FIFO, передающее длины пакетов. И предусмотрел бы в первом FIFO возможность пропустить N (недосланных) слов за раз. Или, если можно долго пропускать байты - то лишний бит-флаг конца пакета, и автомат, пропускающий ненужные байты.

можно поподробнее, что-то я не очень понимаю




имелось ввиду что если присваивается 90 битный регистр, то это можно делать с меньше частотой, чем 2 45 битных регистра. Достаточное время на установку больше становиться. Ячейки дальше друг от друга, больше проводов, длиннее пути... то есть таская 90 битный регистр боюсь в частоте потерять


Про ОЗУ подумаю, но все равно как-то не складно все выходит...

Чтобы ответить "поподробнее", нужно знать:

1. Надо ли использовать два клоковых домена, один - для записи в FIFO, второй - для чтения из FIFO по SPI?
2. Может ли мастер SPI работать в 32-х битном режиме?
3. Всегда ли в FIFO записывается одинаковое количество байт?
4. Нужно ли иметь возможность записывать в FIFO новые данные и читать (по SPI) данные ранее записанные в FIFO одновременно?

1. не обязательно, можно, но с учетом что клок SPI есть вообще только на время передачи, а также есть разрешающий сигнал который показывает что данные на входе SPI можно менять
2. это не важно с точки зрения мастера, он вычитывает всю посылку. Паузы между словами быть не должно, мастер не будет ждать. 32 битный режим плох только тем что неудобно на лету считать контрольную сумму, изначально данные рождаются без нее, а задерживать их на подсчет не хочется, канал надежный, потому сумма примитивная 16 бит от суммы байт по всему сообщению.
3. длинна посылки фиксирована
4. естественно да, иначе зачем городить фифо. Более того нужно если вычитывание посылки по SPI прервалось со стороны мастера, отбросить ее целиком, и в следующих заход выдать новую целиковую посылку. Досылать хвост старой недопустимо.

а без тегов как вы узнаете заполненность буфера и его очередность ?