Перейти к содержанию
    

Помогите избавиться от dangling'а

После компиляции программы для процессора picoblaze создается файл proc_ROM:

 

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";

 

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

 

Подскажите как это можно исправить, плиз.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

В конце концов, можно самостоятельно вставить вместо ram_1024_x_18 что-нибудь более похожее на настоящую ROM-память.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не специалист по Xilinx, но, видимо, на этот варнинг можно не обращать внимания ...

 

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

 

 

В конце концов, можно самостоятельно вставить вместо 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)); 
--

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробовал я разные варианты создания BlockROM для Spartan-3A, наиболее интересным оказался вариант от Core Generator – т.к. и для этого варианта выдаются все теже сообщения, что и у Вас.

 

У Xilinx я не нашел рекомендуемого поведения на эти Warnings. Поэтому спросите у самого Xilinx, что делать, если ругается даже на код, рожденный Core Generator'ом.

Удалось найти только аналогичные ошибки, но про выходные сигналы: http://www.xilinx.com/support/answers/24846.htm

 

    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 при синтезе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Просмотрел 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 когда-нибудь произойдет и не будет удалять входные сигналы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...