If you haven’t been paying attention to how we’ve built our debug bus master access into a wishbone device, you might wish to look at some of the other posts in this series:

Fig 1: WB-UART Overview
Block Diagram of a Simpler Wishbone to UART converter

Today, we’re going to add idle notifications to our stream. These notifications will help to identify this stream to you any time it is idle. The result is that, when you connect to one of these busses, you should know you have a valid connection once you see the idle character passing through the stream.

Idle Requirements

We want to keep this idle capability simple. If we draw out the idea of this idle capability a little bit, we’ll discover we want the following capabilities in this idle component:

  • There should never be any idle characters while the interface is busy. That way the idle character won’t slow down any valid transactions.

  • An idle character should be sent in the stream somewhere between every one and ten seconds, yet at regular intervals.

  • The first idle following any activity shouldn’t show up until one time interval’s distance from the last valid piece of information.

  • If the interface is stopped, such as if the bus is commanded via a SPI slave port, we shouldn’t accumulate more than a single idle character to be returned.

In sum, if you watch this stream, you should be able to identify this stream as a debug controller within a short number of seconds.

The idle stream processor

This section will walk through an example idle stream processor, showing you how to add idle characters (“Z”) into our response stream.

The first step in any protocol handling is to define the protocol words. In this case, we’ll be sending an IDLE_WORD down the line. This will turn into a “Z” when received with the strobe high.

`define	IDLE_SUB_WORD	5'b11011
`define	IDLE_WORD	{ `IDLE_SUB_WORD, {(34-5){1'b0}} }

Knowing when to insert an idle character is pretty simple. By using the timing techniques shared here, we can create a strobe every 2^28 clocks, or about every two and a half seconds. By clearing our idle counter on every input command or reset, we’ll guarantee that the next idle will be at least two and a half seconds after any activity.

initial	idle_stb      = 0;
initial	idle_counter  = 0;
always @(posedge i_clk)
	if ((i_reset)||(i_cmd_stb))
		idle_counter <= 0;
	else
		{ idle_stb, idle_counter } <= idle_counter + 1'b1;

Now that we know when we wish to insert an idle, the next step is to know when to output an idle character. In our case, we’ll output a character, whether idle or not, any time the indication above takes place or any time an incoming word takes place. As a result, this will be a pass-through component–and only change the input when nothing’s there.

	initial	o_idl_stb = 1'b0;
	always @(posedge i_clk)
		if (i_reset)
			o_idl_stb <= 1'b0;
		else if ((i_cmd_stb)&&(!o_idl_busy))
			o_idl_stb <= 1'b1;
		else if ((idle_stb)&&(!o_idl_stb))
			o_idl_stb <= 1'b1;
		else if (!i_busy)
			o_idl_stb <= 1'b0;

The final component is to settle which word we wish to output. On any incoming request to transmit, we’ll send the incoming word out. We’ll also need to ensure that any incoming word is not over-written until the next word goes out. Finally, if nothing is coming in to go out, we’ll just set our output to be the IDLE_WORD.

initial	o_idl_word = IDLE_WORD;
always @(posedge i_clk)
	if ((i_cmd_stb)&&(!o_idl_busy))
		o_idl_word <= i_cmd_word;
	else if (!i_busy)
		o_idl_word <= IDLE_WORD;

The logic is fairly simple.

Ok, I’ll admit it, I got this super-simple interface wrong at first. Worse, I had more than one bug within this component. It got so bad I started to get very frustrated with the simulator until I finally found the bug. What was it you ask? I defined the IDLE_SUB_WORD as 5’h11011 instead of 5’b11011. See the difference? If it hadn’t been for the simulator, I’m not sure I ever would’ve found my mistake.

Future Posts

As with the interrupt capability, adding an idle identifier into our debug protocol was fairly easy to do. Our next post will put the whole interface together. Further posts will include:

While we’re going to do better, this simple debugging bus should be enough to help you debug quite a few designs.