Есть она там. Очень подробно.

Нашел. Максимальная тактовая для XP-5 - 400МГц. Оно там в большой таблице лежит, сразу и не заметишь.

>2. Софтина ispLEVER полная с клизьмами где берется?
>За $500 как-то неохота покупать...

Софтина есть на CD (v5.1 и v6.0), лицензию можно взять от ispLEVER-Starter
(которая нахаляву генерируется на их сайте в меню "Лицензии").
Но! толстые чипы не разрешает трассировать. Для этого нужна опция лицензии
LSC_ADVANCED_ORCA. а ее нет-с, и в клизмах я не нашел. Если кто нашел - бросте ссылку...

С уважением,
derin.

По поводу Place & Route в isplever 7 - почему медленно размещается Lattice ECP2?
Прямо чудовищно беспросветно медленно. Что в проекте на verilog надо "констренить". Все перепробовал. Вроде разумно все, назначение выводов, tsu th tco, группы - но не помогает.

Что делать? Как ускорять?

Моя контора только недавно начала входить в программируемую логику, я должен быть сам решать куда податься. У нас в стране наиболее широко идет Альтера ессно (наверно как и везде), Xilinx тоже весьма известен (особено в военке), но выбрал Латтис.
Альтеру отмел по своему печальному опыту в их supportе - разжирели и обнаглели, на мало-объемных клиентов как моя контора они почти откровенно ложат. С Xilinxом опыта не имел, но наслышан ессно, и их локальный support вроде хорош, но все-таки выбрал Латтис по рекомендации знакомого который ими очень доволен. Кроме имея пока весьма небольшой процент локального рынка они пытаются привлечь клиентов и ценами и качеством supportа.
Насчет цен на их софт - ispLever оказаля наиболее дешев относительно Альтеровского и Xilinxного, да и чипы в среднем дешевле.

Для службы поддержки Альтеры у меня пока вопросов просто нет. Все складно выходит.

А вот Lattice успел меня озадачить по полной программе.
Ладно, удачный набор настроек трассировщика догадался скопировать из проекта отладочной платы с FTP. Без этого трассировка длилась часами.

Предполагаю, ECP2 или ispLever не любят сигналы с большим разветвлением. Которое обычно прокатывало в альтере на ура. Переходим на глобальные трассы, для чего временно применен DCS.

Не могу разобраться, как вывести комбинаторный сигнал на глобальные ресурсы для clock enable. Не подскажете?

В альтере это было что-то вроде global_signal = GLOBAL(local_signal);
Тут USE PRIMARY или SECONDARY, но как их прикрутить к wire или reg (Верилог)?
Все перерыл - не могу понять.

Начинает проясняться.

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

Назначения USE SECONDARY NET "high_fanout_net" все же работают, хотя редактор назначений chip planner их не видит.
Редактор не видит, а в системе помощи есть картинки, где назначения "подцепились" и попали в таблицы. Как это исправить?

Осталось непонятным, почему можно назначить только три глобальных пользовательских сигнала, хотя в описании ECP2 их восемь.

Синтезатор synplify тоже пришлось настроить, т.к. он много раз копировал вычисление разветвленной функции, а глобальный wire переименовывал и назначение ему не присваивалось.

Ладно, для первого знакомства сойдет и так.

"Page Not Found

We are sorry, there is no Intel.com page matching your request. The page may have been renamed, moved or is no longer available. Please verify the address you typed is spelled correctly..."

Оперативно работают! ;О)

Почему задержки на распространение по трассировочным ресурсам - главный фактор, снижающий частоту проекта (пути от регистра к регистру) . Семейство ECP2, размер проекта под 45000 ячеек.

3 нс на пути через LUT - это хорошо.
еще >3 нс на задержку в проводах - это не годится.

Копая app notes, выяснил, что при таком раскладе надо использовать ручное управление трассировкой, например, путем назначения кусков ПЛИС вызываемым функциям. А зачем тогда вообще вводим требования на временнЫе параметры проекта? Трассировщик сам должен вписаться.

Или я не так понял сам процесс программирования Lattice? Скажите хоть, у кого высокие частоты в увесистых проектах. Для ориентира.

Как спокойно жилось в Квартусе...

Как и предполагалось, назначение отдельных регионов для потоков обработки данных сократило задержки в "проводах". Но лишь потому, что трассировщик лишился возможности использовать самые длинные трассы.

Как у инструментов Lattice решается вопрос снижения задержек в трассировочных ресурсах?
Слишком велик ее процент от всех путей распространения.

Прикрепил картинку, красная трасса - 0.95 нс. Более длинная трасса - 0.63 нс. Непонятно, зачем так далеко размещен получатель сигнала от источника, да еще через массу мультиплексоров?

Я не понимаю, зачем Verilog, если потом все равно вручную трассировать. На максимальных частотах наносекунды нельзя разбрасывать.

Кстати, Xilinx есть такие же проблемы с трассировкой? Тут предстоит еще и Xilinx...

А можно вот здесь поподробнее... какие такие настройки трассировщика?
Использую ECP2M50E, 70% забито.
Иногда складывается ощущение, что просто очень неаккуратно разводится там всё...

Сорри, почему-то в свое время не получил уведомления форума от ответах...

Сейчас вернулся к продолжению свого проэкта.
Первая фаза проэкта - небольшая, но в свое время приобрел ECP2 (50E) EVB посему буду пробовать на нем. Займет думаю не более 10-15 процентов логики чипа, 2-3 PLLя и немного памяти (EBR).
Частоты - низкие, проблем с таймингами вроде не ожидаю...как новичок в FPGA пока слабо представляю средства и способы борьбы с проблемами тайминга....

Не только они оперативно работают Пользуйтесь !!!

>А можно вот здесь поподробнее... какие такие настройки трассировщика?
>Использую ECP2M50E, 70% забито.
>Иногда складывается ощущение, что просто очень неаккуратно разводится там всё...

В полностью забитой микросхеме реально одна настройка помогала поднять частоту - перебор cost tables. Если не путаю, называется Placement Iteration Start Pt (начало перебора), Placement Iterations (количество шагов).

Для моих проектов нашлась пара хороших таблиц. Но перебрать удалось только на 20%, уж очень это долго. Кстати, многоядерный процессор перебор должен ускорять.

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

Новый трассировщик NBR не помог.

Как я понял, для проектов с малой глубиной логики хороший результат -50%/50% задержки.
Если перекомпоновать проект так, чтобы логические функции "потяжелели", то получается 70%/30%, что бывает лучше.

Реальные тяжелые проекты есть на CD дисках для отладочных плат для Lattice. Содержимое дисков можно скачать с фтп lattice.

Во понаписал. Ошибки исправил.

Ах да, эти параметры я уже вертел. Помогает только Placement Iteration Start Pt.
Я вот ещё пытался сделать блокинг через Block Modular Design Wizard, и используя симплифаи разных версий и различные комбинации ухищрений (даже без ухищрений точно по документации) ничего не вышло. Не получается этот блокинг... при компиляции вылазит некая ошибка! забил на это... Пытаюсь разобраться с подсовыванием SDC-файлов!