Thursday, August 6, 2020

ARM PROTOCOLS



A SoC design would do one of the following:

Criteria for making system level choices

 • Choosing the right bus for your system

• Peripherals selection

• Performance requirements based on your application

ARM

First you have to learn the three major ARM microprocessor families:

Cortex M, Cortex A and Cortex R.

Cortex M: For micro controller domain and low power consumption and real time application.

Cortex A: For application field and generally used to run an Operating system (specific kernel Linux distribution )

 Cortex R: For automotive area.

 Know the type of instruction set which is RISC because the main goal is reducing the power consumption of the SOC that embed ARM Microprocessor.







APB is mainly proposed for connecting to simple peripherals. It can be seen that the APB comes with a low power peripheral. It groups narrow bus peripherals to avoid loading the system bus.APB does not support burst mode of transfer but AHB does.  

 APB is simple protocol which is useful for register reads and writes mostly with no fancy signals one operation after another. AHB on the other hand supports INCR, WRAP and single mode with varied lengths thus giving better performance.

 The APB has been designed to implement as simple an interface as possible. It is a  simple design which makes it much easier to connect new APB peripherals and makes the analysis of the system performance easier to calculate.

  As the computing demands rise, AHB started to fall short in meeting the demands of the system which were ever hungry for more bandwidths.

  AHB is ARM's most popular protocol, which was invented in an era, where the computing power of the Integrated Circuits were very primitive as compared to what we have now 

                   One of the major problems with the AHB protocol is its inability to support what are called 'outstanding' transactions. An outstanding transaction is simply the one, which has been issued but its response is awaited. Yes, mostly it is related to 'read' transactions, as the 'write' transactions can live without a response.Though AHB does support 'split' transactions which one may argue that its what an outstanding transaction support in AHB is, but it never took off, and neither did it served the purpose of 'outstanding' transactions.

APB is mainly proposed for connecting to simple peripherals. It can be seen that the APB comes with a low power peripheral. It groups narrow bus peripherals to avoid loading the system bus.APB does not support burst mode of transfer but AHB does.  

 APB

APB is simple protocol which is useful for register reads and writes mostly with no fancy signals one operation after another. AHB on the other hand supports INCR, WRAP and single mode with varied lengths thus giving better performance.

 The APB has been designed to implement as simple an interface as possible. It is a  simple design which makes it much easier to connect new APB peripherals and makes the analysis of the system performance easier to calculate.

  As the computing demands rise, AHB started to fall short in meeting the demands of the system which were ever hungry for more bandwidths.

  AHB is ARM's most popular protocol, which was invented in an era, where the computing power of the Integrated Circuits were very primitive as compared to what we have now (2019)

One of the major problems with the AHB protocol is its inability to support what are called 'outstanding' transactions. An outstanding transaction is simply the one, which has been issued but its response is awaited. Yes, mostly it is related to 'read' transactions, as the 'write' transactions can live without a response.Though AHB does support 'split' transactions which one may argue that its what an outstanding transaction support in AHB is, but it never took off, and neither did it served the purpose of 'outstanding' transactions.

APB

 

1. When should APB slave Sample address/Data for read/write transaction from APB master?

As per APB, for READ/WRITE transaction from master, generate PSEL = 1 in the first clock cycle and then PENABLE = 1 in the next clock cycle.

During the two clock cycles, PADDR, PWDATA, PWRITE signals does not change.  APB slave drives PREADY always HIGH. So the PENABLE goes to '0' in the second clock cycle as per the protocol. We need to drive the PREADY and PSLVERR and the PRDATA from slave at the same clock for the read transfer (which should happen in the ACCESS phase here). Control signals should be sampled by the peripheral at the end of the setup phase.

For write transfers the peripheral can then sample PWDATA either at the end of the setup phase (when PSEL=1 and PENABLE=0) or else at the end of the access phase (when PSEL=1 and PENABLE=1).

PWDATA is guaranteed to be stable throughout the APB access, so it doesn't really matter when you sample it, although we suppose sampling at the end of the access phase is the intention of the protocol as it allows the peripheral one cycle to detect the transfer and then another cycle to then prepare to sample the data.

For read transfers the PRDATA bus is only valid during the access phase, so when PSEL=1 and PENABLE=1 (and PREADY=1), so the master will only sample read data just before PENABLE goes low at the end of the access.

 

First clock    : PSEL = 1 & PWRITE = 0/1 (read/write, here PREADY is LOW by default)

Second clock: PSEL =1 & PENABLE = 1 & PWRITE = 0/1 

(For write mem[paddr] <= pwdata and for read prdata <= mem[paddr])

Third clock cycle: PREADY =1 

For write transfers, the addr/data is sampled when PSEL =1 and PENABLE = 1 (SECOND CLOCK).

Later PREADY = 1 is driven in the next clock cycle (which is third clock cycle) where the data is written to the internal registers to make sure both data and PREADY happens at same time. But this takes three cycles to complete one APB write/read transfer. The same is done with read transfer where PRDATA and PREADY =1 is driven in third clock cycle.

Make PREADY =1 by default, the APB master will complete transfer in TWO clock cycles as per protocol. But PRDATA will be only available in third clock cycle by which time PSEL & PENABLE goes to LOW. So now prdata is not valid for Master.

 2. Why is there no wait signal on the APB?

PREADY can remain high forever if you don't want to add wait states. If you are connecting an APB2 peripheral (with no PREADY output) to an APB3 master, you would just tie the PREADY input on the master high.PREADY is only checked during the "ACCESS" phase of an APB access, so during periods when PSEL is low, or when PSEL is high but PENABLE is low (the transfer "SETUP" phase), PREADY is undefined and could be high.

Typically the driver software will first access a status register to determine that data is available

Peripherals which do require wait states can be designed as AHB slaves and in the rare case that a design does include a large number of these peripherals then a secondary stub AHB can be used to reduce the  loading on the main system bus.

3. How should AHB to APB bridges handle accesses that are not 32-bits?

The bridge should simply pass the entire 32-bit data bus through the bridge. When transfers less than 32-bits are performed to an APB slave it is important to ensure that the peripheral is located on the appropriate bits of the APB data bus

4. For your initial descriptions of the first clock and second clock, why can't PREADY be high during the second clock?

If  memory just needs an enable signal to know when PWDATA should be sampled, this just needs to be when PSEL & PWRITE & PENABLE is 1'b1 if the data input is a latch, or the falling edge of the PSEL & PWRITE & PENABLE logic (both probably also including some PADDR decoding).

If we use the above logic during the second clock just to know when to sample data, but this isn't written to the actual memory until one cycle later, then you could drive PREADY one cycle later as you describe, but that is something your design requires, not something the protocol requires.

For reads start the memory access as soon as PENABLE goes high, so if the memory being accessed can generate valid PRDATA during that single cycle "second clock", again PREADY could also be driven high in this cycle. If PRDATA cannot be driven valid during the second clock cycle, again that is a design issue requiring an extra cycle, not something mandated by the APB spec.

It sounds like your PRDATA not being valid until the third clock cycle is an access time limitation of the register/memory being accessed, so having PREADY allows you to stall the APB access until the peripheral can drive back valid read data, but as you know the address being read at the end of the first clock cycle, the protocol does then allow the peripheral to immediately then start returning read data to be sampled by the APB master at the end of the second cycle, so not requiring 3 cycles.

2 cycles is the basic access timing for APB, PREADY allows you to extend this access timing, but only if the peripheral being accessed needs additional access time.APB basic access time is 2 cycles. (1st - SETUP, 2nd - ACCESS PHASE)

 

For write transfers, we can achieve the 2 cycles completion phase by driving PREADY =1 by default or making it HIGH in the second clock cycle (PSEL = 1 , PWRITE =1 , PENABLE =1)  where PADDR , PWDATA is sampled in the second clock cycle. Here we are sure that the data is written to the address specified in the internal register/memory of the slave.

For read transfer, as per earlier details , PADDR is sampled in ACCESS PHASE. So we cant have the PRDATA in the same clock cycle. It takes additional cycle to return the data. So we drive PREADY =1 only when valid data is available. (3rd clock)

    As per protocol, to achieve valid PRDATA and PREADY =1 from slave in second clock cylce, PADDR should be sampled in the SETUP phase (first clock cycle) only,it is indicated to sample paddr during access phase only. So we cant realize if data sampled in access phase. But can be achieved only when sampled in Setup phase (PSEL =1 and PENABLE = 0). As these are NBA assignments it definitely required one cycle to return data.  Sampling should be done only during access phase.

5. In some designs we see that PREADY is driven HIGH all the time. In such scenarios, how do the designer ensure PRDATA is valid in second clock cycle?

 Control signals should be sampled by the peripheral at the end of the setup phase", so this would then allow the peripheral to start driving PRDATA at the start of the access phase, and so allow the transfer to complete at the end of a single cycle access phase if the peripheral's access time allows PRDATA to be valid at the end of that cycle.

This is how read accesses can be completed in 2 cycles, and is how accesses HAD TO work in the first releases of APB where there was no PREADY signal.

6.In APB, Why do we use enable signal?

       In APB, PSELx is used for selecting the slaves on APB bus and PENABLE is used to indicate second cycle of an APB transfer. There is no ready signal, so in order to do data transfer, master and slave both will use enable signal to know that data transfer is done. However the ready signal is added in APB 3.0 and then ready has to be used along with enable to know if data transfer is done.

APB Bridge generates one PSELx signal for each slave, and all the slaves share the same PENABLE signal. if u are design a slave. the PSEL should decode from an address decoder to select which APB slave. So if the APB slave device is not selected than just ignore the PENABLE.

Example: assign select = PWRITE? (PSEL & PENABLE) : (PSEL | PEN)

First clock : PSEL = 1 & PWRITE = 0/1 (read/write, here PREADY is LOW by default)

Second clock : PSEL =1 & PENABLE = 1 & PWRITE = 0/1   (for write mem[paddr] <= pwdata and for read prdata <= mem[paddr])

Third clock cycle : PREADY =1 

7. For write transfers, the addr/data is sampled when PSEL =1 and PENABLE = 1 (SECOND CLOCK). Later PREADY = 1 is driven in the next clock cycle (which is third clock cycle) where the data is written to the internal registers to make sure both data and PREADY happens at same time.

But this takes three cycles to complete one APB write/read transfer. The same is done with read transfer where PRDATA and PREADY =1 is driven in third clock cycle 

If I make PREADY =1 by default, the APB master will complete transfer in TWO clock cycles as per protocol. But PRDATA will be only available in third clock cycle by which time PSEL & PENABLE goes to LOW. So now prdata is not valid for Master.

Please suggest how can we realize making PRDATA have valid data in second clock cycle when PREADY =1 always HIGH

 

8. How can we realize making PRDATA have valid data in second clock cycle when PREADY =1 always HIGH? For your initial descriptions of the first clock and second clock, why can't PREADY be high during the second clock?

If your memory just needs an enable signal to know when PWDATA should be sampled, this just needs to be when PSEL & PWRITE & PENABLE is 1'b1 .if the data input is a latch, or the falling edge of the PSEL & PWRITE & PENABLE logic (both probably also including some PADDR decoding).

If you are using the above logic during the second clock just to know when to sample data, but this isn't written to the actual memory until one cycle later, then you could drive PREADY one cycle later as you describe, but that is something your design requires, not something the protocol requires.

For reads you could start the memory access as soon as PENABLE goes high, so if the memory being accessed can generate valid PRDATA during that single cycle "second clock", again PREADY could also be driven high in this cycle. If PRDATA cannot be driven valid during the second clock cycle, again that is a design issue requiring an extra cycle, not something mandated by the APB spec.

It sounds like your PRDATA not being valid until the third clock cycle is an access time limitation of the register/memory being accessed, so having PREADY allows you to stall the APB access until the peripheral can drive back valid read data, but as you know the address being read at the end of the first clock cycle, the protocol does then allow the peripheral to immediately then start returning read data to be sampled by the APB master at the end of the second cycle, so not requiring 3 cycles.

2 cycles is the basic access timing for APB, PREADY allows you to extend this access timing, but only if the peripheral being accessed needs additional access time.

 APB basic access time is 2 cycles. (1st - SETUP, 2nd - ACCESS PHASE)

For write transfers, we can achieve the 2 cycles completion phase by driving PREADY =1 by default or making it HIGH in the second clock cycle (PSEL = 1 , PWRITE =1 , PENABLE =1)  where PADDR , PWDATA is sampled in the second clock cycle. Here we are sure that the data is written to the address specified in the internal register/memory of the slave.

For read transfer, as per earlier details, PADDR is sampled in ACCESS PHASE. So we can’t have the PRDATA in the same clock cycle. It takes additional cycle to return the data. So we drive PREADY =1 only when valid data is available. (3rd clock)

    As per protocol, to achieve valid PRDATA and PREADY =1 from slave in second clock cycle, PADDR should be sampled in the SETUP phase (first clock cycle) only, but in earlier discussion ,it is indicated to sample paddr during access phase only. So we cant realize if data sampled in access phase. But can be achieved only when sampled in Setup phase (PSEL =1 and PENABLE = 0). As these are NBA assignments it definitely required one cycle to return data. But  understand that Sampling should be done only during access phase.

In some designs we see that PREADY is driven HIGH all the time. In such scenarios, how does the designer ensure PRDATA is valid in second clock cycle?

 Control signals should be sampled by the peripheral at the end of the setup phase", so this would then allow the peripheral to start driving PRDATA at the start of the access phase, and so allow the transfer to complete at the end of a single cycle access phase if the peripheral's access time allows PRDATA to be valid at the end of that cycle. This is how read accesses can be completed in 2 cycles, and is how accesses HAD TO work in the first releases of APB where there was no PREADY signal.

 AMBA protocols never specify max frequencies because that frequency will depend on the silicon library you are targeting, the complexity of the system you are designing, and how much effort you put into synthesis (not just going for simple timing budgets).

9. What is the difference between with wait state and with no wait state(read/write)?what are the advantages of both in APB?

Use a wait state if your periperal access timing requires it, or don't use a wait state if you don't need one.

 

10. What is an error condition in APB transfer and when it is valid?

PSLVERR to indicate an error condition on an APB transfer. Error conditions can occur on both read and write transactions.PSLVERR is only considered valid during the last cycle of an APB transfer, when PSELPENABLE, and PREADY are all HIGH.

 

It is recommended, but not mandatory, that drive PSLVERR LOW when it is not being sampled. That is, when any of PSELPENABLE, or PREADY are LOW.

 

Transactions that receive an error, might or might not have changed the state of the peripheral. This is peripheral-specific and either is acceptable. When a write transaction receives an error this does not mean that the register within the peripheral has not been updated. Read transactions that receive an error can return invalid data. There is no requirement for the peripheral to drive the data bus to all 0s for a read error.

 

 APB peripherals are not required to support the PSLVERR pin. This is true for both existing and new APB peripheral designs. Where a peripheral does not include this pin then the appropriate input to the APB bridge is tied LOW.

 

 11. PSLVERR

 

When bridging:

 

From AXI to APB An APB error is mapped back to RRESP/BRESP = SLVERR. This is achieved by mapping PSLVERR to the AXI signals

 

RRESP[1] for reads and BRESP[1] for writes.

 

From AHB to APB PSLVERR is mapped back to HRESP = ERROR for both reads and writes. This is achieved by mapping PSLVERR to the AHB signal HRESP[0].

 

12. Operational activity of the APB

 

 




IDLE This is the default state of the APB.

 

SETUP When a transfer is required the bus moves into the SETUP state, where the appropriate select signal, PSELx, is asserted. The bus only remains in the SETUP state for one clock cycle and always moves to the ACCESS state on the next rising edge of the clock.

 

ACCESS The enable signal, PENABLE, is asserted in the ACCESS state. The address, write, select, and write data signals must remain stable during the transition from the SETUP to ACCESS state.Exit from the ACCESS state is controlled by the PREADY signal from the slave:

 

If  PREADY is held LOW by the slave then the peripheral bus remains in the ACCESS state.

 

 

If PREADY is driven HIGH by the slave then the ACCESS state is exited and the bus returns to the IDLE state if no more transfers are required. Alternatively, the bus moves directly to the SETUP state if another transfer follows.

 

12. In APB, There are two phases. SETUP and ACCESS. The ACCESS phase is indicated by assertion of PENABLE signal. Why we require this phases?

The signal PENABLE can be driven high at the same time when data and control signals are driven by master and the slave can assert the PREADY when it detects PSEL and PENABLE. 

13. Why there is delay between assertion of PENABLE and Data/Control signals ?? Is there any reason for this delay?

The APB protocol was designed to be simple, so no complex pipelining or timing.So 2 phases allowed the APB master to say what it wanted (the setup phase) and then for the required transfer to occur (the access phase).Everything in one cycle wouldn't work in synchronous logic because the peripheral being accessed won't know there is a transfer request until the end of the first cycle, which for a read access means  will always need a second cycle.

 Or even for write acesses, the peripheral needing to signal wait states won't know to drive PREADY low until it has sampled PSEL/PADDR/PWRITE etc, so again requiring a second cycle for this peripheral decision to be synchronously made and sampled.If  need higher performance, lower latency accesses, use a more complex "system" bus, such as AHB or AXI, and accept more complex interface designs.Control signals (PSEL, PADDR, PWRITE, PPROT etc) are driven at the start of the "setup" phase, and PENABLE is driven once cycle later at the start of the "access" phase.

 It is only PREADY, PSLVERR and PRDATA that are changed during the "access" phase, and there you do PENABLE going high at a time when those PREADY/PSLVERR and PRDATA signals can be changing. But PENABLE, PREADY and PSLVERR valid for the next PCLK rising edge, and PRDATA valid for when PREADY is driven high at the end of the "access" phase.So simplicity of design is the answer. 

1. When should APB slave Sample address/Data for read/write transaction from APB master?

As per APB, for READ/WRITE transaction from master, generate PSEL = 1 in the first clock cycle and then PENABLE = 1 in the next clock cycle.

During the two clock cycles, PADDR, PWDATA, PWRITE signals does not change.  APB slave drives PREADY always HIGH. So the PENABLE goes to '0' in the second clock cycle as per the protocol. We need to drive the PREADY and PSLVERR and the PRDATA from slave at the same clock for the read transfer (which should happen in the ACCESS phase here). Control signals should be sampled by the peripheral at the end of the setup phase.

For write transfers the peripheral can then sample PWDATA either at the end of the setup phase (when PSEL=1 and PENABLE=0) or else at the end of the access phase (when PSEL=1 and PENABLE=1).

PWDATA is guaranteed to be stable throughout the APB access, so it doesn't really matter when you sample it, although we suppose sampling at the end of the access phase is the intention of the protocol as it allows the peripheral one cycle to detect the transfer and then another cycle to then prepare to sample the data.

For read transfers the PRDATA bus is only valid during the access phase, so when PSEL=1 and PENABLE=1 (and PREADY=1), so the master will only sample read data just before PENABLE goes low at the end of the access.

 

First clock    : PSEL = 1 & PWRITE = 0/1 (read/write, here PREADY is LOW by default)

Second clock: PSEL =1 & PENABLE = 1 & PWRITE = 0/1 

(For write mem[paddr] <= pwdata and for read prdata <= mem[paddr])

Third clock cycle: PREADY =1 

For write transfers, the addr/data is sampled when PSEL =1 and PENABLE = 1 (SECOND CLOCK).

Later PREADY = 1 is driven in the next clock cycle (which is third clock cycle) where the data is written to the internal registers to make sure both data and PREADY happens at same time. But this takes three cycles to complete one APB write/read transfer. The same is done with read transfer where PRDATA and PREADY =1 is driven in third clock cycle.

Make PREADY =1 by default, the APB master will complete transfer in TWO clock cycles as per protocol. But PRDATA will be only available in third clock cycle by which time PSEL & PENABLE goes to LOW. So now prdata is not valid for Master.

 2. Why is there no wait signal on the APB?

PREADY can remain high forever if you don't want to add wait states. If you are connecting an APB2 peripheral (with no PREADY output) to an APB3 master, you would just tie the PREADY input on the master high.PREADY is only checked during the "ACCESS" phase of an APB access, so during periods when PSEL is low, or when PSEL is high but PENABLE is low (the transfer "SETUP" phase), PREADY is undefined and could be high.

Typically the driver software will first access a status register to determine that data is available
and only then access the data register. Both of these accesses are possible without the addition of wait states and therefore the peripheral can easily be accessed as an APB device.

Peripherals which do require wait states can be designed as AHB slaves and in the rare case that a design does include a large number of these peripherals then a secondary stub AHB can be used to reduce the  loading on the main system bus.

3. How should AHB to APB bridges handle accesses that are not 32-bits?

The bridge should simply pass the entire 32-bit data bus through the bridge. When transfers less than 32-bits are performed to an APB slave it is important to ensure that the peripheral is located on the appropriate bits of the APB data bus

4. For your initial descriptions of the first clock and second clock, why can't PREADY be high during the second clock?

If  memory just needs an enable signal to know when PWDATA should be sampled, this just needs to be when PSEL & PWRITE & PENABLE is 1'b1 if the data input is a latch, or the falling edge of the PSEL & PWRITE & PENABLE logic (both probably also including some PADDR decoding).

If we use the above logic during the second clock just to know when to sample data, but this isn't written to the actual memory until one cycle later, then you could drive PREADY one cycle later as you describe, but that is something your design requires, not something the protocol requires.

For reads start the memory access as soon as PENABLE goes high, so if the memory being accessed can generate valid PRDATA during that single cycle "second clock", again PREADY could also be driven high in this cycle. If PRDATA cannot be driven valid during the second clock cycle, again that is a design issue requiring an extra cycle, not something mandated by the APB spec.

It sounds like your PRDATA not being valid until the third clock cycle is an access time limitation of the register/memory being accessed, so having PREADY allows you to stall the APB access until the peripheral can drive back valid read data, but as you know the address being read at the end of the first clock cycle, the protocol does then allow the peripheral to immediately then start returning read data to be sampled by the APB master at the end of the second cycle, so not requiring 3 cycles.

2 cycles is the basic access timing for APB, PREADY allows you to extend this access timing, but only if the peripheral being accessed needs additional access time.APB basic access time is 2 cycles. (1st - SETUP, 2nd - ACCESS PHASE)

 

For write transfers, we can achieve the 2 cycles completion phase by driving PREADY =1 by default or making it HIGH in the second clock cycle (PSEL = 1 , PWRITE =1 , PENABLE =1)  where PADDR , PWDATA is sampled in the second clock cycle. Here we are sure that the data is written to the address specified in the internal register/memory of the slave.

For read transfer, as per earlier details , PADDR is sampled in ACCESS PHASE. So we cant have the PRDATA in the same clock cycle. It takes additional cycle to return the data. So we drive PREADY =1 only when valid data is available. (3rd clock)

    As per protocol, to achieve valid PRDATA and PREADY =1 from slave in second clock cylce, PADDR should be sampled in the SETUP phase (first clock cycle) only,it is indicated to sample paddr during access phase only. So we cant realize if data sampled in access phase. But can be achieved only when sampled in Setup phase (PSEL =1 and PENABLE = 0). As these are NBA assignments it definitely required one cycle to return data.  Sampling should be done only during access phase.

5. In some designs we see that PREADY is driven HIGH all the time. In such scenarios, how do the designer ensure PRDATA is valid in second clock cycle?

 Control signals should be sampled by the peripheral at the end of the setup phase", so this would then allow the peripheral to start driving PRDATA at the start of the access phase, and so allow the transfer to complete at the end of a single cycle access phase if the peripheral's access time allows PRDATA to be valid at the end of that cycle.

This is how read accesses can be completed in 2 cycles, and is how accesses HAD TO work in the first releases of APB where there was no PREADY signal.

6.In APB, Why do we use enable signal?

       In APB, PSELx is used for selecting the slaves on APB bus and PENABLE is used to indicate second cycle of an APB transfer. There is no ready signal, so in order to do data transfer, master and slave both will use enable signal to know that data transfer is done. However the ready signal is added in APB 3.0 and then ready has to be used along with enable to know if data transfer is done.

APB Bridge generates one PSELx signal for each slave, and all the slaves share the same PENABLE signal. if u are design a slave. the PSEL should decode from an address decoder to select which APB slave. So if the APB slave device is not selected than just ignore the PENABLE.

Example: assign select = PWRITE? (PSEL & PENABLE) : (PSEL | PEN)

First clock : PSEL = 1 & PWRITE = 0/1 (read/write, here PREADY is LOW by default)

Second clock : PSEL =1 & PENABLE = 1 & PWRITE = 0/1   (for write mem[paddr] <= pwdata and for read prdata <= mem[paddr])

Third clock cycle : PREADY =1 

7. For write transfers, the addr/data is sampled when PSEL =1 and PENABLE = 1 (SECOND CLOCK). Later PREADY = 1 is driven in the next clock cycle (which is third clock cycle) where the data is written to the internal registers to make sure both data and PREADY happens at same time.

But this takes three cycles to complete one APB write/read transfer. The same is done with read transfer where PRDATA and PREADY =1 is driven in third clock cycle 

If I make PREADY =1 by default, the APB master will complete transfer in TWO clock cycles as per protocol. But PRDATA will be only available in third clock cycle by which time PSEL & PENABLE goes to LOW. So now prdata is not valid for Master.

Please suggest how can we realize making PRDATA have valid data in second clock cycle when PREADY =1 always HIGH

 

8. How can we realize making PRDATA have valid data in second clock cycle when PREADY =1 always HIGH? For your initial descriptions of the first clock and second clock, why can't PREADY be high during the second clock?

If your memory just needs an enable signal to know when PWDATA should be sampled, this just needs to be when PSEL & PWRITE & PENABLE is 1'b1 .if the data input is a latch, or the falling edge of the PSEL & PWRITE & PENABLE logic (both probably also including some PADDR decoding).

If you are using the above logic during the second clock just to know when to sample data, but this isn't written to the actual memory until one cycle later, then you could drive PREADY one cycle later as you describe, but that is something your design requires, not something the protocol requires.

For reads you could start the memory access as soon as PENABLE goes high, so if the memory being accessed can generate valid PRDATA during that single cycle "second clock", again PREADY could also be driven high in this cycle. If PRDATA cannot be driven valid during the second clock cycle, again that is a design issue requiring an extra cycle, not something mandated by the APB spec.

It sounds like your PRDATA not being valid until the third clock cycle is an access time limitation of the register/memory being accessed, so having PREADY allows you to stall the APB access until the peripheral can drive back valid read data, but as you know the address being read at the end of the first clock cycle, the protocol does then allow the peripheral to immediately then start returning read data to be sampled by the APB master at the end of the second cycle, so not requiring 3 cycles.

2 cycles is the basic access timing for APB, PREADY allows you to extend this access timing, but only if the peripheral being accessed needs additional access time.

 APB basic access time is 2 cycles. (1st - SETUP, 2nd - ACCESS PHASE)

For write transfers, we can achieve the 2 cycles completion phase by driving PREADY =1 by default or making it HIGH in the second clock cycle (PSEL = 1 , PWRITE =1 , PENABLE =1)  where PADDR , PWDATA is sampled in the second clock cycle. Here we are sure that the data is written to the address specified in the internal register/memory of the slave.

For read transfer, as per earlier details, PADDR is sampled in ACCESS PHASE. So we can’t have the PRDATA in the same clock cycle. It takes additional cycle to return the data. So we drive PREADY =1 only when valid data is available. (3rd clock)

    As per protocol, to achieve valid PRDATA and PREADY =1 from slave in second clock cycle, PADDR should be sampled in the SETUP phase (first clock cycle) only, but in earlier discussion ,it is indicated to sample paddr during access phase only. So we cant realize if data sampled in access phase. But can be achieved only when sampled in Setup phase (PSEL =1 and PENABLE = 0). As these are NBA assignments it definitely required one cycle to return data. But  understand that Sampling should be done only during access phase.

In some designs we see that PREADY is driven HIGH all the time. In such scenarios, how does the designer ensure PRDATA is valid in second clock cycle?

 Control signals should be sampled by the peripheral at the end of the setup phase", so this would then allow the peripheral to start driving PRDATA at the start of the access phase, and so allow the transfer to complete at the end of a single cycle access phase if the peripheral's access time allows PRDATA to be valid at the end of that cycle. This is how read accesses can be completed in 2 cycles, and is how accesses HAD TO work in the first releases of APB where there was no PREADY signal.

 AMBA protocols never specify max frequencies because that frequency will depend on the silicon library you are targeting, the complexity of the system you are designing, and how much effort you put into synthesis (not just going for simple timing budgets).

9. What is the difference between with wait state and with no wait state(read/write)?what are the advantages of both in APB?

Use a wait state if your periperal access timing requires it, or don't use a wait state if you don't need one.

 

10. What is an error condition in APB transfer and when it is valid?

PSLVERR to indicate an error condition on an APB transfer. Error conditions can occur on both read and write transactions.PSLVERR is only considered valid during the last cycle of an APB transfer, when PSELPENABLE, and PREADY are all HIGH.

 It is recommended, but not mandatory, that drive PSLVERR LOW when it is not being sampled. That is, when any of PSELPENABLE, or PREADY are LOW.

 Transactions that receive an error, might or might not have changed the state of the peripheral. This is peripheral-specific and either is acceptable. When a write transaction receives an error this does not mean that the register within the peripheral has not been updated. Read transactions that receive an error can return invalid data. There is no requirement for the peripheral to drive the data bus to all 0s for a read error.

  APB peripherals are not required to support the PSLVERR pin. This is true for both existing and new APB peripheral designs. Where a peripheral does not include this pin then the appropriate input to the APB bridge is tied LOW.

  11. PSLVERR

 When bridging:

 From AXI to APB An APB error is mapped back to RRESP/BRESP = SLVERR. This is achieved by mapping PSLVERR to the AXI signals

 

RRESP[1] for reads and BRESP[1] for writes.

 

From AHB to APB PSLVERR is mapped back to HRESP = ERROR for both reads and writes. This is achieved by mapping PSLVERR to the AHB signal HRESP[0].

 

12. Operational activity of the APB

  

IDLE This is the default state of the APB.

 

SETUP When a transfer is required the bus moves into the SETUP state, where the appropriate select signal, PSELx, is asserted. The bus only remains in the SETUP state for one clock cycle and always moves to the ACCESS state on the next rising edge of the clock.

 

ACCESS The enable signal, PENABLE, is asserted in the ACCESS state. The address, write, select, and write data signals must remain stable during the transition from the SETUP to ACCESS state.Exit from the ACCESS state is controlled by the PREADY signal from the slave:

 If  PREADY is held LOW by the slave then the peripheral bus remains in the ACCESS state.

  

If PREADY is driven HIGH by the slave then the ACCESS state is exited and the bus returns to the IDLE state if no more transfers are required. Alternatively, the bus moves directly to the SETUP state if another transfer follows.

 

 



12. In APB, There are two phases. SETUP and ACCESS. The ACCESS phase is indicated by assertion of PENABLE signal. Why we require this phases?

The signal PENABLE can be driven high at the same time when data and control signals are driven by master and the slave can assert the PREADY when it detects PSEL and PENABLE. 

13. Why there is delay between assertion of PENABLE and Data/Control signals ?? Is there any reason for this delay?

The APB protocol was designed to be simple, so no complex pipelining or timing.So 2 phases allowed the APB master to say what it wanted (the setup phase) and then for the required transfer to occur (the access phase).Everything in one cycle wouldn't work in synchronous logic because the peripheral being accessed won't know there is a transfer request until the end of the first cycle, which for a read access means  will always need a second cycle.

 Or even for write acesses, the peripheral needing to signal wait states won't know to drive PREADY low until it has sampled PSEL/PADDR/PWRITE etc, so again requiring a second cycle for this peripheral decision to be synchronously made and sampled.If  need higher performance, lower latency accesses, use a more complex "system" bus, such as AHB or AXI, and accept more complex interface designs.Control signals (PSEL, PADDR, PWRITE, PPROT etc) are driven at the start of the "setup" phase, and PENABLE is driven once cycle later at the start of the "access" phase.

 It is only PREADY, PSLVERR and PRDATA that are changed during the "access" phase, and there you do PENABLE going high at a time when those PREADY/PSLVERR and PRDATA signals can be changing. But PENABLE, PREADY and PSLVERR valid for the next PCLK rising edge, and PRDATA valid for when PREADY is driven high at the end of the "access" phase.So simplicity of design is the answer.

 Scenario based Questions

1.Design of APB master and slave connected back to back. Slave component has simple reg with 16 locations. As per APB, for READ/WRITE transaction from master I am generating PSEL = 1 in the first clock cycle and then PENABLE = 1 in the next clock cycle. During the two clock cycles, PADDR, PWDATA, PWRITE signals does not change. Here APB slave drives PREADY always HIGH. So the PENABLE goes to '0' in the second clock cycle as per the protocol. Is when should APB slave SAMPLE the Control/Data Signals from Master for both READ/WRITE transfers? Is it in the SETUP phase or the ACCESS phase. We need to drive the PREADY and PSLVERR and the PRDATA from slave at the same clock for the read transfer (which should happen in the ACCESS phase).

Control signals should be sampled by the peripheral at the end of the setup phase.

For write transfers the peripheral can then sample PWDATA either at the end of the setup phase (when PSEL=1 and PENABLE=0) or else at the end of the access phase (when PSEL=1 and PENABLE=1). PWDATA is guaranteed to be stable throughout the APB access, so it doesn't really matter when you sample it, although We suppose sampling at the end of the access phase is the intention of the protocol as it allows the peripheral one cycle to detect the transfer and then another cycle to then prepare to sample the data.

 For read transfers the PRDATA bus is only valid during the access phase, so when PSEL=1 and PENABLE=1 (and PREADY=1), so the master will only sample read data just before PENABLE goes low at the end of the access.

2.For initial descriptions of the first clock and second clock, why can't PREADY be high during the second clock?

If  memory just needs an enable signal to know when PWDATA should be sampled, this just needs to be when PSEL & PWRITE & PENABLE is 1'b1 if the data input is a latch, or the falling edge of the PSEL & PWRITE & PENABLE logic (both probably also including some PADDR decoding).

If we are using the above logic during the second clock just to know when to sample data, but this isn't written to the actual memory until one cycle later, then you could drive PREADY one cycle later , but that is something the design requires, not something the protocol requires.

For reads could start the memory access as soon as PENABLE goes high, so if the memory being accessed can generate valid PRDATA during that single cycle "second clock", again PREADY could also be driven high in this cycle. If PRDATA cannot be driven valid during the second clock cycle, again that is a design issue requiring an extra cycle, not something mandated by the APB spec.

It sounds like your PRDATA not being valid until the third clock cycle is an access time limitation of the register/memory being accessed, so having PREADY allows you to stall the APB access until the peripheral can drive back valid read data, but as you know the address being read at the end of the first clock cycle, the protocol does then allow the peripheral to immediately then start returning read data to be sampled by the APB master at the end of the second cycle, so not requiring 3 cycles.2 cycles is the basic access timing for APB, PREADY allows you to extend this access timing, but only if the peripheral being accessed needs additional access time.

3. APB basic access time is 2 cycles. (1st - SETUP, 2nd - ACCESS PHASE).For write transfers, we can achieve the 2 cycles completion phase by driving PREADY =1 by default or making it HIGH in the second clock cycle (PSEL = 1, PWRITE =1 , PENABLE =1)  where PADDR , PWDATA is sampled in the second clock cycle. Here we are sure that the data is written to the address specified in the internal register/memory of the slave. For read transfer, as per earlier details, PADDR is sampled in ACCESS PHASE. So we can’t have the PRDATA in the same clock cycle. It takes additional cycle to return the data. So we drive PREADY =1 only when valid data is available. (3rd clock).   

 As per protocol, to achieve valid PRDATA and PREADY =1 from slave in second clock cylce, PADDR should be sampled in the SETUP phase (first clock cycle) only, but it is indicated to sample paddr during access phase only. So we can’t realize if data sampled in access phase. But can be achieved only when sampled in Setup phase (PSEL =1 and PENABLE = 0). As these are NBA assignments it definitely required one cycle to return data. But understand that Sampling should be done only during access phase. In some designs we see that PREADY is driven HIGH all the time. In such scenarios, how do the designer ensure PRDATA is valid in second clock cycle?

Control signals should be sampled by the peripheral at the end of the setup phase", so this would then allow the peripheral to start driving PRDATA at the start of the access phase, and so allow the transfer to complete at the end of a single cycle access phase if the peripheral's access time allows PRDATA to be valid at the end of that cycle. This is how read accesses can be completed in 2 cycles, and is how accesses HAD TO work in the first releases of APB where there was no PREADY signal.

4.pstrb = "0000" during read transaction. But what happens if pstrb = "0000" during write transaction. Does data successfully transferred without update? And also I want to know if it is possible to use pstrb = "0101", "1010" or "1001"?

According to APB documents, any cases are possible because each bit corresponds to one byte-lane. In the case of '0000', you can properly handle it as you thought (transfer w/o overwrite).

4. In APB3 spec it is mentioned that "APB peripherals are not required to support the PSLVERR pin". Does it mean that both APB Master and APB Slave PSLVERR is optional or it is optional only for APB Slave? What if APB Slave supports PSLVERR but APB Master doesn't?

 As the APB protocol is targeted at simple slave designs, not all will need to indicate error conditions, so those peripherals wouldn't need to have a PSLVERR output (as opposed to forcing them to have one just permanently tied to 1'b0).However for the APB3 master it would need to have a PSLVERR input.If the APB3 master didn't, it wouldn't then know if any of the APB3 peripherals connected to it were signaling error conditions, so potentially a system failure. So you cannot connect APB3 peripherals that might want to signal error conditions (PSLVERR) or wait states (PREADY) to an older APB2 master which doesn't support these signals.

5. Can PENABLE be removed from APB as it seems redundant at IO level and same logic can be taken care of internally by Master and Slave?

 

PENABLE indicates the second and subsequent cycles of an APB transfer till PREADY goes HIGH.APB transfer can be considered as complete when PSEL==1 and PREADY==1 ignoring PENABLE==1 and PREADY==1 should be considered only after second and subsequent cycles of an APB transfer internally by both Master and Slave.

Design an APB slave that didn't need a PENABLE input as you describe. It would need a simple state machine to track the "idle", "setup" and "access" phases of each transfer. When PSEL is first sampled high on a PCLK rising edge this is the single cycle "setup" phase of a transfer when PREADY is "undefined", and then on each subsequent PCLK rising edge you would test PREADY to detect the end of the "access" phase of the transfer.


The peripheral can then use the detected "setup" and "access" phases to know when to sample the PADDR/PWRITE timed control signals, and when to drive or sample PWDATA/PRDATA.If PSEL is next sampled low, the state machine moves into the "idle" state, but if PSEL is still sampled high the state machine moves back into the single cycle "setup" phase again for a back to back sequence of transfers.PENABLE must still be generated by the APB master so that simpler APB peripheral designs can just detect the "setup" and "access" phases of each transfer by gating together PSEL, PENABLE and PREADY.

So you have two choices how to design the APB slave, either using PENABLE or by implementing a simple state machine.

 

6. PENABLE with respect to PREADY.    1) Can pready remain high for more than one cycle?   2) Does PENABLE from the master has to look for PREADY going low to deassert or it should go low the cycle next to the assertion of PREADY?

1) yes, PREADY can remain high for multiple cycles. When not in the "access" phase of a transfer, PREADY is undefined, so could be driven high.PREADY high could be the default value of this signal, as it only needs to be driven low during the "access" phase of a transfer in which the peripheral wants to add wait states.

2) PENABLE will go low as soon as PREADY is sampled high on a PCLK rising edge. This indicates the end of that APB transfer.

     All of the diagrams in the APB specification will show PENABLE go low when PREADY is sampled high on PCLK rising. So the master asserts PENABLE to start the "access" phase of the transfer, and then each subsequent PCLK rising edge it will check PREADY to see when the "access" phase is ending, at which point it will then de-assert PENABLE.

7)State machine of an APB. I was curious on how the PREADY signal is triggered low so that it can exit from the ACCESS state? 

If the peripheral is driving PREADY low, this means it is adding wait states to extend the ACCESS state, not exit it. When the peripheral can complete the requested transfer it will drive PREADY high, and then on the next PCLK rising edge the state machine will move to either IDLE or SETUP.

8) APB uses massive memory-I/O accesses. What is that massive memory-I/O accesses?

APB is NOT suitable for memory type accesses as it has limited support for narrow transfers (i.e. no SIZE signal), and as each access must take a minimum of 2 PCLK cycles it isn't exactly good for performance

 

9). Why APB masters must drive all bits of PSTRB LOW.It seems that APB slaves can just ignore PSTRB bits for read transactions. What happens if we do not comply with it? Why we must drive all bits of PSTB LOW for read transacitons.As PSTRB gives validity to data on write bus,  it's because only one transaction is available on APB at once. But we can use PWRITE signal to avoid it.

AXI

Name five special features of AXI

The key features of the AXI protocol are:
• separate address/control and data phases
• support for unaligned data transfers, using byte strobes
• uses burst-based transactions with only the start address issued
• separate read and write data channels, that can provide low-cost Direct Memory Access (DMA)
• support for issuing multiple outstanding addresses
• support for out-of-order transaction completion
• permits easy addition of register stages to provide timing closure

 

1. How AXI is different from AHB?

Advanced High-performance Bus is a single channel Bus, the Advanced eXtensible Interface is a multi- chanel Bus. The AHB is also a shared Bus whereas the AXI is a read/write optimized bus.

In AHB, each of the bus masters will connect to a single-channel shared bus. On the other hand, the bus master in AXI will connect to a Read data channel, Read address channel, Write data channel, Write address channel and Write response channel.

Bus latencies in AHB start lower than the AXI. The AHB starts at 16 Byte transactions where as the AXI starts at 64 Byte transactions. It can also be seen that the AHB Bus utilization is higher than AXI utilization. Moreover, The Advanced extensible Interface uses around 50 per cent more power, which means that AHB has an edge over it.

Advanced extensible Interface is the third generation of Advanced Microprocessor Bus Architecture interface.

Some of the features of AXI incude separate address/control and data phases, burst based transactions with start address issued, support for unaligned data transfers using byte strobes, easy addition of register stages to provide timing closure and issuing of multiple outstanding addresses.

The AXI, which suits high speed sub-micrometer interconnect, mainly targets high clock frequency system designs and high performance.
Some of the features of Advanced High-performance Bus includes single edge clock protocol, several bus masters, split transactions, pipelined operations, burst transfers, non-tristate implementation and large bus-widths.

2. How-come AXI offers higher performance and throughput than AHB?

It can be observed from the above table it has been mentioned that AXI offers high throughput, i.e high performance. However its rather uncommon to know the actual reasons
and circumstances in which AXI would offer performance boost.
Actual reasons and the circumstances
in which AXI offers performance boost are listed here:

There are 2 basic reasons why AXI may be faster:

1. Simplex Vs Duplex Transfers

AXI has completely independent channels for read/write, which enables full duplex mode of data transportation. That is to say read and writes can take place simultaneously, giving 2x boost over AHB in any circumstances. However this will only be possible when the slave is able to process 1 read and 1 write operation simultaneously in 1 clock cycle. Which in many cases will be possible, e.g. if the slave is a dual port SRAM which can process 1 read and 1 write transaction simultaneously.

We are considering 1 Master and 1 Slave. But in case of multiple slaves, the master can send read transaction to 1 slave and write to other slave, even if the slave(s) cannot handle more than 1 transaction in single clock cycle.

To make more clarity, in a system where there is only 1 master and only 1 slave, the slave is unable to process read and write in 1 single clock cycle simultaneously and both master and slave are in single synchronous clock domain with no clock delay between the master and the slave there won’t be any difference in performance between AXI and AHB. The AXI will only consume more power and area.

3.When there are clock cycle delays between a Master and a responding slave.

       

 This is usually when the Master clock and slave clock is Async, and a there is a clock domain               crossing bridge. It can be  observed in the diagram shown below, that that as the number of OTs

 

       (outstanding transaction) increase in AXI, the efficiency increases. It can also be observed that with 1 OT, again, the performance will be comparable, if we are doing only reads or only writes.
In AXI case, since the system is able to issue outstanding transactions (OT), i.e. able to issue addresses without waiting for data to return, there is only a initial delay, and then the continuous flow of data follows.


In AHB this is not possible. The AHB cannot issue another transaction, without first receiving the response to its only transaction, which it can issue at a time.

 

It is to be noted again, that if there are no clock delays between a master and a slave, and if we assume only 1 master and 1 slave in the system, then again the AXI performance will be equal to AHB performance, if we are doing only reads or only writes.

Why there is no separate response channel for read burst ?

I would guess it is because the VALID/READY handshake mechanism only allows for traffic flow in one direction, so for read transactions the traffic flow is slave to master for both data and response, sharing a VALID/READY handshake, whereas for write transactions the data is master to slave, but the response is slave to master, hence the response needing a separate channel to support the required VALID/READY controls.

         

4.Explain the concept of the AXI 4KB boundary condition?

Addresses that are multiple of 4KB (say 4096, 4096*2, 4096*3 and so-on) are termed as 4KB address boundaries. That is a burst transfer should always satisfy the following condition.
Start_Address % 4096 == (Start_address + (burst_size * burst_length)) % 4096

Examples:
Valid incremental burst transfer:
Starting Addr: 4080, burst_size = 4bytes, burst_length = 2. Ending address: 4088

Invalid incremental burst transfer:
Starting Addr: 8184, burst_size = 4bytes, burst_length = 3. Ending address = 8196. (burst transfer crossing 8192 (4kb address boundary))

A burst transfer should not cross a 4KB address boundary in AXI, as in this case portion of the burst targets one slave, and the rest of the transfer targets the next slave which is an impractical situation.

 

The granularity of mapping in AXI is 4KB. That means the smallest "block" of addresses that can be assigned to a given slave/peripheral is 4KB. And all allocations are multiples of 4KB. So when you cross a 4K boundary you are potentially going from slave A's address space to slave B' Discarding read data that is not required can result in lost data when accessing a read-sensitive device such as a FIFO.

When accessing such a device, a master must use a burst length that exactly matches the size of the required data transfer


 5.Explain the valid ready handshake in AXI?

AXI4 protocol defines five different channels, as described in AXI channels. All of these channels share the same handshake mechanism that is based on the VALID and READY signals, as shown in the following diagram:







The VALID signal goes from the source to the destination, and READY goes from the destination to the source.

Whether the source or destination is a manager or subordinate depends on which channel is being used. The source uses the VALID signal to indicate when valid information is available. The VALID signal must remain asserted, meaning set to high, until the destination accepts the information. Signals that remain asserted in this way are called sticky signals.

The destination indicates when it can accept information using the READY signal. The READY signal goes from the channel destination to the channel source.This mechanism is not an asynchronous handshake, and requires the rising edge of the clock for the handshake to complete.

 6.Differences between transfers and transactions

When designing interconnect fabric, you must know the capabilities of the managers and subordinates that are being connected. Knowing this information lets you include sufficient buffering, tracking, and decode logic to support the various data transfer ordering possibilities that allow performance improvements in faster devices.

Using standard terminology makes understanding the interactions between connected components easier. AXI makes a distinction between transfers and transactions:

  • A transfer is a single exchange of information, with one VALID and READY handshake.
  • A transaction is an entire burst of transfers, containing an address transfer, one or more data transfers, and, for write sequences, a response transfer.

  7.Explain the channel concept?

The AXI protocol defines five channels: three for write signals, and two for read signals.

Write channel signals

The channels used for a write transaction are:

  • Write Address
  • Write Data
  • Write Response

The channels used for a read transaction are:

  • Read Address
  • Read Data

8.Explain the out-of-order concept?

In AXI, a transfer is not completed until the bus master receive the response from the read data channel or write response channel. Also after a bus master issue a transfer, it can issue another transfer without waiting for the first one to complete. If the order of the responses coming back from the slaves arrived in different order from the order that the transfers were issued, we can call it out of order completion.

For any burst transfer what is the condition?

Master has to pass only first address, for the consecutive transfer address calculation is taken care by Slave.

9.What is the fixed burst type?

if the burst length is "1", FIXED and INCR bursts are equivalent. FIXED burst is a transfer of which next address is not changed. INCR burst is a transfer of which next address is incremented by the data size (ARSIZE/AWSIZE). Basically FIXED burst is used for an address fixed I/O port (e.g. UART TX or RX register) to make continual accesses. INCR burst is used for a normal memory device.

i) In a fixed burst, the address remains the same for every transfer in the burst.

ii) In an incrementing burst, the address for each transfer in the burst is an increment of the previous transfer address.

Master behavior?

If the AxSIZE is the same as bus width, they seem to be the same other than AxBUSRT. In the case of the narrow burst, the data alignment on the data bus will differ.

For example, under the condition AWSIZE=1byte and the data bus width is 4bytes and the start address is 0x0, a master of the INCR burst should align data on AWDATA[7:0], AWDATA[15:8], AWDATA[23:16] and AWDATA[31:24] according to every transaction. On the other hands, a master of the FIXED busrt should put data always on AWDATA[7:0].

10.Explain the AXI response types?

Total four response type is there  :

1) OKAY : Normal response used for indication that Normal access is succesfully completed and also used to indicate exclusive access has failed.

2) EXOKAY : Indicates exclusive access is successful. Or indiicates that either read or write portion of exclusive access has been successful. 

3)SLVERR : Indicates that request has been successfully reached to slave but slave has given some error to the request. 

4) DECERR : Indicates that interconnect is not able to find any slave that supports requested transaction address.

From above errors only three error are given by SLAVE AXI.

While DECERR response should be given by Interconnect if it is not able to find suitable SLAVE for requested address from master device.

Spec recommends to keep one default slave to which arbiter route request if it is not able to decode it and that default slave give DECERR response anytime it is requested. 

The AMBA specification defines 3 AXI4 protocols:

  • AXI4: A high performance memory mapped data and address interface. Capable of Burst access to memory mapped devices.
  • AXI4-Lite: A subset of AXI, lacking burst access capability. Has a simpler interface than the full AXI4 interface.
  • AXI4-Stream: A fast unidirectional protocol for transfering data from master to slave.

11.What is AXI Lite?

AXI4-Lite: A subset of AXI, lacking burst access capability. Has a simpler interface than the full AXI4 interface.

 

12.Why streaming support,it's advantages?


AXI4-Stream protocol is used as a standard interface to connect components that wish to exchange data.AXI4-Stream is a protocol designed to transport arbitrary unidirectional data streams. The interface can be used to connect a single master, that generates data, to a single slave, that receives data. The protocol can also be used when connecting larger numbers of master and slave components.

The protocol supports multiple data streams using the same set of shared wires, allowing a generic interconnect to be constructed that can perform upsizing, downsizing and routing operations.The AXI4-Stream interface also supports a wide variety of different stream types. The stream protocol defines the association between Transfers and Packets.

 In AXI4-Stream TDATA width of bits is transferred per clock cycle. The transfer is started once sender signals TVALID and received responds with TREADY. TLAST signals the last byte of the stream.




13,Write an assertion on handshake signals - ready and valid, ready comes after 5 cycles from the start of valid high?

14.Explain AXI read transaction 

An AXI Read transactions requires multiple transfers on the 2 Read channels.

  • First, the Address Read Channel is sent from the Master to the Slave to set the address and some control signals.
  • Then the data for this address is transmitted from the Slave to the Master on the Read data channel.

Note that, as per the figure below, there can be multiple data transfers per address. This type of transaction is called a burst.

 

AXI Write Transactions

An AXI Write transactions requires multiple transfers on the 3 Read channels.

  • First, the Address Write Channel is sent Master to the Slave to set the address and some control signals.
  • Then the data for this address is transmitted Master to the Slave on the Write data channel.
  • Finally the write response is sent from the Slave to the Master on the Write Response Channel to indicate if the transfer was successful.

The possible response values on the Write Response Channel are:

  • OKAY (0b00): Normal access success. Indicates that a normal access has been successful
  • EXOKAY (0b01): Exclusive access okay.
  • SLVERR (0b10): Slave error. The slave was reached successfully but the slave wishes to return an error condition to the originating master (for example, data read not valid).
  • DECERR (0b11): Decode error. Generated, typically by an interconnect component, to indicate that there is no slave at the transaction address

Note: Read transactions also have a response value but this response is transmitted as part of the Read Response Channel


AXI4 Interface requirements

There are some requirement documented in the AXI4 Specification.

The ones you absolutely want to remember are:

  • When a VALID (AxVALID/xVALID) signal is asserted, it must remain asserted until the rising clock edge after the slave asserts AxREADY/xREADY.
     
  • the VALID signal of the AXI interface sending information must not be dependent on the READY signal of the AXI interface receiving that information
    • However, the state of the READY signal can depend on the VALID signal
       
  • A write response must always follow the last write transfer in the write transaction of which it is a part
     
  • Read data must always follow the address to which the data relates
     
  • A slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available


15.What is the AXI capability of data interleaving?

Write data interleave

Write data interleave happen when two AXI bus masters generate sequence of write data to the same slave, but the write data doesn't arrive every clock cycle. In this case, instead of waiting for one sequence to complete before the other sequence start, the AXI infrastructure can interleave the write data sequences together to avoid wasting idle cycles on the bus.

when multiple masters are connected, suppose master1 and master2 wants to perform a write transaction to the same slave then
Master1 with burst of 4 and Master2 with a burst 8

Master1 Master1 Master2 Master2 Master2 .. . Master1 Master1

which means that as the both the masters are accessing the same slave, when Master1 is in idle state during the transaction then interconnect will perform the Master2 transaction.

This happens only in AXI3 where as in AXI4 the Data interleaving is removed as there is no WID for the Data channel.


16.Explain multiple outstanding address pending?


Any flow control mechanism in AXI?

All five channels use the same VALID/READY handshake to transfer data and control information. This two-way flow control mechanism enables both the master and slave to control the rate at which the data and control information moves. The source generates the VALID signal to indicate when the data or control information is available. The destination generates the READY signal to indicate that it accepts the data or control information. Transfer occurs only when both the VALID and READY signals are HIGH.



How to ensure data integrity on AXI?

By ensuring proper channel handshaking dependencies as per the protocol, We can ensure data integrity.

What is 'last' signal?

What are bursts and transfers?

Maximum size of a transfer?

Write response codes?

What is strobing in AXI?

How to count the outstanding transactions in AXI?
2. will get responses from slave for outstanding transactions?

1. For wrapping bursts, the burst length must be 2, 4, 8, or 16
2. A burst must not cross a 4KB address boundary
3. Early termination of bursts it not supported.

 

1. How many transaction channels are there in AXI?

2. Why we don't have read response channel in AXI?

3. what is the handshake process in between master and slave?

4. Difference between AXI3 and AXi4?

5. what is the use of AWID?

6. How much burst is supported by AXI3?

7. what do you mean by wrap burst type?

8. what is narrow transfer?

9. what is aligned and unaligned transfer in AXI3?

10. what is IN-order and out of order transfer?

11. what is strobe?

12. If Wdata is 64bit, what is AWLEN and AWSIZE?

13. If AWLEN is 3 and AWSIZE is 1. what is Burst length and total number of bytes. Also, what is wrap address?

 

In AMBA 2.0 Slave will issue SPLIT and RETRY Response on HRESP Output in following Scenario :


When the command or data Buffer is full or filled enough, and slave will analyse it will take more cycle to finish then slave has to Stop the master , so slave will issue SPLIT or RETRY Command .
SPLIT and RETRY Can be issued as per System Architecture.

write data channel information is always treated as buffered?

Write data channel information is always treated as buffered so that the master can perform write transactions without slave acknowledgment of previous write transactions.

Which channels are exclusive to slave?

Write Response and Read data channels.

Differ Transaction ,burst ,Beats

Transaction - The complete set of required operations on the AXI bus.
Burst - Required payload data to is transferred.
Beats - Burst can comprise multiple data transfers.

https://www.theartofverification.com/understanding-with-axi-protocol-and-cache-coherency/

Each AXI channel transfers information in only one direction, and the architecture does not require any fixed relationship between the channels.

This means a register stage can be inserted at almost any point in any channel, at the cost of an additional cycle of latency.

The characteristics of a transaction(read/write) like burst_length, burst_size, burst type, atomic characteristics, etc are called the control information.

Manages the transactions between the MASTER and SLAVE like Routing, providing responses, buffer.

Shared address and data buses, shared address buses and multiple data buses, multilayer with multiple addresses and data buses.

If the AXI slave component is taking more time in responding back to the master for the completion of the transfer then such components
are said to be having high initial access latency.

Slave(calculates address of subsequent transfers)

The input and output on hardware are set to individual channels. But the bus is just a pathway from and-to somewhere.

Data interleving increases the throughput.

The AXSIZE signal denotes how much amount of data in bytes can be accommodated in a single beat of the burst.

AXLEN denotes how many transfers are there in a burst.

CACTIVE, CSYSREQ, and CSYSACK.

The strobe signal is used to indicate which bytes of the write data bus are valid for each transfer of data. No, it's only used in a write operation.

 

1) Why there was no Write response for each beat in burst Write. But there is a seperate Read response for each beat in a Read burst ?

All of the AXI channels pass information in only 1 direction (only the xREADY signal goes against the channel direction), so for a slave to give a response back to the master for a write transaction, would need a separate channel.

I guess this channel could have been defined to include a BRESP for each write data item, but this would increase the bandwidth requirement for this channel, and as in most applications you will just repeat the complete transaction for a non-OKAY response, few applications would make use of the additional detail of which transfer in a write burst caused a failure.You do give a RRESP response for each read data item because the higher bandwidth channel is already there,


2) How to terminate A read/write burst ? Specification says we can not stop bursts intermittantly.

you cannot.As soon as the AXI master indicates that it will perform X number of transfers in a transaction, it must complete X transfers. There is no "Early Burst Termination" concept like there was in AHB.

For write transactions the master could complete the burst, but driving the WSTRB bits all to logic '0' (dummy accesses) so that no data is actually being transferred to the slave, but for read transactions there is no equivalent, and so "real" read accesses will be completed.
In AHB Bursts can be early terminated either as a result of the Arbiter removing the HGRANT to a master part way through a burst, or after a slave returns a non-OKAY response to any beat of a burst. Note however that a master cannot decide to terminate a defined length burst unless prompted to do so by the Arbiter or Slave responses.
All AHB Masters, Slaves and Arbiters must be designed to support Early Burst Termination.



3) Can A master can give WLAST in middle of a burst transfer ?

No. WLAST can only be asserted while WVALID is high when the final WDATA of a burst is being transferred. Indicating WLAST (and WVALID) too early in a burst would be a protocol violation.
Also, many slave designs will not use the WLAST input, and will simply count data items coming in, so this would not be a safe (or legal) method of terminating a burst.



4) in the same way if slave assersts RLAST before the completion of a busrt read?

If the slave drives RLAST (and RVALID) too early, this too is a protocol violation, and just as for the WLAST signal, some masters might not be monitoring RLAST, so this illegal use could be missed anyway.

5) If WLAST and RLAST can not do the above cases, then what is the special use of WLAST and RLAST because we are getting individual beat responses anyway?

WLAST and RLAST can be used by masters and slaves that need to be told when the final data in a burst is being transferred.
Most masters and slaves will count the data coming in against how many transfers were indicated on AWLEN and ARLEN, so in these designs the xLAST inputs would not be required.

However to support all master and slave designs, masters must always drive WLAST when appropriate, and slaves must drive RLAST.

6 ) Whats the exact use of Exclusive Read and Write Pair transaction? Where exactly these will be used?

Semaphore passing: Semaphore passing is a software requirement, whereas my background is hardware, so please forgive any vagueness in the following answer.
If you have a shared area of memory used for passing control information between masters (or processes running on a master), you want to make sure that you complete the READ/WRITE sequence without another master changing the shared location.
If your master read the shared memory location, and it was changed by another master before your master could complete the subsequent write to that location, the interim write from the other master would be lost, which could have an impact on how your system works (control information lost)So Exclusive Accesses are a hardware mechanism to support the software, indicating to the master when it did have uninterrupted access to the shared location, meaning that no write accesses from other masters will be accidentally overwritten.


7) Is there a possibility that A Read transaction can complete in One Cycle?
Section 3.1.4 on 3.4 says that "A default ARREADY value of LOW is possible but not recommended, because it implies that the transfer takes at least two cycles, one to assert ARVALID and another to assert ARREADY"

No.

It would take a minimum of 1 clock cycle to pass the address from the master to the slave (assumes ARREADY was high when ARVALID was asserted), and then a minimum of 1 clock cycle to pass the data from the slave to the master (assumes RREADY was high when RVALID was asserted).


If ARREADY is initially low when an address is signaled on ARVALID, it will take one clock cycle for the slave to sample this ARVALID and then assert ARREADY (if it can accept the address), and the address handshake then completes on the next clock rising edge (when both ARREADY and ARVALID are high). So 2 clock cycles just to pass the address from master to slave if ARREADY defaults to LOW.


It would then take at least a further clock cycle before the read data could be returned to the master.

 

 


Exclusive access in AXI protocol


This mechanism enables the implementation of semaphore type of operation without requiring the bus to remain the locked to a particular master for the duration of the operation.
the advantage of exclusive access is that semaphore type operation does not impact either critical bus access latency or the maximum achievable bandwidth.

Four Atomic accesses: Normal, exclusive, locked and reserved
the signal name for atomic access: AWLOCK n ARLOCK

 consider a system in which two AXI master devices are using shared memory and as a system designer, you always will make sure that at a time your one master does not overwrite your memory written by another master.



Consider AXI Master 1 (M1) has initiated exclusive read transaction for address location 12'h100 to 12'h10F. Now slave will start monitoring these addresses for ARID given by M1. Now till exclusive write operation is performed slave monitors that address and if that address is changed by another master M2, it will give an indication of exclusive access failure during the exclusive write transaction and memory will not get updated by M1.



How it works:


What happened in above scenario is that Slave has reserved some memory resource for M1 virtually by given exclusive read request from the master. When the master comes for write transaction for that memory location slave will allow writing that memory resource only if another master device is not using that memory resource other wise data is not written to the memory resource.

So we can avoid memory overwrite problem for shared memory using EXCLUSIVE Access in AXI.

 

Scenario:

Scenario 1:


There is Only 1 AXI master (with support of only 1 Master ID) doing transaction to a slave which is capable of handling multiple outstanding addresses.
So Master sets up A0 address and next A1 address. But since Master is capable of only handling single ID, it will place always only 1 valid ID. Is this kind of transaction also referred to as Multiple out standing addresses?



Scenario 2: There is single master with capability of issuing different ID for different transactions.

 

So if there isA0 with ID 2 and A1 with ID 3, This scenario is called multiple outstanding address. Is my understanding correct?



Scenario 3: In scenario 2, If there are different slaves (1 faster and 1 slower) then how do i issue the out -of order write transaction to different slaves?


Suppose i entered with A0 - ID 2, and A1 - ID 3 on the write address channel and i got the respose of address being accepted. Now i dont know which slave is slow and which is fast. So how do i place my data on the Write data channel? Since the Master dont know which slave is fast or slow, how do i take decision on which data to be placed on Write data channel with corresponding ID and Valid?

 

Scenario 1:


There is Only 1 AXI master (with support of only 1 Master ID) doing transaction to a slave which is capable of handling multiple outstanding addresses.
So Master sets up A0 address and next A1 address. But since Master is capable of only handling single ID, it will place always only 1 valid ID. Is this kind of transaction also referred to as Multiple out standing addresses?



This would only be multiple outstanding addresses assuming addresses A0 and A1 have not yet completed the full data transactions, and assuming the slave has accepted both addresses.
However as they use the same ID there is no possibility of any interleaving or re-ordering.

The only real benefit here of the outstanding address support for this slave is that it has advanced notice of A1, hopefully so that it can prepare to complete that transaction more efficiently once A0 has finished.


Scenario 2: There is single master with capability of issuing different ID for different transactions.

So if there is A0 with ID 2 and A1 with ID 3, This scenario is called multiple outstanding address. Is my understanding correct?



This would also be multiple outstanding transactions, again assuming the A0 and A1 transactions are still active (you have not seen BRESP or RLAST transfers).This time as the IDs are unique, data interleaving and re-ordering could also be supported.


Scenario 3: In scenario 2, If there are different slaves (1 faster and 1 slower) then how do i issue the out -of order write transaction to different slaves?


Suppose i entered with A0 - ID 2, and A1 - ID 3 on the write address channel and i got the respose of address being accepted. Now i dont know which slave is slow and which is fast. So how do i place my data on the Write data channel? Since the Master dont know which slave is fast or slow, how do i take decision on which data to be placed on Write data channel with corresponding ID and Valid?



"Out-of-order" is a term usually referring to slaves, not masters. Slaves can return read data in a different order to that the addresses were received (if the IDs are different), or they can return BRESP write responses at the end of the write data transfers, again in a different order to that of the addresses, if the IDs are different.



Masters can interleave write data to the 2 different slaves (where IDs are unique), but this would be done because the master has that data available, not because it knows a specific slave can accept that data. If this particular data happens to be for your slower slave, WREADY will be driven low from that slave to stall the master until the slave is able to accept that data, and this will stall all data transfers from that master.

However when designing the interconnect logic linking your master to the 2 slaves, and if you knew slave #2 was slow, you could implement some sort of write data buffer on the interconnect output port driving slave #2 so that the buffer fills up quickly with the master data, and then slowly empties at the slave's data rate, thus not impacting on the master.

 

AHB 

Four responses are there same as AXI  with different in indication. 


OKAY :


Indicates transfer is going normally and there is not error as long as this response comes from salve with HREADY signal high. This response indicates transfer has completed successfully.

ERROR :


This response indicates that last transfer was unsuccessful due to some ERROR. Master do not required to repeat the transaction if ERROR response arrived from slave/Arbiter.

RETRY : Indicates transfer can not completed immediately and master should request again the same data to slave. 



SPLIT : Indicates transfer is not completed immediately and master should request same data to slave when slave is ready for data transaction.

Difference between SPLIT and RETRY: 


--> Retry : Slave asks master to request again after sometime arbiter will not remove master from arbitration logic. 
--> SPLIT : Slave tell master that I will tell you when I am ready to serve you request till now arbiter will keep you out of arbitration logic.

1. I have 2 masters M1 and m2, I am initiating write transaction from M1 and M1 connecting to s1. Then if split response initiates from slave S1. Does M1 will again get the grant?

2. When you want to write a location for exclusive write transfer wt is procedure you follow ?

3. How did  you implement lock signal in your vip and if your using multiple masters how it works ?

4. When will get decode error and how did you implemented in your vip?

5. How did you verified out of order transactions?

6. Wt are test scenarios you developed in your vip  and how u verified, did u meet the design criteria?

7. Consider un aligned address tell me what should be strobe first beat and why we don't have strobe for rd data channel ?

8. Why we use wrap transfer and why can't use simple increment transfer?

9. Master issued write transaction with awlen 10. Which means 10 beats, after that master think I don't want to write all 10 locations then it's writes only 5 beats. First in that  case can I assert wlast signal ?

 Why we need bridge?

How will connect SRAM in the design and can perform read and write operation through Bridge?

How to terminate A read/write burst ? Specification says we can not stop bursts intermittantly.

As soon as the AXI master indicates that it will perform X number of transfers in a transaction, it must complete X transfers. There is no "Early Burst Termination" concept like there was in AHB.

For write transactions the master could complete the burst, but driving the WSTRB bits all to logic '0' (dummy accesses) so that no data is actually being transferred to the slave, but for read transactions there is no equivalent, and so "real" read accesses will be completed.


In AHB Bursts can be early terminated either as a result of the Arbiter removing the HGRANT to a master part way through a burst, or after a slave returns a non-OKAY response to any beat of a burst. Note however that a master cannot decide to terminate a defined length burst unless prompted to do so by the Arbiter or Slave responses.

All AHB Masters, Slaves and Arbiters must be designed to support Early Burst Termination.


3) Can A master can give WLAST in middle of a burst transfer ?

Answer : No. WLAST can only be asserted while WVALID is high when the final WDATA of a burst is being transferred. Indicating WLAST (and WVALID) too early in a burst would be a protocol violation.
Also, many slave designs will not use the WLAST input, and will simply count data items coming in, so this would not be a safe (or legal) method of terminating a burst.


4) in the same way if slave assersts RLAST before the completion of a busrt read?

If the slave drives RLAST (and RVALID) too early, this too is a protocol violation, and just as for the WLAST signal, some masters might not be monitoring RLAST, so this illegal use could be missed anyway.

5) If WLAST and RLAST can not do the above cases, then what is the special use of WLAST and RLAST because we are getting individual beat responses anyway?

WLAST and RLAST can be used by masters and slaves that need to be told when the final data in a burst is being transferred.


Most masters and slaves will count the data coming in against how many transfers were indicated on AWLEN and ARLEN, so in these designs the xLAST inputs would not be required.

However to support all master and slave designs, masters must always drive WLAST when appropriate, and slaves must drive RLAST.


6 ) Whats the exact use of Exclusive Read and Write Pair transaction? Where exactly these will be used?

Semaphore passing: If you have a shared area of memory used for passing control information between masters (or processes running on a master), you want to make sure that you complete the READ/WRITE sequence without another master changing the shared location.

If your master read the shared memory location, and it was changed by another master before your master could complete the subsequent write to that location, the interim write from the other master would be lost, which could have an impact on how your system works (control information lost)

So Exclusive Accesses are a hardware mechanism to support the software, indicating to the master when it did have uninterrupted access to the shared location, meaning that no write accesses from other masters will be accidentally overwritten.

7) Is there a possibility that A Read transaction can complete in One Cycle?

 "A default ARREADY value of LOW is possible but not recommended, because it implies that the transfer takes at least two cycles, one to assert ARVALID and another to assert ARREADY"

No.It would take a minimum of 1 clock cycle to pass the address from the master to the slave (assumes ARREADY was high when ARVALID was asserted), and then a minimum of 1 clock cycle to pass the data from the slave to the master (assumes RREADY was high when RVALID was asserted).

If ARREADY is initially low when an address is signaled on ARVALID, it will take one clock cycle for the slave to sample this ARVALID and then assert ARREADY (if it can accept the address), and the address handshake then completes on the next clock rising edge (when both ARREADY and ARVALID are high). So 2 clock cycles just to pass the address from master to slave if ARREADY defaults to LOW.It would then take at least a further clock cycle before the read data could be returned to the master.

  

AHB 

Four responses are there same as AXI   with different in indication. 

OKAY

Indicates transfer is going normally and there is not error as long as this response comes from salve with HREADY signal high. This response indicates transfer has completed successfully.

ERROR

This response indicates that last transfer was unsuccessful due to some ERROR. Master do not required to repeat the transaction if ERROR response arrived from slave/Arbiter.

RETRY

Indicates transfer cannot completed immediately and master should request again the same data to slave. 

SPLIT

Indicates transfer is not completed immediately and master should request same data to slave when slave is ready for data transaction.

Difference between SPLIT and RETRY 


Retry : Slave asks master to request again after sometime arbiter will not remove master from arbitration logic. 


Split : Slave tell master that I will tell you when I am ready to serve you request till now arbiter will keep you out of arbitration logic.

 

1. I have 2 masters M1 and m2, I am initiating write transaction from M1 and M1 connecting to s1. Then if split response initiates from slave S1. Does M1 will again get the grant?

2. When you want to write a location for exclusive write transfer wt is procedure you follow ?

3. How did  you implement lock signal in your vip and if your using multiple masters how it works ?

4. When will get decode error and how did you implemented in your vip?

5. How did you verified out of order transactions?

6. Wt are test scenarios you developed in your vip  and how u verified, did u meet the design criteria?

7. Consider un aligned address tell me what should be strobe first beat and why we don't have strobe for rd data channel ?

8. Why we use wrap transfer and why can't use simple increment transfer?

9. Master issued write transaction with awlen 10. Which means 10 beats, after that master think I don't want to write all 10 locations then it's writes only 5 beats. First in that  case can I assert wlast signal ?

 

Why we need bridge?

How will connect SRAM in the design and can perform read and write operation through Bridge?

How to terminate A read/write burst ? Specification says we can not stop bursts intermittantly.

As soon as the AXI master indicates that it will perform X number of transfers in a transaction, it must complete X transfers. There is no "Early Burst Termination" concept like there was in AHB.

For write transactions the master could complete the burst, but driving the WSTRB bits all to logic '0' (dummy accesses) so that no data is actually being transferred to the slave, but for read transactions there is no equivalent, and so "real" read accesses will be completed.

In AHB, Bursts can be early terminated either as a result of the Arbiter removing the HGRANT to a master part way through a burst, or after a slave returns a non-OKAY response to any beat of a burst.

 Note however that a master cannot decide to terminate a defined length burst unless prompted to do so by the Arbiter or Slave responses.

All AHB Masters, Slaves and Arbiters must be designed to support Early Burst Termination.


AHB Interview Questions

How AHB is pipelined architecture?

What is the size of the max data that can be transferred in a single transfer?

Explain the 1k boundary concept in AHB?

Okay, response is a single cycle? but error/split/retry is two cycles, why?

Explain the concept of a two-cycle response?

What if the slave gets the address out of range?

How to connect multiple slaves to a single master?

Explain the round robin arbitration concept?

Explain the split-retry concept?

What is the difference between HREADY and HREADY_OUT signals?

What is the slave response for a BUSY transfer?

What is the difference between WRAP4 and INCR4?

How to terminate the INCR type transfer?

What is the difference between BURST and Beat?

How to calculate the size of the burst?

Is HREADY is Input or output to/from the slave?

What is the aligned and un-align concept?

Explain wrapping calculation?

Is early burst termination is done by Slave/Arbiter?

Explain the LOCKED transfer?

What is the default Master?

What is a little-endian and big-endian?

How the slave will detect the end of INCR type burst transfer?

AMBA AHB – Arbitration


----------------------


1.         When should a master assert and deassert the HLOCK signal for a locked
transfer?

The HLOCK signal must be asserted at least one cycle before the start of
the address phase of a locked transfer. This is required so that the
arbiter can sample the HLOCK signal as high at the start of the address
phase.

The master should deassert the HLOCK signal when the address phase of the
last transfer in the locked sequence has started.


2. Can an arbiter be designed to always allow bursts to complete?



A SPLIT, RETRY or ERROR response from a slave can always cause a burst to
be early terminated. This is outwith the control of the Arbiter and so must
be supported.



Undefined length INCR bursts cannot have their end point predicted, so
there is no efficient way that an Arbiter design can allow the burst to
complete before granting another master. INCR bursts must be arbitrated on
a cycle by cycle basis.



Defined length INCRx and WRAPx bursts can have their beats counted, and so
allowed to complete by the Arbiter. However because of the AHB arbitration
synchronous timing, there is no way to avoid possibly terminating a burst
immediately after the first transfer of the burst has been indicated.

The Arbiter only knows that a defined length burst is in progress by
sampling the HBURST bus. However the first point at which HBURST can be
sampled is after the first clock cycle of the first burst beat, by which
time the Arbiter may already have decided to grant another master and will
have changed the HGRANT outputs accordingly. Only a combinatorial path from
HBURST to HGRANT would allow the burst to be detected in time to avoid
early termination in this scenario, but combinatorial paths in the AHB bus
are not allowed. ask ARM




3. Why is HADDR sometimes shown as an input to the arbiter?

The address bus, HADDR, is not required as an input to the arbiter but in
some system designs it may be useful to use the address bus to determine a
good point to change over between bus masters. For example, the arbiter
could be designed to change bus ownership when a burst of transfers reaches
a quad word boundary.



4. When can the HGRANT signal change?

The HGRANT signal can change in any cycle and the following cases are
possible:

* It is possible that the HGRANT signal may be asserted and then removed
before the current transfer completes. This is acceptable because the
HGRANT signal is only sampled by masters when HREADY is high.

* A master can be granted the bus without requesting it.

* The above point also means that it is possible to be granted the bus in
the same cycle that it is requested. This can occur if the master is
coincidentally granted the bus in the same cycle that it requests it.


5. What is the relationship between the HLOCK signal and the HMASTLOCK
signal?

At the start of the address phase of every transfer the arbiter will sample
the HLOCK signal of the master that is about to start driving the address
bus and if HLOCK is asserted at this point then HMASTLOCK will be asserted
by the arbiter for the duration of the address phase of the transfer.


6. When should a master deassert its HBUSREQ signal?

For an undefined length burst (INCR) a master must keep its HBUSREQ signal
asserted until it has started the address phase of the last transfer in the
burst. This will mean that if the penultimate transfer in the burst is zero
wait state then the master may be granted the bus for an additional
transfer at the end of an undefined length burst.

For a defined length burst the master can deassert the HBUSREQ signal once
the master has been granted the bus for the first transfer. This can be
done because the arbiter is able to count the transfers in the burst and
keep the master granted until the burst completes.

However it is not a mandatory requirement for an Arbiter to allow a burst
to complete, so the master will have to re-assert HBUSREQ if the Arbiter
removes HGRANT before the burst has been completed.


7. When will the arbiter grant another master after a locked transfer?

The arbiter will always grant the master an extra transfer at the end of a
locked sequence, so the master is guaranteed to perform one transfer with
the HMASTLOCK signal low at the end of the locked sequence. This coincides
with the data phase of the last transfer in the locked sequence.

During this time the arbiter can change the HGRANT signals to a new bus
master, but if the data phase of the last locked transfer receives either a
SPLIT or RETRY response then the arbiter will drive the HGRANT signals to
ensure that either the master performing the locked sequence remains
granted on the bus for a RETRY response, or the Dummy master is granted the
bus for the SPLIT response.


8. Can a master deassert HLOCK during a burst?

The AHB specification requires that all address phase timed control signals
(other than HADDR and HTRANS) remain constant for the duration of a burst.

Although HLOCK is not an address phase timed signal, it does directly
control the HMASTLOCK signal which is address phase timed.

Therefore HLOCK must remain high for the duration of a burst, and can only
be deasserted such that the following HMASTLOCK signal changes after the
final address phase of the burst.


9. If a master is currently granted the bus by default, how many cycles before
starting an non-IDLE transfer does it have to assert HBUSREQ?

None. It can start a non IDLE transfer immediately.


10. Can a master perform transfers other than IDLE when the bus was granted to
it, but not requested by the master?

Yes. A master can perform transfers other than IDLE when it had not
requested the bus. Please note that in this case it is still recommended
that the master asserts its request signal so that the arbiter does not
change ownership of the bus to a lower priority master while the transfers
are in progress.


AMBA 2 AHB – General



1. The specification recommends that only 16 wait states are used. What should
you do if more than 16 cycles are needed?

For some slaves it is acceptable to insert more than 16 wait states. For
example, a serial boot ROM which is only ever accessed at initial power up
could insert a larger number of wait states and it would not affect the
calculation of the system performance and latency once system power up has
been completed.



For other slaves a number of options exist. A SPLIT or RETRY response could
be used to indicate that the slave is not yet able to perform the requested
data transfer, or the slave could be accessed either in response to
interrupts or after polling a status register, in either case indicating
that the slave is now able to respond in an acceptable number of cycles.


2. Why is a burst not allowed to cross a 1 kilobyte boundary?



If an AHB slave samples HSELx at the start of a burst transaction, it knows
it will be selected for the duration of the burst. Also, a slave which is
not selected at the start of a burst will know that it will not become
selected until a new burst is started.



1 kilobyte is the smallest area an AHB slave may occupy in the memory map.
Therefore, if a burst did cross a 1 kilobyte boundary, the access could
start accessing one slave at the beginning of the burst and then switch to
another on the boundary, which must not happen for the above reason.



The 1 kilobyte boundary has been chosen as it is large enough to allow
reasonable length bursts, but small enough that peripherals can be aligned
to the 1 kilobyte boundary without using up too much of the available
memory map.




3. Can an AHB master be connected directly to an AHB slave?

Any slave which does not use SPLIT responses can be connected directly to
an AHB master. If the slave does use SPLIT responses then a simplified
version of the arbiter is also required.



If an AHB master is connected directly to an AHB slave it is important to
ensure that the slave drives HREADY high during reset and that the select
signal HSEL for the slave is tied permanently high.




4. What is the state of the AHB signals during reset?

The specification states that during reset the bus signals should be at
valid levels. This simply means that the signals should be logic '0' or
'1', but not Hi-Z. The actual logic levels driven are left up to the
designer. HTRANS is the only signal specified during reset, with a
mandatory value of IDLE.



It is important that HREADY is high during reset. If all slaves in the
system drive HREADY high during reset then this will ensure that this is
the case. However, if slaves are used which do not drive HREADY high
during reset it should be ensured that a slave which does drive HREADY high
is selected at reset.




5. Can a BUSY transfer occur at the end of a burst?

A BUSY transfer can only occur at the end of an undefined length burst
(INCR). A BUSY transfer cannot occur at the end of a fixed length burst
(SINGLE, INCR4, WRAP4, INCR8, WRAP8, INCR16, WRAP16).




6. What is a default slave?

If the memory map of a system does not define the full 4 gigabyte address
space then a default slave is required, which is selected when an access is
attempted to the empty areas of the memory map. The default slave should
use an OKAY response for IDLE/BUSY transfers and an ERROR response sequence
for NONSEQ/SEQ transfers.




7. Is a default slave really necessary?


If the entire 4 gigabyte address space is defined then a default slave is
not required. If, however, there are undefined areas in the memory map then
it is important to ensure that a spurious access to a non-existent address
location will not lock up the system. The functionality of the default
slave is extremely simple and it will often make sense to implement this
within the decoder.


8. Is a dummy master really necessary?


A dummy master is necessary in any system which has a slave that can give
SPLIT transfer responses. The dummy master is required so that something
can be granted the bus if all the other masters have received a SPLIT
response.

No logic is required for the dummy master and it can be implemented by
simply tying off the inputs to the master address/control multiplexer for
the dummy master position. The requirements for a dummy master are that
HTRANS is driven to IDLE, HLOCK is driven low, and all other master outputs
are driven to legal values.




9. Is it specified that HPROT, HSIZE and HWRITE remain constant throughout a
burst?

Yes, the control signals must remain constant throughout the duration of a
burst.


10. What default state should be used for the HREADY and HRESP outputs from a
slave?

It is recommended that the default value for HREADY is high and the default
value for HRESP is OKAY. This combination ensures that the slave will
respond correctly to IDLE transfers to the slave, even if the slave is in
some form of power saving mode.


11. Is HREADY an input or an output from slaves?



An AHB slave must have the HREADY signal as both an input and an output.

HREADY is required as an output from a slave so that the slave can extend
the data phase of a transfer.



HREADY is also required as an input so that the slave can determine when
the previously selected slave has completed its final transfer and the
first data phase transfer for this slave is about to commence.

Each AHB Slave should have an HREADY output signal (conventionally named
HREADYOUT) which is connected to the Slave-to-Master Multiplexer. The
output of this multiplexer is the global HREADY signal which is routed to
all masters on the AHB and is also fed back to all slaves as the HREADY
input.


12. How many masters can there be in an AHB system?

The AHB specification caters for up to 16 masters. However, allowing for a
dummy bus master means the maximum number of real bus masters is actually
15. By convention bus master number 0 is allocated to the dummy bus
master.


13. Can a master change the address/control signals during a waited transfer?

Yes. If the address/control signals are indicating an IDLE transfer then
the master can change to a real transfer (NONSEQ) when HREADY is low.

However, if a master is indicating a real transfer (NONSEQ or SEQ) then it
cannot cancel this during a waited transfer unless it receives a SPLIT,
RETRY or ERROR response.


14. When a master rebuilds a burst which has been terminated early are there
any limitations on how it rebuilds the burst?

The only limitation is that the master uses legal burst combinations to
rebuild the burst. For example, if a master was performing an 8 beat burst,
but had only completed 3 transfers before losing control of the bus, then
the remaining 5 transfers could be performed either by using a 1 beat
SINGLE burst followed by a 4 beat INCR4 burst, or it could be performed
using a 5 beat undefined length INCR burst.

For simplicity it is recommended that masters use INCR bursts to rebuild
the remaining transfers.


15. What is the recommended default value for HPROT?

Many bus masters will not be able to generate accurate protection
information and for these bus masters it is recommended that the HPROT
encoding shows, Non-cacheable, Non-bufferable, Privileged, Data Accesses
which corresponds to HPROT[3:0] = 4'b0011.


16. Do all slaves have to support the BUSY transfer type?

Yes. All slaves must support the BUSY transfer type to ensure they are
compatible with any bus master.




17. What system support is required if a slave can be powered down or have its
clock stopped?



If a slave access is attempted while that slave is in a power down state or
has had its clock stopped, you must ensure that an access will cause the
power/clock to be restored, or else configure the AHB decoder up to
redirect any such accesses to the dummy slave so that the system does not
hang forever when an access to the device is made when it is disabled.

Redirecting the access in this way will ensure that random "IDLE" addresses
are treated with the HREADY high and HRESP=OKAY default response, but real
accesses (NONSEQ or SEQ) will be detected with an ERROR response.


18. When can Early Burst Termination occur

Bursts can be early terminated either as a result of the Arbiter removing
the HGRANT to a master part way through a burst, or after a slave returns a
non-OKAY response to any beat of a burst. Note however that a master cannot
decide to terminate a defined length burst unless prompted to do so by the
Arbiter or Slave responses.

All AHB Masters, Slaves and Arbiters must be designed to support Early
Burst Termination.




19. Does the address have to be aligned, even for IDLE transfers?

Yes. The address should be aligned according to the transfer size (HSIZE)
even for IDLE transfers. This will prevent spurious warnings from bus
monitors used during simulation.


20. What is the difference between a dummy bus master and a default bus
master?

The term default bus master is used to describe the master that is granted
when none of the masters in the system are requesting access to the bus.
Usually the bus master which is most likely to request the bus is made the
default master.

The dummy bus master is a master which only performs IDLE transfers. It is
required in a system so the arbiter can grant a master which is guaranteed
not to perform any real transfers. The two cases when the arbiter would
need to do this are when a SPLIT response is given to a locked transfer and
when a SPLIT response is given and all other masters have already been
SPLIT.


21. Is it legal for a master to change HADDR when a transfer is extended?

If a master is indicating that it wants to do a NONSEQ, SEQ or BUSY
transfer then it cannot change the address during an extended transfer
(when HREADY is low) unless it receives an ERROR, RETRY or SPLIT response.
If the master is indicating that it wants to do an IDLE transfer then it
may change the address.


22. Can HTRANS change whilst HREADY is low?



In general, an AHB master should not change control signals whilst HREADY
is low. However it is allowable to change HTRANS in the following
conditions:

* HTRANS = IDLE


The AHB master is performing internal operations and has not yet
committed to a bus transfer. However during the AHB wait states (HREADY
low) the master may determine that a bus transfer is required and change
HTRANS on the next cycle to NONSEQ.

* HTRANS = BUSY


HTRANS is being used to give the master time to complete internal
operations, which may be entirely independent of HREADY (i.e. wait states
on the AHB). Therefore HTRANS can change on the next cycle to any legal
value, i.e. SEQ if the burst is to continue, IDLE if the burst has
completed, NONSEQ if a separate burst is to begin.

* HRESP = SPLIT/RETRY


As stated in the AHB specification, a master must assert IDLE on HTRANS
during the second cycle of the two-cycle SPLIT or RETRY slave response so
HTRANS will change value from the first cycle to the second cycle of the
response.

* HRESP = ERROR


The master is permitted to change HTRANS in reaction to an ERROR response
in the same way as in reaction to a SPLIT/RETRY response and cancel any
further beats in the current burst (even if HBURST is indicating a
defined-length burst). In this case HTRANS changes to IDLE on the second
cycle of the response. Alternatively, the master is permitted to continue
with the current transfers.




23. What are the different bursts used for?



Typically a master would use wrapping bursts for cache line fills where the
master wants to access the data it requires first and then it completes the
burst to fetch the remaining data it requires for the cache line fill.
Incrementing bursts are used by masters, such as DMA controllers, that are
filling a buffer in memory which may not be aligned to a particular address
boundary.


24. What sequences of transfers types (HTRANS) can occur on the bus?



The following examples show some of the sequences of HTRANS that can occur
on the bus:



A normal burst of four transfers followed by an IDLE.
N - S - S - S – I



A normal burst of four transfers which includes BUSY transfers.
N - S - B - S - B - S – I



A burst of four transfers followed by another burst.
N - S - S - S - N - S - S - S – I



A single transfer followed by a burst of four transfers.
N - N - S - S - S – I



A single transfer followed by an IDLE
N – I



An undefined length burst which concludes with a BUSY transfer.
N - B - S - B - S - B – I



An undefined length burst which concludes with a BUSY transfer and is followed
immediately by another burst.



N - B - S - B - S - B - N – S




25. How should AHB to APB bridges handle accesses that are not 32-bits?

The bridge should simply pass the entire 32-bit data bus through the
bridge. Please note that when transfers less than 32-bits are performed to
an APB slave it is important to ensure that the peripheral is located on
the appropriate bits of the APB data bus.





AHB - Split/Retry




1. What value should be used for HTRANS when an AHB master gets a RETRY
response from a slave in the middle of burst?

Whenever a transfer is restarted it must use HTRANS set to NONSEQ and it
may also be necessary to adjust the HBURST information (usually just to
indicate INCR).




2. What address should be on the bus during the IDLE cycle after a SPLIT or
RETRY?

It does not matter what address is driven onto the bus during this cycle.
The slave selected by the driven address should not take any action and
must respond with a zero wait state OKAY response.

In many cases it will be simpler for the master to leave the address
unaltered during this cycle, so that it remains at the address of the next
transfer that the master wishes to perform and only in the following cycle
does the master return the address to that of the transfer that must be
repeated because of the SPLIT or RETRY response.

In some designs it may be possible for the master to return the address to
that required to repeat the previous transfer during the IDLE cycle and
this behaviour is also perfectly acceptable.



3. Do all masters have to support SPLIT and RETRY?

Yes. All masters must support SPLIT and RETRY responses to ensure they are
compatible with any bus slave. A master will handle both SPLIT and RETRY
responses in an identical manner.




4. Can a SPLIT or RETRY response be given at any point during a burst?

Yes. A SPLIT, RETRY or ERROR response can be given by a slave to any
transfer during a burst. The slave is not restricted to only giving these
responses to the first transfer.




5. Will a master always lose the bus after a SPLIT response?

Yes. A slave must not assert the relevant bit of the HSPLIT bus in the same
cycle that it gives the SPLIT response and therefore the master will always
lose the bus.




6. Can a slave assert HSPLITx in the same cycle that it gives a SPLIT
response?

No. The specification requires that HSPLITx can only be asserted after the
slave has given a SPLIT response.




7. Do all slaves have to support the SPLIT and RETRY responses?

No. A slave is only required to support the response types that it needs to
use. For example, a simple on-chip memory block which can respond to all
transfers in just a few wait states does not need to use either the SPLIT
or RETRY responses.




8. Can a slave use both SPLIT and RETRY responses?

Normally a slave will not use both the SPLIT and RETRY responses. The SPLIT
response should be used by any slave that may be accessed by many different
masters at the same time. The RETRY response is intended to be used by
peripherals that are only accessed by one bus master.


9. What is the difference between SPLIT and RETRY responses?

Both the Split and Retry responses are used by slaves which require a large
number of cycles to complete a transfer. These responses allow a data phase
transfer to appear completed to avoid stalling the bus, but at the same
time indicate that the transfer should be re-attempted when the master is
next granted the bus.



The difference between them is that a SPLIT response tells the Arbiter to
give priority to all other masters until the SPLIT transfer can be
completed (effectively ignoring all further requests from this master until
the SPLIT slave indicates it can complete the SPLIT transfer), whereas the
RETRY response only tells the Arbiter to give priority to higher priority
masters.

A SPLIT response is more complicated to implement than a RETRY, but has the
advantage that it allows the maximum efficiency to be made of the bus
bandwidth.

The master behaviour is identical to both SPLIT and RETRY responses, the
master has to cancel the next access and re-attempt the current failed
access.


AMBA 2 APB – General



1. Why is there no wait signal on the APB?

The APB has been designed to implement as simple an interface as possible.
Having this simple design makes it much easier to connect new APB
peripherals and makes the analysis of the system performance easier to
calculate.

Although many APB peripherals are slow devices, such as UARTs, they are
normally accessed via control registers. Typically the driver software will
first access a status register to determine that data is available and only
then access the data register. Both of these accesses are possible without
the addition of wait states and therefore the peripheral can easily be
accessed as an APB device.

Peripherals which do require wait states can be designed as AHB slaves and
in the rare case that a design does include a large number of these
peripherals then a secondary stub AHB can be used to reduce the loading on
the main system bus.


2. How should AHB to APB bridges handle accesses that are not 32-bits?

The bridge should simply pass the entire 32-bit data bus through the
bridge. Please note that when transfers less than 32-bits are performed to
an APB slave it is important to ensure that the peripheral is located on
the appropriate bits of the APB data bus

 

1.       Question 1. When Should A Master Assert And Deassert The Block Signal For A Locked Transfer?

Answer :

The GLOCK signal must be asserted at least one cycle before the start of the address phase of a locked transfer. This is required so that the arbiter can sample the HLOCK signal as high at the start of the address phase.

The master should deassert the HLOCK signal when the address phase of the last transfer in the locked sequence has started.

2.       Question 2. Can An Arbiter Be Designed To Always Allow Bursts To Complete?


A SPLIT, RETRY or ERROR response from a slave can always cause a burst to be early terminated. This is outwith the control of the Arbiter and so must be supported.

Undefined length INCR bursts cannot have their end point predicted, so there is no efficient way that an Arbiter design can allow the burst to complete before granting another master. INCR bursts must be arbitrated ona cycle by cycle basis.

Defined length INCRx and WRAPx bursts can have their beats counted, and so allowed to complete by the Arbiter. However because of the AHB arbitration synchronous timing, there is no way to avoid possibly terminating a burst immediately after the first transfer of the burst has been indicated.

The Arbiter only knows that a defined length burst is in progress by sampling the HBURST bus. However the first point at which HBURST can be sampled is after the first clock cycle of the first burst beat, by which time the Arbiter may already have decided to grant another master and will have changed the HGRANT outputs accordingly. Only a combinatorial path from HBURST to HGRANT would allow the burst to be detected in time to avoid early termination in this scenario, but combinatorial paths in the AHB bus are not allowed.


3.       Question 3. Why Is Haddr Sometimes Shown As An Input To The Arbiter?

Answer :

The address bus, HADDR, is not required as an input to the arbiter but in some system designs it may be useful to use the address bus to determine a good point to change over between bus masters. For example, the arbiter could be designed to change bus ownership when a burst of transfers reaches a quad word boundary.


No comments: