[vetal 0]

>Этот вопрос надо адресовать суппорту альтеры

Я адресовал его сюда. Все же это хорошая фича - экономит лишний мультиплексор и увеличивает fmax.

В оригинальном дизайне(на примитивах) у вас 4 comb cell и 2 ff.

На RTL у меня получилось получилось 3 comb и 2ff(для ciii).

 

Для первого триггера в автоматическом режиме он плохо маппит LUT(похоже, что он не может иначе развести схему). Если сигнал со входа C перекинуть на вход B, то появится возможность через С провести сигнал до SLOAD триггера. Преимущества по большому счету не будет от подобных манипуляций.

1 LUT на подвод сигнала к первому триггеру, 1 LUT на формирование сигнала разрешения и 1 LUT на инверсию сигнала первого триггера. Меньше не получится, разве что разное распределение логики и нагрузка на трассировку будет.

Темный лес в общем :)

PS: указанные манипуляции можно проделать в Resource Property Editor

[spoiler=код на vhdl внутри]

library ieee;
use ieee.std_logic_1164.all;

entity testmod is
    port (
    clock             : in std_logic;
    set_primary     : in std_logic;
    set_secondary     : in std_logic;
    data_primary     : in std_logic;
    data_secondary     : in std_logic;
    res             : out std_logic
    );
end testmod;

architecture rtl of testmod is
signal r1,r2    : std_logic;
signal e2        : std_logic;
begin
    e2<= set_primary or set_secondary;
    res<=r2;
    process(clock)
    begin
        if (rising_edge(clock)) then
            if (e2='1') then
                if (set_primary='1') then
                    r1<= data_primary;
                else
                    r1<= data_secondary;
                end if;
            end if;
        end if;
    end process;
    process(clock)
    begin
        if (rising_edge(clock)) then
            if (e2='1') then
                if (set_primary='1') then
                    r2<=not r1;
                else
                    r2<=r1;
                end if;
            end if;
        end if;
    end process;
end rtl;

 

 

[jojo 0]

>Темный лес в общем

Мне надо было сразу написать, что на самом деле хотел сделать. Но пришлось делать отдельный проектик для размещения здесь.

 

В прикрепленном коде summux32.v модель двух нетривиальных этапов конвейера (крайних), 3 логически эквивалентных реализации.

 

В конвейере используются сумматоры трех чисел по 32 бита.

В регистр записывается либо одна тройная сумма, либо другая.

 

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

 

Я же надеялся сделать схему в виде двух разных тройных сумматоров и подать сигнал на вход триггера с синхронной загрузкой. Для Стратикса полезный эффект несколько десятков мегагерц (до 70-80).

 

Можно зафиксировать суммы в регистрах, введя дополнительные этапы конвейера, но сами этапы много весят, под 1000 ячеек.

 

----

Кстати, может кто-нибудь собрать универсальную схему их summux32.v (внизу файла) для Xilinx Virtex5 и Lattice?

 

 

----

Только что подумал, что можно сделать многоцикловую схему, тогда будет потеряно только время.

Тяжеловесные этапы выполнять два такта. Но это уже не относится к исходному вопросу.. и устраняет саму проблему с синтезом. Если я правильно понимаю многоцикловость.

 

Добавил еще две реализации в конец файла summux32_2.v (прикреплен к сообщению)

 

 

//для Stratix

собирается до 350 МГц

 

//для Cyclone

до 200 МГц

 

Разумеется, эта схема будет работать внутри ПЛИС от PLL. Обмен с процессором будет на много меньшей частоте.

 

Кстати, как построить самый быстрый сумматор трех чисел в современных ПЛИСах?

Для Циклона разница в 20 МГц между синтезом Квартуса и моей оптимизацией не в пользу Квартуса.. :(

 

Попробую потом сделать multicycle-ы.

summux32.v

summux32_2.v

[sazh 5]

>Темный лес в общем

 

В воскресенье особенно. Раз у Вас хватило терпенья сработать на gate уровне, то лучше Вас никто не сделает.

Если б Вы привели чисто поведенческое описание, можно было б поэкспериментировать, модифицируя описание. Манипулируя соотношением количества сумматоров и мультиплексоров. А так, чем плохо встроенный макрос в проект. Ничем не хуже фифо и памяти в мегафункциях. (Если у меня миллионник, что мне до экономии регистров в конвейере.) Но если у Вас что еще лучше получиться, все равно покажите. Интересно.

[Leka 0]

Кстати, может кто-нибудь собрать универсальную схему их summux32.v (внизу файла) для Xilinx Virtex5 и Lattice?

Для Spartan3x - пример оптимизации под архитектуру - мультиплексоры совмещены с сумматорами, поэтому хватает 3х сумматоров(3*32=96 ЛУТ), частота около 180МГц по данным синтезатора.

module tst( // (sel)? a0+b0+c0 : a1+b1+c1; 
input  clk, sel,
input  [31:0] da0, db0, dc0, da1, db1, dc1,
output reg [31:0] sum
);
reg    [31:0] sel0, sel1, a0, b0, c0, a1, b1, c1, sum0, sum1;
always@(posedge clk)
begin
  sel0 <= {32{sel}};
  sel1 <= {32{~sel}};
  {a0, b0, c0, a1, b1, c1} <= {da0, db0, dc0, da1, db1, dc1};
  sum0 <= (a0 & sel0) + ((b0 & sel0) | (c1 & ~sel0));
  sum1 <= (a1 & sel1) + ((b1 & sel1) | (c0 & ~sel1));
  sum <= sum0 + sum1;
end
endmodule

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

[des00 25]

//для Stratix

собирается до 350 МГц

 

//для Cyclone

до 200 МГц

 

Странные вы цифры даете. Загнал ваши модули в ква 8.0, таймквест, 250МГц, cII-8.

 

базовый ~119.1 МГц (без sload),

базовый ~120.2 МГц (c sload, используется synthesis keep)

 

базовый пример с дополнительным регистром для трех входового сумматора ~149.1МГц. (констрейны не использовались).

 

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

 

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

 

Замечено что ква работает "по-даташиту", у него указано что вход sload LE в арифметическом режиме якобы идет с Register Carry Chain и если поставить промежуточный регистр, то он точно так, все и делает. А что бы с комб.логики на него завести сигнал то только ручками через констрейны.

[jojo 0]

>Странные вы цифры даете. Загнал ваши модули в ква 8.0, таймквест, 250МГц, cII-8.

 

Обычные цифры из Timing Analyzer Classic, градации только самые быстрые.

 

 

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

 

Это понятно, что оптимизированные с дополнительными регистрами - разъезжаются. В реальном модуле все это учтено.

Ведь все приведенные модули - лишь модели реальных узлов. Модели должны демонстрировать достижимую тактовую частоту регистров.

 

Еще раз попробую собрать.

 

Пересобрал, используя быстрые градации. Результат прикреплен.

Быстрые градации стоят своих денег.

 

 

Регистровость выхода сумматора, очевидно, увеличивает частоту. Эта же регистровость в рабочей схеме добавляет один этап, что нехорошо.

 

Все равно упомянутые модули на Альтере только отрабатываются по привычке. А предназначены для плисов фирмы L., которая достала уже. %|

summux32_3.v

[Builder 1]

Мне тоже теперь все понятно с техникой проектирования FPGA на языках Verilog и VHDL. Больше вопросов не имею.

Зря Вы так. Не знаю как Вы выкручиваетесь с симулятором Q, но у меня было так:

писал маленькие проектики ещё на Max+II на AHDL, симулял встроенным симуляторм, был горд собой.

Потом пришёл Q, поплювался на симулятор, но продолжил писать на AHDL.

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

И тут я понял, что не в состоянии рисовать в Q тест бенчи, не реально это покрыть ручками.

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

 

Если Вы с таким не сталкивались, то тут только одно объяснение вишу - у Вас не очень большие проекты, или прокты, котрые не требовательные к среде отладки.

Иначе Вы бы столкнулись с озвученными проблемами.

AHDL и VeriLog, это почти как asm и С (С++) - можно и на asm всё написать, но это часто требует больше времени, а результат почто тот-же. Совмещать AHDL и VeriLog умудряется SM, но это отдельный разговор.

 

В общем как не любил я AHDL за его полный контроль над реурсами, а пришлост перескакивать на Verilog или VHDL. По моему наблюдению, с AHDL обычно перескакивают на VeroLog. Особенно если знаете С или С++.

Первую неделю было трудно, на в дальнейшем это оправдало себя.

 

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

Мне больше всего помогла книга "verilog hdl synthesis a practical primer.pdf" (кажись была на фтп) и рекомендации по синтезу из док альтеры.

 

И ещё, рабудьте про использование Q кроме как последнего звена. Используйте для разработки спецеальные среды. Для меня удобнее всего оказалатся ActivHDL - всё удобно и понятно и в одно флаконет. Ментор слишком кривой по удобству.

 

В общем спорить безполезно, столкнётесь с ограничениями AHDL - сами поёмёте что к чему.

Эт уже многие проходили, ваша очредь.

[aprox 0]

Зря Вы так. Не знаю как Вы выкручиваетесь с симулятором Q, но у меня было так:

писал маленькие проектики ещё на Max+II на AHDL, симулял встроенным симуляторм, был горд собой.

Потом пришёл Q, поплювался на симулятор, но продолжил писать на AHDL.

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

И тут я понял, что не в состоянии рисовать в Q тест бенчи, не реально это покрыть ручками.

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

 

Если Вы с таким не сталкивались, то тут только одно объяснение вишу - у Вас не очень большие проекты, или прокты, котрые не требовательные к среде отладки.

Спасибо за подробное разъяснение ситуации. Однако, я не произвожу тестовых прогонов сборок проекта целиком на симуляторе. Целиком проект тестирую всегда в реальном FPGA со всей наружной периферией. Перед этим, в проект закладываются специальные тестовые узлы-ловушки с выводами на вспомогательные пины, которые просматриваю снаружи лог.анализатором. Мне представляется, такой прием полностью снимает все вопросы отладки, связанные с пакетом разработки, языком описания схем, симулятором и изготовителем FPGA.

 

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

AHDL и VeriLog, это почти как asm и С (С++) - можно и на asm всё написать, но это часто требует больше времени, а результат почто тот-же.

Совершенно согласен с сопоставлением asm и С. Кроме одного- результат в случае с Verilog совсем не тот-же, что с AHDL, а зависит от качества компилятора. Для микроконтроллеров с течением времени качество компиляторов C достигло такого уровня, что результат С и ASM практически неразличим. Но наблюдая дискуссию данного треда, а также на основание своего скромного опыта с Q, вижу- качество компиляторов с Verilog или VHDL далеко от идеала и на практике требует от разработчика замысловатой пляски с бубном. Вполне возможно, что с течением времени качество и удобство компиляторов с Verilog или VHDL достигнет уровня компиляторов С, но сейчас я предпочту подождать лучших времен со старым добрым ADHL. Еще раз спасибо за подробное описание вашего опыта перехода на Verilog.

[Leka 0]

...Совершенно согласен с сопоставлением asm и С. Кроме одного- результат в случае с Verilog совсем не тот-же, что с AHDL, а зависит от качества компилятора.

Сопоставлять AHDL с ассемблером я бы не стал:

http://electronix.ru/forum/index.php?showt...=10176&st=0

[Builder 1]

Спасибо за подробное разъяснение ситуации. Однако, я не произвожу тестовых прогонов сборок проекта целиком на симуляторе. Целиком проект тестирую всегда в реальном FPGA со всей наружной периферией. Перед этим, в проект закладываются специальные тестовые узлы-ловушки с выводами на вспомогательные пины, которые просматриваю снаружи лог.анализатором. Мне представляется, такой прием полностью снимает все вопросы отладки, связанные с пакетом разработки, языком описания схем, симулятором и изготовителем FPGA.

Ну, не знаю не знаю. Как говорится на вкус и на цвет... главное что-б работало конечно.

Но вот мой кореш делает системы для работы с видио и графикой. Так я слабо себе представляю

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

А снимать? А анализировать где ошибка? Увольте это делать на железе.

У него еще железа может не быть в принципе, а проект уже закончен и работает.

 

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

Я высказывал своё IMHO: после Max+II и тем более после ActiveHDL мне в симуляторе Q работать не удобно.

 

Совершенно согласен с сопоставлением asm и С. Кроме одного- результат в случае с Verilog совсем не тот-же, что с AHDL, а зависит от качества компилятора. Для микроконтроллеров с течением времени качество компиляторов C достигло такого уровня, что результат С и ASM практически неразличим. Но наблюдая дискуссию данного треда, а также на основание своего скромного опыта с Q, вижу- качество компиляторов с Verilog или VHDL далеко от идеала и на практике требует от разработчика замысловатой пляски с бубном. Вполне возможно, что с течением времени качество и удобство компиляторов с Verilog или VHDL достигнет уровня компиляторов С, но сейчас я предпочту подождать лучших времен со старым добрым ADHL. Еще раз спасибо за подробное описание вашего опыта перехода на Verilog.

Cущественной разницы в синтезе не вижу, ADHL или Verilog, в Q довольно хороший оптимизатор. Просто для того что-бы писать на нём эффективно, сначала нужно идейно проникнуться и понимать идеологию описания схемы. Знать, какая конструкция к какой схеме приведёт.

Как в той рекламе: ВЫ не любите кошек? Вы их просто не умеете готовить.

Сам я FPGA программирую не постоянно и тем не менее проблем с Verilog не испытываю.

 

А вообще, в вашем случае вы ставите вопрос так: мне и так хорохо, нафиг мне Verilog?

Ну, если нафиг - не используйте. Если-же хотите до конца понять - придётся сделать пару проектов и погрузится в эту методику. А так получается как в анектоде: мне Карузо не понравился, сам не слышал, но мне Рабинович напевал... Мыслите шире - проекты и ситуации бывают разные.

При синхронном синтезе в 99% случаев у меня прокт пишется без железа.

Когда приходит железо, то я занимаюсь прогонкой системы, а не отладкой прокта.

Ошибки обычно связаны не с самим проектом а с окружнием, а это очень быстро щемится.

 

Да, ещё, описывая проект на VeriLog, я не имею проблем с переносимостью проектов, исключения есть, но это решаемо.

[aprox 0]

Ну, не знаю не знаю. Как говорится на вкус и на цвет... главное что-б работало конечно.

Но вот мой кореш делает системы для работы с видио и графикой. Так я слабо себе представляю

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

А снимать? А анализировать где ошибка? Увольте это делать на железе.

У него еще железа может не быть в принципе, а проект уже закончен и работает.

Я тоже работаю с видеосигналами от морских радаров. И заранее предусмотрел в проекте, чтобы FPGA выдавал тестовый видеосигнал на вход ADC со всеми положенными помехами. И если вижу на экране правильную картинку, то все окей. Кроме того, такой режим самотестирования и самодиагностики был заложен в ТЗ. Это самый очевидный пример, когда симулировать проект целиком на практике не требуется.

Cущественной разницы в синтезе не вижу, ADHL или Verilog, в Q довольно хороший оптимизатор. Просто для того что-бы писать на нём эффективно, сначала нужно идейно проникнуться и понимать идеологию описания схемы. Знать, какая конструкция к какой схеме приведёт.

Зачем пользователю "идейно проникаться" тонкостями компилятора, если готовые мегафункции ADHL дают гарантированно эффективную разводку для каждой конкретного типа FPGA? Над этими мегафункциями трудились специалисты Альтеры, им и флаг в руки. А я лучше займусь прикладной сборкой из готового.

А вообще, в вашем случае вы ставите вопрос так: мне и так хорохо, нафиг мне Verilog?

Ну, если нафиг - не используйте. Если-же хотите до конца понять - придётся сделать пару проектов и погрузится в эту методику.

Нет, не так ставится вопрос. Я уже писал с самого начала, что попытался использовать в своем проекте готовые корки, написанные на Verilog и получил неудовлетворительную разводку. Пришлось вникать внутрь логики и переписать эти корки на ADHL. Сразу прекрасно заработало. Из этого я делаю вывод, неквалифицированно, как в моем случае, использовать чужие модули на Verilog - невозможно. А вникать в тонкости Verilog единственно для того, чтобы править чужие модули, мне представляется неразумной тратой времени.

[Postoroniy_V 0]

........

 

Зачем пользователю "идейно проникаться" тонкостями компилятора, если готовые мегафункции ADHL дают гарантированно эффективную разводку для каждой конкретного типа FPGA? Над этими мегафункциями трудились специалисты Альтеры, им и флаг в руки. А я лучше займусь прикладной сборкой из готового.

 

Нет, не так ставится вопрос. Я уже писал с самого начала, что попытался использовать в своем проекте готовые корки, написанные на Verilog и получил неудовлетворительную разводку. Пришлось вникать внутрь логики и переписать эти корки на ADHL. Сразу прекрасно заработало. Из этого я делаю вывод, неквалифицированно, как в моем случае, использовать чужие модули на Verilog - невозможно. А вникать в тонкости Verilog единственно для того, чтобы править чужие модули, мне представляется неразумной тратой времени.

Вы 1024 раза правы, остальные кто используют верилог или вхдл как раз и есть ламеры

вопрос только возник в связи с

Над этими мегафункциями трудились специалисты Альтеры,

и с

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

 

1)готовые корки надо полагать были написаны тоже в альтере?

2) вас просили переписать эквивалентные модули как на ахдл так и на верилог. каков результат?

 

з.ы. Дурят нашего брата, ой как дурят то ниос подсунут то верилог какой то.

[Maverick_ 15]

Вы 1024 раза правы, остальные кто используют верилог или вхдл как раз и есть ламеры

вопрос только возник в связи с

Над этими мегафункциями трудились специалисты Альтеры,

и с

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

 

1)готовые корки надо полагать были написаны тоже в альтере?

2) вас просили переписать эквивалентные модули как на ахдл так и на верилог. каков результат?

 

з.ы. Дурят нашего брата, ой как дурят то ниос подсунут то верилог какой то.

 

Позвольте мне с Вами не согласиться :(

 

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

1. Он предназначен только для микросхем Altera

2. Программное обеспечение подходит только фирмы Altera (насколько мне известно)

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

 

З.Ы. Это просто мое мнение.

[Postoroniy_V 0]

Позвольте мне с Вами не согласиться :(

 

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

1. Он предназначен только для микросхем Altera

2. Программное обеспечение подходит только фирмы Altera (насколько мне известно)

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

 

З.Ы. Это просто мое мнение.

да нет же! говорю вам ахдл это будущее! вот читал что в моделсим будет его поддержка

в 2009 году 30 февраля будет релиз..как пить дать

 

 

2 Maverick то было типа сарказма :laughing:

2 all и модератор.....ИМХО имеет место рецидив с темой "Не дурят ли нашего брата"

[Maverick_ 15]

да нет же! говорю вам ахдл это будущее! вот читал что в моделсим будет его поддержка

в 2009 году 30 февраля будет релиз..как пить дать

 

 

2 Maverick то было типа сарказма :laughing:

2 all и модератор.....ИМХО имеет место рецидив с темой "Не дурят ли нашего брата"

 

:) :) :) ;)

Как я сразу не понял сарказма!?

:) :) :) ;)