On 1 May 2007, at 11:15:09 AM, Stephen Williams wrote:
This is a bit too glib for my tastes. Parameters, parameter overrides
and constraints on parameters were thoroughly debated during the
standardization process, so I don't think it's quite fair for you
to assume you know so much more (or are so much smarter then) the
people who were there.
You are right.
I have a proclivity for biting (or unnecessarily incendiary)
generalities,
and my lack of credentials tends to render them futile anyhow.
I'll try to minimize those in the future.
In any case, I suppose I directed my "wrath" at the wrong subject.
I still maintain that Verilog *seems* to have many constraints that
have arisen solely for the purpose of easing tool development
rather than logic design.
In this case, they did a reasonable job of keeping the problem
under control. The cycles that remain can be detected by simple
graph algorithms, are localized, and are easy to point out to a
user. Currently, even though dependencies can span heirarchy, the
cycles are guaranteed to be localized within a module instance.
If cycles were allowed to span heirarchy up and down then you
can have the impossible situation of cycles wrapped all around
your design. Add generates to that and you can have an unstable,
non-repeating "cycle".
I'll betray my naivety by requesting more explicit examples.
What exactly do you mean by "localized within a module instance"?
As I see it now, cycles are not possible unless maybe through
some mechanism like generate, but all such cycles, including
the more general ones possible with my suggestion seem
quite avoidable and easily detected unless we have a
"dormant" generate branch that is necessarily poorly written.
As you can tell, I've thought about this some by now, and I now
think it would indeed be a bad feature:-P
I'll admit, my thoughts have been less thorough.
However, two can play at this game!
===> :-P
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
