Jump to content

    
Sign in to follow this  
flammmable

Как обеспечить повторное использование кода для сдвигового регистра?

Recommended Posts

Добрый день!
Я пишу синтезируемый 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.

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

Edited by flammmable

Share this post


Link to post
Share on other sites
18 minutes ago, flammmable said:

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

 

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

 

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

Share this post


Link to post
Share on other sites
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 отдельных модуля?

 

Share this post


Link to post
Share on other sites
1 час назад, flammmable сказал:

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


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

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

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

Share this post


Link to post
Share on other sites
3 hours ago, flammmable said:

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

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

Share this post


Link to post
Share on other sites
43 minutes ago, Raven said:

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

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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:

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this