Зато есть выбор: нужны коммуникации - используешь Linux, нужен доступ к железу - SOS. Конфигурация описанная тобою это позволяет.Сообщение от heroy
Зато есть выбор: нужны коммуникации - используешь Linux, нужен доступ к железу - SOS. Конфигурация описанная тобою это позволяет.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Почему?
Что подразумевается под архитектурой ПЛИС и почему "это" так важно? По поводу средств разработки: ISE или Quartus доступнее, нежели Keil или что-то подобное (про GNU ARM молчу, потому что GNU).
Интересную тему тут подняли...
В данный момент работа моя связана как раз с АРМ. Поэтому некоторые размышления тоже есть.
Во-первых, АРМ на самом деле полностью 32-разрядный, и адресование байта или слова (как в z80) работает не совсем просто.
2. АРМ для самостоятельного изготовления не пригоден в принципе. Корпус на 100 ножек (это минимум необходимого) с шагом 0,5 мм паять в принципе невозможно (по неопытности сразу пробовали). Конечно есть другие корпуса, предназначенные для вставки в колодку. Только 208 ножек колодки с тем же шагом вообще нереально впаять. Промолчу, каково их развести...
3. Готовые платы для разработки на АРМ стоят от 80 баков (галимые). Нормальные вообще от 350.
4. Система команд RISC слишком сложна. Во-первых, команд мало и ими нужно как-то составлять самому сложную команду традиционных процов. Во-вторых, синтаксис достаточно сложен. Конечно Си здесь рулит, но про оптимизацию можно успешно забыть. Только то, что встроено в конкретный компилер.
5. Даже в некоторых АРМ 7-ой серии встроены средства для ускорения выполнения команд - как следствие вычислить время выполнения инструкции становится сложновато.
Вот такие грустные мысли...
Поэтому вывод таков - z80 никто не заменит. Эмуляторов уже и так полно, а полностью правильных нет вообще. И не на арме его делать.
Единственное, для чего его как-то можно попробовать применить, так это заменить всю ту россыпь корпусов, что стоит щаз всюду...
Основной идеей в представленных концепциях была работа программной модели Z80 в ARM'e с программной моделью периферии в ПЛИС или программной модели Z80 в ПЛИС с программной моделью периферии в eZ80+ПЛИС. Программные модели без генерации реальной шины, как понимаю, были выбраны именно из-за сложности соблюдения времянок и для упрощения согласования. Считаешь, в случае ARM'a, будут принципиальные трудности с согласованием софтовых моделей? Ведь в таком варианте единственными жёстко завязанными на время сигналами будут внешние сигналы которые можно засинхрить аппаратно.
Последний раз редактировалось Black_Cat; 06.10.2006 в 11:16.
Я полностью согласен с тов. mungo , ибо и моя работа на данный момент связана с АРМ, а точнее сейчас это LPC221x (Philips). Его внутренняя шина может достигать 60-80 МГц, а с учетом того, что тут хотят Z80 на 20-40 МГц и т.д., точно сэмулировать Z80 на таких скоростях не удастся. Даже если взять другой АРМ, то вряд ли он будет быстрее на порядок, чем желаемый Z80 40 МГц, за приемлемую цену.
Тут кто-то предлагал, что, мол, можно выдрать из исходников эмулятора Unreal часть, отвечающую за эмуляцию команд Z80 - да, оно конечно можно, только надо себе представлять, что, несмотря на простоту строчек си, после компиляции это превращается в десятки машинных команд на одну эмулируемую инструкцию. Да-да, это и выборка кода инструкции из памяти, и ведение внутренней бухгалтерии (подсчет тактов, циклов и т.д.), и непосредственное выполнение - а еще ведь хочется, чтобы была еще и внешняя аппаратная синхронизация с обычной аппаратурой Spectrum, т.е. АРМ должен реагировать на внешние сигналы и сам выставлять их на шину. А это еще пара-тройка команд, а, скорее всего, и десятков команд.
И пусть многие команды АРМ выполняются за один такт. В результате все равно получается несколько десятков тактов на одну команду Z80, который, хочется, чтобы был максимально близок к оригиналу и имел возможность расширения в сторону быстродействия.
При подсчетах (правда, с некоторым запасом), получается, что нам нужен как минимум полугигагерцовый проц.
Кстати, как там с видеопамятью и вообще памятью? LPC221x, например, не умеет работать с РУ5, ему подавай SDRAM. Значит, либо вручную еще и работу с памятью делать (выставлять адрес, ждать данные), либо..? Что вы... лучше уж использовать SDRAM, одну штучку, на мегабайтик. Но тогда и работу с видеопамятью придется возложить на АРМ. Вывод неусиленного видеосигнала тоже должен будет делать АРМ. А еще он должен будет обрабатывать обращение к портам - не ко всем, но только к некоторым - которые имеют отношение к памяти. А если порт имеет отношение не только к памяти? Beta Interface, например (переключение ПЗУ и пространства портов)... что делать? Как разделять внешнее и внутреннее?
Кстати, насчет ПЗУ Spectrum'а... ой! Может, лучше все-таки сделать действительно вручную работу с РУ5 и ПЗУ, и порты тогда не придется разделять...а? Но тогда - все сигналы должны быть как у оригинала, выставить то, се, подождать там, подождать тут (задержки памяти или вдруг кто -BUSREQ просадит или Reset нажмет?).
Получается, что синхронизация с электрической схемой может быть сложнее, чем все вместе взятые дополнения к эмуляции процессора в обычном эмуляторе (вывод звука, на экран, работа с дисками, интерфейс с пользователем), например, под PC.
К чему это я? На обработку каждого действия уходит совсем немного времени. Но этих действий так много - причем, не факт, что меньше, чем в обычном эмуляторе, - что волей-неволей задумаешься: а нафиг?
На АРМ все-таки можно, наверное, сделать 3.5, 7-мегагерцовый Z80, но далее вы упретесь в потолок, и еще не факт, что каждый сможет позволить себе такую хреновину
А что хотим? Хотим расширения, если не в архитектуре, то по скорости. Так это вряд ли получится.
Последний раз редактировалось ARTi; 06.10.2006 в 12:35.
Среди прочих, наиболее интересный способ -
заменить хард софтом.
Каждый экземпляр харда требует выложить за него деньги. По сравнению с ним, софт копируется фактически бесплатно (не учитывая стоимости его разработки).
Этот способ уже применяется. Примеры:
General Sound - формирование звука универсальным процессором.
Multicolor - отображение через видеопамять объёмом 6912 байт изображения, занимающего в замкнутом виде более 6912 байт.
Тесная связь софта и харда в таком решения это и есть основная проблема. Железнячники говорят "кто напишет софт?". Программисты говорят: "кто будет паять железки?". И продолжают делать то что дороже, но можно использовать здесь и сейчас.
R4008 = 10-12$
EP1C3 = 15-17$
SRAM 4шт 512x8 = 12-16$
+мелочевки
итого басис по комплектухе около 60$ цены средней взвинчености можно и дешевле.
Z80 софт вызывает #3D13. Эмулятор перехватывает и подкачивает с HDD средствами ARM OS.
Другой пример - breakpoint отладчика.
Под понятием "архитектура" понимается "программная архитектура". Модель, которая предстаёт перед программистом.
Для "обычных процессоров" архитектура это набор регистров, команд, разрядность адресов и т. п.
Для ПЛИС архитектура это - ?
Ни в коем случае.
Сейчас софта под ускоренный Z80 нет.
Смысл топика именно в том, что для софта, требующем больше скорости, следует переходить на другую архитектуру и работать в её родном коде.
И делать это необходимо до того момента, когда такой софт (под быстрый Z80) вырастет и станет препятствием для такого шага.
Фу, ну значит я правильно понял. Имхо имеет смысл только в поддержке старой переферии.
Без понятия. Может я тебя слишком буквально понял, но тот путь, который ты приводишь в качестве преимущества (именно так я понял это) АРМа перед плисиной подходит так же и для плис. Единственное различие в инструментах разработки, но они есть, вплоть до бесплатных компиляторов/симуляторов и чёрта лысого. Короче говоря, архитектура - не аргумент "за" для АРМа.
У icebear c хамством явно проблемы.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
