Thread: [myhdl-list] newb question
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Neal B. <ndb...@gm...> - 2008-02-01 16:30:13
|
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? |
|
From: Günter D. <dan...@we...> - 2008-02-05 17:57:24
|
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 |
|
From: Christopher L. F. <cf...@uc...> - 2008-02-08 16:54:45
|
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
|
|
From: Thomas H. <th...@ct...> - 2008-02-08 18:24:31
|
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 |
|
From: Christopher L. F. <cf...@uc...> - 2008-02-08 20:54:46
|
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 |
|
From: Thomas H. <th...@ct...> - 2008-02-08 21:01:55
|
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 |
|
From: Jan D. <ja...@ja...> - 2008-02-08 21:39:14
|
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 |
|
From: Jan D. <ja...@ja...> - 2008-02-12 16:35:12
|
Christopher L. Felton wrote: > 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). This seems to imply that more "typical" code (e.g. with more logic inside generators) could have a relatively larger intbv overhead, and therefore more to gain from intbv optimization. I'll see if I can do a profiling check on my recent designs. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
|
From: Jan D. <ja...@ja...> - 2008-02-18 16:33:37
|
Jan Decaluwe wrote:
> Christopher L. Felton wrote:
>
>
>>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).
>
>
> This seems to imply that more "typical" code (e.g. with more logic
> inside generators) could have a relatively larger intbv overhead,
> and therefore more to gain from intbv optimization.
>
> I'll see if I can do a profiling check on my recent designs.
Below you find a profiling output of a recent test plan. I believe this
is quite representative for the code I tend to write.
I used Python 2.5, cProfile, ordered by time (first 20 items).
I use intbv slicing a lot, and you see this takes a considerable amount
of time.
It seems that optimizing intbv would help significantly, but the Simulation
(including Signal) overhead being what it is, we can't expect miracles.
(Until the py.py team delivers a Python that is 10 times faster :-))
Jan
----
Wed Feb 13 18:36:07 2008 runprof
536613094 function calls (523280085 primitive calls) in 2643.025 CPU seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
19119681 257.504 0.000 461.618 0.000 _intbv.py:148(__setitem__)
12 244.692 20.391 2623.724 218.644 _Simulation.py:95(run)
27579102 222.675 0.000 390.886 0.000 _Signal.py:180(_set_next)
2092116 144.248 0.000 937.835 0.000 _Waiter.py:184(next)
89188746 139.018 0.000 139.018 0.000 {isinstance}
25572768 126.633 0.000 126.633 0.000 _intbv.py:80(_checkBounds)
4748554 108.021 0.000 1078.335 0.000 _Waiter.py:152(next)
19675183 105.021 0.000 105.021 0.000 _Signal.py:46(purge)
41201947/30501215 94.226 0.000 168.693 0.000 {cmp}
27633083/26039251 93.698 0.000 248.657 0.000 _Signal.py:426(__cmp__)
10615743 93.432 0.000 140.551 0.000 _intbv.py:121(__getitem__)
28024120 84.658 0.000 107.350 0.000 _Signal.py:151(_update)
668592 76.952 0.000 447.660 0.001 xxx.py:131(xxx)
13568864/13268586 75.899 0.000 127.541 0.000 _intbv.py:428(__cmp__)
63303336 75.171 0.000 75.171 0.000 {method 'append' of 'list' objects}
25711177 61.852 0.000 61.852 0.000 _Signal.py:224(_setNextBool)
8153851 43.938 0.000 122.899 0.000 _Signal.py:284(__getitem__)
33114023 38.130 0.000 38.130 0.000 {id}
29873445 33.188 0.000 33.188 0.000 {method 'extend' of 'list' objects}
3053592 31.259 0.000 50.400 0.000 _intbv.py:39(__init__)
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
|
|
From: Christopher F. <cf...@uc...> - 2008-02-18 17:43:39
|
On Mon, 18 Feb 2008 17:38:33 +0100
Jan Decaluwe <ja...@ja...> wrote:
> Jan Decaluwe wrote:
>> Christopher L. Felton wrote:
>>
>>
>>>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).
>>
>>
>> This seems to imply that more "typical" code (e.g. with more logic
>> inside generators) could have a relatively larger intbv overhead,
>> and therefore more to gain from intbv optimization.
>>
>> I'll see if I can do a profiling check on my recent designs.
>
> Below you find a profiling output of a recent test plan. I believe
>this
> is quite representative for the code I tend to write.
>
> I used Python 2.5, cProfile, ordered by time (first 20 items).
>
> I use intbv slicing a lot, and you see this takes a considerable
>amount
> of time.
>
> It seems that optimizing intbv would help significantly, but the
>Simulation
Does it make sense to formalize a possible plan for optimization
(quick wiki page)? If different folks attack it in parallel they
would head down a similar path. Define if it needs to be optimized
with C code or not. If so, add ctype type for intbv (like numpy folks
did for arrays). Then attributes etc. can easily be accessible from
C?
> (including Signal) overhead being what it is, we can't expect
>miracles.
>
> (Until the py.py team delivers a Python that is 10 times faster :-))
>
> Jan
>
> ----
>
> Wed Feb 13 18:36:07 2008 runprof
>
> 536613094 function calls (523280085 primitive calls) in
>2643.025 CPU seconds
>
> Ordered by: internal time
>
> ncalls tottime percall cumtime percall
>filename:lineno(function)
> 19119681 257.504 0.000 461.618 0.000
>_intbv.py:148(__setitem__)
> 12 244.692 20.391 2623.724 218.644 _Simulation.py:95(run)
> 27579102 222.675 0.000 390.886 0.000
>_Signal.py:180(_set_next)
> 2092116 144.248 0.000 937.835 0.000 _Waiter.py:184(next)
> 89188746 139.018 0.000 139.018 0.000 {isinstance}
> 25572768 126.633 0.000 126.633 0.000
>_intbv.py:80(_checkBounds)
> 4748554 108.021 0.000 1078.335 0.000 _Waiter.py:152(next)
> 19675183 105.021 0.000 105.021 0.000 _Signal.py:46(purge)
> 41201947/30501215 94.226 0.000 168.693 0.000 {cmp}
> 27633083/26039251 93.698 0.000 248.657 0.000
>_Signal.py:426(__cmp__)
> 10615743 93.432 0.000 140.551 0.000
>_intbv.py:121(__getitem__)
> 28024120 84.658 0.000 107.350 0.000
>_Signal.py:151(_update)
> 668592 76.952 0.000 447.660 0.001 xxx.py:131(xxx)
> 13568864/13268586 75.899 0.000 127.541 0.000
>_intbv.py:428(__cmp__)
> 63303336 75.171 0.000 75.171 0.000 {method 'append' of
>'list' objects}
> 25711177 61.852 0.000 61.852 0.000
>_Signal.py:224(_setNextBool)
> 8153851 43.938 0.000 122.899 0.000
>_Signal.py:284(__getitem__)
> 33114023 38.130 0.000 38.130 0.000 {id}
> 29873445 33.188 0.000 33.188 0.000 {method 'extend' of
>'list' objects}
> 3053592 31.259 0.000 50.400 0.000 _intbv.py:39(__init__)
>
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
> From Python to silicon:
> http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> 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
|
|
From: Jan D. <ja...@ja...> - 2008-02-19 10:37:37
|
Christopher Felton wrote: > Does it make sense to formalize a possible plan for optimization > (quick wiki page)? If different folks attack it in parallel they > would head down a similar path. Define if it needs to be optimized > with C code or not. If so, add ctype type for intbv (like numpy folks > did for arrays). Then attributes etc. can easily be accessible from > C? In general, I would recommend to write a wiki page with considerations and specs before implementing anything significant, so that others can review it and perhaps help with specification and implementation. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
|
From: Prakash S. <pra...@gm...> - 2008-02-19 10:42:00
|
Hello, what Prof. Jan telling is right, before implementing we must review this. I have gone through it , i have 1-2 points , i will write after some time. Thanks Prakash , IIT Bombay On Feb 19, 2008 4:12 PM, Jan Decaluwe <ja...@ja...> wrote: > Christopher Felton wrote: > > > Does it make sense to formalize a possible plan for optimization > > (quick wiki page)? If different folks attack it in parallel they > > would head down a similar path. Define if it needs to be optimized > > with C code or not. If so, add ctype type for intbv (like numpy folks > > did for arrays). Then attributes etc. can easily be accessible from > > C? > > In general, I would recommend to write a wiki page with considerations > and specs before implementing anything significant, so that others > can review it and perhaps help with specification and implementation. > > Jan > > -- > Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com > Kaboutermansstraat 97, B-3000 Leuven, Belgium > From Python to silicon: > http://myhdl.jandecaluwe.com > > > ------------------------------------------------------------------------- > 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 > -- Prakash Sutradhar Electrical Engineering Dept. , IIT Bombay +91-9869956941 |
|
From: Christopher L. F. <cf...@uc...> - 2008-02-26 01:26:38
|
>
> In general, I would recommend to write a wiki page with considerations
> and specs before implementing anything significant, so that others
> can review it and perhaps help with specification and implementation.
>
> Jan
I as contemplating creating a wiki page to start off a possible intbv
optimization page. At first I simply wanted to add a small (emphasis
on small) design example with profiling and the results.
While trying to do this I ran into an issue, maybe someone can point
out what I am doing wrong! I created a simple sequential multiplier
that I thought would be an ok model for exercising intbv.
Note the following isn't complete, but hopefully it will convey the
issue. The following is a very basic sequential multiplier, does a
magnitude multiplication and then does a 2's compliment at the end if
the answer should be negative. The fist time my 2's compliment code
simulates and coverts fine. But the 2's complement conversion towards
the bottom fails?? Any suggestions?
Note the commented out code doesn't work, the expression Product.next
= -1 * p0_r works but I don't believe it will convert correctly.
>>> myhdl.__version__
'0.5.1'
>>> myhdl.__revision__
'$Revision: 827 $'
>>>
<<< ------------------ >>>
@always(clk.posedge)
def sm():
if rst == 1:
state.next = 0
m0_r.next = 0
m1_r.next = 0
p0_r.next = 0
cnt.next = MU_N-1
rdy.next = 1
dv_o.next = 0
neg.next = 0
else:
if state == 0:
if dv_i == 1 and rdy == 1:
state.next = 1
if Multiplicand[MC_N-1]:
m0_r.next = ~Multiplicand + 1
else:
m0_r.next = Multiplicand
if Multiplier[MU_N-1]:
m1_r.next = ~Multiplier + 1
else:
m1_r.next = Multiplier
if Multiplicand[MC_N-1] ^ Multiplier[MU_N-1]:
neg.next = 1
else:
neg.next = 0
p0_r.next = 0
cnt.next = MU_N-1
rdy.next = 0
dv_o.next = 0
elif state == 1:
m0_r.next = m0_r << 1
m1_r.next = m1_r >> 1
if m1_r[0] == 1:
p0_r.next = p0_r + m0_r
if cnt == 0:
state.next = 2
else:
cnt.next = cnt - 1
elif state == 2:
state.next = 0
dv_o.next = 1
if neg:
Product.next = -1 * p0_r
# Should Be ----->>> Product.next = ~p0_r + 1
else:
Product.next = p0_r
rdy.next = 1
<<< ------------------ >>> |
|
From: Jan D. <ja...@ja...> - 2008-02-26 23:05:51
|
Christopher L. Felton wrote: > >> >> In general, I would recommend to write a wiki page with considerations >> and specs before implementing anything significant, so that others >> can review it and perhaps help with specification and implementation. >> >> Jan > > > I as contemplating creating a wiki page to start off a possible intbv > optimization page. At first I simply wanted to add a small (emphasis on > small) design example with profiling and the results. > > While trying to do this I ran into an issue, maybe someone can point out > what I am doing wrong! I created a simple sequential multiplier that I > thought would be an ok model for exercising intbv. > > Note the following isn't complete, but hopefully it will convey the > issue. The following is a very basic sequential multiplier, does a > magnitude multiplication and then does a 2's compliment at the end if > the answer should be negative. The fist time my 2's compliment code > simulates and coverts fine. But the 2's complement conversion towards > the bottom fails?? Any suggestions? I tried to duplicate the problem. The Verilog conversion fails on the use of operator ~ on intbv's that may be negative (so it says.) Before trying to remember why that might be - is that the problem that you are seeing also? -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
|
From: Christopher L. F. <cf...@uc...> - 2008-02-26 23:25:52
Attachments:
mult_seq_hdl.py
|
Yes, I get that issue as well (recently grabbed the latest development snapshot). The original error I observed was during simulation, I attached my file that has the testbench also. I get an overflow during simulation. The testbench can be run as >> python mult_seq_hdl.py trace n |
|
From: Christopher L. F. <cf...@uc...> - 2008-02-26 23:31:05
|
Oooppss, the simulation error I get is <<Error>> ValueError: intbv value 552501280646915 >= maximum 281474976710656 << >> Instead of performing 2's complement it greats a very large number. The simulation should be ran as: >> python mult_seq_hdl.py trace_s n Not the previous On Feb 26, 2008, at 4:25 PM, Christopher L. Felton wrote: > Yes, I get that issue as well (recently grabbed the latest > development snapshot). > > The original error I observed was during simulation, I attached my > file that has the testbench also. I get an overflow during > simulation. > > > The testbench can be run as >> python mult_seq_hdl.py trace n > <mult_seq_hdl.py> > > |
|
From: Jan D. <ja...@ja...> - 2008-02-27 11:01:37
|
Christopher L. Felton wrote: > Oooppss, the simulation error I get is > > <<Error>> > ValueError: intbv value 552501280646915 >= maximum 281474976710656 > > << >> > > Instead of performing 2's complement it greats a very large number. I think I identified the problem, but it deserves some thought and discussion. I'll start a specific thread about the issue. Jan > > The simulation should be ran as: > >> python mult_seq_hdl.py trace_s n > > Not the previous > > > On Feb 26, 2008, at 4:25 PM, Christopher L. Felton wrote: > > >>Yes, I get that issue as well (recently grabbed the latest >>development snapshot). >> >>The original error I observed was during simulation, I attached my >>file that has the testbench also. I get an overflow during >>simulation. >> >> >>The testbench can be run as >> python mult_seq_hdl.py trace n >><mult_seq_hdl.py> >> >> > > > ------------------------------------------------------------------------- > 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/ -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
|
From: Jan D. <ja...@ja...> - 2008-02-10 09:20:39
|
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 believe it is. At this point it's the first optimization I would consider. There are a lot of attribute lookups that we could get rid off. Also, slice assignment is often used and probably slow. But this is just based on gut feeling - I have no quantitative data to back it up. Ideas on how to proceed: * design some profiling test to check whether it's worth the trouble and what to expect * intbv is really like a long, so best to start from Python's long module * perhaps best to use a Python in which int and long have completely converged? * on this occasion, review the intbv interface itself thoroughly, some changes may be worthwhile Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X