[StewartLittle 41]

11 минут назад, alexPec сказал:

1. что-то типа always @(posedge clk150M) clk75M = ~ clk75M. Но по-моему как-то криво потом этим клоком питать логику. Ваше мнение?

почему нет? Законстрейнить его на глобальную линию.

Или, чтобы лишний триггер не тратить, заюзать CLKDIV (ну или CLKDIV2, если 150 МГц снаружи на HCLK завести).

[Freibier 3]

Timing Constraints Editor выдаёт ошибку:

строка выглядит так:

set_input_delay -clock clk 0.8 [get_ports {VD[*]}]

Что ему не нравится?

[StewartLittle 41]

5 минут назад, Freibier сказал:

set_input_delay -clock clk 0.8 [get_ports {VD[*]}]

Что ему не нравится?

Может, квадратных скобок не надо?

Проверьте так: set_input_delay -clock clk 0.8 [get_ports {VD*}]

[Freibier 3]

20 минут назад, StewartLittle сказал:

{VD*}

и так тоже не проходит.

причем в обоих случаях синтез проходит без варнингов, но если запустить Timing Constraints Editor то он ругается.

вот и думаю гадаю, учитываются констрейны при синтезе или нет?

 

ЗЫ: похоже что надо каждый сигнал шины индивидуально прописывать.

если так записать :

set_input_delay -clock clk 0.8 [get_ports {VD[5] VD[4] VD[3] VD[2] VD[1] VD[0]}]

ошибок нет и судя по отчетам только при такой записи констрейн работает

 

[Nick_K 0]

34 minutes ago, Freibier said:

set_input_delay -clock clk 0.8 [get_ports {VD[5] VD[4] VD[3] VD[2] VD[1] VD[0]}]

По правилам тикля вайлдкарты используются в кавычках.

get_ports "VD\[*\]"

должно работать. Ну или просто звёздочка в конце, без квадратных скобок.

[Freibier 3]

1 час назад, Nick_K сказал:

По правилам тикля вайлдкарты используются в кавычках.

Уж как только не пробовал, никак не понимает.

Можете написать полностью весь констрейн согласно правилам тикля вайлдкарты?

 

[Nick_K 0]

13 minutes ago, Freibier said:

Уж как только не пробовал, никак не понимает.

Можете написать полностью весь констрейн согласно правилам тикля вайлдкарты?

 

Если раговор про -regexp, тогда все пины VD с любым номерным значение будет выглядеть так:

get_ports -regexp {VD\[[0-9]\]}

По крайней мере у меня так работает.

Самое интересное, что у меня работает так тоже:

get_ports {VD\[?\]}

И так

get_ports "VD*"

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

[Freibier 3]

4 часа назад, Nick_K сказал:

про -regexp

консоли тикля.

что такое -regexp и тикля?

4 часа назад, Nick_K сказал:

Самое интересное, что у меня работает так тоже:

Вы точно используете GOWIN FPGA Designer?

[dxp 33]

16 часов назад, alexPec сказал:

1. что-то типа always @(posedge clk150M) clk75M = ~ clk75M. Но по-моему как-то криво потом этим клоком питать логику. Ваше мнение?

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

16 часов назад, alexPec сказал:

2. Логику 75МГц запитать от клока 150МГц и энейбл на клок выставлять через такт. Так конечно правильнее, но есть вероятность, что после модернизации очередной времянки не пролезут - сейчас на пределе, но влазит.

Чтобы не было траблов с времянками, надо ещё прописать констрейн multicycle на эти пути, тогда тул будет знать, требуемую реально времянку и не будет излишне напрягаться. И тут всё  синхронно получается (если это актуально).

[andrew_b 14]

6 часов назад, Freibier сказал:

что такое -regexp

regexp -- regular expression, регулярное выражение. См. google://

6 часов назад, Freibier сказал:

тикля

Пишется tcl, произносится тикл(ь).

[Freibier 3]

16 часов назад, Freibier сказал:

причем в обоих случаях синтез проходит без варнингов, но если запустить Timing Constraints Editor то он ругается.

вот и думаю гадаю, учитываются констрейны при синтезе или нет?

Спрошу еще раз.

Синтез и сборка проходит без каких либо ошибок.

пишу хоть так {VD[*]} хоть так  {VD*}

Предупреждение выдает только Timing Constraints Editor при его запуске!

[SM 0]

22 hours ago, alexPec said:

На выходе нужно 150МГЦ для SDRAM, 100МГц для логики, и еще 75МГц для трансивера.

Мало вводных. Первый вариант, который прямо сразу просится - получить 75 из 150 на CLKDIV в режиме /2. Если нельзя завести 150 на CLKDIV (я не знаю, можно ли с CLKOUTD - я же правильно понимаю, что сделать 100 и 150 из 50 можно только так, что на CLKOUT и CLKOUTP будет 300, на CLKOUTD 150, а на CLKOUTD3 - 100 ?). Если с CLKOUTD 150 нельзя завести на CLKDIV, то с CLKOUT точно можно. Там 300, его можно поделить на 4. Второй вариант - получить 75 на CLKOUTD с PLL, а 150 на CLKDIV или CLKDIV2 с CLKOUT (там, если я правильно понимаю, 300, а 300 пополам как раз 150).

НО! Если надо получить для сдрам 150 на FCLK, а 75 на PCLK (на входах IDES4_MEM) - то тут вероятно придет облом со 100 МГц, если вдруг нельзя ввести CLKOUTD в HCLK (не знаю, проверять надо, но сильно подозреваю, ибо на CLKDIV2 он прямо не заводится, но это не значит, что не заведется "криво", когда будет использован вход FCLK, прямо говорящий о том, что этот клок надо пускать в HCLK). Но можно для такого случая попробовать сделать 150 из 300 на CLKDIV, а 75 из 150 на CLKDIV2 с выхода CLKDIV, оставив CLKOUTD в покое (вероятность успеха мала, но...)

Пополамить клок триггером в говине пока плохая идея, так как там create_generated_clock не работает как надо, и не даст гарантии точного соблюдения времянок, так как ему надо сдвиг фронтов на задержке входного клока прописывать руками, это косяк среды. Но по всем другим аспектам, в т.ч. и по разводке, все ОК. Техподдержка во главе со Stewart Little на тему этого косяка замолчала...

Ну и вариант 2 с энейблом - а что там за вероятность? Откуда? Если правильно прописаны set_multicycle_path, и в них нет говинных косяков, то должно быть все в порядке и с запаcом. Хотя я и не люблю такого дела, незачем ВЧ клоки гонять по большим деревьям, их стоит минимизировать, это пустая и бесполезная жрачка тока.

[Freibier 3]

Что означает буква "C" в конце Device Family чипа?

Чем GW1N-9 отличается от GW1N-9C ?

[alexPec 3]

10 часов назад, SM сказал:

я же правильно понимаю, что сделать 100 и 150 из 50 можно только так, что на CLKOUT и CLKOUTP будет 300, на CLKOUTD 150, а на CLKOUTD3 - 100 ?

Да, так и есть сейчас

10 часов назад, SM сказал:

Если с CLKOUTD 150 нельзя завести на CLKDIV,

Нельзя

 

10 часов назад, SM сказал:

Там 300, его можно поделить на 4.

Тогда получим 300 (clkout), 75 (clkoutd), 100 (clkoutd3). А 150 уже неоткуда взять. Вот для справки:

 

10 часов назад, SM сказал:

Пополамить клок триггером в говине пока плохая идея

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

 

10 часов назад, SM сказал:

Ну и вариант 2 с энейблом - а что там за вероятность? Откуда?

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

 

10 часов назад, SM сказал:

Если правильно прописаны set_multicycle_path,

Тут я не большой спец, multicycle ни разу не прописывал. Вопрос: а можно ли для относительно большого блока целиком прописать multicycle? Потому как для каждого триггера (из, наверно, 500-900) прописывать multicycle неблагодарное дело...

 

 

 

UPD: Пардон, увидел, что CLKDIV2 - это отдельный компонент, и он у меня свободен. Тогда похоже вопрос решается. А CLKDIV2 нормально констрейнится средой или есть грабли?

[SM 0]

1 hour ago, alexPec said:

Нельзя

А у меня собралось в тупом тестовом примере:

	module test (clk, in, out1, out2, out3);
	input clk, in;
output reg out1, out2, out3;
	wire clkout_o, clkoutd_o, clkoutd3_o;
	Gowin_rPLL pll_inst(
        .clkout(clkout_o), //output clkout
        .clkoutd(clkoutd_o), //output clkoutd
        .clkoutd3(clkoutd3_o), //output clkoutd3
        .clkin(clk) //input clkin
    );
	
CLKDIV clkdiv_inst (.HCLKIN(clkoutd_o), .CLKOUT(clko));
defparam clkdiv_inst.DIV_MODE="2";
	always @(posedge clko)
  out3 <= in;
always @(posedge clkoutd_o)
  out2 <= in;
always @(posedge clkoutd3_o)
  out1 <= in;
	
endmodule
	

 

Самоконстрейнится вроде нормально:

 

Только вот под вопросом другое - клок лэтенси для выхода 150 МГц CLKOUTD 1.080 нс, а для выхода 75 - CLKDIV/CLKOUT 0.685 нс, и получается, что 75 МГц умудряется опередить 150 МГц. Этому по идее есть объяснение - пути то разные от PLL до триггеров через дерево, и от PLL до CLKDIV, которые через HCLK - вот он и обогнал.  Могут быть вопросы с холдами на переходе со 150 на 75, если этот переход не на IDES-ах. А могут и не быть...

 

Ну и хорошая новость - CLKOUTD умеет заходить в HCLK:

 

То есть, можно использовать IDES4 / IDES4_MEM для приема сигналов с SDRAM с FCLK 150 и PCLK 75

 

----------

А вот с CLKDIV2 не удалось "в лоб" (если прямо в этом примере заменить CLKDIV на CLKDIV2 и убрать defparam) - что-то с чем-то не может соединить... И это очень странно, с учетом того, что на CLKDIV зашло [вроде] через тот же HCLK. А на CLKDIV2 не шмогло. Неожиданно. Или, возможно, он не может затащить ВЫХОД (!) CLKDIV2 в primary clock. Но, де факто, облом. С этим, похоже, можно и нужно идти в поддержку с вопросами, "какого хрена", чтобы жизнь кое кому мёдом не казалась.

 

  

1 hour ago, alexPec said:

а можно ли для относительно большого блока целиком прописать multicycle?

Можно. Там куча разных вариантов как их описывать, через "from", "to", "through" со всеми TCL-ными вилдкартами и регекспами для выбора имен.

 

  

1 hour ago, alexPec said:

Тогда получим 300 (clkout), 75 (clkoutd), 100 (clkoutd3). А 150 уже неоткуда взять. Вот для справки:

Так 150 взять из 300, подав 300 на вход CLKDIV-а, настроенного на деление пополам (как в моем примере). И в этом случае, кстати, можно будет поподгонять фазу 150 МГЦ, если это надо, под лэтенси 75 МГц, если 300 взять с CLKOUTP.

Но, как видим из примера, и 75 из 150 получается. Так что даже выбор есть! Вот, пожалуйста:

 

	module test (clk, in, out1, out2, out3);
	input clk, in;
output reg out1, out2, out3;
	wire clkout_o, clkoutd_o, clkoutd3_o;
	Gowin_rPLL your_instance_name(
        .clkout(clkout_o), //output clkout
        .clkoutp(clkoutp_o), //output clkoutp
        .clkoutd(clkoutd_o), //output clkoutd
        .clkoutd3(clkoutd3_o), //output clkoutd3
        .clkin(clk) //input clkin
    );
	
CLKDIV clkdiv_inst (.HCLKIN(clkoutp_o), .CLKOUT(clko));
defparam clkdiv_inst.DIV_MODE="2";
	always @(posedge clko)
  out3 <= in;
always @(posedge clkoutd_o)
  out2 <= in;
always @(posedge clkoutd3_o)
  out1 <= in;
	
endmodule