Возникла следующая фича при проектировании в ISE. Сделал я такой модуль - есть умножитель (A,B 18-и битные входы, P 35-и битный выход) и есть BRAM (RAMB16_S18_S18). Необходимо выходные данные одного из портов брамки подцепить на вход умножителя. Раньше память коэффициентов была вообще 32-х битная и 32-х битный умножитель был собран из 4-х 18х18.
Смысл проблемы в том что пласе-роут ни в какую не хочет использовать брамки расположенные рядом с умножителями. Сейчас у меня получился только один вариант RAMB16_S18_S18 + MULT18X18 и непосредственное задание физразмешения в ucf файле через LOC.
Собственно вопрос можно ли так описать эту конструкцию чтобы пласе-роут сам нормально их разместил рядом без описания привязки в ucf.

хмм а код можно посмотреть ? и настройки блоков ДСП ? и семейство огласите ?

Даже вот такой код - ниже описывать уже некуда, и тот пласе-роут надежно (ни раз на раз, а чтоб от трансляции к трансляции) размещать рядом нихотит. Таблетка XC2VP20, ISE 6.2.03i, опции по умолчанию, какие-то вроде пробовал менять, но без LOC/RLOC в ucf так ничего и не получилось.

entity bram_mult is
Port ( ADDRCOEFF : in std_logic_vector(9 downto 0);
A : in std_logic_vector(17 downto 0);
CLK : in std_logic;
RST : in std_logic;
P : out std_logic_vector(35 downto 0));
end bram_mult;

architecture RTL of bram_mult is

component RAMB16_S18_S18
port (DIA : in STD_LOGIC_VECTOR (15 downto 0);
DIB : in STD_LOGIC_VECTOR (15 downto 0);
DIPA : in STD_LOGIC_VECTOR (1 downto 0);
DIPB : in STD_LOGIC_VECTOR (1 downto 0);
ENA : in STD_logic;
ENB : in STD_logic;
WEA : in STD_logic;
WEB : in STD_logic;
SSRA : in STD_logic;
SSRB : in STD_logic;
CLKA : in STD_logic;
CLKB : in STD_logic;
ADDRA : in STD_LOGIC_VECTOR (9 downto 0);
ADDRB : in STD_LOGIC_VECTOR (9 downto 0);
DOA : out STD_LOGIC_VECTOR (15 downto 0);
DOB : out STD_LOGIC_VECTOR (15 downto 0);
DOPA : out STD_LOGIC_VECTOR (1 downto 0);
DOPB : out STD_LOGIC_VECTOR (1 downto 0)
);
end component;

component MULT18X18S
port (P : out STD_LOGIC_VECTOR (35 downto 0);
A : in STD_LOGIC_VECTOR (17 downto 0);
B : in STD_LOGIC_VECTOR (17 downto 0);
C : in STD_LOGIC;
CE : in STD_LOGIC;
R : in STD_LOGIC
);
end component;

signal MULT_B_IN_i : std_logic_vector(17 downto 0);

begin

coeff_bram_inst : RAMB16_S18_S18 port map(
DIA => (others => '0'),
DIB => (others => '0'),
DIPA => "00",
DIPB => "00",
ENA => '1',
ENB => '1',
WEA => '0',
WEB => '0',
SSRA => RST,
SSRB => RST,
CLKA => CLK,
CLKB => CLK,
ADDRA => ADDRCOEFF,
ADDRB => (others => '0'),
DOA => MULT_B_IN_i(15 downto 0),
DOB => open,
DOPA => MULT_B_IN_i(17 downto 16),
DOPB => open
);

mult_inst : MULT18X18S port map(
P => P,
A => A,
B => MULT_B_IN_i,
C => CLK,
CE => '1',
R => RST
);

end RTL;

Хммм констрейны выполняються ?
я бы предложил вам посмотреть на тайминги сего без рлоков и с рлоками, т.к.
если мне память не изменяет умножители и память стоят "паравозиком", т.е. стоит пара умножителей и потом стоят блоки памяти (у V4 точно так сделанно) и мапер считает что получаеться большие задержки по разводке.

можно еще попробывать софтом другим воспользоваться "по новее".

Попробую потранслировать в ISE 7 может там подхватит, а суть проблемы такова, что если еспользуется схема с умножителями и брамками, получается следующая питрушка. Когда прасе-роут размещает схему, он в схеме брамка+умножитель может поставить какую либо брамку и какой либо умножитель из тех которые он посчитал будет удобней использовать (лишь бы выполнялись констрейны) и соединить их. По архитектуре плис (в частности Virtex2 Pro) брамка и умножитель стоят рядом специально для построения быстрых схем (аля фильтр). При таком несовсем корректном размещении получается что свободную брамку стоящую рядом с занятым умножителем уже нельзя корректно использовать (опять же ругается пласе-роут). Вообщем ресурсы едятся двойными темпами (имеется ввиду брамки).

Как вариант, можно засунуть RPM макрос в нетлист корки.
http://forum.electronix.ru/index.php?showtopic=2136&hl=rpm

Может я конечно что-то не понял, но Floorplaner производит размещение определенной entity архитектуры в прямоугольной области, определяя размер необходимый для размещения, и далее я устанавливаю эту часть в заданную область клистала, т.е. делается RLOC_ORIGIN размещение с заданными координатами и от трансляции к трансляции без нового переразмещения не меняется. Таким образом floorplaner может и даст объединить брамку и умножитель но он привяжет их к определенному месту (хотя этого делать не надо было), тогда уже лучше RLOC/U_SET для умножителя и брамки.

Вы почитаейте внимательнее пост по ссылке, RPM макрос позволяет определять взаимное расположение логики не привязываясь к определенному месту на кристалле. Единственное что меня смущает, как пройдет процесс взаимного привязывания разнородных структур.

В доке от Xilinxa указано что для интеграции RAMBLOCK и MULT18X18 у них должны быть общими некоторые связи в доке они указаны дока ug002.pdf правда для VirtexII но я думаю что остальные не слишком отличаются, там указано что если объеденить не все указанные связи он их раскижает по разным местам.

Routing with BlockRAM
The following input pins are shared among adjacent BlockRAM and multiplier :
• RAMB16 MULT18x18
• DIA16 A0
• DIA17 A1
• DIA18 A2
• DIA19 A3
• DIA20 A4
• DIA21 A5
• DIA22 A6
• DIA23 A7
• DIA24 A8
• DIA25 A9
• DIA26 A10
• DIA27 A11
• DIA28 A12
• DIA29 A13
• DIA30 A14
• DIA31 A15
• DIB16 B0
• DIB17 B1
• DIB18 B2
• DIB19 B3
• DIB20 B4
• DIB21 B5
• DIB22 B6
• DIB23 B7
• DIB24 B8
• DIB25 B9
• DIB26 B10
• DIB27 B11
• DIB28 B12
• DIB29 B13
• DIB30 B14
• DIB31 B15
If the above BlockRAM and multiplier pins do not have common source, the implementation
tools will not place the blocks adjacently.

Хреново что примера нет

Насколько я понял напрямую с ближайшей BRAM идут только старшие 16 бит (16:31) с каждого из портов
поэтому и глюки с размещением если снимать с 0 - 15. Удачи

И подходят под это походу только BRAM16_S36_S36 так только у них такие порты(((

to tegumay

действительно интересная инфа, я по сайту ксалинкса шарился шарился так ничего подобного и не нашел, обязательно попробую. Собственно в этом и была задача, описать данную конструкцию без всяких дополнительных телодвижений (RPM макросы, RLOC в ucf).

Более того, блин такую собаку ксалинк подложил, у в4 в дсп слайсе третий вход C - общий для двух дсп блоков ((
что мещало сделать каждому свое хз

фалик этот был с сайта Xilinxa, User Guide хреново что не к каждой серии они такие файлики пишут
кстати именно из-за того что они его выпустили не сразу были проблемы с согласование LVPECL'a так как он согласуется не так как предписано стандартом, а узнать это можно было токмо из него