Jim: After reading this a few times, I think I figured out what you mean. Please correct me where I'm wrong. 1. Fundamentally you like the idea and don't see any technical issues with the static approach I suggested. 2. You would like to add a facility to globally control the formatting. 3. You would like to add a facility to locally override the global formatting controls. 4. You're also suggesting a new proposal: a writeline override that writes to a log file or to OUTPUT. I think this can be solved with a package to define the writeline override and a protected type to track the log file. So I don't see any language changes necessary here. I guess we could do this for either 'image or implicit to_string. And I suppose if we generalize 'image, we should also generalize 'value. I somewhat favor generalizing both 'image and implicit to_string, mostly because I don't see a reason not to. I suggest we keep the 'image formatting static so that the parsing for 'value remains simple. And to_string already has some formatting options for real and time types, so it's not unreasonable to add formatting options for composite types. Perhaps your local override facility (3) can simply use additional function inputs. Otherwise, I don't particularly need (2) or (3). I might prefer to have a built-in/implicit value-to-string feature and then some good text parsing tools. But I don't object to adding some formatting options to the to_string route. - Ryan -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jim Lewis Sent: Monday, July 21, 2014 1:18 PM To: vhdl-200x@eda.org Subject: Re: [vhdl-200x] Image attribute for array types Hi Ryan, Did you want 'image or an implicit to_string? Either way, I think it is a solvable problem. Now that we have protected types, we could create global configurations for this sort of thing. The global configuration could define a default composite left brace, composite separator, and composite right brace. Each of these can be strings which would allow them to be either the left parenthesis as you suggest "(" or allow them to be simply separated by spaces " ". Beyond global settings, I would like to support a local override. I have not figured out a pattern for this. The issue I run into is that procedures in a package do not currently have a way to see the context of the calling code. I would also like a write (the built-in one) and writeline that do not require the file specification, but instead write to either a common log file if it is opened or otherwise write to OUTPUT. Again, I potentially see this filtered through a global (standard packge based) shared variable object. Cheers, Jim > All: > > Is there any reason not to create a 'image attribute for composite types (arrays and records)? Right now it only exists for scalar types like integer, real, etc. One possible definition is a paren-enclosed, comma-delimited sequence of the element images from left to right (array) or first-to-last defined (record). I believe this would make X'image a valid VHDL aggregate expression representing the current value of X. It's easy to define, unambiguous, and quite general. > > > Example: > > > process images is > variable ary : std_logic_vector(0 to 3) := b"011"; > variable ln : LINE; > begin > write(ln, ary'image); > writeline(OUTPUT, ln); > end process; > -- Will print "('0','1','1')" according to my suggestion. > > > Thanks! > > --- > Ryan Hinton > L-3 Communications / Communication Systems West > ryan.w.hinton@L-3com.com > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis VHDL Training Expert, SynthWorks IEEE 1076 VHDL Working Group Chair Open Source VHDL Verification Methodology (OSVVM), Chief Architect and Co-founder 1-503-320-0782 Jim@SynthWorks.com http://www.SynthWorks.com VHDL Training on leading-edge, best coding practices for hardware design and verification. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 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 Mon Jul 21 12:42:02 2014
This archive was generated by hypermail 2.1.8 : Mon Jul 21 2014 - 12:42:14 PDT