myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Reset functionality "synthesis"

[Ben <ben...@gm...>]

On Jul 3, 2012, at 6:40 PM, Angel Ezquerra wrote:

>>> how do you choose between synchronous and asynchronous reset?
>> 
>> reset = ResetSignal(0, async=False)
>> 
>> Note that you can change the reset style (and the
>> active level) for the whole reset tree by merely
>> changing the reset constructor.
>> Changing styles has never been so easy!
>> 
>>> Is asynchronous reset the default?
>> 
>> Yes.
> 
> Jan,
> 
> given how contentious the asynchronous vs synchronous reset debate is I would argue that there should be no default value in this case, and that the reset type should always be set explicitly.

I second this, and if one get tired of defining the 'synchronousity' at every reset signal, we could define some AsyncResetSignal and SyncResetSignal class that would do it for you ...

Best,
Benoît

Re: [myhdl-list] Reset functionality "synthesis"

[Angel E. <ezq...@gm...>]

On Jul 3, 2012 6:32 PM, "Jan Decaluwe" <ja...@ja...> wrote:
>
> On 07/03/2012 04:33 PM, Angel Ezquerra Moreu wrote:
> > On Tue, Jul 3, 2012 at 1:57 PM, Jan Decaluwe<ja...@ja...>
 wrote:
> >> On 06/27/2012 06:08 AM, Christopher Felton wrote:
> >>> <snip>
> >>>>>>
> >>>>>> Feedback welcome!
> >>>>>>
> >>>>>
> >>>>> Haven't thought this fully through but would it be better
> >>>>> to have the /reset/ properties passes as arguments to the
> >>>>> decorator or properties of the Signal?  Example if properties
> >>>>> used:
> >>>>>
> >>>>>          reset = Signal(False)
> >>>>>          reset.level = 0
> >>>>>          reset.async = True
> >>>>>
> >>>>>          @always_ff(clock.posedge, reset=reset)
> >>>>>
> >>>>> The property defaults would be the same as you stated.
> >>>>
> >>>> Seems a very good idea. Perhaps even introduce a
> >>>> Signal subclass, ResetSignal, to set the properties
> >>>> at construction time and allow type checking in the
> >>>> always_ff decorator:
> >>>>
> >>>> reset = ResetSignal(0, active=0, async=True) # defaults shown
> >>>
> >>> That seems very reasonable, I like it.  This should be a
> >>> pretty cool addition!
> >>
> >> I have gone forward with implementing this, because I am
> >> working on a project in which it is immediately useful.
> >>
> >> I have decided to rename the decorator to always_seq, for
> >> sequential, as opposed to combinatorial.
> >>
> >> always_ff in SystemVerilog means something else, and suggests
> >> a much lower level by referring to flip-flops, so reusing
> >> this name would be confusing. So now we have always_comb
> >> and always_seq, much more logical in RTL coding.
> >>
> >> The draft implementation is in the public repo.
> >> There is a ResetSignal as discussed. Conversion is implemented
> >> for VHDL and Verilog.
> >>
> >> No unit tests yet.
> >> I have only tried it for async reset with active level 0,
> >> so for other cases there may be bugs.
> >>
> >> I think this is going to be a great feature. My code becomes
> >> so much smaller in one pass, and you get "to the point"
> >> immediately instead of being distracted by all those reset
> >> assignments.  At first, it looks a little suprizing
> >> (where are my reset values?) but I think it's a matter of
> >> getting used to the concept.
> >>
> >> Note that you can construct "local" signals close to the
> >> generator where they are used, not necessarily all in
> >> the beginning.
> >>
> >> Example usage:
> >>
> >>       ...
> >>       reset = ResetSignal(0)
> >>       ...
> >>       ready = Signal(bool(0))
> >>       s0, s1, s2 = [Signal(bool(0)  for i in range(3)]
> >>
> >>       @always_seq(clock.posedge, reset=reset)
> >>       def synchronizer():
> >>           s0.next = ready_toggle
> >>           s1.next = s0
> >>           s2.next = s1
> >>           ready.next = s2 != s1
> >>
> >> When reset goes low, the signals are asynchronously reset to
> >> their initial values.
> >
> > Jan,
> >
> > how do you choose between synchronous and asynchronous reset?
>
> reset = ResetSignal(0, async=False)
>
> Note that you can change the reset style (and the
> active level) for the whole reset tree by merely
> changing the reset constructor.
> Changing styles has never been so easy!
>
> > Is asynchronous reset the default?
>
> Yes.

Jan,

given how contentious the asynchronous vs synchronous reset debate is I
would argue that there should be no default value in this case, and that
the reset type should always be set explicitly.

Cheers,

Angel

Re: [myhdl-list] Reset functionality "synthesis"

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

On 07/03/2012 04:33 PM, Angel Ezquerra Moreu wrote:
> On Tue, Jul 3, 2012 at 1:57 PM, Jan Decaluwe<ja...@ja...>  wrote:
>> On 06/27/2012 06:08 AM, Christopher Felton wrote:
>>> <snip>
>>>>>>
>>>>>> Feedback welcome!
>>>>>>
>>>>>
>>>>> Haven't thought this fully through but would it be better
>>>>> to have the /reset/ properties passes as arguments to the
>>>>> decorator or properties of the Signal?  Example if properties
>>>>> used:
>>>>>
>>>>>          reset = Signal(False)
>>>>>          reset.level = 0
>>>>>          reset.async = True
>>>>>
>>>>>          @always_ff(clock.posedge, reset=reset)
>>>>>
>>>>> The property defaults would be the same as you stated.
>>>>
>>>> Seems a very good idea. Perhaps even introduce a
>>>> Signal subclass, ResetSignal, to set the properties
>>>> at construction time and allow type checking in the
>>>> always_ff decorator:
>>>>
>>>> reset = ResetSignal(0, active=0, async=True) # defaults shown
>>>
>>> That seems very reasonable, I like it.  This should be a
>>> pretty cool addition!
>>
>> I have gone forward with implementing this, because I am
>> working on a project in which it is immediately useful.
>>
>> I have decided to rename the decorator to always_seq, for
>> sequential, as opposed to combinatorial.
>>
>> always_ff in SystemVerilog means something else, and suggests
>> a much lower level by referring to flip-flops, so reusing
>> this name would be confusing. So now we have always_comb
>> and always_seq, much more logical in RTL coding.
>>
>> The draft implementation is in the public repo.
>> There is a ResetSignal as discussed. Conversion is implemented
>> for VHDL and Verilog.
>>
>> No unit tests yet.
>> I have only tried it for async reset with active level 0,
>> so for other cases there may be bugs.
>>
>> I think this is going to be a great feature. My code becomes
>> so much smaller in one pass, and you get "to the point"
>> immediately instead of being distracted by all those reset
>> assignments.  At first, it looks a little suprizing
>> (where are my reset values?) but I think it's a matter of
>> getting used to the concept.
>>
>> Note that you can construct "local" signals close to the
>> generator where they are used, not necessarily all in
>> the beginning.
>>
>> Example usage:
>>
>>       ...
>>       reset = ResetSignal(0)
>>       ...
>>       ready = Signal(bool(0))
>>       s0, s1, s2 = [Signal(bool(0)  for i in range(3)]
>>
>>       @always_seq(clock.posedge, reset=reset)
>>       def synchronizer():
>>           s0.next = ready_toggle
>>           s1.next = s0
>>           s2.next = s1
>>           ready.next = s2 != s1
>>
>> When reset goes low, the signals are asynchronously reset to
>> their initial values.
>
> Jan,
>
> how do you choose between synchronous and asynchronous reset?

reset = ResetSignal(0, async=False)

Note that you can change the reset style (and the
active level) for the whole reset tree by merely
changing the reset constructor.
Changing styles has never been so easy!

> Is asynchronous reset the default?

Yes.

-- 
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] Reset functionality "synthesis"

[Angel E. M. <ang...@gm...>]

On Tue, Jul 3, 2012 at 1:57 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 06/27/2012 06:08 AM, Christopher Felton wrote:
>> <snip>
>>>>>
>>>>> Feedback welcome!
>>>>>
>>>>
>>>> Haven't thought this fully through but would it be better
>>>> to have the /reset/ properties passes as arguments to the
>>>> decorator or properties of the Signal?  Example if properties
>>>> used:
>>>>
>>>>         reset = Signal(False)
>>>>         reset.level = 0
>>>>         reset.async = True
>>>>
>>>>         @always_ff(clock.posedge, reset=reset)
>>>>
>>>> The property defaults would be the same as you stated.
>>>
>>> Seems a very good idea. Perhaps even introduce a
>>> Signal subclass, ResetSignal, to set the properties
>>> at construction time and allow type checking in the
>>> always_ff decorator:
>>>
>>> reset = ResetSignal(0, active=0, async=True) # defaults shown
>>
>> That seems very reasonable, I like it.  This should be a
>> pretty cool addition!
>
> I have gone forward with implementing this, because I am
> working on a project in which it is immediately useful.
>
> I have decided to rename the decorator to always_seq, for
> sequential, as opposed to combinatorial.
>
> always_ff in SystemVerilog means something else, and suggests
> a much lower level by referring to flip-flops, so reusing
> this name would be confusing. So now we have always_comb
> and always_seq, much more logical in RTL coding.
>
> The draft implementation is in the public repo.
> There is a ResetSignal as discussed. Conversion is implemented
> for VHDL and Verilog.
>
> No unit tests yet.
> I have only tried it for async reset with active level 0,
> so for other cases there may be bugs.
>
> I think this is going to be a great feature. My code becomes
> so much smaller in one pass, and you get "to the point"
> immediately instead of being distracted by all those reset
> assignments.  At first, it looks a little suprizing
> (where are my reset values?) but I think it's a matter of
> getting used to the concept.
>
> Note that you can construct "local" signals close to the
> generator where they are used, not necessarily all in
> the beginning.
>
> Example usage:
>
>      ...
>      reset = ResetSignal(0)
>      ...
>      ready = Signal(bool(0))
>      s0, s1, s2 = [Signal(bool(0)  for i in range(3)]
>
>      @always_seq(clock.posedge, reset=reset)
>      def synchronizer():
>          s0.next = ready_toggle
>          s1.next = s0
>          s2.next = s1
>          ready.next = s2 != s1
>
> When reset goes low, the signals are asynchronously reset to
> their initial values.

Jan,

how do you choose between synchronous and asynchronous reset? Is
asynchronous reset the default?

At least for Xilinx FPGAs using synchronous reset is highly
recommended over asynchronous reset because most of the bulit-in FPGA
devices (such as BRAM blocks and DSP48) do not have asynchronous reset
lines but they do have synchronous reset lines).

Angel

Re: [myhdl-list] Simplifying Interfaces

[Wesley N. <we...@sk...>]

Great, I have more in-depth look at this and post some feed back as soon as
I get some time. Thanks for the example. :)

Wes

On Tue, Jul 3, 2012 at 1:34 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 06/26/2012 02:35 PM, Christopher Felton wrote:
> > On 6/22/2012 10:24 AM, Jan Decaluwe wrote:
> >> Hi:
> >>
> >> I don't follow the example completely, but if you  -
> >> an experienced MyHDL designer - are surprized, then
> >> others will be even more so.
> >>
> >> I wonder if we can come up with an example suited for
> >> the MyHDL by Example section, that demonstrates the power
> >> of these techniques.
> >>
> >> The message should be that conversion only deals with
> >> code inside generators, in the context of their namespaces.
> >> Conversion restrictions only apply to that code.
> >> The namespaces are created during elaboration, so it
> >> doesn't matter how.
> >>
> >
> > I have been trying to think of a good example, an example that isn't too
> > large (too much code to dig through for a cookbook example) and an
> > example that fits nicely, I haven't come up with too many ideas.
> >
> > One example that appears to be used heavily with VHDL records and SV
> > structs is a simple {opcode, address, flags} bundling.  But this example
> > on its own wouldn't be functional, it wouldn't do anything.
> >
> > It would be nice to have a small example that does something, I am
> > failing to think of a good example.
> >
> > Anyone else have an idea for an example?  I think for the example to be
> > useful, you would want a design that you would use multiple modules and
> > have some interface between.  But the interface would be small (limited
> > number of signals in the class) so the the example would be digestible.
>
> Maybe something based on complex numbers, as Tom D has
> hinted. One could represent them as a class instance,
> or even as a tuple.
>
>
> --
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [myhdl-list] ExtractHierarchyError

[Wesley N. <we...@sk...>]

Yes, Chris and Jan are right.

If you have the wrong amount of objects being returned you get an error
saying as as much.

I was returning the correct amount of objects, but one was a Signal and not
a Method.

Thanks

Wes

On Tue, Jul 3, 2012 at 1:30 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 06/30/2012 10:50 PM, Wesley New wrote:
> > I am getting this error when running the toVerilog method:
> >
> > raise ExtractHierarchyError(_error.InconsistentToplevel %
> (top_inst.level, name))
> > myhdl.ExtractHierarchyError: Inconsistent top level 2 for toplevel -
> should be 1
> >
> > Can anyone shed some more light on this error.
>
> Something strange with the hierarchy definition, as
> Chris F points out you should check whether all
> modules return generators/instances correctly.
>
> --
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [myhdl-list] Reset functionality "synthesis"

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

On 06/27/2012 06:08 AM, Christopher Felton wrote:
> <snip>
>>>>
>>>> Feedback welcome!
>>>>
>>>
>>> Haven't thought this fully through but would it be better
>>> to have the /reset/ properties passes as arguments to the
>>> decorator or properties of the Signal?  Example if properties
>>> used:
>>>
>>>         reset = Signal(False)
>>>         reset.level = 0
>>>         reset.async = True
>>>
>>>         @always_ff(clock.posedge, reset=reset)
>>>
>>> The property defaults would be the same as you stated.
>>
>> Seems a very good idea. Perhaps even introduce a
>> Signal subclass, ResetSignal, to set the properties
>> at construction time and allow type checking in the
>> always_ff decorator:
>>
>> reset = ResetSignal(0, active=0, async=True) # defaults shown
>
> That seems very reasonable, I like it.  This should be a
> pretty cool addition!

I have gone forward with implementing this, because I am
working on a project in which it is immediately useful.

I have decided to rename the decorator to always_seq, for
sequential, as opposed to combinatorial.

always_ff in SystemVerilog means something else, and suggests
a much lower level by referring to flip-flops, so reusing
this name would be confusing. So now we have always_comb
and always_seq, much more logical in RTL coding.

The draft implementation is in the public repo.
There is a ResetSignal as discussed. Conversion is implemented
for VHDL and Verilog.

No unit tests yet.
I have only tried it for async reset with active level 0,
so for other cases there may be bugs.

I think this is going to be a great feature. My code becomes
so much smaller in one pass, and you get "to the point"
immediately instead of being distracted by all those reset
assignments.  At first, it looks a little suprizing
(where are my reset values?) but I think it's a matter of
getting used to the concept.

Note that you can construct "local" signals close to the
generator where they are used, not necessarily all in
the beginning.

Example usage:

     ...
     reset = ResetSignal(0)
     ...
     ready = Signal(bool(0))
     s0, s1, s2 = [Signal(bool(0)  for i in range(3)]
   
     @always_seq(clock.posedge, reset=reset)
     def synchronizer():
         s0.next = ready_toggle
         s1.next = s0
         s2.next = s1
         ready.next = s2 != s1

When reset goes low, the signals are asynchronously reset to
their initial values.

-- 
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] Simplifying Interfaces

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

On 06/26/2012 02:35 PM, Christopher Felton wrote:
> On 6/22/2012 10:24 AM, Jan Decaluwe wrote:
>> Hi:
>>
>> I don't follow the example completely, but if you  -
>> an experienced MyHDL designer - are surprized, then
>> others will be even more so.
>>
>> I wonder if we can come up with an example suited for
>> the MyHDL by Example section, that demonstrates the power
>> of these techniques.
>>
>> The message should be that conversion only deals with
>> code inside generators, in the context of their namespaces.
>> Conversion restrictions only apply to that code.
>> The namespaces are created during elaboration, so it
>> doesn't matter how.
>>
>
> I have been trying to think of a good example, an example that isn't too
> large (too much code to dig through for a cookbook example) and an
> example that fits nicely, I haven't come up with too many ideas.
>
> One example that appears to be used heavily with VHDL records and SV
> structs is a simple {opcode, address, flags} bundling.  But this example
> on its own wouldn't be functional, it wouldn't do anything.
>
> It would be nice to have a small example that does something, I am
> failing to think of a good example.
>
> Anyone else have an idea for an example?  I think for the example to be
> useful, you would want a design that you would use multiple modules and
> have some interface between.  But the interface would be small (limited
> number of signals in the class) so the the example would be digestible.

Maybe something based on complex numbers, as Tom D has
hinted. One could represent them as a class instance,
or even as a tuple.


-- 
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] ExtractHierarchyError

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

On 06/30/2012 10:50 PM, Wesley New wrote:
> I am getting this error when running the toVerilog method:
>
> raise ExtractHierarchyError(_error.InconsistentToplevel % (top_inst.level, name))
> myhdl.ExtractHierarchyError: Inconsistent top level 2 for toplevel - should be 1
>
> Can anyone shed some more light on this error.

Something strange with the hierarchy definition, as
Chris F points out you should check whether all
modules return generators/instances correctly.

-- 
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] Incorrect conclusions in TSConIT paper

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

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.

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

Re: [myhdl-list] ExtractHierarchyError

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

On 6/30/12 3:50 PM, Wesley New wrote:
> I am getting this error when running the toVerilog method:
>
> raise ExtractHierarchyError(_error.InconsistentToplevel %
> (top_inst.level, name))
> myhdl.ExtractHierarchyError: Inconsistent top level 2 for toplevel -
> should be 1
>
> Can anyone shed some more light on this error.
>
> Thanks
>
> Wes

I haven't run across this particular error before.  My guess is either, 
some how, to functions were sent for the top-level (??) or not all the 
generators were returned.

Regards,
Chris

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

[Christopher F. <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.

Regards,
Chris

[myhdl-list] ExtractHierarchyError

[Wesley N. <we...@sk...>]

I am getting this error when running the toVerilog method:

raise ExtractHierarchyError(_error.InconsistentToplevel % (top_inst.level,
name))
myhdl.ExtractHierarchyError: Inconsistent top level 2 for toplevel - should
be 1

Can anyone shed some more light on this error.

Thanks

Wes

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

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

Am 29.06.2012, 23:16 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> <snip>
>>
>> My version with the initial values would look like this:
>>
>>     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 = 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] * coefs[ii])
>> 	  sig_out.next = (sop >> mshift)
>>
>>         return hdl_sop
>>
>> but there is still the shift error.
>>
>>
>> greetings
>> Norbo
>>
>>
>
> I don't think the above would work because the loop doesn't use
> bufferVal[len(coef)-1) and coef[len(coef)-1].

thanks, of course it should look like this:

      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

greetings
Norbo

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

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

<snip>
> Yes, in GHDL I get the following error for the converted VHDL.
>
>       ghdl -c pck_myhdl_08dev.vhd firfilt.vhd
>       firfilt.vhd:46:36: ';' is expected instead of 'when'
>
> I am running the latest 0.8dev and didn't check with 0.7.

The issue has to do with the python conditionals, if I remove the python 
conditional then it doesn't error in this spot with GHDL or quartus (I 
realize Norbo said this in his original response).

I do *not* get any errors with GHDL but I do get the shift_right error 
with quartus and ise.

quartus error:
   can't determine type of object at or near identifier
   "shift_right" -- found 0 possible types

ise error:
   shift_right can not have such operands in this context
   IN mode Formal size of to_signed wiht no default value
   must be associated with an actual value

The verilog version synthezied, PaR'd, and bit'd fine.

Regards,
Chris

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

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

<snip>
>
> My version with the initial values would look like this:
>
>     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 = 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] * coefs[ii])
> 	  sig_out.next = (sop >> mshift)
>
>         return hdl_sop
>
> but there is still the shift error.
>
>
> greetings
> Norbo
>
>

I don't think the above would work because the loop doesn't use 
bufferVal[len(coef)-1) and coef[len(coef)-1].  I think if you ran the 
testbench it would fail?  If the testbench does pass, I think my test 
conditions are not tight enough then, disregarding the last tap and 
coefficient should have some effect.  I believe you either need the 
conditional or two loops.  Given the original context, I used the 
conditional vs. an /if/ or two loops.

Regards,
Chris

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

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

On 6/29/12 12:43 PM, Norbo wrote:
> Am 26.06.2012, 13:51 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
>> On 6/22/2012 9:57 AM, Jan Decaluwe wrote:
>>> The author presents the following example:
>>>
>>> --
>>> from myhdl import *
>>>
>>> def firfilt (sigin, sigout, coefs, clk):
>>>        buffer = Signal(intbv(0)[len(sigin)*len(coefs)])
>>>        inlen = len(sigin)
>>>        saved_coefs = coefs
>>>        colen = len(saved_coefs)
>>>
>>>        @always(clk.posedge)
>>>        def logic():
>>>            buffer.next[inlen:] = sigin
>>>            buffer.next[:inlen] = buffer[inlen * (colen-1):]
>>>            tmp = 0
>>>            for index in range(colen):
>>>                mult = saved_coefs[inlen*(index+1):inlen*index] * \
>>>                       buffer[inlen*(index +1): inlen*index]
>>>                tmp = tmp + sigin
>>>            sigout.next = tmp
>>>
>>>        return logic
>>
>> The author did a poor job picking their examples.  I say
>> this because I don't think their VHDL example is correct,
>> either.  They don't provide enough information but for the
>> VHDL example to be correct the instantiator would need to
>> take care of the output word size to handle the bit growth
>> as a result of the multiplies and additions (or limit the
>> input range).  I think if they would have verified the VHDL
>> they would have found the VHDL implementation did not meet
>> their requirements (or any requirements for a FIR filter).
>>
>> Also, I don't think the author provides the description of
>> the RAM/ROM for the coefficients in the VHDL example.  The
>> VHDL example is not a fair comparison because it would need
>> additional description, somewhere, to define the coefficient
>> array.  Where as the MyHDL version the coefficient array
>> description is embedded!
>>
>> Here is my version of the FIR filter in MyHDL that matches
>> the simplified templated:
>>
>>       from myhdl import *
>>       def firfilt(sig_in, sig_out, coef, clk):
>>           buffer = [Signal(intbv(0, min=sig_in.min, max=sig_in.max)) \
>>                     for ii in range(len(coef))]
>>           coef = tuple(coef)
>>           mshift = len(sig_in)-1
>>           @always(clk.posedge)
>>           def hdl_sop():
>>               sop = 0
>>               # Note this adds an extra delay! (Group delay N/2+2)
>>               for ii in range(len(coef)):
>>                   buffer[ii].next = sig_in if ii == 0 else buffer[ii-1]
>>                   c = coef[ii]
>>                   sop = sop + (buffer[ii] * c)
>>               sig_out.next = (sop >> mshift)
>>
>>           return hdl_sop
>>
>
> i just tried to run the converted vhdl through quartus and it came up with
> the following error:
>
> 	Error (10500): VHDL syntax error at firfilt.vhd(39) near text "when";
> expecting ";"
>
> hm.. maybe its not supported in a clocked process but i am not so sure i
> have to look at that closer.
> the next error after i changed to a normal if i got:
>
> 	Error (10405): VHDL error at firfilt.vhd(78): can't determine type of
> object at or near identifier "shift_right" -- found 0 possible types
>
>
>
>
> Note: I changed buffer to bufferVal because it is a reserved keyword in
> vhdl
>
>
>
> My version with the initial values would look like this:
>
>     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 = 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] * coefs[ii])
> 	  sig_out.next = (sop >> mshift)
>
>         return hdl_sop
>
> but there is still the shift error.
>
>
> greetings
> Norbo
>
>
>

I didn't follow the reason for adding the LoS with initial values?  Why 
did you add the

     coefs = [Signal(intbv(ii, min=min(coef), max=max(coef)+1)) \
              for ii in coef]
?

Yes, in GHDL I get the following error for the converted VHDL.

     ghdl -c pck_myhdl_08dev.vhd firfilt.vhd
     firfilt.vhd:46:36: ';' is expected instead of 'when'

I am running the latest 0.8dev and didn't check with 0.7.

I am not sure what the the error is, when I have a little more time I 
can investigate (or maybe someone else has some insight).

I did add cosimulation with Verilog to the testbench and the 
cosimulation runs fine (passes tests).  The updated code is available in 
the same location, bitbucket repo.  I renamed the "buffer" as well.  I 
also added a reset so I didn't need a special case for checking the 
output.  The circuit would run ok without a reset it just would take N 
cycles (N being the number of taps) before a valid output is available.

Regards,
Chris

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

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

Am 26.06.2012, 13:51 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> On 6/22/2012 9:57 AM, Jan Decaluwe wrote:
>> The author presents the following example:
>>
>> --
>> from myhdl import *
>>
>> def firfilt (sigin, sigout, coefs, clk):
>>       buffer = Signal(intbv(0)[len(sigin)*len(coefs)])
>>       inlen = len(sigin)
>>       saved_coefs = coefs
>>       colen = len(saved_coefs)
>>
>>       @always(clk.posedge)
>>       def logic():
>>           buffer.next[inlen:] = sigin
>>           buffer.next[:inlen] = buffer[inlen * (colen-1):]
>>           tmp = 0
>>           for index in range(colen):
>>               mult = saved_coefs[inlen*(index+1):inlen*index] * \
>>                      buffer[inlen*(index +1): inlen*index]
>>               tmp = tmp + sigin
>>           sigout.next = tmp
>>
>>       return logic
>
> The author did a poor job picking their examples.  I say
> this because I don't think their VHDL example is correct,
> either.  They don't provide enough information but for the
> VHDL example to be correct the instantiator would need to
> take care of the output word size to handle the bit growth
> as a result of the multiplies and additions (or limit the
> input range).  I think if they would have verified the VHDL
> they would have found the VHDL implementation did not meet
> their requirements (or any requirements for a FIR filter).
>
> Also, I don't think the author provides the description of
> the RAM/ROM for the coefficients in the VHDL example.  The
> VHDL example is not a fair comparison because it would need
> additional description, somewhere, to define the coefficient
> array.  Where as the MyHDL version the coefficient array
> description is embedded!
>
> Here is my version of the FIR filter in MyHDL that matches
> the simplified templated:
>
>      from myhdl import *
>      def firfilt(sig_in, sig_out, coef, clk):
>          buffer = [Signal(intbv(0, min=sig_in.min, max=sig_in.max)) \
>                    for ii in range(len(coef))]
>          coef = tuple(coef)
>          mshift = len(sig_in)-1
>          @always(clk.posedge)
>          def hdl_sop():
>              sop = 0
>              # Note this adds an extra delay! (Group delay N/2+2)
>              for ii in range(len(coef)):
>                  buffer[ii].next = sig_in if ii == 0 else buffer[ii-1]
>                  c = coef[ii]
>                  sop = sop + (buffer[ii] * c)
>              sig_out.next = (sop >> mshift)
>
>          return hdl_sop
>

i just tried to run the converted vhdl through quartus and it came up with  
the following error:

	Error (10500): VHDL syntax error at firfilt.vhd(39) near text "when";   
expecting ";"

hm.. maybe its not supported in a clocked process but i am not so sure i  
have to look at that closer.
the next error after i changed to a normal if i got:

	Error (10405): VHDL error at firfilt.vhd(78): can't determine type of  
object at or near identifier "shift_right" -- found 0 possible types




Note: I changed buffer to bufferVal because it is a reserved keyword in  
vhdl



My version with the initial values would look like this:

   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 = 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] * coefs[ii])
	  sig_out.next = (sop >> mshift)

       return hdl_sop

but there is still the shift error.


greetings
Norbo

Re: [myhdl-list] Lists of signals now do appear in vcd file

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

On 06/27/2012 08:14 PM, Christopher Felton wrote:
> On 6/27/2012 12:15 PM, Jan Decaluwe wrote:
>> I am considering to incorporate this feature more
>> or less as per this patch.
>>
>> I don't want to create a different function - this
>> could be a configuration of traceSignals.
>>
>> One question: should I make memory tracing optional?
>> Or is it something that people just will always
>> want to use when available?
>>
>> Jan
>>
>>
>
> I vote always on.
>
> If it were to be optional, I believe the use case is when modeling large
> memories.  For a larger memory you might not want the overhead.  In this
> case I would want a method to disable only for a particular LoS and not
> all LoS.  My main use case for LoS is not to model RAM or ROM but for
> modularity.

I have implemented it such that it is on by default,
and controlled by setting 'traceSignals.tracelists'.
Only in 0.8-dev, this qualifies as a new feature instead
of a bug.

-- 
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] Lists of signals now do appear in vcd file

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

On 6/27/2012 12:15 PM, Jan Decaluwe wrote:
> I am considering to incorporate this feature more
> or less as per this patch.
>
> I don't want to create a different function - this
> could be a configuration of traceSignals.
>
> One question: should I make memory tracing optional?
> Or is it something that people just will always
> want to use when available?
>
> Jan
>
>

I vote always on.

If it were to be optional, I believe the use case is when modeling large 
memories.  For a larger memory you might not want the overhead.  In this 
case I would want a method to disable only for a particular LoS and not 
all LoS.  My main use case for LoS is not to model RAM or ROM but for 
modularity.

Regards,
Chris

Re: [myhdl-list] Lists of signals now do appear in vcd file

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

I am considering to incorporate this feature more
or less as per this patch.

I don't want to create a different function - this
could be a configuration of traceSignals.

One question: should I make memory tracing optional?
Or is it something that people just will always
want to use when available?

Jan


On 03/28/2012 09:52 PM, Frederik T. wrote:
> Hello everybody,
>
> I just had a look into _traceSignals.py . I wrote a few lines to write
> flattened memories into the vcd file. The vcd standard does not support
> multidimensional arrays. You can see it in the attached screenshot.
>
> If you have a signal like
>
> ram = [Signal(intbv(0, max=LMAX, min=-LMAX)) for i in range(N)]
>
> the list items now appear as ram(0), ram(1), .. , ram(N-1) in the vcd file.
>
> I attached a patch and the patched files, too.
>
> It would be nice if you could test this code on your designs. If there
> might be any problems or there are any please report them to me.
>
> This patch announces a new trace option called
> "traceSignalsAndMemories". If you use "traceSignals" no memories are dumped.
>
> Example:
>
> # The normal trace
> tb = traceSignals(testBenchDut)
> sim = Simulation(tb)
> sim.run()
>
> # can be changed to
> tb = traceSignalsAndMemories(testBenchDut)
> sim = Simulation(tb)
> sim.run()
> # .. to trace the memories as well.
>
> It works with both the stable 0.7-version and the version from the
> repository.
>
>
> Happy debugging,
>
> Frederik
>
>
> Am 28.03.2012 15:08, schrieb Oscar Diaz:
>> 2012/3/28 Frederik T.<sp...@ne...>:
>>> Hello Oscar,
>>>
>>> that sounds great. I would test it, if it would help you.
>>
>> This is a "very" preliminary version of signal_monitor, a class to
>> generate vcd files in myhdl. As you can guess, it has little
>> documentation (sorry for that) and probably needs a lot of adjustments
>> and improvements. Feel free to test it and send me any suggestions,
>> doubts or even complains about it. I'll try to finish it ASAP and
>> upload in the myhdl wiki (or somewhere else if needed).
>>
>> I hope this helps you or anyone on the mail list.
>>
>> Best regards
>>
>>>
>>>
>>> Regards,
>>>
>>> Frederik
>>>
>>> Am 28.03.2012 13:28, schrieb Oscar Diaz:
>>>> 2012/3/27 Christopher Felton<chr...@gm...>:
>>>>> On 3/27/2012 9:43 AM, Frederik T. wrote:
>>>>>> Hello everybody,
>>>>>>
>>>>>> I have a question concerning lists of signals. Whenever I use a list of
>>>>>> signals I don't see they don't appear in the vcd file created by
>>>>>> traceSignals(), see gtkwave.png .
>>>>>>
>>>>>
>>>>> That is correct, currently a "List of Signals" is not traced with
>>>>> traceSignals.
>>>>
>>>> I had this problem a couple months ago, and I make a custom vcd
>>>> generator that adds manually the signals that you need, assuming you
>>>> had the references to the desired signals (and it supports lists and
>>>> dicts of signals). The main idea is to make an object that returns
>>>> generators that react to traced signals and generate the vcd file. It
>>>> is completely unrelated to traceSignals function.
>>>>
>>>> It works for my needs but I'm afraid it needs refactoring. I can send
>>>> my code if you need it, anyway I'm planning to fix it, upload
>>>> somewhere and receive feedback on the list.
>>>>
>>>> As soon I fix it I'll announce it on the list.
>>>>
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF email is sponsosred by:
>>>>> Try Windows Azure free for 90 days Click Here
>>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>>> _______________________________________________
>>>>> myhdl-list mailing list
>>>>> myh...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>>>
>>>> Best regards
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>>
>>
>>
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


-- 
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] Summary of "Initial Values Support" threads

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

On 6/15/12 4:12 AM, Jan Decaluwe wrote:
> On 05/30/2012 06:47 AM, Christopher Felton wrote:
>> We listed a summary a couple time but the initial value support (ivs)
>> was embedded in a separate thread.  So, I thought it would be worth
>> while to summarize in a new thread.
>>
>>
>>      1.  Initial value support can be re-enabled.  The Verilog
>>          support of initial values as verified with the latest
>>          of Quartus.
>>          Need to test with (list syn and sim tools)?
>>            [x] Quartus latest
>>            [ ] ISE (xst) latest
>>            [ ] cver
>>            [ ] icarus
>
> Ok, perhaps make a page on the site to keep track
> of the status.
>

I created a wiki page and essentially copied the latest summary to the 
wiki page, it is a little rough right now.

http://www.myhdl.org/doku.php/dev:initial_values

Regards,
Chris

Re: [myhdl-list] Reset functionality "synthesis"

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

<snip>
>>>
>>> Feedback welcome!
>>>
>>
>> Haven't thought this fully through but would it be better
>> to have the /reset/ properties passes as arguments to the
>> decorator or properties of the Signal?  Example if properties
>> used:
>>
>>        reset = Signal(False)
>>        reset.level = 0
>>        reset.async = True
>>
>>        @always_ff(clock.posedge, reset=reset)
>>
>> The property defaults would be the same as you stated.
>
> Seems a very good idea. Perhaps even introduce a
> Signal subclass, ResetSignal, to set the properties
> at construction time and allow type checking in the
> always_ff decorator:
>
> reset = ResetSignal(0, active=0, async=True) # defaults shown

That seems very reasonable, I like it.  This should be a
pretty cool addition!

Regards,
Chris

Re: [myhdl-list] Simplifying Interfaces

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

On 6/26/12 7:23 AM, Christopher Felton wrote:
> On 6/25/2012 3:30 AM, Wesley New wrote:
>> Firstly, thanks for Chris for bringing this feature to light. It is
>> definitely one I will employ.
>>
>> The only problem I am having is that the ports arent expanded out when I am
>> using user-defined hdl.
>> As it isnt creating a flat file, the wrapper doesnt have any wishbone ports.
>>
>> For instance see the attached file.
>>
>> Initially all I wish to do is to encapsulate the wishbone ports so that I
>> dont have to type them every time I instantiate a module that has a
>> wishbone interface
>>
>> Regards
>>
>> Wesley
>>
>
>
> You would not be able to use the "object" on the top-level.  The outside
> world (your Verilog or VHDL) wouldn't know how to interface to a /wb/.
> The top-level has to be the discrete signals everything inside can use
> the /wb/ to simplify the interface.
>
> I haven't tested it with the user defined code, you might have to do and
> extra step, but it should be possible.
>
> Regards,
> Chris
>

I added an example that I believe does what you are trying to do.

https://bitbucket.org/cfelton/examples/src/tip/stitch

The example is a little redonkulous right now, lot of top-level ports 
that are not used.  The top-levels will always need to be the individual 
signals (best of my knowledge) don't think it is reasonable that the 
top-level can be something else.

Regards,
Chris

Re: [myhdl-list] Simplifying Interfaces

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

On 6/22/2012 10:24 AM, Jan Decaluwe wrote:
> Hi:
>
> I don't follow the example completely, but if you  -
> an experienced MyHDL designer - are surprized, then
> others will be even more so.
>
> I wonder if we can come up with an example suited for
> the MyHDL by Example section, that demonstrates the power
> of these techniques.
>
> The message should be that conversion only deals with
> code inside generators, in the context of their namespaces.
> Conversion restrictions only apply to that code.
> The namespaces are created during elaboration, so it
> doesn't matter how.
>

I have been trying to think of a good example, an example that isn't too 
large (too much code to dig through for a cookbook example) and an 
example that fits nicely, I haven't come up with too many ideas.

One example that appears to be used heavily with VHDL records and SV 
structs is a simple {opcode, address, flags} bundling.  But this example 
on its own wouldn't be functional, it wouldn't do anything.

It would be nice to have a small example that does something, I am 
failing to think of a good example.

Anyone else have an idea for an example?  I think for the example to be 
useful, you would want a design that you would use multiple modules and 
have some interface between.  But the interface would be small (limited 
number of signals in the class) so the the example would be digestible.

Regards,
Chris