[Plain 392]

33 минуты назад, _pv сказал:

делает из этого CLB "эталонное ненужно"

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

[makc 385]

Обсуждение МК, DSP и т.п. выделено в новую тему: 

 

[sclv 7]

On 5/12/2025 at 6:12 PM, _pv said:

CLB01* TBLE Single BLE input to output propagation time — 10 — ns

CLB06* FMAX_SYNC CLB module maximum clock frequency for synchronous applications — 16 — MHz

CLB07* FMAX_ASYNC CLB module maximum switching frequency for asynchronous applications — 100 — MHz

 

On 5/13/2025 at 5:49 PM, Plain said:

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

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

[iBredihin 3]

К слову автор еще не выиграл конкурс

[sclv 7]

13 minutes ago, iBredihin said:

К слову автор еще не выиграл конкурс

Если вы это знали, почему сразу завели разговор о договоре и переводе денег?

[_pv 107]

5 hours ago, sclv said:

Ну как раз случай им все это сказать, раз они открыты, только более ясным языком.

Это их даташит, в котором они сами, сознательно, не привели нормального описания этого самого CLB, и о том как именно он будет функционировать приходится догадываться по косвенным признакам. Это ещё не говоря про описание конфигурации CLB, его программирование и ПО для всего этого.

Пусть используют это поделие сами, на пару с Маском.

[quаrk 73]

3 часа назад, sclv сказал:

Если вы это знали, почему сразу завели разговор о договоре и переводе денег?

Идея - "скрестить "ужа" и "ежа", и получить"'моток колючей проволоки" - стара, как мир. Где обоснование технической  и экономической целесообразности?!

Edited May 15, 2025 by quаrk

[quаrk 73]

4 часа назад, iBredihin сказал:

К слову автор еще не выиграл конкурс

И не выиграет!

В "рулетку" всегда выигрывает только владелец "рулетки"...

[mantech 139]

4 часа назад, _pv сказал:

Это их даташит, в котором они сами, сознательно, не привели нормального описания этого самого CLB

Как по мне, "взлетела" такая концепция, как МК+ПЛИС только у цинка, были попытки атмела сделать такую связку, но походу получилось, как с подобным пиком, цинк получился, т.к. там сделали все по-взрослому, мощный процессор и большое кол-во логических блоков, тут какой-то детсад, ИМХО.

[khach 82]

Если бы  такое появилось лет 20 назад, то было бы очень неплохо. Но сейчас копаться в ассемблере PIC будет только мазохист. Хотя хитрый квадратурный энкодер или перекодировщик SPI интерфейса АЦП-ЦАП к другому стандарту могут неплохо получиться.  A 40  ногие или 44 ногие такие есть? А то контроллер-эмулятор  GPIB или старого SCSI может неплохой получиться. Хотя это и древние интерфейсы, но иногда возникает потребность.

[quаrk 73]

49 минут назад, khach сказал:

Если бы  такое появилось лет 20 назад, то было бы очень неплохо. Но сейчас копаться в ассемблере PIC будет только мазохист.

Как раз, примерно, 20 с лишним лет назад познакомился с ассемблерами для PIC. Написал одну программу. После чего этот ассемблер выкинул и больше о нем не вспоминал. Написал свой, которым до сих пор и пользуюсь.

P.S. Как правило, производители чипов не умеют делать нормальные ассемблеры...

[_pv 107]

2 hours ago, mantech said:

Как по мне, "взлетела" такая концепция, как МК+ПЛИС только у цинка, были попытки атмела сделать такую связку, но походу получилось, как с подобным пиком, цинк получился, т.к. там сделали все по-взрослому, мощный процессор и большое кол-во логических блоков, тут какой-то детсад, ИМХО.

Там скорее наоборот ПЛИС + мк, чтобы не городить в логике всякие вещи вроде сетевых протоколов и всё что выше, а переложить на процессор с linux.

Более менее "взлетели", ну или так скажем, не совсем ещё померли, это psoc, который изначально был с 8051 и даже хуже, а сейчас к 6 версии уже на cortex-M4 + M0+.

Да и вместо именно мелкой CPLD в МК, дополнительные примитивные недоядра вроде PIO у rp2040, PRU у техасских армов, или слишком умных таймеров c программируемым конечным автоматом у LPC, имхо гораздо полезнее.

[mantech 139]

14 минут назад, _pv сказал:

Да и вместо именно мелкой CPLD в МК

Как по мне, лучше быстрое доп. ядро с возможностью софт-периферии, по типу древних scenix-ов, например, чем мелкая плисинка)))

[dxp 213]

11 часов назад, _pv сказал:

Там скорее наоборот ПЛИС + мк, чтобы не городить в логике всякие вещи вроде сетевых протоколов и всё что выше, а переложить на процессор с linux.

Вот тут трудно согласиться: тот же Zynq-7000, к примеру, -- это классическая SoC: CPU с развитым интерконнектом, кучей достаточно мощных периферийных блоков (типа Gigabit MAC, который оснащён своим специализированным DMA, позволяющим метать пакеты из памяти, используя механизм дескрипторов), которые способны много чего делать самостоятельно (как и положено в SoC, в отличие от МК), имеется DDR контроллер, который кроме CPU могут использовать почти все перифейные устройства -- т.е. таки система, и это только PS (Processor System). Помимо этого есть PL (Programmable Logic), которая цепляется к тому же центральному интерконнекту через AXI мосты, через которые осуществляется связь с CPU или другими устройствами PS, а также имеет прямое подключение к DDR контроллеру и непосредственную связь с CPU через ACP (AXI мост, подключенный L1 кэшам (через SCU). 

Сама PL часть при этом выступает как ещё одно устройство наряду с другими в PS. Да, это самая жирная по кремнию часть, и это именно то, что отличает Zynq от других SoC принципиально. Но по сути FPGA там -- это как возможность создавать кастомную периферию, которая идеологически стоит на той же "полке", что и остальные части в PS. Поэтому я бы не назвал PS часть придатком к FPGA. Это таки, повторю, классическая SoC с мощным CPU, развитыми интерконнектами и достаточно автономными периферийными устройствами, к коим относится и PL часть. И, кстати, совсем не обязательно использовать там Linux, мой кейс как раз bare-metal, хотя это весьма затратно в плане подъёма всего этого хозяйства.

Обращаясь к существу обсуждения (надо -- не надо такое: МК + ПЛИС), хочется заметить следующее: даже такая вполне удачная SoC как Zynq-7000 имеет существенный недостаток, возникающий из её некой монструозности и сложности: довольно большие задержки обращения между CPU и PL. В таких SoC задержки от CPU к периферии всегда немаленькие -- разные тактовые домены, несколько уровней интерконнектов -- пока до какого-нить UART'а достучишься, не один десяток тактов улетит, а тут для PL ещё и дополнительные AXI мосты. В итоге, там транзакция чтения регистра из PL может занимать сотни тактов (при тактовой CPU 400 МГц и тактовой PL 100 МГц такое обращение занимает почти 1 мкс, что очень много).

А вот в более лёгких системах этот недостаток можно сильно нивелировать -- если CPU и ПЛИС работают в одном тактовом домене, если там не AXI, а какой-то более простой мост, то такое обращение вполне может уложиться в десяток тактов или даже меньше -- вполне должно получиться не хуже обращения к какому-нибудь штатному периферийному устройству вроде таймера или порта (у младшего семейства Gowin есть вариант FPGA c аппаратным ядром Cortex-M3, любопытно было бы узнать, как оно в эксплуатации). И вот такая кастомная периферия в ряде случаев может оказаться весьма кстати. Современные технологии позволяют сделать на борту МК приличный по размерам блок FPGA (на пару тыщ ячеек с LUT4 + FF), это не должно сильно раздуть размер кристалла и цену.

Интерес Microchip к этой теме понятен -- у него есть все необходимые технологии и компетенция: он является разработчиком и производителем нескольких серий МК, он уже достаточно давно приобрёл ПЛИСовое подразделение -- семейство PolarFire является отличным кандидатом для ембеда FPGA в МК (у них уже есть SoC на базе этой FPGA, где в качестве CPU используется 4 64-битных ядра RISC-V (Application Level, Linux capable) от SiFive + 1 32-битное ядро МК (тоже RISC-V от SiFive). Софт для ПЛИС у них тоже есть (а софт зачастую поважнее самой ПЛИС). Вот только выбор МК в виде PIC16, имхо, явно неудачен. В качестве такового надо брать либо ARM, либо RISC-V, либо их же dsPIC.

 

[mantech 139]

2 часа назад, dxp сказал:

Но по сути FPGA там -- это как возможность создавать кастомную периферию, которая идеологически стоит на той же "полке", что и остальные части в PS.

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

15 часов назад, khach сказал:

Если бы  такое появилось лет 20 назад, то было бы очень неплохо.

Лет 15 назад точно было, только у Атмела, МК + нек-е колво ЛБ, но не взлетело даже тогда... Может потому, что были scenix-ы, 150мипс в МК, можно свою периферию было программно делать, это к тому, что тогдашние 8и битки были очень медленные, пики 16МГц \4, АВР 10МГц макс...

Edited May 16, 2025 by mantech