{"action":"created","issue":{"url":"https://api.github.com/repos/freechipsproject/firrtl/issues/674","repository_url":"https://api.github.com/repos/freechipsproject/firrtl","labels_url":"https://api.github.com/repos/freechipsproject/firrtl/issues/674/labels{/name}","comments_url":"https://api.github.com/repos/freechipsproject/firrtl/issues/674/comments","events_url":"https://api.github.com/repos/freechipsproject/firrtl/issues/674/events","html_url":"https://github.com/freechipsproject/firrtl/issues/674","id":262165106,"number":674,"title":"[question] Clarification on Guarantees for High/Mid/Low FIRRTL","user":{"login":"seldridge","id":1018530,"avatar_url":"https://avatars0.githubusercontent.com/u/1018530?v=4","gravatar_id":"","url":"https://api.github.com/users/seldridge","html_url":"https://github.com/seldridge","followers_url":"https://api.github.com/users/seldridge/followers","following_url":"https://api.github.com/users/seldridge/following{/other_user}","gists_url":"https://api.github.com/users/seldridge/gists{/gist_id}","starred_url":"https://api.github.com/users/seldridge/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/seldridge/subscriptions","organizations_url":"https://api.github.com/users/seldridge/orgs","repos_url":"https://api.github.com/users/seldridge/repos","events_url":"https://api.github.com/users/seldridge/events{/privacy}","received_events_url":"https://api.github.com/users/seldridge/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2017-10-02T17:40:09Z","updated_at":"2017-10-04T23:45:25Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I had an odd realization in that FIRRTL levels below High do not respect last connect semantics. The `ExpandWhens` transform is expected to clean this up for you.\r\n\r\nA result of this is that transforms that add new statements (that are not \"in place\" modifications of existing statements) should either take place at the High FIRRTL level or emit High FIRRTL so that the circuit will be cleaned up for you.\r\n\r\n__Are there any existing clarifications of what guarantees are expected for specific transforms at specific FIRRTL levels?__\r\n* Technically these guarantees can be gleaned by reading the `LoweringCompilers` code...\r\n\r\nWhat I've discovered:\r\n  * `circuits <= Mid FIRRTL` do not obey last connect semantics (cleand up by `ExpandWhens`)\r\n  * `circuits == Mid FIRRTL` provide no guarantees that signal names will not alias to each other (cleaned up by `Uniquify`), e.g., adding the signal `wire r_x: UInt<5>` to a module with existing signal `wire r : {x: UInt<5>}` will result in a hidden name conflict\r\n\r\nThese may be bugs or they may be a violation of the `[High, Mid, Low]` FIRRTL contract.\r\n\r\nAlternatively, this may motivate a new `CheckMidForm` pass (to save me from myself...).\r\n\r\n__Edit:__ After digging a bit more, this _is_ some documentation of this in the code: [`Compilers.scala`](https://github.com/freechipsproject/firrtl/blob/master/src/main/scala/firrtl/Compiler.scala#L138). I think that the restrictions are stricter, nonetheless."},"comment":{"url":"https://api.github.com/repos/freechipsproject/firrtl/issues/comments/334320638","html_url":"https://github.com/freechipsproject/firrtl/issues/674#issuecomment-334320638","issue_url":"https://api.github.com/repos/freechipsproject/firrtl/issues/674","id":334320638,"user":{"login":"jackkoenig","id":8584418,"avatar_url":"https://avatars3.githubusercontent.com/u/8584418?v=4","gravatar_id":"","url":"https://api.github.com/users/jackkoenig","html_url":"https://github.com/jackkoenig","followers_url":"https://api.github.com/users/jackkoenig/followers","following_url":"https://api.github.com/users/jackkoenig/following{/other_user}","gists_url":"https://api.github.com/users/jackkoenig/gists{/gist_id}","starred_url":"https://api.github.com/users/jackkoenig/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jackkoenig/subscriptions","organizations_url":"https://api.github.com/users/jackkoenig/orgs","repos_url":"https://api.github.com/users/jackkoenig/repos","events_url":"https://api.github.com/users/jackkoenig/events{/privacy}","received_events_url":"https://api.github.com/users/jackkoenig/received_events","type":"User","site_admin":false},"created_at":"2017-10-04T23:45:25Z","updated_at":"2017-10-04T23:45:25Z","author_association":"CONTRIBUTOR","body":"@seldridge I agree with you're interpretation that signals that would conflict via flattening *are different signals*, but clearly the compiler is just not really enforcing this at the moment. We either, need to run Uniquification as part of the MiddleToLow transform or we need to error if a collision would occur. My opinion is that we should do the former, ie. run uniquification during middle to low.\r\n\r\nFor the time being, you should run uniquification, but @azidar we should make this unnecessary."}}
{"actor":{"display_login":"jackkoenig"}}