[libre-riscv-dev] nMigen Hierachical Issues

[libre-riscv-dev] nMigen Hierachical Issues

[Yehowshua]

I noticed this a couple days back.

https://github.com/m-labs/nmigen/issues/328 <https://github.com/m-labs/nmigen/issues/328>

Does that affect cookie cutter VLSI layout?

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] nMigen Hierachical Issues

[Luke Kenneth Casson Leighton]

On Friday, May 8, 2020, Yehowshua <yimmanuel3@gatech.edu> wrote:

> I noticed this a couple days back.
>
> https://github.com/m-labs/nmigen/issues/328 <https://github.com/m-labs/
> nmigen/issues/328>


the problem i think is that the WIDTH parameter could potentially radically
alter the submodule.

thus, efforts to "analyse" the submodules and get them to share the same
"include" (if i uderstand him correctly this is what he wants) would need
literally a full AST tree walk to determine if they were identical.

Does that affect cookie cutter VLSI layout?


yes.  pass in different parameters or take in global python state which
produces different AST, we cannot safely expect the instances to be the
same.

if *we* know that the AST is the same, we might take the risk.



the "paranoid" solution is to create external imports.

external imports nmigen is forced to stop at the boundary of the import.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev