Bus AMBA APB3 and APB4 have PENABLE signal, but there isn't usage of it in RTL generation file (regblock)

[AaronPham0701]

Hi everyone, can you please help me about this problem below: When I use --cpuif apb3 and apb4, the signal PENABLE is still declared in the interface module. However, I couldn't find any usage of it in the RTL generation code (regblock option) and I need it for my project. Are there any options that use this signal? Or we have to edit the source code to add the usage of it based on our demand? Please help me! Thank you alot!

[amykyta3]

If you look closely at AMBA's specification of the APB3 & APB4 protocols, you'll notice the PENABLE signal is not actually strictly necessary in order for a peripheral to decode transactions. Just using PSEL and PREADY is unambiguous enough to handle a transaction handshake since the "Active" phase unconditionally starts one cycle after the assertion of PSEL.

Some implementations of an APB device may choose to use PENABLE, but for PeakRDL-regblock, it was not necessary and it is still compliant with the AMBA spec. Even so, I chose to keep the PENABLE signal input for compatibility reasons.

If you still find that your application will not function properly without the use of PENABLE, please provide some more detail.

[AaronPham0701]

Hi Mr. Alex, Firstly, I really appreciate your thoughtful response and the comprehensive SystemRDL tool that you are developing. According to the AMBA APB standard specification, PENABLE is one of the mandatory signal that is indispensable for any designs related to APB protocol. I have attached the signal list and marked it as red color for ease of reference. Could you please take your time to investigate it again? I am certain that this problem would help your tool far more developed because we are VLSI professionals who implementing APB protocol for a long time and vividly understand how important PENABLE signal is. Thank you again for your time and helpfulness. Best regards, Aaron

On Wed, 17 Jan 2024 at 11:38 Alex Mykyta @.***> wrote:

If you look closely at AMBA's specification of the APB3 & APB4 protocols, you'll notice the PENABLE signal is not actually strictly necessary in order for a peripheral to decode transactions. Just using PSEL and PREADY is unambiguous enough to handle a transaction handshake since the "Active" phase unconditionally starts one cycle after the assertion of PSEL.

Some implementations of an APB device may choose to use PENABLE, but for PeakRDL-regblock, it was not necessary and it is still compliant with the AMBA spec. Even so, I chose to keep the PENABLE signal input for compatibility reasons.

If you still find that your application will not function properly without the use of PENABLE, please provide some more detail.

— Reply to this email directly, view it on GitHub https://github.com/SystemRDL/PeakRDL-regblock/issues/82#issuecomment-1894926795, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFLGNVGLQCN7I53W2XC7Z23YO5IVXAVCNFSM6AAAAABB26TNECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUHEZDMNZZGU . You are receiving this because you authored the thread.Message ID: @.***>

[amykyta3]

I agree that it is mandatory for masters/initiators to provide PENABLE, but not necessary for slave devices that are APB3 and newer to actually use it due to the reasons described in my first response. PENABLE may be used as a secondary signal to assist some implementations of register files to control register file internals.

Can you please provide details that demonstrate specifically what type of transaction is not working for you? Preferably with a waveform.

[AaronPham0701]

Hi Mr. Alex, Thank you for your reply. I got your point of view, however, here is the FSM which describes in the APB standard. Your generated RDL is the slave, and for implementing this state machine, as you can see at the SETUP state (PENABLE = 0) and ACCESS state (PENABLE = 1) The master will drive this signal, and how your slave could handle this state machine without it? Thank you again for your support. Best regards, Aaron

On Wed, 17 Jan 2024 at 13:23 Alex Mykyta @.***> wrote:

I agree that it is mandatory for masters/initiators to provide PENABLE, but not necessary for slave devices that are APB3 and newer to actually use it due to the reasons described in my first response. PENABLE may be used as a secondary signal to assist some implementations of register files to control register file internals.

Can you please provide details that demonstrate specifically what type of transaction is not working for you? Preferably with a waveform.

— Reply to this email directly, view it on GitHub https://github.com/SystemRDL/PeakRDL-regblock/issues/82#issuecomment-1895013213, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFLGNVGO2P5DGDKL3QZ24YDYO5U5ZAVCNFSM6AAAAABB26TNECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGAYTGMRRGM . You are receiving this because you authored the thread.Message ID: @.***>

[amykyta3]

I am not seeing any of your attachments on github, but I assume you are referring to this FSM diagram:

The spec also explicitly states that the device can only be in the SETUP state for exactly one cycle:

This means for any transfer if PSEL is asserted, the clock cycle that follows is unconditionally the ACCESS state. True, the PENABLE signal also indicates this, but it is possible to design a slave device that omits it due to the unconditional transition from SETUP to ACCESS state. If you study the older APB1 and APB2 specifications, you'll see hints that suggest that PENABLE may have been a historical relic from implementations of APB that used asynchronous & tristated logic. Modern APB3 and APB4 versions of the standard have removed these examples since they are seldom relevant. Even so, some implementations may choose to use PENABLE since it can be used as a clock-enable signal to a flop. PeakRDL-regblock's implementation uses a decoded strobe approach which is able to implicitly stage the transition from SETUP to ACCESS using a pipeline stage. This has the benefit of being a more pipelined approach which can scale better for high frequency designs above 1GHz. This also scales well in FPGAs where fanout congestion can be challenging in dense designs.

I'm happy to review this in more detail if you see that your usage is not able to complete transactions correctly, but please be assured that this strategy has seen numerous ASIC tapeouts that are in production globally and has been validated to be AMBA-compliant.

[amykyta3]

Here is a post on the ARM community forum that may help describe this a different way: https://community.arm.com/support-forums/f/soc-design-and-simulation-forum/81/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/28514#28514

You could 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.

[AaronPham0701]

Thank you so much for your response, Mr. Alex. I got your point, and I totally agree. Thank you so much, again!