This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

About AHB5 protection control signals

In AHB5, we have extended memory bits as [6:4] hprot. Previously we have [3:0] hprot. For implementation purpose, i treated [6:4] as a separate signal. This separate signal am qualifying based on some filter, just because not to consider for older AHB. Please suggest me, whether am doing in correct way.

Parents
  • Hi smata,

    There isn't really much anyone could suggest here, it sounds is if your tool's "randomize" function isn't very random if you don't see these bits driven low.

    Going by table 3-6 in the protocol, non-shared and non-allocated transfers are valid (as demonstrated by the first 5 memory types listed), so it can't be something the tool has forbidden as illegal.

    This is probably something you should be asking the supplier of the verification tool to see why you never see these 2 bits tested as you require.


    JD

Reply
  • Hi smata,

    There isn't really much anyone could suggest here, it sounds is if your tool's "randomize" function isn't very random if you don't see these bits driven low.

    Going by table 3-6 in the protocol, non-shared and non-allocated transfers are valid (as demonstrated by the first 5 memory types listed), so it can't be something the tool has forbidden as illegal.

    This is probably something you should be asking the supplier of the verification tool to see why you never see these 2 bits tested as you require.


    JD

Children
No data