Conversation
|
Hello @dcmid , Thank you for the pull request. To give you a bit of a history why it was done this way. The reason for mem element to be inside the addrmap, is to be able to add interface, port information. We should just verify with @benoitdenkinger if this change doesn't break the designs he is working with, I think it should not break anything. |
|
Hello @dcmid, Thank you for your contribution. I'll check and test it. The use of memory parent's name was a workaround fix for something I don't remember exactly. This will break our setup for sure, but I agree that your changes make more sense. I'll check again our exact problem, test with your PR and come back to you. |
|
Thank you! |
|
@benoitdenkinger any update on finding the conflict? Is there anything I can do to help? |
|
@dcmid I tried and actually it doesn't break anything for us. I want to try one more thing by the end of the week to try to remember if there was a specific reason for this or if I remembered something wrong. |
This PR removes the assertion blocking the use of multiple memory nodes, allowing uses such as registers and memories in the same addrmap.
A change is also made in
addrmap.h.j2, where memories were assigned the name of their parent class instead of their own names, allowing for the use of multiple mem types in one addrmap. Previously, this resulted in the classes in the generated header having identical names.A test description
regs_and_mem.rdlis added which places multiple registers and memories in the same addrmap. Its generated output is also committed, and a loop is added toexport.pyto support multiple.rdlexamples.