Спасибо за статью!
Подскажите, а какой максимальный объем доступных микросхем? Всё же 8Мбайт не на всё хватает.
Мы хотели использовать HyperRAM в прошлогоднем проекте, но нам нужно было 32Мбайт, а таких чипов не было…
А при таких требованиях к SSD не рассматривали вариант хранить всё в оперативной памяти? А сливать данные на диск/SSD изредка для backup'а и при сигнале от UPS'ы?
Из-под Linux, работающий на ARM, заливается на ура. Я тоже не занимался прошивкой по частям: FPGA маленькая, чтобы таким заниматься.
P.S. Из интересных особенностей (если про них вопрос). Можно ресетить FPGA или прошивать FPGA только когда нет передачи данных (и нет неотвеченных запросов) по AXI-шине (внутренние шины от ARM к FPGA и обратно), а то может нарушиться протокол AXI и ARM зависнет.
1) Наверное, стоило бы добавить в обзор и Xilinx ZC702 Evaluation Kit, хотя он и стоит заметно дороже.
2) SDK работает у меня на Debian с XFCE отлично, если перед запуском сказать export SWT_GTK3=0.
3) Хотелось бы еще увидеть в статье ссылки на ресурсы (кроме сайтов самих плат). Например, мне очень помог www.wiki.xilinx.com.
Сравнение, скажем, в ракурсе поиска маршрута с пересадками.
У Яндекса удобно, что можно искать маршрут с пересадками на разные виды транспорта (например, часть пути на электричке, часть — на поезде; в Московской области это не актуально, т.к. поезда нигде кроме Москвы не останавливаются, а в других областях можно проехать как на электричке, так и на поезде). Но не удобно, что время пересадки непонятно как считается (IMHO сильно завышено).
У Вас удобно, что можно задавать время на пересадку. Но не удобно, что поезда не учитываются.
Вот я и сравнил ;). Что скажете, какие планы в этой области?
И более общий вопрос. Планируете ли развиваться в сторону поддержки всевозможных видов транспорта? Мне как пассажиру нужно добраться из А в Б, а уж каким транспортом — не так важно, главное за разумные (для меня лично) время и деньги.
Было бы интересно!
Я занимаюсь разработкой проекта на SoC Xilinx Zynq 7020 (аналог Вашего). И скорости взаимодействия ARM и FPGA части интересны, т.к. они временами нас ограничивают…
Правильно ли я понял, что скорость (400Мбит/с для шифрования) ограничивает не столько самой реализация AES в FPGA (блоки и размножить можно) (8Гбит/с), сколько скорость обмена данных? Не измеряли чистую скорость обмена данных (с учетом всего стека, конечно)?
А на какой максимальной частоте может работать такой проект не оценивали? Квартус выдает оценку. Чтобы ножки не влияли на оценку, можно вставить регистры на входе и выходе.
Вообще, переходя к конвейеру растет площадь — добавляются регистры и, может быть, логика. Но и растет максимальная рабочая частота (правда она сильно зависит от типа и поколения ПЛИС). Не очевидно где будет оптимум. Продолжайте исследования!
Интересно! А типизация распространяется только на комбинационные сигналы? Нельзя ли связать типом значения сигнала на разных тактах? Например, можно ли описать сигнал похожий на Either A B, но что не просто приходит сигнал типа A или B, а в более жестком смысле, что данные типов A и B чередуются во времени: A, B, A, B, ...?
Мне часто приходится передавать данные «размазанные» по времени и хочется уметь описывать каком-то образом их типы, чтобы компилятор проверял, правильно ли такие данные генерируются и потребляются.
Поезда проще машин (едешь по рельсам, никто не подрезает, не выбегает на дорогу и т.п.). Но и автоматические поезда контролируют операторы из диспетчерской.
Всё ж до сих пор полных автопилотов для самолетов (самолетов без пилтов) нет — значит есть какие-то трудности. Те же трудности будут ожидать и автомобили.
1) Все же пилота удалить из кабины не получается. Он контролирует автопилот, и в каких-то условиях, когда автопилот перестает справляться, берет управление на себя. Решение и ответственность на пилоте, а тот или иной автопилот — его помощник, пользованием которого он обучен.
2) Приборы — это хорошо. Но за частую они только передают информацию (скажем, как метеорадар), а анализировать ее и принимать решение (скажем, как лететь через грозу) — приходится пилотам. Это не тупая прослойка ;) — распознавание и анализ ситуации еще не всегда автоматизировано.
3) Собственно, ровно как в машине: хочешь, включаешь круиз контроль, хочешь — адаптивный, хочешь — слежение за разметкой и движение по полосам, и т.п. Но это всё системы, поведение которых водитель понимает. Соединение в связку — сложность системы резко возрастает и ее поведение перестает понимать водитель. Тогда либо его специально обучать (как пилотов самолетов, поездов, операторов различного типа станций, ...), либо выкидывать из машины и заменять внешним контролирующим оператором (без которого пока ничего не обходится).
Интересно было бы сравнить развитие автопилотов у автомобилей с автопилотами, например, в авиации, которые прошли достаточно большой путь. Но пилоты до сих пор остались: они контролируют автоматику, автоматика контролирует пилота. В хороших погодных условиях (те самые ~80%) — автопилот может полностью сам вести самолет. Однако есть условия, в которых автопилот не справляется, и тогда в дело вступает человек. Чтобы не потерять навыки для этих ~20% случаев приходится время от времени пилотировать в хороших условиях в неавтоматическом режиме.
Возможно, у автомобилей будет примерно тоже: в идеальных условиях (автобаны в хорошую погоду) автопилот полностью заменяет человека (и если ситуация не стандартная, то просит помощи у человека), а в других условиях — помогает человеку не допустить ошибки (как сейчас парктроники и т.п.).
Еще наблюдение. Чем больше автоматизации, тем обученней должен быть человек, чтобы понять, что автоматика не справляется. И человеку нужно постоянно следить за автоматикой, чтобы не пропустить тот момент, когда автоматика отказала, как в случае с Теслой. Так что если полные автопилоты и будут, то всех обучить их контролировать экономически неоправданно, поэтому IMHO их придется контролировать сверху (типа как автоматические ж.д. поезда). Но посмотрим.
Подскажите, а какой максимальный объем доступных микросхем? Всё же 8Мбайт не на всё хватает.
Мы хотели использовать HyperRAM в прошлогоднем проекте, но нам нужно было 32Мбайт, а таких чипов не было…
P.S. Из интересных особенностей (если про них вопрос). Можно ресетить FPGA или прошивать FPGA только когда нет передачи данных (и нет неотвеченных запросов) по AXI-шине (внутренние шины от ARM к FPGA и обратно), а то может нарушиться протокол AXI и ARM зависнет.
2) SDK работает у меня на Debian с XFCE отлично, если перед запуском сказать export SWT_GTK3=0.
3) Хотелось бы еще увидеть в статье ссылки на ресурсы (кроме сайтов самих плат). Например, мне очень помог www.wiki.xilinx.com.
Сравнение, скажем, в ракурсе поиска маршрута с пересадками.
У Яндекса удобно, что можно искать маршрут с пересадками на разные виды транспорта (например, часть пути на электричке, часть — на поезде; в Московской области это не актуально, т.к. поезда нигде кроме Москвы не останавливаются, а в других областях можно проехать как на электричке, так и на поезде). Но не удобно, что время пересадки непонятно как считается (IMHO сильно завышено).
У Вас удобно, что можно задавать время на пересадку. Но не удобно, что поезда не учитываются.
Вот я и сравнил ;). Что скажете, какие планы в этой области?
И более общий вопрос. Планируете ли развиваться в сторону поддержки всевозможных видов транспорта? Мне как пассажиру нужно добраться из А в Б, а уж каким транспортом — не так важно, главное за разумные (для меня лично) время и деньги.
Можете сравнить себя с коллегами из Яндекса? Получаете ли вы актуальные опоздания электричек?
Я занимаюсь разработкой проекта на SoC Xilinx Zynq 7020 (аналог Вашего). И скорости взаимодействия ARM и FPGA части интересны, т.к. они временами нас ограничивают…
Вообще, переходя к конвейеру растет площадь — добавляются регистры и, может быть, логика. Но и растет максимальная рабочая частота (правда она сильно зависит от типа и поколения ПЛИС). Не очевидно где будет оптимум. Продолжайте исследования!
Мне часто приходится передавать данные «размазанные» по времени и хочется уметь описывать каком-то образом их типы, чтобы компилятор проверял, правильно ли такие данные генерируются и потребляются.
1) Все же пилота удалить из кабины не получается. Он контролирует автопилот, и в каких-то условиях, когда автопилот перестает справляться, берет управление на себя. Решение и ответственность на пилоте, а тот или иной автопилот — его помощник, пользованием которого он обучен.
2) Приборы — это хорошо. Но за частую они только передают информацию (скажем, как метеорадар), а анализировать ее и принимать решение (скажем, как лететь через грозу) — приходится пилотам. Это не тупая прослойка ;) — распознавание и анализ ситуации еще не всегда автоматизировано.
3) Собственно, ровно как в машине: хочешь, включаешь круиз контроль, хочешь — адаптивный, хочешь — слежение за разметкой и движение по полосам, и т.п. Но это всё системы, поведение которых водитель понимает. Соединение в связку — сложность системы резко возрастает и ее поведение перестает понимать водитель. Тогда либо его специально обучать (как пилотов самолетов, поездов, операторов различного типа станций, ...), либо выкидывать из машины и заменять внешним контролирующим оператором (без которого пока ничего не обходится).
Посмотрим, что выйдет ;).
Возможно, у автомобилей будет примерно тоже: в идеальных условиях (автобаны в хорошую погоду) автопилот полностью заменяет человека (и если ситуация не стандартная, то просит помощи у человека), а в других условиях — помогает человеку не допустить ошибки (как сейчас парктроники и т.п.).
Еще наблюдение. Чем больше автоматизации, тем обученней должен быть человек, чтобы понять, что автоматика не справляется. И человеку нужно постоянно следить за автоматикой, чтобы не пропустить тот момент, когда автоматика отказала, как в случае с Теслой. Так что если полные автопилоты и будут, то всех обучить их контролировать экономически неоправданно, поэтому IMHO их придется контролировать сверху (типа как автоматические ж.д. поезда). Но посмотрим.