myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Incorrect conclusions in TSConIT paper

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

On 6/22/2012 9:57 AM, Jan Decaluwe wrote:
> I came across a paper that compares HDLs:
>
> http://referaat.cs.utwente.nl/TSConIT/download.php?id=1144


I am not very familiar with /Functional Languages/.  I have studied the 
Kansas Lava in the past, briefly.  /Functional Languages/ for HDLs seem 
to have the same track record as they have had with general programming 
languages; they appear to be an elegant solution but when the rubber 
meets the road they are difficult to use.


Regards,
Chris

Re: [myhdl-list] Simplifying Interfaces

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

On 6/25/2012 3:30 AM, Wesley New wrote:
> Firstly, thanks for Chris for bringing this feature to light. It is
> definitely one I will employ.
>
> The only problem I am having is that the ports arent expanded out when I am
> using user-defined hdl.
> As it isnt creating a flat file, the wrapper doesnt have any wishbone ports.
>
> For instance see the attached file.
>
> Initially all I wish to do is to encapsulate the wishbone ports so that I
> dont have to type them every time I instantiate a module that has a
> wishbone interface
>
> Regards
>
> Wesley
>


You would not be able to use the "object" on the top-level.  The outside 
world (your Verilog or VHDL) wouldn't know how to interface to a /wb/. 
The top-level has to be the discrete signals everything inside can use 
the /wb/ to simplify the interface.

I haven't tested it with the user defined code, you might have to do and 
extra step, but it should be possible.

Regards,
Chris

Re: [myhdl-list] Incorrect conclusions in TSConIT paper

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

On 6/22/2012 9:57 AM, Jan Decaluwe wrote:
> The author presents the following example:
>
> --
> from myhdl import *
>
> def firfilt (sigin, sigout, coefs, clk):
>       buffer = Signal(intbv(0)[len(sigin)*len(coefs)])
>       inlen = len(sigin)
>       saved_coefs = coefs
>       colen = len(saved_coefs)
>
>       @always(clk.posedge)
>       def logic():
>           buffer.next[inlen:] = sigin
>           buffer.next[:inlen] = buffer[inlen * (colen-1):]
>           tmp = 0
>           for index in range(colen):
>               mult = saved_coefs[inlen*(index+1):inlen*index] * \
>                      buffer[inlen*(index +1): inlen*index]
>               tmp = tmp + sigin
>           sigout.next = tmp
>
>       return logic

The author did a poor job picking their examples.  I say
this because I don't think their VHDL example is correct,
either.  They don't provide enough information but for the
VHDL example to be correct the instantiator would need to
take care of the output word size to handle the bit growth
as a result of the multiplies and additions (or limit the
input range).  I think if they would have verified the VHDL
they would have found the VHDL implementation did not meet
their requirements (or any requirements for a FIR filter).

Also, I don't think the author provides the description of
the RAM/ROM for the coefficients in the VHDL example.  The
VHDL example is not a fair comparison because it would need
additional description, somewhere, to define the coefficient
array.  Where as the MyHDL version the coefficient array
description is embedded!

Here is my version of the FIR filter in MyHDL that matches
the simplified templated:

     from myhdl import *
     def firfilt(sig_in, sig_out, coef, clk):
         buffer = [Signal(intbv(0, min=sig_in.min, max=sig_in.max)) \
                   for ii in range(len(coef))]
         coef = tuple(coef)
         mshift = len(sig_in)-1
         @always(clk.posedge)
         def hdl_sop():
             sop = 0
             # Note this adds an extra delay! (Group delay N/2+2)
             for ii in range(len(coef)):
                 buffer[ii].next = sig_in if ii == 0 else buffer[ii-1]
                 c = coef[ii]
                 sop = sop + (buffer[ii] * c)
             sig_out.next = (sop >> mshift)

         return hdl_sop

The testbench can be found here:
https://bitbucket.org/cfelton/examples/src/tip/firfilt/test_firfilt.py

and some plots of the working filter.
http://flic.kr/p/cko2SY
http://flic.kr/p/cko2Tj

Note:  This example is not reasonable for most implementations.
A very large combinational path is created for the multiplies
and accumulate (MAC).  Most implementations would break this up
some how, pipelining, multiple clocks ticks (flow control), etc.

To be honest, I ran into a couple bumps.  I had created the
following version first.

         @always(clk.posedge)
         def hdl_sop():
             buffer[0].next = sig_in
             sop = sig_in * coef[0]
             for ii in range(1, len(coef)):
                 buffer[ii].next = buffer[ii-1]
                 sop = sop + (buffer[ii-1] * coef[ii])
             sig_out.next = (sop >> mshift)

My first off the cuff, solution was to avoid an extra delay by
using the sig_in and not the registered version.  But this didn't
follow the list of signals (LoS) memory template and was not
convertible.  This can be fixed by not including the LoS access
in the expressions.

         @always(clk.posedge)
         def hdl_sop():
             buffer[0].next = sig_in
             c = coef[0]
             sop = sig_in * c
             for ii in range(1, len(coef)):
                 buffer[ii].next = buffer[ii-1]
                 c = coef[ii]
                 sop = sop + (buffer[ii-1] * c)
             sig_out.next = (sop >> mshift)

This is one of those rules that you have to remember but there
is good reason.  You are getting the coefficient description
(in this case a ROM) without needing a completely separate
generator, the description is conveniently embedded.  Well
almost conveniently, you do have to access the /tuple of ints/
(ToI) separately.  If the ToI is not access separately the
conversion code would have to infer signals between the ROM
description and the expressions, which might not be desirable
(at least that is my understanding?).

The one thing the authors inadvertently demonstrate, is the
*importance* of verifying the design even if the example isn't
the main focus.  As you point out, how can you make any kind
of reasonable argument if one language is more /concise/,
/comprehensible/, or /reusable/ if the example is not even
functional!


Regards,
Chris

Re: [myhdl-list] Incorrect conclusions in TSConIT paper

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

<snip>
>
> The author complains about verboseness and large amounts
> of conditional statements, but fails to take advantage of
> the idiomatic Python way to work with booleans:
>
>       empty = Signal(bool(0))
>       ...
>       empty.next = (dindex == 0)
>
> which would reduce the nr of lines drastically.
>

I agree this is a large flaw by the author.  First, as you
mention, you can do better using common Python idioms.

Second, I am sure there have been many debates (i.e. references)
on the pros/cons of Python/Haskell/Ada.  I believe considerable research 
should be performed on the base languages before the
HDLs. IMO for the analysis in the paper to be useful you would
need a prior Haskell/Python/Ada analysis on /Conciseness/, 
/Comprehensibility/, and /Reusablilty/ before comparing the HDLs
based on the general language.  And the reason you need this is
that you leverage prior debates/analysis, where experienced
designers have been able to comment.  Otherwise the authors
probably have an inherent bias because they are more familiar
with one language or the other.

I suppose the derived HDLs can break the base language feature but 
knowing that a base language had "conciseness" and the derived HDL 
doesn't is useful.

I am not convinced /conciseness/, via the line/word metric, is
useful.  We can write a program with very few lines/words that is
terse and conclude it is compact but most do *not* find terseness
very useful (to me terse is not concise).  I think the author
(unintentionally?) delved into a philosophical debate by relating
the number of words and lines to being concise vs. some actual
objective measurement.


I would say they completely missed the point on /Reusability/!

Regards,
Chris

Re: [myhdl-list] MEP-108 Bundle

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

On 06/24/2012 06:46 PM, Christopher Felton wrote:
> On 6/15/12 4:07 AM, Jan Decaluwe wrote:
>> On 06/01/2012 03:35 AM, Christopher Felton wrote:
>>
>>>> I think we should have a go at MEP 108 to remove the
>>>> confusing "class attribute" terminology. Perhaps the
>>>> explanations make it less clear than just stating what
>>>> this MEP is about. Perhaps we should just
>>>> talk about a method at the top level - I understand
>>>> methods at lower levels already worked without this MEP.
>>>>
>>>
>>> Sounds good, I should have some time tomorrow to work
>>> through the modifications you suggested.
>>
>> About the "self" argument: the MEP says that the
>> implementation looks for this argument and assumes it
>> has the usual meaning. This is just fine with me,
>> provided it is the *first* argument as per convention.
>> Probably this is what the implemenation does? If not,
>> it should, and the documentation should be adapated
>> also.
>>
>>
>
> There are two locations in the code that were modified.  First, the
> top-level visitor.  These modifications didn't require the use of the
> "self".
>
> The second in the extract hierarchy , the original code uses a different
> mechanism (not ast) to determine if user defined code is present.  The
> modifications here do not enforce the "self" as the first argument.  The
> code where the changes were added uses the python profile extraction to
> identify a function on a return event.  For a method, the "func" from
> the global space would be None, if that was the case then self was
> retrieved from the local space and funcname was checked as an attribute.
>
> What does this all mean, it means it doesn't enforce "self" to be the
> first position but it will only use self if it has the /function/ that
> it is looking for (funcname).  If the code fails to find the funcname in
> the global space or as an attribute (method) of "self" in the localspace.

Perhaps that is an indirect check of the conventional use of
self, including the position?
  
> I will investigate if there is a mechanism to also verify "self" is the
> first argument.  I tried to find a means to not use "self" but with the
> profile extraction I was not successful.

Mm, in any case it looks like a very minor issue (if any) and I don't
want to cause too much extra effort on it.

-- 
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] MEP-108 Bundle

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

On 6/15/12 4:07 AM, Jan Decaluwe wrote:
> On 06/01/2012 03:35 AM, Christopher Felton wrote:
>
>>> I think we should have a go at MEP 108 to remove the
>>> confusing "class attribute" terminology. Perhaps the
>>> explanations make it less clear than just stating what
>>> this MEP is about. Perhaps we should just
>>> talk about a method at the top level - I understand
>>> methods at lower levels already worked without this MEP.
>>>
>>
>> Sounds good, I should have some time tomorrow to work
>> through the modifications you suggested.
>
> About the "self" argument: the MEP says that the
> implementation looks for this argument and assumes it
> has the usual meaning. This is just fine with me,
> provided it is the *first* argument as per convention.
> Probably this is what the implemenation does? If not,
> it should, and the documentation should be adapated
> also.
>
>

There are two locations in the code that were modified.  First, the 
top-level visitor.  These modifications didn't require the use of the 
"self".

The second in the extract hierarchy , the original code uses a different 
mechanism (not ast) to determine if user defined code is present.  The 
modifications here do not enforce the "self" as the first argument.  The 
code where the changes were added uses the python profile extraction to 
identify a function on a return event.  For a method, the "func" from 
the global space would be None, if that was the case then self was 
retrieved from the local space and funcname was checked as an attribute.

What does this all mean, it means it doesn't enforce "self" to be the 
first position but it will only use self if it has the /function/ that 
it is looking for (funcname).  If the code fails to find the funcname in 
the global space or as an attribute (method) of "self" in the localspace.

I will investigate if there is a mechanism to also verify "self" is the 
first argument.  I tried to find a means to not use "self" but with the 
profile extraction I was not successful.

Regards,
Chris

Re: [myhdl-list] Simplifying Interfaces

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

Hi:

I don't follow the example completely, but if you  -
an experienced MyHDL designer - are surprized, then
others will be even more so.

I wonder if we can come up with an example suited for
the MyHDL by Example section, that demonstrates the power
of these techniques.

The message should be that conversion only deals with
code inside generators, in the context of their namespaces.
Conversion restrictions only apply to that code.
The namespaces are created during elaboration, so it
doesn't matter how.

On 06/20/2012 05:37 AM, Christopher Felton wrote:
> In one of the MEP-107 threads we had been discussing
> the current support of attribute conversion.  It was
> pointed out by Oscar that attributes will convert fine
> as long as a local reference is made.  This was interesting
> because it provides a means with the current release
> to use objects to simplify interfaces.
>
> At first I thought this would be restrictive in the
> sense that the attributes would only be an intermediate
> reference, something like the following:
>
> In [2]: def top(clock, reset):
>      ...:     x,y,z = [Signal(False) for ii in range(3)]
>      ...:     class bucket(): pass
>      ...:     bb = bucket()
>      ...:     bb.x = x
>      ...:     bb.y = y
>      ...:     bb.z = z
>      ...:     g1 = some_module(clock, reset, bb)
>      ...:     return g1
>      ...:
>
> In [3]: def some_module(clock, reset, bb):
>      ...:     x = bb.x
>      ...:     y = bb.y
>      ...:     z = bb.z
>      ...:     @always(clock.posedge)
>      ...:     def hdl():
>      ...:         if not reset:
>      ...:             z.next = False
>      ...:         else:
>      ...:             z.next = x or y
>      ...:     return hdl
>
> Which converts to the following
>
>        ...
>        always @(posedge clock) begin: TOP_G1_HDL
>            if ((!reset)) begin
>                z<= 1'b0;
>            end
>            else begin
>                z<= (x || y);
>            end
>        end
>
>
> What I found interesting was the fact that you do not
> need to start with the individual signals and reference
> through attributes.  The conversion will work in the
> following case as well.
>
> In [11]: def top2(clock, reset):
>       ...:     class bucket():
>       ...:         def __init__(self):
>       ...:             self.x = Signal(False)
>       ...:             self.y = Signal(False)
>       ...:             self.z = Signal(False)
>       ...:     bb = bucket()
>       ...:     g1 = some_module(clock, reset, bb)
>       ...:     return g1
>
> The above will convert to
>
>        always @(posedge clock) begin: TOP2_G1_HDL
>            if ((!reset)) begin
>                g1_z<= 1'b0;
>            end
>            else begin
>                g1_z<= (g1_x || g1_y);
>            end
>        end
>
> There doesn't seem to be any restriction in the use of
> attributes other than they need to be locally referenced
> (with the current release and development branch).
>
> I created a larger example using an embedded bus, wishbone.
> Using a similar technique you can simplify the interfaces
> between modules.  This example is functional but incomplete.
> I had a little bit of time and implemented but time was
> limited and didn't even take the time to look at the wishbone
> spec (it has been a while since I last used wishbone).
> There could be some inaccuracies.
>
> Using this approach, which is fully supported by conversion
> with today's releases, a couple simplifications (imo) were
> achieved.
>
> First, the interface was simplified and generalized.  As
> discussed only a single reference was passed to a module.
> All the signals were encapsulated by the reference.
>
>        def gpio(wb, out, NumOutputs=1):
>        """Very simple memory mapped peripheral"""
>
> Second, now the embedded bus can be very modular.  In this
> case the peripheral doesn't know or care what bus is actually
> used.  In the peripheral it simply requests the registers it
> needs.  This works for basic rw (control) and ro (status)
> registers (although the current example only uses rw).  The ridiculously
> simple gpio is:
>
>        def gpio(wb, out, NumInputs=0, NumOutputs=1):
>            """Very simple memory mapped peripheral"""
>            rin = Signal(intbv(0)[8:])
>            rout = Signal(intbv(0)[8:])
>            wbdev = wb.AddDevice(Name="GPIO")
>            iReg = wb.AddDeviceRegister(rin, rout, wbdev)
>
>            @always_comb
>            def hdl_assigns():
>                out.next = rout[0]
>
>       return iReg, hdl_assigns
>
> The above should probably be changed to have a
> AddDeviceRwRegister(...) and AddDeviceRoRegister(...).
> As mentioned, the bus referenced passed could be any bus
> protocol because the actual bus interfacing is part of the
> generators in the bus object.
>
> The top-level looks something like the following
>
>        def simple_top(clock, reset, buttons, leds):
>
>            wb = Wishbone(DataWidth=8, AddressWidth=16)
>            iController = buttons2bus(clock, reset, wb, buttons)
>            outs = [Signal(False) for ii in range(len(leds))]
>            iGpios = [None for ii in range(len(leds))]
>            for ii in range(len(leds)):
>                iGpios[ii] = gpio(wb, outs[ii])
>
>            iBus = wb.DeviceBusses()
>            print(wb.Summary())
>
>            return iController, iGpios, iBus, hdl_assigns
>
> The complete example can be found here
>     https://bitbucket.org/cfelton/examples/src/tip/simple
>
> The main file is the simple.py file and the bus is
> implemented in the wishbone.py.
>
> This example is *silly*.  It has buttons as inputs and leds
> as outputs.  If a button is pressed it will create a bus
> access to a gpio (one module per led) and toggle the led.
> The example was simple to verify (limited inputs and outputs)
> and I can test it on actual hardware.
>
> Feedback and comments welcomed.
> Chris Felton
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


-- 
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] Incorrect conclusions in TSConIT paper

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

I came across a paper that compares HDLs:

http://referaat.cs.utwente.nl/TSConIT/download.php?id=1144

Many conclusions and remarks about MyHDL are incorrect
for the following reasons:

1) the author doesn't fully understand the nature of
MyHDL/Python. This can be excused for a newbie; perhaps
we have to do a better job explaining.

2) Some conclusions are based on non-functional code.
No excuses here; conclusions based on code that doesn't
work are not acceptable.

I will first explain the conceptual errors, and then
go into the details of the incorrect code (for those
interested).

The author makes the common error of equating MyHDL with
conversion. But MyHDL is primarily about modeling in
general. Conversion is really just a workaround to
play well with the backend tools in established
design flows.

For example, he states that MyHDL only supports
intbv and not floating point, which is completely wrong.
For modeling purposes, any type can be used as the underlying
type of a Signal. Conversion is restricted to intbv and a
few other types (because its primary target is synthesis)
but when the purpose is modeling and system verification,
why worry about conversion?

The author has critique on duck typing (which has indeed
disadvantages) but fails to recognize that it is exactly
this that allows MyHDL models to be written in
a type-independent way.

The author complains about verboseness and large amounts
of conditional statements, but fails to take advantage of
the idiomatic Python way to work with booleans:

     empty = Signal(bool(0))
     ...
     empty.next = (dindex == 0)

which would reduce the nr of lines drastically.

Finally, the author complains about cryptic messages when
conversion fails. Taken on its own, he has a point. It is
certainly true that the conversion error reporting can be improved.
However, the reason why this is such a blocking problem in
this case is a flawed methodology. The author seems to consider
the convertor as some kind of compiler which can help to
produce working MyHDL code. But this is completely wrong.
The goal of the convertor is to convert *working* MyHDL code
to equivalent Verilog/VHDL.

Creating working MyHDL code has to be done in the Python way.
We don't have a compiler that finds a lot of errors. In a super
dynamic language like Python, the run-time rules. In MyHDL,
this means simulation:

http://www.myhdl.org/doc/current/manual/conversion.html#simulate-first

My biggest critique on the paper is that the author apparently
hasn't done this. When he got stuck with conversion, his immediate
reaction should have been to simulate. I believe that even a
simple simulation would have revealed basic errors, and
correcting those would have made conversion much more friendly.

This is a severe critique, and I will show in detail
why I came to this conclusion.

The author presents the following example:

--
from myhdl import *

def firfilt (sigin, sigout, coefs, clk):
     buffer = Signal(intbv(0)[len(sigin)*len(coefs)])
     inlen = len(sigin)
     saved_coefs = coefs
     colen = len(saved_coefs)

     @always(clk.posedge)
     def logic():
         buffer.next[inlen:] = sigin
         buffer.next[:inlen] = buffer[inlen * (colen-1):]
         tmp = 0
         for index in range(colen):
             mult = saved_coefs[inlen*(index+1):inlen*index] * \
                    buffer[inlen*(index +1): inlen*index]
             tmp = tmp + sigin
         sigout.next = tmp

     return logic

def convert():
     sin = Signal(intbv(0)[8:])
     sout = Signal(intbv(0)[8:])
     coefs = [2, 8, 6 ,20 ,3]
     clk = Signal(bool(0))
     toVHDL(firfilt , sin , sout , coefs , clk )

convert()
--

It seems clear that this code has not been simulated and
cannot work. First:

     buffer = Signal(intbv(0)[len(sigin)*len(coefs)])

is most likely wrong as only a single bit is selected,
Probably what is meant is a bit vector definition as follows:

     buffer = Signal(intbv(0)[inlen*colen:])

Furthermore, the following lines:

         mult = saved_coefs[inlen*(index+1):inlen*index] * \
                buffer[inlen*(index +1): inlen*index]
         tmp = tmp + sigin

must be wrong: what can be the purpose of multiplying
a sequence of constants with a bit vector?  Furthermore, it
seems nothing happens with variable mult. Looking at the VHDL
version, what was probably intended is something like
the following:

--
from myhdl import *

def firfilt (sigin, sigout, coefs, clk):
     inlen = len(sigin)
     colen = len(coefs)
     buffer = Signal(intbv(0)[inlen*colen:])

     @always(clk.posedge)
     def logic():
         buffer.next[inlen:] = sigin
         buffer.next[:inlen] = buffer[inlen*(colen-1):]
         tmp = 0
         for index in range(colen):
             c = coefs[index]  # select one coefficient
             mult = c * buffer[inlen*(index +1):inlen*index]
             tmp = tmp + mult # mult/accumulate
         sigout.next = tmp

     return logic

def convert():
     sin = Signal(intbv(0)[8:])
     sout = Signal(intbv(0)[8:])
     coefs = (2, 8, 6, 20, 3) # tuple of constants
     clk = Signal(bool(0))
     toVHDL(firfilt , sin , sout , coefs , clk )

convert()
--


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

Re: [myhdl-list] Reset functionality "synthesis"

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

On 06/18/2012 07:18 PM, Christopher Felton wrote:
> <snip>
>>
>> However, I think we can do better. Recall that always_comb
>> already inferres a sensitivity list. What if we introduced
>> a new decorator, always_ff, that would infer the reset
>> structure?
>
>
> I really like this idea.  I think it can be very useful.
> If I understand correctly, the initial value of the Signal
> is used for the /reset/ value?  If the above was change to
>
>       ...
>       count = Signal(modbv(17)[8:])
>       ...
>
> Then the inferred reset logic would be
>
>           ...
>           if reset == 0:
>               count.next = 17
>           ...
>
> Correct?

Yes, that is exactly the idea.

>> Currently, I think always_ff would have an argument
>> list as follows:
>>
>>        always_ff(edge, reset=False, level=0, async=True)
>>
>> The False default for the reset parameter would allow
>> to force the presence of a reset signal. (A block
>> without reset would require reset=None explicitly).
>> The reset level and style can also be specified, with
>> defaults that correspond to the most common case in
>> my opinion.
>>
>> Feedback welcome!
>>
>
> Haven't thought this fully through but would it be better
> to have the /reset/ properties passes as arguments to the
> decorator or properties of the Signal?  Example if properties
> used:
>
>       reset = Signal(False)
>       reset.level = 0
>       reset.async = True
>
>       @always_ff(clock.posedge, reset=reset)
>
> The property defaults would be the same as you stated.

Seems a very good idea. Perhaps even introduce a
Signal subclass, ResetSignal, to set the properties
at construction time and allow type checking in the
always_ff decorator:

reset = ResetSignal(0, active=0, async=True) # defaults shown

> I guess the benefit of this is you could easily change
> the reset characteristics by only changing a couple lines
> of code (not all always_ff decorators).
>
> Also, I think if the @always_ff is used you have to
> explicitly state the reset.  The reset argument would
> not have a default value.
>
>       @always_ff(edge, reset)
>
> The @always_ff expects 1 edge and 1 reset.  Anything more
> complicated fall back to the @always.  In this case
> reset=None is a valid option.

Right.

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

[myhdl-list] (no subject)

[Dan F. <dfa...@ya...>]

http://www.perfscipress.com/wp-content/themes/eShop/google.html?sdm=ge.sxfs&shn=mgh.jyg&eec=akid

[myhdl-list] Simplifying Interfaces

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

In one of the MEP-107 threads we had been discussing
the current support of attribute conversion.  It was
pointed out by Oscar that attributes will convert fine
as long as a local reference is made.  This was interesting
because it provides a means with the current release
to use objects to simplify interfaces.

At first I thought this would be restrictive in the
sense that the attributes would only be an intermediate
reference, something like the following:

In [2]: def top(clock, reset):
    ...:     x,y,z = [Signal(False) for ii in range(3)]
    ...:     class bucket(): pass
    ...:     bb = bucket()
    ...:     bb.x = x
    ...:     bb.y = y
    ...:     bb.z = z
    ...:     g1 = some_module(clock, reset, bb)
    ...:     return g1
    ...:

In [3]: def some_module(clock, reset, bb):
    ...:     x = bb.x
    ...:     y = bb.y
    ...:     z = bb.z
    ...:     @always(clock.posedge)
    ...:     def hdl():
    ...:         if not reset:
    ...:             z.next = False
    ...:         else:
    ...:             z.next = x or y
    ...:     return hdl

Which converts to the following

      ...
      always @(posedge clock) begin: TOP_G1_HDL
          if ((!reset)) begin
              z <= 1'b0;
          end
          else begin
              z <= (x || y);
          end
      end


What I found interesting was the fact that you do not
need to start with the individual signals and reference
through attributes.  The conversion will work in the
following case as well.

In [11]: def top2(clock, reset):
     ...:     class bucket():
     ...:         def __init__(self):
     ...:             self.x = Signal(False)
     ...:             self.y = Signal(False)
     ...:             self.z = Signal(False)
     ...:     bb = bucket()
     ...:     g1 = some_module(clock, reset, bb)
     ...:     return g1

The above will convert to

      always @(posedge clock) begin: TOP2_G1_HDL
          if ((!reset)) begin
              g1_z <= 1'b0;
          end
          else begin
              g1_z <= (g1_x || g1_y);
          end
      end

There doesn't seem to be any restriction in the use of
attributes other than they need to be locally referenced
(with the current release and development branch).

I created a larger example using an embedded bus, wishbone.
Using a similar technique you can simplify the interfaces
between modules.  This example is functional but incomplete.
I had a little bit of time and implemented but time was
limited and didn't even take the time to look at the wishbone
spec (it has been a while since I last used wishbone).
There could be some inaccuracies.

Using this approach, which is fully supported by conversion
with today's releases, a couple simplifications (imo) were
achieved.

First, the interface was simplified and generalized.  As
discussed only a single reference was passed to a module.
All the signals were encapsulated by the reference.

      def gpio(wb, out, NumOutputs=1):
      """Very simple memory mapped peripheral"""

Second, now the embedded bus can be very modular.  In this
case the peripheral doesn't know or care what bus is actually
used.  In the peripheral it simply requests the registers it
needs.  This works for basic rw (control) and ro (status)
registers (although the current example only uses rw).  The ridiculously 
simple gpio is:

      def gpio(wb, out, NumInputs=0, NumOutputs=1):
          """Very simple memory mapped peripheral"""
          rin = Signal(intbv(0)[8:])
          rout = Signal(intbv(0)[8:])
          wbdev = wb.AddDevice(Name="GPIO")
          iReg = wb.AddDeviceRegister(rin, rout, wbdev)

          @always_comb
          def hdl_assigns():
              out.next = rout[0]

     return iReg, hdl_assigns

The above should probably be changed to have a
AddDeviceRwRegister(...) and AddDeviceRoRegister(...).
As mentioned, the bus referenced passed could be any bus
protocol because the actual bus interfacing is part of the
generators in the bus object.

The top-level looks something like the following

      def simple_top(clock, reset, buttons, leds):

          wb = Wishbone(DataWidth=8, AddressWidth=16)
          iController = buttons2bus(clock, reset, wb, buttons)
          outs = [Signal(False) for ii in range(len(leds))]
          iGpios = [None for ii in range(len(leds))]
          for ii in range(len(leds)):
              iGpios[ii] = gpio(wb, outs[ii])

          iBus = wb.DeviceBusses()
          print(wb.Summary())

          return iController, iGpios, iBus, hdl_assigns

The complete example can be found here
   https://bitbucket.org/cfelton/examples/src/tip/simple

The main file is the simple.py file and the bus is
implemented in the wishbone.py.

This example is *silly*.  It has buttons as inputs and leds
as outputs.  If a button is pressed it will create a bus
access to a gpio (one module per led) and toggle the led.
The example was simple to verify (limited inputs and outputs)
and I can test it on actual hardware.

Feedback and comments welcomed.
Chris Felton

Re: [myhdl-list] MEP 107 - update assessment

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

On 06/18/2012 05:27 PM, Christopher Felton wrote:

>> We could restrict the examples to instance variables,
>> but add a note in the end that attribute lookup is
>> general (as I think it can be without too much problems).
>> This would include class attributes, but also lookup
>> in modules or in NamedTuples.
>
> Sounds fine, will make the changes.
>
> NamedTuples?  Would this cause confusion?  A NamedTuple
> access via attributes would convert via the lookup but
> what happens if the NamedTuple is indexed?  Would indexing
> of a NamedTuple be supported?  Also, wouldn't a NamedTuple
> be identified by the converter as a MemObj?

Forget about NamedTuples for the moment - I wrote it
down without thinking it through.


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

Re: [myhdl-list] Reset functionality "synthesis"

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

<snip>
>
> However, I think we can do better. Recall that always_comb
> already inferres a sensitivity list. What if we introduced
> a new decorator, always_ff, that would infer the reset
> structure? The advantages would be:
>
> * reset functionality automatically correct by construction
> * no need to write code dedicated to reset functionality
>
> The latter feature is important because reset code tends
> to take up a lot of lines for non-functional reasons.
> Also, we would save a level of indentation.
>
> For example, suppose we have a wrap-around incrementer
> as follows:
>
>       ...
>       count = Signal(modbv(0)[8:])
>       ...
>       def Inc(count, enable, clock, reset):
>
>           @always(clock.posedge, reset.negedge)
>           def incLogic():
>               if reset == 0:
>                   count.next = 0
>               else:
>                   if enable:
>                       count.next = count + 1
>
>           return incLogic
>
> With an always_ff decorator, we could rewrite it as follows:
>
>       def Inc(count, enable, clock, reset):
>
>           @always_ff(clock.posedge, reset=reset)
>           def incLogic():
>               if enable:
>                   count.next = count + 1
>
>           return incLogic
>
> and it would do exactly the same as the original.


I really like this idea.  I think it can be very useful.
If I understand correctly, the initial value of the Signal
is used for the /reset/ value?  If the above was change to

     ...
     count = Signal(modbv(17)[8:])
     ...

Then the inferred reset logic would be

         ...
         if reset == 0:
             count.next = 17
         ...

Correct?

>
> Currently, I think always_ff would have an argument
> list as follows:
>
>       always_ff(edge, reset=False, level=0, async=True)
>
> The False default for the reset parameter would allow
> to force the presence of a reset signal. (A block
> without reset would require reset=None explicitly).
> The reset level and style can also be specified, with
> defaults that correspond to the most common case in
> my opinion.
>
> Feedback welcome!
>

Haven't thought this fully through but would it be better
to have the /reset/ properties passes as arguments to the
decorator or properties of the Signal?  Example if properties
used:

     reset = Signal(False)
     reset.level = 0
     reset.async = True

     @always_ff(clock.posedge, reset=reset)

The property defaults would be the same as you stated.

I guess the benefit of this is you could easily change
the reset characteristics by only changing a couple lines
of code (not all always_ff decorators).

Also, I think if the @always_ff is used you have to
explicitly state the reset.  The reset argument would
not have a default value.

     @always_ff(edge, reset)

The @always_ff expects 1 edge and 1 reset.  Anything more
complicated fall back to the @always.  In this case
reset=None is a valid option.

Regards,
Chris

Re: [myhdl-list] MEP 107 - update assessment

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

On 6/15/2012 5:26 AM, Jan Decaluwe wrote:
> MEP 107 has been rewritten with support for attribute
> lookup only - ok.
>
> Comments:
>
> 1) the proposal is to support attribute lookup with an
> arbitrary depth. Until now I had only considered a
> single level of lookup.
>
> I think support for arbitrary depth may complicate
> things significantly, and I am not sure that there is
> good use case that warrants the effort.


My thought is, if depth greater than 1 requires too
much effort in the near-term we can add an implementation
amendment listing the limitations to the MEP.  But I
think to cover the general case we should investigate
depth greater than 1.

I have prototyped, generically, decoding arbitrary lookup
depths and it seems plausible.  At least in the generic
sense (not the actual conversion code).  I will try and
add this to the MEP.

>
> 2) I miss lists of signals. I believe people will want
> to use the container as a namespace for all signal-like
> objects that are currently supported, including lists.
> I expect this would not add too much additional
> difficulties to implement.

Good suggestion, it is worthwhile repeating in the MEP that
all convertible types are intended to be supported in
the attribute Signal containers (lookup) and what that
might look like.

>
> 3) I don't think the difference between class attributes
> and instances attributes is subtle. I also think that
> the overwhelming usage of the lookup feature will be
> for instance attributes. In short: I would remove the
> explication of the difference; I think it will only
> confuse people without adding value.
>
> We could restrict the examples to instance variables,
> but add a note in the end that attribute lookup is
> general (as I think it can be without too much problems).
> This would include class attributes, but also lookup
> in modules or in NamedTuples.

Sounds fine, will make the changes.

NamedTuples?  Would this cause confusion?  A NamedTuple
access via attributes would convert via the lookup but
what happens if the NamedTuple is indexed?  Would indexing
of a NamedTuple be supported?  Also, wouldn't a NamedTuple
be identified by the converter as a MemObj?

>
> 4) Currently, MyHDL supports only local variables (this
> may change with Python 3.0 in the future) that do not
> take part in hierarchy extraction. Therefore, the way
> they are named in conversion should also be different
> and local.
>
> That having said, I have not thought about lookup
> support for variables and it may prove to be very
> different from signals.
>
> I think the most "urgent" need is for signals,
> to emulate interfaces. We could consider to
> keep variable support for a future MEP, after we see
> how the signal lookup support turns out.

Sure, limiting to only Signals simplifies and as you
state covers majority of the intended use.  Sounds
good to me, I will remove the references to variables.

Regards,
Chris

Re: [myhdl-list] Reset functionality "synthesis"

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

On 06/15/2012 04:39 PM, Tom Dillon wrote:
> One question, will you still be able to have a register that is not
> reset and doesn't have an initial value?
>
> I often use those in FPGAs when I want a shift register to get
> optimized to local memory.

For clarity: the present proposal suggest to use initial
values in MyHDL as a specification of reset values.
This is completely independent from the question whether
such initial values should be written out in the converted
Verilog or VHDL output code.

The proposal would not change any current feature. Everything
you can do today would be available unchanged. What you
would have is an additional decorator that can be used
to infer the reset structure automatically.

Even if you don't want a reset, the new decorator would
have value, because it permits to specify the absence
of a reset explicitly:

     always_ff(clock.posedge, reset=None)
     def shift_reg():
         reg.next = reg << 1

A reviewer would have no doubt that the absence of the
reset is intentional, instead of a potential oversight.

What you would not be able to do with this decorator
is to mix resettable and non-resettable registers in the
same block. But in my view that is not a good idea style-wise
anyway. I always factor out such registers in a separate block.

-- 
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] Update on MyHDL benchmarks with pypy

[Norbo <Nor...@gm...>]

Am 15.06.2012, 10:53 Uhr, schrieb Jan Decaluwe <ja...@ja...>:

> For your info.
>
> Since pypy 1.6, the benchmarks for MyHDL have stagnated
> or become slightly worse (within 15%).
>
> Still, the results are much better than the average
> speedup over the pypy set of benchmarks. I guess it is
> to be expected that improvements depend heavily on
> a particular application.
>
> http://myhdl.org/doku.php/performance?&#historical_data
>
>

hey, i just was able to run the lfsr24 example with my implementation of a  
myhdl simulator (yes sounds crazy but is true,i also was able to run my  
RS232 implementation with it, but it has still a lot of shortcommings and  
i bassically avoided every design rule i ever heard of, so it is nothing  
for production!!)
here are my benchmark results:


lfsr24:
-------------
Myhdl orginal with pypy:  user    1m29.174s
my Myhdl with pypy:       user    0m45.687s


RS232:
-------------
Myhdl orginal with pypy: user    0m2.936s
my Myhdl with pypy:      user    0m1.492s

(what i bassically did is i appended the function of an e.g always block  
directly to the signal on which
the block reacts on) So the yield is only possible in a instance block.

Re: [myhdl-list] Reset functionality "synthesis"

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

One question, will you still be able to have a register that is not 
reset and doesn't have an initial value?

I often use those in FPGAs when I want a shift register to get optimized 
to local memory.

On 06/15/2012 09:02 AM, Jan Decaluwe wrote:
> I think I have a good idea for a "micro-killer feature" -
> something that one can't do with traditional HDLs, but
> that makes a designer's life much easier.
>
> This was triggered by the latest discussion and work on
> initial values. Here is a summary of the starting point.
>
> I believe all signals/variables should have an initial
> value in RTL. Ideally, those initial values should be
> present in the converted Verilog/VHDL also, and we are
> currently discussing how and when to do so.
>
> However, there is the question of the reset functionality
> at the lower levels. Some people use the fact that
> signals are not initialized to check whether the reset
> works properly. With initial values, this is no longer
> possible (in simulation at least).
>
> The idea I have started as follows. Initial values and
> reset functionality seem related but at a different level.
> However, I don't see why there can ever be a good reason to
> use an initial value that is different from the reset value.
> The question is then if we can use that redundancy to our
> advantage.
>
> In a language like SystemVerilog, there is a dedicated
> always construct, always_ff, which can be used to check
> correctness of blocks with flip-flop inference, e.g.
> whether all flip-flops have a reset. In MyHDL, we could
> improve by checking that all flip-flops are reset to the
> initial value.
>
> However, I think we can do better. Recall that always_comb
> already inferres a sensitivity list. What if we introduced
> a new decorator, always_ff, that would infer the reset
> structure? The advantages would be:
>
> * reset functionality automatically correct by construction
> * no need to write code dedicated to reset functionality
>
> The latter feature is important because reset code tends
> to take up a lot of lines for non-functional reasons.
> Also, we would save a level of indentation.
>
> For example, suppose we have a wrap-around incrementer
> as follows:
>
>       ...
>       count = Signal(modbv(0)[8:])
>       ...
>       def Inc(count, enable, clock, reset):
>
>           @always(clock.posedge, reset.negedge)
>           def incLogic():
>               if reset == 0:
>                   count.next = 0
>               else:
>                   if enable:
>                       count.next = count + 1
>
>           return incLogic
>
> With an always_ff decorator, we could rewrite it as follows:
>
>       def Inc(count, enable, clock, reset):
>
>           @always_ff(clock.posedge, reset=reset)
>           def incLogic():
>               if enable:
>                   count.next = count + 1
>
>           return incLogic
>
> and it would do exactly the same as the original.
>
> Currently, I think always_ff would have an argument
> list as follows:
>
>       always_ff(edge, reset=False, level=0, async=True)
>
> The False default for the reset parameter would allow
> to force the presence of a reset signal. (A block
> without reset would require reset=None explicitly).
> The reset level and style can also be specified, with
> defaults that correspond to the most common case in
> my opinion.
>
> Feedback welcome!
>

[myhdl-list] Reset functionality "synthesis"

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

I think I have a good idea for a "micro-killer feature" -
something that one can't do with traditional HDLs, but
that makes a designer's life much easier.

This was triggered by the latest discussion and work on
initial values. Here is a summary of the starting point.

I believe all signals/variables should have an initial
value in RTL. Ideally, those initial values should be
present in the converted Verilog/VHDL also, and we are
currently discussing how and when to do so.

However, there is the question of the reset functionality
at the lower levels. Some people use the fact that
signals are not initialized to check whether the reset
works properly. With initial values, this is no longer
possible (in simulation at least).

The idea I have started as follows. Initial values and
reset functionality seem related but at a different level.
However, I don't see why there can ever be a good reason to
use an initial value that is different from the reset value.
The question is then if we can use that redundancy to our
advantage.

In a language like SystemVerilog, there is a dedicated
always construct, always_ff, which can be used to check
correctness of blocks with flip-flop inference, e.g.
whether all flip-flops have a reset. In MyHDL, we could
improve by checking that all flip-flops are reset to the
initial value.

However, I think we can do better. Recall that always_comb
already inferres a sensitivity list. What if we introduced
a new decorator, always_ff, that would infer the reset
structure? The advantages would be:

* reset functionality automatically correct by construction
* no need to write code dedicated to reset functionality

The latter feature is important because reset code tends
to take up a lot of lines for non-functional reasons.
Also, we would save a level of indentation.

For example, suppose we have a wrap-around incrementer
as follows:

     ...
     count = Signal(modbv(0)[8:])
     ...
     def Inc(count, enable, clock, reset):

         @always(clock.posedge, reset.negedge)
         def incLogic():
             if reset == 0:
                 count.next = 0
             else:
                 if enable:
                     count.next = count + 1

         return incLogic

With an always_ff decorator, we could rewrite it as follows:

     def Inc(count, enable, clock, reset):

         @always_ff(clock.posedge, reset=reset)
         def incLogic():
             if enable:
                 count.next = count + 1

         return incLogic

and it would do exactly the same as the original.

Currently, I think always_ff would have an argument
list as follows:

     always_ff(edge, reset=False, level=0, async=True)

The False default for the reset parameter would allow
to force the presence of a reset signal. (A block
without reset would require reset=None explicitly).
The reset level and style can also be specified, with
defaults that correspond to the most common case in
my opinion.

Feedback welcome!

-- 
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] MEP 107 - update assessment

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

MEP 107 has been rewritten with support for attribute
lookup only - ok.

Comments:

1) the proposal is to support attribute lookup with an
arbitrary depth. Until now I had only considered a
single level of lookup.

I think support for arbitrary depth may complicate
things significantly, and I am not sure that there is
good use case that warrants the effort.

2) I miss lists of signals. I believe people will want
to use the container as a namespace for all signal-like
objects that are currently supported, including lists.
I expect this would not add too much additional
difficulties to implement.

3) I don't think the difference between class attributes
and instances attributes is subtle. I also think that
the overwhelming usage of the lookup feature will be
for instance attributes. In short: I would remove the
explication of the difference; I think it will only
confuse people without adding value.

We could restrict the examples to instance variables,
but add a note in the end that attribute lookup is
general (as I think it can be without too much problems).
This would include class attributes, but also lookup
in modules or in NamedTuples.

4) Currently, MyHDL supports only local variables (this
may change with Python 3.0 in the future) that do not
take part in hierarchy extraction. Therefore, the way
they are named in conversion should also be different
and local.

That having said, I have not thought about lookup
support for variables and it may prove to be very
different from signals.

I think the most "urgent" need is for signals,
to emulate interfaces. We could consider to
keep variable support for a future MEP, after we see
how the signal lookup support turns out.


-- 
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] Summary of "Intial Values Support" threads

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

On 05/30/2012 06:47 AM, Christopher Felton wrote:
> We listed a summary a couple time but the initial value support (ivs)
> was embedded in a separate thread.  So, I thought it would be worth
> while to summarize in a new thread.
>
>
>     1.  Initial value support can be re-enabled.  The Verilog
>         support of initial values as verified with the latest
>         of Quartus.
>         Need to test with (list syn and sim tools)?
>           [x] Quartus latest
>           [ ] ISE (xst) latest
>           [ ] cver
>           [ ] icarus

Ok, perhaps make a page on the site to keep track
of the status.

>
>     2.  None will *not* be added to intbv.  An argument will
>         be added to the toVerilog and toVHDL to disable
>         "plain" Signal init and "memory" (array) init.
>         Something like the following.
>
>           toVerilog(... disable_init=False, disable_mem_init=False)
>           toVHDL( "" "" )

Arguments can always be used as ports, so configuration
should go elsewhere. Currently function attributes are for
such purposes:

toVerilog.disable_init = False


>     3.  toVerilog will only create initial values for Signals
>         converted to register types.

Yes, good compromise.

>
>     4.  Initial values for memories (list of signals) will be
>         generated.  If feasible the synthesizable versions [1]
>         of the memory init values will be generated.

More work, so we should be certain about synthesizability
certainly with Xilinx and Altera tools.

>
>
> Let me know if I missed something or summarized incorrectly.
>
> Regards,
> Chris
>
> [1] http://www.altera.com/literature/hb/qts/qts_qii51007.pdf
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


-- 
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] MEP-108 Bundle

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

On 06/01/2012 03:35 AM, Christopher Felton wrote:

>> I think we should have a go at MEP 108 to remove the
>> confusing "class attribute" terminology. Perhaps the
>> explanations make it less clear than just stating what
>> this MEP is about. Perhaps we should just
>> talk about a method at the top level - I understand
>> methods at lower levels already worked without this MEP.
>>
>
> Sounds good, I should have some time tomorrow to work
> through the modifications you suggested.

About the "self" argument: the MEP says that the
implementation looks for this argument and assumes it
has the usual meaning. This is just fine with me,
provided it is the *first* argument as per convention.
Probably this is what the implemenation does? If not,
it should, and the documentation should be adapated
also.


-- 
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] Update on MyHDL benchmarks with pypy

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

For your info.

Since pypy 1.6, the benchmarks for MyHDL have stagnated
or become slightly worse (within 15%).

Still, the results are much better than the average
speedup over the pypy set of benchmarks. I guess it is
to be expected that improvements depend heavily on
a particular application.

http://myhdl.org/doku.php/performance?&#historical_data


-- 
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] Hack a day

[Jan C. <jan...@gm...>]

On 12/06/06 15:10, Christopher Felton wrote:
> A MyHDL project was posted on hack a day by [hardsoftlucid].
http://pycpu.wordpress.com

Yes, looks progressive, and interesting.  Good work Norbert, hope 
we can meet sometime.

Jan Coombs
-- 

[myhdl-list] myhdl.org dokuwiki upgrade

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

myhdl.org upgrated to dokuwik "Angua". Report glitches if any.

-- 
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] Hack a day

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

On 6/11/2012 8:53 PM, Christopher Felton wrote:
> A MyHDL project was posted on hack a day by [hardsoftlucid].
>
> http://hackaday.com/2012/06/11/programming-fpgas-with-python/
>
> Enjoy,
> Chris Felton
>
>
Something to note, the hack-a-day does a horrible (beyond horrible) job 
describing the project, PyCPU (http://pycpu.wordpress.com/) and MyHDL.

I should have just posted the PyCPU project and not the hack-a-day link.

Regards,
Chris