**************************************************************************** *** VHDL Users' Group DIGEST: Volume 1, No. 2 Sep - Oct 1989 *** **************************************************************************** Msg # 1 Dated 09-05-89 16:17:28 From: JOHN WILLNER To: ALL Re: EIA.MEETINGS The VHDL Model Standards Committee of the EIA will meet September 12th from 9 to 5 at the Wyndham Bristol Hotel, 2430 Pennsylvania Ave. N.W. in Washington,D.C. The principal item on the agenda is the review of ballot results & recommendations derived therefrom. The EIA's preliminary VHDL package containing definitions of the logic states necesssary for building behavioral models of commercial components will be issued from review. The VHDL Cooperative Project Committee of the EIA will meet September 13th from 9 to 5 at the Wyndham Bristol Hotel, 2430 Pennsylvania Ave. N.W. in Washington,D.C. The main bujsiness actions will be to review model priorities & model development bids, to discuss a recommended solution with DoD for the data rights issue and to seek monetary commitments for model development and validation. Management level representatives with corporate level contacts should attend. John Willner Msg # 2 Dated 09-06-89 01:58:40 From: GUY JACKSON To: ALL Re: HI FROM QUADTREE Hi! I wanted to be the first to logon to this BBS but Mr. Willner beat me to it! Anyhow... As an introduction, I am the customer support engineer for the Quadtree Software Corporation. If you don't know of us, we make component behavioral models for simulation. We presently have various component models for such simulators as Mentor's Quicksim, HHB's CADAT, Verilog, etc. and are converting our present library of parts to VHDL. At the present time, we support Viewlogic VHDL, Zycad/Endot VHDL, Intermetrics and Vantage with others in the works. Additionally, we have developed (in cooperation with Hughes Aircraft Company) the VTIME(tm) Timing Module Generator Tool which will generate a timing and simulator options flags packages along with the entity and architecture shells for a model. For more info- rmation, contact me (Guy Jackson) with a message here or through the EIA. In parting, we definitely should have some sub-boards on topics such as WAVES, CALS, EIS, etc. and while not directly related to VHDL, I'd like to start some discussions on the little-lost standard -- IEEE 91! I'll try to log on at least once a week and I'd like to agree on some standard conferencing times. Bye for now. GJJ Msg # 8 Dated 09-10-89 22:45:32 From: SYSOP To: ALL Re: DISCUSSIONS ON LINE Now that we have a number of users signed up and logging on, lets increase the active discussion. A favorite topic of mine is enhancements desired in the IEEE 1076 VHDL standard. For example, most every one knows that the standard explicitely does not provide for conversion between the STANDARD package types BIT_VECTOR and INTEGER. This has always been justified because of the many representations used by various hosts (one's complement, two's complement, BCD, etc.). Well, for those who try and use VHDL as an ISA/RTL language, all objects are bit fields (i.e. BIT_VECTOR). But, to index any BIT_VECTOR or register bank (i.e. array type) one must have an INTEGER. Therefore, one must somehow have the BIT_VECTOR type converted to an integer type for every array index operation. This is painful to program. Either we need to define a pre-defined BIT_VECTOR to INTEGER conversion -- how about unsigned string of bits interpretation -- which is implicit in array index operations or, like the resolution functions, allow a user to define such a function which will be invoked implicitely. Any comments on this one or others? randolph harr Msg # 15 Dated 09-20-89 10:45:26 From: SYSOP To: ALL Re: BIT_VECTOR TO INTEGER (For those responding, please do not use [RE]spond as this sends a private message to me only which no one else can read. I have not figured out how to include a previous message in a current message.) John Winkler responded to my initial comments about conversion from Bit Vectors to Integers. His response boiled down to one of being able to override the implicit conversion that might be set up. I think this can be engineered properly using constructs of VHDL. First, one could pre-define all the standard conversions needed: signed vector to signed integer, unsigned vector to unsigned integer, two's complement vector to integer, and one's complement to integer. Let us give them names of svtoi, uvtoi, tvtoi, and ovtoi for convenience. The predefined conversion for bit_vector to integer could be given a unique name such as "vtoi" and (important) be defined as a prefix, single parameter operator. This conversion operator could be implicit anywhere a bit_vector type actual is located where an integer is required. The default could be that "vtoi" maps to "uvtoi", for example. If anyone wants it different in a specific case, they should use an explicit conversion. If you want to change the default, overload the pre-defined operator with your own conversion function in any declarative region desired. Unless I am missing some more basic point of VHDL, this should solve the problems John was worried about. Msg # 16 Dated 09-20-89 10:58:02 From: SYSOP To: ALL Re: RESOLUTION FUNCTIONS I had not been fully aware of many of the problems that the VHDL resolution function introduces until discussing the in-depth details with Alec Stanculescu. But it is now apparent that the original intent and use of resolution functions in commercial HDL's and simulators has been muddled. In an apparent effort to give generality to the functions they have picked up unwanted characteristics which have no design or hardware counter part. Therefore, unless the resolution function and resolved port / signal objects are used in a restrictive manner, one can get very unexpected results. In fact, one can easily create a model which executes differently on differnt simulators (or maybe even the same simulator). Resolution functions originally were meant to take care of design netlists which were created with a physical implementation in mind. In most modeling systems, interconnect has NO behavior other than to cause information and events to transfer from one black box to another. In order to mimic actual chips "interconnected" on a board, wired outputs have to be handled as a network behavior. Therefore, most simulators with there pre-defined types, allowed "wired" resolution functions on special nets. These functions were applied to the flattenned simulation model and were pre-defined and well behaved. Much care must be taken in creating resolution functions and using resolved types to maintain these characteristics -- especially in the environment of VHDL which applies the resolution functions hierarchically. If the restrictions are imposed, a user need not worry about the hierarchical versus flattenned application of the function nor the generality allowed. Initial sets of properties proposed are: permutability of the inputs to the function, Alec's term "reflexitivity" of the function, and what I will call non-mutually-exclusive subsets. (cont. next message) Msg # 17 Dated 09-20-89 11:25:38 From: SYSOP To: ALL Re: RESOLUTION (CONT) Permutability of inputs requires that the function not be sensitive to the order with which signals are in the list. That is, no matter what order the values are put in the list, the same output will occur. This prevents a function which says "the fifth value will always override all others". Reflexitivity basically states that what you put in is what you get out when zero or one signal values are used to call the function. This prevents, for example, a single value of '1' being fed in and a value of '0' (i.e. different than '1') coming out. Finally, the last one kind of includes the first two. It states that for a flattenned signal net (all conversions applied), that the effective value output from the final resolution function is the same no matter whether all driving values are input to a single call of the resolution function nor whether sub-groups of the values are created, put through the resolution function, and the output of the function fed in as a value replacing the previously resolved values. This property basically states that the final resolved signal output should be the same no matter how the signals are grouped and fed through the resolution function recursively (hierarchically, or whatever). Does anyone have any ideas on this? Maybe how to represent the idea more formally or more concisely? Msg # 22 Dated 10-02-89 12:18:27 From: SYSOP To: ALL Re: FILES SUBSYSTEM A snapshot of the entire contents of the Files subsystem (i.e. downloadable files) will be taken on Friday. The snapshot will be reproduced onto a floppy and distributed with the notebooks at the June meeting. If you know of other information that would be useful to others, please upload it by Friday. If you think there is incorrect of inaccurate information on the board, correct it or let me know. The University of Cincinnati repository information should be on this BBS by Friday in time for the snapshot. The BBS machine will be moved to Redondo Beach for the week of the 22nd October. This is being done to advertise the service at the meeting. A copy of the machine and software will remain on this phone line but will not accept new USER registrations or MESSAGES. File uploads and downloads of already registered users will still be enabled. Sorry for the inconvenience. This is a onetime occurence to help improve the BBS use and support. Msg # 31 Dated 10-14-89 15:19:43 From: SYSOP To: ALL Re: ARMSTRONG FILES To those of you who are still looking for the individual Jim Armstrong files; they were all concatenated together into a single file named Armstron.v. Because there were 20 files, each only 500 to 3000 bytes, I felt it better to bunch them together. If you have a PC, download the armstron.arc file which, when un-arced will give you the individual files. Otherwise, download amrstron.v and use your favorite text editor to separate them. This should be more convenient than trying to correctly type the name of twenty (nineteen?) files for download! Msg # 32 Dated 10-18-89 16:35:33 From: SYSOP To: ALL Re: FALL 1989 MEETING Our little mishap here has not affected the planning for next weeks meeting. We will still plan to see you all there. Thank you for your calls of concern. Your local Red Cross will be glad to receive any assistance you may wish to offer. See you next week in Redondo Beach! Randy **** END OF DIGEST