Re: [vhdl-200x] Request for Input

From: Daniel Kho <daniel.kho@gmail.com>
Date: Fri Dec 31 2010 - 00:05:04 PST

Hi Ben,
*I don't believe that the community would buy the idea of a function (or
something like it) that returns a module since it is equivalent to a module
instantiation. *
Probably. But I am in the view that we perhaps do not need to "instantiate"
the whole module, rather some processes in the module will be converted to
logic, while the other processes will not be synthesized.
A function could trigger a process within a module, that's the idea. So only
that process gets synthesized to logic.

Well, I'm open to other suggestions too, including the use of macros. Are
they similar to synthesis pragmas in VHDL?

Regards,
Daniel
On Fri, Dec 31, 2010 at 3:46 PM, ben cohen <hdlcohen@gmail.com> wrote:

> Hi Daniel,
> * Currently, writing the equation is already possible for most synthesis
> tools, however, the tool will select the divider and power-of-two functions
> from its own predefined library, and sometimes there is a need to optimize
> these functions by writing (or overloading) your own. This is where my
> suggestion of having a function link to a process (a process is similar to
> an "always" block in SV) of an entity/module comes in.*
> The fact that the language supports equations with multiplications and
> divisions, along with function calls that return a single value) means that
> it expresses the desired functionality for what you are addressing. Also,
> as you said, synthesis tools support such features with the use of libraries
> that need to be tuned -- that reality. I don't believe that the community
> would buy the idea of a function (or something like it) that returns a
> module since it is equivalent to a module instantiation.
>
> One could reduce the typing (in SystemVerilog) with
> macro definitions ('define). Maybe something like that could be added (but I
> see that as a low priority item). It takes one vote to kill a proposal.
> Besides, there are so many more important things that need to be fixed or
> improved in VHDL, that this proposal is too far from the tasks at hand.
>
> BTW, I am very familiar with VHDL as I wrote 6 books on the subject, plus
> one on PSL that uses VHDL.
> Ben Cohen SystemVerilog.us
>
> On Thu, Dec 30, 2010 at 11:24 PM, Daniel Kho <daniel.kho@gmail.com>wrote:
>
>> Hi Ben,
>> In our case here, though we have the module instantiation concept (or
>> entity instantiation) in VHDL and Verilog, there are limitations such as
>> what I've mentioned in my earlier email. For example, we have to declare
>> separate modules (or entities) and connect them structurally, when it is
>> much easier if we create a function and write the DSP equation as an
>> equation.
>>
>> For the example earlier, writing out *z <= x**2 / y;* is much easier than
>> instantiating separate modules/entities for a divider and a power-of-two and
>> connecting all the signals together as a structural description. Currently,
>> writing the equation is already possible for most synthesis tools, however,
>> the tool will select the divider and power-of-two functions from its own
>> predefined library, and sometimes there is a need to optimize these
>> functions by writing (or overloading) your own. This is where my suggestion
>> of having a function link to a process (a process is similar to an "always"
>> block in SV) of an entity/module comes in.
>>
>> Sorry I'm not too familiar with SystemVerilog. Anyway, I believe the ##
>> notation in SV is probably similar to the "after" clause in VHDL? We can
>> specify delays using the "after" clause, though this is usually ignored by
>> synthesis tools, as delays with specific timing are non-synthesizable.
>>
>> Regards,
>> Daniel
>>
>> On Fri, Dec 31, 2010 at 2:57 PM, ben cohen <hdlcohen@gmail.com> wrote:
>>
>>> Daniel,
>>> *z <= x**2 / y; --where "/" is an internal function (I think it's in
>>> the std library - not too sure)
>>> *
>>> *instead of writing:*
>>> *q<=x**2;*
>>> *divider0: entity work.div32(rtl) port map(a=>q, b=>y, res=>z,
>>> remainder=>remainder);*
>>> Behavioral synthesis would accept "z <= x**2 / y;"
>>> To have a function return an instantiation is not a good idea since we
>>> have in both VHDL and SystemVerilog the module instantiation concept.
>>>
>>> I never used behavioral synthesis; however, below is a SystemVerilog
>>> model where the assignment to z occurs after 10 clock cycles if "go" is
>>> enabled. The ## is a clock cycle delay.
>>> I am not necessarily suggesting this for VHDL. I am just showing how
>>> SystemVerilog can handle in clock delays using a notation.
>>> Of course, there are other ways to express this delay.
>>> module f;
>>> int x, y, z;
>>> logic clk, clk_dsp, go;
>>>
>>> default clocking default_clk @ (posedge clk_dsp); endclocking
>>>
>>> always @ (posedge clk)
>>> if(go) ##10 z <= x**2 / y;
>>>
>>> endmodule : f
>>>
>>>
>>> On Thu, Dec 30, 2010 at 10:12 PM, Daniel Kho <daniel.kho@gmail.com>wrote:
>>>
>>>> Hi all,
>>>> There have been some discussions and suggestions (here and in separate
>>>> email threads - such as "Strong Timing" as first suggested by Jonathan, as
>>>> well as OO and others) on the next revision of VHDL.
>>>>
>>>> I decided (finally) to ask a few questions to the reflector. These could
>>>> appear as suggestions or "request for suggestions" and may stir up some
>>>> inspiration from the SG on new ideas for the next revision.
>>>>
>>>> I have found it troublesome to do certain things in HDL-based digital
>>>> design. I believe these apply to both VHDL and SystemVerilog.
>>>>
>>>> First, on VHDL "functions". All functions synthesize to regular
>>>> (combinatorial) logic (muxes, gates) and never to clocked/registered logic.
>>>> Meanwhile, if you were to design a clocked circuit, you will most definitely
>>>> need to use "processes", or alternately, concurrent statements sensitive to
>>>> a clock signal.
>>>>
>>>> I find it really troublesome to have to describe a simple algorithmic
>>>> (or DSP) design as separate "entities" and connect those entities
>>>> "structurally" as a synchronous circuit. For example, say I need to use a
>>>> divider for my current design. If I want a clocked arithmetic divider (I
>>>> would want this since it uses much less logic resources, and I can afford
>>>> many clock cycles for the computation), I would have to describe it
>>>> separately as another entity (say we name it "div32") with a clocked process
>>>> in its architecture. I would then have to connect that div32 block to my
>>>> design structurally, i.e. using port maps to internal signals in my design.
>>>> Writing the process into the top-level design works too, but this
>>>> unnecessarily makes the top-level design larger, and look less modular and
>>>> more complex.
>>>>
>>>> I would really like to stick to the "function" way of describing this,
>>>> as it is much less verbose, though I would also like to have a way for
>>>> functions to be able to be clocked. So, in my design, I can just stick to
>>>> something like:
>>>> z <= x**2 / y; --where "/" is an internal function (I think it's in
>>>> the std library - not too sure)
>>>> instead of writing:
>>>> q<=x**2;
>>>> divider0: entity work.div32(rtl) port map(a=>q, b=>y, res=>z,
>>>> remainder=>remainder);
>>>>
>>>> and creating a separate entity to perform the division.
>>>>
>>>> Perhaps we can think of a way for functions to access clocked processes?
>>>> Or maybe a link between a function and an entity-architecture? Something
>>>> like accessing an entity's process from within a function, like below?
>>>> function "/"({parameter_list})
>>>> begin
>>>> return entityName.architectureName.processName({parameter_list});
>>>> end function "/";
>>>> where parameter_list is just the inputs to the process (no outputs in
>>>> parameter_list), and the output (or return value) of the process is
>>>> automatically mapped to the function caller. This would mean that by
>>>> specifying it this way, we allow the process to drive only a single output
>>>> (since the function has only a single return value):
>>>> z <= a / b;
>>>> In this case, "a" and "b" are both inputs to the function (and the
>>>> process), and the process is checked to have only a single output, which is
>>>> mapped to "z".
>>>> I'm not too sure, hopefully we can brainstorm more ideas.
>>>>
>>>> Another thing I found troublesome was type conversions or type casting.
>>>> Also, that certain library functions only support a limited set of types.
>>>> One example mentioned earlier was in the use of literals. The following
>>>> statement is invalid (not supported) at the moment:
>>>> signal a:integer:=x"1a2b";
>>>>
>>>> though ironically this is supported:
>>>> signal a:integer:=16#1a2b#;
>>>>
>>>> Also, one example regarding certain library functions only supporting a
>>>> limited set of datatypes is the arithmetic shift operations: sra, sla.
>>>> The arithmetic shifts only support the bit_vector type, and doesn't
>>>> support std_logic_vector or unsigned/signed. And up till now, since I
>>>> haven't been using a lot of bit_vectors, I am still in the dark on how to
>>>> convert bit_vectors to say, std_logic_vectors?
>>>>
>>>> Comments and ideas, anyone?
>>>>
>>>> Regards,
>>>> Daniel Kho
>>>> On Tue, Dec 21, 2010 at 12:58 AM, Evan Lavelle <
>>>> eml-vhdl-200x@cyconix.com> wrote:
>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> --
>>>>> 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 message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Dec 31 00:06:27 2010

This archive was generated by hypermail 2.1.8 : Fri Dec 31 2010 - 00:06:54 PST