Понеже много ми хареса дискусията между miro_atc и gicho от страница 106 на темата „новини от производителите на МЦУ-та“, реших да споделя своята гледна точка относно едно просто решение на двата проблема многозадачност и зависимост от производителите на uC. А то е именно – собствена хардуерна архитектура. Предимствата са налице:

1. Гъвкавост от към HW/SW сплит, скалируемост, изисквания за сигурност а защо не и възможност за по-нататъшна продажба на технологията (IP-то) на някоя от големите акули, които в нещно време идват и от запад и от изток

2. Независимост от производителите на uC. Портирането на код от една FPGA архитектура на друга в почти всички случаи е транспарентно, освен ако не е решил човек сам да се набутва.

3. За множество приложения елиминиране на необходимостта от операционна система, чрез distributed multi core architecture. Компании като Ceva, Cadence и Synopsys предлагат ядра от по 100-200 kgates, достигащи лесно скорости от порядъка на 100 МHz на FPGA. Разработвал съм продукти съдържащи по 10-ина такива ядра, където всяко ядро работи върху строго специфична задача(и). Комуникацията между тях се осъществява със съобщения и много рядко със семафори и споделени памети. Real time изискванията биват покрити от елементарна софтуерна архитектура базирана на “time slicing” с “predetermined scheduling”и множество таймери.

4. Там където мощността не достига се добягва до писането на хардуерни ускорители. Нещо което с наличните High Level Synthesis (C/MATLAB to RTL) продукти като Stratus на Cadence, HDL coder на MATLAB и CyberWorkBench на NEC може да бъде постигнато ефективно и от софтуерен разработчик. Алтернативно има голяма палета на хардуерно IP, предлагана от компании като Cadence, Synopsys, Xilinx, но и безплатни такива като OpenCores. А който може, си ги дялка и сам

Имайки предвид характеристиките на модерните FPGA (цена, размер, консумация) този подход ми се струва особено атрактивен. Ще се радвам да чуя какви са мненията и настроенията по въпроса?

Ти все едно отиде на пясъчника и показа на децата един Caterpillar паркиран наблизо.

Няколко въпроса.
Колко хора участват в разработката на такава многозадачна система?
При вариантите от предишната тема става въпрос за ресурс от един човек. Който е и системен архитект и дизайнер и имплементатор и верификатор и тестер че и сервизен техник.

Колко време отнема разработката на подобна система?
С всичките верификации, валидации, тестове... При решението с uC от даден производител, това вече е направено от техен екип хора, за които тези задачи са ежедневие.

Какво захранване има една такава система? Каква мощност, размери, топлоотвеждане...

Какъв е фуутпринта върху платката на FPGA и околните карантии?

Не че имам нещо контра на това за което говориш. Но сравняваш различен клас решения. И все още разстоянието между тях е голямо независимо от

Не виждам списъка с недостатъците, но сигурно целта е да го изградим заедно?
Колкото и да са отворени отворените кор-ове все още бая народ се храни да прави "затворени" такива. Значи имат някъде място за една сергийка за платени IP-та.
Ако нещата бяха толкова розови досега само FPGA-а да са наоколо. Но не излиза сметката - един четириядрек куртекс на гигахерц е 4-5 долара, един цинк тръгва от 50-60. Не че едините са по-гладни от другите - силиция си струва пари и софт процесор излиза много по-скъп от хард такъв.
Харесваме ги, но не смеем да ги предлагаме в проекти дето могат да минат с някое мижаво микроконтролерче. Не заради друго ами както изчерпателно беше казал някой, на касата в магазина все още искат реални пари.
А и от моята камбанария се вижда само нашето село, а съм чувал че имало и други.

ФПГА за такива задачи и с корпус, който се запоява без рентген.. май са на изчезване, което си е ограничение.

Ами недостатъците са всички тези, поради които не се срещат много FPGA в ембедед проекти. Нека ги разнищим заедно

1. Цена - ако приемем, че златната среда са FPGA с малко над 100к cells и 3-4 Mbit памет, което е достатъчно да се вмъкне едно компактно, но прилично ядро, като Xtensa на Tensilica например и прилично количество хардуерни ускорители, като FFT, филтри, крипто и прочее. Това означава, че се движим актуално около 100$ на чип. В същия диапазон се намират и у-вата, който предлага около 30к cells и вграден Куртекс до 700 МХц. Ако се доверим на чичко Муур след около 5-6 години обаче се очаква да слезем под 20$ на чип. И тогава става рентабилно, особено за проекти от по 100...10к бройки

Малко по-рано тази година Microsoft намекна, че ще оборудва сървърите си, които са близо милион, с FPGA платки с цел ускоряване. Проектът е стар, с множество итерации зад себе си и нищо чудно това да са краткосрочни амбиции. Днес Xilinx оповести, че разширява 7-та серия от към low cost пазара, т.е. едноядрени Куртекси, по-малко high speed tranceiver-и и по-агресивни цени. Като добавим и покупката на Altera от Intel и производствените капацитети на последните и 5-те години от по-горе започват да изглеждат съвсем реалистично.

2. Размер - както спомена stefan63 никак не са големи. Което е както проблем, така и предимство. Но да предприемем че за производствени серии до 100 бройки е по-скоро проблем. От там нагоре става предимство. Или?

to be continued...

@Zdrav нека да дам пример. През 2009г. основахме startup с 50 човека. Финансирането беше от части от рисков капитал 2.5м евро, отчасти директно и индиректно държавно/европейско финансиране на стойност 1.5м евро. За 12 месеца създадохме продукт IP, чийто работещ прототип представихме на световно изложение. Шест месеца по-късно бяхме купени за около 24 милиона евро. Което според мен беше изключително ниска цена, имайки предвид спецификата на продукта. Оттатък в долина цената би била х10. Но това няма значение, тук сме в Европа. Като цяло екипът покриваше всички аспекти необходими на fabless компания.

1. Системно инженерство – спецификация и архитектура на продукта (HW/SW split), scalability, landing zone, etc.
2. Алгоритми – DSP, coding, cryptography, image processing, big data analysis, machine learning, combinatorial and computation math, etc…
3. Софтуер – Архитектура и разработка
4. Хардуер – Архитектура и разработка
5. Устройство – печатни платки, кутия, etc.
6. Маркетинг

Тогава ми направи следното впечатление. От тези 50 човека, 20% бих категоризирам като твърдо ядро експерти. Ако двама-трима от тях ги нямаше, щеше да стане резил. Както и става с 90% от startup-ите. След тях идват 40% high level контрибутори, които са си точно на мястото и 40% low level контрибутори, които са лесно заменими.

5 години по-късно говорим за продукт, който се е продал над 100 милиона пъти, на цена около 20-ина долара.

Ако сега бъда изправен пред проблематиката да организирам подобно начинание. Бих потърсил ниша с потенциал и бих заложил на екип от 10-20 добре подбрани експерта. А ако нишата е по-тясна, тогава размерът на екипа би могъл да бъде сведен до 5-10 човека.

Имайки предвид това, бих оспорил сравнението с деца играещи в пясъчник за нашата професия. По мои наблюдения сериозна част от хората в този форум си играят с Caterpillar-и или поне имат подходящите знания и умения. Това защо не го правят е съвсем друг въпрос, за друг вид дискусия.

Идеята за къстъм дизайн определено е малка ниша. Трябва да познаваш потенциален пазар на подобни ниши, иначе шансовете са отрицателни. За съжаление (или за щастие на други) в тая област вече има поне един много сериозен играч - Xilinx с техния цинк. От беглите ми експерименти останах много впечатлен. Точно перфектната комбинация от HW/SW, гъвкавост и т.н. Xilinx просто инвестираха страшно много в тази технология и на всичкото отгоре привлякоха и open source общество и не малко комерсиални партньори и не виждам как някой стартъп ще ги бие. Даже ако говорим за пряката им конкуренция дето я купиха твоите хора си мисля че нямат шанс. Щото то не е само да издялкаш чеповете ами си трябва и много сериозна еко-система и след това тая система да се наложи/приеме от пазара така както стана с цинк-а.
С две думи - шибана работа...

Сещам се за друг потенциален бизнес, макар че там пък си е направо откачена работа... Говоря за дизайн на периферии, щото ядра има кой да прави (АРМ, MIPS....), но за перифериите, особено дребните има мноооого какво да се желае. Но е също много работа с труден пазар, щото зависиш от много хора/фактори и т.н.

Иначе не виждам връзката на тая с тема с фуксията и с операционните системи.... Тва си е съвсем различна бира поне както аз го разбирам.

Така е, определено трябва да познаваш въпросния пазар добре. Има обаче и алтернативни ситуации, нови пазари намиращи се във фаза на възникване, както е случая с много хибридни технологии - бионика, микро реактори, дрони, невронни мрежи и т.н.

А защо не и "узрели" технологии, подлежащи на оптимизация. За втори път в рамките на няма и една година ставам свидетел как ниша, която е заета от 2-3 фирми от десетилетие бива атакувана успешно от 10-ина човека екип, изцяло на софтуерно ниво. В единият от случаите пазарът беше разучен в движение, благодарение на частични прилики с предишни проекти.

Относно Zynq - още си чакам snickerdoodlers но и аз виждам голямо бъдеще за тях, особено като паднат на 20$, а и това ще стане рано или късно. Xilinx определено направиха добър ход с платформата.
Аз в момента си играя с едно у-во наречено Myo, което перфектно пасва на комбинацията Zynq+TI WI18xx+MG92B, но това ще го бистрим в друга тема.

IP периферията е супер идея, особено за малък екип от 1-5 човека. Synopsys и Cadence са страшно агресивни и аквизицията е напълно възможна. Особено ако разработката идва от източна европа или Русия, където цената е в пъти по атрактивна от централна и западна европа, за долината да не говорим. Миналата година имах възможност да разговарям лично с Даниел Ненни по въпроса, който беше тук да разучва положението за два фонда за рискови инвестиции. Поляците работят много сериозно по подобни проекти и най-вероятно е румънците да ги последват скоро. Но там си е малко на късмет, а и всеки знае кой от кого зависи...

Темата я отворих като следствие от въпроса как може да се заобиколи необходимостта от операционни системи в ембедед приложенията и какво ги налага. Ако приемем, че това са изискванията за многозадачност и real time, то един от възможните отговори е многопроцесорната архитектура. Това разбира се не изисква директно разработката на собственo SoC IP налятo в FPGA. Но и този вариант е възможен и би осигурил независимост от производителите на uC и особен голяма гъвкавост от гледна точка на скалирането за бъдещи проекти.

Май ще трябва малко да поясня.
"Подхода" за който отвори темата сравнен с "ОС-че" за MCU е като Caterpillar за детски пясъчник.
Разбира се че има хора, фирми, които използват такъв подход, но в онази тема ставаше дума за съвсем по-ширпотреба решение.
По мое впечатление, цифровите дизайнери имат друг поглед върху нещата и света въобще. От своя страна писачите на фърмуеър друг и трети, хората които се занимават с application нивото. "ОС-чето" макар и ширпотреба дава в ръцете на хората, които мислят по-приложно, възможност да си реализират идеите. При това без да навлизат надълбоко в света на цифровия дизайн.
За такива хора говоря. Не знам защо си решил, че омаловажавам "професията".
Та... дори и да можеш да караш Caterpillar по-добре е да го паркираш извън пясъчника.

Никак... нали това обяснявам постоянно. На операционната система преди всичко трябва да се гледа като концепция за решаване на определен кръг проблеми. Дали концепцията ти е хардуерна или софтуерна няма никакво значение. Проблемите ги има по дефиниция, работата ни е да ги решаваме по един или друг начин. Е точно начина и тертипа на работа се предопределят от "операционната система" или "хардуерна система". От там и изборът на дадена система казваме, че е като женитбата щото трябва да се съобразяваш с жената/системата

Има и друг аспект - екипната работа. Ако по даден проект работят няколко калпака те малко или много трябва да имат съвместим стил на работа. Тва също идва от "системата". Верно в твоята система може всеки калпак да бачка на отделен кур по свой собствен стил. Обаче пак ще стане боза повярвай ми. Подобни бози наблюдавам в перифериите на разните производители (особено ST). Едната периферия с една организация, другата с друга. Даже в рамките на една и съща периферия се вижда как нещата са правени от различни хора и единия направил едни регистри с един тип поведение, другия други регистри с друго. Боза, пълна боза. Отвратително е да работиш щото за всяко нещо се чудиш тва аджеба как са го направили...
Като казах че има бизнес с перифериите имах точно предвид, че има нужда от "система". Набор от правила как да се конфигурират нещата, това включва подредба на регистри, тяхното поведение. Вътрешно каква да е архитектурата на всички перифери. Външно как да се интерфейсват не само от софтуера, ами и помежду си щото днешно време перифериите не са изолирани, споделят и клоци, споделят ДМА-та, шини и какво ли не. Отделно как да се правят изнесени периферии и т.н. Изобщо говоря за правила, принципи, стил на работа, не знам даже как да го нарека, но това ако го има спестява много и дава много възможности. От друга страна пък пак стигаме до проблема с "женитбата" щото ако имаш правила е редно да ги спазваш... Разбира се някъде трябва да се сложи чертата и от там нататък дизайнера да има свобода. И точно това ми харесва в цинка или по-точно средата на Xilinx. Измислили са го как да може да си правиш каквото искаш периферия, как да я интегрираш със софтуера в това число различни ОС-ве, т.е. освен IP-то с HDL-те имаш възможност и да си слагаш драйвери и код. И тва цялото върви в пакет, който някой може да вземе и с няколко клика на мишката да си го сложи в неговия проект и да го подкара заедно с други IP-та и софтуери от други хора. Точно "организацията" е уникалната, т.е. възможността всеки да прави отделни парченца от пъзела и после да може да се сглобяват безконфликтно е уникалното. На мен не веднъж ми е било мъка като трябва да взема два отделни HDL модула и да ги подкарам в нов общ проект. Хем неща дето аз съм ги писал, уж с един и същ стил и пак обикновено има проблеми щото все има разни сигнали и клоци дето не пасват и трябва да се бара тук-там.... Затова като гледам цинк-системата се радвам като малко дете на пясъчник

Преди да се говори по тая тема е редно да се изяснят някой термини и постановки, които уж са ясни и го ползваме, но се разбират по различен начин от всеки.
Усещанието ми е че това което наричате "ползване на ОС" е модел за програмиране, известен под името "procedural programming". В този случай програмирането се опитва да постигне многозадачност като предостави на програмиста възможност да стартира множество паралелни main() функции - процеси, нишки. Идеята е ясна - да могат програмисти като нас, обременени с известно количество наследство (като BASIC) да работят в проекти, където има някакви паралелно работещи задачи. За тях моделът е познат - тръгва мейна и те залупват каквото искат да правят - блокират където решат, тъй де, където има нужда. Искат нещо от някого и очакват питката да се изпече на момента. Ако не може да е на момента печката да замрази времето и за тях да изглежда все едно е станало изведнъж... Ама някой им звънил по телефона да затворят крана в банята че станало наводнение - е, не, ние чакаме питката, не може да се отклоняваме!
Малко отклонение - такъв модел на независими процеси е идеален за постановката на 100-тина студента на отдалечени терминали които работят на един централен VAX, и където целта е те да са изолирани и да си правят задачите. Предполагам оттам идват корените на тези концепции.
Разликата с ембедед системите е че същия модел се прилага по аналогия върху друг проблем - нишки които трябва да изпълняват отделни части (отделни приоритети) от комплексна свързана задача. Там "студентите" изведнъж се оказват в небрано лозе - трябва заедно, като екип, да направят един проект. За да стане това се налага да почнат да си комуникират помежду си. Това въвежда в картинката синхронизационните примитиви. Само че студентите вече са свикнали да пишат блокиращо и очакват някой да им осигури API с което да се чувстват комфортно. По-точно в началото почват да си подвикват между компютрите, да си оставят листчета, да се сърдят че А слуша Б ама не чува Ц. И Ц чака Б който чака А, който чака Ц и айде за другата сесия.
Интелигентни хора са успели да преборят проблема и да намерят начин това да се случва - с цената на допълнителен код.
В тази постановка всяка нишка (всеки от main()-овете) се оказва разделен на отделни сегменти. Границите между тези сегменти са ясно различими - това са различните блокиращи викания които стигат до чакане, т.е. до някоя от синхронизационните примитиви. Между границите (в сегментите) се намират парцали код, които са реалната работа, свършена от този модул(клас, обект, компонент). Между сегментите в които се върши работа се намира "чакане" - някой от някъде да ни каже да свършим следващия сегмент.

Алтернативите са повече от една, но да кажем най-общо това му викат "event programming" или нещо подобно. Най-популярният модел е ROOMS и той е база за UML statecharts.
https://en.wikipedia.org/wiki/Real-Time_Object-Oriented_Modeling
Както красиво са го казали там става и се ползва за
Там същите сегменти от код се ползват като реакция на събитие (онова дето ни буди в другия модел). В зависимост от нашето състояние реакцията на едно и също събитие може да се променя (ако сме в състояние disabled игнорираме събитието старт, но ако сме в enabled почва нещо).
Така модела се обръща и водещото там ставата самите събития. Приоритетите, които преди са били характеристика на нишките, сега се явяват характеристика на събитието. Например събитието "OnPinChange()" има приоритет 20, събитието "OnTimerTick()" има 40 и т.н.
Този модел е много близък до модела, по който хардуера, за който пишем, работи. В микроконтролера всичко е събития, ама там му викаме exception или просто interrupt. Това е начинът по който хардуера ни казва че има работа - дошли са данни, сменило се е нивото на пин, изтекло е някакво време. Този модел, бидейки реализиран в хардуера, има естествени лимитации - брой на векторите и прекъсванията, брой на приоритетите, възможност или невъзможност за reentrancy и preemption.
Например CAN контролера може да има само едно прекъсване, който да значи "нещо стана". Оттам това може да "приехме нещо", или "завърши предаването на нещо". Приемането на нещо може да е "нещо важно" или "нещо маловажно". Оттам възможностите за разклоняване са многобройни и в някой ситуации може да се наложи някой съобщения да се обработват с висок приоритет, а други с нисък. И това не може да се реши от хардуера под формата на различни вектори. Тогава идва нуждата от scheduler - някакъв код, който да ни позволи да имаме виртуални вектори и множество приоритети. Това си е част и от "нормалните" ОС-ове - да пуснат парче код според това кой на кого е батко.
Та зад тези събития - дали директно на хардуерните вектори, или на виртуалните (или софтуерни прекъсвания) стоят тези парчета код, дето им викаме сегменти. Те са run-to-an-end, не викат блокиращи сървиси (дежавю с изискванията за interrupt handler?) и вършат малка част от работата, която в другия модел е била в големия thread_x_main().

Така де, стана голямо изложение, но се чувствам длъжен да споделя по темата имайки предвид че автора обоснова създаването и донякъде с мойта особа
Но за да има конструктивна дискусия ми се струва важно да уточним за какво точно говорим или спорим. Много хора под думата ОС биха разпознали цяла софтуерна платформа с все драйвер, протоколни стекове, файлови системи и т.н.
А въпросът с женитбата е важен и интересен. Макар и утопично, не е ли ценно да търсим начин да имаме ползите от женитбата без да се обвързване? По аналогия можем да кажем бракът е нужен за да имаме изгодата. Само че някой завидни индивиди ги имат тия ползи и без халката - дали не знаят нещо повече?

Та моята теза е че при определени постановки и организация на кода е съвсем реално да се минимизират зависимостите и да се избегнат негативите от брака. Пътят за постигане е ясен - да пишем код така че да изкореним зависимостите - не само от хардуера (платформата), но и от други софтуерни компоненти.
За пример - ако не ползваме част от услугите на ОС-a (мутекси примерно) няма да трябва да мигрираме. То ясно че можем да ги скрием зад абстракция, но това пак иска тази абстракция някой да я имплементира за всеки нов компонент (ОС да кажем, понеже и тя е просто компонент който ползваме или не, сменяме или да).
Един от примерите, който ми идва в момента, е разликата между "printf" и "snprintf" - в аспекта кое колко скрити зависимости има и на колко други неща разчита за да свърши работата. И поради колко причини може да се издъни.

Моите търсения по тази линията датират от няколко години само, но имам някаква идея. Ще ми е много полезно да се развие дискусия по темата.

Точно така както си го написал не е просто утопично, ами си е оксиморон... Във всяка една работа (без значение каква) с времето се учиш, както се казва трупаш "know-how". Отделно събираш/купуваш или си правиш подходящите инструменти. На всичкото това аз му викам "женитба", защото ако пак ти се наложи да свършиш подобно нещо, най-вероятно ще използваш вече натрупаните знания и инструменти. В това се състои евентуалната полза от "женитбата". Разбира се, може и да е недостатък защото може и да има друг начин да се свърши работата, други инструменти... Но ако си вложил време или пари в едните, трудно ще ги изхвърлиш, освен ако другите не са мноооо по-добри.
В случая за да подкараш един ОС трябва да го разучиш, може да се наложи да портваш това-онова, да си дописваш библиотечки и т.н. Направиш ли го - вече си женен. За да имаш полза обаче трябва да може да го използваш пак, а това е "обвързване". Нали не е задължително всичко да стане с copy&paste, тук имам предвид повече правилата, техниките, триковете... Тези правила и техники (евентуално) дават ползи ако ги прилагаш, ако не ги спазваш/прилгаш няма полза от тях.

Тъй де, задълбаваме излишно... Според мен няма какво да се притесняваме от женитбите, щото те са неизбежни. По-скоро трябва добре да си опичаме акъла преди олтара и евентуално навреме да сменяме булката

Аз съм "за" да оставим общите приказки, но много ми се иска да се завърти дискусия и да споделим опит и ... мечти.

gicho, звучиш като младеж дето са го нападнали девойките и се чуди коя да избере

Ако ще избираш ОС сподели вариантите и мечтите си, за нас ще е интересно, но не очаквай друг да ти избере жената и дали бракът ти е да е по сметка или по любоф...

Аз с избора на ОС проблеми нямам - гледам да нямам прекалено много допирни точки.
Разбирам и липсата на интерес - работата ни натиска и на никой не му разбутват ла*ната. За съжаление проблемът е по-скоро академичен и в реална ситуация, докато се копае по проекти, трудно остава време и трудно се оправдават рисковете.