Mike, thanks for the feedback. If your goal is "100% portability", that is unlikely to ever be achieved since that would require a defined algorithm for randomization constraint solutions (which is unlikely to ever happen). There are also, of course, well known places in the scheduling algs where there are implementation dependent behaviors. It is definitely worthwhile to determine where "exact" compatibility is necessary. I definitely agree that the conditions under which $typename(t1) == $typename(t2) holds are crucial and should be part of the LRM. Do you anticipate having situations in which a $display (or similar) of a $typename would be compared between vendors? Gord. Michael Burns wrote: > > A big reason Freescale is moving to SystemVerilog is portability - we > want our code to work across different implementations. Perhaps 100% > exact portability is not likely to be achieved in the near future, but > it should be the goal. > > There are some areas where it's not there (no standard attributes, no > standard coverage database format); however, this looks like one that > could affect simulation semantics if people are checking the type name. > > --Mike Burns > > Gordon Vreugdenhil wrote: > >> >> In terms of $typename, what are the user expectations? Do users >> intend/expect to have $typename produce identical strings >> across implementations? If not, that might make the specification >> somewhat easier since only the semantic decisions need to be >> addressed. If users expect $typename to yield identical strings >> on every implementation, the bar is considerably higher since >> format decisions would also need to be made precise. >> >> User feedback on this would be very helpful. I've cc'd this >> to EC as well (EC only people - see the issues raised in >> Mantis 1511 to see the context for this question). >> >> >> Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Thu Jun 22 14:15:32 2006
This archive was generated by hypermail 2.1.8 : Thu Jun 22 2006 - 14:16:42 PDT