https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L194

Return -1 on failure, instead of 0.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_loader.c#L197

This is a general catch all issue - but for example, what does (1 << 13) represent?

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L24

Please fix this issue for all related functions in the library. Assume 0 is 'OK' and anything else is 'FAIL'

(Reference fixed issue in PR to dev that fixes this issue, and only this issue)

We need a function for waiting on kernel completion!

(Thanks to @bornaehsani for catching this!)

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L33

Verify the validity of the manycore handle with an assertion, or macro that returns an error when the handle is invalid.

For a request packet, the destination coordinates are those of the responder and the source coordinates are those of the requester.

https://github.com/bespoke-silicon-group/bsg_f1/blob/3ac04bb5bf85e1214b43089f894064df3be54fb8/cl_manycore/libraries/bsg_manycore_packet.h#L18

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L143

Let's use the new structs in the manycore packet API instead of uint32_t*. This will mean that the packet struct pointer has to be passed as an argument.

All development is happening in the dev-cuda branch with the CUDA-Lite feature tag.

Related Issues:
#39
#40
#41
#42
#43
#55
#56
#54

Let's define a ROM space on the FPGA that we can read configuration data out of. Let's make it big enough that we can add parameters as generations progress, maybe 4KB (fits in a BRAM) and describe a substantial amount of data in.

Off the top of my head:

• A Manycore version ID
• Compilation date?
• Network bit-width
• X/Y Dimensions
• Host Interface Locations
• A pointer to a "description" of the manycore with format TBD.
• BSG IP Cores, BSG Manycore, BSG F1 Commit IDs?

I will gladly entertain other suggestions

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.h

Variables should be defined in the .c source files they are used in to avoid global variables. If a variable is needed in multiple files then we should (probably) have an API for doing so.

https://github.com/bespoke-silicon-group/bsg_f1/blob/6e12e7e6baea1c4b06418b3b924c1681092dde00/cl_manycore/hardware/create_bladerunner_rom.py

The python script should take arguments - hashes, etc. These arguments should have defaults, or be parsed from the verilog files in the same directory.

https://github.com/bespoke-silicon-group/bsg_f1/blob/3be88f28d1a3e84e8f133a226a9a73fbccd53ee6/cl_manycore/hardware/cl_manycore.sv#L174-L216

For example:

logic [2*6-1:0] m_axi4_concat_awid;

should be replaced with

logic [`macro_name*6-1:0] m_axi4_concat_awid;

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L24

Please create a new typedef for int that replaces uint8_t. Use int so that we can return negative values in errors.

hb_mc_device_launch will load the binary on the manycore, transfer the arguments, and cause the kernel to run.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_loader.c#L9

Can it be parsed from the .elf file?

An example is here:

Eventually, when we load the x/y coordinates at runtime we should check that the x/y coordinate is valid and is a vanilla core processor.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_loader.c#L236

https://github.com/bespoke-silicon-group/bsg_f1/blob/7886d81c8568ac09ee6057eb839f5e1a1702d55d/cl_manycore/libraries/bsg_manycore_driver.c#L210

Let's not expose the underlying implementation details - instead, let's say it returns HB_MC_FAIL (which is -1, right?)

The latest Bitstreams have tile groups; the host programs need to be changed to accommodate this.
The Makefile for the host programs defines the Library path - this is not necessary and should be removed.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_print.c

Unless there's a purpose I can't see...

$ ls -lah 
-rwxrwxr-x. 1 dustinar dustinar 1.4K Apr  1 10:48 cosim_rom_test.h

Not urgent - next time we touch the file it would be great if someone can fix this

This test requires an environment variable that points to the binary. This needs to be documented.

https://github.com/bespoke-silicon-group/bsg_f1/blob/eded3a7229dd73c6359fe0997b55588a4accb9b6/cl_manycore/examples/loopback_test.c#L38

The hb_mc_device_init function will:

• Take an eva_id and .elf file as a parameter
• Load the binary
• Initialize a malloc manager object
• Unfreeze the tiles in a tile group.
• Initialize the tiles in a tile group with the specified EVA (future feature)

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_loader.c#L236

I think this is a general catch-all too. Instead of printing a message and returning void, let's return -1 and (if necessary) print to a log file or stderr.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L93

Will it be removed? Is it still useful in some way?

Open question...

https://github.com/bespoke-silicon-group/bsg_f1/blob/fb12112f23e95f51d30ed45c2d9942d08086940a/hdl/bsg_manycore_link_to_2fifo.v#L129-L139

Let's use a struct, defined in some header file or package, instead of concatenating and assigning to an un-structured 128-bit bus.

hb_mc_init_device described in Issue #39 should be combined with hb_mc_init_host into 1 function.

https://github.com/bespoke-silicon-group/bsg_f1/blob/60ca12b947e5a2c341f0765cabec3ac2ad36a3c4/cl_manycore/libraries/bsg_manycore_driver.h#L51

PROJECT=cl_manycore make cosim

https://github.com/bespoke-silicon-group/bsg_f1/blob/b15423845a81f05858d7e4061d47b4707237ff33/cl_manycore/libraries/bsg_manycore_driver.cpp#L44

The mapping should from fd to Memory Manager and not from eva id.

Instead of passing void* and uint32_t let's use a new union, hb_mc_packet_t that encapsulates request/response packets, and uint32_t[4] for sending/receiving raw data.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7886d81c8568ac09ee6057eb839f5e1a1702d55d/cl_manycore/libraries/bsg_manycore_driver.c#L176

https://github.com/bespoke-silicon-group/bsg_f1/blob/7886d81c8568ac09ee6057eb839f5e1a1702d55d/cl_manycore/libraries/bsg_manycore_driver.c#L212

https://github.com/bespoke-silicon-group/bsg_f1/blob/7886d81c8568ac09ee6057eb839f5e1a1702d55d/cl_manycore/libraries/bsg_manycore_driver.c#L232

https://github.com/bespoke-silicon-group/bsg_f1/blob/7886d81c8568ac09ee6057eb839f5e1a1702d55d/cl_manycore/libraries/bsg_manycore_driver.c#L176

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L71

if we need to communicate data to a user we should have an API for doing so. If we need debug information (I think) it should go to a log (if /var/log is writable...) and be enabled by a DEBUG macro

These functions should take an X and return a Y. The NPA to EVA translation may need additional information but isn't critical yet.

The functions should take an EVA ID as an argument, and error on non-host accessible locations (or an unknown EVA).

Open for discussion. This was discussed previously and should be simple with a well-engineered C API (like the one @ashwin-hari is writing 👍 )

Please mark as Nope if the conclusion is that we should not support this.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L22

Instead of using NUM_X or NUM_Y as statically defined macros, read num_x and num_y from each manycore device on library init.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_loader.c#L65-L96

This seems more general than the loader, is it?

If so, please move this into the driver, and use Max's new struct interface. I suggest renaming it to 'format_pkt' or similar

This function should use a response_packet_t array instead. The response_packet_t struct is just a placeholder and should be replaced with an actual structure to make this possible.

https://github.com/bespoke-silicon-group/bsg_f1/blob/3ac04bb5bf85e1214b43089f894064df3be54fb8/cl_manycore/libraries/bsg_manycore_mem.h#L18

This is an example; instead of returning HB_MC_FAIL, the function should return something like HB_MC_INVALID_FIFO.

https://github.com/bespoke-silicon-group/bsg_f1/blob/eded3a7229dd73c6359fe0997b55588a4accb9b6/cl_manycore/libraries/bsg_manycore_driver.c#L181-L184

This is an example; instead of returning HB_MC_FAIL, the function should return something like HB_MC_INVALID_FIFO.

https://github.com/bespoke-silicon-group/bsg_f1/blob/eded3a7229dd73c6359fe0997b55588a4accb9b6/cl_manycore/libraries/bsg_manycore_driver.c#L183

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L167

Let's pass in the struct we want to fill as a pointer.

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.h#L56

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L13

Is it not already? Stale comment?

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L34

Let's not use an extra argument for reg size. Let's define three methods that we can use

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.h#L54

This is a bit vague... But let's create a struct for tracking the state of each manycore device handle.

Off the top of my head, the struct should have:

• A pointer to the device's mmap'd region
• the x/y dimensions
• A lock? (maybe?)

In an effort to make our testing infrastructure more robust and extensible some adjustments need to be made to the tests in cl_manycore. The high-level objective is to remove source code from .h files, make the tests independently runnable, and merge the cosimulation and runtime (f1) tests.

Items:

• Merge tests in cl_manycore/examples into cl_manycore/software and make both runnable in Cosimulation and F1.
• Create .c/.h files for each test with a % target in the cl_manycore/software makefile
• Create a regression target in the cl_manycore/software directory that all the tests in cl_manycore/software and passes/fails depending on their results
• The cosim target in cl_manycore should run all available tests.
• Address #51
• Remove MAIN_LOOPBACK environment variable dependency, instead make a dependency in cosimulation/regression build makefiles
• Parse (or ???) NUM_X and NUM_Y variables during program compilation

In an effort to make MC programs (more?) cross-configuration compatible, we will be moving the host interface to 0,0

The function hb_mc_device_memcopy should:

• Transfer a host-allocated buffer to a device-allocated buffer in EVA-space.
• Take an EVA as an argument (void*?)
• call low-level function to_eva_copy

https://github.com/bespoke-silicon-group/bsg_f1/blob/7feb9a38b0248546ddc5560078afbd0d1cbe5274/cl_manycore/libraries/bsg_manycore_driver.c#L24

Open question - should we make this function inline?

The function hb_mc_device_malloc should:

• Take an EVA ID
• Check for initialization
• Call the malloc manager object
• Take size parameters similar to CudaMalloc
• Return an EVA (a void*?)

The hb_mc_device_finish function should:

• Take an EVA ID
• Deallocate the memory manager for that EVA
• Freeze the tiles (associated with that EVA?)