И аз нещо не мога да се ориентирам в софтуера, който ни трябва. Гледам разни клипчета за Вивалдото, но не схващам нещата ...
Вероятно за човек, който е наясно с дев. туловете и линукса ще му е много лесно да сглоби необходимата функционалност на базата на тези китчета, но аз не съм този човек (за мое съжаление).

В крайна сметка какво ни трябва?
Трябва ни FPGA, което да можем да преконфигурираме както си искаме. То трябва да е закачено към някаква RAM памет (колкото повече - толкова по-добре), като в FPGA-то трябва да е реализирана функционалност тази RAM да е с двоен достъп. т.е. микроконтролер закачен също към ФПГА-то да може да я чете ("dual access ram" мисля се казваше - рам с двоен достъп). Трябва ни някакъв процесор, който да чете през ФПГА-то данните от РАМ-а и да ги стрийнмва към PC-то (галванично развързано примерно през 100MBit етернет). T.e.функциите на проца ще са да конфигурира ФПГА-то, и след това като има някакви данни в рам-а да ги преточи към PC-то възножно най бързо.
Цялата функционалност по декодирането на SWO-то, обработката на тригерите за логическия анализатор, "компресирането" на данните, писането в RAM-a (организиран като цикличен буфер FIFO) и арбитрирането на достъпа до RAM-а между ЦПУ-то и логера (ще трябва някакво буфериране да има в фпга-то докъто проца аксесва RAM-a) ще е в ФПГА-то.

Така дев. средата ще е само за ФПГА и по никакъв начин няма да е намесен Линукс и др. бози и куп неизвестни.
В микроконтролера вече може да има някакъв малък ОС, който да клати етернета и да стриймва данните прочетени по паралелен даннов бъс (поне 16 битов) от RAM-a (през ФПГА-то).

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

Да не говорим, че подобно реализиране евентуално ще е доста по-близко до комерсиален продукт, спрямо вариант с готов дев. борд ... (за момента не гледам в такава посока)

Ако си сложим някакво "разумно" ограничение - например семплиране до 100MHz, (както по-горе писах лог, анализатор едва ли ще се използва за логване на по-бързи сигнали, поради неизвестните (паразитни капацитети, DC утечки, отразени сигнали и шумове ), които сондата ще вкара в линията, която "гледаме" ) и RAM-а е закачен на поне 16 (32 още по-добре) битова шина, то няма да пишем в него с по-висока честота от може би 100 (200) МХз.
(Е, разбира се вътрешно в ФПГА-то може да семплираме SWO-то на доста по-висока честота - примерно поне 3-4 пъти по-висока от бит рейтта му ...)

П.П.
ФПГА-то ще е поне Спартан-6 в лесен за "хоби" запояване корпус ...

Емо, май не четеш...
Няма разумна опция за фпга с външен РАМ. Излиза по-скъпо, по-трудно и много по-кофти, отколкото варианта с цинк. Просто забрави!

Вариантите са:
1. mcu+fpga, като през mcu-ти се стриймват не повече от 10-20MB/s реално време към РС. И допълнително фпга-то може да логва още до към 100MB/s към SD-карти.
2. Китайската марийка (освен ако не смятате че аналоговщините на петята си струват 200лв отгоре).

3. Вариантът на emilvtc + външно phy за ethernet. Има свободни mac контролери за fpga-то и някакъв дребен mcu да конфигурира ip адреса. Така няма да има нужда големият поток от данни да минава през процесор.

НЕ!

Аз спирам. Както казах, лично нямам време да участвам с труд, така, че нямам право да давам наклон. Ако решите да е цинк, понеже тоя вариант ми допада като концепция, съм навит да купя борда на човека който ще го прави, като слагам лимит до 400Е, без да искам от него нещо като краен резултат, просто да споделя какво е постигнал (каквото и да е то).

И просто последно, аз цялостно устройството го виждам като:

1. лог. анализатор с функции за шпиониране на серийни интерфейси.
2. SWO трейс (още не мога да си изчистя в главата пълната му функционалност).
3. JTAG към АРМ (това даже според мен е излишно)
3. Дву канален осцилоскоп нещо от сорта на 10Mhz лента, 10 - 12 бита би било абсолютно достатъчно и като цяло всичко това е пожелателно.
4. Сигнал генератор, също пожелателно.

Последните две, ако не са базирани на марийката, според мен са немислими да се случат, защото има много ПЦ софтуер за изкопаване.

Вие хубаво си хортувате, но не разбрах, кои са марийка, пенка и т.н.?
Питането ми е съвсем сериозно. Дайте някакъв линк към тия бордове, че ми стана интересно.

+1

Марийка щото името на фирмата е MYIR и ми звучи като марийка

Накратко платка с Zynq, 1GB RAM, 2* 8o pin 1.27 хедърчета

Червената Петя ... името може би идва от тая мома

Също Zynq, 512M Ram, 2 * 125MSpsp 14-bit ADC+DAC + разни приложения за използване като осцилоскоп, спектр. анализатор и т.н.

Емо, Цецо...

Опитвам се да обобщя... Изглежда като че ли и двамата не се интересувате от трейс на инструкциите. Емо всъшност го иска, ама мисли да го прави с трейс по стимулите, което е тъпо.
Аз пак ще кажа моето мнение, че текстовия трейс е супер ценно нещо, но в момента в който го получите ще поискате и пълния трейс. Казвам го на база опит.

Както и да е... важното за тоя проект е да се прецени скоростите на обмен и/или запис. От една страна цинк решенията позволяват супер високи скорости, но са с ограничена продължителност, колкото се събере в SDRAM-a. Примерно петята ако пуснат и 4-те аналоговщите те правят 1GB/s, но те ги пускат в кръгови буфери дето постоянно превъртат. Не става да направиш дълъг запис с тия скорости. Няма къде и как...
Ние обаче нямаме полза от превъртанията. Трябва данните или да пратим към РС в реално време или да направим лог, който после да се прати. За лога цинка не ни помага особено, защото няма чак толкова RAM. Може би при Петята ще може да се заделят 512MB, но при максимална скорост от 100MB/s тва ще го пълни за 5 секунди и сме до там.
За връзката с PC предимството на цинка е гигабита, но и това доколко е предимство е спорно... Така или иначе повечето РС-та клякат като ги натовариш с повече от 30MB/s, което се постига и с бързото USB.

Не знам... и аз вече се омотовам. Според мен трябва да се постига стрийм от порядъка поне 10-30MB/s, отделно поне 100MB/s трябва да може да се помнят дали в SDRAM или SD карти.
Това е постижимо и без цинк. Цинка просто може малко повече, той всъщност може много повече ама трябва да си поиграем повече и цената ще е много повече от тия платки....

Ами прав си, не мисля за инструкшън трейс, щото ти навремето някъде написа, че няма как да се случи през SWO. И понеже не съм ползвал такова нещо така или иначе, не напъвам в тая посока.

Реално ако имам 5 секунди инструкшън трейс за мен е направо чудно, щото сега нямам нищо. Реално едни 5 секунди в кръгов буфер си звучат съвсем примамливо. То и секунда стига в 90% от случаите които аз си представям (гонене на ексепшъни ).

Работил съм с итински вътрешносхемен емулатор на Фуджитсу с процове 16LX и знам за "благините" на истински трейс. Налагло ми се е 2-3 пъти да се заравям дълбоко в него, но не е никак приятна работа. Преравяш огромни логове докъто намериш момента, който теинтересува (отнема много време и нерви) и след това започваш да го анализираш... Цялото инфо е налично, но кушията е голяма...
Та както казах за истински трейс през няколко пина не ми се мисли, най-малкото защото ги нямам налични в моите проекти. Обикновено имам шернати пиное между перифрии... Също имам периферия (обикновено цифрови входове от ключета, джъмпери или dnp пул ъп и даун резитори) и на jtag пиновете...
Относно текстовия трейс - явно не съм обяснил добре. Ще има такъв, но опциите ще са две.
Първата е със заместване.
Имам 32 отделни порта в swo-то. Да кажем, че заделям 24 от тях (чисто условно) -по един за всеки таск. За всеки таск си дефинирам до 128 контролни точки (стимули) в еднa enum тип променлива(номера на всяка контролна точка е 7битово число). В същи enum копираме променливите още веднъж започвайки от номер 128, като добавяме в имената им ткст "_data". Целта е да можем да изведем през swo_то само номера на контролната точка (в двубайтов фрейм през swo_то) или да изведем същия номер на контролна точка (младшите7 бита) + стойност на променлива/променливи (до 3 8битови променливи/една 16 бит променлива или една 8 бит +една 16 бит променлива в един swo фрейм).
Така за всяка контролна точка с номер над 128 ще знаем, че следват даннова стойност/стойности на променлива/променливи, които нашата терминална програма ще трябва да интерпретира и изведе в конзолата по съответен наин.

В терминалната РС програма ще трябва да се опишат за всеки порт стрингове за всяка контролна точка(от 0 до 255), както и как да се интерпртират данните за точките с номера над 128.
Например проца поства по swo двубайтов фрейм (port 3, bytes 2 + даннов байт 5). Терминалната програма като приеме този фрейм ще види, че той идва по порт 3 ище извежда в конзола 3, вижда, че фрейма съдържа един даннов байт, който е номера на контролната точка ( в слчая този номер ще е <128). Замества този номер със произволно дълъг текстов стринг извлечен от кофиг файла на терминала за съответния порт и го извежда на отделен ред в конзола та - в случая конзола 3.
Т.е. с едно писане от страна на проца в swo порт 3 на еднобайтов номер на контролната точка, swo-то ще изведе двубайтов фрейм, който ще се предаде максимално бързо за няколко микросекунди например (в зависимост от текущия клок на проца и избрания прескелър), като това предаване НЯМА да забави хода на изпълнение на програмата ни.
Ако трябва да изведем например и стойността на дадена 16 битоа променлива например, то трбва да изведем в съответен порт номер на контролна точка (над 128) и съответната двубайтова стойност. Това в нашата мцу програма се свежда до писане ана една 32битова стойност в съответен swo порт. Например в порт 2пишем стойност 0х82 00 08. 00, където 0х82 е номера на контролната точка, 0х0008 е стойността на променливата, а последния байт 0х00 е падинг допълващ до 32 битова стойност.
Та през swo- то в случая ще се изведе автоматично без забавяне на хода на програмата ни 4 байтов фрейм (байт 1 съдържа номер на порт 2 и брой байтове =4, байтове 2,3и 4 са 0х82 00 08).
Терминалната ни прорма като приеме този фрейм ще види, че той е по пот 2 и ще го изведе в конзола 2, ще види, че номера на контролната точка е х82 и ще замести този номер със съответстващия стрингот конфиг файла за съответния порт, ще види, че номера на стринга е над 128 и ще знае, че трябва да изведе и данни. Инфо за вида на данните за съответната контролна точка за дадения порт ще се извлече от конфигурационния файл и след стринга ще изведе стойност след стринга примерно в хекс формат 0х0008.

За чисто стрнгово инфо можем да използваме няколко от оставащите ни swo портове. Например за таск 1 ще използваме порт 25, а за таск 3 порт 26 ( за таск 2 например няма да ни трябва извеждане на стринг)
В конфига на терминалната ни програма ще укажем в конзола 1 да се извеждат и интерпретират фреймовете от портове 1 и 25, в конзола 2фреймовете от порт 2, в конзола 3 фреймовете от портове3 и 26 и т.н.

Естествено при извеждане на стрингове от мцу-то ще се забавя изпълнението на програмата ни в дадения таск, защото преди да запишем следващите до 4 байта от стринга в дадения порт (25или 26 в случая) ще трябва да изчакваме предаването на предишните такива през swo- то. Т.е. НЕ трябва да се прекалява с извеждането на такъв вид инфо от проца

Относно данните, които трябва да се пазят в РАМ, като че ли няма да са толкова много при наличие на компресия.
Данните по swo линията ще се стримват към РСто като декодирани данни, а не като семплирана стойност, така че няма да са много.
Лог. сигнали при наличие на компресия ще изискват РАМ за буфериране преди предаването им към РСто само в моментите на активност(клатене на пиновете), която не е постоянна. Е, когато активността (клатенето на пиновете) е нонстоп и е с висока честота, въпреки компресията ще напълном РАМа относително бързо , но колкото -толкова.
Относно аналоговия канал/канали, те ще се семплират да кажем максимално с 1 мегасемпъл в секунда, така че трафика от тях няма да е толкова голям

Пълно щастие няма...

Емо, аз пък работя с АРМ вече доста години и винаги съм ползвал текстов трейс, още от времето на ARM7 с DCC по JTAG. По-удобно от текста няма. И аз съм правил разни трикове, но след като си направих всичко за читав текст, дори и не искам да си помислям за нещо друго.
Като (ако) стигнем до нещо работещо ще ти обясня как да подкараш чист текст, а ти после прави какввото искаш.
Иначе продължаваш да говориш за RAM... Това значи, че се ориентираш към цинк?
Аз колкото повече разсъждавам, толкова повече се убеждавам, че варианта mcu+fpga е по-подходящ.

Кой проц и кое фпга мислиш, че ще са подходящи?

Ако има паралелен бъс между проца и фпга-то (16 или 32 битов) и ако проца има повечко вътрешна РАМ веротно ще стне за не много бързо променящи се сигнали за продължителен период от реме, но лог. анализатора със сигурност трябва да е с компресирани данни. Евентуално може да се организира и малък ФИФО буфер във фпга-то ако има ресурс.
Проца ще е добре ако е с етернет и USB.

не ти трябва широк бъс, а PCIe