[vladimir_f 0]

Здравствуйте, уважаемое сообщество.

 

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

Warning: Timing Analysis is analyzing one or more combinational loops as latches

 

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

Но если речь идет всего о двух элементах ЛА3, на который собран триггер?

 

Куда уж проще то?

 

Код проекта:

Library IEEE;
Use     IEEE.std_logic_1164.all;
ENTITY LA3 IS
    port(    
        IN1: In    STD_LOGIC;    --  
        IN2: In    STD_LOGIC;    --  
        OUT1: Out   STD_LOGIC);    --
END ENTITY;
ARCHITECTURE StrLA3 OF LA3 IS
BEGIN
--OUT1 <= IN1 nand IN2;
OUT1 <= not ( IN1 and IN2 );
END ARCHITECTURE;

Library IEEE;
Use     IEEE.std_logic_1164.all;
ENTITY BPR1 IS
    port( out1:    Out   STD_LOGIC;
          out2:    Out   STD_LOGIC;
        
        in1:    In    STD_LOGIC;
        in2:    In    STD_LOGIC);
END ENTITY;

ARCHITECTURE STRBPR1 OF BPR1 IS
COMPONENT LA3 IS
    port(IN1: In STD_LOGIC;IN2: In STD_LOGIC;OUT1: Out STD_LOGIC);
END COMPONENT;

Signal    LA3_1_in1    :STD_LOGIC;
Signal    LA3_2_in1    :STD_LOGIC;
Signal    LA3_1_out    :STD_LOGIC;
Signal    LA3_2_out    :STD_LOGIC;

BEGIN
LA3_1_in1 <= in1;
LA3_2_in1 <= in2;


LA3_1:    LA3    PORT MAP(LA3_1_in1, LA3_2_out, LA3_1_out);
LA3_2:    LA3    PORT MAP(LA3_2_in1, LA3_1_out, LA3_2_out);

out1 <= LA3_1_out;
out2 <= LA3_2_out;
END ARCHITECTURE;

 

В общем смысл ошибки понятен, quartus не может определить некоторые состояния схемы, тем самым создавая защелки. При этом идет генерация на выходах.

 

Если схемно нарисовать такую же схему, генерация не убирается. Правда удалось таки убрать генерацию при изменении назначенных пинов ПЛИС.

Но это же не выход?

[sazh 3]

Если схемно нарисовать такую же схему, генерация не убирается. Правда удалось таки убрать генерацию при изменении назначенных пинов ПЛИС.

 

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

Если посмотреть в Technology map viewer, там больше чем два ЛА3 получается.

 

[almost 0]

А что без клоков? Попробуйте сделать все операции по клоку.

[vladimir_f 0]

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

Если посмотреть в Technology map viewer, там больше чем два ЛА3 получается.

Вот и я не понимаю откуда) Technology map viewer посмотрю завтра на работе. Но вроде как ничего лишнего там нет. Но проверю обязательно.

 

А что без клоков? Попробуйте сделать все операции по клоку.

Если честно не совсем понимаю, что вы имеете ввиду(

OUT <= I21 nand IN2;

Что здесь синхронизировать? И с чем?

 

Дело все в том, что это лишь малый пример реализации вызываемых схемой генераций. Отдельно от большого проекта.

В главном же проекте таких комбинаторных петель множество. И они состоят из множества узлов. Максимально было 60 узлов.

Если удастся разобраться с этой ситуацией, разберусь и с остальными.

[sazh 3]

Максимально было 60 узлов.

Если удастся разобраться с этой ситуацией, разберусь и с остальными.

 

Глухой номер. Если это Вы реализацию на микросхемах среднего уровня интеграции в лоб на FPGA переводите.

Даже 20 лет назад использовали типа ТМ2. И только отдельные субьекты корпуса экономили, используя неиспользуемые вентили в ЛА3. (Никто не знал в каком состоянии они по включению питания окажутся)

[des00 25]

TC, проще, быстрее и лучше переписать этот проект с использованием современных подходов к разработке

[vladimir_f 0]

В Technology map viewer ничего сверхнового не увидел, все так, как и должно быть по схеме.

 

TC, проще, быстрее и лучше переписать этот проект с использованием современных подходов к разработке

К сожалению я с вами согласен, а начальство имеет другое мнение.

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

И вот решили в эту прогу добавить новый функционал. Прога должна сама генерировать код VHDL, который будет полностью соответствовать схеме.

Далее понятно зачем это все нужно.

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

 

По теме: итак я понимаю, другого способа убрать комбинаторные петли кроме как менять схему нет? Это ладно, допустим это комбинаторная петли на одном узле. Тут логику поменять просто. Как быть с петлями размером в 60 узлов?

Изменено 22 июля, 2011 пользователем vladimir_f

[des00 25]

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

И вот решили в эту прогу добавить новый функционал. Прога должна сама генерировать код VHDL, который будет полностью соответствовать схеме.

Далее понятно зачем это все нужно.

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

вот как раз и скажите им, что VHDL был разработан для военных и лучше на нем переписать ваши схемы (тестирование то они все равно будут проходить), а не делать генератор непонятно откуда.

Их схемы вытаскиваете функционал, затем реализуете его на языке и проверяете через уже разработанные тесты. ИМХО это лучше чем один в один переносить схемы.

 

[iosifk 3]

К сожалению я с вами согласен, а начальство имеет другое мнение.

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

На самом деле неправильная постановка задачи неминуемо приведет к неправильному результату.

"Перерисовать схему" - это 30-40% трудозатрат... 70% сделать так, чтобы она работала... Но и это не гарантируется при "перерисовывании". Мучений будет довольно мнего, вот только начальство сейчас это понять не хочет...

Ну так Вы ему объясните. Примерно так: 1 постаянная времени дает 30%, 3 постоянных - 95% приближения экспоненты к результату. Но это только 5 % ошибок. Хотите 0,1%? А сколько это будет в "постаянных времени"? Нарисуйте эту картину Вашим командирам...

И сравните со временем на "переделку" проекта. Возможно Вам удастся 50/50 % ... Вот здесь и будет экономия...

 

 

PS. Термин "функционал" - такого на родном языке нет, это жаргон...

[sazh 3]

то становится понятно насколько стары схемы и какого они размера.

Как быть с петлями размером в 60 узлов?

 

Старых схем не бывает. И это тот случай - когда размер не имеет значения.

Вы сначала поинтересуйтесь, а разрешат ли Вам такой перевод или изменение функционала.

Тем более, что под это выпущено море документации стариканами, которых уже нет.

Может и функционал Вами давно потерян.

А с петлями все просто. В том же асинхронном стиле ваяйте. На той же элементной базе.

[Maverick_ 15]

Просто совет.

Если Вы будете просто перерисовывать схему, разработанную давно на дискретной логике, на ПЛИС можете получить ерунду. Потому что некоторые принципы разработки цифровых схем на дискретной логике и на ПЛИС отличаются. И на отладку нарисованной схемы потратите большое количество времени.

Возьмите схему и опишите ее по всем правилам разработки цифровых схем на ПЛИС, соблюдая временные соотношения сигналов.

 

[vladimir_f 0]

Просто совет.

Спасибо за совет.

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

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

В принципе он компилируется с ворнингами, но ПЛИС неимоверно много потребляет ток, оно и понятно тк схема уходит в "разнос"(происходит генерация на некоторых её участках).

Задача: избавится от этих комбинаторных петель.

 

А с петлями все просто. В том же асинхронном стиле ваяйте. На той же элементной базе.

Не могли бы Вы пояснить данное высказывание. Ведь именно по такому принципу и составляется описательная часть схемы. Именно из-за асинхронного "стиля" и возникают петли. Я правильно понимаю ситуацию?

[sazh 3]

Именно из-за асинхронного "стиля" и возникают петли. Я правильно понимаю ситуацию?

 

Стиль проектирования, на который Вы напоролись, проистекает из возможностей элементной базы той поры.

Жесткая экономия как по количеству микросхем на плате, так и потреблению толкала разработчиков на использование так называемой асинхронщины. Т.Е. например у Вас есть ПЗУ. На его выходе надо бы регистр поставить для устранения пичков. А на плате уже места нет. Но плат то 60. Вот на задержках элементов (а они известны были для всего используемого температурного диапазона) лепились разрешающие импульсы, когда данные на выходе этого ПЗУ уже устаканены и передавались на например на 60 плату.

Такую схемную реализацию в лоб на программируемую логику не перенести. Да и ресурсы позволяют делать синхронные схемы (работающие на сетке частот с прогнозируемыми задержками)

Функционально этот триггер легко реализовать на примитиве dff.

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

Основная проблема у Вас будет в согласовании всего этого с заказчиком.

И в деньгах на весь комплекс повторных испытаний и выпуск документации, согласованной с заказчиком.

[almost 0]

Если честно не совсем понимаю, что вы имеете ввиду(

 

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

 

[vladimir_f 0]

В том плане что "эффект гонок" на который, насколько я понял, вы напоролись берется из за разный длин линий.

Именно так. Спасибо за совет, не сразу вас понял. Но такой вариант "кое-кого" не устраивает.

 

В общем спасибо всем ответившим, в особенности sazh. Немного "просветился", буду думать дальше.

Всем удачи.

Изменено 22 июля, 2011 пользователем vladimir_f