POETSII / tinsel

Manythread RISC-V overlay for FPGA clusters
Other
35 stars 1 forks source link

Manage provisioning and execution of a core by full address #77

Closed mvousden closed 4 years ago

mvousden commented 5 years ago

Edit: I found HostLink::fromAddr, which makes this somewhat redundant. Apologies, feel free to close.

In HostLink, In a post-Orchestrator-hardware-model world, it would be useful to manipulate cores using their full address as opposed to their address components.

Currently, the following exist:

loadInstrsOntoCore(const char* codeFilename, uint32_t meshX, uint32_t meshY, uint32_t coreId)
loadDataViaCore(const char* dataFilename, uint32_t meshX, uint32_t meshY, uint32_t coreId)
startOne(uint32_t meshX, uint32_t meshY, uint32_t coreId, uint32_t numThreads)
goOne(uint32_t meshX, uint32_t meshY, uint32_t coreId)

these methods only use meshX, meshY, and coreId to reconstitute a hardware address, and perform some operations with that address.

I am suggesting the following overloads:

loadInstrsOntoCore(const char* codeFilename, uint32_t address)
loadDataViaCore(const char* dataFilename, uint32_t address)
startOne(uint32_t address, uint32_t numThreads)
goOne(uint32_t address)

This way, the Mothership (and the Orchestrator) do not need to hold meshX and meshY data beyond the hardware model parser.

I'm happy to make this change if someone else thinks this is a reasonable thing to do.

mn416 commented 4 years ago

Hi Marks, sounds like you found a workaround, so I'll close this for now. Feel free to reopen...

mvousden commented 4 years ago

Yes, this is not necessary any more (there are methods to transition from address to meshx, meshy, etc.).