myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Re: Cosimulation with the simple FSM example.

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

Brendan Rankin wrote:
> Brendan Rankin <brendan.rankin <at> gmail.com> writes:
> 
> 
>>Please let me know if you spot anything that you feel is in err.
>>
>>Thanks, in advance, and Best Regards,
>>
>>- Brendan
> 
> 
> 
> Nevermind.  Found the "x" issue.  For every clock, prior to the reset event, the
> state was being assigned x's.

Yes, this is a classical initialization issue: a difference between
the initial value of a high-level type (some enum item) and its
low level equivalent ('x').

At some point, I used initial values in reg declaration in the
Verilog output, as supported by recent Verilogs. This
would solve this issue (but of course it would mask potential
reset problems, just like in the high-level code). However,
it turns out that many currently used tools don't support
them yet. So I took this out for now.

Thinking about it, for implementation purposes it may be
better to collapse the final state with the default
case (the 'else' in MyHDL), or remove the default
alltogether.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: Cosimulation with the simple FSM example.

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

George Pantazopoulos wrote:

> Yeah, I think I will try that. Also, I want to try making it easier to do
> co-simulation/unit testing. I'm doing my project for fun, and often I feel
> it hampers the fun and creativity if I have to write up (and debug!) a
> unit test every time I add or change a component.

I understand completely. We're engineers, and we want results asap.

I think the expected lifetime of your project is important. Take
my case with MyHDL itself for example. I knew that it would be a
long-going project and that sometimes I may not touch it for months.
What unit tests give me is that I have at least a basic level of
confidence to change things (perhaps after a long period
of inactivity). Without them, the project would be one big mess by now,
I'm sure. While I am writing unit tests, they often seem trivial,
or overhead, but they really are not. On numerous occasions, they
have prevented me from creating new or re-creating old bugs.

Note that I'm also using the XP technique of first writing the test,
see it fail, and then add or adapt the implementation to make it
work. This is fun and enhances confidence.

Often we tend to underestimate the lifetime of a project (this may be
your case :-)) In such cases, under-verification creates uncertainties
and bugs that will hamper productiviy in the longer run. Your decision
not to use enum types may be an example :-)

> I feel my last attempt at incorporating unit testing in my design flow was
> somewhat successful, however I really didn't like having to spend time
> debugging the unit tests themselves! This may be easier now that I'm more
> experienced with Python, myHDL, co-simulation, and hardware design (that's
> a lot of things to learn at once, on top of extreme programming!). Unit
> testing and co-simulating *everything* still doesn't feel natural to me,
> and I'm not sure if it ever will.
> 
> Speaking of promotional breaks, have you seen the new colorful photos I
> took of my project? :-)
> 
> http://myhdl.jandecaluwe.com/doku.php/projects:phoenixsid_65x81

Sure, thanks for those. They convincingly illustrate that MyHDL
is a practical tool that can be used for real engineering projects.
Which is exactly what I want it to be.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: Cosimulation with the simple FSM example.

[Brendan R. <bre...@gm...>]

Brendan Rankin <brendan.rankin <at> gmail.com> writes:

> In the meantime, may I suggest demoting this to a informational message,
> rather than raising an exception?

Oops.... sorry.  I'm not being clear!  I think the "x" propagation thing is
already under user control and _should_ remain as is.  I think the enum
cosimulation reverse-mapping should be demoted to a warning, rather than raising
an exception, though I don't have strong feelings about it.

Cheers,

- Brendan

[myhdl-list] Re: Cosimulation with the simple FSM example.

[Brendan R. <bre...@gm...>]

Brendan Rankin <brendan.rankin <at> gmail.com> writes:

> 
> Please let me know if you spot anything that you feel is in err.
> 
> Thanks, in advance, and Best Regards,
> 
> - Brendan


Nevermind.  Found the "x" issue.  For every clock, prior to the reset event, the
state was being assigned x's.

I'll still take a look at the enum thing, even though it's more of a "nice to
have".  In the meantime, may I suggest demoting this to a informational message,
rather than raising an exception?

Cheers,

- Brendan

Thanks,

- Brendan

Re: [myhdl-list] Re: Cosimulation with the simple FSM example.

[George P. <ge...@ga...>]

>  > In one of my modules where I tried using the enum, I
>  > noticed that I got incorrect behavior (incorrect initial states, I
>  > believe) if I didn't specify the encoding style. It worked correctly
>  > when I specified 'encoding=3Done_cold'. I haven't tried other encodi=
ng
>  > styles.
>
>> This was in the synthesized hardware (Xilinx ISE w/XST). I didn't
>> co-simulate this module. Is this dependence on encoding type something
>> to
>> be expected when doing synthesis?
>
> Certainly not. It should always work. Out of the 3 possible encodings
> the default (binary) is the "least risky": as the initial
> state will be all zero's (often the default in fpga's), things may stil=
l
> work when your reset sequence doesn't work as it should. Moreover,
> once in the Verilog domain, binary encoding is basically identical
> to the simplest use of plain integers. So the problems you report
> are the opposite of what I would expect, and I haven't a clue
> on what went wrong.
>
> Cosimulation may help to clarify things in the future :-)
>
> Jan

Yeah, I think I will try that. Also, I want to try making it easier to do
co-simulation/unit testing. I'm doing my project for fun, and often I fee=
l
it hampers the fun and creativity if I have to write up (and debug!) a
unit test every time I add or change a component.

I feel my last attempt at incorporating unit testing in my design flow wa=
s
somewhat successful, however I really didn't like having to spend time
debugging the unit tests themselves! This may be easier now that I'm more
experienced with Python, myHDL, co-simulation, and hardware design (that'=
s
a lot of things to learn at once, on top of extreme programming!). Unit
testing and co-simulating *everything* still doesn't feel natural to me,
and I'm not sure if it ever will.

Speaking of promotional breaks, have you seen the new colorful photos I
took of my project? :-)

http://myhdl.jandecaluwe.com/doku.php/projects:phoenixsid_65x81

George

[myhdl-list] Re: Cosimulation with the simple FSM example.

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

George Pantazopoulos wrote:
>>====Begin====
>>from myhdl import *
>>
>>t_State = enum('SEARCH', 'CONFIRM', 'SYNC', encoding='one_hot')
>>ACTIVE_LOW = 0
>>FRAME_SIZE = 8
>>
> 
> 
> Jan,
> 
>   Ever since trying myHDL I've been using plain integers to define states
> for all my code.

Ok, let's insert a promotional break then :-)
Despite the issues (when going to low-level Verilog), I believe enum
is a very valuable high-level thing - it's in MyHDL because I liked it
so much in VHDL. Moreover, the possibility to specify the encoding
in MyHDL (basically giving you a trade-off between nr of flipflops
and logic delay right from the high-level code) is a unique feature,
that I always had wanted when still doing VHDL/Verilog/Synopsys.

 > In one of my modules where I tried using the enum, I
 > noticed that I got incorrect behavior (incorrect initial states, I
 > believe) if I didn't specify the encoding style. It worked correctly
 > when I specified 'encoding=one_cold'. I haven't tried other encoding
 > styles.

> This was in the synthesized hardware (Xilinx ISE w/XST). I didn't
> co-simulate this module. Is this dependence on encoding type something to
> be expected when doing synthesis? 

Certainly not. It should always work. Out of the 3 possible encodings
the default (binary) is the "least risky": as the initial
state will be all zero's (often the default in fpga's), things may still
work when your reset sequence doesn't work as it should. Moreover,
once in the Verilog domain, binary encoding is basically identical
to the simplest use of plain integers. So the problems you report
are the opposite of what I would expect, and I haven't a clue
on what went wrong.

Cosimulation may help to clarify things in the future :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: Cosimulation with the simple FSM example.

[George P. <ge...@ga...>]

> =3D=3D=3D=3DBegin=3D=3D=3D=3D
> from myhdl import *
>
> t_State =3D enum('SEARCH', 'CONFIRM', 'SYNC', encoding=3D'one_hot')
> ACTIVE_LOW =3D 0
> FRAME_SIZE =3D 8
>

Jan,

  Ever since trying myHDL I've been using plain integers to define states
for all my code. In one of my modules where I tried using the enum, I
noticed that I got incorrect behavior (incorrect initial states, I
believe) if I didn't specify the encoding style. It worked correctly
when I specified 'encoding=3Done_cold'. I haven't tried other encoding
styles.

This was in the synthesized hardware (Xilinx ISE w/XST). I didn't
co-simulate this module. Is this dependence on encoding type something to
be expected when doing synthesis? I don't have the code ready to paste
(though I could possibly get something together) I'm just asking in
general.

Thanks,
George

[myhdl-list] Re: Cosimulation with the simple FSM example.

[Brendan R. <bre...@gm...>]

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> Please consider posting the code you're using. It always saves time
> when troubleshooting.
> 
> Best regards,
> 
> Jan

Jan,

I'll probably enhance the enum type in the near future to better handle this.
It's not a big deal anyway....  

Here's the code you requested -- Python code that simulates the FSM and
generates the Verilog, first:

====Begin====
from myhdl import *

t_State = enum('SEARCH', 'CONFIRM', 'SYNC', encoding='one_hot')
ACTIVE_LOW = 0
FRAME_SIZE = 8

def FramerCtrl(SOF, state, syncFlag, clk, reset_n):
   """Framing control FSM.

   SOF => start-of-frame output bit
   state => FramerState output
   syncFlag => sync pattern found indication bit
   clk => clock input
   reset_n => active low reset
   """

   index = Signal(intbv(0)[8:]) #position in frame...
   
   @always(clk.posedge, reset_n.negedge)
   def FSM():
      if reset_n == ACTIVE_LOW:
         SOF.next = 0
         index.next = 0
         state.next = t_State.SEARCH
         
      else:
         index.next = (index + 1) % FRAME_SIZE
         SOF.next = 0

         
         if state == t_State.SEARCH:
            index.next = 1
            if syncFlag:
               state.next = t_State.CONFIRM

               
         elif state == t_State.CONFIRM:
            if index == 0:
               if syncFlag:
                  state.next = t_State.SYNC
               else:
                  state.next = t_State.SEARCH

                     
         elif state == t_State.SYNC:
            if index == 0:
               if not syncFlag:
                  state.next = t_State.SEARCH
            SOF.next = (index == FRAME_SIZE-1)

               
         else:
            print "State = %" % state
            raise ValueError("Undefined state")

   return FSM

def testbench():
   SOF = Signal(bool(0))
   syncFlag = Signal(bool(0))
   clk = Signal(bool(0))
   reset_n = Signal(bool(1))
   state = Signal(t_State.SEARCH)

   framerctrl = FramerCtrl(SOF, state, syncFlag, clk, reset_n)

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

   @instance
   def stimulus():
      reset_n.next = 1
      yield delay(50)
      reset_n.next = 0
      yield delay(50)
      reset_n.next = 1
      for i in range(20):
         yield clk.posedge
      for n in (12, 8, 8, 4):
         syncFlag.next = 1
         yield clk.posedge
         syncFlag.next = 0
         for i in range(n-1):
            yield clk.posedge
      raise StopSimulation

   return framerctrl, clkgen, stimulus

def GenWaveform():
   tb_fsm = traceSignals(testbench)
   sim = Simulation(tb_fsm)
   sim.run()

def GenVerilog():
   SOF = Signal(bool(0))
   syncFlag = Signal(bool(0))
   clk = Signal(bool(0))
   reset_n = Signal(bool(1))
   state = Signal(t_State.SEARCH)
   frmrctrl_inst = toVerilog(FramerCtrl, SOF, state, 
                             syncFlag, clk, reset_n)

GenWaveform()
GenVerilog()
=====End=====

Here, also, are the simple changes I made to cosimulate:

=====Begin=====
cmd = "iverilog -o FramerCtrl.o " + \
      "FramerCtrl.v " + \
      "tb_FramerCtrl.v "

def FramerCtrl(SOF, state, syncFlag, clk, reset_n):
   os.system(cmd)
   return Cosimulation("vvp -m <some_long_path>/myhdl.vpi FramerCtrl.o",
                        SOF=SOF, state=state, syncFlag=syncFlag,
                        clk=clk, reset_n=reset_n)
=====End=====

Please let me know if you spot anything that you feel is in err.

Thanks, in advance, and Best Regards,

- Brendan

[myhdl-list] Re: Cosimulation with the simple FSM example.

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

Brendan Rankin wrote:
> I'm having some issues getting cosimulation to work with the simple FSM example
> an d Icarus.  I have two issues:
> 
> 1.  I'm seeing an 'x' being assigned to the state value, at some point.
>     - I can get around this by removing the $finish from the casez statement in
> the generated Verilog.
>     - I suspect that this issue is due to the active-inactive transition of
> reset_n.  If so, then it's not an issue at all.

It's not clear to me what's happening. It would be useful to see the
exact code you're using, including the testbench.

> 2.  It appears that the enum'ed state types are not being properly de-enum'ed. 
> I get the following traceback:

> I can work around this, as well, by simply changing this exception to a print
> statement, but it would be nice to have a "fix" for this one.  It does appear
> that I'm seeing the values of SEARCH, CONFIRM, SYNC...but these are not being
> converted to the expected type _enum.

Enum is a high-level type with no direct equivalent in Verilog. So the
Verilog convertor maps enum items to encoded values. So there is some
information loss.

Co-simulation has no idea that the Verilog you co-simulate came from a
MyHDL conversion, or that you wrote it by hand. So it cannot
automatically map the encodings back to the high-level type -
you have to do that explicitly (by a map from encodings to
enum items, in the MyHDL domain).

Thinking about it, I guess that the Enum type should offer some
help to make this easier, that is, offer some kind of an interface
to retrieve an enum item based on its encoding. But currently
it doesn't.

> Unless I'm doing something terribly wrong, you should be able to duplicate this
> by simply trying to cosimulate the FSM example with Icarus.

Please consider posting the code you're using. It always saves time
when troubleshooting.

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Cosimulation with the simple FSM example.

[Brendan R. <bre...@gm...>]

I'm having some issues getting cosimulation to work with the simple FSM example
an d Icarus.  I have two issues:

1.  I'm seeing an 'x' being assigned to the state value, at some point.
    - I can get around this by removing the $finish from the casez statement in
the generated Verilog.
    - I suspect that this issue is due to the active-inactive transition of
reset_n.  If so, then it's not an issue at all.
2.  It appears that the enum'ed state types are not being properly de-enum'ed. 
I get the following traceback:

Traceback (most recent call last):
  File "./FSM_Example_cosim.py", line 63, in ?
    GenWaveform()
  File "./FSM_Example_cosim.py", line 53, in GenWaveform
    sim.run()
  File "/home/brendan/lib/python/myhdl/_Simulation.py", line 137, in run
    cosim._get()
  File "/home/brendan/lib/python/myhdl/_Cosimulation.py", line 144, in _get
    s.next = next
  File "/home/brendan/lib/python/myhdl/_Signal.py", line 172, in _set_next
    self._setNextVal(val)
  File "/home/brendan/lib/python/myhdl/_Signal.py", line 226, in _setNextType
    raise TypeError("Expected %s, got %s" % (self._type, type(val)))
TypeError: Expected <class 'myhdl._enum.EnumItem'>, got <type 'int'>

I can work around this, as well, by simply changing this exception to a print
statement, but it would be nice to have a "fix" for this one.  It does appear
that I'm seeing the values of SEARCH, CONFIRM, SYNC...but these are not being
converted to the expected type _enum.

Unless I'm doing something terribly wrong, you should be able to duplicate this
by simply trying to cosimulate the FSM example with Icarus.

Please let me know if you need any further information from me.  I am using the
0.5 version of MyHDL and the 0.8.1 version of Icarus.

Best Regards, and Thanks for the great tool.  I'm sure I'll have plenty of use
for it, now, and in the future!

- Brendan

Re: [myhdl-list] Re: MyHDL 0.5 released

[George P. <ge...@ga...>]

>>>
>>> I have released MyHDL 0.5 on SourceForge.
>>>
>> Congratulations Jan! How else do you plan on promoting MyHDL?
>
>
> 1) announcements in selected news forums
> 2) Set up Google AdWords campaign (done)
> 3) How-to article on http://www.pldesignline.com/
>
> Thanks to Tom Dillon, I have been invited to publish a
> How-to article about MyHDL on this on-line publication.
> I have deliberately postponed it until MyHDL 0.5 was out, but
> it's the first thing I would like to do now. Nothing has
> been done yet, and I'll discuss it in more detail later
> in this forum.
>
Excellent! Let me know if you need anyone to proofread it :)

George

[myhdl-list] Re: MyHDL 0.5 released

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

George Pantazopoulos wrote:
>> Hi all:
>>
>> I have released MyHDL 0.5 on SourceForge.
>>
> Congratulations Jan! How else do you plan on promoting MyHDL?

1) announcements in selected news forums

I have prepared an extensive announcement that I post to the
following forums:

geda-announce (done)
comp.lang.verilog (done)
comp.lang.fpga
comp.lang.python.announce

I do the announcements in stages to get an idea of the impact
(in terms of downloads). For completeness, I have just posted
the announcement to this forum also. Sometimes I add a sentence
that targets the public of a particular forum.

2) Set up Google AdWords campaign (done)

I have no idea whether this is meaningful, but in any case,
the idea seems fun. I am intrigued on how AdWords
works, and as there's no substitute for experience, I decided
to set up a campaign on this occasion.

3) How-to article on http://www.pldesignline.com/

Thanks to Tom Dillon, I have been invited to publish a
How-to article about MyHDL on this on-line publication.
I have deliberately postponed it until MyHDL 0.5 was out, but
it's the first thing I would like to do now. Nothing has
been done yet, and I'll discuss it in more detail later
in this forum.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] [ANNOUNCE] MyHDL 0.5 released

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

Hi all:

I'm pleased to announce the release of MyHDL 0.5.

MyHDL is an open-source package for using Python as a hardware
description and verification language. Moreover, it can convert
a design to Verilog. Thus, MyHDL provides a complete path
from Python to silicon.

MyHDL 0.5 has many new features, in particular with regard to
conversion to Verilog. The converter automates certain tasks
that are hard in Verilog directly.

For a complete overview, go here:
   http://myhdl.jandecaluwe.com/doku.php/overview

The manual is here:
   http://www.jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html

To find out the details of what's new, go here:
   http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5

You can download the release from SourceForge:
   http://sourceforge.net/project/showfiles.php?group_id=91207

Best regards,

Jan Decaluwe

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] MyHDL 0.5 released

[George P. <ge...@ga...>]

> Hi all:
>
> I have released MyHDL 0.5 on SourceForge.
>
Congratulations Jan! How else do you plan on promoting MyHDL?

George

[myhdl-list] MyHDL 0.5 released

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

Hi all:

I have released MyHDL 0.5 on SourceForge.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] MyHDL 0.5 released

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

Hi all:

I have released MyHDL 0.5 on SourceForge.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: MyHDL 0.5 promotion

[George P. <ge...@ga...>]

> Yes - it seems uploading is disabled by default for users.
> I have now turned it on - does it work now?
>
Yup, I took some pictures of my setup and put them up!
http://myhdl.jandecaluwe.com/doku.php/projects:phoenixsid_65x81

I haven't yet figured out how to delete files :)

George

[myhdl-list] Re: MyHDL 0.5 promotion

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

George Pantazopoulos wrote:
> Nice! How would I go uploading pictures to the wiki?
> 
>>
>> There is an media file upload button (with balloon text)
>> from the editor.
>>
> 
> The button "Add images or other files" opens a pop-up window that only 
> lets me select from some existing files. This document says you probably 
> have to add permission to upload files:

Yes - it seems uploading is disabled by default for users.
I have now turned it on - does it work now?


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: MyHDL 0.5 promotion

[George P. <ge...@ga...>]

Nice! How would I go uploading pictures to the wiki?

>
> There is an media file upload button (with balloon text)
> from the editor.
>

The button "Add images or other files" opens a pop-up window that only 
lets me select from some existing files. This document says you probably 
have to add permission to upload files:

http://wiki.splitbrain.org/wiki:acl

Thanks,
George

[myhdl-list] Re: MyHDL 0.5 promotion

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

George Pantazopoulos wrote:

> Speaking of wiki's I think MoinMoin is a much better (looking and 
> functioning) wiki than docuwiki. Just a thought, since you've been 
> putting more work into promotion :) It's also easy to install

Even though the "looks" are "just" a stylesheet, not directly related
to the wiki engine itself, I find that quite surprizing. When I was
looking for a suitable wiki engine, dokuwiki was one of the very few
with a default look that seemed attractive and "professional" to me.
(It seems the default stylesheet borrows a lot from a Python CMS
tool, Plone, btw). MoinMoin's look I didn't like, certainly not
the incarnation on the python website.

More importantly, most wiki engines, including dokuwiki, seemed to
miss some features that I consider essential, such as a sidebar
for navigation (but not only that). I have put in quite some
work to add those missing features to dokuwiki myself. For the
details, see:

     http://www.jandecaluwe.com/testwiki/doku.php/navigation:intro

Of course I would have preferred a Python tool instead of php. But,
dare I admit it, my websites are on yahoo. No Python there. Yahoo
hosting may have been a bad decision in the past, but on the other
hand, php is (unfortunately) the lingua franca of the net, so I'm
confident it will be a nobrainer to rehost the websites if necessary.

Personally I'm quite happy with the current solution - it is now
what I looked for. Therefore, in the near future I have no plans for
more wiki-related or website-related efforts or changes. (Maintaining
content and keeping the tools current is enough work.) Also, next year
I will probably have less "open-source" time available, and I plan to
devote it to MyHDL itself.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: MyHDL 0.5 promotion

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

George Pantazopoulos wrote:
> 
>> MyHDL 0.5 will be released shortly.
>>
>> I would like to take some actions to promote it to potential
>> new users. I'm convinced the best promotion is examples
>> of real users doing real projects.
>>
>> Therefore, if you're doing a project in which MyHDL is
>> used, and if you're not there yet, please consider adding
>> it to the Users & Projects page (or even create a
>> separate page). Of course, you can also simply mail the
>> info to me and I'll add it, no problem.
>>
>> Thanks!
>>
> Nice! How would I go uploading pictures to the wiki? 

There is an media file upload button (with balloon text)
from the editor.

> Does it do thumbnail previews?

You can resize images from a link, see the wiki:syntax page.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] MyHDL 0.5 promotion

[George P. <ge...@ga...>]

> which MyHDL is
> used, and if you're not there yet, please consider adding
> it to the Users & Projects page (or even create a
> separate page). Of course, you can also simply mail the
> info to me and I'll add it, no problem.

Speaking of wiki's I think MoinMoin is a much better (looking and 
functioning) wiki than docuwiki. Just a thought, since you've been 
putting more work into promotion :) It's also easy to install

George

Re: [myhdl-list] MyHDL 0.5 promotion

[George P. <ge...@ga...>]

> MyHDL 0.5 will be released shortly.
>
> I would like to take some actions to promote it to potential
> new users. I'm convinced the best promotion is examples
> of real users doing real projects.
>
> Therefore, if you're doing a project in which MyHDL is
> used, and if you're not there yet, please consider adding
> it to the Users & Projects page (or even create a
> separate page). Of course, you can also simply mail the
> info to me and I'll add it, no problem.
>
> Thanks!
>
Nice! How would I go uploading pictures to the wiki? Does it do 
thumbnail previews?

George

[myhdl-list] MyHDL 0.5 promotion

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

Hi all:

MyHDL 0.5 will be released shortly.

I would like to take some actions to promote it to potential
new users. I'm convinced the best promotion is examples
of real users doing real projects.

Therefore, if you're doing a project in which MyHDL is
used, and if you're not there yet, please consider adding
it to the Users & Projects page (or even create a
separate page). Of course, you can also simply mail the
info to me and I'll add it, no problem.

Thanks!

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] 0.5c1

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

Release candidate 0.5c1 is available from the snapshot area.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com