Closed andrewmkeller closed 4 years ago
Another e-mail from @Blazingmarimba
Actually, it seems like changing how I was doing naming (I was not preserving hierarchical names but am now) fixed the bug that was causing it to produce incorrect edf files. Can you recommend ways to verify that I am flattening correctly? The code is on GitHub so you two can also look over it. It also not really commented right now so that is something that I need to get done. Would it be a better use of my time to comment it or work on code to make each definition instanced only once for this release?
Ways to verify that you are flattening correctly?
Hmm... This is tricky, I think it will become easier as api becomes more developed, but here are some thoughts.
I would suggest that for an example, you do not need to have it fully tested right now. As we migrate the example into the API as a feature instead of an example, we will provide more fully developed tests. What do you guys think about this? Is it cutting too many corners, or is it giving the users an idea of what can be done with this tool?
Would it be a better use of my time to comment it or work on code to make each definition instanced only once for this release?
For examples, highest priority is that it works, second highest is that is commented, third highest is that it works in more situations. I would say that if you have code that works for flattening netlists that have unique definitions, lets get that out there; then lets comment it well, then lets make it work with netlist that have unique instances.
One thought I had on flattening. For edif we can preserve uniqueness of names if we take the highest level hierarchical name for any net that we flatten (in the scenario where we do not use connectors). In structural verilog/VHDL nameless connectors may be the most elegant option.
Email received from @Blazingmarimba