search

bespoke-silicon-group / bsg_manycore

Tile based architecture designed for computing efficiency, scalability and generality
Other
230 stars 58 forks source link

DRAM EVA to NPA hashing changes #349

Open stdavids opened 4 years ago

stdavids commented 4 years ago

Commit (aa446423420533d4e78ed6bcd4a6065fcdca79eb) made the following change to the bsg_manycore_eva_to_npa.v: Before: https://github.com/bespoke-silicon-group/bsg_manycore/blob/10af917bcd151569cfed03b5bd074706da90529f/v/bsg_manycore_eva_to_npa.v#L98 After: https://github.com/bespoke-silicon-group/bsg_manycore/blob/fb9cecf863cb423e11436d2d0146dc30fbb8f978/v/bsg_manycore_eva_to_npa.v#L99

This severely limits the ability to attach a accelerators to the manycore array. I have an accelerator that lives between the manycore and the bottom caches and I can't use hetero socket because the hetero socket interface is extremely limited in its capabilities. It was still very easy to get around that issue with the old dram npa hashing but this commit has made it virtually impossible, is it possible to revert this back to the original having of just going to y-max?

tommydcjung commented 4 years ago

This change was made for crossbar network. and I think the easy solution is to make y_max a parameter with the default value of {y_cord_width_p{1'b1}}.

stdavids commented 4 years ago

That would certainly solve my problem, you can make the default whatever makes the most sense for a majority of the systems using the manycore.

tommydcjung commented 4 years ago

I think nbf.py should also be parameterized to set y-max, which is fine. https://github.com/bespoke-silicon-group/bsg_manycore/blob/master/software/py/nbf.py#L265 @taylor-bsg does having y-max as parameter sound like a reasonable solution?

stdavids commented 4 years ago

I agree the NBF could use this too. My current makefile hacks around this.