myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] howto cite MyHDL

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

On 10/05/2011 12:21 PM, Christopher Felton wrote:
> On 10/2/11 9:33 PM, Dan White wrote:
>> I've used MyHDL for some digital parts on my last mixed-signal ASIC
>> for my PhD research.  The chip is currently in fab and I've been
>> waiting to get a die photo after testing to announce here the second
>> verified silicon using MyHDL in the flow.
>>
>
> Congratulations as well!  It seems MyHDL might have found a niche in
> mixed-signals ICs.

 From what I see, this is becoming the niche of ASICs tout court:
pure digital designs are systematically migrating to FPGAs,
the few exceptions being super high volume and complexity designs.

Therefore - there must be some MyHDL FPGA success stories
out there as well. We may not have heard about them because
the typical ASIC milestones like sign-off and tape-out are
not applicable (fortunately I would add.) But I would encourage
anyone with such success stories (especially FPGAs in production)
to tell us about it if possible.

More than anything else, I think the project needs the
credibility from working silicon, FPGAs included.

-- 
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] Sigma-Delta DAC

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

On 10/4/11 2:37 AM, Bob Cunningham wrote:
> More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000
>
> I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.
>

I think what you are getting at, is that you want an AGC part of your 
design.  This should not be part of the delta-sigma module.  You might 
consider it part of your "DAC" but I don't think it should be part of 
the delta-sigma module.

> With this goal in mind, my first detailed pass through the existing code raises two related questions:
>
> 1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?
>
> The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.
>
> The question is: Would the extra processing be worth doing?  Why or why not?
>
>
> 2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
>    - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
>    - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
>    - Or am I missing some of the intent of the test?
>

The integration time, might be poorly named, in the testbench.  It is 
simply some amount of time delayed for each step to test.  You can work 
backwards and analytically determine the response time (I don't know 
this off the top of my head).  Or you could apply a step function to the 
module and empirically determine the response time.  Is there a reason 
you want to change it?

For the most part, these are general design questions.  You might want 
to cross-post to comp.arch.fpga or sci.electronics.design (.basic). 
There were no protest to post here, as stated I think it is fine, but 
you might get a better response from some of the other news/irc groups 
in addition.

Regards,
Chris
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1

Re: [myhdl-list] howto cite MyHDL

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

On 10/2/11 9:33 PM, Dan White wrote:
> I've used MyHDL for some digital parts on my last mixed-signal ASIC
> for my PhD research.  The chip is currently in fab and I've been
> waiting to get a die photo after testing to announce here the second
> verified silicon using MyHDL in the flow.
>

Congratulations as well!  It seems MyHDL might have found a niche in 
mixed-signals ICs.

Regards,
Chris

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

More questions about this code: http://www.myhdl.org/doku.php/projects:dsx1000

I'd like to optimize the DAC output performance so the analog audio output would faithfully as possible represent a 10-bit digital input sequence at 44.1 KHz.  I have two usage scenarios:  a) Driving a line-out connection to an external amplifier, and b) driving a local analog comparator (with known hysteresis) as part of a sigma-delta ADC.  In both cases, I'd want to optimize both the RC filter design (for the intended load and PWM drive current/voltage) and the digital DAC design (mainly to use a minimum PWM output bit rate).  Ideally, the synthesized circuit would default to the current code (or raise an error) when the output filter characteristics are not specified.

With this goal in mind, my first detailed pass through the existing code raises two related questions:

1. The definition of dac_dsx1000() in dac_dsx1000_hd.pydoes not take into account either the characteristics of the load on the PWM output pin, nor the drive capability of that pin.  If these characteristics are known prior to synthesis, shouldn't the generated PWM bitstream be pre-compensated accordingly?  That is, when the input value changes, shouldn't the output be driven hard until the estimated filter output (not the pin output) gets to within a single bit-time delta of the desired value?

The formula for a simple first-order RC output filter is simple.  My naive guess is the correction could be implemented as a digital filter (the inverse of the output filter), perhaps by modifying the integrator stage (Adder()).  The main benefit would be that the required PWM clock rate could be significantly reduced and/or output fidelity improved.

The question is: Would the extra processing be worth doing?  Why or why not?


2.  The unit test in bench_static() in dac_dsx1000_ut.py sets "INTEGRATION_TIME = 512".  This seems like a very long time.  I doubt I'll see that many PWM clock periods in any realistic implementation scenario.
  - Is there a better or more realistic way to determine this value?  Perhaps as a function of input word width and output bitstream frequency?
  - How should the value change if the optimization described in the prior question were implemented?  That is, I'd like the test to tell me if the PWM output will drive the filter output (not just the pin output) with the desired level of error.
  - Or am I missing some of the intent of the test?


-BobC

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

On 10/03/2011 06:36 PM, Christopher Felton wrote:
> On 10/3/11 7:56 PM, Bob Cunningham wrote:
>> Hi Chris,
>>
>> On 10/01/2011 06:38 PM, you wrote:
>>> You can refer to a recent thread why the error occurs.
>> I've searched, but found no such thread.  Would you send me a link to it?
> http://article.gmane.org/gmane.comp.python.myhdl/2057/match=driving+constants

Oh, THAT thread.  I have it archived, but had no clue it was in any way related to my questions.

Well, still don't, really.  But I'm studying it.

Beware the newbie:  Speak slowly.  Use small words.

-BobC

Re: [myhdl-list] Sigma-Delta DAC

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

On 10/3/11 7:56 PM, Bob Cunningham wrote:
> Hi Chris,
>
> On 10/01/2011 06:38 PM, you wrote:
>> You can refer to a recent thread why the error occurs.
>
> I've searched, but found no such thread.  Would you send me a link to it?

http://article.gmane.org/gmane.comp.python.myhdl/2057/match=driving+constants

>
>> If you want to convert the waveform generator as well, simply bring the
>> reset to a port and remove the dummy reset driver.
>
> Nothing is 'simply' done by a newbie.
>
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1

Re: [myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

Hi Chris,

On 10/01/2011 06:38 PM, you wrote:
> You can refer to a recent thread why the error occurs. 

I've searched, but found no such thread.  Would you send me a link to it?

> If you want to convert the waveform generator as well, simply bring the
> reset to a port and remove the dummy reset driver.

Nothing is 'simply' done by a newbie.


-BobC

Re: [myhdl-list] howto cite MyHDL

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

On 10/03/2011 04:33 AM, Dan White wrote:
> I've used MyHDL for some digital parts on my last mixed-signal ASIC
> for my PhD research.  The chip is currently in fab and I've been
> waiting to get a die photo after testing to announce here the second
> verified silicon using MyHDL in the flow.

Congratulations, great news!

> However, we are writing up several papers related to the IC and are
> not sure how to cite the software.  The place holder is:
>
> "J. Decaluwe, 'MyHDL -- Python to Silicon,' http://www.myhdl.org"
>
> Would a better reference be Jan's "MyHDL-based design of a digital
> macro" paper or something else?

I would use the most appropriate reference for the context.

When referring to MyHDL in general, I would merely refer to the website
as the first source for more information. No names or taglines,
like one would do for VHDL or Verilog.

Jan

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

[myhdl-list] howto cite MyHDL

[Dan W. <eti...@gm...>]

I've used MyHDL for some digital parts on my last mixed-signal ASIC
for my PhD research.  The chip is currently in fab and I've been
waiting to get a die photo after testing to announce here the second
verified silicon using MyHDL in the flow.

However, we are writing up several papers related to the IC and are
not sure how to cite the software.  The place holder is:

"J. Decaluwe, 'MyHDL -- Python to Silicon,' http://www.myhdl.org"

Would a better reference be Jan's "MyHDL-based design of a digital
macro" paper or something else?

More info on the chip and thoughts after we verify the smoke stays in...

Thanks,
Dan White

Electrical Engineering
University of Nebraska-Lincoln

-- 
SDG
www.whiteaudio.com

Re: [myhdl-list] myHDL First Project: Audio Effects System

[Sébastien B. <seb...@mi...>]

On 10/02/2011 01:31 AM, Bob Cunningham wrote:
> Bryan's feature and value propositions excel on all levels, not just compared to Papilio, but also when compared to any other FPGA dev board available on the planet.

OMGLOL, how about those?
http://www.dinigroup.com

Re: [myhdl-list] Sigma-Delta DAC

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

On 10/1/11 8:20 PM, Bob Cunningham wrote:
> I'm trying to learn from this code:
> http://www.myhdl.org/doku.php/projects:dsx1000
>
> I first ran dac_dsx1000_ut.py, and all tests passed.  I next tried to
> run dac_dsx1000_syn.py, but got the following errors:

You can refer to a recent thread why the error occurs.  If you are only 
concerned with converting the DAC portion you can use the following.

     # PCM Audio signal.
     # Note that we control the (theoretical) resolution of the converter
     # by setting the bit width of this signal.
     DAC_RESOLUTION = 8
     clk_i = Signal(False)
     rst_i = Signal(False)
     pcm_i = Signal(intbv(0)[DAC_RESOLUTION:])
     pdm_o = Signal(False)

     # MyHDL to Verilog conversion
     toVerilog.name = "dsx1000"
     toVerilog(dac_dsx1000, clk_i, rst_i, pcm_i, pdm_o)

If you want to convert the waveform generator as well, simply bring the 
reset to a port and remove the dummy reset driver.

Hope that helps,
Chris

>
>     $ pypy ./dac_dsx1000_syn.py
>     CLK_HZ =  16000000
>     OUTPUT_FREQ_HZ =  440
>     FVAL =  461
>     Traceback (most recent call last):
>        File "app_main.py", line 53, in run_toplevel
>        File "./dac_dsx1000_syn.py", line 137, in<module>
>          toVerilog(top, clk, rst, pdm_o, CLK_HZ)
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/conversion/_toVerilog.py", line 128, in __call__
>          h = _HierExtr(name, func, *args, **kwargs)
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/_extractHierarchy.py", line 228, in __init__
>          _top = dut(*args, **kwargs)
>        File "./dac_dsx1000_syn.py", line 97, in top
>          @always_comb
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 64, in always_comb
>          c = _AlwaysComb(func, symdict)
>        File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 203, in __init__
>          raise AlwaysCombError(_error.EmptySensitivityList)
>     AlwaysCombError: sensitivity list is empty
>
>
> I got the same errors when using python instead of pypy.
>
> My naive solution was to modify dac_dsx1000_syn.py to add 'rst' to
> top()'s parameter list, move the rst declaration to line 132, and
> comment-out the definition of rstDrv(), after which the above errors
> went away.
>
> While the tests in dac_dsx1000_ut.py still pass, I'm now torturing my
> newbie brain to figure out how best to update the testbench to include
> testing of rst.  The pain is terrible, but slow progress is being made.
>
> I haven't yet fed the generated Verilog code to ISE, nor have I run a
> cosimulation to test it.
>
> Questions:
> 1. Is this the right approach to use to fix this problem?
> 2. When the fix is complete and tested, where should the updated code go?
>
> TIA,
>
> -BobC
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Sigma-Delta DAC

[Bob C. <Fl...@gm...>]

I'm trying to learn from this code: http://www.myhdl.org/doku.php/projects:dsx1000

I first ran dac_dsx1000_ut.py, and all tests passed.  I next tried to run dac_dsx1000_syn.py, but got the following errors:

    $ pypy ./dac_dsx1000_syn.py
    CLK_HZ =  16000000
    OUTPUT_FREQ_HZ =  440
    FVAL =  461
    Traceback (most recent call last):
       File "app_main.py", line 53, in run_toplevel
       File "./dac_dsx1000_syn.py", line 137, in<module>
         toVerilog(top, clk, rst, pdm_o, CLK_HZ)
       File "/usr/lib/pypy-1.6/site-packages/myhdl/conversion/_toVerilog.py", line 128, in __call__
         h = _HierExtr(name, func, *args, **kwargs)
       File "/usr/lib/pypy-1.6/site-packages/myhdl/_extractHierarchy.py", line 228, in __init__
         _top = dut(*args, **kwargs)
       File "./dac_dsx1000_syn.py", line 97, in top
         @always_comb
       File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 64, in always_comb
         c = _AlwaysComb(func, symdict)
       File "/usr/lib/pypy-1.6/site-packages/myhdl/_always_comb.py", line 203, in __init__
         raise AlwaysCombError(_error.EmptySensitivityList)
    AlwaysCombError: sensitivity list is empty


I got the same errors when using python instead of pypy.

My naive solution was to modify dac_dsx1000_syn.py to add 'rst' to top()'s parameter list, move the rst declaration to line 132, and comment-out the definition of rstDrv(), after which the above errors went away.

While the tests in dac_dsx1000_ut.py still pass, I'm now torturing my newbie brain to figure out how best to update the testbench to include testing of rst.  The pain is terrible, but slow progress is being made.

I haven't yet fed the generated Verilog code to ISE, nor have I run a cosimulation to test it.

Questions:
1. Is this the right approach to use to fix this problem?
2. When the fix is complete and tested, where should the updated code go?

TIA,

-BobC

Re: [myhdl-list] myHDL First Project: Audio Effects System

[Bob C. <Fl...@gm...>]

My apologies to all list members!   My prior post should have been directly addressed.

I didn't intend to broadcast all that off-topic content (though I hope it was at least somewhat entertaining).


-BobC

Re: [myhdl-list] myHDL First Project: Audio Effects System

[Bob C. <Fl...@gm...>]

Hi Chris,

On 10/01/2011 12:15 PM, Christopher Felton wrote:
> I would not use a kickstarter board, simply because your project is then
> dependent on the kickstarter project.
>
> Personally, for a project like this I would make it board agnostic.  You
> haven't indicated anything that would tie you to a particular board.  I
> would focus on the project development versus the hardware platform but
> you provide "examples" for a particular board.  This also allows folks
> with other dev boards to participate without having to get the "project"
> board.
>
> Tangent, the online back and forth (claims) of the AlienCortex project
> and the PapilioOne are, as Bohr would say, interesting.

Well, I already bought the board!  It should ship Real Soon Now...  My hobby budget allows for no other board purchases in the near-term.

 From a technical perspective, I found the Papilio to be a PITA for newbie FPGA folks like me:
- It is little more than a breakout board.
- It lives in its own universe (no standard interconnects).
- It does little out-of-the-box (the FPGA doesn't even come programmed with a useful self-test demo).
However, for what it is, the Papilio is truly a decent piece of hardware at a great price.

Bryan's board, OTOH, screams "Use me!":
- On-board peripherals and interfaces are simple and generic, making them useful for multiple projects.
- Ease-of-use has been addressed at multiple levels:
   * The "Core-Pack" integrates several proven SoC-level ready-to-run projects in a cross-platform package that even integrates the programming tool on PS, Mac and Linux platforms (a real technical accomplishment).
   * Several ready-to-run soft processors are included.
   * Multi-core AVR support is provided, with 1, 2 and 4 cores supported.
   * For the AVR cores (both single and multi), free unlimited custom versions of 3 commercial compilers from MikroElektronika are included (quite a coup).

IMHO, and from my perspective and for my specific needs, Bryan's feature and value propositions excel on all levels, not just compared to Papilio, but also when compared to any other FPGA dev board available on the planet.  Digilent is the next closest I found, and it isn't all that close.  That is the only reason I'm Bryan's customer instead of Jack's or Digilent's: It's all about what I want for my own uses, how functional it is, and how I can get it all for the least money.  I became Bryan's backer on the day his KS project appeared:  The moment I saw it, I knew it was what I wanted.  At the time, I was literally a day or two away from placing an order for a Digilent board!

I've repeatedly communicated with both Bryan and Jack, and have read everything each has written publicly.  Bryan supports his arguments extremely well, and (to me) Jack doesn't.

It is actually worse than that: I believe Jack may have emotional issues that have spilled over into what should be a merit- and evidence-based discussion.  He uses innuendo and appeals to authority rather than stating clear dates and verifiable facts.  If he has a good argument to make, he has gotten in his own way while trying to make it.

Despite already having already backed Bryan's board, I contacted Jack when he started his own own KickStarter project (http://www.kickstarter.com/projects/13588168/papilio-fpga-shield-for-arduino) to try to help him see the limited appeal of his approach, and to warn him that his project would probably not exceed 50% of his goal (an amount I based on my analysis of other electronic KS projects).  I gave him a whole list of suggestions to improve his presentation and broaden his appeal (again, based on what I saw other successful projects do).  While he did slightly update the content of his video, he did nothing to make his overall pitch more attractive, to make his support levels more enticing, or to make his minimum monetary goal more realistic.  Not surprisingly, his KS project failed.  Quite surprisingly, it failed within 10% of my predicted yield!

Basically, it seems clear to me Jack didn't bother to do any due diligence investigation of the KS market, so he wound up creating a product and pitch that had little chance of success in that universe.  And even when I did an analysis for him, and freely shared my conclusions and recommendations, he generally ignored them (or he may have failed to comprehend them - he never questioned the reasoning behind my observations and suggestions).  The impression I was left with was simple: When it comes to his business, Jack doesn't play well with others.  He is the Commanding Officer, and he is alone on the bridge.  Which is totally his prerogative.  This matches well with Bryan's public descriptions of his interactions with Jack.

The thing is, I absolutely believe the market is more than big enough for *both* Jack and Bryan to succeed and even thrive (along with Seed Studios, SparkFun, AdaFruit, and all the others).  I also believe they should be 'coopetitors', innovating together (even selling each other's hardware) while each leaves the other to their own product focus.  Bryan has publicly wished Jack nothing but success, and has repeatedly encouraged him to innovate and compete, rather than complain.  Jack has never responded in kind.  Unless, of course, you take Jack's KS project to be a de-facto acknowledgment of, and agreement with, but poor copy of, Bryan's strategy, focus, features, and arguments.

If you look at the timeline of Bryan's and Jack's public actions and statements, a clear pattern emerges.  Jack's actions seem to run completely counter to his words:
- Jack creates Papilio
- Jack creates Papilio 'wings' with individual peripherals
- Bryan works (and lives!) with Jack
- Bryan and Jack part ways (with tension, but no acrimony at that time)
- Bryan designs some music-related sequencer and synthesizer boards, none reaching full implementation until the current board
- Bryan unveils his KickStarter project
- Internet bickering starts
- Jack, having previously rejected using KS (one of the reasons they parted ways) suddenly creates his own KS project with feature-for-feature functionality surprisingly equivalent to Bryan's, but without the tight product focus and OOBE:
   * Jack tries to sell a board that has no working prototype, compared to Bryan's fully tested board
   * Jack also adds an Arduino pin-out to the Papilio,  but fails to add 5V level shifters, making it incompatible with many Arduino shields
   * Jack also integrates SRAM on the board with the FPGA
   * Jack adds similar I/O integrated as a separate board, rather than integrating it into a single board
   * Jack creates the "Community Cores" vapor-ware to match the already-working Core-Pack
   * Jack sets his functionally equivalent kit price to be a close match to Bryan's

If jack had done any of this *before* Bryan's KS project existed, he'd at least have an evidence-based argument to make.  But instead he rushed out a half-baked 'me too' KS project that failed.

When Jack tried to accuse Bryan of using his work without attribution, Bryan correctly pointed out that the base Papilio is little more than a breakout board.  Bryan also made it very clear that every feature Jack complained about came either from published articles and/or app notes, all of which predated Jack's own Papilio work.  Bryan had the good taste *not* to accuse Jack of claiming all that 'prior art' as Jack's own work.  Jack's accusations of intellectual knowledge theft abruptly ceased immediately after Bryan's post.

The thing is, Jack makes much of his living from his GadgetFactory product line, and I would imagine any close competitor would be viewed as a direct threat to his livelihood.  I believe Bryan when he says that during his time with Jack he encouraged (maybe even nagged) Jack to expand beyond his current narrow 'hard-core' project market in two ways: 1) To make it easier for newbies to get started, and 2) to provide pre-integrated platform-level functionality out-of-the-box.  Jack disagreed, chose the direction he wanted his business to go, and he and Bryan parted ways.

I helped convince Bryan to find a better balance between Open licensing and closed business development, to use the 'delayed Open' release schedule and dual-licensing (used by many other companies in the Open space), along with an 'abandonment' release commitment.  I think this is precisely the right balance in today's economic and legal climate.  And *nothing* prevents *anyone* from reverse-engineering and cloning Bryan's hardware and software!  (I may even do so myself.)  All Bryan wants is a little bit of a head start based only on his own implementations: He is willing to go head-to-head with anybody and everybody.

I also convinced Bryan to ship a full schematic, complete BOM, and annotated VHD files with the board, holding back only the testbenches, Spice analysis, layout and Gerbers.  I simply showed him that, since his current board is 2-sided and uses the 3E PQ208, it is trivial to extract the schematic.  He wanted to go to 4-layers, but it would have delayed the ship date by at least a month.  (I'm amazed the board meets full timing specs with only two layers, but Bryan assures me it does.  Quite an engineering accomplishment!)

Based on my own experience with each of them, I can say Bryan is much more open to soliciting, responding to, and acting on external input than Jack.  At least when it comes to the specific kinds of input I provided to each of them.

Bryan has his own business goals, and he is a realist who knows how important the Open community is to his ultimate success.  All the functional and porting-related changes he has made to the Open cores in the Core-Pack will be published when the boards ship, as well as being offered as patches to the individual projects.  Bryan wants to delay all file releases as long as possible (until board ships) mainly to avoid releasing crap: He wants everything released in sync.  He also lacks the time to interact with the community: He intends to improve each product feature until the day the boards ship.  It is a simple legal fact that the release provisions of Open licenses don't apply until *after* a product is shipped, and not a moment before.

My own project, if successful, will be added to the to the Core-Pack, in addition to being released independently.  My secret agenda is to use that effort to encourage Bryan to release some/all of the Core-Pack platform code under an Open license by including in my release a self-installation script to wrap the generated binary.

I'm also on a mission for myHDL to be the default HDL for Bryan's board (much as the MikroE compilers are the default compilers), which is why I intend to document my project to death and make it as Open as possible.  I hope the combination of Bryan's platform and my project will make it the 'go-to' platform for myHDL education and evaluation.  The mention of myHDL on his KS project pages was also my doing.

My project can't really be completely board-agnostic simply because it needs an analog interface, and some planned synthesis spins will require buttons, serial and/or parallel interfaces, and even an integrated uP core (making it dependent on FPGA size).  Plus, I don't yet know enough to know *how* to make it board agnostic!   I intend to provide not only the project itself (files), but also port it to the first board.  I will be *very* happy if my project gets ported to work on the Papilio (and Digilent and and other FPGA dev boards), and to make it more generic and platform-agnostic.  I would gladly and thankfully review all patches submitted to make that happen!

But Bryan's boards will be shipping 'soon', and my project could easily take 6 months to get to its first full-featured functional release (remember, I am a newbie), though I intend to keep my development tree public so anyone can copy it whenever they wish (and provide help!).

-BobC

Re: [myhdl-list] myHDL First Project: Audio Effects System

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

My thoughts and opinions (opinions are like ...)

On 9/29/11 1:04 PM, Bob Cunningham wrote:
> I want to attack a useful stand-alone application as my first myHDL project, with the primary goal being to become intimately familiar with all aspects of the myHDL-to-hardware development process (making full use of the expertise captured on the myHDL site), and the secondary goal being to start learning digital design by examining the work of others and porting it to myHDL.
>
> To the greatest extent possible, code will be released under an appropriate Open license on OpenCores, GitHub and/or the myHDL site.
>
I would use GitHub or Bitbucket.  Clean interfaces and you have the 
potential to include interested parties outside of the MyHDL community. 
  The first item on you list should be determining the license you want 
to use.

<snip>
> B. Implementation constraints:
>    - Initial hardware target is a Spartan 3E-500-4 FPGA with external SRAM available.
>    - My initial dev board: http://www.kickstarter.com/projects/794668827/aliencortex-av
>    - Use PWM on a standard digital output with RC filter to implement a 44.1 KHz ~10-bit DAC.
>    - Use an LVDS comparator to implement a successive-approximation or sigma-delta 44.1 KHz ~10-bit ADC.
>    - Allow for future use of external ADCs/DACs (SPI, parallel) and other streaming data sources (PC, S/PDIF).

I would not use a kickstarter board, simply because your project is then 
dependent on the kickstarter project.

Personally, for a project like this I would make it board agnostic.  You 
haven't indicated anything that would tie you to a particular board.  I 
would focus on the project development versus the hardware platform but 
you provide "examples" for a particular board.  This also allows folks 
with other dev boards to participate without having to get the "project" 
board.

Tangent, the online back and forth (claims) of the AlienCortex project 
and the PapilioOne are, as Bohr would say, interesting.

<snip>

>
> Before going any further, I'd like to solicit suggestions and recommendations from the myHDL community:

There can be benefit of completely defining the goals and specification 
of a project and developing the project to the specification.  I think 
for this "project" you can start building the IP/cores/blocks. 
Completely define the interfaces required to build the system and 
completely define and document the cores as you build them.  Unless you 
are looking to do a kickstarter type project, I would start basic and 
create some inertia, keeping in mind you final goal.

Start simple:

   * Select your licensing scheme (source code and documentation)
   * Select your hosting site
   * Select one of the "cores" and *start* working on it.

I assume you are interested in building the project completely in 
Python/MyHDL versus system design, i.e. integrating a bunch of blocks. 
If that is the case, capture the overall project in a simple sentence or 
two and start building the IP for the project.

If you start with the DAC check out a previous MyHDL community member's 
work, http://www.myhdl.org/doku.php/projects:dsx1000.

>
> 1. Would you be interested in supporting this project with mentoring, infrastructure, and/or code?
>
> 2. I think I'd like to document project progress on a wiki.  Recommendations?  Alternatives?  Should I use a page on the myHDL wiki?  Or would a blog be better (possibly with a wiki)?
>

The wiki is a possible spot, also, Sphinx is a popular method for 
documenting Python projects.  Both GitHub and BitBucket support static 
pages where you can post the Sphinx output.

> 3. Is it OK to use the myHDL list as a forum for this project, or should it get its own facilities?

I don't see an issue (I am just one vote though).  If the day came were 
core development and user discussion activity is too high, I imagine a 
dev and user groups could be created.

Regards,
Chris Felton

>
> 4. What is this project missing?
>
>
> Thanks,
>
> -BobC
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1

[myhdl-list] myHDL First Project: Audio Effects System

[Bob C. <Fl...@gm...>]

I want to attack a useful stand-alone application as my first myHDL project, with the primary goal being to become intimately familiar with all aspects of the myHDL-to-hardware development process (making full use of the expertise captured on the myHDL site), and the secondary goal being to start learning digital design by examining the work of others and porting it to myHDL.

To the greatest extent possible, code will be released under an appropriate Open license on OpenCores, GitHub and/or the myHDL site.

I've chosen to implement an audio effects suite that would initially be suitable for use as a guitar pedal system or voice processor.  I have the following specific goals:

A. General specifications/scope:
  - Support line-level analog input and output.
  - Start with 44.1 KHz audio sample rate, sample width of ~10 bits.
  - Design should be parameterized for faster/wider analog data.
  - Allow for future resampling to support different input and output sample rates/widths.
  - Start with single audio channel I/O.
  - Allow for upgrades for multiple input and output channels and mixing.
  - Modular design for individual effects with a common streaming interface.
  - Effects built from a set of reusable mathematical/operational elements.
  - Allow for implementation optimizations to mux operating elements in time domain.
- Start with simple effects (echo, reverb, filtering).
  - Allow for more complex effects (e.g., pitch modification, auto-tune).
  - Start with a simple discrete button control interface.
  - Allow for multiple control interfaces: MIDI, SPI, parallel.
  - Allow for use by internal uP (e.g. http://opencores.org/project,avr_core)
  - Start with simple discrete LED status/configuration display.
  - Allow for output of current status/configuration (serial, parallel).
  - Allow for tracking net delay between input and output (effects modules would eventually need to report the delay they currently add to the process).
  - Allow for future inclusion of a VGA display (control, status, animated effects)

B. Implementation constraints:
  - Initial hardware target is a Spartan 3E-500-4 FPGA with external SRAM available.
  - My initial dev board: http://www.kickstarter.com/projects/794668827/aliencortex-av
  - Use PWM on a standard digital output with RC filter to implement a 44.1 KHz ~10-bit DAC.
  - Use an LVDS comparator to implement a successive-approximation or sigma-delta 44.1 KHz ~10-bit ADC.
  - Allow for future use of external ADCs/DACs (SPI, parallel) and other streaming data sources (PC, S/PDIF).


I have several reasons for choosing this project:
  - It's useful and fun.
  - It is relatively easy to understand.
  - It is a stand-alone system (minimal parts needed other than FPGA itself).
  - It is a true SoC, but a fairly simple one.
- It can be expanded almost without limit.
  - Data rates are slow enough to monitor with inexpensive equipment (PC, multimeter).
  - Real-time simulation/emulation possible with even slow PCs.
  - Relevant software and Verilog/VHDL code snippets are freely available, permitting initial development to focus more on architecture and process rather than detailed digital design.
  - Opportunities for cosimulation and mixed-signal simulation (Spice for external analog components).
  - Could eventually become an end-to-end myHDL hands-on tutorial.
  - Should be compatible with broad community participation.


I expect the system will have multiple implementation/elaboration cycles, starting with simple (perhaps inefficient) and progressing to sophisticated and highly optimized.  For example:
  - Implement DAC using PWM first, successive-approximation later.
  - Test DAC with canned data and multimeter (DC) or o'scope (AC).
  - Implement digital ADC using LVDS comparator: successive-approximation first, delta-sigma later.
  - Test ADC with resistor ladder (DC tests).
- Do Spice analog cosimulation of external components of ADC and DAC (optional).
  - Connect ADC input to DAC output.
  - Connect microphone and earbuds, test 'live'.
  - Measure delay between input and output.
  - Add fixed echo effect.
  - Test as isolated component.
  - Integrate with ADC/DAC.
  - Test as system.
  - Modify echo module and tests to support variable echo delay and decay times.
  - Use buttons to control echo module, and discrete LEDs to display state.
  - Add hiss (low-pass) filter effect.
  - Test in isolation.
  - Test as integrated system.
  - Test via cosimulation (optional).
  - Add mux/switch component to select effects and their order.
  - Update modules to use uniform streaming and control interfaces.
  - Add RS-232 status/control interface (for use by a person with a terminal program).
- Add more effects:
     - Import other HDL code (e.g. FIR filter) into a myHDL wrapper.
     - Add myHDL tests.
     - Port code from other HDL to myHDL.
  - Add SPI interface for use by external uP (make it look more like just another part).
- Add subsystem reuse in time domain (with state switching).
- Add basic VGA display.
  - Convert from a stand-alone component to a core.
  - Add AVR8 core (or, more correctly, add effects system as AVR8 peripheral on SoC).
  - Add software for more sophisticated and flexible operation (e.g., simpler external control).  (I really wish the embedded core could run Python...)

While the project goals are initially based on my own desires, I hope this project could eventually become an ideal gateway tutorial project for myHDL, since it creates a real product (not a toy example) that starts simple (and fully functional) and grows to a complete SoC, while hopefully requiring only minimal resources (few components, simple tools, no logic analyzer) and limited digital design skills (e.g., no SDRAM interface).


Before going any further, I'd like to solicit suggestions and recommendations from the myHDL community:

1. Would you be interested in supporting this project with mentoring, infrastructure, and/or code?

2. I think I'd like to document project progress on a wiki.  Recommendations?  Alternatives?  Should I use a page on the myHDL wiki?  Or would a blog be better (possibly with a wiki)?

3. Is it OK to use the myHDL list as a forum for this project, or should it get its own facilities?

4. What is this project missing?


Thanks,

-BobC

Re: [myhdl-list] Bug in MyHDL compiler?

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

On 09/27/2011 06:25 PM, David Greenberg wrote:
> Hi Jan, I'm trying to make register file that returns a read and
> write function, the former which will be synthesized as a verilog
> function and the latter as a task. I don't want to have to explicitly
> pass around the register file's signals. Does that make sense?

The proper way to implement such functionality would seem
to be classes and methods, not passing functions around explicitly.
(Supporting that in conversion is a different matter.)

-- 
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] Register file in MyHDL?

[David G. <dsg...@gm...>]

I think a good start would be to have this example work with
toVerilog/toVHDL. This is a 2 port register file with bypass logic.
I'd also like to move more of the signal definitions internal to the
register file (i.e. the read_* signals). Also, I'd like to make
writing to the file a function, but that would require some kind of
one-shot signal do support the equivalent functionality of write_do.
This would be possible by using another decorator to enable adding
code before and after the function to the generator, and then having
the write function be a parameter to that decorator that allows it to
initialize its guard.

Getting back to this example, I'd expect the following verilog to be
generated for read0:

task read0;
input [4:0] in;
output [31:0] out;
assign out = read_val0;
begin
  read_reg0 <= in;
end
endtask

I don't know if verilog supports putting the assign there or in the
begin/end pair, but I think the intent is clear. Getting this is the
first step towards having a basis to implement GAA.

from myhdl import *

def regfile(read_reg0, read_reg1,read_val0, read_val1, write_reg,
write_val, write_do, clk, funcs):
	"""
	regs is the number of registers in the file
	bits is the number of bits per register
	read_reg[01] is a signal of log2(regs) bits that selects the register
for output
	"""
	assert len(read_reg0) == len(read_reg1) == len(write_reg)
	assert len(write_do) == 1
	regBits = len(write_reg)
	regCount = 2**regBits
	bits = len(write_val)
	regs = [Signal(intbv(0)[bits:]) for x in range(regCount)]


	@always_comb
	def read0func():
		if write_do and write_reg == read_reg0:
			read_val0.next = write_val
		else:
			read_val0.next = regs[int(read_reg0)]
	@always_comb
	def read1func():
		if write_do and write_reg == read_reg1:
			read_val1.next = write_val
		else:
			read_val1.next = regs[int(read_reg1)]

	@always(clk.posedge)
	def writefunc():
		#print regs.join('\n')
		if write_do:
			regs[int(write_reg)].next = write_val

	def read0(reg):
		read_reg0.next = reg
		return read_val0

	def read1(reg):
		read_reg1.next = reg
		return read_val1

	return (read0func, read1func, writefunc), read0, read1, writereg

clk = Signal(bool(0))

@always(delay(10))
def clkgen():
	clk.next = not clk

def merger(clk):

	readport0 = Signal(intbv(0)[5:])
	readport1 = Signal(intbv(0)[5:])
	write_reg = Signal(intbv(0)[5:])
	write_val = Signal(intbv(0)[32:])
	write_do = Signal(bool(0))

	readval0 = Signal(intbv(0)[32:])
	readval1 = Signal(intbv(0)[32:])

	regfile_logic, read0, read1 = regfile(readport0, readport1, readval0,
readval1, write_reg, write_val, write_do, clk, iregfile)

	count = Signal(intbv(0)[4:])
	@always(clk.posedge)
	def logic():
		count.next = (count + 1) % 16
		if count == 0:
			write_reg.next = 3
			write_val.next = read0(3) + read1(4)
			write_do.next = True
		else:
			write_do.next = False

	return logic, regfile_logic

print toVerilog(merger, clk)


On Tue, Sep 27, 2011 at 4:53 PM, Jan Langer
<jan...@et...> wrote:
> Hi all,
>
> I think David's idea is great, although I never actively worked with
> Bluespec. But in my opinion it is nothing which should be part of
> MyHDL itself. MyHDL uses the same abstraction level (RTL) as VHDL and
> Verilog. However, MyHDL could be a great basis for implementing higher
> abstraction layers and mixing them.
>
> When I started my PhD work on synthesizing a special kind of temporal
> properties to RTL, I wished there would be a platform for this. I
> looked into MyHDL but I chose a more conventional way (parser of a
> specific language -> transformation -> VHDL writer). Mixing such an
> approach with other tools and methodologies is always complicated. It
> would be great to just implement your specific language as a domain
> specific language in Python and MyHDL and provide algorithms that
> transform your language dynamically to basic MyHDL constructs, that
> also allow conversion.
>
> A very comfortable example, but probably the most difficult would be
> algorithmic high-level synthesis from Python to hardware via MyHDL.
>
> n = Signal(intbv(0))
> start = Signal(bool(0))
> ready = signal(bool(0))
> out = Signal(intbv(0))
>
> @algorithmic(clk,n,start,out,ready)
> def faculty():
>        s = intbv(1)
>        for i in range(2,n+1):
>                s *= i
>        return s
>
> would become something along the lines of
>
> counter = Signal(intbv(0))
> s = signal(intbv(0))
>
> @always(clk.posedge)
> def faculty():
>        if counter == 0:
>                if start:
>                        counter.next = n
>                ready.next = False
>        elif counter > 1:
>                s.next = s * counter
>                counter.next = counter - 1
>                ready.next = False
>        else:
>                out.next = s
>                s.next = 0
>                ready.next = True
>
> This would open a whole world of cool things. The work David is
> proposing could be a first step in this direction, exploring how MyHDL
> will fit into the picture. I hope my thoughts were not too
> confusing. :-)
>
> Jan
>
> Am 27.09.2011 um 18:23 schrieb Jan Decaluwe:
>> On 09/27/2011 02:12 AM, David Greenberg wrote:
>>> Have you ever heard of Guarded Atomic Actions?
>>
>> No, so I'm not sure I understand much of what your are saying.
>>
>> I have difficulties understanding how those guards
>> would map to MyHDL semantics, and in particular, whether
>> the code you show can work as you expect.
>>
>> I assume guards mean "waiting" for something. In MyHDL, I
>> see two ways to accomplish that: in RTL style with an FSM,
>> or in behavioral style with yield statements and generators.
>> I see neither in the code you show for those guards.
>
> --
> Jan Langer
> Professorship Circuit and System Design
> Chemnitz University of Technology, Reichenhainer Str. 70, 09126 Chemnitz
> Phone: +49 37209 688001, Fax: +49 371 531-833158, Mobile: +49 162
> 9847325
> http://www.tu-chemnitz.de/etit/sse
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Register file in MyHDL?

[Jan L. <jan...@et...>]

Hi all,

I think David's idea is great, although I never actively worked with  
Bluespec. But in my opinion it is nothing which should be part of  
MyHDL itself. MyHDL uses the same abstraction level (RTL) as VHDL and  
Verilog. However, MyHDL could be a great basis for implementing higher  
abstraction layers and mixing them.

When I started my PhD work on synthesizing a special kind of temporal  
properties to RTL, I wished there would be a platform for this. I  
looked into MyHDL but I chose a more conventional way (parser of a  
specific language -> transformation -> VHDL writer). Mixing such an  
approach with other tools and methodologies is always complicated. It  
would be great to just implement your specific language as a domain  
specific language in Python and MyHDL and provide algorithms that  
transform your language dynamically to basic MyHDL constructs, that  
also allow conversion.

A very comfortable example, but probably the most difficult would be  
algorithmic high-level synthesis from Python to hardware via MyHDL.

n = Signal(intbv(0))
start = Signal(bool(0))
ready = signal(bool(0))
out = Signal(intbv(0))

@algorithmic(clk,n,start,out,ready)
def faculty():
	s = intbv(1)
	for i in range(2,n+1):
		s *= i
	return s

would become something along the lines of

counter = Signal(intbv(0))
s = signal(intbv(0))

@always(clk.posedge)
def faculty():
	if counter == 0:
		if start:
			counter.next = n
		ready.next = False
	elif counter > 1:
		s.next = s * counter
		counter.next = counter - 1
		ready.next = False
	else:
		out.next = s
		s.next = 0
		ready.next = True

This would open a whole world of cool things. The work David is  
proposing could be a first step in this direction, exploring how MyHDL  
will fit into the picture. I hope my thoughts were not too  
confusing. :-)

Jan

Am 27.09.2011 um 18:23 schrieb Jan Decaluwe:
> On 09/27/2011 02:12 AM, David Greenberg wrote:
>> Have you ever heard of Guarded Atomic Actions?
>
> No, so I'm not sure I understand much of what your are saying.
>
> I have difficulties understanding how those guards
> would map to MyHDL semantics, and in particular, whether
> the code you show can work as you expect.
>
> I assume guards mean "waiting" for something. In MyHDL, I
> see two ways to accomplish that: in RTL style with an FSM,
> or in behavioral style with yield statements and generators.
> I see neither in the code you show for those guards.

-- 
Jan Langer
Professorship Circuit and System Design
Chemnitz University of Technology, Reichenhainer Str. 70, 09126 Chemnitz
Phone: +49 37209 688001, Fax: +49 371 531-833158, Mobile: +49 162  
9847325
http://www.tu-chemnitz.de/etit/sse

Re: [myhdl-list] Bug in MyHDL compiler?

[David G. <dsg...@gm...>]

Hi Jan,
I'm trying to make register file that returns a read and write
function, the former which will be synthesized as a verilog function
and the latter as a task. I don't want to have to explicitly pass
around the register file's signals. Does that make sense?

Sent from my iPhone

On Sep 27, 2011, at 10:59 AM, Jan Decaluwe <ja...@ja...> wrote:

> On 09/27/2011 02:10 PM, David Greenberg wrote:
>> While considering other approaches for a register file, if I could
>> return functions that would be synthesized into tasks, then I could
>> have a very similar interface to the one I imagined.
>>
>> It seems that the hierarchy extractor could ignore these unknown
>> objects as long as they're used only during the elaboration phase.
>> Is there a technical reason this isn't done?
>
> I'm not very proud on the hierarchy extraction code, which I find
> tricky and confusing. I have tried to simplify it before, by
> imposing tougher restrictions on what it supports.
>
> The problem is that I use the general Python profiler. During
> profiling, all functions get traced. Currently, the only way
> I have to differentiate between general functions and those
> used to define MyHDL structure, is by looking at the return
> type.
>
> I assume that users will want this distinction, and therefore
> I consider anything that doesn't strictly comply with the
> definition of a MyHDL instance as something that doesn't
> participate in the structure.
>
> I don't understand exactly what you try to accomplish but
> there may be ways to do it today without changes. For
> example, you can play scoping games with top-level signals,
> and pass function as parameters etc. The convertor
> doesn't care, as long as it's in the elaboration phase.
>
> --
> 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
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Register file in MyHDL?

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

On 09/27/2011 02:12 AM, David Greenberg wrote:
> Have you ever heard of Guarded Atomic Actions?

No, so I'm not sure I understand much of what your are saying.

I have difficulties understanding how those guards
would map to MyHDL semantics, and in particular, whether
the code you show can work as you expect.

I assume guards mean "waiting" for something. In MyHDL, I
see two ways to accomplish that: in RTL style with an FSM,
or in behavioral style with yield statements and generators.
I see neither in the code you show for those guards.

-- 
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] Bug in MyHDL compiler?

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

On 09/27/2011 02:10 PM, David Greenberg wrote:
> While considering other approaches for a register file, if I could
> return functions that would be synthesized into tasks, then I could
> have a very similar interface to the one I imagined.
>
> It seems that the hierarchy extractor could ignore these unknown
> objects as long as they're used only during the elaboration phase.
> Is there a technical reason this isn't done?

I'm not very proud on the hierarchy extraction code, which I find
tricky and confusing. I have tried to simplify it before, by
imposing tougher restrictions on what it supports.

The problem is that I use the general Python profiler. During
profiling, all functions get traced. Currently, the only way
I have to differentiate between general functions and those
used to define MyHDL structure, is by looking at the return
type.

I assume that users will want this distinction, and therefore
I consider anything that doesn't strictly comply with the
definition of a MyHDL instance as something that doesn't
participate in the structure.

I don't understand exactly what you try to accomplish but
there may be ways to do it today without changes. For
example, you can play scoping games with top-level signals,
and pass function as parameters etc. The convertor
doesn't care, as long as it's in the elaboration phase.

-- 
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] Bug in MyHDL compiler?

[David G. <dsg...@gm...>]

While considering other approaches for a register file, if I could
return functions that would be synthesized into tasks, then I could
have a very similar interface to the one I imagined.

It seems that the hierarchy extractor could ignore these unknown
objects as long as they're used only during the elaboration phase.  Is
there a technical reason this isn't done? I'd like to extend MyHDL to
support this. If you could just give me a pointer or two to get
started it'd make this easier for me (I have some experience in
compiler implementation)

1) I think that if I modify the _ConvertVisitor to treat non-instance
functions as either being ignored or the same as other functions, this
would work, since MyHDL doesn't generate hierarchy, so the returned
function would be accessible from the outer scope in the generated
code.

2) Would it be more effective to make another subclass of
ast.NodeVisitor and have all of the code generator/waveform viewer
visitors inherit from the subclass of NodeVisitor instead of
NodeVisitor itself?

3) Does the waveform analyzer require something different for this?

Thanks,
David

On Tue, Sep 27, 2011 at 3:46 AM, Jan Decaluwe <ja...@ja...> wrote:
> On 09/27/2011 06:13 AM, David Greenberg wrote:
>> When I try to run the following code in a file, it terminates with an
>> error. It appears to occur when a memory list is used in a function
>> that doesn't return something directly executable,
>
> Hierarchy extraction (used for lower level tasks like conversion
> and waveform tracing) doesn't work for things that are not strictly
> instances according to MyHDL definition:
>
>     http://www.myhdl.org/doc/current/manual/modeling.html#structural-modeling
>
>
>
>
> --
> 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
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Register file in MyHDL?

[David G. <dsg...@gm...>]

Hey Chris,
I know your answer wasn't flippant, but I wanted to clarify where I
was coming from and the synthesizable behavior I was expecting with
the code I wrote.

On Tue, Sep 27, 2011 at 7:33 AM, Christopher Felton
<chr...@gm...> wrote:
> On 9/26/11 7:12 PM, David Greenberg wrote:
>> Have you ever heard of Guarded Atomic Actions? It's a model that lets
>> you map classes/methods into sythesizable constructs. Essentially, a
>> method has 2 implicit signals, "ready" and "start". When you call a
>> method, the "ready" signal is used as a guard, so that the logic using
>> that method call is transformed as follows:
>
> This is an interesting spin on the thread.  Your original question had
> nothing to do with HLS.  My response was appropriate for your question
> and not flippant.
>
> Chris
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Register file in MyHDL?

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

On 9/26/11 7:12 PM, David Greenberg wrote:
> Have you ever heard of Guarded Atomic Actions? It's a model that lets
> you map classes/methods into sythesizable constructs. Essentially, a
> method has 2 implicit signals, "ready" and "start". When you call a
> method, the "ready" signal is used as a guard, so that the logic using
> that method call is transformed as follows:

This is an interesting spin on the thread.  Your original question had 
nothing to do with HLS.  My response was appropriate for your question 
and not flippant.

Chris