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

[wb_acq_core] Add multiple "simultaneous" acquisition paths #31

Closed
lerwys opened this issue Jun 26, 2014 · 2 comments
Closed

[wb_acq_core] Add multiple "simultaneous" acquisition paths #31

lerwys opened this issue Jun 26, 2014 · 2 comments

Comments

@lerwys
Copy link
Contributor

lerwys commented Jun 26, 2014

Issue by lerwys
Wednesday Jun 04, 2014 at 19:17 GMT
Originally opened as lerwys/bpm-sw-old-backup#31


There is a need to have multiple acquisition paths acquiring data simultaneous,
in a multiplexed way.

This is the traditional use case for our case, in that 1 AFC handles 2 BPMs signals.
So, at least we must decouple the acquisition paths from the 2 different BPMs

lerwys added a commit that referenced this issue Nov 4, 2014
This will be the basis for fixing the github issue #31.
lerwys added a commit that referenced this issue Nov 5, 2014
This top file is the same as the afc_v3/dbe_bpm_dsp_fmc130m_4ch
with the difference that we use the new wb_acq_core_2_to_1_mux
for simultaneous acquisition of BPM1 and BPM2.

This was suppose to fix github issue #31, but there is a
problem when reading from the PCIe DDR3 memory space
whle still acquiring samples. The PCIe core hangs
when asked to read/write to/from DDR3 and outputs
FF's forever.
@lerwys
Copy link
Contributor Author

lerwys commented Nov 30, 2014

Problem: We need to fix the PCIe core for this to work, as hanging the req line will cause the pcie core to generate timeouts.

Possible solution 1 (software only): On receiving an arbitrary number of continous 0xFF's, detect a PCIe timeout. After this, clear the reset the timeout counter and try again.

Possible solution 2 (FPGA firmware) as suggested by @abyszuk: FPGA PCIe core "client" should periodically withdraw the the access request to allow for possible pending PCIe transactions.

Possible solution 3 (FPGA firmware) as suggested by @abyszuk: Give more meaning to the ui_app_gnt line: if arbiter pulls it low while ui_app_req is high, it's a signal that it wants to withdraw the access permission. In response client should deassert the ui_app_req signal as fast as possible.
Of course it could then assert it back again few clock cycles later and wait for permission.

@lerwys
Copy link
Contributor Author

lerwys commented Jun 23, 2017

Fixed long time ago by using AXI protocol and AXI datamover+interconnect

@lerwys lerwys closed this as completed Jun 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant