Re: [myhdl-list] Incorrect conclusions in TSConIT paper

[Christopher F. <chr...@gm...>]

On 7/3/12 5:26 AM, Norbo wrote:
> Am 01.07.2012, 03:47 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
>> On 6/30/12 2:11 PM, Norbo wrote:
>>> def firfilt(sig_in, sig_out, coef, clk):
>>>             bufferVal = [Signal(intbv(0, min=sig_in.min, max=sig_in.max))
>>> for ii in range(len(coef))]
>>>             coefs = [Signal(intbv(ii, min=min(coef), max=max(coef)+1))
>>> for
>>> ii in coef]
>>>             mshift = len(sig_in)-1
>>>             @always(clk.posedge)
>>>             def hdl_sop():
>>>               sop = (bufferVal[0] * coefs[0])
>>>               # Note this adds an extra delay! (Group delay N/2+2)
>>>               bufferVal[0].next=sig_in
>>> 	
>>>               for ii in range(len(coef)-1):
>>>                  bufferVal[ii+1].next = bufferVal[ii]
>>>                  sop = sop + (bufferVal[ii+1] * coefs[ii+1])
>>>               sig_out.next = (sop >> mshift)
>>>
>>>             return hdl_sop
>>
>>
>> It should be noted, that the above doesn't work with any current version
>> of code.  I think you (Norbo) might have some local changes to create
>> the initial values for a RAM and they probably will be added with the
>> initial value changes but there are a bunch of tools that need to be
>> tested/verified.
>>
>> The above will not work with ROM extraction but appears to work with RAM
>> extraction, but RAM extraction requires initial values (only applicable
>> for FPGAs and not currently implemented) or some method to program the
>> RAM with the initial values.
>
> Using a singal (probably declared as constant) which has initialvalues is
> to my knowledge the number
> one way to describe some indexable constants in VHDL. I dont think the
> switch case construct which maps the values is
> in any way preferable to that other than for the Xilinx tool ROM inference.

The statement wasn't a /for/ or /against/ it simply was pointing out the 
limitations so that others would not be surprised if they tried the 
initial value approach with the latest release or latest development.

>
> It is a very basic way to describe some constant values in VHDL. If a tool
> doesn't support this i personaly would not use
> it. If there is no ROM or RAM for the device for which the synthesis is
> done the tool should at least could implement your constant signals with
> some Vcc or Ground connections wheater it is for an ASIC or an FPGA. Realy
> if the tool can't do this, its game over.
>
> Thats for the VHDL side.
>
>
> The way i have done it in myhdl with the code above is not the preferably
> way, because a extra signals is missused to implement it altought the list
> of tuple is allready here as a port input. Mapping a integer list of
> tuples to the switch case construct is not preferable too i think, because
> then you need the extra line to map the coef's.
> 		 c = coef[ii]
>                    sop = sop + (buffer[ii] * c)
>
> this also creates the variable "c" and as we have seen with the
> right_shift, convertion, implementation an usage of varibles
> in a description can easily become a pain.
> Why risk it when the list of tuple can "easly" be implemented in vhdl or
> verilog with a signal array with initial values.
>
>
> greetings
> Norbo

For the most part I agree, I like the initial value method and not 
introducing the separate variable.  I am not sure if *all* tools support 
this method for Verilog and VHDL, though.

In addition I don't know if this approach is general enough.  These are 
the problems I see or questions I have:

1.  ASIC tools don't have an equivalent RAM/ROM mapping.  But you might 
do the logic implementation.  In that case, if you had a tuple of ints 
or LoS of ints and wanted them implemented in logic, I don't know if the 
initial value (IV) method would synthesize.  ASIC tools will have an 
external tool (ROM builder) that is used for ROMs but, as stated, if you 
wanted it in logic I don't know if the IV would work.

2. Does there need to be a method to disable?  What if a synthesis tool
does not support the IV method.  Is it expected that all tools would 
support IV.

3. What if you want to use logic and not memory? (kinda the same 
question as the disable).  For small lists (tuples) of ints you might 
not want (or can't) to use a BRAM block.

I think it comes down to tool support.  For the tuple of ints and/or 
list of signal with initial value (converts to switch/case and initial 
values assignments respectively) which tools support which method.  The 
switch/case will be supported by all tools (even if not optimal) but I 
don't know if the IV is supported by all tools?

You have a valid point, the current tuple of its will only convert to a 
ROM for the Xilinx synthesis tools and not the Altera tools.  But it 
will work for both tools even if not optimal for Altera.

Regards,
Chris


>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>