RE: [vhdl-200x] VHDL enhancements wish list

I have questions concerning the name of the Z-transform function. When the term Z-transform is used the first thing that comes to my mind is the mathematical definition of performing a Z-transform of a polynomial. Would this have any conflicts with conventions in VHDL-AMS since it has standard definitions that are closer to the pure mathematical definitions? Since the digital portion of VHDL is at the hardware view, would it make more sense to just call it a pipeline delay or something equivalent to help minimize any confusion, even though the Z-transform in hardware is just a tap delay line? Any thoughts?

P.S. is the anonymous identifier that Jim showed in his PipeReg procedure is that a valid VHDL identifier or is it a proposed identifier?

Scott D. Hoy
E-mail: scott.hoy@itt.com<mailto:scott.hoy@itt.com>
Phone: 301-497-9900 Ext. 7162
Fax: 301-497-0207

ITT-AES
141 National Business Pkwy. Suite 200
Annapolis Junction, MD 20701
Phone: 301-497-9900 Fax: 301-497-0207

________________________________
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Thursday, February 24, 2011 2:52 PM
To: vhdl-200x@eda.org
Cc: David Bishop; ryan.w.hinton@L-3com.com
Subject: Re: [vhdl-200x] VHDL enhancements wish list

David,
I'm in favour of having a set of predefined attributes and a nice operator like the one you suggested for pipelining FFs.

I was also thinking about re-using for synthesis, currently available (but not so commonly used) VHDL constructs, especially those that are exclusively used only for simulation, such as the "after" clause, as was also suggested earlier.

Why not we have a mix of these ideas? Such as we could have the behavioural description for the pipelined FFs described thus:
r2 <= r1 after zt 2;

but also preserve all the other default attributes as you suggested.

I agree that with this we would make the code more concise and readable. Also, we maintain the design at a higher level of abstraction - describing this behaviourally is always easier to read than structurally pipelining those FFs.

I noticed something really interesting that Jim brought up. He wrote an interesting procedure that (to me) is highly configurable for describing pipelined FFs. Here again, copied from Jim's post:
Implementation takes something that is not synthesizable right now:
  procedure PipeReg (
    signal Clk : std_logic ;
           ValIn : anonymous ; -- anonymous is another thing I would like
    signal Valout : out ValIn'subtype ;
           Stages : integer := 2
  ) is
    type PipeRegType is array (1 to Stages) of ValIn'subtype ;
    variable PipeReg : PipeRegType ;
  begin
    loop
      wait until Clk = '1' ;
      PipeReg := PipeReg(2 to Stages) & ValIn ;
      ValOut <= PipeReg(1) ;
    end loop ;
  end procedure PipeReg ;

I was still stuck with the old-school way of describing pipelines, i.e. making as many assignments as I deemed fit. With a large number of pipeline stages, I end up having to declare a large number of such signals and making such assignments, which I feel clutters up my design. With this method, I would just need to use this procedure and specify the maximum number of stages I need.

I feel we could somehow use this procedure as a starting point for implementing the Z-transform function/procedure you are proposing. This means getting synthesisers to use this procedure to implement the "after zt" clause.

Regards,
Daniel
On Fri, Feb 25, 2011 at 2:28 AM, David Bishop <dbishop@eda.org<mailto:dbishop@eda.org>> wrote:
On 2/24/2011 12:24 PM, ryan.w.hinton@L-3com.com wrote:
David,

This sounds scary and error-prone to me. With this approach I have to
look all over the declarative regions inside and outside the entity (if
the attribute is specified where the entity is instantiated) to find out
what my clock is!

For most entities, I find that I use one clock and one reset. I would find this short hand useful. I would, however, make sure that the attribute section was just after my Architecture statement.

Should you forget to set these attributes, the Z-Transform with have to error out.

I much prefer a clocked process construct. The definition of this
construct in the LRM should include some way of communicating the clock,
reset, enable, etc. to operators within the process.

You could put the attributes on a single process, but if you went that far, then the old "elsif rising_egde (clk)" would be shorter and easier to understand.

I see this as a way to reduce the size of my code and make it more understandable from an algorithmic point of view.

--
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<http://www.mailscanner.info/>, and is
believed to be clean.
________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.