[files 0]

FPGA Altera Cyclone до 4-го поколения включительно имеют в составе LE 4-входовой LUT. В арифметическом режиме этот LUT фактически интерпретируется как два 3-входовых LUT-а, один из которых реализует функцию суммирования, а другой переноса. Причем оба эти 3-входовых LUT-а имеют каждый свой отдельный выход.

 

Вопрос к знающим людям: есть ли возможность реализовать на арифметической конфигурации LE (с двумя 3-входовыми LUT-ами) две произвольные логические функции от трех общих переменных?

 

[ViKo 1]

А вы проверьте сами, сделайте то, что вам нужно.

[dxp 33]

FPGA Altera Cyclone до 4-го поколения включительно имеют в составе LE 4-входовой LUT. В арифметическом режиме этот LUT фактически интерпретируется как два 3-входовых LUT-а, один из которых реализует функцию суммирования, а другой переноса. Причем оба эти 3-входовых LUT-а имеют каждый свой отдельный выход.

Если судить по картинке LUT в арифметическом режиме (С4 handbook), то выход-то каждый под-LUT имеет отдельный, но вот наружу из них отдаётся только один (мультиплексор стоит), а выход второго ещё напрямую зацеплен на cout, т.е. подаётся на carry-chain этого LAB, на вход сin следующего LE. Поэтому как-то не очень понятно, как вы хотите использовать оба выхода одновременно как выходы разных функций.

 

Вопрос к знающим людям: есть ли возможность реализовать на арифметической конфигурации LE (с двумя 3-входовыми LUT-ами) две произвольные логические функции от трех общих переменных?

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

 

А что у вас за потребность такая? Ресурсов не хватает (хочется выжать из чипа всё "до капли") или чисто академический интерес?

[SM 0]

Вопрос к знающим людям: есть ли возможность реализовать на арифметической конфигурации LE (с двумя 3-входовыми LUT-ами) две произвольные логические функции от трех общих переменных?

 

Возможность есть - для этого есть примитив CARRY_SUM (в старых версиях был только примитив CARRY) - используя его, можно указать, какая из функций идет на cout, какая на sum. Но! При этом надо учитывать физические ограничения возможности трассировки сигналов с выхода cout (да и на вход cin тоже), поэтому синтезатор может с легкостью Ваш CARRY_SUM выкинуть.

[dvladim 0]

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

Даёт. В исходник вставляете элемент cycloneii_lcell_comb #(...) name (...); и Квартус его не оптимизирует и вставляет "как есть". Маску рисуете сами. На этом хаке сделаны некоторые мегафункции типа ALTDQ ALTDDIO.

 

Но:

1. Как и говорил SM: лучше через примитив.

2. Один из выходов идёт только на вход следующего LUT. Так что применение оч. ограничено.

[files 0]

Возможность есть - для этого есть примитив CARRY_SUM (в старых версиях был только примитив CARRY) - используя его, можно указать, какая из функций идет на cout, какая на sum. Но! При этом надо учитывать физические ограничения возможности трассировки сигналов с выхода cout (да и на вход cin тоже), поэтому синтезатор может с легкостью Ваш CARRY_SUM выкинуть.

Огромное спасибо за комментарии.

 

Однако относительно примитива CARRY_SUM не все понятно.

Я правильно понимаю принцип работы этого примитива: сигналы, которые я подаю на входы sin, cin разведуться на выходы суммы и переноса логического элемента LE FPGA?

 

У меня такой разводки при помощи примитива CARRY_SUM добиться не удалось. Оба выхода LUT-а подключаются к выходам суммы, а цепь переноса оказывается не задействована.

 

Или я неправильно понял, как работает примитив?

 

 

 

[SM 0]

Поняли все правильно. А то, что не получается - это значит, что физически нельзя развести то, что Вы хотите и куда хотите, с физического выхода переноса ячейки.

 

Ну, либо, у Вас в опциях где-то стоит игнорирование CARRY

[files 0]

Поняли все правильно. А то, что не получается - это значит, что физически нельзя развести то, что Вы хотите и куда хотите, с физического выхода переноса ячейки.

 

Ну, либо, у Вас в опциях где-то стоит игнорирование CARRY

Спасибо за комментарий.

 

Я вот сделал такую примитивную схему.

 

Ожидалось, что:

– верхний элемент И (inst3) и элемент ИЛИ (inst4) упакуются в один LUT элемента, находящегося в арифметическом режиме;

– второй элемент И (inst5) примет данные из этого LUT-а через цепь переноса;

– всего для реализации этой схемы будет задействовано 2 LUT-а.

У меня были правильные ожидания относительно этой схемы, или я что-то делаю не так?

 

Реально же схема размещается в 3-х LE (каждый логический элемент в отдельном LUT), все LE в нормальном режиме, цепь переноса не задействована.

 

Среда разработки – Quartus 13.0. Опции игнорирования CARRY вроде нет

Изменено 27 августа, 2014 пользователем files

[SM 0]

По идее, должно упаковаться в два лута. Смотрите опции....

 

У меня, кстати, были случаи, когда свежий квартус не упаковывал как мне надо, как не танцуй вокруг него, а какой-то древний - делал без проблем заказанное...

[files 0]

По идее, должно упаковаться в два лута. Смотрите опции....

 

У меня, кстати, были случаи, когда свежий квартус не упаковывал как мне надо, как не танцуй вокруг него, а какой-то древний - делал без проблем заказанное...

Как я опции не крутил, все равно при синтезе этой схемы выдает сообщение «Ignored 1 CARRY_SUM primitive» и Quartus 13.0 и Quartus 8.1.

 

Может, у кого есть мысли, что не так?

 

 

[SM 0]

Может, у кого есть мысли, что не так?

Видимо, мой тот случай, когда свежий (на то время, наверное, 9-й) квартус упрямо выкидывал примитив, а 7-ой собрал все по моему заказу.

 

Попробуйте, разве что, еще оставшуюся часть схемы (выход AND3 которая внизу справа) пропустить через CARRY_SUM, sin->sout, а cin не задействовать.

 

А потом останется только техподдержка альтеры.