myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] attribute enum_encoding: string;

[David H. <da...@ad...>]

Hello, When using ghdl for syntax checks, I get the following error for any
state machine where encoding="one_hot":
pcie_drx.vhd:137:11: no declaration for "enum_encoding"

I can resolve ghdl's complaints by adding
  attribute enum_encoding: string;
to the generated .vhd file.

Is there a way to have this line included automatically in .vhd output?  I
could add it via a shell script, but I'm wondering if there is "better way"
to do it.  (or is GHDL in error?)


For example, here is an trimmed-down excerpt from the top of the .vhd file
showing where I add the line:

package pck_pcie_drx is
>     attribute enum_encoding: string;  <--- I need to add this line.

    type t_enum_t_state_22 is (
>
    IDLE,

    THINK,

    SEND_CMD,

    ADVANCE

);

attribute enum_encoding of t_enum_t_state_22: type is "0001 0010 0100 1000";

    type t_enum_t_state_23 is (
>     CMD,
>     MWR_H0H1,
>     MWR32_H2D0,
>     MWR32_D1D2,
>     MWR32_D3XX,
>     MWR64_H2H3,
>     MWR64_D0D1,
>     DROP
> );
> attribute enum_encoding of t_enum_t_state_23: type is "00000001 00000010
> 00000100 00001000 00010000 00100000 01000000 10000000";
> end package pck_pcie_drx;
> library IEEE;
> etc...




- David
  ps:  Thank you for the fantastic MyHDL.

Re: [myhdl-list] fixed-point thoughts : part one

[Martin S. <ha...@se...>]

Hi all,

On 08/28/2013 05:25 PM, Tom Dillon wrote:

> 
> I don't think you would want to build that into the fixbv multiply.
> 

No, I guess that would be rather unflexible. I had a look at your
library, and it just does it as expected. Surprised that different
format mul's are supported, too.

I like the VHDLish resize() approach.

Let me grab Chris' example and think this through loud:

     z = resize(x+y,format,
                round_mode='convergent',
                overflow_mode='saturate')

So if I did a signal assigment in a clock sensitive process:

     a.next = resize(x+y,format,
                round_mode='convergent',
                overflow_mode='saturate')

it will throw an exception if:

1) Formats of 'a' and 'z' (the result) don't match when a is a fixbv
2) Width doesnt match when a is an intbv (might be a dangerous
assignment, maybe casting would be more appropriate?)
3) x and y don't match WRT format (not just width)
4) Overflow is not handled

Something like that? But I'll keep my trap shut now and wait for Chris'
details.

> I don't see why those functions would not be convertible already to VHDL
> or Verilog.
> 

No question, but there would be many ways to implement it. I'm a fan of
helper functions (readability), but maybe there are reasons to do it the
unrolled way...I don't know.

I'd second Chris' opinion and also rather go with a lean&mean 'kernel',
no high level stuff that makes things complicated or more complex to
document..

For me, the basic rounding/overflow handling of a classical DSP would be
good enough.

Cheers,

- Martin

Re: [myhdl-list] fixed-point thoughts : part one

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

On 8/28/2013 8:34 AM, Martin Strubel wrote:
> Hi Chris,
>
> I'd like to see 'fixbv' as a sophisticated standard inside MyHDL.

Me too :)

> I presume many people are cooking their own soup (including me).
>
> A few things are still unclear to me though, in particular WRT rounding
> options and conversion to synthesizable code. I wouldn't want to
> anticipate too much from your announced "part 2" of the proposal, but
> let me throw in a few comments/questions anyhow:

Yes, part II I will be discussing operations including
rounding and overflow.

>
> 1. I'd personally prefer the strict bit definition for the initializer.
>     Why not just allow
>       a = fixbv("si.ffffff")
>     Might only make an automated width generation a little quirky, but so
> far I always stuck to a fixed bit size.

Definition by properties (min,max,res) or by explicit
bit widths is intended (proposed):

     # construction by properties
     x = fixbv(0,min=-1,max=1,res=2**-15)

     # construction by explicit bit-widths
     x = fixbv(0)[16,0,15]  # form [wl,iwl,fwl]

Although "si.ffff" is readable and explicit I don't
think it is modular enough.

>
> 2. Internally, for example a typical DSP like multiplication of two 1.15
> values would yield a 2.30, and the accumulator depth would be kinda up
> to the expected value range of the algo. Slicing to an output format
> seems kinda straightforward, I guess a conversion function (including
> standard rounding options) could come in handy, but apart from that, are
> there any thoughts on how such an assignment and rounding is translated
> into VHDL/Verilog? Or would you leave the rounding to the user (via his
> own rounding convertors)?

Via a "resize" function.  This is similar to other
packages and I think this makes the most sense.  I
will cover this in part II (working out some of the
details).  The "resize" will handle the rounding
and generate the required logic.

     z = resize(x+y,format,
                round_mode='convergent',
                overflow_mode='saturate')

I will get into the details in part II.  Note, in
the above example /x/ and /y/ need to be aligned!

>
> 3. I guess a fixbv should make handling easier for beginners. But for a
> standard rounding option set, quite some documentation needs to be made
> (and read). I am a bit unsure, where the effort would be paying off.
> Eventually, one needs to dig into the hard matter on the bit level when
> it comes to minimize 'binarithmetic' noise, etc.
> Maybe it's best to not discuss it too much and just implement a solution
> that works well for a standard filter bank.

Similiar to /intbv/, /fixbv/ will provide a useful
building block.  Many of the design issues the user
will still need to deal with (how to analyze SNR, etc).

Many of these high-level tools we can collect as well
but a separate pkg/repo would be a more appropriate home.

>
> Just as example, I had been following the concept of a well documented
> DSP (the Blackin). See
> http://www.analog.com/static/imported-files/processor_manuals/Blackfin_pgr_rev2.2.pdf,
> in particular the MAC command section with all the rounding options.
>
> Assuming the fixbv is simply a derived intbv, I guess it's just a matter
> of discussing what other exceptions than overflow would make sense (like
> rounding issues) in order to help with tracking down numerical
> weaknesses (unstable IIRs...).
>

Thanks for the feedback and comments!
Chris

Re: [myhdl-list] fixed-point thoughts : part one

[Tom D. <TD...@Di...>]

Martin,


On Wed, Aug 28, 2013 at 8:34 AM, Martin Strubel <ha...@se...> wrote:

> Hi Chris,
>
> I'd like to see 'fixbv' as a sophisticated standard inside MyHDL. I
> presume many people are cooking their own soup (including me).
>
> Been cooking my own a long time as well.


> 2. Internally, for example a typical DSP like multiplication of two 1.15
> values would yield a 2.30, and the accumulator depth would be kinda up
> to the expected value range of the algo. Slicing to an output format
> seems kinda straightforward, I guess a conversion function (including
> standard rounding options) could come in handy, but apart from that, are
> there any thoughts on how such an assignment and rounding is translated
> into VHDL/Verilog? Or would you leave the rounding to the user (via his
> own rounding convertors)?
>

I would think you would want some conversion functions that had rounding
modes built in.

For example, the fixbv multiply of two 1.15 values would return a 2.30.
 After that there are cases you may
want to just use the 2.30 result, or convert to 1.15, or 2.15 or many
others. During those conversions you
would want options on rounding modes, overflow handling (saturate or
rollover) and so on.

I don't think you would want to build that into the fixbv multiply.

I don't see why those functions would not be convertible already to VHDL or
Verilog.

Just my thoughts, we may be saying the same thing.

Tom

Re: [myhdl-list] fixed-point thoughts : part one

[Martin S. <ha...@se...>]

Hi Chris,

I'd like to see 'fixbv' as a sophisticated standard inside MyHDL. I
presume many people are cooking their own soup (including me).

A few things are still unclear to me though, in particular WRT rounding
options and conversion to synthesizable code. I wouldn't want to
anticipate too much from your announced "part 2" of the proposal, but
let me throw in a few comments/questions anyhow:

1. I'd personally prefer the strict bit definition for the initializer.
   Why not just allow
     a = fixbv("si.ffffff")
   Might only make an automated width generation a little quirky, but so
far I always stuck to a fixed bit size.

2. Internally, for example a typical DSP like multiplication of two 1.15
values would yield a 2.30, and the accumulator depth would be kinda up
to the expected value range of the algo. Slicing to an output format
seems kinda straightforward, I guess a conversion function (including
standard rounding options) could come in handy, but apart from that, are
there any thoughts on how such an assignment and rounding is translated
into VHDL/Verilog? Or would you leave the rounding to the user (via his
own rounding convertors)?

3. I guess a fixbv should make handling easier for beginners. But for a
standard rounding option set, quite some documentation needs to be made
(and read). I am a bit unsure, where the effort would be paying off.
Eventually, one needs to dig into the hard matter on the bit level when
it comes to minimize 'binarithmetic' noise, etc.
Maybe it's best to not discuss it too much and just implement a solution
that works well for a standard filter bank.

Just as example, I had been following the concept of a well documented
DSP (the Blackin). See
http://www.analog.com/static/imported-files/processor_manuals/Blackfin_pgr_rev2.2.pdf,
in particular the MAC command section with all the rounding options.

Assuming the fixbv is simply a derived intbv, I guess it's just a matter
of discussing what other exceptions than overflow would make sense (like
rounding issues) in order to help with tracking down numerical
weaknesses (unstable IIRs...).

Cheers,

- Martin

Re: [myhdl-list] MyHDL : The Case for a Better HDL

[Jonas <jon...@gm...>]

Christopher Felton <chris.felton <at> gmail.com> writes:

> For more information on the first topic, see Jan's "These Ints are Made 
> For Countin'" essay http://jandecaluwe.com/hdldesign/counting.html.

> For me, the "RTL abstraction" section touched on some important points. 
>   How do you effectively teach complex digital systems architecture and 
> implementation (HDL) and the low-level digital circuits?  I see this as 
> a failure in the current education sytle.  We teach the digital systems 
> and HDL the same as the digital circuits, from the bottom-up.  Even 
> folks that are teaching themselves HDL appear to fall into folly.

I was working with VHDL a while ago. I liked a lot the very flexible type
system and the philosophy about code readability even if it results in more
typing. All those good features comes from Ada, on which VHDL was greatly
inspired. From all the languages I know, I see Ada as the best source of
inpiration for an HDL, because you could have a very flexible language with
high level constructs (for each loops, array slicing, attributes, ...), but
with the possibility of specifying low level details. Unfortunately VHDL
wasn't as much fun as it could be for several reasons. One reason was that
VHDL use the good concepts from Ada only halfway. For example the numbers
management. numbers (signed and unsigned) where defined as array of
characters, so they were represented like strings. Then working with them,
doing mixed arithmetics with integer and signed or unsigned wasn't that
natural and has some quirks. In Ada you can optionnally tell the hardware
representation of a variable or a type with a "for ... use" clause. Why not
using such a mechanism in VHDL and than use signed and unsigned types as
real integer ? Then working with numbers could be as easy as that :

  -- VHDL builtins
  type unsigned is range 0 to ∞;
  subtype sys_unsigned is unsigned range 0 to MAX_UNSIGNED;
  --

  variable A : sys_unsigned;
  variable B : unsigned slice 7 downto 0;
  variable C : unsigned slice 8 downto 0;

  A := 2;
  B := A.Fit; -- Resizing is needed here
  C := B + B;
  -- Repr attribute give the hardware representation
  B'Repr <= A'Repr(5 downto 0) & "00"; 

We can even extend the mecanism to other things like enumerate types :

  type Enum is (A, B, C) with (A => "00", B => "11", C => "01");
  type Enum_2 is (D, E, F, G) with Gray_Encoding;

A bigger reason of my bad experience with VHDL, was the persistant mentality
among the community of VHDL to think low level only, even in situation when
thinking high level makes a lot more sense. That leaded to absurd and
outdated coding standards like transforming everything to std_logic or
std_logic_vector in the ports of entities (including unsigned/signed signals
although they are represented exactly the same way as std_logic_vector)
instead of keeping the higher level types, which makes it harder to read and
more error prone. And those coding standards gets imposed upon you but
nobody can tell you why. All you hear is something like "the VHDL experts
told that it has to be done that way".

Even if it sounds weird to me to use python to do HDL, at least I like the
idea of bringing modern ideas and a different mentality in the HDL community.

Re: [myhdl-list] fixed-point thoughts : part one

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

On 8/23/13 7:07 AM, Martin Thompson wrote:
> Christopher Felton <chr...@gm...> writes:
>
> <snip>
> This sounds like an excellent addition to MyHDL's capabilities...
>
>> Example:
>> 	s : sign bit
>> 	i : integer bits
>> 	f : fractional bits
>>
>> 	siii.ffff
>>
>
> I have in the past needed values of this form:
>
> s0.00fff
>
> i.e. three bits of precision representing a small range either side of zero
>
> when using Xilinx System Generator there was not a convenient way to
> represent them using their fixed-point types other than using integers
> and remembering to shift them.
>
> It would be nice if your proposal could represent these types of numbers too.
>
> Would an initialiser of this form work I wonder?
>
>   	x = fixbv(0.033, min=-0.25, max=0.25, res=0.001)

Most definitely, I didn't explicitly call it out but
the proposal intends to support your example or

     x = fixbv(0.033)[4,-2,5]

This is similar to how VHDL and SystemC fixed pkgs
allow negative integer and fractional widths.

Less resolution with small word-widths would also
be supported

    # siiii0000.0
    x = fixbv(34, min=-256, max=256, res=16)

Regards,
Chris

Re: [myhdl-list] fixed-point thoughts : part one

[Martin T. <mar...@tr...>]

Christopher Felton <chr...@gm...> writes:

<snip>
This sounds like an excellent addition to MyHDL's capabilities...

> Example:
> 	s : sign bit
> 	i : integer bits
> 	f : fractional bits
>
> 	siii.ffff
>

I have in the past needed values of this form:

s0.00fff

i.e. three bits of precision representing a small range either side of zero

when using Xilinx System Generator there was not a convenient way to
represent them using their fixed-point types other than using integers
and remembering to shift them.

It would be nice if your proposal could represent these types of numbers too.

Would an initialiser of this form work I wonder?

 	x = fixbv(0.033, min=-0.25, max=0.25, res=0.001)


Cheers,
Martin

-- 
mar...@tr... 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Re: [myhdl-list] MyHDL Tristate Logic

[Jan C. <jen...@mu...>]

On 09/08/13 23:48, Alexander Hungenberg wrote:
> Thank you for your replies.
> I did now indeed switch to the manual way Jan described. Didn't 
> know that this was possible before. :-)
>
> With this I managed to advance quite a bit with my I2C module but 
> just ran into a new problem. When converting the module to VHDL / 
> Verilog I get a warning
> "** ToVHDLWarning: Output port is read internally: sda_oe" 
> (sda_oe is the output enable signal)
> So far so good, but I nowhere do access the value of sda_oe 
> internally.
Converting just I2CByte generates the error:  "Output port is read 
internally: scl"  Using a separate signal for the output fixes 
this, as per regular VHDL code.  Showing changes in part of your 
code, which must also add the new signal:

     # we will update SCL at clock negedges so that we may alter 
SDA on the posedges
     @always_seq(clock.negedge, reset=reset)
     def scl_driver():
         if state == STATES.IDLE:
             scl_i.next = False
         elif state == STATES.START:
             scl_i.next = False
         elif state == STATES.TRANSMIT:
             scl_i.next = not scl_i
         elif state == STATES.STOP:
             scl_i.next = False

     @always_comb
     def port_out():
       ''' write output ports '''
       scl.next = scl_i

     return single_byte, scl_driver, port_out

There is the same problem in I2CBurstProtocol.

Hope this helps, Jan Coombs.
-- 

Re: [myhdl-list] MyHDL Tristate Logic

[Alexander H. <ale...@gm...>]

Thank you for your replies.
I did now indeed switch to the manual way Jan described. Didn't know that
this was possible before. :-)

With this I managed to advance quite a bit with my I2C module but just ran
into a new problem. When converting the module to VHDL / Verilog I get a
warning
"** ToVHDLWarning: Output port is read internally: sda_oe" (sda_oe is the
output enable signal)
So far so good, but I nowhere do access the value of sda_oe internally.

The (quite lengthy) MyHDL and converted VHDL code can be find at pastebin.
Ctrl-F might help to find all sda_oe assignments.
MyHDL: http://pastebin.com/taVCdxR5
VHDL: http://pastebin.com/EPncdgba

I would be glad if you got any suggestions or tips.

Best,
Alex




2013/7/31 Christopher Felton <chr...@gm...>

> On 7/30/13 2:33 PM, Alexander Hungenberg wrote:
> > Hi all!
> >
> > I'm a new user of this very nice piece of software but unfortunately
> > stumbled upon some problem while implementing tri-state logic (of course
> > for an I2C module). Originally I wrote directly to Jan (thank you for
> > your reply!) and he pointed me to this mailing list.
> >
> > Regarding my problem, I am not sure whether it is a bug in MyHDL or my
> > fault, but the generated Verilog code looks wrong to me.
> >
> > MyHDL: http://pastebin.com/sQRnRPFL
> > Verilog: http://pastebin.com/qVzew9wg
> >
> > Especially the fact that tristate is declared as output and not inout as
> > well as the three assign lines make me kind of nervous. Do you have any
> > idea?
> >
> > Best,
> > Alex
> >
>
> This might be a bug, I haven't had time to identify
> a fix.
>
> I posted a tristate FAQ previously:
> http://article.gmane.org/gmane.comp.python.myhdl/2338/match=faq+tri+states
>
> I also copied the embedded code example here:
> https://gist.github.com/cfelton/6119313
>
> For this example, the VHDL creates the tristate and
> inout port correctly, whereas Verilog does not.
> Probably should create an issue on bitbucket.
>
> Regards,
> Chris Felton
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] MEP 107 Initial support

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

On 8/8/2013 10:40 AM, Keerthan jai.c wrote:
> Originally, the implementation did not touch any of the 'reserved'
> attriubutes ('next' etc..) whose names were stored in a list.
> But now, rather than relying on a list of reserved attributes, it just
> ignores all attributes which myhdl._Signal._Signal has, based on hasattr.

Yes, that is a better approach.

>
> The side effect of this is that it is possible to inherit the Signal class
> and add custom attributes without affecting conversion. It is not a
> feature, per se.
>

Ok, I like that.  You get a "nice side effect" for
cleanup and/or more general support.

Thanks,
Chris

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

Originally, the implementation did not touch any of the 'reserved'
attriubutes ('next' etc..) whose names were stored in a list.
But now, rather than relying on a list of reserved attributes, it just
ignores all attributes which myhdl._Signal._Signal has, based on hasattr.

The side effect of this is that it is possible to inherit the Signal class
and add custom attributes without affecting conversion. It is not a
feature, per se.

In my example, a class 'Operand' is defined as a subclass as Signal, and in
its __init__, attributes 'opcode', 'a' and 'b' are added as shadow signals
on particular ranges.
There are no changes to the conversion mechanism. So these attributes get
converted  how normal shadow signals get converted.



On Wed, Aug 7, 2013 at 11:22 PM, Christopher Felton
<chr...@gm...>wrote:

> On 8/7/13 4:30 PM, Keerthan jai.c wrote:
> > I just pushed better support for dealing with signal attributes.
>
> jck,
>
> We want to be a little careful and not add too many
> features to a single enhancement.  This addition
> might warrant some conversation.
>
> You might want to explain what this additional support
> does?  I am not sure if I follow based on the example.
>
> I think it takes and attribute that is a SignalSlice
> and does the name expansion, etc?  Personally, I think
> I would like to see a separate MEP for this and a separate
> commit for the additional feature.  The MEP are great for
> explaining the uses cases etc.  We want to be very careful
> and not have "feature" bloat.
>
> Regards,
> Chris
>
> >
> > This enables us to do cool things such as subclassing Signal to define a
> > bitfield.
> > Among other things, I beleive this feature will be helpful to describe
> > things like instruction opcodes, which are actually a single signal(in
> > memory), rather than a collection of discrete signals.
> > For example:
> >
> > class Operand(Signal):
> >      def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]):
> >          val = concat(fielda, fieldb)
> >          super(Operand, self).__init__(val)
> >          self.opcode = self(20, 16)
> >          self.a = self(16, 8)
> >          self.b = self(8, 0)
> >
> > def decoder(operand, ...):
> >      @always_comb
> >      def logic():
> >          if operand.opcode == ...
> > ...
> >
> > and in the generated HDL, operand.opcode would refer to bits 20:16.
> >
> >
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

[myhdl-list] Simplified FPGA tool flow

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

Recently at a regional python conference (@pyohio [1][2]) I gave
a hands-on introduction to MyHDL and FPGA.  It was a time limited
open-space and we only scratched the surface of MyHDL and FPGA dev.

The FPGA tool flow can be daunting.  I new going into it I had to
simplify the tool flow to a single "push button" compile, at least
for trivial examples one typically starts with.  We could not waste
time learning a particular vendors IDE.

I put together a set of scripts to drive conversion, match ports,
and execute the FPGA tool flow (synthesize, map, PaR, bit).  I
have this in a repository called myhdl_tools [3].

What I think is useful, is that the package contains a collection
of development board definitions.  The the package will manage
mapping the ports to pins and generate the constraints (limited at
this point to support basic designs).

I think the cool feature is: if you use the default names from
the development board (e.g. the schematic net names) in the top-level
module you are done.  The package will map the module ports to the
ports defined in the dev board entry, you don't need to do anything.
If the top-level port names do not match, you need to add the new
port (or soon, map ports).  See [4][5] for examples.

The tools will assist driving the flow but it does not assist
installing the vendor tools, installation is still a pain :)

Guenter's original work [6], spawned this development.

Regards,
Chris

[1] http://www.pyohio.org
[2] http://www.fpgarelated.com/showarticle/433.php
[3] http://www.bitbucket.org/cfelton/myhdl_tools
[4] http://www.bitbucket.org/cfelton/pyohio/2013/workshop
[5] http://www.fpgarelated.com/showarticle/437.php
[6] http://myhdl.org/doku.php/projects:ise_py

Re: [myhdl-list] MEP 107 Initial support

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

On 8/7/13 4:30 PM, Keerthan jai.c wrote:
> I just pushed better support for dealing with signal attributes.

jck,

We want to be a little careful and not add too many
features to a single enhancement.  This addition
might warrant some conversation.

You might want to explain what this additional support
does?  I am not sure if I follow based on the example.

I think it takes and attribute that is a SignalSlice
and does the name expansion, etc?  Personally, I think
I would like to see a separate MEP for this and a separate
commit for the additional feature.  The MEP are great for
explaining the uses cases etc.  We want to be very careful
and not have "feature" bloat.

Regards,
Chris

>
> This enables us to do cool things such as subclassing Signal to define a
> bitfield.
> Among other things, I beleive this feature will be helpful to describe
> things like instruction opcodes, which are actually a single signal(in
> memory), rather than a collection of discrete signals.
> For example:
>
> class Operand(Signal):
>      def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]):
>          val = concat(fielda, fieldb)
>          super(Operand, self).__init__(val)
>          self.opcode = self(20, 16)
>          self.a = self(16, 8)
>          self.b = self(8, 0)
>
> def decoder(operand, ...):
>      @always_comb
>      def logic():
>          if operand.opcode == ...
> ...
>
> and in the generated HDL, operand.opcode would refer to bits 20:16.
>
>
>

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

I just created a 0.9-dev branch, merged the mep107 branch into it and sent
a pull request to jandecaluwe/myhdl.


If you would like to improve upon this implementation, you can fork the
mep107 branch at https://bitbucket.org/jck2/myhdl/* *and send me a pull
request.

The full changeset can be viewed here:
https://bitbucket.org/jandecaluwe/myhdl/pull-request/3/


On Wed, Aug 7, 2013 at 5:33 PM, Keerthan jai.c <jck...@gm...> wrote:

> Oops, the first line in __init__ of Operand should be:
> concat(opcode, a, b)
>
>
> On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm...>wrote:
>
>> I just pushed better support for dealing with signal attributes.
>>
>> This enables us to do cool things such as subclassing Signal to define a
>> bitfield.
>> Among other things, I beleive this feature will be helpful to describe
>> things like instruction opcodes, which are actually a single signal(in
>> memory), rather than a collection of discrete signals.
>> For example:
>>
>> class Operand(Signal):
>>     def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]):
>>         val = concat(fielda, fieldb)
>>         super(Operand, self).__init__(val)
>>         self.opcode = self(20, 16)
>>         self.a = self(16, 8)
>>         self.b = self(8, 0)
>>
>> def decoder(operand, ...):
>>     @always_comb
>>     def logic():
>>         if operand.opcode == ...
>> ...
>>
>> and in the generated HDL, operand.opcode would refer to bits 20:16.
>>
>>
>>
>> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton <
>> chr...@gm...> wrote:
>>
>>> On 7/29/13 5:23 PM, Keerthan jai.c wrote:
>>> > Thanks a lot Chris!
>>> >
>>> > Jan,
>>> > Did you get a chance to take a look at the implementation? I would love
>>> > to hear some feedback on whether you think this implementation can be
>>> > merged into myhdl.
>>> >
>>> >
>>>
>>> @jck,
>>>
>>> I just submitted a pull-request with some mods to
>>> the tests and a start on some documentation.  At
>>> this point I would suggest we create a 0.9-dev branch,
>>> merge the mep-107 to the 0.9-dev, and create a
>>> pull-request to Jan's repo.
>>>
>>> It will be easier to comment on the changes etc. in
>>> the pull-request.
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get your SQL database under version control now!
>>> Version control is standard for application code, but databases havent
>>> caught up. So what steps can you take to put your SQL databases under
>>> version control? Why should you start doing it? Read more to find out.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>>
>>
>>
>>
>> --
>> have a nice day
>> -jck
>>
>
>
>
> --
> have a nice day
> -jck
>



-- 
have a nice day
-jck

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

Oops, the first line in __init__ of Operand should be:
concat(opcode, a, b)


On Wed, Aug 7, 2013 at 5:30 PM, Keerthan jai.c <jck...@gm...> wrote:

> I just pushed better support for dealing with signal attributes.
>
> This enables us to do cool things such as subclassing Signal to define a
> bitfield.
> Among other things, I beleive this feature will be helpful to describe
> things like instruction opcodes, which are actually a single signal(in
> memory), rather than a collection of discrete signals.
> For example:
>
> class Operand(Signal):
>     def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]):
>         val = concat(fielda, fieldb)
>         super(Operand, self).__init__(val)
>         self.opcode = self(20, 16)
>         self.a = self(16, 8)
>         self.b = self(8, 0)
>
> def decoder(operand, ...):
>     @always_comb
>     def logic():
>         if operand.opcode == ...
> ...
>
> and in the generated HDL, operand.opcode would refer to bits 20:16.
>
>
>
> On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton <
> chr...@gm...> wrote:
>
>> On 7/29/13 5:23 PM, Keerthan jai.c wrote:
>> > Thanks a lot Chris!
>> >
>> > Jan,
>> > Did you get a chance to take a look at the implementation? I would love
>> > to hear some feedback on whether you think this implementation can be
>> > merged into myhdl.
>> >
>> >
>>
>> @jck,
>>
>> I just submitted a pull-request with some mods to
>> the tests and a start on some documentation.  At
>> this point I would suggest we create a 0.9-dev branch,
>> merge the mep-107 to the 0.9-dev, and create a
>> pull-request to Jan's repo.
>>
>> It will be easier to comment on the changes etc. in
>> the pull-request.
>>
>> Regards,
>> Chris
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
> --
> have a nice day
> -jck
>



-- 
have a nice day
-jck

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

I just pushed better support for dealing with signal attributes.

This enables us to do cool things such as subclassing Signal to define a
bitfield.
Among other things, I beleive this feature will be helpful to describe
things like instruction opcodes, which are actually a single signal(in
memory), rather than a collection of discrete signals.
For example:

class Operand(Signal):
    def __init__(opcode=intbv(0)[4:], a=intbv(0)[8:], b=intbv(0)[8:]):
        val = concat(fielda, fieldb)
        super(Operand, self).__init__(val)
        self.opcode = self(20, 16)
        self.a = self(16, 8)
        self.b = self(8, 0)

def decoder(operand, ...):
    @always_comb
    def logic():
        if operand.opcode == ...
...

and in the generated HDL, operand.opcode would refer to bits 20:16.



On Mon, Aug 5, 2013 at 10:11 PM, Christopher Felton
<chr...@gm...>wrote:

> On 7/29/13 5:23 PM, Keerthan jai.c wrote:
> > Thanks a lot Chris!
> >
> > Jan,
> > Did you get a chance to take a look at the implementation? I would love
> > to hear some feedback on whether you think this implementation can be
> > merged into myhdl.
> >
> >
>
> @jck,
>
> I just submitted a pull-request with some mods to
> the tests and a start on some documentation.  At
> this point I would suggest we create a 0.9-dev branch,
> merge the mep-107 to the 0.9-dev, and create a
> pull-request to Jan's repo.
>
> It will be easier to comment on the changes etc. in
> the pull-request.
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] MEP 107 Initial support

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

On 7/29/13 5:23 PM, Keerthan jai.c wrote:
> Thanks a lot Chris!
>
> Jan,
> Did you get a chance to take a look at the implementation? I would love
> to hear some feedback on whether you think this implementation can be
> merged into myhdl.
>
>

@jck,

I just submitted a pull-request with some mods to
the tests and a start on some documentation.  At
this point I would suggest we create a 0.9-dev branch,
merge the mep-107 to the 0.9-dev, and create a
pull-request to Jan's repo.

It will be easier to comment on the changes etc. in
the pull-request.

Regards,
Chris

[myhdl-list] fixed-point thoughts : part one

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

Introduction
=============
A couple years ago I adopted Tom Dillon’s Python
fixed-point module [1] and used the /intbv/ as a
base class, hence convertible.  I would like to
start taking the steps to get the /fixbv/ type into
the MyHDL package (target 0.9).  The following is a
conversation on a proposed MyHDL fixed-point type,
/fixbv/ (a MEP will be created post any conversations).

The brief fixed-point primer:  a fixed-point bit-vector
represents a signed rational fractional value.  The
*point* will be logically assigned at some position
in the bit-vector.  The bits to the left of the *point*
are the -well known- integer values and the bits to
the right are the fractional values.

Example:
	s : sign bit
	i : integer bits
	f : fractional bits

	siii.ffff

The above example is an 8-bit bit-vector with three
integer bits and four fractional bits.  The fractional
values are combinations of negative powers of two,
analogous, integers are combinations of positive powers
of two.

     In [8]: [2**(-1*ii) for ii in range(1,9)]
     Out[8]: [0.5, 0.25, 0.125, 0.0625, 0.03125,
              0.015625, 0.0078125, 0.00390625]


fixbv class
============
Creating a /fixbv/ object should be straightforward.
I followed Jan Decaluwe’s lead and designed the /fixbv/
instantiation similar to /intbv/.  Meaning, the natural
method to declare a /fixbv/ is to define the: initial
value, minimum, maximum, and resolution.

Example:

	x = fixbv(0.333, min=-1, max=1, res=0.1)

The resolution is the smallest quantity representable.
In many cases the requested /res/ cannot be encoded
exactly with a reasonable number of bits.  As mentioned,
the resolution is limited to negative powers of two.
In the above example a resolution of 0.1 is defined
and the resulting resolution will be 0.0625.  This
resolution is better than the 0.1 but will have the
downside that multiples of the requested resolution
cannot be represented exactly.  If the goal is to encode:
0.1, 0.2, 0.3, 0.4, etc., it cannot with a finite number
of bits.  The basic idea: if one of the denominators
prime multiples (e.g. 2 and 5 for 10) is not a multiple
of the base then the rational fraction cannot be
represented exactly (something to that effect).

The above definition (instantiation) should cover most
of the use cases.  Except, some designers have the habit
of defining the bits explicitly.  Like the /intbv/ the
proposed /fixbv/ would allow the definition of the bits
contained.  To define the bits the word-length (wl),
integer word-length (iwl), and fractional word-length
(fwl) are set, example:

	fixbv(0)[wl,iwl,fwl]

The word-lengths have a simple relation:

	wl = iwl + fwl + 1

There are a couple more arguments that are needed to
complete the constructor:

	rounding_mode : instructs how to round the
                         initial value
	overflow_mode : instructs how to handle overflow
                         in the initial value

There are six different round modes and two overflow
modes supported by /fixbv/ type.  These will be discussed
again in the operators discussions (part two).

The complete /fixbv/ constructor is:

fixbv(val, [, min=-1] [, max=1] [, res=None]
       [, round_mode=’convergent’]
       [, overflow_mode=’saturate’])


This was part one of the conversations on fixed-point.
This post covered the fixed-point representation and
constructing a /fixbv/ object.  The next post will
cover fixed-point operations.

Regards,
Chris

[1] http://www.dilloneng.com/documents/downloads/demodel/

Re: [myhdl-list] MyHDL Tristate Logic

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

On 7/30/13 2:33 PM, Alexander Hungenberg wrote:
> Hi all!
>
> I'm a new user of this very nice piece of software but unfortunately
> stumbled upon some problem while implementing tri-state logic (of course
> for an I2C module). Originally I wrote directly to Jan (thank you for
> your reply!) and he pointed me to this mailing list.
>
> Regarding my problem, I am not sure whether it is a bug in MyHDL or my
> fault, but the generated Verilog code looks wrong to me.
>
> MyHDL: http://pastebin.com/sQRnRPFL
> Verilog: http://pastebin.com/qVzew9wg
>
> Especially the fact that tristate is declared as output and not inout as
> well as the three assign lines make me kind of nervous. Do you have any
> idea?
>
> Best,
> Alex
>

This might be a bug, I haven't had time to identify
a fix.

I posted a tristate FAQ previously:
http://article.gmane.org/gmane.comp.python.myhdl/2338/match=faq+tri+states

I also copied the embedded code example here:
https://gist.github.com/cfelton/6119313

For this example, the VHDL creates the tristate and
inout port correctly, whereas Verilog does not.
Probably should create an issue on bitbucket.

Regards,
Chris Felton

Re: [myhdl-list] MyHDL Tristate Logic

[Jan C. <jen...@mu...>]

On 30/07/13 20:33, Alexander Hungenberg wrote:
> Hi all!
>
> I'm a new user of this very nice piece of software but 
> unfortunately stumbled upon some problem while implementing 
> tri-state logic (of course for an I2C module). Originally I wrote 
> directly to Jan (thank you for your reply!) and he pointed me to 
> this mailing list.
<snip>

If your chip has tri-state buffers, then you can drive the I2C bus 
by connecting the outgoing signal to the enable pin on the outgoing 
pin buffer, and tying it's input low.  An internal or external 
pullup is required to complete the driver.  The incoming bus 
signals can be read via the pin input buffer.

Since the input and output signals are separate in hardware, why 
would you want to model them combined as tri-state signals?

Jan Coombs.

[myhdl-list] MyHDL Tristate Logic

[Alexander H. <ale...@gm...>]

Hi all!

I'm a new user of this very nice piece of software but unfortunately
stumbled upon some problem while implementing tri-state logic (of course
for an I2C module). Originally I wrote directly to Jan (thank you for your
reply!) and he pointed me to this mailing list.

Regarding my problem, I am not sure whether it is a bug in MyHDL or my
fault, but the generated Verilog code looks wrong to me.

MyHDL: http://pastebin.com/sQRnRPFL
Verilog: http://pastebin.com/qVzew9wg

Especially the fact that tristate is declared as output and not inout as
well as the three assign lines make me kind of nervous. Do you have any
idea?

Best,
Alex

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

Thanks a lot Chris!

Jan,
Did you get a chance to take a look at the implementation? I would love to
hear some feedback on whether you think this implementation can be merged
into myhdl.


On Sun, Jul 14, 2013 at 12:00 AM, Christopher Felton <chr...@gm...
> wrote:

> On 7/4/13 9:37 PM, Keerthan jai.c wrote:
> > I have also added support for inferring portnames from objects.
> > There is no depth restriction, You can safely use something like
> > instance.attr1.attr2.next = something.
> >
> > Feel free to try it out and let me know if you experience any errors.
> >
> >
> > On Wed, Jul 3, 2013 at 10:44 PM, Keerthan jai.c <jck...@gm...
> > <mailto:jck...@gm...>> wrote:
> >
> >     Hi,
> >
> >     I've added inital support for conversion of attribute references. So
> >     far, it does not support inferring port names at the top level.
> >     However, it does support attribute referencing in lower levels of
> >     the hierarchy. I have not yet tested it extensively, but I did
> >     confirm it does not break any older tests.
> >
> >     You can find it in the MEP107 branch here:
> >     https://bitbucket.org/jck2/myhdl
> >
> >     --
> >     have a nice day
> >     -jck
> >
> >
>
> I have not had time to review the changes line-by-line
> but I have added a couple unit tests [1] and tested on
> a project [2][3].
>
> jck has added the unit tests to the repository mentioned
> above [4].  See jck's repo for the latest implementation.
>
> Functionally this implementation looks complete and has
> tested well.  Thanks for the implementation jck!  This
> is really exciting.  All the tests in conversion/general
> appear to pass, need to run the other tests when we have
> a chance.
>
> Regards,
> Chris Felton
>
> [1] https://bitbucket.org/cfelton/myhdl_interfaces_09dev
> [2] https://github.com/cfelton/minnesota/tree/myhdl_09
>
>
> https://github.com/cfelton/minnesota/blob/myhdl_09/mn/cores/usb_ext/fpgalink/_fpgalink_fx2.py
> [3] https://groups.google.com/forum/#!topic/fpgalink-users/P8q7texZqIQ
> [4] https://bitbucket.org/jck2/myhdl
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

[myhdl-list] myhdl @pyohio

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

Anyone in the Columbus Ohio area in the United States
this upcoming weekend (7/27 and 7/28) should stop by
the @pyohio conference [1].  This is a *FREE* regional
python conference.  I will be giving a talk at the end
of the day Sunday and a hands-on workshop following.

The talk will focus on introducing programmable hardware
(FPGAs) to "imperative thinkers" (quote stolen from
twitter).

Most of the talk is an introduction to programmable
hardware and contrast it to the modern computer and will
conclude introducing MyHDL.  The workshop will walk through
a simple example and allow Python programmers to modify
the example, configure a development board and observe
their modifications.  Xess corp was kind and loaned a set
of development boards [2][3] for the hands-on workshop

Regards,
Chris

[1] http://pyohio.org/
[2] http://www.xess.com/prods/prod048.php
[3] http://www.xess.com/prods/prod050.php

Re: [myhdl-list] Question about conversion of slice types

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

On 7/17/2013 12:38 PM, Martin Strubel wrote:
> Hi list,
>
> for a few reasons, one of them being switchable external definitions,
> I'd like to define slice types as follows:
>
> OP_INDEX = slice(11, 8)
> OP_MODE = slice(8, 6)
>
> and use them later in the HDL. No problem in the native simulation, but
> obviously, myhdl would not convert the slice type into VHDL. I've done
> some patching in the AST-featured visitors to turn the slice into a subtype:
>
>      subtype OP_INDEX is integer range 11-1 downto 8;
>
> to be used by the HDL conversion as:
>
>          index := resize(opcode(OP_INDEX), 11);
>
> Now with the new shadow signals, in particular the slice signal, a
> presumably much more elegant solution is possible, but when I tried
> last, it wouldn't infer the signal for some reason (not investigated
> further). I'm using the 0.8 sourceforge distribution.
>
> Apology if I'm bringing up some FAQ, but does anyone see reasons not to
> do it this way or problems for the Verilog conversion side?
>
> Cheers,
>
> - Strubi
>


I like the idea of converting 'slice' but I would think
direct conversion would be suitable.  The 'slice' is setup
in elaboration (outside the generators) and is static in the
generators (generators are the converted sections), the converter
could directly insert the literals in the converted code, then
it works for Verilog and VHDL.

Regards,
Chris