[Postoroniy_V 0]

Железный аргумент. Подозреваю, что он единственный в поддержку софтпроцессора в FPGA.

видимо не судьба вам понять :(

Есть готовый девайс. Внешних процессоров там нет а есть большая FPGA. Надо сделать User Interface

и если бы вы сходили по ссылке которую вам дал slog

то вы бы наверное/может быть/скорей всего поняли о чём вам "талдычат", но вам как и всегда просто нас...ть на аргументы/доказательство и прочее...

вообщем да... увы и ах...

а про тему не восприятия верилога это ваще песня

[aprox 0]

видимо не судьба вам понять :(

и если бы вы сходили по ссылке которую вам дал slog

то вы бы наверное/может быть/скорей всего поняли о чём вам "талдычат", но вам как и всегда просто нас...ть на аргументы/доказательство и прочее...

По ссылке, которую выдал Leka я ходил, смотрел и понял, что речь идет о готовом в железе изделии, внутрь, которого пытаются влезть через софт. Хард переделке не подлежит. Hикакого отношения данная ситуация к вопросу об эффективности софтпроцессоров в разработках на FPGA не имеет.

[Postoroniy_V 0]

По ссылке, которую выдал Leka я ходил, смотрел и понял, что речь идет о готовом в железе изделии, внутрь, которого пытаются влезть через софт. Хард переделке не подлежит. Hикакого отношения данная ситуация к вопросу об эффективности софтпроцессоров в разработках на FPGA не имеет.

тоесть ваша логика в данном случае такова

1) Обана! есть готовый девайс! Хорошо!

2) Опа! а где же Z80 снаружи? не эффективно! без него нельзя GUI сделать!

3) Паём снаружи Z80! Ура! Вот так эффективно!

вообщем..желаю вам того же что и des00 - Удачного заката солнца в ручную!

[Omen_13 0]

Рекомендую прекратить флуд

С уважением, модератор

[Leka 0]

Пример: 2 канала АЦП дают 2Гбайт/сек, не меньшую пропускную способность должна иметь подсистема памяти, в сумме - не менее 4Гбайт/сек --> ПЛИС в БГА корпусе. Чтобы не тормозить быстрый внешний процессор, нужна дополнительная параллельная шина, это потенциальный 2Гбайт/сек канал, выбрасываемый на ветер: разводим ПЛИС на 6Гбайт/сек, а используем только 4Гбайт/сек. Если же использовать софт-процессор - достаточно развести ПЛИС на 4Гбайт/сек. А ставить на последовательный интерфейс медленный внешний микроконтроллер - бессмысленно в таких задачах.

[aprox 0]

Пример: 2 канала АЦП дают 2Гбайт/сек, не меньшую пропускную способность должна иметь подсистема памяти, в сумме - не менее 4Гбайт/сек --> ПЛИС в БГА корпусе. Чтобы не тормозить быстрый внешний процессор, нужна дополнительная параллельная шина, это потенциальный 2Гбайт/сек канал, выбрасываемый на ветер

Вы не ошиблись с порядком цифр производительности? Во-вторых, речь изначально шла о применении софтпроцессора для целей управления и мониторинга процессов внутри FPGA, когда никаких гигабайтов в секунду вовсе не требуется.

Если же использовать софт-процессор - достаточно развести ПЛИС на 4Гбайт/сек. А ставить на последовательный интерфейс медленный внешний микроконтроллер - бессмысленно в таких задачах.

Мне представляется, ставить софтпроцессор на перекачку данных столь высокой производительности - бесперспективная затея. Его программа вся будет состоять из двух инструкций в цикле. И никаких других действий в него уже не втиснуть, никаких дополнительных устройств. Hу, и зачем тогда нужны, все эти навороты с софтпроцессором, когда достаточно простенькой state_maсhine?

Я по-прежнему считаю, что единственным неубиваемым аргументом в пользу софтпроцессоров является случай модификации готового и неизменного HW с FPGA.

[Builder 0]

Я по-прежнему считаю, что единственным неубиваемым аргументом в пользу софтпроцессоров является случай модификации готового и неизменного HW с FPGA.

Вы забываете, что самые маленькие FPGA стали большими и не всегда на 100% заполненными.

Скажите, нафига тогда козе баян, если я могу использовать свободные ресурсы для организации всего внутри?

И вообще, Вы пользуетесь не верными логическими выводами, Вы придумываете частный случай когда что-то нельзя, не эффективно или не удобно сделать и распространяете это на общую ситуацию.

А это не есть верно исходно.

Надо быть пластичнее и подходить к задаче с позиции: а как решить данную задачу максимально эффективно с заданными исходными? И от этого уже плясать.

А то устроили тут крестовый поход на xHDL и софт процессоры. Софт процессоры это не понацея, а одтн из вариантов решения задачи.

 

Нужен небольшой софт процессор для обслуживания юзер-интерфейса. Большая производительность не нужна, хватило бы и 8-ми разрядного. Основные требования - нормальные крос-тулзы для программирования на Си, небольшой размер, бесплатность. NIOS бы отлично подошёл, но он требует лицензии. В некоторы странах это важно. :crying: Предпочтительно бы стандартное ядро типа AVR или 51-х. На opencores много всякого - но что-то всё не то. Не знаю что выбрать. Направьте пожалуйста на путь истинный...

По теме беседы, к автору: а что, купить NIOS не дешевле выйдет (если нужна лиц. чистота), чем маятся с ядрами, которые требуют адаптации? Тем более что стандартные ядра (AVR или 51-х) места будут занимать не меньше Ниоса, а маленькие не будут иметь того набота средств разработки и отладка как Ниос. Или я что-то не понимаю?

Изменено 30 сентября, 2008 пользователем Builder

[0608 0]

Я по-прежнему считаю, что единственным неубиваемым аргументом в пользу софтпроцессоров является случай модификации готового и неизменного HW с FPGA.

Это один из аргументов, но единственный, есть и другие. Они вытекают из концепции построения систем на кристалле (SOPC), с ее громадными возможностями.

Может быть, проблема в отсутствии ясных методик построения SOPC.

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

[Omen_13 0]

Последнее предупреждение участникам, прекращайте флуд!

Дальше буду использовать карательные меры - выпишу пилюли и закрою тему.

Aprox кандидат №1 на пилюлю если не прекратит флудить

С уважением, модератор

Изменено 30 сентября, 2008 пользователем Omen_13

[Leka 0]

Вы не ошиблись с порядком цифр производительности? Во-вторых, речь изначально шла о применении софтпроцессора для целей управления и мониторинга процессов внутри FPGA, когда никаких гигабайтов в секунду вовсе не требуется.

Это и имел в виду, поэтому написал: "потенциальный 2Гбайт/сек канал, выбрасываемый на ветер", те пустая трата ресурсов чипа и печатной платы - только для того, чтобы вынести наружу относительно медленную обработку. Удельная стоимость БГА пина(даже без учета платы и монтажа) очень высока, например: FPGA кристалл в FG320 стоит столько же, сколько вдвое больший кристалл в FG256 --> с софт-процессором получается дешевле.

[aprox 0]

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

Это и имел в виду, поэтому написал: "потенциальный 2Гбайт/сек канал, выбрасываемый на ветер", те пустая трата ресурсов чипа и печатной платы - только для того, чтобы вынести наружу относительно медленную обработку. Удельная стоимость БГА пина(даже без учета платы и монтажа) очень высока, например: FPGA кристалл в FG320 стоит столько же, сколько вдвое больший кристалл в FG256 --> с софт-процессором получается дешевле.

Спрошу не флуда ради, а уразумения для- зачем нужен 2Гбайт/сек канал связи с медленным внешним процессором? Разве не сгодится обыкновенный 4-х проводный SPI интерфейс? Четыре любых свободных пина BGA- это действительно так напряжно? И внутри FPGA никакого софтпроцессора не потребуется. Достаточно будет встроить в проект столько сдвиговых регистров, сколько требуется по задаче.

[Leka 0]

Спрошу не флуда ради, а уразумения для- зачем нужен 2Гбайт/сек канал связи с медленным внешним процессором? Разве не сгодится обыкновенный 4-х проводный SPI интерфейс? Четыре любых свободных пина BGA- это действительно так напряжно? И внутри FPGA никакого софтпроцессора не потребуется. Достаточно будет встроить в проект столько сдвиговых регистров, сколько требуется по задаче.

Если хватает SPI - скорее всего придется выбирать между 8-разрядными решениями(например: AVR и софт-ядро уровня PicoBlaze), а не 32-разрядными(например: ARM и NIOS). Если есть куча кнопок, ключей, светодиодов и тп - имеет смысл отдать все это хозяйство внешнему 8-разрядному микроконтроллеру. Если надо слить дамп системной памяти - проще будет софт-процессор. Так что оправданным м/б одновременное применение и софт-процессора, и внешнего микроконтроллера, и связать их по SPI.

Изменено 30 сентября, 2008 пользователем Leka

[aprox 0]

Если хватает SPI - скорее всего придется выбирать между 8-разрядными решениями(например: AVR и софт-ядро уровня PicoBlaze), а не 32-разрядными(например: ARM и NIOS). Если есть куча кнопок, ключей, светодиодов и тп - имеет смысл отдать все это хозяйство внешнему 8-разрядному микроконтроллеру. Если надо слить дамп системной памяти - проще будет софт-процессор. Так что оправданным м/б одновременное применение и софт-процессора, и внешнего микроконтроллера, и связать их по SPI.

Консенсус!

[Leka 0]

Консенсус!

Ok!

 

2ALL

Мысли вслух... примерные оценки скорости случайного доступа по SPI:

1) внешним AVR к 16-разрядным внутренним ресурсам FPGA: 10МГц(клок)/32бита(адрес+данные)=0,3МГц;

2) внутренним софт-ядром к 32-разрядной памяти программ на конфигурационной флешке: 50МГц(клок)/64бита(инструкция+адрес+данные)=0,7МГц.

Скорости сопоставимые, и напрашиваются софт-ядра, ориентированные на исполнение инструкций из SPI flash...

Изменено 1 октября, 2008 пользователем Leka

[Mahagam 0]

про возможности кеширования не забывай. и выборку данных из флешки по подряд идущим адресам быструю...