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

Вопрос к

 

А простенький код на этот случай покажите?

А то использовать как-то стрёмно, мало ли как синтезатор это "скушает", сам подставив нужные состояния по коду Грея.

Хорошо, а если ручками делать? Интересует просчитывание переходов в различные места. Поясню: ведь не всегда переход осуществляется из первого состояние во второе (001 -> 011) иногда надо к третьему (001 -> 010). А это уже "иголка".

 

1) "ведь не всегда переход осуществляется из первого состояние во второе (001 -> 011) иногда надо к третьему (001 -> 010). А это уже "иголка"" - ну не всегда везёт и всё просто и автоматически, но иногда так получается...

 

2) Иногда можно синтезатор заставить делать кодировку определённого вида, если он конечно умеет....

 

3) Ручное кодирование состояний автомата в Verilog:

 

reg [1:0] FSM_seq;
reg [1:0] FSM_next;

parameter [1:0]
    STATE0 =0,
    STATE1 =1,
    STATE2 =2,
    STATE3 =3;

always @ (FSM_seq)
begin 
    case (FSM_seq)
    
        STATE0  : FSM_next <=  STATE1;
        STATE1  : FSM_next <=  STATE2;
        STATE2  : FSM_next <=  STATE3;
        default   :  FSM_next <=  STATE0;
                                
    endcase
end

always @ (posedge clk)
begin
       FSM_seq <= FSM_next;    
end

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


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

... Ручное кодирование состояний автомата в Verilog:

 

reg [1:0] FSM_seq;
reg [1:0] FSM_next;

parameter [1:0]
    STATE0 =0,
    STATE1 =1,
    STATE2 =2,
    STATE3 =3;

always @ (FSM_seq)
begin 
    case (FSM_seq)
    
        STATE0  : FSM_next <=  STATE1;
        STATE1  : FSM_next <=  STATE2;
        STATE2  : FSM_next <=  STATE3;
        default   :  FSM_next <=  STATE0;
                                
    endcase
end

always @ (posedge clk)
begin
       FSM_seq <= FSM_next;    
end

 

Почти полный функциональный аналог(различия только в старте):

`define state @( posedge clk )

always `state 
begin
    /* STATE0 */ `state;  
    /* STATE1 */ `state;  
    /* STATE2 */ `state;  
    /* STATE3 */   
end

 

 

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


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

может и грамотный, но после таких фраз

Ну Salеmi вроде должен понимать что пишет...

Имеется ввиду ситуация, что

если выходы с автомата не triggered, по нашему сказать, не являются выходами с синхронного элемента, а

результат комбинационной схемы, то может быть и 6 нан path delay по выходу модуля, делее, например, по входу другого модуля, тоже комбинационная схема

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

Но если задан базоывй констрейн period на 10 нан, то timing analyzer должен выдать ошибку. Тем не менее,

что бы исключить такую ситуацию, рекомендуется чтобы выходы автомата были регистровыми.

 

 

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


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

Ну Salеmi вроде должен понимать что пишет...

Имеется ввиду ситуация, что

то что имеется в виду понятно, но автор забывает о том, что современные синтезаторы, особенно поддерживающие технологии Timing Driven Synthesis, Resynthesis, Logic Dublication и т.д. не рассматривают логику модулей безотносительно друг друга(а вы думали почему от vqm альтеровцы ушли ;)), логика выходов КА будет интегрирована в логику устройства, которым он управляет. В случае если цепи не лягут в нужные ограничения, начнется автоматический повторный синтез, что бы добиться результатов.

 

А погоня в КА за обязательными триггерами на выходе модуля, может привести к необходимости введения дополнительных состояний, усложнения логики переходов и т.д. ИМХО в современных плис правило "лучше день потерять, потом за 5 минут долететь" не всегда работает.

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


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

а вы думали почему от vqm альтеровцы ушли

А может, просто чтобы результваты синтеза(преобразование исходного HDL описания в набор базовых примитивов) нельзя было использовать "на стороне"?

 

 

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


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

А может, просто чтобы результваты синтеза(преобразование исходного HDL описания в набор базовых примитивов) нельзя было использовать "на стороне"?

их и так нельзя было использовать на стороне, т.к. они были построены на основе примитивов целевой фпга. разве что только в ручную переписать ovi_<fpga_series_name> ну и подсунуть ovi_lpm, ovi_altera_mf

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


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

Ну Salеmi вроде должен понимать что пишет...

Имеется ввиду ситуация, что

если выходы с автомата не triggered, по нашему сказать, не являются выходами с синхронного элемента, а

результат комбинационной схемы, то может быть и 6 нан path delay по выходу модуля, делее, например, по входу другого модуля, тоже комбинационная схема

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

Но если задан базоывй констрейн period на 10 нан, то timing analyzer должен выдать ошибку. Тем не менее,

что бы исключить такую ситуацию, рекомендуется чтобы выходы автомата были регистровыми.

 

"что бы исключить такую ситуацию, рекомендуется чтобы выходы автомата были регистровыми." - Извините конечно, но это грубое заблуждение.

Это забота тулзы - выполнение нужных задержек.

И ничего подобного не рекомендуется, не поможет и ненадо...

 

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

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

 

Изменено пользователем Torpeda

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


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

"что бы исключить такую ситуацию, рекомендуется чтобы выходы автомата были регистровыми." - Извините конечно, но это грубое заблуждение.

Поясните, будьте любезны.

 

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


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

Поясните, будьте любезны.

 

Это забота тулзы - выполнение нужных задержек.

 

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

На то тулза и нужна.

 

Даже если Вы пропустите все выходы с FSM через тригера, всё равно при Place & Route тул имеет право сделать розброс во времени между выходами этих тригеров (на конечных точках) в пределах 1CLK.

Это и есть принцип синхронного дизайна!

Изменено пользователем Torpeda

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


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

Это забота тулзы - выполнение нужных задержек.

 

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

На то тулза и нужна.

Вы не разу не получали отрицательный слак на клоковый констрейн?

Прощу прощения, говорю в терминах тулзовин xilinx, констрейн

TIMESPEC "TS_CLKX" = PERIOD "CLKX" xxx ns HIGH 50 %;

гарантирует, что задержка на распространение сигналов между всеми

синхронными элементами в данном клоковом домене, удовлетворяет заданному требованию.

Но вот вопрос, что вы будете делать, если этот констрейн не проходит?

 

IMHO, грубое заблуждение, слепо полагаться, что синтезатор сделает всю работу за вас.

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


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

Вы не разу не получали отрицательный слак на клоковый констрейн?

Прощу прощения, говорю в терминах тулзовин xilinx, констрейн

TIMESPEC "TS_CLKX" = PERIOD "CLKX" xxx ns HIGH 50 %;

гарантирует, что задержка на распространение сигналов между всеми

синхронными элементами в данном клоковом домене, удовлетворяет заданному требованию.

Но вот вопрос, что вы будете делать, если этот констрейн не проходит?

 

Причины отрицательных слаков могут быть весьма разнообразны.

 

Одной из них может быть то, что комбинаторные задержки >1CLK... Тогда возможным решением может быть как написано выше:

"Иногда, в весьма исключительно-ограниченных случаях, приходиться розбивать комбинаторику тригерами на 2 части - чтобы уменьшить комбинаторную задержку.

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

 

Кстати, это поможет только при SET-UP отрицательных слаках.

Изменено пользователем Torpeda

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


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

Одной из них может быть то, что комбинаторные задержки >1CLK..

Но это большое исключение, и относится оно скорее к самой комбинаторике, а не к FSM.... ."

Так вот об этом речь и идет, когда выход FSM формируется комбинаторикой плюс комбинаторика на входе другого модуля.

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

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

 

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


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

Так вот об этом речь и идет, когда выход FSM формируется комбинаторикой плюс комбинаторика на входе другого модуля.

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

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

 

А заблуждение - это потому, что :

 

1) вставление тригеров на выходах FSM исключает только комбинаторику самой FSM из бщей задержки.

А что будете делать когда декодер FSM имеет 1нс, вход другого модуля имеет входную комбинаторику с 20нс задержкой?

 

2) В технологиях <0.18 задержка определяется длинной проводом а не гейтами - т.е Placement & routing.

Как тут тригера по выходу FSM помогут?

 

3) Ваше решение ну никак не может быть общей рекомендацией при проектировании FSM.

Оно может помочь в очень ограниченно-специальных случаях.

 

------

Кстати, может если в вашем проекте выкинуть все ненужные тригера по каждому выходу FSM, то у тулзы места больше для оптимального Placement & routing появиться, и все слаки сами пропадут?

А-то кажеться мне, что количество таких "ненужных" тригеров даже больше количества нужных....

Изменено пользователем Torpeda

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


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

Так что то совсем дебри какие-то.

Давайте сначала. Ваш код.

 

reg [1:0] FSM_seq;
reg [1:0] FSM_next;

wire A;

parameter [1:0]
    STATE0 =0,
    STATE1 =1,
    STATE2 =2,
    STATE3 =3;

always @ (FSM_seq)
begin 
    case (FSM_seq)   
        STATE0  : FSM_next <=  STATE1; 
        STATE1  : FSM_next <=  STATE2; A = 1;
        STATE2  : FSM_next <=  STATE3; A = 0;
        default   :  FSM_next <=  STATE0;                                
    endcase
end
always @ (posedge clk)
begin
       FSM_seq <= FSM_next;    
end

Выход A not triggered. Результат комбинаторики.

reg [1:0] FSM_seq;
reg [1:0] FSM_next;

wire A;

parameter [1:0]
    STATE0 =0,
    STATE1 =1,
    STATE2 =2,
    STATE3 =3;

always @ (FSM_seq)
begin 
    case (FSM_seq)   
        STATE0  : FSM_next <=  STATE1; 
        STATE1  : FSM_next <=  STATE2; 
        STATE2  : FSM_next <=  STATE3; 
        default   :  FSM_next <=  STATE0;                                
    endcase
end
always @ (posedge clk)
begin
       FSM_seq <= FSM_next;    
end

assign A = ( FSM_seq == STATE1 )  ? 1 : 0

Выход A triggered. Выход с регистра.

 

Чем второй вариант лучше первого и Вы и я уже сказали по два раза каждый.

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

 

-----

По поводу проекта. 5 клоковых доменов, есть и передача импульсов и передача данных и обмен сигналами между автоматами из разных доменов.

Поверьте не один день бился с формальным подходом синтезатора и роутера к предлагаемой задаче.

Так что не все задачи можно решить слепо полагаясь на инструменты.

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


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

Так что то совсем дебри какие-то.

Давайте сначала. Ваш код.

 

-----

По поводу проекта. 5 клоковых доменов, есть и передача импульсов и передача данных и обмен сигналами между автоматами из разных доменов.

Поверьте не один день бился с формальным подходом синтезатора и роутера к предлагаемой задаче.

Так что не все задачи можно решить слепо полагаясь на инструменты.

 

1) 1-й вариант, здаётся мне - А латч. Изз-за недоопределения А на всех кейсах.

Если доопределить - комбинаторный выход.

2) 2-й вариант - комбинаторный выход из-за компаратора.

 

3) "...5 клоковых доменов, есть и передача импульсов и передача данных и обмен сигналами между автоматами из разных доменов.

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

Ну в таком стрёмном случае есть 3 простых решения:

- задать при синтезе все клок соурсы строго одинаковыми - по наиболее быстрому. Тулза подумает что всё "почти" синхронно...

- физически подключить все клоковые входы (напр. мультиплексором) к одному источнику (напр. тестовому клоку) и синтезить как синхронную схему.

При этом, генерация тест векторов сильно упроститься (если это ASIC и там есть DFT и тестовый клок)...

В FPGA можно по ресету мультиплексор включать на разные клоковые входы, а при синтезе задать константы, переключающие все клоки на один.

Это конечно технологическая нашлёпка, но сильно упрощает жизнь.

- если первые 2 не нраавяться, ну задать фалс пас от одного клока к другому, при условии что вставлены синхронизаторы между ними.

Как тут привязка FSM выходов к флопам поможет - не знаю.

 

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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