[CaPpuCcino 0]

что-то Синплифай последнее время стал раздражать (а точнее уже бесить)

хочу сообщить вам об очередной коре от Синплифай 8.2:

пишу ему следующий код -

 
module ring_buffer (clk, reset_n, data_in, data_out, read_op_req, write_op_req, read_op_gnt, write_op_gnt);
`include "power.v"
parameter word_width=4;
parameter stack_depth=16;
parameter ptr_width=number_of_bits_for_value_representation(stack_depth-1);
 input clk;
 input reset_n;
 input [word_width-1:0] data_in; 
 output reg [word_width-1:0] data_out; 
 input read_op_req, write_op_req; 
 output reg read_op_gnt, write_op_gnt;
...
endmodule

а он мне и говорит:

@E: CG254 : Redeclaration of ports. Cannot mix styles.

This error occurs when the compiler finds both Verilog 2001 as well as Verilog 95 syntax in the same port list.

то есть обвиняет меня, что я смешиваю стили декларации портов (что очевидно не так, а компилятор Верилог2001 должен надо полагать понимать и декларацию Верилога 95)

думаю обману если принудительно поставлю ему галочку о компиляции только по 95-стандарту - НИФИГА!

так что если кто решит пользовать Синплифай 8.2 будьте готовы писать полную декларацию портов в шапке модуля - а в случае старых проектов - переписывать их под стиль 2001

[ilya79 0]

В 8.2 очень много глюков c Verilog попробуйте 8.2.1 c ftp (мне помогло , был глюк с удалением инициализированных при декларации регистров в Verilog).

[des00 25]

В 8.2 очень много  глюков c  Verilog  попробуйте 8.2.1 c ftp (мне помогло , был глюк с удалением инициализированных при декларации регистров в Verilog).

<{POST_SNAPBACK}>

Уже появился ? а аспирин тот же ?

[dxp 51]

В 8.2 очень много  глюков c  Verilog  попробуйте 8.2.1 c ftp (мне помогло , был глюк с удалением инициализированных при декларации регистров в Verilog).

<{POST_SNAPBACK}>

Это как это "инициализированных при декларации регистров в Verilog"? Что, уже можно написать:

 

reg a = 1;

 

и это будет синтезабельная конструкция? Или тут что-то другое имелось в виду?

[v_mirgorodsky 0]

В 8.2 очень много   глюков c  Verilog  попробуйте 8.2.1 c ftp (мне помогло , был глюк с удалением инициализированных при декларации регистров в Verilog).

<{POST_SNAPBACK}>

Это как это "инициализированных при декларации регистров в Verilog"? Что, уже можно написать:

 

reg a = 1;

 

и это будет синтезабельная конструкция? Или тут что-то другое имелось в виду?

<{POST_SNAPBACK}>

 

Это всегда была синтезабельная конструкция, по крайней мере для Xilinx FPGA. Для компилятора нет никаких проблем в Xilinx FPGA поставить начальное состояние триггера в bit-файле равным определенному значению. У нас на этом принципе была написана пара модулей, которые не требовали изначального ресета. В Альтере ситуация с этим похуже :( Там синтезатор просто игнорирует эту конструкцию и триггер по умолчанию всегда установлен в нуль.

 

С этим связана разница в one-hot КА кодировании. У Альтеры первое состояние всех триггеров всегда нулевое, у Xilinx - произвольное. Если КА для Альтеры имеет ненулевые биты состояния стартового состояния (такой себе каламбурчик), то компилятор генерирует предупреждение, что мол схеме для корректной работы необходим стартовый ресет.

[dxp 51]

В 8.2 очень много   глюков c  Verilog  попробуйте 8.2.1 c ftp (мне помогло , был глюк с удалением инициализированных при декларации регистров в Verilog).

<{POST_SNAPBACK}>

Это как это "инициализированных при декларации регистров в Verilog"? Что, уже можно написать:

 

reg a = 1;

 

и это будет синтезабельная конструкция? Или тут что-то другое имелось в виду?

<{POST_SNAPBACK}>

 

Это всегда была синтезабельная конструкция, по крайней мере для Xilinx FPGA. Для компилятора нет никаких проблем в Xilinx FPGA поставить начальное состояние триггера в bit-файле равным определенному значению. У нас на этом принципе была написана пара модулей, которые не требовали изначального ресета. В Альтере ситуация с этим похуже :( Там синтезатор просто игнорирует эту конструкцию и триггер по умолчанию всегда установлен в нуль.

 

С этим связана разница в one-hot КА кодировании. У Альтеры первое состояние всех триггеров всегда нулевое, у Xilinx - произвольное. Если КА для Альтеры имеет ненулевые биты состояния стартового состояния (такой себе каламбурчик), то компилятор генерирует предупреждение, что мол схеме для корректной работы необходим стартовый ресет.

<{POST_SNAPBACK}>

Насчет синтезабельности этой конструкции. В языке Верилог объекты reg не являются триггерами. И вышепривденный объект 'a' может быть как триггером, так и простой логичекой связью (node, если по AHDL'ному). Во втором случае смысла в начальной инициализации просто нет.

 

Сейчас уже не помню, давно было, когда разбирался, но, afair, присваивания (в том числе и начальные) к объектам reg можно делать только в поведенческих блоках initial и always. При этом блоки initial являются несинтезабельными - синтезатор в лучшем случае их игнорирует.

 

Сам же всегда синтезуруемые объекты привожу к исходному состоянию явно в описании логики - для этого (и только для этого) использую асинхронный сброс триггеров непосредственно после влючения ПЛИС.

 

Что касается исходного состояния триггеров в ПЛИС от Альтеры, то и тут, насколько помню, не так, как Вы сказали. Есть там возможность установить их при загрузке, сам пользовался этим несколько лет назад, когда работал на AHDL, это был какой-то из ACEX'ов.

[v_mirgorodsky 0]

Это как это "инициализированных при декларации регистров в Verilog"? Что, уже можно написать:

 

reg a = 1;

 

и это будет синтезабельная конструкция? Или тут что-то другое имелось в виду?

<{POST_SNAPBACK}>

 

Это всегда была синтезабельная конструкция, по крайней мере для Xilinx FPGA. Для компилятора нет никаких проблем в Xilinx FPGA поставить начальное состояние триггера в bit-файле равным определенному значению. У нас на этом принципе была написана пара модулей, которые не требовали изначального ресета. В Альтере ситуация с этим похуже :( Там синтезатор просто игнорирует эту конструкцию и триггер по умолчанию всегда установлен в нуль.

 

С этим связана разница в one-hot КА кодировании. У Альтеры первое состояние всех триггеров всегда нулевое, у Xilinx - произвольное. Если КА для Альтеры имеет ненулевые биты состояния стартового состояния (такой себе каламбурчик), то компилятор генерирует предупреждение, что мол схеме для корректной работы необходим стартовый ресет.

<{POST_SNAPBACK}>

Насчет синтезабельности этой конструкции. В языке Верилог объекты reg не являются триггерами. И вышепривденный объект 'a' может быть как триггером, так и простой логичекой связью (node, если по AHDL'ному). Во втором случае смысла в начальной инициализации просто нет.

 

Сейчас уже не помню, давно было, когда разбирался, но, afair, присваивания (в том числе и начальные) к объектам reg можно делать только в поведенческих блоках initial и always. При этом блоки initial являются несинтезабельными - синтезатор в лучшем случае их игнорирует.

 

Сам же всегда синтезуруемые объекты привожу к исходному состоянию явно в описании логики - для этого (и только для этого) использую асинхронный сброс триггеров непосредственно после влючения ПЛИС.

 

Что касается исходного состояния триггеров в ПЛИС от Альтеры, то и тут, насколько помню, не так, как Вы сказали. Есть там возможность установить их при загрузке, сам пользовался этим несколько лет назад, когда работал на AHDL, это был какой-то из ACEX'ов.

<{POST_SNAPBACK}>

 

Оки, тогда расскажу как я это делал и делаю на VHDL под Xilinx. У меня там есть объявления сигналов, поведение которыч в последствии описывается как триггер. По VHDL - помещается в process() blah-blah-blah, чувствительный к клоковому сигналу, по Verilog - аналогом должна быть конструкция вида always() blah-blah-blah. Так вот, фактическим триггерам описанным данным сигналом можно присваивать конкретные логические значения, которые в случае Xilinx будут внедрены в сгенерированный bit-файл. При этом триггер будет установлен в начальное состояние без любых воздействий на логику прошивки из вне. Похожий фокус для Altera тоже возможен, но для этого необходимо дернуть DEV_CLRn внешним устройством, о чем и предупреждает компилятор во время сборки прошивки.

 

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

[id_gene 0]

CaPpuCcino, смешение портов у вас из файла power.v происходит?

Просто из любопытства спрашиваю (я так полагаю, у вас там объявление функций)

 

У меня, кстати, 8.0 ругался "out of memory", а 8.2 на том же проекте -> "internal error in m_altera.exe" Кто-нибудь встречал такое?

 

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

[des00 25]

nternal error in m_altera.exe

 

иногда случаестья только с m_xilinx

перезапуск в моих случаях помогал

[CaPpuCcino 0]

CaPpuCcino, смешение портов у вас из файла power.v происходит? 

Просто из любопытства спрашиваю (я так полагаю, у вас там объявление функций)

<{POST_SNAPBACK}>

 

нет - в файле power.v только функции для расчёта параметров. никакого смешения стилей там в принципе нет. а ругается он от своей тупости указывая на сигналы clk, reset_n, data_in, data_out, read_op_req, write_op_req, read_op_gnt, write_op_gnt, а описаны они в чисто 95 стиле, так как мне нужно рассчитывать их разрядность по параметрам

[CaPpuCcino 0]

CaPpuCcino, смешение портов у вас из файла power.v происходит? 

Просто из любопытства спрашиваю (я так полагаю, у вас там объявление функций)

<{POST_SNAPBACK}>

 

нет - в файле power.v только функции для расчёта параметров. никакого смешения стилей там в принципе нет. а ругается он от своей тупости указывая на сигналы clk, reset_n, data_in, data_out, read_op_req, write_op_req, read_op_gnt, write_op_gnt, а описаны они в чисто 95 стиле, так как мне нужно рассчитывать их разрядность по параметрам

<{POST_SNAPBACK}>

ок - поглядел еще раз - в файле с функциями действительно есть обявление типа function ( input integer x, input integer y )

но вот только вопрос - какое это отношение имеет к разным блокам - тем более функции и модулю - и что теперь мне из-за них заголовки функций переписывать? - до сих пор не встречал такого мозго..ства - к стати попробовал поставить 8.2.1 - не помогает

[des00 25]

к стати попробовал поставить 8.2.1 - не помогает

аспирин тот же ?

[CaPpuCcino 0]

к стати попробовал поставить 8.2.1 - не помогает

аспирин тот же ?

<{POST_SNAPBACK}>

сорри - аспиринами не банчим - у нас лицензии - но должен быть тот же -- потому как 8.2.1 всего лишь апгрэйд в 11 мегабайт

[id_gene 0]

объявление функций не должно тут влиять.

Пробовал воспроизвести у себя что-то похожее - не ругается, компилирует нормально; описание ошибки в хелпе - вообще не похоже. Так что ошибка просто глючная странно.

 

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

[popeye 0]

что-то Синплифай последнее время стал раздражать (а точнее уже бесить)

хочу сообщить вам об очередной коре от Синплифай 8.2:

пишу ему следующий код -

 
module ring_buffer (clk, reset_n, data_in, data_out, read_op_req, write_op_req, read_op_gnt, write_op_gnt);
`include "power.v"
parameter word_width=4;
parameter stack_depth=16;
parameter ptr_width=number_of_bits_for_value_representation(stack_depth-1);
 input clk;
 input reset_n;
 input [word_width-1:0] data_in; 
 output reg [word_width-1:0] data_out; 
 input read_op_req, write_op_req; 
 output reg read_op_gnt, write_op_gnt;
...
endmodule

а он мне и говорит:

@E: CG254 : Redeclaration of ports. Cannot mix styles.

This error occurs when the compiler finds both Verilog 2001 as well as Verilog 95 syntax in the same port list.

то есть обвиняет меня, что я смешиваю стили декларации портов (что очевидно не так, а компилятор Верилог2001 должен надо полагать понимать и декларацию Верилога 95)

думаю обману если принудительно поставлю ему галочку о компиляции только по 95-стандарту - НИФИГА!

так что если кто решит пользовать Синплифай 8.2 будьте готовы писать полную декларацию портов в шапке модуля - а в случае старых проектов - переписывать их под стиль 2001

<{POST_SNAPBACK}>

Если посмотреть стандарт IEEE1394-1995, Annex A.2, то можно увидеть это:

output_declaration ::= output[range] list_of_port_identifiers;

У Вас есть объявления вида output reg, что допускается в Verilog 2001. Если хотите писать в стиле 95, то объявите просто output, и reg с таким же именем.