myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Henry G. <he...@ca...>]

On 14/06/15 06:32, Ben Reynwar wrote:
> You should be able to take advantage of pyvivado Vivado stuff just by 
> using the `pyvivado.project` module.  You could just use that along 
> with all the V* files that you generated using Veriutils.  The main 
> speedup you get is that the project only gets regenerated if the files 
> have changed, which doesn't make much difference during development 
> but is a big plus when you're running unit tests later.  Still 
> annoyingly slow though!
>

Yeah, it is crap. There is a huge overhead in doing anything in Vivado - 
all my tests are creating new instances which takes ~7 seconds or so

> If I understand your comments on wrapper generation, you're suggesting 
> something similar to what I'm doing with the interface functions but 
> more formalized.  I could then use that same definition to generate 
> VHDL wrappers or a MyHDL wrapper. Is that correct?

Yeah exactly. Some sort of simple interface language/definition from 
which interface wrappers can be generated. Certainly, it's a common 
problem in myhdl that is in need of a neat solution.

That said, what does the new use_std_logic flag do? Is that per-module?

Cheers,

Henry

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Ben R. <be...@re...>]

You should be able to take advantage of pyvivado Vivado stuff just by using
the `pyvivado.project` module.  You could just use that along with all the
V* files that you generated using Veriutils.  The main speedup you get is
that the project only gets regenerated if the files have changed, which
doesn't make much difference during development but is a big plus when
you're running unit tests later.  Still annoyingly slow though!

If I understand your comments on wrapper generation, you're suggesting
something similar to what I'm doing with the interface functions but more
formalized.  I could then use that same definition to generate VHDL
wrappers or a MyHDL wrapper.  Is that correct?



On Sat, Jun 13, 2015 at 2:58 AM, Henry Gomersall <he...@ca...> wrote:

> On 06/05/15 18:54, Ben Reynwar wrote:
> > At the moment pyvivado is doing four fairly independent things for me:
> >
> > 1) I use it as a build system to keep track of which modules depend on
> > which other modules and IP blocks and to specify how files that need
> > to be generated are generated.
> > 2) I use it to run python unittests (very similar to what you do with
> > veriutils)
> > 3) I use it to automate Vivado (simulation, synthesis, implementation
> > and deployment)
> > 4) I use it to communicate with the FPGA from python.
>
> Hi Ben (and all),
>
> I've been thinking a bit more about this (in the context of every call
> to vivado taking an age to run) and I've just taken a bit of a look at
> your code. I'm sure Veriutils could benefit from the build system you
> offer. You've clearly put a lot of work into the interaction with Vivado
> and it would be stupid for me to replicate it all (Veriutil's
> interaction is very much simpler - a basic tcl script that is fleshed
> out with a template and then executed).
>
> There's the mucky area around wrapping V* code, which you attack with
> your python function to generate an interface. My experience so far has
> been there are a few things that one wants to consider in wrapping
> existing code:
> 1) There are the port mappings (which may include different names).
> 2) Type conversions.
> 3) Ports held as a constant.
> 4) other things I've not thought of...
>
> I dare say it would be possible to have a way of formalising those
> aspects, which could then be used to auto-generate wrappers around V*
> code. For some piece of VHDL (say), I currently have a VHDL wrapper as
> well as a vhdl_code snippet in the respective myhdl function.
>
> I think this could be a really useful bit of code to break out as a
> separate project. I think it would make interaction between myhdl and
> vhdl much easier.
>
> Cheers,
>
> Henry
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Henry G. <he...@ca...>]

On 06/05/15 18:54, Ben Reynwar wrote:
> At the moment pyvivado is doing four fairly independent things for me:
>
> 1) I use it as a build system to keep track of which modules depend on 
> which other modules and IP blocks and to specify how files that need 
> to be generated are generated.
> 2) I use it to run python unittests (very similar to what you do with 
> veriutils)
> 3) I use it to automate Vivado (simulation, synthesis, implementation 
> and deployment)
> 4) I use it to communicate with the FPGA from python.

Hi Ben (and all),

I've been thinking a bit more about this (in the context of every call 
to vivado taking an age to run) and I've just taken a bit of a look at 
your code. I'm sure Veriutils could benefit from the build system you 
offer. You've clearly put a lot of work into the interaction with Vivado 
and it would be stupid for me to replicate it all (Veriutil's 
interaction is very much simpler - a basic tcl script that is fleshed 
out with a template and then executed).

There's the mucky area around wrapping V* code, which you attack with 
your python function to generate an interface. My experience so far has 
been there are a few things that one wants to consider in wrapping 
existing code:
1) There are the port mappings (which may include different names).
2) Type conversions.
3) Ports held as a constant.
4) other things I've not thought of...

I dare say it would be possible to have a way of formalising those 
aspects, which could then be used to auto-generate wrappers around V* 
code. For some piece of VHDL (say), I currently have a VHDL wrapper as 
well as a vhdl_code snippet in the respective myhdl function.

I think this could be a really useful bit of code to break out as a 
separate project. I think it would make interaction between myhdl and 
vhdl much easier.

Cheers,

Henry

Re: [myhdl-list] Signal has multiple drivers: tlp_tx_tvalid_renamed0

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

On 6/11/2015 10:39 AM, Guy Eschemann wrote:
> Hi,
>
> I'm not sure why the following code gives the conversion error mentioned
> above.

It is a known issue in the 0.9dev:
https://github.com/jandecaluwe/myhdl/issues/82

You can checkout 88cb76b and it should fix this
issue:

     >> git checkout 88cb76b

But this previous issue does not have the fix for
interface attribute constant conversion.

Hope this helps,
Chris

[myhdl-list] Signal has multiple drivers: tlp_tx_tvalid_renamed0

[Guy E. <guy...@gm...>]

Hi,

I'm not sure why the following code gives the conversion error mentioned
above.

===

from myhdl import *

class TlpTxInterface:
    """ PCIe endpoint TX-interface """
    def __init__(self):
        self.tvalid = Signal(bool(False))

def tx_engine(clk, rst, tlp_tx):

    t_tx_state = enum("TX_IDLE", "TX_CPLD_WORD0", "TX_CPLD_WORD1",
"TX_CPLD_WAIT_ACK", "TX_DONE")

    s_tx_state_r = Signal(t_tx_state.TX_IDLE)

    @always_seq(clk.posedge, reset=rst)
    def logic():

        if s_tx_state_r == t_tx_state.TX_IDLE:
            s_tx_state_r.next = t_tx_state.TX_CPLD_WORD0
            tlp_tx.tvalid.next = 0

        elif s_tx_state_r == t_tx_state.TX_CPLD_WORD0:
            tlp_tx.tvalid.next = 1
            s_tx_state_r.next = t_tx_state.TX_CPLD_WORD1

        elif s_tx_state_r == t_tx_state.TX_CPLD_WORD1:
            tlp_tx.tvalid.next = 1
            s_tx_state_r.next = t_tx_state.TX_CPLD_WAIT_ACK

        elif s_tx_state_r == t_tx_state.TX_CPLD_WAIT_ACK:
            s_tx_state_r.next = t_tx_state.TX_DONE

        elif s_tx_state_r == t_tx_state.TX_DONE:
            s_tx_state_r.next = t_tx_state.TX_CPLD_WORD1

    return instances()

if __name__ == "__main__":
    # Define port signals:
    clk = Signal(bool(0))
    rst = ResetSignal(0, active=1, async=False)
    tlp_tx = TlpTxInterface()

    # Convert to VHDL:
    toVHDL.std_logic_ports = True
    inst_tx_engine = toVHDL(tx_engine, clk, rst, tlp_tx)


===

Thanks,
Guy.

Re: [myhdl-list] tri1 and tri0 net types

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

On 6/9/2015 4:32 PM, Jan Marjanovic wrote:
> Hi,
>
> I am starting to experiment with MyHDL and I noticed that there is a feature
> missing, namely an equivalent to tri1 and tri0 net types in Verilog. They are
> used to model a net with a pull-up or pull-down resistor, e.g. an I2C bus.

You should be able to do what you want with the
TristateSignal [1].

There were some questions recently on IRC, couple
examples from that discussion:

https://gist.github.com/cfelton/748f5364a1a483f1e982
https://gist.github.com/josyb/c816d585e12ae397627b
https://gist.github.com/cfelton/6119313

There is an outstanding TristateSignal conversion
bug but with any luck (resources) we should have
it fixed soon ...

Hope that helps,
Chris

[1] 
http://docs.myhdl.org/en/latest/manual/reference.html?highlight=tracesignals#myhdl.traceSignals

[myhdl-list] tri1 and tri0 net types

[Jan M. <jan...@ou...>]

Hi,

I am starting to experiment with MyHDL and I noticed that there is a feature 
missing, namely an equivalent to tri1 and tri0 net types in Verilog. They are 
used to model a net with a pull-up or pull-down resistor, e.g. an I2C bus.

I believe that this feature could add to completeness of the language, and 
also that it is quite trivial to implement it. The user would specify a 
default value to TristateSignal constructor and the resolve function will 
honor the default value instead of just returning None when no driver is 
driving the net.

What do the others think?

Best Regards,
(the other) Jan

Re: [myhdl-list] multiple instances and (e.g.) vhdl_code

[Henry G. <he...@ca...>]

On 08/06/15 13:41, Christopher Felton wrote:
> On 6/8/2015 7:05 AM, Henry Gomersall wrote:
>> Is there a template string for getting an identifier for the current
>> instance when using vhdl_code?
>>
>> That is, I want the name of the function inside the vhdl code to be
>> different for each call to the instance constructor. So the vhdl_code
>> could look something like:
>> FOO_BAR.vhdl_code = '''
>> foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
>> ...
>> '''
> I don't believe there exists an automatic method for
> doing this, you would need to manage it yourself.  You
> could have a random unique value created or use a `id`
> string argument to the module (function).
>
> You could use a function attribute and increment on
> each call [1]:
>
>       def vhdl_stub(...)
>           vhdl_stub.id = vhdl_stub.id + 1
>           this_id = vhdl_stib_id
>
>

Thanks Chris,

That is essentially what I've done (albeit with a global list keeping 
track of the allocated values). I do think there is probably grounds for 
an ID to be set by the converter.

Cheers,

Henry

Re: [myhdl-list] multiple instances and (e.g.) vhdl_code

[Ben <ben...@gm...>]

That is a frequent request, and as such, I think it would make sense
to implement, document such an automatic method in the core of MyHDL.

Regards,
Ben.

On Mon, Jun 8, 2015 at 2:41 PM, Christopher Felton
<chr...@gm...> wrote:
> On 6/8/2015 7:05 AM, Henry Gomersall wrote:
>> Is there a template string for getting an identifier for the current
>> instance when using vhdl_code?
>>
>> That is, I want the name of the function inside the vhdl code to be
>> different for each call to the instance constructor. So the vhdl_code
>> could look something like:
>> FOO_BAR.vhdl_code = '''
>> foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
>> ...
>> '''
>
> I don't believe there exists an automatic method for
> doing this, you would need to manage it yourself.  You
> could have a random unique value created or use a `id`
> string argument to the module (function).
>
> You could use a function attribute and increment on
> each call [1]:
>
>      def vhdl_stub(...)
>          vhdl_stub.id = vhdl_stub.id + 1
>          this_id = vhdl_stib_id
>
> Regards,
> Chris
>
> [1] https://gist.github.com/cfelton/79012fa54868fbd2ebf7
>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] multiple instances and (e.g.) vhdl_code

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

On 6/8/2015 7:05 AM, Henry Gomersall wrote:
> Is there a template string for getting an identifier for the current
> instance when using vhdl_code?
>
> That is, I want the name of the function inside the vhdl code to be
> different for each call to the instance constructor. So the vhdl_code
> could look something like:
> FOO_BAR.vhdl_code = '''
> foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
> ...
> '''

I don't believe there exists an automatic method for
doing this, you would need to manage it yourself.  You
could have a random unique value created or use a `id`
string argument to the module (function).

You could use a function attribute and increment on
each call [1]:

     def vhdl_stub(...)
         vhdl_stub.id = vhdl_stub.id + 1
         this_id = vhdl_stib_id

Regards,
Chris

[1] https://gist.github.com/cfelton/79012fa54868fbd2ebf7

[myhdl-list] multiple instances and (e.g.) vhdl_code

[Henry G. <he...@ca...>]

Is there a template string for getting an identifier for the current 
instance when using vhdl_code?

That is, I want the name of the function inside the vhdl code to be 
different for each call to the instance constructor. So the vhdl_code 
could look something like:
FOO_BAR.vhdl_code = '''
foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
...
'''

I'm currently working around it with a module local list of allocated 
ids and creating a new one each time. This works, but is not very neat.

Cheers,

Henry

Re: [myhdl-list] Initial value support

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

On 6/5/2015 6:38 AM, Henry Gomersall wrote:
> What is current status of the initial value support? My understanding is
> that the code is there but comes caveat emptor.
>
> Certainly, in the Xilinx FPGA world, initial values seem to be the
> preferred strategy:
> http://www.xilinx.com/support/documentation/white_papers/wp272.pdf
>
> (though I appreciate that ASICs are not like that).

Yes, there is code that can be enable for initial value
support (IVS).  At one point XST actually failed on IVS.

Before enabling we wanted to do our due-diligence and
verify most major tools supported:

http://dev.myhdl.org/tasks/initial-values-support.html
http://dev.myhdl.org/ideas/initial-values.html

Creating an issue request IVS to be enabled is probably
a reasonable path forward (or a PR enabling it).

Inevitably, IVS also morphs into RAM initialization
support (RIS), which is less consistent between
languages and vendors.  We should not try and include
RIS when enabling IVS.

Regards,
Chris

Re: [myhdl-list] Constant assignments in co-simulation

[Nikolay K. <nik...@gm...>]

On 5 June 2015 at 13:29, Henry Gomersall <he...@ca...> wrote:

> I would have expected the Verilog to work as expected. Does it need a
bitwidth or something?

I would also expect so. My guess is that the problem is in the interface
between MyHDL and Icarus. The OutPort never changes value, the expression
assign OutPort = CONSTANT is never evaluated, the value on the MyHDL side
is never updated... something like that. When you put the assignment in a
alway @ section which is evaluated, the value on the MyHDL side in correct.


> What do other simulators do?

I haven't tried with other simulators.

Nkolay



On 5 June 2015 at 13:29, Henry Gomersall <he...@ca...> wrote:

>  On 05/06/15 12:19, Nikolay Kavaldjiev wrote:
>
> During co-simulation we expect to see the output ports aBit and aByte of
> the co-simulated module to be assigned values True and 55 respectively.
> However, the values that we actually see are different, False and 0. These
> are the default values of the signals my_bit and my_byte connected to the
> co-simulated module.
>
> The Reason
>
> We are not sure what the reason for this problem is, but what causes the
> problem seams to be a Verilog continuous assignments of type:
>
> assign OutPort = CONSTANT
>
>
> I would have expected the Verilog to work as expected. Does it need a
> bitwidth or something?
>
> What do other simulators do?
>
> Henry
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

[myhdl-list] Initial value support

[Henry G. <he...@ca...>]

What is current status of the initial value support? My understanding is 
that the code is there but comes caveat emptor.

Certainly, in the Xilinx FPGA world, initial values seem to be the 
preferred strategy:
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf

(though I appreciate that ASICs are not like that).

Cheers,

Henry

Re: [myhdl-list] Constant assignments in co-simulation

[Henry G. <he...@ca...>]

On 05/06/15 12:19, Nikolay Kavaldjiev wrote:
>
> During co-simulation we expect to see the output ports aBit and aByte 
> of the co-simulated module to be assigned values True and 55 
> respectively. However, the values that we actually see are different, 
> False and 0. These are the default values of the signals my_bit and 
> my_byte connected to the co-simulated module.
>
> The Reason
>
> We are not sure what the reason for this problem is, but what causes 
> the problem seams to be a Verilog continuous assignments of type:
>
> assign  OutPort=  CONSTANT

I would have expected the Verilog to work as expected. Does it need a 
bitwidth or something?

What do other simulators do?

Henry

Re: [myhdl-list] Constant assignments in co-simulation

[Nikolay K. <nik...@gm...>]

Hi All,

To close this thread, I give a summary and a workaround, which can also be
found in the original gist:
https://gist.github.com/nkavaldj/650fafbc3693f7a501e2

==============

The Problem

When we do MyHDL co-simulation using Icarus Verilog simulator, we have the
following problem: if in the converted MyHDL code we have a combinatorial
assignment of type

OutPort.next = CONSTANT

, where OutPort is an output port of the co-simulated module and CONSTANT
is some constant value, then during the co-simulation, in MyHDL we do not
see on OutPort value CONSTANT.

The problem is demonstrated by the code in cosim_issue.py given in the gist
above. There we have the MyHDL module "const_assign":

def const_assign(x, y, aBit, aByte):
    @always_comb
    def logic():
        y.next = x + 5
        aBit.next = True
        aByte.next = 55
    return logic

, which we convert to Verilog:

module const_assign (
    x,
    y,
    aBit,
    aByte
);
input [7:0] x;output [7:0] y;wire [7:0] y;output aBit;wire aBit;output
[7:0] aByte;wire [7:0] aByte;
assign y = (x + 5);assign aBit = 1'b1;assign aByte = 55;
endmodule

, and then we co-simulate with Icarus Veriog.

During co-simulation we expect to see the output ports aBit and aByte of
the co-simulated module to be assigned values True and 55 respectively.
However, the values that we actually see are different, False and 0. These
are the default values of the signals my_bit and my_byte connected to the
co-simulated module.

The Reason

We are not sure what the reason for this problem is, but what causes the
problem seams to be a Verilog continuous assignments of type:

assign OutPort = CONSTANT

The reason might be a VPI issue?!

A Workaround

We managed to to avoid the problem by slightly modifying the MyHDL module
to:

def const_assign(x, y, aBit, aByte):
    @always_comb
    def logic():
        dummy = 0
        y.next = x + 5
        aBit.next = True
        aByte.next = 55
    return logic

The only difference with the previous version of the module is the addition
of the dummy assignment dummy = 0, which serves no other purpose, but to
alter the generated Verilog:

module const_assign (
    x,
    y,
    aBit,
    aByte
);
input [7:0] x;output [7:0] y;reg [7:0] y;output aBit;reg aBit;output
[7:0] aByte;reg [7:0] aByte;
always @(x) begin: CONST_ASSIGN_LOGIC
    reg dummy;
    dummy = 0;
    y = (x + 5);
    aBit = 1'b1;
    aByte = 55;end
endmodule

By adding the dummy assignment to our @always_comb section we avoid the
Verilog continuous assignments that cause our problem, and instead of them
we get a combinatorial Verilog process, which co-simulates fine.



Regards,

Nikolay

Re: [myhdl-list] Array of constants and code generation

[Thomas H. <th...@ct...>]

Am 02.06.2015 um 12:55 schrieb Josy Boelen:
>
> This converts:
[...]

> By introducing the variable *aa* and coercing *angles* into a tuple we
> get plausible VHDL code.
> I agree that  *indexing an array of constants* would looks nice, and
> probably is what you expected. But I'm almost 100% sure the
> synthesizer/mapper will generate the same element usage for both.

Cool!  Thanks for this trick.

> I had to disable the print statement as that doesn't convert when using
> parenthesis and without it will emit writelines, which is probably not
> intended either.

Sure.

> Regards,
>
> Josy

Thanks again,
Thomas

Re: [myhdl-list] Array of constants and code generation

[Josy B. <jos...@gm...>]

> I'm trying to implement a cordic module to calculate the phase of a
> vector with rectangular coordinates x and y.  The cordic is a full
> parallel pipelined architecture; the vector rotations are generated in 
a 
> loop.  The angles are precalculated as integers in a list.
> The code simulates perfectly; but code generation with toVHDL
> or toVerilog fails with this error:
> 
> ConversionError: in file 
> 
C:\Users\thomas\devel\mytss5\dist\components\_Pythonlib\pmc4\hardware\ip
\cordic.py, 
> line 40:
>      Object type is not supported in this context: angles, <type 
'list'>
> 
> I tried a tuple instead of a list but conversion failed as well.
> 
> How can I rewrite the code for conversion?

This converts:
SCALE = 2000
N = 10

def Cordic(clk,  x, y, phase):

    xi = [Signal(intbv(0, min = - 2**12, max = 2**12)) for _ in 
range(N)]
    yi = [Signal(intbv(0, min = - 2**12, max = 2**12)) for _ in 
range(N)]
    zi = [Signal(intbv(0, min = - 2**11, max = 2**11)) for _ in 
range(N)]

    angles = tuple([int(round(math.atan(2**-i) * SCALE / 2 / math.pi)) 
for i in range(N)])

    @always_seq(clk.posedge, reset = None)
    def doit():
        if x < 0:
            xi[0].next = -x
            yi[0].next = -y
            zi[0].next = SCALE // 4 * 3
        else:
            xi[0].next = x
            yi[0].next = y
            zi[0].next = SCALE // 4

        for i in range(9):
            aa = angles[i]
            if yi[i] < 0:
                xi[i+1].next = xi[i] - (yi[i] >> i)
                yi[i+1].next = yi[i] + (xi[i] >> i)
                zi[i+1].next = zi[i] + aa
            else:
                xi[i+1].next = xi[i] + (yi[i] >> i)
                yi[i+1].next = yi[i] - (xi[i] >> i)
                zi[i+1].next = zi[i] - aa

#         print(xi[N-1], yi[N-1], zi[N-1])
        phase.next = zi[N-1]

    return  doit

By introducing the variable *aa* and coercing *angles* into a tuple we 
get plausible VHDL code.
I agree that  *indexing an array of constants* would looks nice, and 
probably is what you expected. But I'm almost 100% sure the 
synthesizer/mapper will generate the same element usage for both.
I had to disable the print statement as that doesn't convert when using 
parenthesis and without it will emit writelines, which is probably not 
intended either.

Regards,

Josy

[myhdl-list] Array of constants and code generation

[Thomas H. <th...@ct...>]

I'm trying to implement a cordic module to calculate the phase of a
vector with rectangular coordinates x and y.  The cordic is a full
parallel pipelined architecture; the vector rotations are generated in a 
loop.  The angles are precalculated as integers in a list.
The code simulates perfectly; but code generation with toVHDL
or toVerilog fails with this error:

ConversionError: in file 
C:\Users\thomas\devel\mytss5\dist\components\_Pythonlib\pmc4\hardware\ip\cordic.py, 
line 40:
     Object type is not supported in this context: angles, <type 'list'>

I tried a tuple instead of a list but conversion failed as well.

How can I rewrite the code for conversion?

Thanks,
Thomas

<code>
SCALE = 2000
N = 10

def Cordic(clk,
            x, y,
            phase):

     xi = [hdl_util.signed(13) for _ in range(N)]
     yi = [hdl_util.signed(13) for _ in range(N)]
     zi = [hdl_util.signed(12) for _ in range(N)]

     angles = [int(round(math.atan(2**-i) * SCALE / 2 / math.pi))
               for i in range(N)]

     @myhdl.always(clk.posedge)
     def doit():
         if x < 0:
             xi[0].next = -x
             yi[0].next = -y
             zi[0].next = SCALE // 4 * 3
         else:
             xi[0].next = x
             yi[0].next = y
             zi[0].next = SCALE // 4

         for i in range(9):
             if yi[i] < 0:
                 xi[i+1].next = xi[i] - (yi[i] >> i)
                 yi[i+1].next = yi[i] + (xi[i] >> i)
                 zi[i+1].next = zi[i] + angles[i]
             else:
                 xi[i+1].next = xi[i] + (yi[i] >> i)
                 yi[i+1].next = yi[i] - (xi[i] >> i)
                 zi[i+1].next = zi[i] - angles[i]

         print(xi[-1], yi[-1], zi[-1])

         phase.next = zi[-1]

     return myhdl.instances()

</code>

Re: [myhdl-list] Hello World

[Günther S. <gue...@gm...>]

Hi Christopher,
Now i rewrote my code with only the system clock in the
process, and i do not have any timing issues anymore.
Now i can run the 3wire SPI with 1 MHz and get
the correct DEVID of the accelerometer.
i checked in my code:
https://github.com/stangassinger/de0_nano_adxl345
Thanks a lot.

Regards

guenther


Am 26.05.2015 um 16:59 schrieb Christopher Felton:
> On 5/21/2015 5:20 AM, Günther Stangassinger wrote:
>> Hello Christopher,
>> you wrote:
>>
>> "The DEnano has a 50MHz clock, this should be
>> the clock driving all your processes/generators.  Don't
>> use the generated SCLK to clock any internal logic."
>>
>>
>> Can you please tell me the reason for this?
> It is going to be the safest design practice and
> the easiest to guarantee you have met timing.  Even
> with slow clocks it is best to use a single clock
> and a single edge in most cases (there are always
> exceptions).
>
> The Altera Quartus synthesis guide is a reasonable
> reference and will do a better job describing the
> pitfalls than I would in a short response.
>
> See section "Synchronous FPGA Design Practices" on
> page12-2 in the following document and specifically
> "Clocking Schemes" on page 12-7.
> https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/qts/qts_qii51006.pdf
>
> Hope that helps,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] VHDL converted ConcatSignal

[Henry G. <he...@ca...>]

On 27/05/15 14:20, Josy Boelen wrote:
>>> > >3. I don't have the issue when taking a subscript instead of a slice,
>>> > >and neither should you because a single bit from either a signed or an
>>> > >unsigned still is a std_logic.
>> >
>> >Yes, I think I was wrong on this - the problem was a zero length vector,
>> >which Python is quite happy with but Vivado baulks at (I assume because
>> >it's invalid VHDL or something).
> A zero-length vector is invalid VHDL, and perhaps we should have MyHDL
> complain about that too? But how do you fabricate a zero-length vector in
> MyHDL?

Hmmm good question. I suspect this is a non-issue that some other 
problem caused to be shown. I've removed such a case from my test suite 
and caught it earlier, so I'm not concerned with it anymore. I suspect 
if it is a real problem it will be corrected by proper coercion of types.

Cheers,

Henry

Re: [myhdl-list] VHDL converted ConcatSignal

[Josy B. <jos...@gm...>]

> > 3. I don't have the issue when taking a subscript instead of a slice,
> > and neither should you because a single bit from either a signed or an
> > unsigned still is a std_logic.
> 
> Yes, I think I was wrong on this - the problem was a zero length vector, 
> which Python is quite happy with but Vivado baulks at (I assume because 
> it's invalid VHDL or something).

A zero-length vector is invalid VHDL, and perhaps we should have MyHDL 
complain about that too? But how do you fabricate a zero-length vector in 
MyHDL?

Regards,

Josy

Re: [myhdl-list] VHDL converted ConcatSignal

[Henry G. <he...@ca...>]

On 27/05/15 13:57, Josy Boelen wrote:
> 2. Actually the ShadowSignal(h,l) remembers that the source was signed,
> but the ConcatSignal() doesn't take that into account. The fix is quite
> simple. I'm actually working on the new 'std_logic_ports' feature and
> some issues when ShadowSignal is involved. I'll post a PR later tonight.
> I have no idea on solving 1. (yet) but will look into that. I'm going to
> do it in several PR's though (or at least in separate commits)

That sounds great. I look forward to seeing the PR.

Cheers,

Henry

Re: [myhdl-list] VHDL converted ConcatSignal

[Henry G. <he...@ca...>]

On 27/05/15 13:57, Josy Boelen wrote:
> 3. I don't have the issue when taking a subscript instead of a slice,
> and neither should you because a single bit from either a signed or an
> unsigned still is a std_logic.

Yes, I think I was wrong on this - the problem was a zero length vector, 
which Python is quite happy with but Vivado baulks at (I assume because 
it's invalid VHDL or something).

Cheers,

Henry

Re: [myhdl-list] VHDL converted ConcatSignal

[Josy B. <jos...@gm...>]

> I started writing this when I noticed that the new (allowing 
constants) 
> ConcatSignal doesn't produce VHDL that coerces a signed intbv signal 
to 
> unsigned such that (at least in Vivado) an error occurs. In producing 
a 
> minimal non-working example, I've noticed some other peculiarities in 
> conversion.
> 
> I say the new ConcatSignal, but it might still be present in the older 
code.
> 
> The following gist gives an example of code causing a problem, along 
> with generated output and my comments:
> 
> https://gist.github.com/hgomersall/cf8a47e7f6929564addd
> 
> The work around for the above is fairly simple and neat (and arguably 
> better as it makes the signedness explicit) by having an interim 
> unsigned signal. This is shown in the second comment of the above 
gist.
> 
> FYI: I get a similar complaint if concat_sig_in is set to be a single 
bit:
> 
> concat_sig_in = ConcatSignal(sig_in(1), intbv(0)[9:])
> 
> in which case I get an error along the lines of "indexed name is not a 
> std_ulogic".

Hello Henry,

Three issues in one :)
1. ShadowSignals are taken from the 'original' Signal, but the VHDL 
conversion takes the names from the top-level function. I guess that 
almost everybody uses the same names in the definition and in the 
instantiations, so this doesn't show up often? See 2.

2. Actually the ShadowSignal(h,l) remembers that the source was signed, 
but the ConcatSignal() doesn't take that into account. The fix is quite 
simple. I'm actually working on the new 'std_logic_ports' feature and 
some issues when ShadowSignal is involved. I'll post a PR later tonight.
I have no idea on solving 1. (yet) but will look into that. I'm going to 
do it in several PR's though (or at least in separate commits) 

3. I don't have the issue when taking a subscript instead of a slice, 
and neither should you because a single bit from either a signed or an 
unsigned still is a std_logic.

Regards,

Josy