Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STAT reg #34

Closed
mkrivda opened this issue Jan 24, 2018 · 6 comments
Closed

STAT reg #34

mkrivda opened this issue Jan 24, 2018 · 6 comments

Comments

@mkrivda
Copy link

mkrivda commented Jan 24, 2018

We have a universal board which has several firmware types, so we need to have read-only register with FW_TYPE at defined address which is the same for all types of firmware.
We have used STAT reg inside CTRL type reg.
If we add more CTRL reg then address for STAT reg changes as they are created after CTRL regs.
Is it possible to modify firmware in such way that STAT registers are created first ?

@tswilliams
Copy link
Collaborator

Hi,

I assume that you are referring to the ipbus_ctrlreg_v entity that's defined within ipbus_ctrlreg_v.vhd. If that's not the case, please let me know

I do not believe that it would be possible at this stage to change the order of the STAT & CTRL register within ipbus_ctrlreg_v, as that would be a backward-incompatible change that would affect many other people.

Instead, given the fixed-address constraint on the firmware version/type register(s) in your case, I think that a more feasible solution would be for you to declare the CTRL and STAT register blocks as two separate components in place of the single ipbus_ctrlreg_v entity that you're currently instantiating.

Cheers,
Tom

@dmnewbold
Copy link
Collaborator

I have added a new generic SWAP_ORDER to the ctrlreg_v block and its friend syncreg_v. Added to the dev branch for this issue.

@dmnewbold
Copy link
Collaborator

I've also used this branch to fix a recently-discovered race condition in ipbus_syncreg_v. This caused a lock-up condition if a block of syncreg_v stat registers were read too quickly, due to a bug in the read handshake logic.

@alessandrothea
Copy link
Collaborator

Any more work required on this or shall the branch merged back into the master?

@dmnewbold
Copy link
Collaborator

Pull request made.

@dmnewbold
Copy link
Collaborator

dmnewbold commented Mar 1, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants