[flammmable 0]

Добрый день!
Я пишу синтезируемый JTAG-slave на System Verilog. В стандарте во многих местах пишется что-то типа "the <...> register connected between TDI and TDO". Т.к. в JTAG-е несколько регистров и все они постоянно подключаются между TDI и TDO я решил сделать отдельный модуль, описывающий любой подобный сдвиговый регистр JTAG-а. Вот так я описал входы и выходы из этого модуля:

package shift_control;
	typedef enum bit[1:0]{
		IDLE,
		CAPTURE,
		SHIFT,
		UPDATE} control_enum;
endpackage

module shift_reg #(
	parameter REG_LENGTH
	)(
	input		clk,
	input		reset,
	input		[1:0]control,
	input		data_in,
	output reg	data_out,
	inout reg	[REG_LENGTH-1:0]data_par,
	input		[REG_LENGTH-1:0]data_par_mask,
	input		[REG_LENGTH-1:0]data_init
	);
	//...
endmodule

Я планировал в зависимости от состояний автомата и инструкций в регистре инструкций коммутировать data_in/data_out различных регистров на TDI/TDO и data_par на различные источники/приемники.

Но тут возникло две проблемы.
1) регистр BYPASS является слишком вырожденным случаем сдвигового регистра - ввиду малой длины, его не требуется сдвигать.
2) регистр BSR потенциально коммутируется своим data_par-ом непосредственно на входы/выходы ПЛИСа. И выдает, а также забирает данные.
Регистр инструкций через data_par только выдает данные (о текущей инструкции). Причем только внутрь ПЛИСа.
Регистру IDCODE вообще data_par не нужен.

Т.е. регистры в ряде моментов принципиально отличны, хотя и во многом схожи.

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

Могли бы вы посоветовать, как бы это покрасивей оформить?

Изменено 5 июля, 2021 пользователем flammmable

[Raven 8]

18 minutes ago, flammmable said:

Могли бы вы посоветовать, как бы это покрасивей оформить?

 

Для начала, не надо никаких inout reg на интерфейсе, только раздельные in и out. И уже это сделает решение легче (переосмыслите реализацию с учетом такого разделения, и поймете - например, насчет регистров, где нужно только IN или только OUT). Сюда же относится вопрос - зачем вам ВХОД data_init, а не соответствующий параметр? У вас что, послересетовые значения могут меняться?

 

А дальше - прикиньте, какой набор секций shift регистра удовлетворит всему вашему набору инструкций, и соорудите мультиплексируемую схему. Регистры BYPASS и BSR можно реализовать особняком (слишком отличающиеся случаи).

[flammmable 0]

2 minutes ago, Raven said:

зачем вам ВХОД data_init, а не соответствующий параметр? У вас что, послересетовые значения могут меняться?

Блин, логично.

3 minutes ago, Raven said:

Для начала, не надо никаких inout reg на интерфейсе, только раздельные in и out.

Пожалуй.

2 minutes ago, Raven said:

Регистры BYPASS и BSR можно реализовать особняком (слишком отличающиеся случаи).

Иными словами на 4 регистра всё же нужно 3 отдельных модуля?

 

[iosifk 3]

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

Добрый день!
Я пишу синтезируемый JTAG-slave на System Verilog. 

Могли бы вы посоветовать, как бы это покрасивей оформить?

А на какие выводы цеплять будете?

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

[Raven 8]

3 hours ago, flammmable said:

Иными словами на 4 регистра всё же нужно 3 отдельных модуля?

Почему 4, например? Вы не раскрыли, какие TAPC инструкции собираетесь реализовывать (с деталями типа разрядностей и общей структуры их DR) - так что сложно советовать конкретнее.

[flammmable 0]

43 minutes ago, Raven said:

Почему 4, например? Вы не раскрыли, какие TAPC инструкции собираетесь реализовывать (с деталями типа разрядностей и общей структуры их DR) - так что сложно советовать конкретнее.

Я имею ввиду в базовом варианте - IR, IDCODE, BSR и BYPASS - четыре регистра.

[Raven 8]

51 minutes ago, flammmable said:

Я имею ввиду в базовом варианте - IR, IDCODE, BSR и BYPASS - четыре регистра.

Ну, для этой 4-ки комбинировать и химичить с какой-то мультиплексируемой схемой - нерационально, IMHO. Накладных расходов будет больше, чем выгоды.

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

IR: стоит и обрабатывается особняком, лучше его с DR-ми не смешивать.

IDCODE, BAPASS: из-за разности в размерах и малости второго строить общий для них сдвиговый регистр нецелесообразно.

Все это не исключает возможности построить IR, IDCODE и BYPASS в виде инстансов одного и того же параметризуемого блока (TAP shift register), типа того, который вы привели в самом начале темы.

Совсем другое дело, если у вас появляются еще какие-то private instructions - вот их то DRs как раз можно было бы скомбинировать друг с другом и с IDCODE.

[flammmable 0]

4 minutes ago, Raven said:

Ну, для этой 4-ки комбинировать и химичить с какой-то мультиплексируемой схемой - нерационально, IMHO. Накладных расходов будет больше, чем выгоды.

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

IR: стоит и обрабатывается особняком, лучше его с DR-ми не смешивать.

IDCODE, BAPASS: из-за разности в размерах и малости второго строить общий для них сдвиговый регистр нецелесообразно.

Все это не исключает возможности построить IR, IDCODE и BYPASS в виде инстансов одного и того же параметризуемого блока (TAP shift register), типа того, который вы привели в самом начале темы.

Совсем другое дело, если у вас появляются еще какие-то private instructions - вот их то DRs как раз можно было бы скомбинировать друг с другом и с IDCODE.

Чтож, большое спасибо! Теперь я на стадии принятия )) Я пожалуй сделаю 4 отдельных модуля.

3 hours ago, iosifk said:

А на какие выводы цеплять будете?

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

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

[Avex 1]

Открою секрет. Если взять стандарт житаг, то там все варианты регистров не просто описаны, а прямо таки нарисованы в виде электрической принципиальной схемы. Основная сложность - написать код по схеме, и параметризировать. Можно еще взять доки synopsys dc, описание айпи ядер тап-контроллера, там тоже все разжевано в виде схем. 35 лет интерфейсу ...