RE: [sv-cc] Another errata for 32 bit wide items ?

First of all, I think it's a very good idea for all
of DPI. The number 32 appears so often in Appendix E
that we ought to lock the definition down to being
a 32-bit type.

Secondly, as I understand it, uint32_t is not a C
standard type, but one that is provided by a set
of system-specific definitions in a separate file.
But (again, as I understand it) when it is provided,
it always represents a 32-bit type. We might want
to allow some room in the standard for systems that
don't happen to have it.

Thirdly, this is not necessarily required for the
PLI header files -- although I think it would be a
good idea. Most of PLI doesn't deal in aggregate
types, so whether an unsigned int has 32, 36, 48,
or 64 bits doesn't make a lot of difference.

But as I understand things at the moment, if someone
put in a proposal to use uint32_t, I'd be inclined to
vote for it.

Regards,
Jim Vellenga

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
  
 

] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] Behalf Of Michael Rohleder
] Sent: Wednesday, October 27, 2004 1:09 PM
] To: sv-cc@eda.org
] Subject: [sv-cc] Another errata for 32 bit wide items ?
]
] Hi all,
]
] triggered by Ralph's proposal I would like to request to file an
] additional errata.
] If you look at this excerpt from his proposal:
]
] typedef unsigned int svBitActual32;
] typedef struct {unsigned int part1; unsigned int part2;}
] svLogicActual32;
]
] it is obvious that it is ASSUMED that 'unsigned int' is a 32
] bit integer
] value. Since we clearly have
] identified that this is not neccessarily the case for all
] platforms/C-compilers/... we might think about
] replacing 'unsigned int' by 'uint32_t' whenever we assume 32 bit wide
] integer values.
]
] As Ralph pointed out that this is general problem, I suggest
] to file a
] new errata stating that we should
] replace 'all references to unsigned int whenever it is assumed that
] unsigned int is 32 bit wide by uint32_t'.
] Alternatively we might borrow one of the PLI specific definitions for
] this task. Ralph pointed out that
] this very likely applies also to E.7.7, and the svBitVec32
] defs, etc. in
] F.1 and 9.1.2.
]
] The idea behind this is that we better don't put in any
] _assumptions_ of
] integer file sizes; instead make
] clear that this is the intended size. To my knowledge uint32_t is
] defined by the C standard as a 32 bit
] wide integer type.
]
] Regards,
] -Michael
]
]
] --
]
] NOTE: The content of this message may contain personal views
] which are not neccessarily the views of Freescale,
] unless specifically stated.
]
] ___________________________________________________
] | |
] _ | Michael Rohleder Tel: +49-89-92103-259 | _
] / )| Freescale Semiconductor Fax: +49-89-92103-680 |( \
] / / | Freescale Halbleiter Deutschland GmbH | \ \
] _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
] (((\ \>|_/ > < \_|</ /)))
] (\\\\ \_/ / mailto:Michael.Rohleder@freescale.com \ \_/ ////)
] \ /_______________________________________________\ /
] \ _/ \_ /
] / / \ \
]
] The information contained in this email has been classified as:
] General Business Information ( )
] Freescale Internal Use Only ( )
] Freescale Confidential Proprietary ( )
]
]
] *** This note may contain Freescale Confidential Proprietary
] or Freescale Internal Use Only Information and is intended to
] be reviewed by only the individual or organization named
] above. If you are not the intended recipient or an authorized
] representative of the intended recipient, you are hereby
] notified that any review, dissemination or copying of this
] email and its attachments, if any, or the information
] contained herein is prohibited. If you have received this
] email in error, please immediately notify the sender by
] return email and delete this email from your system.
] Thank you! ***
]
]
]
]
]
Received on Wed Oct 27 10:46:06 2004