myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] newb question

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

Thomas Heller wrote:

> IIUC, this means that modelsim is (only) a factor of ~5 faster?

I have some relevant data from a recent project. With the newest
MyHDL (development version) I can convert a test plan suited
to run under py.test to an equivalent test plan in VHDL and
in Verilog (significant coding restrictions apply, as always).

So it becomes easy to compare run times. The result for the
project were as follows:

MyHDL                        281s
modelsim VHDL RTL             21s
modelsim Verilog, gate level  41s

So VHDL RTL ran 13.4 times faster, Verilog gate level 6.9 times
faster for this project.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

[Thomas H. <th...@ct...>]

Christopher L. Felton schrieb:
> I don't have an exact number because Modelsim doesn't dump the time  
> running when it is complete.
> This particular simulation was setup to run for 4 seconds simulation  
> time with a 100ns simulation step.
> My guesstimate was that Modelsim took between 2hrs - 3hrs because  
> Modeslsim took 15-20 minutes
> to simulate 500ms.

IIUC, this means that modelsim is (only) a factor of ~5 faster?

> For this test, most people would not simulate this design this way.   
> The design has a simple state machine
> that controls the inputs to a bank of pwm's (controls the duty  
> cycle).  But the state machine goes to the next
> state on the order of 100ms real-time.  But since the simulation has  
> little logic and the logic switches minimally
> it seemed like a good test to profile the MyHDL simulation execution
> (most the time spent in the simulation code and not the logic code).
> 
> Also, I should be a little careful because I have not verified the  
> generated Verilog is 100% logically equivalent to
> the MyHDL logic.  I have only spot checked this with the waveform  
> outputs.

Well, we all know what benchmakrs tell us ;-)

Thomas

Re: [myhdl-list] newb question

[Christopher L. F. <cf...@uc...>]

I don't have an exact number because Modelsim doesn't dump the time  
running when it is complete.
This particular simulation was setup to run for 4 seconds simulation  
time with a 100ns simulation step.
My guesstimate was that Modelsim took between 2hrs - 3hrs because  
Modeslsim took 15-20 minutes
to simulate 500ms.

For this test, most people would not simulate this design this way.   
The design has a simple state machine
that controls the inputs to a bank of pwm's (controls the duty  
cycle).  But the state machine goes to the next
state on the order of 100ms real-time.  But since the simulation has  
little logic and the logic switches minimally
it seemed like a good test to profile the MyHDL simulation execution
(most the time spent in the simulation code and not the logic code).

Also, I should be a little careful because I have not verified the  
generated Verilog is 100% logically equivalent to
the MyHDL logic.  I have only spot checked this with the waveform  
outputs.

On Feb 8, 2008, at 11:24 AM, Thomas Heller wrote:

> Christopher L. Felton schrieb:
>> Couple more comments on this topic.
>>
>> One issue if the simulation were to be enhanced by C functions (no
>> need for C++) the build and distribution would become much more work
>> to build and build for the various platforms.
>>
>> But with that said, there have been posts that the simulation speed
>> in some cases seem a bit slow.  I used the python tool cProfile to
>> capture some information on a simulation.
>>
>> The following was a simulation that wasn't horribly efficient as
>> simulations go. The logic included some pwm's and other slowly
>> changing signals.  There were many clock cycles per event (many
>> simulation steps).  But to keep everything relative I had to keep the
>> ratio high (many clk/sim step per event).  The good thing is that
>> because it was a long simulation most of the cProfile errors should
>> of averaged out (this is my first experience with the python profile
>> tools).
>>
>> The MyHDL simulation took 50078.309 CPU seconds (~13 hours) where the
>> converted Verilog with same testbench (same timescale, etc) ran on
>> Modelsim was much shorter.
>>
>
> How long did it take in Modelsim?  Just curious;-)
>
> Thomas
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] newb question

[Thomas H. <th...@ct...>]

Christopher L. Felton schrieb:
> Couple more comments on this topic.
> 
> One issue if the simulation were to be enhanced by C functions (no
> need for C++) the build and distribution would become much more work
> to build and build for the various platforms.
> 
> But with that said, there have been posts that the simulation speed
> in some cases seem a bit slow.  I used the python tool cProfile to
> capture some information on a simulation.
> 
> The following was a simulation that wasn't horribly efficient as
> simulations go. The logic included some pwm's and other slowly
> changing signals.  There were many clock cycles per event (many
> simulation steps).  But to keep everything relative I had to keep the
> ratio high (many clk/sim step per event).  The good thing is that
> because it was a long simulation most of the cProfile errors should
> of averaged out (this is my first experience with the python profile
> tools).
> 
> The MyHDL simulation took 50078.309 CPU seconds (~13 hours) where the
> converted Verilog with same testbench (same timescale, etc) ran on
> Modelsim was much shorter.
> 

How long did it take in Modelsim?  Just curious;-)

Thomas

Re: [myhdl-list] newb question

[Christopher L. F. <cf...@uc...>]

Couple more comments on this topic.

One issue if the simulation were to be enhanced by C functions
(no need for C++) the build and distribution would become much more  
work to build and
build for the various platforms.

But with that said, there have been posts that the simulation speed in  
some cases
seem a bit slow.  I used the python tool cProfile to capture some  
information on a simulation.

The following was a simulation that wasn't horribly efficient as  
simulations go.  The logic
included some pwm's and other slowly changing signals.  There were  
many clock cycles
per event (many simulation steps).  But to keep everything relative I  
had to keep
the ratio high (many clk/sim step per event).  The good thing is that  
because it was a long
simulation most of the cProfile errors should of averaged out
(this is my first experience with the python profile tools).

The MyHDL simulation took 50078.309 CPU seconds (~13 hours) where the  
converted
Verilog with same testbench (same timescale, etc) ran on Modelsim was  
much shorter.

The first table shows the number of functions calls, total time, time  
per call, etc.
The second table shows the call with subcalls and times.

With the data below, I don't know if it is conclusive that optimizing  
intbv would help. You
would need to optimize frequently called functions and relatively long  
functions.



------------ Table 1 --------------------
Ncalls                        Total Time            Per Call (s)        
Cumulative      Function
          1    27367.717 s   2.737e+04   50078.309  _Simulation.py: 
92(run)
  900001800     2477.968 s   2.753e-06   16404.167  _Waiter.py:139(next)
  400000792     2213.805 s   5.535e-06    7412.291  led_pulse.py: 
64(registers)
  700113088     2137.623 s   3.053e-06    6044.433  _Signal.py: 
169(_set_next)
  700113088     1985.815 s   2.836e-06    3780.550  _Signal.py: 
140(_update)
  400000792     1454.013 s   3.635e-06    2394.522  led_pulse.py: 
30(pwm_regs)
  400112492     1374.422 s   3.435e-06    2542.942  _Signal.py: 
214(_setNextIntbv)
1000002000     1280.135 s   1.280e-06   14798.262  _always.py: 
94(genfunc)
  950496034     1116.341 s   1.174e-06    1624.344  _Signal.py: 
405(__cmp__)
1801193755     1085.671 s   6.028e-07    1085.671  {isinstance}
  400167349     1036.418 s   2.590e-06    1036.418  _intbv.py: 
80(_checkBounds)
  400608311      853.896 s   2.131e-06    1132.867  _intbv.py: 
427(__cmp__)
   50000099      765.953 s   1.532e-05    2308.521  tb_led_pulse.py: 
64(ticks_per)
1800509971      702.584 s   3.902e-07     702.584  {method 'append' of  
'list' objects}
1351104345      645.456 s   4.777e-07     646.963  {cmp}
  100042182      619.051 s   6.188e-06     619.051  _Signal.py: 
239(_printVcdBit)
1000011811      517.325 s   5.173e-07     517.325  {method 'pop' of  
'list' objects}
  100000199      401.288 s   4.013e-06    1081.786  tb_led_pulse.py: 
58(clkgen)
  100000303        9.161 s   9.161e-08    1600.072  _Waiter.py:126(next)
  550000649        6.524 s   1.186e-08     356.524  _Signal.py: 
251(__nonzero__)
  200000398        6.849 s   3.424e-08     226.849  _Signal.py: 
204(_setNextBool)
  400003732        0.952 s   2.380e-09     220.952  _Signal.py: 
159(_get_val)
  800198082        1.977 s   2.471e-09     211.977  {method 'extend'  
of 'list' objects}
   50000099        0.519 s   1.038e-08     321.007  led_pulse.py: 
170(ramp_sm)
  100000198        3.947 s   3.947e-08     224.504  _Signal.py: 
209(_setNextInt)
  100030091        6.383 s   6.381e-08     236.571  _Signal.py: 
268(__add__)
  100000200        1.236 s   1.236e-08     131.236  {method 'sort' of  
'list' objects}
      54822        1.464 s   2.670e-05       2.089  _bin.py: 
29(_int2bitstring)
      54857        0.727 s   1.325e-05       2.431  copy.py: 
144(deepcopy)
      54857        0.522 s   9.516e-06       0.550  copy.py: 
260(_keep_alive)
      54822        0.436 s   7.953e-06       2.632  _bin.py:45(bin)
      54857        0.422 s   7.693e-06       0.743  _intbv.py: 
39(__init__)
      54822        0.374 s   6.822e-06       3.006  _Signal.py: 
242(_printVcdVec)
     329066        0.292 s   8.874e-07       0.292  {divmod}
      54857        0.191 s   3.482e-06       0.934  _intbv.py: 
99(__deepcopy__)
     383493        0.108 s   2.816e-07       0.108  {abs}
      54857        0.104 s   1.896e-06       0.104  {issubclass}
      54822        0.083 s   1.514e-06       0.083  _intbv.py: 
412(__long__)
      52542        0.083 s   1.580e-06       0.119  _intbv.py: 
190(__add__)
     110039        0.076 s   6.907e-07       0.076  _intbv.py: 
109(__nonzero__)
     109714        0.059 s   5.378e-07       0.059  {method 'get' of  
'dict' objects}
      54013        0.055 s   1.018e-06       0.055  {method 'join' of  
'str' objects}
     167955        0.049 s   2.917e-07       0.049  {id}
       8000        0.042 s   5.250e-06       0.216  led_pulse.py: 
85(logic_addr)
      54857        0.037 s   6.745e-07       0.037  {getattr}
       8016        0.027 s   3.368e-06       0.261  _Waiter.py:171(next)
      54865        0.024 s   4.374e-07       0.024  {len}
       1692        0.019 s   1.123e-05       0.129  led_pulse.py: 
107(logic_amp)
       1692        0.017 s   1.005e-05       0.153  _Waiter.py:184(next)
       9708        0.017 s   1.751e-06       0.363  _always_comb.py: 
173(genfunc)
      54013        0.016 s   2.962e-07       0.016  {method 'reverse'  
of 'list' objects}
        103        0.016 s   1.553e-04       0.022  tb_led_pulse.py: 
83(stim)
       3378        0.008 s   2.368e-06       0.008  _Signal.py:46(purge)
        824        0.003 s   3.641e-06       0.004  _Signal.py: 
388(__int__)
       1692        0.002 s   1.182e-06       0.002  _Waiter.py: 
180(__init__)
        101        0.002 s   1.980e-05       0.002  {time.localtime}
          1        0.001 s   1.000e-03       0.001  {method 'close' of  
'file' objects}
        824        0.001 s   1.214e-06       0.001  _intbv.py: 
409(__int__)
        102        0.001 s   9.804e-06       0.001  _delay.py: 
32(__init__)
        259        0.000 s   0.000e+00       0.000  {method 'values'  
of 'dict' objects}
         16        0.000 s   0.000e+00       0.001  led_pulse.py: 
51(read)


------------ Table 2 --------------------

    Ordered by: internal time

Function                                          called...
                                                       ncalls   
tottime  cumtime
_Simulation.py:92(run)                            ->    3378     
0.008    0.008  _Signal.py:46(purge)
                                                    700113088 1985.815  
3780.550  _Signal.py:140(_update)
                                                            1     
0.000    0.002  _Simulation.py:75(_finalize)
                                                    100000303  359.161  
1600.072  _Waiter.py:126(next)
                                                    900001800 2477.968  
16404.167  _Waiter.py:139(next)
                                                         8016     
0.027    0.261  _Waiter.py:171(next)
                                                         1692     
0.017    0.153  _Waiter.py:184(next)
                                                            1     
0.000    0.000  _util.py:57(_printExcInfo)
                                                    100000302    
53.018   53.018  {isinstance}
                                                    100000302    
53.910   53.910  {method 'append' of 'list' objects}
                                                    700113088   
169.890  169.890  {method 'extend' of 'list' objects}
                                                    1000011811   
517.325  517.325  {method 'pop' of 'list' objects}
                                                    100000200   
131.236  131.236  {method 'sort' of 'list' objects}
                                                          259     
0.000    0.000  {method 'values' of 'dict' objects}
_Waiter.py:139(next)                              -> 900001800  
1145.934 13582.275  _always.py:94(genfunc)
                                                    900001800   
343.925  343.925  {method 'append' of 'list' objects}
led_pulse.py:64(registers)                        -> 400000400   
220.950  220.950  _Signal.py:159(_get_val)
                                                    400000792 1225.857  
4293.407  _Signal.py:169(_set_next)
                                                    400000792   
467.805  684.128  _Signal.py:405(__cmp__)
_Signal.py:169(_set_next)                         -> 200000398   
226.849  226.849  _Signal.py:204(_setNextBool)
                                                    100000198   
183.947  224.504  _Signal.py:209(_setNextInt)
                                                    400112492 1374.422  
2542.942  _Signal.py:214(_setNextIntbv)
                                                    700113088   
632.827  632.827  {isinstance}
                                                    700113088   
279.688  279.688  {method 'append' of 'list' objects}
_Signal.py:140(_update)                           -> 100042182   
619.051  619.051  _Signal.py:239(_printVcdBit)
                                                        54822     
0.374    3.006  _Signal.py:242(_printVcdVec)
                                                       110039     
0.076    0.076  _intbv.py:109(__nonzero__)
                                                    400112492  852.963  
1130.514  _intbv.py:427(__cmp__)
                                                    100084994    
42.087   42.087  {method 'extend' of 'list' objects}
led_pulse.py:30(pwm_regs)                         ->  100944     
0.318    3.584  _Signal.py:169(_set_next)
                                                    400000400   
254.121  254.121  _Signal.py:251(__nonzero__)
                                                        49885     
0.168    0.315  _Signal.py:268(__add__)
                                                    400320469   
465.501  682.488  _Signal.py:405(__cmp__)
_Signal.py:214(_setNextIntbv)                     -> 400112492  
1036.295 1036.295  _intbv.py:80(_checkBounds)
                                                        54857     
0.727    2.431  copy.py:144(deepcopy)
                                                    400224550   
129.794  129.794  {isinstance}
_always.py:94(genfunc)                            -> 400000792  
1454.013 2394.522  led_pulse.py:30(pwm_regs)
                                                    400000792 2213.805  
7412.291  led_pulse.py:64(registers)
                                                     50000099   
200.519  321.007  led_pulse.py:170(ramp_sm)
                                                    100000199  401.288  
1081.786  tb_led_pulse.py:58(clkgen)
                                                     50000099  765.953  
2308.521  tb_led_pulse.py:64(ticks_per)
                                                           19     
0.000    0.000  {len}
_Signal.py:405(__cmp__)                           ->  
950496034/950336293  506.160  508.176  {cmp}
{isinstance}                                      ->
_intbv.py:80(_checkBounds)                        ->
_intbv.py:427(__cmp__)                            ->  
400608311/400448570  139.296  140.223  {cmp}
                                                    400608311   
139.170  139.170  {isinstance}
tb_led_pulse.py:64(ticks_per)                     -> 200000396   
592.609 1136.658  _Signal.py:169(_set_next)
                                                     99979207   
146.211  236.247  _Signal.py:268(__add__)
                                                    100000198   
122.592  169.663  _Signal.py:405(__cmp__)
-------------------------------------------------------

 From the above information (and information from other sims) it may  
expose some areas that
could use a performance boost??  The MyHDL sim was ran on a Mac G5  
1.8G with 6MB ram.





On Feb 5, 2008, at 10:57 AM, Günter Dannoritzer wrote:

> Neal Becker wrote:
>> Hi.  I just discovered myhdl.  I'm very interested.
>>
>> Haven't tried any coding yet, just reading the docs - but I was  
>> immediately
>> struck by the thought that intbv is going to be awfully slow coded in
>> python - seems to cry out for a c++ implementation.  Is this worth
>> pursuing?
>>
>
> I am not an expert on that subject, but there has been some discussion
> on this list here before about that subject. Maybe looking in the
> archive gives you some answers to your question.
>
> Cheers,
>
> Guenter
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] newb question

[Günter D. <dan...@we...>]

Neal Becker wrote:
> Hi.  I just discovered myhdl.  I'm very interested.
> 
> Haven't tried any coding yet, just reading the docs - but I was immediately
> struck by the thought that intbv is going to be awfully slow coded in
> python - seems to cry out for a c++ implementation.  Is this worth
> pursuing?
> 

I am not an expert on that subject, but there has been some discussion
on this list here before about that subject. Maybe looking in the
archive gives you some answers to your question.

Cheers,

Guenter

[myhdl-list] List of Signals == Memory

[Christopher L. F. <cf...@uc...>]

In this newsgroup a "List of Signals" appears to be a common theme or 
misunderstanding.  I think it is a "natural" Pythonic usage of lists as 
general containers, to group items, build structures, etc.

With the current implementation there are some limitations to using a 
list of signals.  Example the "list syntax" cannot be used in the 
generator code.  This seems to break a very natural way of writing HDL 
in python.

The last 2 MyHDL projects that I did I ran into exactly this issue.  I 
used a "List of Signals" to logically group related (but separate) 
signals.  But I had to go and rewrite the MyHDL code once I tried to 
convert the code to Verilog/VHDL.  The second project I have not gotten 
working yet (still converting) and the first project I had to throw away 
modularity and simply type out sig0, sig1, sig2, ...

I usually end up using "List of Signals" because I am
   1.  Trying to create parameter modules
   2.  Logically organize signals
   3.  I am lazy, don't want to type "din0, din1, din2, ..."
       and maintain

I think the main issue is that a "List of Signals" is preferred to be 
converted to a memory.  I don't know if this always makes sense because 
a Signal is used as 'reg' and 'wire'.  I have used Verilog 2D vectors to 
  represent memories but also a collection of N 32bit buses.

Second issue would be loop unrolling.

Possible resolutions (or at least start dialog to educate me)
   1.  Create a new type 'Memory' that is simply a new class
       that inherits a 'Signal'.  This way simulation will not
       change because 'Memory' will be treated the same as a
       'Signal'.  And the conversion can simply identify a memory
       type.  A "List of Signals" will not be converted to a memory
       structure, only a 'List of Memory' will be converted to a
       Verilog/VHDL memory structure.

   2.  The MyHDL to Verilog/VHDL should unroll the loops.
       a.  This is what the synthesis tool will eventually do anyway
       b.  Allow list syntax in generator code

Pros/Cons:

Pros  -  Hopefully this was somewhat covered above.
   1.  More flexible (natural?) use of a "List of Signals"
   2.  There maybe more special cases for memories that the new
       type will help handle.  Also memories are commonly used to
       simulate an existing memories functionality.  Don't actually
       need the conversion.

Cons
   1.  Not necessarily a minimalistic approach (i.e. adding a new type)


Example of a previous post (Subj: ListElementNotUnique error 5/24/2006)

 > signal_list = [Signal(intbv(0)[WIDTH:]) for i in range(NUMBER)]
 > insts = [module_name(signal_list[i]) for i in range(NUMBER)]
 > @always(clk.negedge)
 >     def select_best():
 >         """Compare values and select the best one"""
 >         best=0
 >         for nr in range(NR_REGS):
 >             if signal_list[nr] > signal_list[best]:
 >                 best=nr
 >
 >     max.next = best

With the current implementation the above will not work.  In the 
original thread Jan gave a good explanation why it currently does not 
work and some examples of how "List of Signals" can be used.  But my 
thought is that the above is an common approach and maybe it should work.

Now the above example would still not work with my proposed changes but 
I think it would be closer.  First the "List of Signals" would not be 
convert to memories (no confusion what it should be) second the list 
syntax can be used in the generator code.  The above loop would not work 
for the same reason as it would not in Verilog.  The indices in the loop 
are not static so the loop cannot be unrolled for a fully parallel 
implementation.  But it could be change to the following.

 > din  = [Signal(intbv(0)[WIDTH:]) for i in range(NUMBER)]
 > dout = Signal(intbv(0)[WIDTH:])
 > ...
 > def top(dout, din, clk, WIDTH=8):
 >     max = [Signal(intbv(0)[WIDTH:]) for i in range(len(din))]
 >     max[0] = din[0]   # assign statement
 >
 >     @always_comb
 >     def compare():
 >         for i in range(NR_REGS-1):
 >             if max[i] > din[i+1]:
 >                 max[i+1].next = max[i]
 >             else:
 >                 max[i+1].next = din[i+1]

 >
 >     @always(clk.negedge)
 >     def dout_reg():
 >             dout.next = max[-1]
 >
 >     return dout_reg, compare

Now the above unrolled should provide a parallel implementation, 
cascaded compares (basically Jan's original solution, just different). 
This is similar to how I may write Verilog, one behavioral block for 
combinational logic (if it complicated) and a behavioral block for 
sequential.

I doubt this would be a simple change(?) because the din would have to 
be converted to din_0, din_1, ... din_NUMBER, and this would have to be 
included in declarations, ports, etc (same for any list of signals).

There have also been some recent posts with similar questions/issues.

Thanks

[myhdl-list] newb question

[Neal B. <ndb...@gm...>]

Hi.  I just discovered myhdl.  I'm very interested.

Haven't tried any coding yet, just reading the docs - but I was immediately
struck by the thought that intbv is going to be awfully slow coded in
python - seems to cry out for a c++ implementation.  Is this worth
pursuing?

[myhdl-list] Test bench conversion methodology

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

Hi:

In a recent design project, verification was done as follows.

* I used py.test instead of unittest. In this way I can write
testbenches simply using 'assert' statements.

* When the design was verified, I converted it to VHDL for
synthesis.

* The synthesis result is a Verilog net list.

* For regression test purposes, I picked a few relevant test
benches and converted them to Verilog and VHDL.


So in the end I have a regression test plan in MyHDL, an
equivalent one in VHDL (to check the convertor) and an
equivalent one in Verilog (to check synthesis and backend
transformation such as atpg and layout).

This works like a charm, and I can do this all without relying
on cosimulation - just standalone simulators in MyHDL, Verilog
and VHDL.

Some details:

* I had to enhance the convertor, e.g. to convert assert statements.

* The top-level design has __vhdl__ and __verilog__ directives that
can be enabled under parameter control, and that hold a top-level
instantiation. This is used to prevent the convertor from converting
the design during test bench conversion. In this way, the conversion
of the design and the test benches are decoupled, as desired.

* The regression tests have to be written in a way to enable conversion.
I had to rewrite some of the original models to make this possible.


If you compare the above with what I have been announcing for
MyHDL 0.6, my conclusion is that I have on the wrong track:

* I emphasized print statements and support for all kinds of
format conversions.

* I introduced "conversion.verify" as a wrapper to check converted
code.

I now think I was trying to be way too clever. For example, I was
trying to emulate format width specifiers, while a language like
Verilog doesn't even have these natively. Also, the "conversion.verify"
wrapper is useful for me to debug the convertor, but it would be
useless in the real-life methodology outlined above.

So I want to back-track as follows for 0.6:

* emphasize assert statement conversion over print conversion
* stop worrying about format width specifier support - support
"%s" and "%d" and that's it
* remove "conversion.verify" from the documentation. It won't be
useful for a broad public - instead people will find out ways
to do their verification based on their needs and what MyHDL
supports, as I did.

So, unless someone gives good arguments to the contrary, that
is the path I'd like to follow.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] bit slicing

[Jon C. <jo...@ho...>]

Fundamentally, I agree that you should keep myhdl as minimal as possible an=
d leverage pure Python as much as possible.  As far as a converter is conce=
rned, I=0A=
suppose that people can do what I'm attempting which is to write a=0A=
crude script to convert Verilog to myhdl. I think in the future I will=0A=
probably have to put some comments in my Verilog code to make the=0A=
process easier.=20
=0A=
=0A=
As far as co-simulation is concerned, I would prefer not to go down that ro=
ute as I want as much of the simulation in Python as possible to give me mo=
re flexibility for analysis, etc.


> To: myh...@li...
> From: ja...@ja...
> Date: Sat, 26 Jan 2008 22:08:03 +0100
> Subject: Re: [myhdl-list] bit slicing
>=20
> Jon Choy wrote:
> > =20
> >  Jan,
> > =20
> >   I apologize for submitting to the bug tracker instead of discussion=20
> > list and I missed some details in the bit slicing. It does make=20
> > conversion of Verilog to myhdl a little bit cumbersome.
>=20
> Ok. MyHDL slicing is done like that to stay in line with the Python
> convention that the high index is excluded. (However, unlike typical
> Python slices, the high index is the *left* index in MyHDL, to stay
> in line with common hardware conventions.)
>=20
> It may sometimes be confusing, I agree. On the other hand, you may
> appreciate the fact that [m:] indicates an m-bit bus, and that
> slice [m:n] has m-n bits.
>=20
>  > Is it true that
> > you plan to support bidirectional conversion? What I mean by=20
> > bidirectional conversion means converting myhdl to Verilog and vice=20
> > versa.
>=20
> No, I have no plans in that direction. Seems like a daunting and frustrat=
ing
> task. Note that when I start from MyHDL, I start from a minimalistic
> language with all tools at hand (the Python compiler package). In the
> opposite direction it would be the opposite ...
>=20
>  > This would enable me to use legacy code and/or old Verilog
> > behavioral models.  I assume that others would be interested in trying=
=20
> > to import their old code to myhdl.
>=20
> Perhaps a more general co-simulation approach could address this where
> you embed an arbitrary number of Verilog simulators in a MyHDL design.
> (Currently cosimulation is limited to a single cosimulation object).
> No idea how feasible that is, though.
>=20
> Jan
>=20
> --=20
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>      From Python to silicon:
>      http://myhdl.jandecaluwe.com
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

_________________________________________________________________
Climb to the top of the charts!=A0Play the word scramble challenge with sta=
r power.
http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=
n=

Re: [myhdl-list] bit slicing

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

Jon Choy wrote:
>  
>  Jan,
>  
>   I apologize for submitting to the bug tracker instead of discussion 
> list and I missed some details in the bit slicing. It does make 
> conversion of Verilog to myhdl a little bit cumbersome.

Ok. MyHDL slicing is done like that to stay in line with the Python
convention that the high index is excluded. (However, unlike typical
Python slices, the high index is the *left* index in MyHDL, to stay
in line with common hardware conventions.)

It may sometimes be confusing, I agree. On the other hand, you may
appreciate the fact that [m:] indicates an m-bit bus, and that
slice [m:n] has m-n bits.

 > Is it true that
> you plan to support bidirectional conversion? What I mean by 
> bidirectional conversion means converting myhdl to Verilog and vice 
> versa.

No, I have no plans in that direction. Seems like a daunting and frustrating
task. Note that when I start from MyHDL, I start from a minimalistic
language with all tools at hand (the Python compiler package). In the
opposite direction it would be the opposite ...

 > This would enable me to use legacy code and/or old Verilog
> behavioral models.  I assume that others would be interested in trying 
> to import their old code to myhdl.

Perhaps a more general co-simulation approach could address this where
you embed an arbitrary number of Verilog simulators in a MyHDL design.
(Currently cosimulation is limited to a single cosimulation object).
No idea how feasible that is, though.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] bit slicing

[Jon C. <jo...@ho...>]

  Jan,
=20
  I apologize for submitting to the bug tracker instead of discussion list =
and I missed some details in the bit slicing. It does make conversion of Ve=
rilog to myhdl a little bit cumbersome. Is it true that you plan to support=
 bidirectional conversion? What I mean by bidirectional conversion means co=
nverting myhdl to Verilog and vice versa.  This would enable me to use lega=
cy code and/or old Verilog behavioral models.  I assume that others would b=
e interested in trying to import their old code to myhdl.
=20
=20
=20
  Jon
  =20
=20
---------------------------------------------------------------------->Comm=
ent By: Jan Decaluwe (jandecaluwe)Date: 2008-01-24 14:04Message:Logged In: =
YES user_id=3D144795Originator: NOI think you're confused about how slicing=
 works in MyHDL (and Python).Have you read this:   http://www.jandecaluwe.c=
om/Tools/MyHDL/manual/intro-slicing.htmlIssues like this are better discuss=
ed on the mailing list/newsgroup first.------------------------------------=
----------------------------------   Submitted By: h2opolo (h2opolo)Assigne=
d to: Nobody/Anonymous (nobody)Summary: concat and intbvInitial Comment:I'm=
 fairly new to myhdl; but I've been using many mixed signal design tools fo=
r years. I use tools like ncverilog, vcs, etc. Myhdl looks very promising f=
or mixed signal design. Anyway, I noticed that when I try to specify a bit =
width and assign it a value it seems like I have to use an additional bit. =
For example, if I try to do the following:  a =3D intbv(2)[2:]  It does not=
 like it and I end up having to add additional bit (e.g. a =3D intbv(2)[3:]=
 ). When converting Verilog code to Python, there are occasions where I hav=
e to concatenate signals like the following example:    b =3D {4'b1011,a[1:=
0]} and in this case I would create a 6 bit bus. It seems like I have to ad=
d a bit or I don't get the correct value. It almost seems like the upper bi=
t gets chopped off. It doesn't look like this was fixed for the 0.6 develop=
ment version. Is there a reason for this? Like dealing with signed integers=
 or something. It makes conversion to and from Verilog a little cumbersome.=
  JonYou can respond by visiting: https://sourceforge.net/tracker/?func=3Dd=
etail&atid=3D596332&aid=3D1878630&group_id=3D91207
_________________________________________________________________
Climb to the top of the charts!=A0Play the word scramble challenge with sta=
r power.
http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=
n=

[myhdl-list] The Miracle of Love

[<dhi...@ko...>]

Wrapped in Your Arms http://24.150.173.130/

[myhdl-list] A Is For Attitude

[<fa...@ar...>]

Magic Power Of Love  http://65.189.144.143/

[myhdl-list] Surrounded by Love

[<jws...@ml...>]

You... In My Dreams http://67.149.17.5/

[myhdl-list] A Token of My Love

[<ron...@wh...>]

You... In My Dreams http://68.94.189.39/

[myhdl-list] 0.6dev6

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

Hello all - happy new year!

I have put development version 0.6dev6 on the web site:

    http://myhdl.jandecaluwe.com/doku.php/dev:snapshots#snapshots

This should be quite a strong release, because it is the version
that I have just used for a "real" design project as a consultant,
targetting both Verilog and VHDL.

There are many improvements, both in simulation and conversion to
Verilog. Moreover, conversion to VHDL should now be as strong as
conversion to Verilog. The improvements were all triggered by
real-life usage in the project. Backward compatibility should
be close to perfect.

What is lacking is documentation, and of course fixing of some
open ends.

I have documented some fixed bugs on SourceForge (opened and closed again),
but I have many more things to document about features and methodology.
I hope to do that here and on the site in the weeks ahead - I will
not take new consultancy projects until March (but from then on,
feel free to consider me ;-)).

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Dynamically Generated Assignments

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

Evan Broder wrote:
> Jan Decaluwe wrote:
> 
>>Evan Broder wrote:
>>
>>>Hi -
>>>    I'm trying to write a (HDL) module to permute an input bit-vector
>>>from a mapping list that's fed in when the module is initialized, but I
>>>can't seem to get it to work. I've gone through a bunch of different
>>>revisions trying to make this work, and finally settled on trying to
>>>generate one generator for each assignment so that I could loop without
>>>MyHDL trying to convert the loop to Verilog. I think that code will
>>>explain this much better than I can, so:
>>>
>>>def module(self, clock, in_perm, out_perm):
>>>	permutations = []
>>>	for i in range(len(mapping)):
>>>		input_index = mapping[i]
>>>		@always_comb
>>>		def permute():
>>>			out_perm.next[i] = in_perm.val[input_index]
>>>		
>>>		permutations.append(permute)
>>>	
>>>	return tuple(permutations)
>>>
>>>For some reason, though, it seems that each generator overwrites the old
>>>one, meaning that only the last bit of out_perm ever gets set.
>>
>>This is a consequence from how "free variables" (i) are handled in Python.
>>Consider:
>>
>>def f():
>>     funcs = []
>>     i = 0
>>     def g():
>>         print "func 1"
>>         print i
>>     funcs.append(g)
>>     i = 1
>>     def g():
>>         print "func 2"
>>         print i
>>     funcs.append(g)
>>
>>     for h in funcs:
>>         h()
>>
>>f()
>>
>>The output is:
>>
>> > python tmp4.py
>>func 1
>>1
>>func 2
>>1
>>
>>So, the functions are different, but the value of the free variable
>>is the "last" one in both cases.
>>
>>
>>>Is there some way that I can make this work the way that I want?
>>
>>It would be quite easy to accomplish what you want with
>>lists for Signals instead of bit vectors modeled by intbv's.
>>Would that be acceptable?
>>
>>Jan
>>
> 
> 
> I don't want the interface to the module to change (I want the inputs
> and outputs to be bit vectors). Are you suggesting that I should change
> the arguments or convert the intbv's to lists within the module/function?

No, just checking - with lists of signals you could make something
more general than just for bits.

With intbv's and Signals thereof you'll have to stay within a
single generator - otherwise the convertor will complain about
multiple Signal drivers. What you can do is index into the mapping,
represented as a tuple:

def module(in_perm, out_perm, mapping):

     @always_comb
     def permute():
         j = intbv(0, min=0, max=len(mapping))
         for i in range(len(mapping)):
             j[:] = mapping[i]
             out_perm.next[i] = in_perm[int(j)]

     return permute

Note that j is an intbv, and the indexing is on a single
line. This is due to convertor restrictions, for pure
modeling this is not required of course. The convertor
can map this to a case statement. Now you can do:

mapping = (2, 3, 0, 1)
in_perm = Signal(intbv(0)[4:])
out_perm = Signal(intbv(0)[4:])

toVerilog(module, in_perm, out_perm, mapping)

and you'll get:

---

// File: module.v
// Generated by MyHDL 0.6dev6
// Date: Thu Jan  3 22:59:40 2008

module module (
     in_perm,
     out_perm
);

input [3:0] in_perm;
output [3:0] out_perm;
reg [3:0] out_perm;



always @(in_perm) begin: MODULE_PERMUTE
     integer i;
     reg [2-1:0] j;
     j = 0;
     for (i=0; i<4; i=i+1) begin
         // synthesis parallel_case full_case
         case (i)
             0: j = 2;
             1: j = 3;
             2: j = 0;
             default: j = 1;
         endcase
         out_perm[i] <= in_perm[j];
     end
end

endmodule
---

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Dynamically Generated Assignments

[Evan B. <br...@mi...>]

Jan Decaluwe wrote:
> Evan Broder wrote:
>> Hi -
>>     I'm trying to write a (HDL) module to permute an input bit-vector
>> from a mapping list that's fed in when the module is initialized, but I
>> can't seem to get it to work. I've gone through a bunch of different
>> revisions trying to make this work, and finally settled on trying to
>> generate one generator for each assignment so that I could loop without
>> MyHDL trying to convert the loop to Verilog. I think that code will
>> explain this much better than I can, so:
>>
>> def module(self, clock, in_perm, out_perm):
>> 	permutations = []
>> 	for i in range(len(mapping)):
>> 		input_index = mapping[i]
>> 		@always_comb
>> 		def permute():
>> 			out_perm.next[i] = in_perm.val[input_index]
>> 		
>> 		permutations.append(permute)
>> 	
>> 	return tuple(permutations)
>>
>> For some reason, though, it seems that each generator overwrites the old
>> one, meaning that only the last bit of out_perm ever gets set.
>
> This is a consequence from how "free variables" (i) are handled in Python.
> Consider:
>
> def f():
>      funcs = []
>      i = 0
>      def g():
>          print "func 1"
>          print i
>      funcs.append(g)
>      i = 1
>      def g():
>          print "func 2"
>          print i
>      funcs.append(g)
>
>      for h in funcs:
>          h()
>
> f()
>
> The output is:
>
>  > python tmp4.py
> func 1
> 1
> func 2
> 1
>
> So, the functions are different, but the value of the free variable
> is the "last" one in both cases.
>
>> Is there some way that I can make this work the way that I want?
>
> It would be quite easy to accomplish what you want with
> lists for Signals instead of bit vectors modeled by intbv's.
> Would that be acceptable?
>
> Jan
>

I don't want the interface to the module to change (I want the inputs
and outputs to be bit vectors). Are you suggesting that I should change
the arguments or convert the intbv's to lists within the module/function?

Re: [myhdl-list] Dynamically Generated Assignments

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

Evan Broder wrote:
> Hi -
>     I'm trying to write a (HDL) module to permute an input bit-vector
> from a mapping list that's fed in when the module is initialized, but I
> can't seem to get it to work. I've gone through a bunch of different
> revisions trying to make this work, and finally settled on trying to
> generate one generator for each assignment so that I could loop without
> MyHDL trying to convert the loop to Verilog. I think that code will
> explain this much better than I can, so:
> 
> def module(self, clock, in_perm, out_perm):
> 	permutations = []
> 	for i in range(len(mapping)):
> 		input_index = mapping[i]
> 		@always_comb
> 		def permute():
> 			out_perm.next[i] = in_perm.val[input_index]
> 		
> 		permutations.append(permute)
> 	
> 	return tuple(permutations)
> 
> For some reason, though, it seems that each generator overwrites the old
> one, meaning that only the last bit of out_perm ever gets set.

This is a consequence from how "free variables" (i) are handled in Python.
Consider:

def f():
     funcs = []
     i = 0
     def g():
         print "func 1"
         print i
     funcs.append(g)
     i = 1
     def g():
         print "func 2"
         print i
     funcs.append(g)

     for h in funcs:
         h()

f()

The output is:

 > python tmp4.py
func 1
1
func 2
1

So, the functions are different, but the value of the free variable
is the "last" one in both cases.

> 
> Is there some way that I can make this work the way that I want?

It would be quite easy to accomplish what you want with
lists for Signals instead of bit vectors modeled by intbv's.
Would that be acceptable?

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Dynamically Generated Assignments

[Evan B. <br...@mi...>]

Hi -
    I'm trying to write a (HDL) module to permute an input bit-vector
from a mapping list that's fed in when the module is initialized, but I
can't seem to get it to work. I've gone through a bunch of different
revisions trying to make this work, and finally settled on trying to
generate one generator for each assignment so that I could loop without
MyHDL trying to convert the loop to Verilog. I think that code will
explain this much better than I can, so:

def module(self, clock, in_perm, out_perm):
	permutations = []
	for i in range(len(mapping)):
		input_index = mapping[i]
		@always_comb
		def permute():
			out_perm.next[i] = in_perm.val[input_index]
		
		permutations.append(permute)
	
	return tuple(permutations)

For some reason, though, it seems that each generator overwrites the old
one, meaning that only the last bit of out_perm ever gets set.

Is there some way that I can make this work the way that I want?

Thanks,
   Evan

[myhdl-list] Happy New Year To You!

[<im...@aa...>]

Happy 2008!
http://newyearwithlove.com/

[myhdl-list] Time for an update

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

Hi all:

I thought it was time for an update :-)

I've been quiet lately, but this doesn't mean that there
was no MyHDL activity from my part, to the contrary.

In the past 3 months I have - for the first time - done
a paid consultancy job based on MyHDL, using both
conversion to Verilog and VHDL as well as unit testing.
The project was the design of the digital part of
an ASIC, so I've been able to put the tool and the
methodology to a real test.

This has gone very well. I've really enjoyed it, and
learned a lot both in MyHDL details and in overall
methodology. This will keep me busy for quite some time!

So chances are you'll hear lot more from me in the
coming days and weeks. Based on this experience, I'll
also announce the availability of commercial support
from my part for MyHDL and MyHDL-related design jobs.

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Tristate bus to external SRAM

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

Randy Lea wrote:

> Thanks for all the work on MyHDL.

Thanks for the interest.

> The project I'm looking at requires Tri-state signals for external 8-bit data
> path to memory. I noticed that the latest dev release (0.6dev4) includes
> Tri-state support for simulation. I have installed dev4, all of the examples
> run, but I am having difficulty using the Tri-state signals. I have a lot of
> experience in Python, none with MyHDL.
> 
> Is the dev4 release stable enough to use for simulation?

In general, for all features in earlier releases (1.5.1) it should be stable or
better because of bug fixes. Features under development will be buggy
or incomplete.

> Is the Tri-state signal working?

There is in an experimental implementation (corresponding to MEP 103)
in 0.6dev4. No extensive testing or unit tests yet though.

> If yes, could you post a simple example of using a Tri-state signal?

Sure. Here is the example that I used to quickly check the experimental
implementation. Let me know if this functionality is what you're looking
for:

---
from myhdl import *

def test(bus):

     d1 = bus.driver()
     d2 = bus.driver()
     d3 = bus.driver()

     @instance
     def proc1():

         for v in (1, None, 2, None, 3, 10, None, None):
             yield delay(10)
             d1.next = v

         raise StopSimulation

     @instance
     def proc2():

         for v in (None, 4, None, 5, 6, None, None):
             yield delay(10)
             d2.next = v

     @instance
     def proc3():
         for v in (None, None, None, None, None, None, 44):
             yield delay(10)
             d3.next = v

     @always(bus)
     def monitor():
         print now(), bus

     return proc1, proc2, proc3, monitor

bus = Tristate(intbv(0)[4:])
sim = Simulation(test(bus))
sim.run()

---
Output:

 > python test.py
10 1
20 4
30 2
40 5
** BusContentionWarning: Bus contention
** BusContentionWarning: Bus contention
** BusContentionWarning: Bus contention
50 None
60 10
70 44
---

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Tristate bus to external SRAM

[Randy L. <Dog...@bl...>]

George Pantazopoulos <george <at> gammaburst.net> writes:

> 
> 
> On Wed, December 13, 2006 9:16 am, Jan Decaluwe wrote:
> > George Pantazopoulos wrote:
> >>>At some point I would like to take some time to think thorougly
> >>>about tristates and inouts and come up with a satisfactory
> >>>solution, hopefully based on user inputs and feedback.
> >>>Currently, I'm focussed on getting toVHDL on track
> >>>and right - which offers more than enough brain teasers 



Thanks for all the work on MyHDL.

The project I'm looking at requires Tri-state signals for external 8-bit data
path to memory. I noticed that the latest dev release (0.6dev4) includes
Tri-state support for simulation. I have installed dev4, all of the examples
run, but I am having difficulty using the Tri-state signals. I have a lot of
experience in Python, none with MyHDL.

Is the dev4 release stable enough to use for simulation?

Is the Tri-state signal working?

If yes, could you post a simple example of using a Tri-state signal?

Thanks again.