Re: [vhdl-200x] Request for Input

From: Daniel Kho <>
Date: Thu Dec 30 2010 - 23:24:45 PST

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.


On Fri, Dec 31, 2010 at 2:57 PM, ben cohen <> 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 <> 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 <
>>> 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* <>, 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 Thu Dec 30 23:25:46 2010

This archive was generated by hypermail 2.1.8 : Thu Dec 30 2010 - 23:26:24 PST