myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Testbench Template

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

On 7/31/12 10:50 PM, Christopher Felton wrote:
> I have been using a simple testbench template
> for small single module tests.  I use this testbench
> template so that I can quickly add basic test stimulus
> to a module.  From the testbench I can do operations
> that require similar setup.
>
>    >> python test_.py trace
>    >> python test_.py convert
>    >> python test_.py cosim
>
> Note, I usually have a more complicated test environment
> (only as complicated as needed and no more) for full
> designs.  In addition to the *full* verification
> environment I typically have individual module tests
> that use the template.
>
> I attached the template and an example using a simple
> adder.  Might be useful (might not).  Feel free to
> comment, always room for improvement.  This is a
> template that needs to be manually modified and uses
> some features only available in 0.8dev branch.
>
> Regards,
> Chris
>
>

I modified the /testbench/ template to be a class
which is more reusable.  Also, used the Python
argparser for the command line options.


Using the same example as the previous post the
CLI is:

    python test_myadder.py -h
    usage: test_myadder.py [-h] [--trace] [--cosim] [--convert]
                           [-Tclk CLOCK_PERIOD]

    Testbench

    optional arguments:
      -h, --help            show this help message and exit
      --trace               enable testbench tracing (create VCD file)
      --cosim               run cosimulation
      --convert             convert the module
      -Tclk CLOCK_PERIOD, --clock_period CLOCK_PERIOD
                            set the clock period

Again, this is intended to streamline the creation
of tests for small single module designs.

Regards,
Chris

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

[Frederik T. <f...@ne...>]

You're welcome.


Kind regards,

Frederik Teichert


Am 13.07.2012 00:33, schrieb Christopher Felton:
> On 6/27/2012 4:40 PM, Jan Decaluwe wrote:
>> 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.
>>
> 
> Just wanted to say, this is a really nice feature!  Thanks
> to Frederik and Jan D. for adding this feature!  It is nice,
> in gtkwave you can create a group of the explicit LoS and
> open/close (expand/hide) with a 'T'.
> 
> Regards,
> Chris
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

[myhdl-list] Testbench Template

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

I have been using a simple testbench template
for small single module tests.  I use this testbench
template so that I can quickly add basic test stimulus
to a module.  From the testbench I can do operations
that require similar setup.

   >> python test_.py trace
   >> python test_.py convert
   >> python test_.py cosim

Note, I usually have a more complicated test environment
(only as complicated as needed and no more) for full
designs.  In addition to the *full* verification
environment I typically have individual module tests
that use the template.

I attached the template and an example using a simple
adder.  Might be useful (might not).  Feel free to
comment, always room for improvement.  This is a
template that needs to be manually modified and uses
some features only available in 0.8dev branch.

Regards,
Chris

Re: [myhdl-list] ROMs and Init'd RAMs

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

<snip>
>>
>> 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.
<snip>

We have had a couple threads on this and I created a wiki
page [1] to keep track of the /initial value support/ progress,
comments, and opinions.  The ROM/RAM is closely related
(pre-init ram).  I think the biggest hurdle is resolving
the options for automatic memory synthesis, mainly for FPGAs,
that may not map to other synthesis technologies.

Currently, the /case/ statements for ROM will work in any
technology but will only be an optimized memory structure
in the Xilinx tools.  The Altera tools will not extract a ROM.
It has been requested that initial values for list of signals
be created.  The FPGA tools (at least Altera) creates a
configuration file to pre-init the BRAMs.

We had discussed adding function attributes for conversion
configuration.  We discussed adding an attribute to disable
initial value creation.

   toVerilog.disable_init
   toVHDL.disable_init

I believe, but I didn't list it in the wiki, we also discussed
adding an attribute to enable list of signals initial values.

   toVerilog.enable_list_init
   toVHDL.enable_list_init

If this makes sense, I believe we have the options covered.
The tuple of ints will be converted as is, and a list of signals
can be configured to create the array (list of signals) initial
values using the VHDL function and Verilog initial block as
previously discussed.

Regards,
Chris

[1] http://www.myhdl.org/doku.php/dev:initial_values

Re: [myhdl-list] cosimulation question

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

On 7/31/12 1:24 PM, Geoffrey Brown wrote:
> When cosimulating (icarus) if I include the following in my test bench
>
> raise StopSimulation
>
> I get the following annoying message:
>
>
> Exception AttributeError: "'NoneType' object has no attribute
> '_cosim'" in <bound method Cosimulation.__del__ of
> <myhdl._Cosimulation.Cosimulation object at 0x1040db690>> ignored
>
>
> It's not fatal, but I'm doing something wrong.
>
> Geoffrey
>

Are you using version 0.7 or the latest from the
development branch?  I run Cosimulation frequently
with cvc, mti, and ncsim.  I haven't noticed the
above error.

Strange timing, last night I was going to post a
simply "testbench" template I use for small modules
(never hit send).  I will post it shortly, will test
the cosim see if I get a similar error with icarus.

Regards,
Chris

[myhdl-list] cosimulation question

[Geoffrey B. <geo...@gm...>]

When cosimulating (icarus) if I include the following in my test bench

raise StopSimulation

I get the following annoying message:


Exception AttributeError: "'NoneType' object has no attribute
'_cosim'" in <bound method Cosimulation.__del__ of
<myhdl._Cosimulation.Cosimulation object at 0x1040db690>> ignored


It's not fatal, but I'm doing something wrong.

Geoffrey

[myhdl-list] cosimulation question

[Geoffrey B. <geo...@in...>]

When cosimulating (icarus) if I include the following in my test bench

raise StopSimulation

I get the following annoying message:


Exception AttributeError: "'NoneType' object has no attribute
'_cosim'" in <bound method Cosimulation.__del__ of
<myhdl._Cosimulation.Cosimulation object at 0x1040db690>> ignored


It's not fatal, but I'm doing something wrong.

Geoffrey

Re: [myhdl-list] Conversion for variable argument list

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

On 07/18/2012 02:23 PM, Oscar Diaz wrote:
> Hi
>
> Suppose I want to design a cascade adder of several number of inputs,
> for instance, a 3-input adder consists of two 2-input adders connected
> in cascade, a 4-input adder will have three 2-input adders, and so on.
> The tricky part is I won't know the number of inputs I need until
> runtime.
>
> It really doesn't matter for me how to implement it internally, my
> problem is how to declare the argument list to accept a "variable
> number" of input values, and I would like a VHDL (or Verilog) code
> that reflects the correct number of inputs.
>
> My first approach was to use variable argument list:
>
> def variable_adder(output, *inputs):
>
> Works fine for simulation, fails for conversion.

Only if it's at the top-level, which is probably not
how you will use it in a real design.

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

[myhdl-list] Conversion for variable argument list

[Oscar D. <osc...@gm...>]

Hi

Suppose I want to design a cascade adder of several number of inputs,
for instance, a 3-input adder consists of two 2-input adders connected
in cascade, a 4-input adder will have three 2-input adders, and so on.
The tricky part is I won't know the number of inputs I need until
runtime.

It really doesn't matter for me how to implement it internally, my
problem is how to declare the argument list to accept a "variable
number" of input values, and I would like a VHDL (or Verilog) code
that reflects the correct number of inputs.

My first approach was to use variable argument list:

def variable_adder(output, *inputs):

Works fine for simulation, fails for conversion. I'm wonder if there's
any way to dynamically declare the component interface, or if there's
a better idea to dynamically instantiate components (I really don't
like the idea of declare each one of "variable_adder2",
"variable_adder3", etc. in MyHDL).

In case of this approach are proved wrong, I already though on some
workarounds for this precise example:

1. Put a fixed number of inputs (say 10 for example) and ignore unused
inputs that will be trimmed in synthesis stage.
2. Put a single input bit_vector and slice it internally depending on
number of inputs (this idea is my best bet).

My intention is to see if the idea of elaboration can be applied (or
if it make sense) to the signal interface.

I attach a example with the tests I've been working on.

Best regards

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] No proper edge value test

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

On 7/18/2012 6:24 AM, Jan Decaluwe wrote:
> On 07/18/2012 05:05 AM, Christopher Felton wrote:
>> With the latest 0.8dev code the following will cause
>> a "No proper edge value test"
>>
>>       def testm(clock, reset, out):
>>           @always(clock.posedge, reset.negedge)
>>           def hdl():
>>               if not reset:
>>                   out.next = 0
>>               else:
>>                   out.next = out ^ 0x55
>>
>>           return hdl
>>
>>       def convert():
>>           clock = Signal(False)
>>           reset = Signal(False)
>>           out   = Signal(intbv(0)[8:])
>>           toVerilog(testm, clock, reset, out)
>>           toVHDL(testm, clock, reset, out)
>>
>>
>> Is this expected behavior?  This could possibly break
>> existing code.
>
> Don't think so - same in 0.7.
>
> Yes, I would call it expected behavior. A reset should
> check on a value - giving it a logical interpretation
> can only lead to confusion. (As here, where 'not reset'
> checks for an active reset.)
>

Ahh, I didn't describe the observed issue correctly.  It
is the difference between toVerilog and toVHDL.  Not a
difference between revisions, toVerilog will accept the
above toVHDL will error.

And both will accept

    ...
    if reset
    ...

In the past I had only used toVerilog and when I added
a toVHDL, I mistakenly thought it might have been a
change in behavior due to recent changes.

Regards,
Chris

Re: [myhdl-list] No proper edge value test

[Oscar D. <osc...@gm...>]

2012/7/18 Jan Decaluwe <ja...@ja...>:
> On 07/18/2012 05:05 AM, Christopher Felton wrote:
>> With the latest 0.8dev code the following will cause
>> a "No proper edge value test"
>>
>>       def testm(clock, reset, out):
>>           @always(clock.posedge, reset.negedge)
>>           def hdl():
>>               if not reset:
>>                   out.next = 0
>>               else:
>>                   out.next = out ^ 0x55
>>
>>           return hdl
>>
>>      def convert():
>>          clock = Signal(False)
>>          reset = Signal(False)
>>          out   = Signal(intbv(0)[8:])
>>          toVerilog(testm, clock, reset, out)
>>          toVHDL(testm, clock, reset, out)
>>
>>
>> Is this expected behavior?  This could possibly break
>> existing code.
>
> Don't think so - same in 0.7.
>
> Yes, I would call it expected behavior. A reset should
> check on a value - giving it a logical interpretation
> can only lead to confusion. (As here, where 'not reset'
> checks for an active reset.)

I also checked it (both in 0.7 and 0.8dev). I noticed that it only
fails for VHDL conversion (Verilog works fine). Changing the condition
to "reset == 0" or "reset == False" solves the problem.

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



-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] No proper edge value test

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

On 07/18/2012 05:05 AM, Christopher Felton wrote:
> With the latest 0.8dev code the following will cause
> a "No proper edge value test"
>
>       def testm(clock, reset, out):
>           @always(clock.posedge, reset.negedge)
>           def hdl():
>               if not reset:
>                   out.next = 0
>               else:
>                   out.next = out ^ 0x55
>
>           return hdl
>
>      def convert():
>          clock = Signal(False)
>          reset = Signal(False)
>          out   = Signal(intbv(0)[8:])
>          toVerilog(testm, clock, reset, out)
>          toVHDL(testm, clock, reset, out)
>
>
> Is this expected behavior?  This could possibly break
> existing code.

Don't think so - same in 0.7.

Yes, I would call it expected behavior. A reset should
check on a value - giving it a logical interpretation
can only lead to confusion. (As here, where 'not reset'
checks for an active reset.)

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

[myhdl-list] No proper edge value test

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

With the latest 0.8dev code the following will cause
a "No proper edge value test"

     def testm(clock, reset, out):
         @always(clock.posedge, reset.negedge)
         def hdl():
             if not reset:
                 out.next = 0
             else:
                 out.next = out ^ 0x55

         return hdl

    def convert():
        clock = Signal(False)
        reset = Signal(False)
        out   = Signal(intbv(0)[8:])
        toVerilog(testm, clock, reset, out)
        toVHDL(testm, clock, reset, out)


Is this expected behavior?  This could possibly break
existing code.

Regards,
Chris

Re: [myhdl-list] Keeping hierarchy for conversion

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

>>
>
> I'm sorry to "bring back" previous discussions (I hope I'm not
> reviving past flames), but since I've been studying the conversion
> code, I'm ready to put better arguments (and code) to solve this
> pending issue. And, as I was saying, personally I really need this
> feature for my projects.
>
>>

I don't see any issues re-visiting features/issues.  But I
did want you to be aware of past conversations.  I don't think
there were any flames previously(?).  I don't believe anyone
would object to a keep_hier in theory but in practice it is a
little different.

Regards,
Chris

Re: [myhdl-list] Keeping hierarchy for conversion

[Oscar D. <osc...@gm...>]

2012/7/17 Christopher Felton <chr...@gm...>:
> This topic has popped up from time to time.  I haven't
> had time to read your post thoroughly but I wanted to
> bring attention to some old posts, in case you were
> unaware of them, that discuss this topic.
>
> http://thread.gmane.org/gmane.comp.python.myhdl/1484
> http://thread.gmane.org/gmane.comp.python.myhdl/1484/focus=1488
> http://thread.gmane.org/gmane.comp.python.myhdl/2019

Oops, my fault, I didn't check past posts deep enough. I agree my
first reason for hierarchy keeping can be easily solved by
user-defined code (mea culpa, I'll withdraw that example). However,
for my second example I should remembered saying floor-planning,
because this is a more general motivation for this proposal (and right
now it's very difficult to do floor-planning with MyHDL).

>
> In an ideal world it would probably be nice to have
> an option to keep hierarchy but I think there a many
> technical obstacles that make it impractical(?).  As
> discussed in the first thread the two step approach
> is required.  I don't know if the two step approach
> could be generalized to a single function call.

I implemented something similar to that "two step" approach: first
iterate through available sub-components, do toVHDL() for each one of
them, and then generate the top module. Of course, I assume my design
as structural at the top, and next sub-components are converted in the
usual way. However, I think it's possible to extend it for complex
hierarchies.

Don't misunderstand me, IMHO flattening hierarchy is one of the most
powerful feature of MyHDL because I can do very sophisticated things
in elaboration. But, after my recent experience, I advocate for
"selective" hierarchy keeping; for instance, a top module with several
sub-components, in a one-level-deep hierarchy. This top module could
be marked with a function attribute (something like
"topmodule.keep_hierarchy=True") that instructs the converter to walk
through sub-components, call normal converter for each of them and
finally do component instantiation and port mappings. That's the
reason I thought on a separate function for this kind of conversion.

>

I'm sorry to "bring back" previous discussions (I hope I'm not
reviving past flames), but since I've been studying the conversion
code, I'm ready to put better arguments (and code) to solve this
pending issue. And, as I was saying, personally I really need this
feature for my projects.

>
> Regards,
> Chris
>
> On 7/17/2012 1:23 PM, Oscar Diaz wrote:
>> Hi
>>
>> I want to start a discussion about keeping the hierarchy on conversion
>> and how to implement. Although flattening feature of current converter
>> is a nice "killer feature", I can provide couple examples which it's
>> needed to keep hierarchy inside a design:
>>
>> 1. Special instances on an FPGA: suppose you need an special component
>> (my experience is limited to Xilinx, I guess Altera and other vendors
>> had similar features), for instance a block RAM. Sometimes I need to
>> explicitly use a block RAM in a particular configuration, I know
>> exactly how to instantiate it in VHDL, and I can write a MyHDL
>> equivalent model for simulation. However, when converting, it is
>> difficult to write code that synthesizer use to infer a block RAM. And
>> for other special components it can be worse (ICAP, PLL, DCM, and
>> others).
>>
>> 2. Partial re-configuration [1]: design tools can work only with
>> structural descriptions because it needs complete information about
>> boundary signals between sub-modules. A converted MyHDL design only
>> has a top module with all the sub-modules flattened in multiple
>> process (or always blocks in Verilog).
>>
>> It's worth mention that, for the previous examples, it's explicit
>> stated the need to keep hierarchy, and those components will be
>> instantiated in the nearest-top component (I mean, in VHDL it will be
>> some component declarations, instantiations and port mappings).
>>
>> Now the question is: how to implement it? I've been thinking and
>> working on it for a long time, and those are some of my thoughts
>> (disclaimer: since I'm more accustomed to VHDL to Verilog, I'll give
>> only examples with VHDL, Verilog should be somehow alike):
>>
>> * Current converter rely on flattening the structure before do actual
>> conversion. Perhaps a different function is convenient/needed here?
>> something like "toVHDL_keep_hierarchy()" can run through the
>> hierarchical structure and call toVHDL() for its internal components.
>> This is "relatively" easy to implement in the case of simple
>> hierarchies (for instance, a top module with sub-components), but
>> mixed "keep-hierarchy" components with "normal" components could be
>> tricky without deep changes to converter code (something probably not
>> desirable right now).
>>
>> * Internally, converter needs to generate a separate output file for
>> that component and also need component declarations to put in that
>> file. Perhaps a function that infer the external interface of a
>> component is needed, something that toVHDL() already do internally to
>> generate the entity declaration, and would be nice to move to another
>> function for this purpose.
>>
>> * user-defined code, if used, must declare almost the entire code
>> (interface declaration is inferred from the call signature). Other
>> option is point to an external file, and in this case, its interface
>> must match the call signature.
>>
>> Since I was in a hurry to have "keep hierarchy" feature in my
>> projects, I wrote a custom converter, but it's tightly coupled to my
>> specific designs (for instance, I use objects instead of functions to
>> declare components, and my converter looks through those specific
>> objects and its attributes. Also, there's a separate mechanism for
>> interface declaration). However, I want to decouple that code for
>> general use, and I want to hear your opinions.
>>
>> Best regards, Oscar
>>
>> PD: <spam warning> Part of the code I mentioned is part of a
>> open-source project I've been working in, and I think now I can
>> present it to the list. Its called NoCModel, and it's available on
>> github (https://github.com/dargor0/nocmodel), also I keep a copy on
>> opencores. </spam>
>>
>> [1] http://en.wikipedia.org/wiki/Partial_re-configuration
>>
>
>
>
>
> ------------------------------------------------------------------------------
> 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



-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Keeping hierarchy for conversion

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

This topic has popped up from time to time.  I haven't
had time to read your post thoroughly but I wanted to
bring attention to some old posts, in case you were
unaware of them, that discuss this topic.

http://thread.gmane.org/gmane.comp.python.myhdl/1484
http://thread.gmane.org/gmane.comp.python.myhdl/1484/focus=1488
http://thread.gmane.org/gmane.comp.python.myhdl/2019

In an ideal world it would probably be nice to have
an option to keep hierarchy but I think there a many
technical obstacles that make it impractical(?).  As
discussed in the first thread the two step approach
is required.  I don't know if the two step approach
could be generalized to a single function call.

Regards,
Chris

On 7/17/2012 1:23 PM, Oscar Diaz wrote:
> Hi
>
> I want to start a discussion about keeping the hierarchy on conversion
> and how to implement. Although flattening feature of current converter
> is a nice "killer feature", I can provide couple examples which it's
> needed to keep hierarchy inside a design:
>
> 1. Special instances on an FPGA: suppose you need an special component
> (my experience is limited to Xilinx, I guess Altera and other vendors
> had similar features), for instance a block RAM. Sometimes I need to
> explicitly use a block RAM in a particular configuration, I know
> exactly how to instantiate it in VHDL, and I can write a MyHDL
> equivalent model for simulation. However, when converting, it is
> difficult to write code that synthesizer use to infer a block RAM. And
> for other special components it can be worse (ICAP, PLL, DCM, and
> others).
>
> 2. Partial re-configuration [1]: design tools can work only with
> structural descriptions because it needs complete information about
> boundary signals between sub-modules. A converted MyHDL design only
> has a top module with all the sub-modules flattened in multiple
> process (or always blocks in Verilog).
>
> It's worth mention that, for the previous examples, it's explicit
> stated the need to keep hierarchy, and those components will be
> instantiated in the nearest-top component (I mean, in VHDL it will be
> some component declarations, instantiations and port mappings).
>
> Now the question is: how to implement it? I've been thinking and
> working on it for a long time, and those are some of my thoughts
> (disclaimer: since I'm more accustomed to VHDL to Verilog, I'll give
> only examples with VHDL, Verilog should be somehow alike):
>
> * Current converter rely on flattening the structure before do actual
> conversion. Perhaps a different function is convenient/needed here?
> something like "toVHDL_keep_hierarchy()" can run through the
> hierarchical structure and call toVHDL() for its internal components.
> This is "relatively" easy to implement in the case of simple
> hierarchies (for instance, a top module with sub-components), but
> mixed "keep-hierarchy" components with "normal" components could be
> tricky without deep changes to converter code (something probably not
> desirable right now).
>
> * Internally, converter needs to generate a separate output file for
> that component and also need component declarations to put in that
> file. Perhaps a function that infer the external interface of a
> component is needed, something that toVHDL() already do internally to
> generate the entity declaration, and would be nice to move to another
> function for this purpose.
>
> * user-defined code, if used, must declare almost the entire code
> (interface declaration is inferred from the call signature). Other
> option is point to an external file, and in this case, its interface
> must match the call signature.
>
> Since I was in a hurry to have "keep hierarchy" feature in my
> projects, I wrote a custom converter, but it's tightly coupled to my
> specific designs (for instance, I use objects instead of functions to
> declare components, and my converter looks through those specific
> objects and its attributes. Also, there's a separate mechanism for
> interface declaration). However, I want to decouple that code for
> general use, and I want to hear your opinions.
>
> Best regards, Oscar
>
> PD: <spam warning> Part of the code I mentioned is part of a
> open-source project I've been working in, and I think now I can
> present it to the list. Its called NoCModel, and it's available on
> github (https://github.com/dargor0/nocmodel), also I keep a copy on
> opencores. </spam>
>
> [1] http://en.wikipedia.org/wiki/Partial_re-configuration
>

[myhdl-list] Keeping hierarchy for conversion

[Oscar D. <osc...@gm...>]

Hi

I want to start a discussion about keeping the hierarchy on conversion
and how to implement. Although flattening feature of current converter
is a nice "killer feature", I can provide couple examples which it's
needed to keep hierarchy inside a design:

1. Special instances on an FPGA: suppose you need an special component
(my experience is limited to Xilinx, I guess Altera and other vendors
had similar features), for instance a block RAM. Sometimes I need to
explicitly use a block RAM in a particular configuration, I know
exactly how to instantiate it in VHDL, and I can write a MyHDL
equivalent model for simulation. However, when converting, it is
difficult to write code that synthesizer use to infer a block RAM. And
for other special components it can be worse (ICAP, PLL, DCM, and
others).

2. Partial re-configuration [1]: design tools can work only with
structural descriptions because it needs complete information about
boundary signals between sub-modules. A converted MyHDL design only
has a top module with all the sub-modules flattened in multiple
process (or always blocks in Verilog).

It's worth mention that, for the previous examples, it's explicit
stated the need to keep hierarchy, and those components will be
instantiated in the nearest-top component (I mean, in VHDL it will be
some component declarations, instantiations and port mappings).

Now the question is: how to implement it? I've been thinking and
working on it for a long time, and those are some of my thoughts
(disclaimer: since I'm more accustomed to VHDL to Verilog, I'll give
only examples with VHDL, Verilog should be somehow alike):

* Current converter rely on flattening the structure before do actual
conversion. Perhaps a different function is convenient/needed here?
something like "toVHDL_keep_hierarchy()" can run through the
hierarchical structure and call toVHDL() for its internal components.
This is "relatively" easy to implement in the case of simple
hierarchies (for instance, a top module with sub-components), but
mixed "keep-hierarchy" components with "normal" components could be
tricky without deep changes to converter code (something probably not
desirable right now).

* Internally, converter needs to generate a separate output file for
that component and also need component declarations to put in that
file. Perhaps a function that infer the external interface of a
component is needed, something that toVHDL() already do internally to
generate the entity declaration, and would be nice to move to another
function for this purpose.

* user-defined code, if used, must declare almost the entire code
(interface declaration is inferred from the call signature). Other
option is point to an external file, and in this case, its interface
must match the call signature.

Since I was in a hurry to have "keep hierarchy" feature in my
projects, I wrote a custom converter, but it's tightly coupled to my
specific designs (for instance, I use objects instead of functions to
declare components, and my converter looks through those specific
objects and its attributes. Also, there's a separate mechanism for
interface declaration). However, I want to decouple that code for
general use, and I want to hear your opinions.

Best regards, Oscar

PD: <spam warning> Part of the code I mentioned is part of a
open-source project I've been working in, and I think now I can
present it to the list. Its called NoCModel, and it's available on
github (https://github.com/dargor0/nocmodel), also I keep a copy on
opencores. </spam>

[1] http://en.wikipedia.org/wiki/Partial_re-configuration

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

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

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

On 6/27/2012 4:40 PM, Jan Decaluwe wrote:
> 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.
>

Just wanted to say, this is a really nice feature!  Thanks
to Frederik and Jan D. for adding this feature!  It is nice,
in gtkwave you can create a group of the explicit LoS and
open/close (expand/hide) with a 'T'.

Regards,
Chris

Re: [myhdl-list] Architecture Modelling with MyHDL

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

<snip>
>>
>>
>>      We can now perform pretty complicated concurrent simulations with this
>>      circular buffer, such as connect each side to a different clock - as
>>      demonstrated in the attached test.py.
>
> This is probably quite obvious so please forgive me if this question
> is very basic. I don't understand how can you directly call
> "super(HCBuff, self).write(din.val)", since in the original write
> method self.wr_off is incremented directly, rather than using
> self.wr_off.next (which is not possible since self.wr_off is not a
> signal). A similar problem occurs with the read method.
>
> What am I missing?
>
> Angel
>

In this case the two instance variables wr_off and rd_off
don't need to be signals (they don't signal anything) they
are just local variables that keep track of some state.
The only time super(CBuff,self).write and super(CBuff,self).read
do something is when they are explicitly called.

The example takes an "algorithm" and then wraps an interface
that looks like a module, in this case the interface is
a clock and data.  As mentioned, this is good for a "golden"
models.  You can verify the "algorithm" via standard
imperative programming, write, read, write, write, read.  You
have a set of statements you can see what happens.  And then
you can add the interface adapters to get a cycle accurate
model and compare the actual implementation to the "golden" model.

Regards,
Chis

Re: [myhdl-list] Architecture Modelling with MyHDL

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

On Mon, Jul 9, 2012 at 9:45 PM, Uri Nix <ur...@gm...> wrote:
> Hi all,
>
>     I would like to focus a bit on MyHDL's modelling abilities, using a
> simple
>     example to demonstrate an effective development flow.
>
>     Let's consider a circular buffer, implemented as a pure algorithm.
>
> class CBuff(object):
>     def __init__(self, size):
>         self.ram = array.array('B', [0]*size)
>         self.modulo = size
>         self.rd_off = 0
>         self.wr_off = 0
>
>     def write(self, value):
>         self.ram[self.wr_off] = value
>         self.wr_off += 1
>         if self.wr_off >= self.modulo: self.wr_off = 0
>
>     def read(self):
>         value = self.ram[self.rd_off]
>         self.rd_off += 1
>         if self.rd_off >= self.modulo: self.rd_off = 0
>         return value
>
>
>     After fully testing this algorithm, we can add a measure of hardware
>     orientation by making the accesses synchronous (using the same method
>     names, but that of course is a matter of taste):
>
> class HCBuff(CBuff):
>     def write(self, clk, din):
>         @always(clk.posedge)
>         def logic():
>             super(HCBuff, self).write(din.val)
>         return logic
>
>     def read(self, clk, dout):
>         @always(clk.posedge)
>         def logic():
>             dout.next = super(HCBuff, self).read()
>         return logic
>
>
>     We can now perform pretty complicated concurrent simulations with this
>     circular buffer, such as connect each side to a different clock - as
>     demonstrated in the attached test.py.

This is probably quite obvious so please forgive me if this question
is very basic. I don't understand how can you directly call
"super(HCBuff, self).write(din.val)", since in the original write
method self.wr_off is incremented directly, rather than using
self.wr_off.next (which is not possible since self.wr_off is not a
signal). A similar problem occurs with the read method.

What am I missing?

Angel

Re: [myhdl-list] Architecture Modelling with MyHDL

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

<snip>
>
>
>      This methodology allows a very graceful transition from pure algorithms
> to
>      hardware oriented structures. Indeed, when considering the design phases
>      detailed in Jan's article
>      [http://www.jandecaluwe.com/hdldesign/digmac.html], the delivery of the
>      architectural stage can very well be the verification model - already
>      validated against the original concept!
>
>
>      I have found this aspect of MyHDL very powerful and amazingly easy even
>      for more complicated structures. Hopefully this can gain more users from
>      the non-RTL oriented.
>
> Cheers,
>      Uri
>
>

Nice example and write-up!  Thanks for sharing.

Regards,
Chris Felton

[myhdl-list] Architecture Modelling with MyHDL

[Uri N. <ur...@gm...>]

Hi all,

    I would like to focus a bit on MyHDL's modelling abilities, using a
simple
    example to demonstrate an effective development flow.

    Let's consider a circular buffer, implemented as a pure algorithm.

class CBuff(object):
    def __init__(self, size):
        self.ram = array.array('B', [0]*size)
        self.modulo = size
        self.rd_off = 0
        self.wr_off = 0

    def write(self, value):
        self.ram[self.wr_off] = value
        self.wr_off += 1
        if self.wr_off >= self.modulo: self.wr_off = 0

    def read(self):
        value = self.ram[self.rd_off]
        self.rd_off += 1
        if self.rd_off >= self.modulo: self.rd_off = 0
        return value


    After fully testing this algorithm, we can add a measure of hardware
    orientation by making the accesses synchronous (using the same method
    names, but that of course is a matter of taste):

class HCBuff(CBuff):
    def write(self, clk, din):
        @always(clk.posedge)
        def logic():
            super(HCBuff, self).write(din.val)
        return logic

    def read(self, clk, dout):
        @always(clk.posedge)
        def logic():
            dout.next = super(HCBuff, self).read()
        return logic


    We can now perform pretty complicated concurrent simulations with this
    circular buffer, such as connect each side to a different clock - as
    demonstrated in the attached test.py.


    This methodology allows a very graceful transition from pure algorithms
to
    hardware oriented structures. Indeed, when considering the design phases
    detailed in Jan's article
    [http://www.jandecaluwe.com/hdldesign/digmac.html], the delivery of the
    architectural stage can very well be the verification model - already
    validated against the original concept!


    I have found this aspect of MyHDL very powerful and amazingly easy even
    for more complicated structures. Hopefully this can gain more users from
    the non-RTL oriented.

Cheers,
    Uri

Re: [myhdl-list] MEP 109: Automatic inference of reset behavior

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

That look great. Good enhancement.


On 07/06/2012 10:11 AM, Jan Decaluwe wrote:
> I have put the proposal about Automatic inference of reset
> behavior in a MEP. Hopefully this clarifies everything.
>
> http://myhdl.org/doku.php/meps:mep-109
>

[myhdl-list] MEP 109: Automatic inference of reset behavior

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

I have put the proposal about Automatic inference of reset
behavior in a MEP. Hopefully this clarifies everything.

http://myhdl.org/doku.php/meps:mep-109

-- 
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"

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

On Friday, July 6, 2012, Jan Decaluwe wrote:

> On 07/06/2012 05:00 AM, Christopher Felton wrote:
>
>
> >    From my understanding (and what I agree with) is that the
> > /@always_seq/ requires a reset.  If you don't want a reset
> > you will need to use the /@always(clock.posedge)/.  If you
> > use the /@always_seq/ it requires a reset.
>
> That's not quite right.
>
> The @always_seq decorator needs a reset *argument*, that is
> correct. However it can be 'None' to indicate explicitly that
> you don't want a reset:
>
> @always_seq(clock.posedge, reset=None)
> ...
>
> A reviewer will have no doubt what the intention is.
> In the case of a traditional always block, he may think
> you have delayed the reset coding (e.g. because it's
> boring) and forgotten about it.
>
>
How quickly I forget.  Thanks for the correction, it all makes sense.

Chris