Книжка есть, прочитана несколько раз. но конкретно по языку там маловато.
для "как начать работу" - эта книжка в самый раз, а вот для более глубинного понимания VHDL вообще и ФПГАшек в частности ее маловато.

время выхода на режим -- макс. время перекладывания у них нормировано, скорость перекладывания вполне линейна.
разбор со стороны ПЛИС -- мне как-то привычнее с мелким процессором. В идеале, наверное, подошло бы что-то среднее между пико- и микро-блейзом.

Уточните

Подавать ОДНОВРЕМЕННО на все 16 каналов импульс разной для каждого канала длины или все-же последовательно?

Ну это... пишется дальше...

16-разрядное ядро для ПЛИС напрашивается оригинальное. Да, долго, плюс надо софт. Однако под идеологию ПЛИС оно подходит наилучшим образом. Главный плюс - можно как угодно крутить архитектуру.

Всё равно. В любом случае ~20 каналов в указанный интервал "последовательно" не влезают, а хитрооптимизации с переупорядочиванием не во всех случаях работать будут.

Какое брать за основу?
Чуть уширенный пикоблейз, и переименовать в наноблейз?
с компилятором - да, засада будет. Да и первые попавшиеся 'обычные микроконтроллеры' оказались с труднодекодируемой системой команд.

Есть хороший способ - представить, что процессор уже есть И... начать писать для него программу, пользуясь всеми необходимыми регистрами и командами! Потом, когда программа вчерне оформится, будет видно, какая архитектура получилась. Самое трудное в разработке эффективных решений для ПЛИС - ломка десятилетиями вырабатывавшихся стереотипов, что аппаратная платформа - это данность, и Интел с пути уже не свернет. Самый простой процессор делается двухтактным автоматом. На первом такте читаем команду из блочной памяти, на втором выполняем ее большим-большим оператором case(cmd). Есть нюансы, конечно же, но тут главное принцип.

Просто процессор почти бесполезен, интересен комплект процессор+компилятор какого-нибудь языка, например 'стандартного' Си.
А вот написание компилятора, как я понимаю, весьма отдельная и нетривиальная задача.

Кстати, а си под пикоблейз бывает? или это из области фантастики?
(под АВРки и даже ПИКи си бывает)

Потому, что:
1. отладить десяток РАЗНЫХ узлов намного проще независимо.
2. "не худшая производительность" вилами по воде писана. Да, Spartan будет иметь эту производительность на автоматных (не требующих хоть сколь ни будь сложных алгоритмов) задачах, но как только задача станет чуть сложнее, то десять мелких МК один большой уделают причем многократно т.к. они независимо одновременно выполняют десяток разных потоков, а один большой только пытается это делать.
3. потребление будет такое, как пожелаешь - Sleep рулит.
4. Если ставить ограничение в DIP-корпусах, то советую посмотреть в сторону линейки более мелких МК. АтМега48/88/168, АтТини261/461/861, АтТини25/45/85 т.к. 32-я сильно избыточна.
5. Меньше проблем с ЭМИ и прокладкой проводов
....

ПЛИС не то что допускают, а просто рекомендуют модульную разработку.

Spartan - это никак не МК. Десять (а хоть бы и 20) ядер вполне в нем поместятся. Основное преимущество ПЛИС как раз в том и состоит, что обработка прекрасно распараллеливается, и отдельные модули не обязаны точно впихиваться в корпуса, разбросанные по плате - кто-то может быть больше, а кто-то меньше.

Почти аналогично.

Вот уж не надо! Это-то откуда взялось??? 20 корпусов, все соединить, куча дорожек и конденсаторов, гонки фронтов, уходы тактовых генераторов... В ПЛИС за синхронизацией следит САПР, multiclocking уже давно разработчикам САПР известен, и все достаточно хорошо анализируется. Никаких ЭМИ (внутрь корпуса влезет?), никаких непропаев и к.з.

Вах, откель такой ужас ?
Вы вероятно не поняли моей мысли. 20 корпусов на РАЗНЫХ платах соединенных ДВУМЯ проводами. Протокол обмена по проводу - асинхронный где-то на 9600...19200 (нечто смахивающее на 1-Wire, LIN, CAN...)
На каждой плате поставить мелкий стабилизатор (а-ля Lp2950) и разместить плату там, где ее исполнители (датчики), а не тянуть все провода к одной общей.

Еще как влазит. Особенно наносекундная дрянь.


Да хоть 100 ядер. Откель эти ядра исполняемые инструкции ОДНОВРЕМЕННО выбирать будут?! у Spartan-а "на борту" (на кристале) сотня кБайт блочной памяти которую можно раздать под память программ найдется? А чем они ОДНОВРЕМЕННО управлять будут? А с каких источников (АЦП) они данные брать будут?
Кроме того, 10 МК это не только 10 ядер, но и десять оперативок, десять флешей программ (сразу готовых для исполнения, а не после загрузки), десятка 2-3 таймеров (3-4 десятка аппаратных PWM-ов или таймерных событий), десяток АЦП (более 50 каналов в т.ч. дифференциальных), десяток генераторов, около 200 универсальных ног ... и прочей мелкой и не очень ерунды. И все это работает ПОЛНОСТЬЮ независимо.

Что значит "все равно" ?! Есть громадная разница сколько одновременно считать времянок 3 или 17!
Если допускается последовательная подача импульсов, то задача для 16 каналов решается одним 16-битным таймером и 3-мя компараторами.

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



Ничем, кроме готовой периферии. ARM контроллеры будут мощнее,
а по стоимости уже почти сравнялись:)

Решать задачу можно на имеющемся железе, а IPC хоть в плис,
хоть в контроллере придется делать, и не обязательно для
соединения использовать тормоза RS-232. Достаточно выбрать
компромис по разрядности шины. В семействе AVR есть контроллеры
с командами выборки данных из внешней памяти.

P.S. Приводимые доводы - это не агитация, за использование контроллеров.
Попробуйте реально оценить требуемые ресурсы и возможности
разных решений:) И возможно найдете приемлемое решение.

При таком оживленном обсуждении данного топика, может его перенести
в раздел "Наши проекты" ?

Может лучше сраазу на си писать?
Дык интели действительно не свернут, но на них свет клином не сошелся. avr, pic, arm, mips тут уже поминали.


И по этому интерфейсу(кстати, какой топологии: лично с каждым, кольцо, общая магистраль с арбитражем) на скорости 1кбайт/с будем гонять тристокилобайтную картинку?


каждый из своего блока памяти. А вот, например, 32м аппаратным ШИМам в спартане ни в какую общую память лазить не надо.



50МГц тактовой, чуть меньше мегабита прошивка. Время загрузки сами посчитаете?
Кстати, а нам что, всё время перезагружаться надо?



Подумайте о топологии и логике межпроцессорного взаимодействия.
Пара-тройка каких-нибудь SPI интерфейсов потребует 6-9 ног от каждого микроконтроллера, а программный 1-wire одновременно с 20ШИМ пишите сами.



В любом случае у нас асинхронно по двум-трём внешним портам могут приходить запросы вида "вышай параметры этого ШИМ" и "вот новые параметры этого ШИМ".

Понятно что задача "в принципе решается", но решение получается громоздким и малорасширяемым.
Кстати, если 1мс поделить на 250 дискретов и на 16 каналов, то получится 4операции на частоте 16МГц.


Это только цена кристалла.
Паять на коленке БГА или даже TQFP с шагом ног 1.27мм - это мазохизм, про изготовление плат промолчу, а цена (и доставаемость) готовых плат может сильно отличаться в зависимости от региона, тиража, погоды на марсе итп. (при тираже 1шт наверняка выйдет дороже, чем кит с ФПГАшкой)

На счет IPC. В ПЛИСе я могу сделать тупой 'регистр-ШИМ', который будет наружу работать как ШИМ, а изнутри выглядеть как обычный регистр. К такому регистру тупо подводим параллельную шину данных, шину команд, we/re И всё. Работы минут на десять.

Интерес может представлять, возможность в топологии например из 10 контроллеров
решить задачу обработки изображения ( что-то распознать? )
300Kб/10 = 30кб обработки данных для одного контроллера.
на AVR, любители, программно делали поддержку USB.
Поэтому получить данные для обработки, в реальном времени, скорее всего удастся.
( или поставить более производительный контроллер для их рассовывания по
другим контроллерам и последующей общей обработкой)

P.S. Насколько это реально, трудно сказать без предварительного прототипирования.

Не лучше т.к. существующие компиляторы не позволят максимально
использовать существующую аппаратуру.
Придется закладывать более дорогие аппаратные решения.

P.S. Изюминка Форта в том что, позволяет при прогнозируемых затратах
получить приемлемое решение., но не даром конечно.