myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

[Tom D. <td...@di...>]

Not sure but have you simulated it in MyHDL? Usually that will help 
expose problems better than trying to go directly to Verilog.

On 05/21/2012 03:54 PM, Thoma HAUC wrote:
> Hi,
>
> I am new to myHDL and it seems to be a powerful tool.
> Today, I need some help to locate the reason of the below exception.
> Because there are no clue to indicate the line of the issue, I am
> currently blocked in my evaluation of myHDL.
>
> Thank you in advance.
>
> Thoma
>
> Traceback (most recent call last):
>    File "bidir_serial.py", line 209, in<module>
>      convert2verilog(bidir_serial)
>    File "bidir_serial.py", line 200, in convert2verilog
>      convert(toVerilog, architecture)
>    File "bidir_serial.py", line 194, in convert
>      converter(architecture, clr, clk, run, ld, datain, rdy, serialout)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVerilog.py",
> line 142, in __call__
>      genlist = _analyzeGens(arglist, h.absnames)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
> line 174, in _analyzeGens
>      v.visit(tree)
>    File "/usr/lib/python2.7/ast.py", line 241, in visit
>      return visitor(node)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
> line 1078, in visit_Module
>      self.generic_visit(node)
>    File "/usr/lib/python2.7/ast.py", line 249, in generic_visit
>      self.visit(item)
>    File "/usr/lib/python2.7/ast.py", line 241, in visit
>      return visitor(node)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
> line 1154, in visit_FunctionDef
>      self.visit(n)
>    File "/usr/lib/python2.7/ast.py", line 241, in visit
>      return visitor(node)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
> line 744, in visit_If
>      self.visitList(node.else_)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_misc.py", line
> 161, in visitList
>      self.visit(n)
>    File "/usr/lib/python2.7/ast.py", line 241, in visit
>      return visitor(node)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
> line 740, in visit_If
>      self.visitList(suite)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_misc.py", line
> 161, in visitList
>      self.visit(n)
>    File "/usr/lib/python2.7/ast.py", line 241, in visit
>      return visitor(node)
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
> line 770, in visit_If
>      if (len(choices) == _getNritems(var1.obj)) or node.else_:
>    File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
> line 407, in _getNritems
>      raise TypeError("Unexpected type")
> TypeError: Unexpected type
>
>
> ------------------------------------------------------------------------------
> 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/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] TypeError: Unexpected type with toVerilog

[Thoma H. <tho...@gm...>]

Hi,

I am new to myHDL and it seems to be a powerful tool.
Today, I need some help to locate the reason of the below exception.
Because there are no clue to indicate the line of the issue, I am 
currently blocked in my evaluation of myHDL.

Thank you in advance.

Thoma

Traceback (most recent call last):
  File "bidir_serial.py", line 209, in <module>
    convert2verilog(bidir_serial)
  File "bidir_serial.py", line 200, in convert2verilog
    convert(toVerilog, architecture)
  File "bidir_serial.py", line 194, in convert
    converter(architecture, clr, clk, run, ld, datain, rdy, serialout)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_toVerilog.py", 
line 142, in __call__
    genlist = _analyzeGens(arglist, h.absnames)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py", 
line 174, in _analyzeGens
    v.visit(tree)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py", 
line 1078, in visit_Module
    self.generic_visit(node)
  File "/usr/lib/python2.7/ast.py", line 249, in generic_visit
    self.visit(item)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py", 
line 1154, in visit_FunctionDef
    self.visit(n)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py", 
line 744, in visit_If
    self.visitList(node.else_)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_misc.py", line 
161, in visitList
    self.visit(n)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py", 
line 740, in visit_If
    self.visitList(suite)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_misc.py", line 
161, in visitList
    self.visit(n)
  File "/usr/lib/python2.7/ast.py", line 241, in visit
    return visitor(node)
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py", 
line 770, in visit_If
    if (len(choices) == _getNritems(var1.obj)) or node.else_:
  File "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py", 
line 407, in _getNritems
    raise TypeError("Unexpected type")
TypeError: Unexpected type

Re: [myhdl-list] Restrictions for conversion

[Tom D. <td...@di...>]

On 05/24/2012 12:37 PM, Jan Decaluwe wrote:
> On 05/24/2012 06:14 PM, Tom Dillon wrote:
>>
>> On 05/24/2012 09:17 AM, Jan Decaluwe wrote:
>>> On 05/24/2012 04:14 PM, Christopher Felton wrote:
>>>> On 5/24/2012 9:02 AM, Tom Dillon wrote:
>>>> Use MyHDL :)
>>> Right :-)
>>>
>> So there are no Xs in MyHDL. Then what we are really talking about is
>> making sure the downstream tools don't put them in where they weren't?
>>
>> For instance, you have a state machine initialized to a known state in
>> MyHDL. How do you know the synthesis results to say an ASIC will produce
>> logic to match that?
> A formal check of flip-flop types inferred (fast, cheap, my preference),
> or gate level simulation, or formal verification of gate level against RTL.
>
> This would be identical to a pure VHDL flow, where the use
> of an enumerated type to specify states is standard practice.

I get it. I thought there was some kind of magic here that would keep 
you from having to verify your synthesis results and allow you to 
neglect good design practices up front.

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/24/2012 06:14 PM, Tom Dillon wrote:
>
>
> On 05/24/2012 09:17 AM, Jan Decaluwe wrote:
>> On 05/24/2012 04:14 PM, Christopher Felton wrote:
>>> On 5/24/2012 9:02 AM, Tom Dillon wrote:
>>> Use MyHDL :)
>> Right :-)
>>
> So there are no Xs in MyHDL. Then what we are really talking about is
> making sure the downstream tools don't put them in where they weren't?
>
> For instance, you have a state machine initialized to a known state in
> MyHDL. How do you know the synthesis results to say an ASIC will produce
> logic to match that?

A formal check of flip-flop types inferred (fast, cheap, my preference),
or gate level simulation, or formal verification of gate level against RTL.

This would be identical to a pure VHDL flow, where the use
of an enumerated type to specify states is standard practice.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.co

Re: [myhdl-list] Restrictions for conversion

[Norbo <Nor...@gm...>]

Am 22.05.2012, 23:28 Uhr, schrieb Jan Decaluwe <ja...@ja...>:

> On 05/22/2012 10:41 PM, Norbo wrote:
>> Am 22.05.2012, 15:16 Uhr, schrieb Jan Decaluwe<ja...@ja...>:
>>
>>> On 05/05/2012 05:20 PM, Norbo wrote:
>>>
>>>> another point is that i think it is a good thing to have all the
>>>> variables
>>>> by default not to be initialized
>>>> with values in the converted code. Initialisation should only occour  
>>>> if
>>>> you really want to describe (pre-init RAM)
>>>> or ROM.
>>>> because for example in VHDL all the std_logic signals are set at  
>>>> startup
>>>> of a vhdl simulation to the value 'U' (stands for uninitialized) if
>>>> there
>>>> is no other initial value given. After the reset all values should  
>>>> have
>>>> changed from this
>>>> 'U' to something usefull. This allows you to see imidiatly if you have
>>>> messed up or missed something in the reset code.
>>>
>>> No, you don't see it immediately. You have to fire up a simulation,
>>> and then be lucky that the problem is not masked by logical
>>> operations.
>>
>> obviously there is no way around the simulation at least for setting the
>> reset for some time
>> to low and then to high.
>> What you forget is that the reset is asynchron, so the normal flip-flop
>> operation is "blocked" and no logical
>> masking or whatsoever will occour. You dont even have to apply a clock
>> signal to see it.
>
> What I mean is that you have to look for unitialized values
> specifically, on every signal, after a dedicated reset sequence

In myhdl it would be quit easy to iterate through the complete signallist.
Ok but there would still be a problem with the Registers that dont have a  
reset.
To make it a 100% coverage thing , the only rule to obey is, don't use  
Register without reset.


> Other simulations may not reveal any issue, even if there are
> unitialized values at the start.

For example in a plane vhdl simulation.
(This is bassically also my number one reason why the initial values from  
my point of view should not be written to
just every signal because then it wouldn't be possible to just look at the  
'U' signals, or in other words
  you have to look at every signal because you cant tell wheater the value  
comes from the initial or from the reset)

What i bassically do is:

open the waveformviewer, recursivly add all signals,
set the marker at the point of interesst,
scroll down, watch out for uninitialized values with 'U' (mostly red),
if there is a 'U' signal, check if its not from a Register without a  
reset  ->  100 % resetvalue set coverage


> But things may still go wrong
> at the gate level because RTL and gate level are only loosely
> related on this point.

Thats just a reason more, to somehow be able to verify it at least at the  
RTL level.



> I have also given considerable thought on the value of
> 'X' in digital design. A full explanation is very extensive,
> but my conclusion is that 'X' has no place in RTL design,
> and its value at the gate level is doubtful at best.

I completly agree with the 'X' but i am not so sure about the 'U'


But i came to understand that the 'U' concept, kind of involves the 'X'  
concept
and that the 'X' concept is not compatible with the intbv() integer  
concept, especially when
it comes to operaters like "&" or "|".

So in the end i kind of have to thank you for stopping me on continue  
implementing on something which is not reasonable feasible the way i  
thought.

greetings
Norbo

Re: [myhdl-list] Restrictions for conversion

[Tom D. <td...@di...>]

On 05/24/2012 09:17 AM, Jan Decaluwe wrote:
> On 05/24/2012 04:14 PM, Christopher Felton wrote:
>> On 5/24/2012 9:02 AM, Tom Dillon wrote:
>> Use MyHDL :)
> Right :-)
>
So there are no Xs in MyHDL. Then what we are really talking about is 
making sure the downstream tools don't put them in where they weren't?

For instance, you have a state machine initialized to a known state in 
MyHDL. How do you know the synthesis results to say an ASIC will produce 
logic to match that?

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/24/2012 04:14 PM, Christopher Felton wrote:
> On 5/24/2012 9:02 AM, Tom Dillon wrote:

> Use MyHDL :)

Right :-)

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

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

On 5/24/2012 9:02 AM, Tom Dillon wrote:
> On 05/24/2012 05:30 AM, Jan Decaluwe wrote:
>> On 05/24/2012 11:35 AM, Norbo wrote:
>>
>>
>>> I don't see a reason (other than irritating the VHDL or Verilog Simulation
>>> or synthesis tool) to write a initial value
>>> to a Signal that gets its value in a combinatorical process. Such a Signal
>>> gets its value at a beginning from a zero time delta cycle there
>>> is "time 0 missmatch" for such a signal.
>>>
>>> I also don't see whats this thing about the "time 0 mimatch".
>> The problem is that there may be an event in in Verilog/VHDL
>> while there may be no event in MyHDL. E.g. going from X->0
>> as opposed to 0->0.
>>
>> This may lead to subtle difficulties, typically in test
>> benches. At least in mine.
>>
>>> If i have a
>>> memory where the initial values are not written then i get a missmatch
>>> every time i read from the memmory wheater it is time 0 or time 5trillion.
>> This would be an argument to write the initial values.
>>
>>> The only missmatch i see is from a Flip-Flop output signal. In this case i
>>> think the missmatch is a good thing, because it allows to check if a
>>> Flip-Flob is not
>>> not reseted.
>> This has been covered before: at best it is a half-hearted
>> solution for which much better formal alternatives are
>> available.
>>
>> Some background perhaps: the type system in MyHDL was not inspired
>> by Verilog, but by VHDL, in particular its abstract types such as
>> integer, boolean and enum. The simple reason is that I largely
>> prefer such types over low-level "representational" types such
>> as signed/unsigned or the Verilog types.
>>
>> In particular, intbv is intended to be a better constrained
>> integer type: with indexing support and without limits on the
>> constraints. However, it keeps the fact that abstract types
>> are initialized to some implicit or explicit value that
>> belongs to the type.
>>
>> And again, there is also bool and enum whose use I would like
>> to encourage in synthesizable MyHDL.
>>
>> I have also given considerable thought on the value of
>> 'X' in digital design. A full explanation is very extensive,
>> but my conclusion is that 'X' has no place in RTL design,
>> and its value at the gate level is doubtful at best.
>
> That peaks my interest. How do you get them out of RTL design?
>

Use MyHDL :)

Re: [myhdl-list] Restrictions for conversion

[Tom D. <td...@di...>]

On 05/24/2012 05:30 AM, Jan Decaluwe wrote:
> On 05/24/2012 11:35 AM, Norbo wrote:
>
>
>> I don't see a reason (other than irritating the VHDL or Verilog Simulation
>> or synthesis tool) to write a initial value
>> to a Signal that gets its value in a combinatorical process. Such a Signal
>> gets its value at a beginning from a zero time delta cycle there
>> is "time 0 missmatch" for such a signal.
>>
>> I also don't see whats this thing about the "time 0 mimatch".
> The problem is that there may be an event in in Verilog/VHDL
> while there may be no event in MyHDL. E.g. going from X->0
> as opposed to 0->0.
>
> This may lead to subtle difficulties, typically in test
> benches. At least in mine.
>
>> If i have a
>> memory where the initial values are not written then i get a missmatch
>> every time i read from the memmory wheater it is time 0 or time 5trillion.
> This would be an argument to write the initial values.
>
>> The only missmatch i see is from a Flip-Flop output signal. In this case i
>> think the missmatch is a good thing, because it allows to check if a
>> Flip-Flob is not
>> not reseted.
> This has been covered before: at best it is a half-hearted
> solution for which much better formal alternatives are
> available.
>
> Some background perhaps: the type system in MyHDL was not inspired
> by Verilog, but by VHDL, in particular its abstract types such as
> integer, boolean and enum. The simple reason is that I largely
> prefer such types over low-level "representational" types such
> as signed/unsigned or the Verilog types.
>
> In particular, intbv is intended to be a better constrained
> integer type: with indexing support and without limits on the
> constraints. However, it keeps the fact that abstract types
> are initialized to some implicit or explicit value that
> belongs to the type.
>
> And again, there is also bool and enum whose use I would like
> to encourage in synthesizable MyHDL.
>
> I have also given considerable thought on the value of
> 'X' in digital design. A full explanation is very extensive,
> but my conclusion is that 'X' has no place in RTL design,
> and its value at the gate level is doubtful at best.

That peaks my interest. How do you get them out of RTL design?

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/24/2012 11:35 AM, Norbo wrote:


> I don't see a reason (other than irritating the VHDL or Verilog Simulation
> or synthesis tool) to write a initial value
> to a Signal that gets its value in a combinatorical process. Such a Signal
> gets its value at a beginning from a zero time delta cycle there
> is "time 0 missmatch" for such a signal.
>
> I also don't see whats this thing about the "time 0 mimatch".

The problem is that there may be an event in in Verilog/VHDL
while there may be no event in MyHDL. E.g. going from X->0
as opposed to 0->0.

This may lead to subtle difficulties, typically in test
benches. At least in mine.

> If i have a
> memory where the initial values are not written then i get a missmatch
> every time i read from the memmory wheater it is time 0 or time 5trillion.

This would be an argument to write the initial values.

> The only missmatch i see is from a Flip-Flop output signal. In this case i
> think the missmatch is a good thing, because it allows to check if a
> Flip-Flob is not
> not reseted.

This has been covered before: at best it is a half-hearted
solution for which much better formal alternatives are
available.

Some background perhaps: the type system in MyHDL was not inspired
by Verilog, but by VHDL, in particular its abstract types such as
integer, boolean and enum. The simple reason is that I largely
prefer such types over low-level "representational" types such
as signed/unsigned or the Verilog types.

In particular, intbv is intended to be a better constrained
integer type: with indexing support and without limits on the
constraints. However, it keeps the fact that abstract types
are initialized to some implicit or explicit value that
belongs to the type.

And again, there is also bool and enum whose use I would like
to encourage in synthesizable MyHDL.

I have also given considerable thought on the value of
'X' in digital design. A full explanation is very extensive,
but my conclusion is that 'X' has no place in RTL design,
and its value at the gate level is doubtful at best.


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

[Norbo <Nor...@gm...>]

Am 23.05.2012, 04:37 Uhr, schrieb Christopher Felton  
<chr...@gm...>:


> That was somewhat missed phrased, "... reasonable method ...".
> Currently initial values are not supported (enabled), for basic types or
> arrays (memories).  Currently you cannot do either.  I should have
> said, pre-init RAM is not supported in MyHDL.
>
> Known, reasonable, RAM pre-init methods are available for Verilog/VHDL.
>   It seems reasonable to include with the initial value support.
>
> Norbo prototyped this and it all seemed good but we have been discussing
> the overall behavior.  I think this is where we sit right now.
>
>     1.  Initial value support should be added, it resolves
>         the time 0 mismatch.  It has been verified with
>         the latest versions of Quartus and ISE.

I don't see a reason (other than irritating the VHDL or Verilog Simulation  
or synthesis tool) to write a initial value
to a Signal that gets its value in a combinatorical process. Such a Signal  
gets its value at a beginning from a zero time delta cycle there
is "time 0 missmatch" for such a signal.

I also don't see whats this thing about the "time 0 mimatch". If i have a  
memory where the initial values are not written then i get a missmatch
every time i read from the memmory wheater it is time 0 or time 5trillion.

The only missmatch i see is from a Flip-Flop output signal. In this case i  
think the missmatch is a good thing, because it allows to check if a  
Flip-Flob is not
not reseted.

greetings
Norbo

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/23/2012 12:47 PM, Christopher Felton wrote:

>>
>>> Norbo prototyped this and it all seemed good but we have been discussing
>>> the overall behavior.  I think this is where we sit right now.
>>>
>>>        1.  Initial value support should be added, it resolves
>>>            the time 0 mismatch.  It has been verified with
>>>            the latest versions of Quartus and ISE.
>>
>> Yes.
>
> The one implementation detail we ran into, was that the continuous
> assign statements in Verilog will need to be replaced with an @always block.

Ok, I see, I glanced over the discussions between Norbo and you.

A word of caution though: there are subtle semantic differences
between assign, always(*) and always_comb in Verilog.

I *think* always_comb should be ok, after all I once modeled
it in MyHDL after this.

Several new issues arise: do all synthesis tools that we target
(also the free ones from X/A) support always_comb, which is
basically a SystemVerilog construct? And if they do, do they
support it in a template for RAM inference?

A prudent way forward initially might be to add the initialization
only to what is currently converted as a reg.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

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

On 5/23/12 4:01 AM, Jan Decaluwe wrote:
> On 05/23/2012 04:37 AM, Christopher Felton wrote:
>> On 5/22/12 4:32 PM, Jan Decaluwe wrote:
>>> On 05/22/2012 05:34 PM, Christopher Felton wrote:
>>>
>>>>
>>>> FPGAs support pre-init RAM.  Synthesis will extract the array initial
>>>> values from the HDL and during configuration program the BRAM (internal
>>>> FPGA RAM).  When the FPGA comes out of reset (not logic reset, FPGA post
>>>> config reset) the RAM will contain the initial values.  The RAM is a RAM
>>>> so the values can be overridden by the logic, i.e not a ROM.  This is
>>>> only possible in an FPGA and is supported by X&A synthesis tools.
>>>>
>>>> I don't know a reasonable method to achieve the pre-init RAM, currently.
>>>
>>> Do you mean no reasonable method from MyHDL, or no reasonable method
>>> at all?
>>
>> That was somewhat missed phrased, "... reasonable method ...".
>> Currently initial values are not supported (enabled), for basic types or
>> arrays (memories).  Currently you cannot do either.  I should have
>> said, pre-init RAM is not supported in MyHDL.
>>
>> Known, reasonable, RAM pre-init methods are available for Verilog/VHDL.
>>     It seems reasonable to include with the initial value support.
>
> Yes. Now, from the altera literature it seems they also support
> $readmemb, which would make it possible to initialize a RAM with
> arbitrary values. But I don't know how to do that with VHDL.

The Verilog initial and the VHDL function just get ugly to the human 
reader.  Nothing says you can explicitly list each array element.  This 
is where the concern to disable arose.

     initial begin
         mem[0] = 123;
         mem[1] = 78;
         ...
         mem[31] = 9;
     end

     FUNCTION ...
     BEGIN
         result(0) := to_unsigned(natural(123), natural'(8)
         result(1) := to_unsigned(natural(78), natural'(8)
         ...
         result(31) := to_unsigned(natural(9), natural'(8)
         RETURN result;
     END

This is what was prototyped.

>
> Would it be sufficient to support memory initialization to
> an identical value for each location?
>
>> Norbo prototyped this and it all seemed good but we have been discussing
>> the overall behavior.  I think this is where we sit right now.
>>
>>       1.  Initial value support should be added, it resolves
>>           the time 0 mismatch.  It has been verified with
>>           the latest versions of Quartus and ISE.
>
> Yes.

The one implementation detail we ran into, was that the continuous 
assign statements in Verilog will need to be replaced with an @always block.

>
>>       2.  Intial value support for arrays should be included
>>           (all types are initialized).  Verdict is still out
>>           if the ivs for arrays should be "synthesizable".
>
> Yes.
>
> In summary: I think initial values should be written, regardless of
> what synthesis does with it, because of the exact match in
> simulation.
>
>
>>       3.  Unresolved, should there be a method to disable
>>           ivs.  The current proposed method is to use None.
>
> As a fallback method, I think it would be wise to be able
> to disable initial value writing by a control parameter
> to toVerilog/toVHDL. A separate control for plain signals
> and arrays probably. But this would be purely because some
> synthesis tools may not support the syntax.
>
> I don't see a value in adding support for None to intbv,
> as discussed before.
>

Sounds fine to me, to disable you would need to explicitly send the 
argument to the conversion for plain signals and/or for arrays.

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/23/2012 04:37 AM, Christopher Felton wrote:
> On 5/22/12 4:32 PM, Jan Decaluwe wrote:
>> On 05/22/2012 05:34 PM, Christopher Felton wrote:
>>
>>>
>>> FPGAs support pre-init RAM.  Synthesis will extract the array initial
>>> values from the HDL and during configuration program the BRAM (internal
>>> FPGA RAM).  When the FPGA comes out of reset (not logic reset, FPGA post
>>> config reset) the RAM will contain the initial values.  The RAM is a RAM
>>> so the values can be overridden by the logic, i.e not a ROM.  This is
>>> only possible in an FPGA and is supported by X&A synthesis tools.
>>>
>>> I don't know a reasonable method to achieve the pre-init RAM, currently.
>>
>> Do you mean no reasonable method from MyHDL, or no reasonable method
>> at all?
>
> That was somewhat missed phrased, "... reasonable method ...".
> Currently initial values are not supported (enabled), for basic types or
> arrays (memories).  Currently you cannot do either.  I should have
> said, pre-init RAM is not supported in MyHDL.
>
> Known, reasonable, RAM pre-init methods are available for Verilog/VHDL.
>    It seems reasonable to include with the initial value support.

Yes. Now, from the altera literature it seems they also support
$readmemb, which would make it possible to initialize a RAM with
arbitrary values. But I don't know how to do that with VHDL.

Would it be sufficient to support memory initialization to
an identical value for each location?

> Norbo prototyped this and it all seemed good but we have been discussing
> the overall behavior.  I think this is where we sit right now.
>
>      1.  Initial value support should be added, it resolves
>          the time 0 mismatch.  It has been verified with
>          the latest versions of Quartus and ISE.

Yes.

>      2.  Intial value support for arrays should be included
>          (all types are initialized).  Verdict is still out
>          if the ivs for arrays should be "synthesizable".

Yes.

In summary: I think initial values should be written, regardless of
what synthesis does with it, because of the exact match in
simulation.


>      3.  Unresolved, should there be a method to disable
>          ivs.  The current proposed method is to use None.

As a fallback method, I think it would be wise to be able
to disable initial value writing by a control parameter
to toVerilog/toVHDL. A separate control for plain signals
and arrays probably. But this would be purely because some
synthesis tools may not support the syntax.

I don't see a value in adding support for None to intbv,
as discussed before.


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

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

On 5/22/12 4:32 PM, Jan Decaluwe wrote:
> On 05/22/2012 05:34 PM, Christopher Felton wrote:
>
>>
>> FPGAs support pre-init RAM.  Synthesis will extract the array initial
>> values from the HDL and during configuration program the BRAM (internal
>> FPGA RAM).  When the FPGA comes out of reset (not logic reset, FPGA post
>> config reset) the RAM will contain the initial values.  The RAM is a RAM
>> so the values can be overridden by the logic, i.e not a ROM.  This is
>> only possible in an FPGA and is supported by X&A synthesis tools.
>>
>> I don't know a reasonable method to achieve the pre-init RAM, currently.
>
> Do you mean no reasonable method from MyHDL, or no reasonable method
> at all?
>
> And if there is a reasonable method, how does it work?
>

Didn't include the reference, for Quartus the pre-init RAM templates can 
be found in the following.

http://www.altera.com/literature/hb/qts/qts_qii51007.pdf

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

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

On 5/22/12 4:32 PM, Jan Decaluwe wrote:
> On 05/22/2012 05:34 PM, Christopher Felton wrote:
>
>>
>> FPGAs support pre-init RAM.  Synthesis will extract the array initial
>> values from the HDL and during configuration program the BRAM (internal
>> FPGA RAM).  When the FPGA comes out of reset (not logic reset, FPGA post
>> config reset) the RAM will contain the initial values.  The RAM is a RAM
>> so the values can be overridden by the logic, i.e not a ROM.  This is
>> only possible in an FPGA and is supported by X&A synthesis tools.
>>
>> I don't know a reasonable method to achieve the pre-init RAM, currently.
>
> Do you mean no reasonable method from MyHDL, or no reasonable method
> at all?

That was somewhat missed phrased, "... reasonable method ...". 
Currently initial values are not supported (enabled), for basic types or 
arrays (memories).  Currently you cannot do either.  I should have 
said, pre-init RAM is not supported in MyHDL.

Known, reasonable, RAM pre-init methods are available for Verilog/VHDL. 
  It seems reasonable to include with the initial value support.

Norbo prototyped this and it all seemed good but we have been discussing 
the overall behavior.  I think this is where we sit right now.

    1.  Initial value support should be added, it resolves
        the time 0 mismatch.  It has been verified with
        the latest versions of Quartus and ISE.

    2.  Intial value support for arrays should be included
        (all types are initialized).  Verdict is still out
        if the ivs for arrays should be "synthesizable".

    3.  Unresolved, should there be a method to disable
        ivs.  The current proposed method is to use None.


>
> And if there is a reasonable method, how does it work?
>

For Verilog it is an initial block, like the following

     initial begin
         for (i = 0; i < 32; i = i + 1)
             mem[i] = i[7:0];
     end

VHDL it is similar but uses a function,

     TYPE MEM IS ARRAY(31 DOWNTO 0) OF unsigned(7 DOWNTO 0);
     FUNCTION initialize_ram
         return MEM is
         variable result : MEM;
     BEGIN
         FOR i IN 31 DOWNTO 0 LOOP
             result(i) := to_unsigned(natural(i), natural'(8));
         END LOOP;
         RETURN result;
    END initialize_ram;

What I don't recall (what needs to be verified) if the above "templates" 
are supported by most synthesis tools, pretty sure simulation will 
support the above for arrays (memories).

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/22/2012 05:34 PM, Christopher Felton wrote:

>
> FPGAs support pre-init RAM.  Synthesis will extract the array initial
> values from the HDL and during configuration program the BRAM (internal
> FPGA RAM).  When the FPGA comes out of reset (not logic reset, FPGA post
> config reset) the RAM will contain the initial values.  The RAM is a RAM
> so the values can be overridden by the logic, i.e not a ROM.  This is
> only possible in an FPGA and is supported by X&A synthesis tools.
>
> I don't know a reasonable method to achieve the pre-init RAM, currently.

Do you mean no reasonable method from MyHDL, or no reasonable method
at all?

And if there is a reasonable method, how does it work?



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/22/2012 10:41 PM, Norbo wrote:
> Am 22.05.2012, 15:16 Uhr, schrieb Jan Decaluwe<ja...@ja...>:
>
>> On 05/05/2012 05:20 PM, Norbo wrote:
>>
>>> another point is that i think it is a good thing to have all the
>>> variables
>>> by default not to be initialized
>>> with values in the converted code. Initialisation should only occour if
>>> you really want to describe (pre-init RAM)
>>> or ROM.
>>> because for example in VHDL all the std_logic signals are set at startup
>>> of a vhdl simulation to the value 'U' (stands for uninitialized) if
>>> there
>>> is no other initial value given. After the reset all values should have
>>> changed from this
>>> 'U' to something usefull. This allows you to see imidiatly if you have
>>> messed up or missed something in the reset code.
>>
>> No, you don't see it immediately. You have to fire up a simulation,
>> and then be lucky that the problem is not masked by logical
>> operations.
>
> obviously there is no way around the simulation at least for setting the
> reset for some time
> to low and then to high.
> What you forget is that the reset is asynchron, so the normal flip-flop
> operation is "blocked" and no logical
> masking or whatsoever will occour. You dont even have to apply a clock
> signal to see it.

What I mean is that you have to look for unitialized values
specifically, on every signal, after a dedicated reset sequence.

Other simulations may not reveal any issue, even if there are
unitialized values at the start. But things may still go wrong
at the gate level because RTL and gate level are only loosely
related on this point.

>> For something like this, I think the only good way is a formal
>> check. What I always use is a simple check of flip-flop types
>> inferred by synthesis. Works like a charm, no simulation needed,
>> and you catch everything in one pass.
>
> Yeah, you can do that but, i personally dont like two wait till the end of
> a e.g: "hour" long synthesis to
> just discover that something is wrong with reset values and than synthesis
> all over again.

You must be doing million gate synthesis runs then :-)

No need for full synthesis of course. The analysis phase of a tool
like Design Compiler gives you a full list with all registers
and their characteristics within seconds. To me it's part
of debugging and fixing synthesis warnings to get the design
clean for synthesis.


--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

[Norbo <Nor...@gm...>]

Am 22.05.2012, 15:16 Uhr, schrieb Jan Decaluwe <ja...@ja...>:

> On 05/05/2012 05:20 PM, Norbo wrote:
>
>> another point is that i think it is a good thing to have all the  
>> variables
>> by default not to be initialized
>> with values in the converted code. Initialisation should only occour if
>> you really want to describe (pre-init RAM)
>> or ROM.
>> because for example in VHDL all the std_logic signals are set at startup
>> of a vhdl simulation to the value 'U' (stands for uninitialized) if  
>> there
>> is no other initial value given. After the reset all values should have
>> changed from this
>> 'U' to something usefull. This allows you to see imidiatly if you have
>> messed up or missed something in the reset code.
>
> No, you don't see it immediately. You have to fire up a simulation,
> and then be lucky that the problem is not masked by logical
> operations.

obviously there is no way around the simulation at least for setting the  
reset for some time
to low and then to high.
What you forget is that the reset is asynchron, so the normal flip-flop  
operation is "blocked" and no logical
masking or whatsoever will occour. You dont even have to apply a clock  
signal to see it.


> For something like this, I think the only good way is a formal
> check. What I always use is a simple check of flip-flop types
> inferred by synthesis. Works like a charm, no simulation needed,
> and you catch everything in one pass.

Yeah, you can do that but, i personally dont like two wait till the end of  
a e.g: "hour" long synthesis to
just discover that something is wrong with reset values and than synthesis  
all over again.


greetings
Norbo

Re: [myhdl-list] Restrictions for conversion

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

On 5/22/2012 8:51 AM, Jan Decaluwe wrote:
> On 05/22/2012 03:29 PM, Tom Dillon wrote:
>> On 05/22/2012 08:12 AM, Jan Decaluwe wrote:
>>> On 05/05/2012 05:20 PM, Norbo wrote:
>>>
>>>
>>>> another point is that i think it is a good thing to have all the variables
>>>> by default not to be initialized
>>>> with values in the converted code.
>>> No, they should, for the simple reason that the intent of conversion
>>> is to generate Verilog/VHDL which matches the MyHDL behavior exactly.
>>>
>>> The only reason why they are not written currently (once they were) is
>>> a practical one: some synthesis tools didn't support this. But as soon
>>> we are sure they all do, I will want to change that. That would solve all
>>> kinds of issues at simulation time 0.
>>
>> It can be annoying not to have a value at time 0 since you can get some
>> warnings but I don't think all synthesis tools will take care of this
>> for you. Depending on what you are synthesizing to it might not even be
>> possible.
>
> I am not saying synthesis should do anything with these values. It
> should just support the syntax.
>
> What this gives us is that at least in simulation, we would get a full
> match between MyHDL and the converted Verilog/VHDL, which is the
> primary goal of conversion. Now we sometimes don't at time 0, and it's
> always confusing.
>
>> I think the only way to guarantee initial values is the have a set/reset
>> that is activated and use it in your logic to properly initialize
>> anything that matters.
>
> At the gate level, of course.
>
>> Now maybe we are trying to deal with special cases in FPGAs? Such as
>> initializing memory? I am coming late to this discussion.
>
> Me also :-) I would also like to hear a simple explanation of this.
>
>

You had to add the "simple" qualifier :)

FPGAs support pre-init RAM.  Synthesis will extract the array initial 
values from the HDL and during configuration program the BRAM (internal 
FPGA RAM).  When the FPGA comes out of reset (not logic reset, FPGA post 
config reset) the RAM will contain the initial values.  The RAM is a RAM 
so the values can be overridden by the logic, i.e not a ROM.  This is 
only possible in an FPGA and is supported by X&A synthesis tools.

I don't know a reasonable method to achieve the pre-init RAM, currently. 
  Theoretically, this would be supported with initial value support; 
such that the lower HDL matches the MyHDL at time 0.  I don't see a 
reason why the memory initial value shouldn't be synthesizable, as well, 
if the tools support it.

The question is for large memories would you want to be able to disable 
initial values for the memory array?  Would the overhead in simulation 
and/or synthesis be too costly to always include the memory initial values?

And yes, we should have some information on the cost of large memory 
initial values before proclaiming we need a method to disable.  I have 
not run any experiments or run into this in the past.  Anyone have any 
data points if large pre-init RAM structures are costly in simulation or 
synthesis?

Summary, two items.  One synthesizable initial value support (ivs) for 
RAM memories.  Second, does there need to be a method to disable ivs for 
RAM memories?

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

[Tom D. <td...@di...>]

On 05/22/2012 08:51 AM, Jan Decaluwe wrote:
> On 05/22/2012 03:29 PM, Tom Dillon wrote:
>> On 05/22/2012 08:12 AM, Jan Decaluwe wrote:
>>> On 05/05/2012 05:20 PM, Norbo wrote:
>>>
>>>
>>>> another point is that i think it is a good thing to have all the variables
>>>> by default not to be initialized
>>>> with values in the converted code.
>>> No, they should, for the simple reason that the intent of conversion
>>> is to generate Verilog/VHDL which matches the MyHDL behavior exactly.
>>>
>>> The only reason why they are not written currently (once they were) is
>>> a practical one: some synthesis tools didn't support this. But as soon
>>> we are sure they all do, I will want to change that. That would solve all
>>> kinds of issues at simulation time 0.
>> It can be annoying not to have a value at time 0 since you can get some
>> warnings but I don't think all synthesis tools will take care of this
>> for you. Depending on what you are synthesizing to it might not even be
>> possible.
> I am not saying synthesis should do anything with these values. It
> should just support the syntax.
>
> What this gives us is that at least in simulation, we would get a full
> match between MyHDL and the converted Verilog/VHDL, which is the
> primary goal of conversion. Now we sometimes don't at time 0, and it's
> always confusing.

Yes, that makes good sense.

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/22/2012 03:29 PM, Tom Dillon wrote:
> On 05/22/2012 08:12 AM, Jan Decaluwe wrote:
>> On 05/05/2012 05:20 PM, Norbo wrote:
>>
>>
>>> another point is that i think it is a good thing to have all the variables
>>> by default not to be initialized
>>> with values in the converted code.
>> No, they should, for the simple reason that the intent of conversion
>> is to generate Verilog/VHDL which matches the MyHDL behavior exactly.
>>
>> The only reason why they are not written currently (once they were) is
>> a practical one: some synthesis tools didn't support this. But as soon
>> we are sure they all do, I will want to change that. That would solve all
>> kinds of issues at simulation time 0.
>
> It can be annoying not to have a value at time 0 since you can get some
> warnings but I don't think all synthesis tools will take care of this
> for you. Depending on what you are synthesizing to it might not even be
> possible.

I am not saying synthesis should do anything with these values. It
should just support the syntax.

What this gives us is that at least in simulation, we would get a full
match between MyHDL and the converted Verilog/VHDL, which is the
primary goal of conversion. Now we sometimes don't at time 0, and it's
always confusing.

> I think the only way to guarantee initial values is the have a set/reset
> that is activated and use it in your logic to properly initialize
> anything that matters.

At the gate level, of course.

> Now maybe we are trying to deal with special cases in FPGAs? Such as
> initializing memory? I am coming late to this discussion.

Me also :-) I would also like to hear a simple explanation of this.


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

[Tom D. <td...@di...>]

On 05/22/2012 08:12 AM, Jan Decaluwe wrote:
> On 05/05/2012 05:20 PM, Norbo wrote:
>
>
>> another point is that i think it is a good thing to have all the variables
>> by default not to be initialized
>> with values in the converted code.
> No, they should, for the simple reason that the intent of conversion
> is to generate Verilog/VHDL which matches the MyHDL behavior exactly.
>
> The only reason why they are not written currently (once they were) is
> a practical one: some synthesis tools didn't support this. But as soon
> we are sure they all do, I will want to change that. That would solve all
> kinds of issues at simulation time 0.

It can be annoying not to have a value at time 0 since you can get some 
warnings but I don't think all synthesis tools will take care of this 
for you. Depending on what you are synthesizing to it might not even be 
possible.

I think the only way to guarantee initial values is the have a set/reset 
that is activated and use it in your logic to properly initialize 
anything that matters.

Now maybe we are trying to deal with special cases in FPGAs? Such as 
initializing memory? I am coming late to this discussion.

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/05/2012 05:20 PM, Norbo wrote:

> another point is that i think it is a good thing to have all the variables
> by default not to be initialized
> with values in the converted code. Initialisation should only occour if
> you really want to describe (pre-init RAM)
> or ROM.
> because for example in VHDL all the std_logic signals are set at startup
> of a vhdl simulation to the value 'U' (stands for uninitialized) if there
> is no other initial value given. After the reset all values should have
> changed from this
> 'U' to something usefull. This allows you to see imidiatly if you have
> messed up or missed something in the reset code.

No, you don't see it immediately. You have to fire up a simulation,
and then be lucky that the problem is not masked by logical
operations.

For something like this, I think the only good way is a formal
check. What I always use is a simple check of flip-flop types
inferred by synthesis. Works like a charm, no simulation needed,
and you catch everything in one pass.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Restrictions for conversion

[Jan D. <ja...@ja...>]

On 05/05/2012 05:20 PM, Norbo wrote:


> another point is that i think it is a good thing to have all the variables
> by default not to be initialized
> with values in the converted code.

No, they should, for the simple reason that the intent of conversion
is to generate Verilog/VHDL which matches the MyHDL behavior exactly.

The only reason why they are not written currently (once they were) is
a practical one: some synthesis tools didn't support this. But as soon
we are sure they all do, I will want to change that. That would solve all
kinds of issues at simulation time 0.

> The point is, by default no initial value should be written in the
> converted code, only when you need it explicit to describe something.
> Maybe a default None value in the intbv?

If you do something special for the intbv, then that can only give
a half-hearted solution. I would like to encourage the use of high-level
types such as bool and enum.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com