roboforum.ru

Давайте.
Скажем пятьдесят восьмибитных регистров - это 400 триггеров.
Даже в младшем семействе 3000A есть кристаллы по 512 макроселлов (считай, триггеров с широко конфигурируемой логикой на входах-выходах).
При этом асинхронная логика часто может быть реализована без использования
макроселлов вообще (то есть фактически "не занимая" ресурсы CPLD)...

А в семействе MAX II, например, есть кристаллы с двумя тысячами триггеров.

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

а сколько уйдет на обработку?

А в ФПГА?

Спор переходит уже в область религии.
Предлагаю прекратить его и топикстартеру самому определяться с элементной базой

Именно!

Ну триггеры в CPLD это хорошо. 512 штук даже похоже хватает, но насколько красиво их можно будет разбить на байтовые ячейки и организовать их адресацию?
Может чтобы не задиратся на FPGA - сделать буффер на внешнем ОЗУ- на том же куда результат будет выплевыватся?

(ну и если разница в монтаже и стоимости FPGA и CPLD не велика - может ну его - АРМом будем моторчики крутить?)

Добавлено спустя 5 минут 11 секунд:


Кто такой "Катус"? Гугль кошек какихто выдает.

И сделать это узким местом? Круто тогда зачем было переходить с АРМа на ПЛИС?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Ну можно же поставить 2 шустрых ОЗУ по сотне ячеек - и завести их по независимым ШД. ША тоже не широкая получится для адресования 100-200 ячеек. И одну большую медленную ОЗУ для сливания результата.

Пока вопрос "триггеры в CPLD ... насколько красиво их можно будет разбить на байтовые ячейки и организовать их адресацию?"

Das ist Quartus -среда разработки от Altera

Добавлено спустя 50 секунд:
Тогда может озвучети применяемый АЦП. Какой у него интерфейс?

имхо надо определится с математикой, на мой взгляд лучшее решение для аналога в цифре это DSP

_________________
die Wahrheit ist irgendwo da draußen

Это типовое применение.


Угу. Причем и внутреннее ОЗУ циклона работает так же (ну разве что пошустрее и двухпортовое),
- поддержку шины все равно придется такую же лепить и принципиально оно тоже будет узким местом
(хотя и не таким "узким").


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

И корпуса... разные... как обычно - чем круче, тем непаябельнее.

Так, пробую описать алгоритм. Немного мозги вскипели. Не сильно оно параллелится.

Для хранения всей информации достаточно буферов А, В (байтовые) и промежуточного S (WORD-овый). (размеры раза в 2-3 больше чем на картинке)

В каждом цикле (каждые 80 нс) содержимое А и В сдвигается влево и в освободившуюся ячейку пишется значения с АЦП1 и АЦП2 (Да, их два).

Сами вычисления пока не очень хорошо ложатся на программируемую логику. Пытаюсь пока оптимизировать это на Си++, а там и озарение прийдет.

За цикл нужно успеть как минимум заполнить вектор S - каждая ячейка - сумма отклонений вектора А от ячеек вектора В (взятых с соответсвующим номеру ячейки S смещением)

Что-то вроде КИХ-фильтра.
А что потомс вектором S делать? (ну не наружу же его целиком o_O)

2executer: Опишите алгоритм тупо на Си, там посмотрим.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Каждый цикл выдается одно BYTE значение - индекс ячейки вектора S с минимальным значением.

Вот-вот - и описываю как раз. В голову не лезет чтоб сразу на Си писать - вот и рисую.