Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Помогите избавиться от dangling'а
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
fylhtq2u
После компиляции программы для процессора picoblaze создается файл proc_ROM:

CODE
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
library unisim;
use unisim.vcomponents.all;

entity proc_rom is
Port ( address : in std_logic_vector(9 downto 0);
instruction : out std_logic_vector(17 downto 0);
clk : in std_logic);
end proc_rom;

architecture low_level_definition of proc_rom is
attribute INIT_00 : string;
...
attribute INITP_07 : string;
--
-- Attributes to define ROM contents during implementation synthesis.
--
attribute INIT_00 of ram_1024_x_18 : label is "09FF003A09FF030002010F020E010D0000340F460E410D0A00340F390E300D00";
...
attribute INITP_07 of ram_1024_x_18 : label is "C000000000000000000000000000000000000000000000000000000000000000";
--
begin
--
--Instantiate the Xilinx primitive for a block RAM
ram_1024_x_18: RAMB16_S18
port map( DI => "1111111111111111",
DIP => "11",
EN => '1',
WE => '0',
SSR => '0',
CLK => clk,
ADDR => address,
DO => instruction(15 downto 0),
DOP => instruction(17 downto 16));
--
end low_level_definition;


При синтезе удаляется входные сигналы для блочной памяти: DI и DIP. И в МАП затем выдается сообщение о том, что

WARNING:PhysDesignRules:812 - Dangling pin <DIA0> on
block:<FILTER_1/CONTROL_1/PROGRAM_1/RAM_1024_X_18/FILTER_1/CONTROL_1/PROGRAM_
1/RAM_1024_X_18>:<RAMB16BWE_RAMB16BWE>.


Пробовал применить в файле proc_rom такой вот аттрибут

Код
    attribute BOX_TYPE: string;
    attribute BOX_TYPE of ram_1024_x_18: label is "BLACK_BOX";


Но он тоже не помог. Синтезатор все равно выкидывает входные сигналы для памяти.

Подскажите как это можно исправить, плиз.
Sefo
Я не специалист по Xilinx, но, видимо, на этот варнинг можно не обращать внимания - ROM и не должна иметь входных сигналов для данных. Но т.к. ROM описывается на основе RAM блока у которого эти сигналы есть, вот и получается, что в режиме ROM ппамяти у него остаются "болтаться" ножки для входных данных.

В конце концов, можно самостоятельно вставить вместо ram_1024_x_18 что-нибудь более похожее на настоящую ROM-память.
fylhtq2u
Цитата(Sefo @ Sep 10 2009, 00:28) *
Я не специалист по Xilinx, но, видимо, на этот варнинг можно не обращать внимания ...


Да, в процессе синтеза и в par на это можно не обращать внимания, но при прошивке ПЛИС bitgen сообщает о предупреждении, что некоторые контакты примитива не подключены. А в таком случае, при прошивке ПЛИС, я не уверен, что с ней будет все в порядке. До этого прошивал ПЛИС и bitgen не выдавал никаких предупреждений. ПЛИС работала как и при моделировании.


Цитата(Sefo @ Sep 10 2009, 00:28) *
В конце концов, можно самостоятельно вставить вместо ram_1024_x_18 что-нибудь более похожее на настоящую ROM-память.


1.ROM-память в Spartan-3 можно построить только на рассыпухе и каждый блок имеет только 16 бит памяти. Команды же для процессора имеют ширину 18 бит. У меня для процессора 311 команд, т.е. мне потребуется около 600 LUTов. Будут раскиданы по всей ПЛИС.
2.Машинный код для процессора компилируется отдельной программой, а исправляеть его каждый раз не хочется.


На BRAM постоянно подается сигнал чтения (EN = '0') и так как никакие данные записываться не будут, то синтезатор и убирает входные проводники. Из-за чего потом появляется предупреждение. Я не знаю какой аттрибут надо применить, чтобы синтезатор и map не трограли входные сигналы.

В cgd написано, что необходимо использовать аттрибут "keep". Но я не знаю как правильно его применить к такому коду

Код
begin
--
  --Instantiate the Xilinx primitive for a block RAM
  ram_1024_x_18: RAMB16_S18
  port map(    [b]DI => "1111111111111111",
              DIP => "11",[/b]
               EN => '1',
               WE => '0',
              SSR => '0',
              CLK => clk,
             ADDR => address,
               DO => instruction(15 downto 0),
              DOP => instruction(17 downto 16));
--
Boris_TS
Попробовал я разные варианты создания BlockROM для Spartan-3A, наиболее интересным оказался вариант от Core Generator – т.к. и для этого варианта выдаются все теже сообщения, что и у Вас.

У Xilinx я не нашел рекомендуемого поведения на эти Warnings. Поэтому спросите у самого Xilinx, что делать, если ругается даже на код, рожденный Core Generator'ом.
Удалось найти только аналогичные ошибки, но про выходные сигналы: http://www.xilinx.com/support/answers/24846.htm

Цитата(fylhtq2u @ Sep 9 2009, 23:52) *
CODE
attribute INIT_00 : string;
...
attribute INITP_07 : string;
--
-- Attributes to define ROM contents during implementation synthesis.
--
attribute INIT_00 of ram_1024_x_18 : label is "09FF003A09FF030002010F020E010D0000340F460E410D0A00340F390E300D00";
...
attribute INITP_07 of ram_1024_x_18 : label is "C000000000000000000000000000000000000000000000000000000000000000";
--
begin
--
--Instantiate the Xilinx primitive for a block RAM
ram_1024_x_18: RAMB16_S18
port map( DI => "1111111111111111",
DIP => "11",
EN => '1',
WE => '0',
SSR => '0',
CLK => clk,
ADDR => address,
DO => instruction(15 downto 0),
DOP => instruction(17 downto 16));
--
end low_level_definition;

И я что-то не уловил: А зачем Вы используете attribute INIT (именно как атрибут) ? - Ведь у RAMB16_S18 есть Generic INIT - делает всё тоже самое, только без warnings при синтезе.
fylhtq2u
Просмотрел vhd-файлы после каждой процедуры. translate пока не трогает входные сигналы. В MAP входные сигналы были уже удалены.


В отчете MAP сначала писалось предупреждение

WARNING:LIT:243 - Logical network DIA0 has no load,

а после него

WARNING:PhysDesignRules:812 - Dangling pin <DIA0> on
block:<FILTER_1/CONTROL_1/PROGRAM_1/RAM_1024_X_18/FILTER_1/CONTROL_1/PROGRAM_
1/RAM_1024_X_18>:<RAMB16BWE_RAMB16BWE>.


Нашел на Xilinx что-то подобное, но для Spartan-2

http://www.xilinx.com/support/answers/30390.htm

Там также появлялось предупреждение "LIT:243" и сказано, что ее можно безопасно игнорировать.
После же такого предупреждения может появиться следующее предупреждение

WARNING:PhysDesignRules:812

И далее сказано, что это сообщение также можно проигнорировать.
У меня они появлялись в таком же порядке. Правда примитив совсем другой.

Просмотрел другие BRAM в проекте и там не все входные сигналы использовались, а только часть. Возможно это "болтание" ни как не повлияет на работоспособность ПЛИС, но мне все же хочется избавиться от удаления входных сигналов. Можно ли это как-нибудь сделать?




P.S. Хотя есть несколько другой "изращенный" вариант. Подать сигнал "записи" на BRAM. Хотя сделать так, чтобы логически на этом сигнале единица появиться не смогла. Тогда ISE будет "думать", что запись в BRAM когда-нибудь произойдет и не будет удалять входные сигналы.
des00
Цитата(fylhtq2u @ Sep 15 2009, 15:45) *
Просмотрел другие BRAM в проекте и там не все входные сигналы использовались, а только часть. Возможно это "болтание" ни как не повлияет на работоспособность ПЛИС, но мне все же хочется избавиться от удаления входных сигналов. Можно ли это как-нибудь сделать?

P.S. Хотя есть несколько другой "изращенный" вариант. Подать сигнал "записи" на BRAM. Хотя сделать так, чтобы логически на этом сигнале единица появиться не смогла. Тогда ISE будет "думать", что запись в BRAM когда-нибудь произойдет и не будет удалять входные сигналы.


ИМХО х...ей маетесь. ИСЕ честно вас информирует, а не говорит об ошибке, что на блочной памяти не используется часть входов. И это на самом деле так. Чего тут бороть то?

Таких предупреждений синтезатор выдает туеву хучу. И на автоматическое приведение разрядности (verilog) и на регистры которые были удалены из-за отсутствия fanout/объединения триггеров при оптимизации/перемещения триггеров в hardware блоки и на порты ввода/вывода на которые подан постоянный уровень и т.д. и т.п. вы что собираетесь все эти предупреждения бороть? Ну тогда вы долго будете буксовать на одном месте, что не скажется хорошо на вашей скорости работы.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.