Feldman, Yulik wrote: > Yes, you're right. Maybe the example would be more persuading if I would > use a typedef: > > typedef logic base_type [3:1]; > base_type a [4:1]; > base_type b; > logic c; > assign b = a[3]; > assign c = b[i]; > > Anyway, probably this example by itself is not a strong enough argument > for not normalizing the types. Perhaps the other argument I mentioned, > to keep selects with more than one selection, like a[3][1], unambiguous > and similar in semantics with expressions like (a[3])[i], is a stronger > argument. > > Another reason to keep the original type, is that if the type is > normalized, you're practically introducing a new type to the model. For > a software tool that means it should keep another object in memory, for > example. Yulik, You are making a rather deep assumption here. In my experience with work on multiple simulator implementations, the opposite is in fact true. It is more efficient on several fronts to assume normalization everywhere. This has been Ok to do in Verilog and implementations assume various aspects of a normalized model in fairly deep ways. For those reasons, I will continue to have serious reservations about this direction. There may be some cases in which it is reasonable to require more specific type information. Steven has raised some of those. But requiring fully accurate information in various places is a mine field and is a position for which you'll almost certainly find substantial opposition. Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Oct 18 07:05:05 2007
This archive was generated by hypermail 2.1.8 : Thu Oct 18 2007 - 07:05:26 PDT