Делаем анти-штеуд

А материнские платы уже есть? Или надо разводить и делать?

Материнские платы для J-CORE?

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

Почему выбор х86?

Мимикрия шлюпки под титаник.

давай я тебе расскажу про «малое»

дело в том, что малое, которое можно себе позволить в моем положении - это xilinx easy path например. то есть то же FPGA просто без лишних тормозов. но проблема лять не в тормозах а в том, что на FPGA не сделать ассоциативную память. ArriaGX имеет блоки по 64к ОЗУ но и то она стоит конских денег и блок там один кажется. на практике я заявляю что сделать чип по 1000нм CMOS + взять кэш L2 от 100мгц мамок дешевле чем на FPGA делать.

Зачем это все? Мы же вчера узнали про скорый конец.

Давай сперва проясним задачу: ты хочешь сделать свою железку, которая может исполнять существующий х86 код не сильно хуже, чем оригинальная от интела? Или ты хочешь исполнять х86 код быстрее, чем интел?
Про несоответствие адресов трансляций и исходных команд понятно, в большинстве существующих систем с динамической бинарной трансляцией этими переходами занимается рантайм и соответствующее железо(ну, оно довольно очевидно)
Как насчет небольшого пруф оф концепта?
Например, выберем сабсет х86 команд, на которых напишем простенькую программку(сложение в цикле), потом на верилоге напишем кусок ядра с х86 архитектурой, на котором эта программка сможет исполняться, а потом можно попробовать твой подход?

а это мое хобби. ну вот просто мне это нравится и я буду это делать пока есть возможность.

Может, сперва стоит поставить функциональность во главу угла, а потом уже идти за скоростью? Тем более для потактовых симуляций и времянок можно использовать верилятор. Оно, конечно, не фпга по скорости, зато там можно сэмулировать, что хочешь(но синхронное).

ты хочешь сделать свою железку, которая может исполнять существующий х86 код не сильно хуже

более того я утверждаю, что моя железка сможет выполнять х86 код быстрее чем х86 при меньшей частоте. как - сиё мой know-how. кстати если его описать, то все хлопнут ладонью по лбу и скажут вау, а что всё было настолько просто.

Это справедливо для любого х86 кода или какого-то сабсета? Т.е. легаси говно вс авх512.
Я вполне допускаю, что это возможно, но ни один из известных мне проектов в этом направлении не взлетел, тк очень уж много корнеркейсов вылезает.

Опенриск свое отжил, увы, в то время как риск5 набирает обороты.

Не сказал бы, что отжил. Стагнирует - да. Отжил - ещё нет.

Производство - не такая большая сложность, как создание нужных микросхем, которые будут покупать.

Весь вопрос в целевой аудитории. А ЦА тут - люди, которые хотят железо без зондов, а также энтузиасты, которым интересно поковыряться в архитектуре от сообщества для сообщества. Остаётся узнать, сколько таких людей и сколько денег каждый готов выложить за такой процессор с материнской платой.

Те результат и не планируется?

Нахрен кэш на данном этапе, если речь про FPGA. Сейчас нужно решение, которое можно распиарить в сообществе и которое сообщество подхватит и не бросит вскоре. Тогда можно будет и процессор производить.

Может кулер лучше?

Для QorIQ. Мне интересно знать, насколько сейчас этот вариант готов для ознакомления и что нужно доделать для получения десктопа и ноутбука.

А материнские платы уже есть? Или надо разводить и делать?

Если для QorIQ, то есть девборда для T4240 от самих NXP с лейаутом и гербером:

https://www.nxp.com/support/developer-resources/software-development-tools/qo...

https://www.nxp.com/webapp/Download?colCode=T4240RDB_DESIGNFILES

Все их девбоорды есть на маузере: https://ru.mouser.com/Search/Refine.aspx?Keyword=t4240

На QorIQ P5 (но это предыдущее поколение микроархитектуры) есть готовая ATX плата:

http://www.amigaos.net/hardware/133/amigaone-x5000

на QorIQ T2 ноутбук собирались делать:

https://www.powerpc-notebook.org/en/

Для всего семейства есть открытые примеры плат от самих NXP на сайте, доступны для скачки анонимами (Gerber, PDF с советами, все прочее).

+ любители пилят помаленьку (см. предыдущий коммент).

дело в том, что малое, которое можно себе позволить в моем положении - это xilinx easy path например. то есть то же FPGA просто без лишних тормозов.

Так. Уже хорошо. Линукс с консолью, базовыми иксами (X-терминал сделать как демонстрацию) и Emacs на таком компьютере гонять нормально можно?

но проблема лять не в тормозах а в том, что на FPGA не сделать ассоциативную память.

Так в кэше или в желании сделать транслятор проблема?

Все их девборды и процессоры есть на маузере: https://ru.mouser.com/

Во главу угла надо поставить не функциональность и скорость, а саму возможность, причём не как возможность как таковую, а продемонстрировать и предоставить. ТС этого не понимает. Он затирает про зонды от штеуда, но идёт не в том направлении.

смотри в чем проблема.

если ты хочешь сделать чип, то во главу угла становится экономика. экономика, а не скорость, или функциональность.

экономика чипа состоит из ряда факторов, главными в которых являются величины NRE и RE. Первая говорит нам о затратах на маску. 180нм медь это тот минимум куда мы еще можем нырнуть. 130нм медь - это уже ок. 90нм - это хорошо. 65 или 45 - мы объявляем о победе. ибо см ниже.

RE - это затраты, пропорциональные объему производства. Они зависят главным образом от следующих факторов:

1) площадь одного кристалла. чем больше площадь, тем больше дефектов и тем меньше yield - выход годных чипов с пластины. Я рассчитывал экономическую эффективность для 90нм с площадью 7х7мм и 10х10мм относительно микроконтроллеров. То есть изначально была идея такая - мы делаем кристалл, который можно использовать как быстрый микроконтроллер, а можно из них собрать по принципу «много чипов на подложке» лютый GPU. Дальше увеличивать площадь бесполезно - yield падает очень быстро.

далее, я 6 лет придумывал АЛУ. 6 лет - потому что АЛУ это площадь. Площадь это убийца yieldа. Я разработал улучшенный алгоритм бута(booth), способ синхронизации устойчивый к jitter, структуру ALU позволяющие на одним блоках считать как float/double, так и int/mmx

На FPGA это класть уже бесполезно. Кроме того, verilator не работает в некоторых интересных случаях. Например, у меня есть конвейерная SRAM. Как мне оценить её параметры? От них зависит между прочим задержка между стадиями конвейера. Верилятор этого не делает. Поэтому я сижу и пишу симулятор чипов, где ты не просто верилог пишешь, а пишешь также «генераторы» блоков, размещаешь их по layout. Задача сложнее.

Наконец, сам способ синхронизации, нечувтсвительный к jitter исключает саму основу верилога. Динамическая логика по сути. Ты на верилоге писать убьёшься.

На последнем ORCONF не было ни одного доклада про опенриск. Окей, они наконец допинали многоядерность и запушили ее в ядро, но кому от этого легче? Я, например, не вижу смысла туда еще что-либо вливать.
Пытались уже собрать денег на тейпаут опнриска, не собрали. К тому же толку от пары девборд с соками, если на них ничего не делают?
Вот на риск5 сделали limeSDR, например. Ну и вообще судя по последним риск5 воркшопам, народ в индустрии подхватывает его: WD планирует использовать риск5 в своих хардах, нвидия использует его в своих чипах и тд.

Чувак затирает про ноу-хау, которое никому не покажет. То есть либо мы ничего не увидим, либо он хочет патенты-проприетарщину-все такое. Или я наговариваю?

Спасибо. Это то, что я и хотел узнать. Значит сейчас имеет смысл просто двигаться на PowerPC в виде QorIQ, обустраиваться, набираться опыта в переезде между архитектурами и доведения решений до ума, и после этого уже можно будет что-то своё делать.

2) далее. пусть я сделал таки layout и мои тесты показали что скорость вроде достаточна. а теперь поговорим о компиляторе.

я утверждаю, что моя железка сможет выполнять х86 код быстрее чем х86 при меньшей частоте. как - сиё мой know-how.

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

я ведь хочу совсем немногого: я хочу иметь возможность видеть конвейер, иметь возможность выделить часть проводов, и по их состоянию понять каков семантически сигнал на них. я хочу иметь возможность запускать программу с точками останова, сохранения и возобновления чтобы понимать, где мой процессор обосрался и что надо исправить. я хочу иметь возможность удобно(даже лучше чем в существующих отладчиках) инспектировать данные программы.

есть такой софт? я не видел.

я не хочу патенты. мне просто писать очень долго.

https://opencores.org/projects

спасибо за ссылку, кэп. куда дальше мне там смотреть?

То есть либо мы ничего не увидим

Вот это. Даже если он это реализует.

100mm^2 по 90нм это ж какой микроконтроллер?
Для примера я взял picoRV32 ядро и разложил его по tsmc180 элементам, получил площадь самих элементов порядка 125000мкм^2(мало, в общем). Конечно, это так себе аргумент, тк это ядро делалось специально под оптимизацию размера.
Я согласен про экономику, она во главе, но есть поправки:
Представим, что ты сделал крутой чип, но кто у тебя его купит просто так?
Да, верилятор многие вещи не поддерживает, но для ряда задач он очень классный.
У нас с тобой разные целеполагания: я хочу сделать какой-нибудь кристалл(с процессором, конечно), который был бы кому-то нужен, чтобы усилия и ресурсы не были потрачены напрасно. Ты же сразу хочешь с места в карьер, насколько я понимаю. Твой вариант гораздо сложнее.

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

Понятное дело, что открытого софта нет. Его практически нет для простого чипдизайна, не говоря уж про твои кастомные нужды. Тот коммерческий софт, который есть в индустрии, тоже не рассчитан на твои требования, никто с этим не спорит.
Ты не хочешь сначала иметь функциональную модель, на ней отладиться и продемонстрировать(не мне), что твой подход работает, а потом уже идти за сайкл пресайс/железом?

Глупый вопрос, но все же: ты ведь знаешь про макрооп фьюжн в железе?

offtopic, но такой вопрос возник. А насколько сложно создать OpenSource SoC типа Texas Instruments DaVinci DM368?

http://www.ti.com/product/TMS320DM368/technicaldocuments

http://www.ti.com/product/TMS320DM355/description

Кмк в основном подобные однокристальные системы крайне закрыты, кроме TI я и не знаю, кто еще доступен для радиолюбителей с бордами на маузере и документацией, вроде никого нет.

В качестве ядер можно использовать либо RISC-V либо ARM920T, вроде бы патенты истекают или истекли. В качестве медиакодера пока придется обойтись MPEG2/MPEG4. ISP еще очень важно разработать, но, может быть патенты на соответствующие алгоритмы уже заекспайрились или можно как-то обойти.

DM355 производилась на 90 нм оборудовании, умела MPEG4 в 720p разрешении и стоила 10$. Реально такое повторить «радиолюбителям» на основе доступных ядер + свои доработки в видеокодере и ISP? И заказать потом?

offtopic, но такой вопрос возник. А насколько сложно создать OpenSource SoC типа Texas Instruments DaVinci DM368?

Всё зависит от того, какую периферию пихать туда.

DM355 производилась на 90 нм оборудовании, умела MPEG4 в 720p разрешении и стоила 10$.

Сдаётся мне, тут уже будут решать объёмы производства и поставок. Для этого уже нужна коммерческая компания, которая возьмётся за это дело. А ещё нужны целевая аудитория, из которой предыдущее и будет складываться, а следовательно численность ЦА и будет определять стоимость.

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

Сдаётся мне, тут уже будут решать объёмы производства и поставок.

Цену я зря указал, понятно что мелкосерийное изделие будет очень дорогое. Просто выше в треде прозвучала какая-то совсем доступная цена в 3000$ для 130нм за десяток микросхем, если я правильно понял. А целевая аудитория - все те, кто хочет собрать фото/видеокамеру.

На TI чипе много таких проектов было. Типа: http://webcache.googleusercontent.com/search?q=cache:wL6zhL_vmngJ:designsomet...

Но постепенно они уходят, например, designsomething.org уже недоступен, хотя в кеше гугла еще есть.

Я согласен с Quasar.
Если рассматривать сок, как конструктор, для которого у тебя есть все нужные части, то собрать его и просимулировать достаточно просто. Затем физдизайн и в печку.
Сложности начинаются с патентами, про них я ничего не могу сказать. Если требуется разработка собственного блока декодера, это головная боль: помимо написания и верификации блока, придется еще дружить его с софтом.
К тому же эта микруха предполагает на себе линукс или нет? Если добавляется линукс, добавляется еще боли, в сравнении с микроконтроллерными ядрами.
Такой цены точно добиться не выйдет, тк объемы не те.

5к за 180нм и десяток откорпусированных.

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

Парни из беркли так и делают с Паттерсоном наперевес.

К тому же эта микруха предполагает на себе линукс или нет? Если добавляется линукс, добавляется еще боли, в сравнении с микроконтроллерными ядрами.

Да, у того, что я «хочу» «повторить» SDK с Linux.

Такой цены точно добиться не выйдет, тк объемы не те.

Цену я зря сказал, меня устроит и 3000$ за 10 штук, если я верно тебя понял. Я такое могу и сам скопить даже один.

Если требуется разработка собственного блока декодера,

Ну какие-то vhdl с кодерами по интернету валяются, начать есть с чего. Насколько они хороши, конечно, вопрос. Меня больше другой блок беспокоит - Image Signal Prcoessor (ISP). Готового ничего нет, а алгоритмы там не факт, что тривиальны.

3-5к баксов это вполне подъемная сумма, да.
Какие-то блоки процессинга наверняка есть, но вопрос в патентах и наличии нужных блоков. Я бы в этом случае сперва озаботился блоками обработки(разработать свой или найти готовый), а уж воткнуть ядро процессора и остальное на шину это просто.

Спасибо за информацию, не верю, что смогу довести до производства, но в качестве «морковки» эта информация действует весьма стимулирующе, значит имеет смысл делать. MPEG4, по идее, через 2-3 года станет patent-free, да и патенты на всякие ISP в ранних цифрозеркалках на 180-нм чипах Fujitsu MB56xx во временном горизонте разработки проекта будут истекать. Интересно заняться FPGA-версией.

Тебе никто не мешает, например, сесть и написать нужный тебе блок, забив на патенты. Пока ты его пишешь и тестируешь, патенты же протухнут, например. К тому же, думаю, если ты будешь ниже радаров(ака не продавать свои чипы), то и про патенты могут и не вспомнить.

Посмотри в сторону верилятора, он генерит ц++ объект. Этот объект можно обернуть в питон и гонять как хочешь там, или, например, импортировать в матлаб. Для обработки изображений вроде самое то?
Плюс есть дешевая и классная борда Pynq Z1 от дигилента, посмотри.

Угу, до чего прогресс дошел. Круто, остается только дело сделать.

так подход-то я проверил. просто данные в АЛУ доставлять уже приходится на QDR-скорости. насколько я знаю, сама память 128х36 бит может работать на очень большой частоте, плюс мы еще внутри её конвееризуем. но насколько? дело в том, что этот момент на декодер влияет.

про макрооп фьюжн в железе

да я в курсе этого зла. ну то есть это не зло для мну вообще. зло это для декодера вышеописанного «псевдо-х86» где байт за два идет. ибо хоть битов и вдвое больше, но надо следить чтоб jmp не прилетел посередине оптимизированной последовательности. а это фу.

способ синхронизации устойчивый к jitter

так у тебя асинхронный дизайн что-ли? не синхронный RTL? ты же про propagation delay и аналоговый jitter?

Меня больше другой блок беспокоит - Image Signal Prcoessor (ISP)

А его нельзя заменить на софт, который крутится на проце общего назначения? ну вплоть до бинаря ffmpeg поверх uclinux ?

Я как-то смотрел, можно ли что-то сделать с моей новой днищекамерой - даже не понял, что там за SoC стоит .... (хотел понять , нет ли возможности увеличить частоту оцифровки звука)

Нашёл SPCA533A User Guide от 2002, необрадовало разрешение, но потом подумалось, что большое изображение можно на 2-4 куска разбить. Но в целом уловил сходство между новыми SPCA и вот этим....

А его нельзя заменить на софт, который крутится на проце общего назначения?

Можно, но для этих целей обычно все-таки специализированный процессор используется (как _тут_) или Ip block: http://www.ti.com/lit/pdf/sprufg8

Обычный процессор будет много жрать электричества.

ну вплоть до бинаря ffmpeg поверх uclinux

ffmpeg же не про ISP (хотя всех его фильтров и фич я не знаю, может там вообще все есть), а в первую очередь про компрессию данных в MPEG, а это без аппаратного блока будет много есть электричества и сильно тормозить.

Но, в тех же TI аппаратный компрессор - это просто блок сопроцессоров (ME, IDT etc) для ихнего DSP.

Нашёл SPCA533A User Guide от 2002

Посмотрю, очень интересно как устроены подобные SoC.

В принципе стадо параллельных «Cortex-M4» или что там сейчас доступно open source и модно + какие-то сопроцессоры, возможно, то что нужно.