Support CoreMgmt over DRTIO on Zynq Devices #323
No reviewers
Labels
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: M-Labs/artiq-zynq#323
Loading…
Reference in New Issue
No description provided.
Delete Branch "occheung/artiq-zynq:drtio-coremgmt"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The corresponding Kasli-SoC PR for ARTIQ PR.
Main differences to the ARTIQ PR
config write
Similar issues experienced on RISC-V devices can be expected here.
@ -232,1 +870,3 @@
pub fn start(cfg: Config) {
pub fn start(
cfg: Config,
drtio_tuple: Option<(
Slightly related: I like the tuple to keep the argument list shorter/more compartmentalized, should we adapt it in other places too?
Agreed that a a lot of argument lists are needlessly long. Especially with the shared sync primitives theres a lot of repetition. Though I'm not sure that these tuples make things much shorter, without some type aliasing. Is there a case for putting these shared sync prims in a struct and passing around an
Rc
to that instead? (In a similar style to how the mainline repo passes aroundIo
)Putting the idea out there, obviously it would be a heavy refactor...
@ -115,0 +837,4 @@
stream: &mut TcpStream,
pull_id: Rc<RefCell<u32>>,
cfg: Rc<Config>,
_drtio_tuple: Option<(&Rc<Mutex<bool>>, &RoutingTable, GlobalTimer)>,
Isn't that just an idiosyncratic object? Canonical way would be to define a
struct
.fbb20bc723
to93e25169fb
WIP: Support CoreMgmt over DRTIO on Zynq Devicesto Support CoreMgmt over DRTIO on Zynq DevicesStep 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Gitea.