| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, `flatten` matched the template objects with
the newly created objects solely by their name. Because of this,
it could be confused by code such as:
module bar();
$dff a();
endmodule
module foo();
bar b();
$dff \b.a ();
endmodule
After this commit, `flatten` avoids every possible case of name
collision.
Fixes #2106.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
`flatten` cannot derive modules in most cases because that would just
yield processes, and it does not support `-autoproc`; in practice
`flatten` has to be preceded by a call to `hierarchy`, which makes
deriving unnecessary.
|
| |
|
|
| |
Remove redundant sigmaps.
|
| |
|
|
|
| |
Flattening does not benefit from topologically sorting cells within
a module when processing them.
|
| |
|
|
|
| |
Flatten is non-recursive and doesn't need to keep track of handled
cells.
|
| |
|
|
| |
Flattening always does "non-recursive" mapping.
|
| |
|
|
| |
The `celltypeMap` always maps `x` to `{x}`.
|
| |
|
|
| |
The `design` and `map` designs are always the same when flattening.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
After splitting the passes, some options can never be activated,
and most conditions involving them become dead. Remove them, and also
all of the newly dead code.
|
|
|
Although the two passes started out very similar, they diverged over
time and now have little in common. Moreover, `techmap` is extremely
complex while `flatten` does not have to be, and this complexity
interferes with improving `flatten`.
|
