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> 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, and is
believed to be clean.