On Oct 19, 2010, at 6:49 PM, Martin O'Leary wrote:
> Scott
> Here are my questions on the SystemVerilog reals and UDTs - I am
> hoping that the answers to these will be helpful for the committee
have a common background of relevant SystemVerilog knowledge.
>
> I was unable to send out these questions yesterday so I don't expect
them to be answered before or during tomorrow's SV-DC meeting - however
great if they can be. If not, hope that they can be answered on the
reflector after the tomorrow's meeting.
>
> Thanks,
> --Martin
>
>
>
> 1. I understand that SystemVerilog supports real variables attached to
ports. 1.1 In this case, how is resolution done?
> 1.2 Also is directionality supported on such ports? And if so what are
the semantics for input, inout, output?
A real on a port is a variable, not a net. As with all variable ports,
inout is not allowed but "ref" is allowed. As such there is no
resolution. Variables are allowed to have a unique continuous driver or
as many procedural assignments as desired (but not both continuous and
procedural). Note that in SV (and even earlier in Verilog for output
ports) that it is NOT the case that a port is a net. The "kind" of a
port is distinct from either its type or mode.
>
>
> 2. I understand that SystemVerilog supports structs. Can there be real
fields in these structs?
Yes.
>
>
> 3. Using struct mechanism, what does SystemVerilog support in terms of
> "Aggregate nets with real valued components including constructs such
> as vectors, static arrays, structs, unions" - [Ref R05]
Reals are not a valid net type, either independently or in a composite.
You could have a composite variable port with a real but not a net port.
>
> 4. I understand that SystemVerilog supports struct variables attached
to ports. In this case, how is resolution done?
All composite nets are resolved individually at the bit-level.
Resolution follows the rules imposed by the dominating net in the
connected topology. There is no way to modify or override the bit-wise
resolution.
>
>
> 5. Does SystemVerilog support any form of "type conversion mechanisms
> to enable connection of nets of different, yet compatible, types and
> structures, including connection of aggregate nets" - [Ref R11]
All implicit conversions are permitted but there is no user defined
conversion functions. So, for example, connecting an integer (or any
packed value) to a "real" input port would be legal -- the implicit
integer to real conversion would take place. There are particular rules
for "structural net expressions" on ports which define (effectively) the
collapsed simulation net; connections that are not structural net
expressions can only be unidirectional -- so, for example, using "a+b"
as the actual in a port connection would be fine but would not be a
structural net expression and would not collapse. The directionality of
net ports with structural net expressions is immaterial; as noted above
the entire collapsible connections form one net (at least conceptually).
So though the LRM talks about "port coercion" that is in reality a poor
approximation to the actual behavior of collapsing nets. Note that this
is quite different than for variable ports in which the port mode is in
fact authoritative and no "coercion" takes place.
The above are short versions; there is a lot of interacting detail but
this gives you at least basic answers.
Gord.
>
>
> -----Original Message-----
> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
> Little Scott-B11206
> Sent: Wednesday, October 13, 2010 9:07 AM
> To: sv-dc@eda.org
> Subject: [sv-dc] Questions for the SV-DC meeting on 2010-10-20
>
> Hi all:
>
> In the last meeting it was decided that in our upcoming meeting on
2010-10-20 we would have a presentation regarding wreal from Cadence.
> If there are questions regarding the current capabilities of reals
and/or aggregates within SystemVerilog we would do our best to discuss
those questions.
>
> If you have items you would like to see Cadence cover regarding wreal
or questions regarding the current capabilities or reals and/or
aggregates within SystemVerilog please send them to the list by Monday
evening.
>
> Thanks,
> Scott
>
>
> --
> This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
>
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Oct 19 19:27:09 2010
This archive was generated by hypermail 2.1.8 : Wed Oct 20 2010 - 06:12:11 PDT