Средства и методы разработки

iCE40 UltraPlus family. Начало новой эры полностью кастомизированных микроконтроллеров. * ICE40UP5K-SG48I; 5280 LUT + Flip-Flop; 30 псевдо-двухпортовых блоков памяти по 4Кбита х16 макс.; 4 однопортовых блока памяти 16к Х 16; 8 DSP блоков; 39 IO; 48QFN, 0.5 mm, 7.0 mm x 7.0 mm; 2000шт - $6.30 * то же для партии 100 шт - $9.24, для нормального корпуса в невагонных количествах цену задрали. * ICE40UP5K-UWG30I; 5280 LUT + Flip-Flop; 30 псевдо-двухпортовых блоков памяти по 4Кбита х16 макс.; 4 однопортовых блока памяти 16к Х 16; 8 DSP блоков; 21 IO; 30BGA, 0.4 mm, 2.15 mm x 2.55 mm; 50шт - $5.76 * ICE40UP3K-UWG30I; 2800 LUT + Flip-Flop; 20 псевдо-двухпортовых блоков памяти по 4Кбита х16 макс.; 4 однопортовых блока памяти 16к Х 16; 4 DSP блока; 21 IO; 30BGA, 0.4 mm, 2.15 mm x 2.55 mm; 100шт - $4.46 * ICE40UP3K в QFN нет. Тонкость в том, что однопортовая память не инициализируется из встроенной FLASH. SPI флешки стоят совсем не дорого, так что это пережить можно. Все чипы имеют -40°C ~ 100°C (TJ), и это по такой цене! Вообще все семейство ice40 для всех чипов изначально имеет -40°C ~ 100°C (TJ). Вот здесь я рассматривал ICE40UL1K-CM36AI 100 - $1.86 1248 LUT + Flip-Flop, 14 блоков памяти по 512 байт. + силабсовкая EFM8 Universal Bee. http://caxapa.ru/732261.html + еще 8 битный АЦП ADS7949SRTER 3000 - $0.84 получалось: + MCU ($0.8) = $3,5 - это для дешевых MCU без шины + MCU ($1.5) = $4,2 - рассматриваемые 51 + MCU ($3) = $5,7 - распространенный MCU с шиной. Т.е. нормальный MCU с внешней шиной + простенькая FPGA ~ равно FPGA с неплохими набортными ресурсами. Когда iCE40 UltraPlus только вышли, я никак не мог понять замысел семейства, и зачем там 128к статического ОЗУ? Давным давно, осознав семейства MachXO* от Lattice, я написал несколько постов - типа щаз все перейдем на полностью кастомные MCU, софткор + кастомная периферия. Благо дока по синтезу софткора LatticeMico32 http://www.lattice …s02/LatticeMico32.aspx в MachXO была, что-то типа 2к LUT, Lattice Mico8 ваще 200 LUT - щас заживем! http://www.lattice …e/IPCores02/Mico8.aspx Однако внимательное изучение объема набортной памяти MachXO, стоимоси чипов быстро выветрило мой энтузиазм - кастомный MCU получатся убогим по памяти и категорически неконкурентоспособным по цене. Я также несколько осторожно относился к ICE40, потому что сам латтис считает, что это - "умная периферия на SPI и I2C" и не более. Форумчане делились опытом, что попытки синтезировать что-то более-менее сложное в ICE40 приводили к тому, что проект не собиралcя - не хватало путей трассировки, хотя в такие же по количеству LUT MachXO все собиралось. Вот тут лежит статья caxapa.ru/732082.html В которой сказано, что если FPGA синтезировать не фирменной тулзой (8619 LUTs (4-input) using Lattice Synthesis Engine (LSE)), то упрощенный RISC-V (PicoRV32, 0.309 DMIPS/MHz) влазит в 1521 (опенсорцная тулза) - 1320 (Synplify Pro) LUTs iCE40. Цельный 32 битный процессор! (статья про другое подсемейство ice40, более дорогое, но ячейки те же самые - есть шанс что можно экстраполировать и на это подсемейство). Чуток есть про RISC-V и ice40 https://www.reddit …_platform_riscv_based/ Zylin ZPU - стековый 32 битный процессор, с портированным GCC тулчейном. http://caxapa.ru/430201.html http://caxapa.ru/595444.html http://caxapa.ru/595522.html https://github.com/zylin/zpu http://opensource.zylin.com/zpu.htm В варианте Spartan 6 он синтезируется в окло 1K LUT (но там 6 входовые LUT), или чуть меньше. Вот тут народ опенсорцной тулзой (http://caxapa.ru/732073.html) синтезировал его в Lattice ICE40HX8, потратив Total Logic Cells: 3099/7680. Статья April 26, 2014 - это важно, ибо упомянутая тулза очень интесивно развивается. В мейл листе Zylin ZPU обсуждается, что некий крендель синтезировал в 1175 LUT's ice40 May 07, 2015 https://groups.google.com/forum/#!topic/zylin-zpu/AYzWi4sF1us В целом, в ICE40UP5K два 32 битых софткора скорее всего влезут, и даже чуток на периферию останется. Но не влезут. У нас большая блочная память однопортовая и 16 битная. Для одного проца в виде 64к кода и 64к данных - влезет, а для двух - либо адское извращение с мультиплексным доступом к ОЗУ, либо никак. Но!!! А нафига нам 32 битники? Есди IP не гонять, по SD карточке не шарится. Не так и много 32 битных задач в каноническом embedded мире. Если бы было простое 16 битное ядро, предельно простое и прямолинейное, с отдельными портами для памяти команд и памяти данных, то, вот так навскидку, я бы оценил его в 500-600 LUT, и был бы очень красивый двухядерный дизайн, у каждого ядра по 32к кода и данных. Наличие до 8 DSP блоков позволяет делать совсем не игрушечные вещи. Мы тут как-то обсуждали мегетему по совмещению питания и данных по одной витой паре, так вот там DSP фильтрация очень к месту. Важно иметь не крутое ядро, в котором все есть, а предельно постое ядро, к которому удобно подцеплять аппаратные блоки для управления ими. DSP фукнции в ядро точно тащить не надо - пусть они стоят в сторонке, а ядро только дергает ими. И так во всем. Ну и межядерное взаимодействие можно накодить качественно :) В RTL'е :) Лично мне такие ядра не известны, но я знаю как быстро просимулировать придуманную систему команд, да еще совместно с периферией :) http://caxapa.ru/732499.html Насчет готовых 16 битных ядер. Они изначально не были заточены под эконом-FPGA вариант. На всех этапах своего создания. Итог - печален. http://caxapa.ru/728688.html Там чуваки за 7 лет родили клон MSP430, который по LUT больше реализаций RISC-V, а по производительности во много раз меньше. Ну и кому такое ядро нужно? Подведем кратко итог. Что практически полезного можно получить от нашего двухядерного кастомного микроконтроллера за $5-6. Вернемся к витой паре, совмещающей данные и питание. Там две фундаментальные задачи: * DC-DC с малой проходной емкостью * модем под вариант с индуктивной развязкой данных и питания и передачи данных на поднесущей. Что именно позводяет сделать в части DC-DC такого, что просто MCU не может, я изложил. http://caxapa.ru/732261.html Для модема FPGA тоже необходима. Это и фильтрация, и работа с быстрым АЦП и ЦАП, аппаратная поддержка системы синхронизации (для уменьшения количества кода и повышения надежноси синхронизации). Неприятно, что придется на asm писать код для обоих ядер - разбираться, как LLVM научить работать со своим ядром, в моем понимании, это пару человеко-лет. Хотя дорогу осилит идущий... В итоге получается достаточно красивое решение. Критика?