HammerBlade Manycore Accelerator

[sripathi-muralitharan]

This PR adds the HammerBlade Manycore as an accelerator to Dromajo. This mimics the BlackParrot<-->HammerBlade hardware bridge in software.

[dpetrisko]

It doesn't seem like there's anything special about having different fifo types? Why not just have fifo_ids? That way we can expand this to more fifos in the future similar to the zynq-parrot setup

[sripathi-muralitharan]

I just kept it this way to make it easier to understand and mirror what we have in the manycore repository. Question is will we even need to expand to more FIFOs for the manycore? Or do you wanna make this setup more generic to handle other accelerators as well?

[sripathi-muralitharan]

Either ways the types are part of an enum and so effectively they are IDs :)

[dpetrisko]

I want to make it more generic to handle other accelerators. But yeah exactly it seems like there are two tags which do the exact same thing (the enum and the id)

[dpetrisko]

And in the manycore, here's a really simple use-case: multicore dromajo will require 3*N fifos. Could instantiate dromajo twice but not sure if that'll have a problem

[sripathi-muralitharan]

For the manycore: Isn't it more accurate to have > 1 Dromajo if we wanna emulate the multicore case?

For this PR: I guess you understand that the intention was to have a main type/ID which is the enum and each of the 32-bit FIFOs are identified by IDs. So what is the action item here? Should I just get rid of the 32-bit FIFO IDs and keep only the enum? So, writing to the FIFOs will look like - *addr = val. There could be a counter in the background that indicates which 32-bit FIFO the value goes to.

[dpetrisko]

For the manycore: Isn't it more accurate to have > 1 Dromajo if we wanna emulate the multicore case?

No, dromajo is capable of multicore simulation. In fact, it is necessary to use multicore dromajo rather than several instances of single core dromajo to enable coherent memory between them

I would pass fifo pointers to each function that acts on them

[sripathi-muralitharan]

FIFO pointers are passed in the internal helper functions used to perform the actual function. The API functions are wrappers and require only a type to perform the function. The appropriate FIFO is chosen based on the switch..case statement.

[dpetrisko]

How is this used? Primarily we should be querying credits, not emptiness

[sripathi-muralitharan]

I use the empty function to check is there are packets to transmit. It is also used on the receiving FIFOs if there are any entries. Credits is a different mechanism altogether. The overarching fifo struct has a field to maintain credits that gets updated by the x86 code after every packet transmission.

[dpetrisko]

Okay, so this is read by the manycore_simulator, not the software ever?

[sripathi-muralitharan]

The software never uses this function directly. It doesn't even know this function exists. This exists only for Dromajo to know how to handle the device. And strictly speaking not even the simulator uses this particular function. The simulator uses the mc_get_fifo_empty function which calls this function internally.

To be exact this is what happens under different cases -->
Software loads from the FIFO address --> mc_fifo_read is called on the correct FIFO
Software stores to the FIFO address --> mc_fifo_write is called on the correct FIFO
Software wants to know the number of credits used --> mc_fifo_get_credits is called on the FIFO (prints a warning message if this function is triggerred)
Software wants to check the if entries present in the FIFO --> mc_is_fifo_empty called on the correct FIFO (The function is generic but always the software checks for emptiness of the manycore request/response FIFOs and the simulator checks the emptiness of the host request FIFO)

[sripathi-muralitharan]

@dpetrisko any other review comments?

[dpetrisko]

is this assuming some particular addressing scheme?

[sripathi-muralitharan]

Yes, the addressing scheme is defined here - https://github.com/sripathi-muralitharan/dromajo/blob/f198a4272c633795fbebd01dac4991cc3c32e252/include/riscv_machine.h#L139-L148. I can add a comment pointing to this file for future reference, when adding comments for the other functions in this file.

[sripathi-muralitharan]

@dpetrisko any more review comments?