this module support outstanding,out of order and interleaving?

[Alexander-0619]

Hi!

This is a good project!

But I would like to ask whether the module supports outstanding, out of order and interleaving transfer?

[atfox272]

Hi Alexander

Thank you for considering my project

My module supports the following 3 features.

1. Outstanding transaction feature:

• Support for both Read & Write channels.
• You can configure the number of outstanding transactions via the parameter OUTSTANDING_AMT in the top module (axi_interconnect.v)

2. Interleaving transfer feature:

• This feature is supported for the Read channel only
  // According to the AXI4 specification, the protocol does not support interleaving transfer for the Write channel

3. Out-of-order feature:
   I want to explain more about the "out-of-order" mechanism and what I will be "reordering".

• The "out-of-order" occurs by slaves, because there is no timing constraint for their response. Therefore, when 1 master requests some transactions to multiple slaves, the response transfers from slaves will have a different order than the request transfers from the master. My module ensures that the order of response transfers matches the order of the request transfer.
  // The request transfer is AW channel and AR channel
  // The response transfer is B channel and R channel

[Alexander-0619]

I see. Thx for your reply!

[Alexander-0619]

Hi!

I also want to know if this module supports unaligned and narrow transfers?

Besides, would it be convenient for you to write some explanations on how this module is implemented? It's a bit hard to understand just by looking at the code, or could you recommend some documents about AXI interconnect?

[atfox272]

Hi!

I also want to know if this module supports unaligned and narrow transfers?

Besides, would it be convenient for you to write some explanations on how this module is implemented? It's a bit hard to understand just by looking at the code, or could you recommend some documents about AXI interconnect?

Hi,
As I understand, intermediate components like the Interconnect do not concern with whether transactions are aligned or unaligned, it is to move transfers between the master and the slave (or vice versa). It is the slave that needs to handle whether the transaction is aligned or unaligned.

I will update the specification for this design soon (in about 1-2 days)

[Alexander-0619]

thx again!

[Alexander-0619]

Hi!

I learn a lot from this project, but have some questions.

Different skid buffers are used in different sub-modules. Why is it necessary to use different skid buffers to optimize timing? For instance, in the dsp_W_channel, backward timing needs to be optimized, while in the dsp_B_channel, forward timing needs to be optimized. Additionally, could you recommend some docs of the skid buffer in the project? The skid buffer in the project seems to be different from the basic skid buffer, and I'm not quite able to understand why it is designed this way in the project.

[atfox272]

Hi!

I learn a lot from this project, but have some questions.

Different skid buffers are used in different sub-modules. Why is it necessary to use different skid buffers to optimize timing? For instance, in the dsp_W_channel, backward timing needs to be optimized, while in the dsp_B_channel, forward timing needs to be optimized. Additionally, could you recommend some docs of the skid buffer in the project? The skid buffer in the project seems to be different from the basic skid buffer, and I'm not quite able to understand why it is designed this way in the project.

Hi Alexander,

All types of skid buffers have the same functionality. However, depending on the type of skid buffer, the approach to timing optimization (known as optimizing the Critical Path) will differ. Here, I will mention the 2 main types of skid buffers that I have designed.

1. Optimized Backward Skid buffer

In this figure, you can see that the RECEIVE data path is pipelined with a 1-stage register.

→ As a result, when other modules connect to this skid buffer (in the direction of sending data into it), they will NOT increase in their timing path. Below is the illustrative diagram.

⇒ The 1-stage pipeline helps SPLIT the timing path of the connected design.
→ This makes it easier to meet higher frequency requirements.

From this, you can see that the context above is quite similar to the context of dsp_W_channel, as dsp_W_channel is on the RECEIVE side and is directly connected to an AXI4 Master.

---

2. Optimized Forward Skid buffer

For the optimized forward skid buffer, the direction is opposite to that of the optimized backward skid buffer. It optimizes the SEND data path (instead of the RECEIVE data path like the backward skid buffer).

→ The purpose is also to prevent an increase in the timing path of the connected design.

And you can see that when connecting an AXI4 Master to an AXI4 Interconnect, the direction of the B channel is opposite to that of the W channel. (The B channel of the Interconnect is in the SEND direction, while the W channel of the Interconnect is in the RECEIVE direction).

→ Therefore, in the dsp_B_channel block, a forward skid buffer is used instead of a backward skid buffer like in dsp_W_channel. Below is the diagram.

[Alexander-0619]

Thank you for your answer. The selection of the skid buffer type depends on the direction of the data path.

I know that Register Slice can improve timing, while the skid buffer incorporates a FIFO, which seems to increase the area. What's the pros and cons of Register Slice and skid buffer?

[atfox272]

Thank you for your answer. The selection of the skid buffer type depends on the direction of the data path.

I know that Register Slice can improve timing, while the skid buffer incorporates a FIFO, which seems to increase the area. What's the pros and cons of Register Slice and skid buffer?

You are right, a register slice (without using FIFO) can improve timing. However, the improvement is NOT entirely strict. I will explain this issue later.

I have designed a type of skid buffer that does not use FIFO. This skid buffer is similar to a register slice. Its design is also in the skid_buffer.v file, named FULL_REGISTERED, as shown in the figure below:

However, FULL_REGISTERED skid buffer has not yet completely SPLIT the timing from other modules. Below is an illustrative diagram of this skid buffer.

Did you notice that the input signals going into the skid buffer can still increase the timing path? So, if another design connects to my design and has bad timing → It can still cause the entire system to fail to meet the frequency requirement.

This is also a common issue with most register slices I’ve seen on the Internet, as well as with the two register slice designs you just shared, they also have this problem.

Therefore, I designed two types of optimized backward/forward skid buffers with the goal of:

SPLITTING the entire timing path from other designs when connecting to my module.

Placing flip-flops before/after (corresponding to backward/forward) makes the design more complex, and avoiding the use of FIFO is nearly impossible. As a result, I still have to use FIFO here, but with very low depth to minimize area.

[atfox272]

If the timing requirement of your system is not very strict, you can change SBUF_TYPE parameter of all skid buffers to 0 (FULL_REIGSTERED skid buffer) to reduce the area of the system

[Alexander-0619]

For the register slice, the input signal needs to go through combinational logic and flip-flops, which increases the timing path. However, for the optimized backward/forward skid buffers you designed, the input signal directly passes through flip-flops, but this requires FIFO to buffer data, which is beneficial for high-speed design.

Is my understanding correct?

btw, What is the role of almost_full_o signal of fifo in optimized backward skid buffer? Why can't the fifo be full?

[atfox272]

Yep, your understanding is correct.

The almost_full_o signal is asserted when the FIFO has only 1 remaining empty slot. It helps you know that the next write operation will make the FIFO full.

[atfox272]

In this case, I do not use the full_o signal because the moment it is asserted is too late to be captured in the bwd_ready_q flip-flop. Therefore, I use the almost_full_o signal to capture the future of full_o signal.

[Alexander-0619]

I still have some doubts about the optimized backward skid buffer. Why is inter_fifo_counter == 2'd2 used as the judgment basis, while the depth of the FIFO is 4?

sry for so many questions...

[atfox272]

I still have some doubts about the optimized backward skid buffer. Why is inter_fifo_counter == 2'd2 used as the judgment basis, while the depth of the FIFO is 4?

sry for so many questions...

No problem :v feel free to ask

The reason I use the counter == 2'd2 flag here is that: bwd_ready_o is a flip-flop, and its latency is 1 cycle. You can see the timing diagram below:

If I only use full (counter == 2’d4) and almost_full (counter == 2’d3) here, the master might think that DATA4 has been accepted even though the FIFO is full.
Therefore, if the master changes the data after cycle 5, DATA4 might be skipped.