myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] multiple instantiations

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

On 13/02/15 16:51, Edward Vidal wrote:
> Henry,
> Do you have and example of your code?

Here's an example:
https://gist.github.com/hgomersall/9b061b2b92ddc0775789

When converting that, one gets two processes for each TrivialTest.

Cheers,

Henry

Re: [myhdl-list] register-file with variable register size

[SHEN C. <she...@co...>]

 

Yes this is exactly what I needed. Thank you very much. 

regards,


shenchen 

On 2015-02-13 23:20, Christopher Felton wrote: 

> On
2/12/2015 1:40 PM, SHEN Chen wrote:
> 
>> The controller ensures that no
conflicting access to the register files would ever occur. I'm trying to
implement this with ConcatSignal and interface (code at the end of the
msg).
> 
> You can review the original MEP, it might give some insight
>
to the uses and limitations:
> http://dev.myhdl.org/meps/mep-105.html
>

>> The code for the controller accessing the 2-byte read-port is quite
clean, but it gets muddy for the 2-byte write-port (regAw).
> 
> Yes,
the read is clean because it can be handled by
> getting references to
the various signals. The write
> is a different case. I think what you
are looking for
> is a method to map a bunch of signal references
(your
> named register) to the appropriate "mem" index.
> 
> I modified
your code, generates a map and then the map
> can assign all the named
registers to the correct spot
> (notice the use of ShadowSignal "()" in
the map).
> 
> The updated code is here:
>
https://gist.github.com/cfelton/316bb5fce038e67dbbad
> 
> Hope that
helps,
> Chris
> 
>
------------------------------------------------------------------------------
>
Dive into the World of Parallel Programming. The Go Parallel Website,
>
sponsored by Intel and developed in partnership with Slashdot Media, is
your
> hub for all things parallel software development, from weekly
thought
> leadership blogs to news, videos, case studies, tutorials and
more. Take a
> look and join the conversation now.
http://goparallel.sourceforge.net/
>
_______________________________________________
> myhdl-list mailing
list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list

 

Re: [myhdl-list] multiple instantiations

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

On 13/02/15 16:51, Edward Vidal wrote:
> Do you have and example of your code?

Not yet! :) (apologies!)

Re: [myhdl-list] multiple instantiations

[Edward V. <dev...@sb...>]

Henry,
Do you have and example of your code?
Regards

 
Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613


On Friday, February 13, 2015 8:31 AM, Henry Gomersall <he...@ca...> wrote:
 


On 13/02/15 16:05, Edward Vidal wrote:

 Henry,
>Your problem sounds like what I am working on.
>
>
<snip>

As I understand it, you're doing it by lumping your parallel logic
    into one block? Or perhaps I've missed something?

The problem with this is it breaks a given serial pipeline. My
    algorithm is embarrassingly parallel, but each parallel stream is
    not particularly simple. In fact, it gets worse because each serial
    pipeline is re-purposed in several different ways at run time -
    essentially I'm wrapping DSP units with lots of data marshalling and
    shuffling. I really want the serial unit to be as sane as possible,
    and I'm happy to accept any kind of VHDL to give me that.


Cheers,

Henry


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] multiple instantiations

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

On 13/02/15 16:05, Edward Vidal wrote:
>  Henry,
> Your problem sounds like what I am working on.
>
<snip>

As I understand it, you're doing it by lumping your parallel logic into 
one block? Or perhaps I've missed something?

The problem with this is it breaks a given serial pipeline. My algorithm 
is embarrassingly parallel, but each parallel stream is not particularly 
simple. In fact, it gets worse because each serial pipeline is 
re-purposed in several different ways at run time - essentially I'm 
wrapping DSP units with lots of data marshalling and shuffling. I really 
want the serial unit to be as sane as possible, and I'm happy to accept 
any kind of VHDL to give me that.

Cheers,

Henry

Re: [myhdl-list] multiple instantiations

[Edward V. <dev...@sb...>]

 Henry,
Your problem sounds like what I am working on.

In file https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/jpeg_constants.py I define 8 variables below depending on the bitwidth
and the number in the array.
W0 = 8
LVL0 = 64
W1 = 8
LVL1 = 64
W2 = 8
LVL2 = 64
W3 = 5
LVL3 = 64
This file generates the Verilog & VHDL https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/array_jpeg.py
8 64 8 64 8 64 5 64 0
left_s_i <class 'myhdl._Signal._Signal'>
sam_s_i <class 'myhdl._Signal._Signal'>
right_s_i <class 'myhdl._Signal._Signal'>
flgs_s_i <class 'myhdl._Signal._Signal'>
8 64 8 64 8 64 5 64 0
left_s_i <class 'myhdl._Signal._Signal'>
sam_s_i <class 'myhdl._Signal._Signal'>
right_s_i <class 'myhdl._Signal._Signal'>
flgs_s_i <class 'myhdl._Signal._Signal'>
My VHDL that is generated has the following entity
entity jp_process is
    port (
        res_out_x: out signed (7 downto 0);
        left_s_i: in unsigned(511 downto 0);
        sam_s_i: in unsigned(511 downto 0);
        right_s_i: in unsigned(511 downto 0);
        flgs_s_i: in unsigned(319 downto 0);
        noupdate_s: out std_logic;
        update_s: in std_logic
    );
end entity jp_process;

JP_PROCESS_JPEG_LOGIC: process (update_s, right_s(0), right_s(1), right_s(2), right_s(3), right_s(4), right_s(5), right_s(6), right_s(7), right_s(8), right_s(9), right_s(10), right_s(11), right_s(12), right_s(13), right_s(14), right_s(15), right_s(16), right_s(17), right_s(18), right_s(19), right_s(20), right_s(21), right_s(22), right_s(23), right_s(24), right_s(25), right_s(26), right_s(27), right_s(28), right_s(29), right_s(30), right_s(31), right_s(32), right_s(33), right_s(34), right_s(35), right_s(36), right_s(37), right_s(38), right_s(39), right_s(40), right_s(41), right_s(42), right_s(43), right_s(44), right_s(45), right_s(46), right_s(47), right_s(48), right_s(49), right_s(50), right_s(51), right_s(52), right_s(53), right_s(54), right_s(55), right_s(56), right_s(57), right_s(58), right_s(59), right_s(60), right_s(61), right_s(62), right_s(63), flgs_s(0), flgs_s(1), flgs_s(2), flgs_s(3), flgs_s(4), flgs_s(5), flgs_s(6), flgs_s(7), flgs_s(8),
 flgs_s(9), flgs_s(10), flgs_s(11), flgs_s(12), flgs_s(13), flgs_s(14), flgs_s(15), flgs_s(16), flgs_s(17), flgs_s(18), flgs_s(19), flgs_s(20), flgs_s(21), flgs_s(22), flgs_s(23), flgs_s(24), flgs_s(25), flgs_s(26), flgs_s(27), flgs_s(28), flgs_s(29), flgs_s(30), flgs_s(31), flgs_s(32), flgs_s(33), flgs_s(34), flgs_s(35), flgs_s(36), flgs_s(37), flgs_s(38), flgs_s(39), flgs_s(40), flgs_s(41), flgs_s(42), flgs_s(43), flgs_s(44), flgs_s(45), flgs_s(46), flgs_s(47), flgs_s(48), flgs_s(49), flgs_s(50), flgs_s(51), flgs_s(52), flgs_s(53), flgs_s(54), flgs_s(55), flgs_s(56), flgs_s(57), flgs_s(58), flgs_s(59), flgs_s(60), flgs_s(61), flgs_s(62), flgs_s(63), sam_s(0), sam_s(1), sam_s(2), sam_s(3), sam_s(4), sam_s(5), sam_s(6), sam_s(7), sam_s(8), sam_s(9), sam_s(10), sam_s(11), sam_s(12), sam_s(13), sam_s(14), sam_s(15), sam_s(16), sam_s(17), sam_s(18), sam_s(19), sam_s(20), sam_s(21), sam_s(22), sam_s(23), sam_s(24), sam_s(25), sam_s(26), sam_s(27), sam_s(28),
 sam_s(29), sam_s(30), sam_s(31), sam_s(32), sam_s(33), sam_s(34), sam_s(35), sam_s(36), sam_s(37), sam_s(38), sam_s(39), sam_s(40), sam_s(41), sam_s(42), sam_s(43), sam_s(44), sam_s(45), sam_s(46), sam_s(47), sam_s(48), sam_s(49), sam_s(50), sam_s(51), sam_s(52), sam_s(53), sam_s(54), sam_s(55), sam_s(56), sam_s(57), sam_s(58), sam_s(59), sam_s(60), sam_s(61), sam_s(62), sam_s(63), left_s(0), left_s(1), left_s(2), left_s(3), left_s(4), left_s(5), left_s(6), left_s(7), left_s(8), left_s(9), left_s(10), left_s(11), left_s(12), left_s(13), left_s(14), left_s(15), left_s(16), left_s(17), left_s(18), left_s(19), left_s(20), left_s(21), left_s(22), left_s(23), left_s(24), left_s(25), left_s(26), left_s(27), left_s(28), left_s(29), left_s(30), left_s(31), left_s(32), left_s(33), left_s(34), left_s(35), left_s(36), left_s(37), left_s(38), left_s(39), left_s(40), left_s(41), left_s(42), left_s(43), left_s(44), left_s(45), left_s(46), left_s(47), left_s(48),
 left_s(49), left_s(50), left_s(51), left_s(52), left_s(53), left_s(54), left_s(55), left_s(56), left_s(57), left_s(58), left_s(59), left_s(60), left_s(61), left_s(62), left_s(63)) is
begin
    if bool(update_s) then
        noupdate_s <= '0';
        for i in 0 to LVL0-1 loop
            if (flgs_s(i) = 7) then
                res_out_x <= signed(sam_s(i) - (shift_right(left_s(i), 1) + shift_right(right_s(i), 1)));
            elsif (flgs_s(i) = 5) then
                res_out_x <= signed(sam_s(i) + (shift_right(left_s(i), 1) + shift_right(right_s(i), 1)));
            elsif (flgs_s(i) = 6) then
                res_out_x <= signed(sam_s(i) + shift_right((left_s(i) + (right_s(i) + 2)), 2));
            elsif (flgs_s(i) = 4) then
                res_out_x <= signed(sam_s(i) - shift_right((left_s(i) + (right_s(i) + 2)), 2));
            end if;
        end loop;
    else
        noupdate_s <= '1';
    end if;
end process JP_PROCESS_JPEG_LOGIC;

I would like arrays that are larger but now the entity signals become quite large.

8 256 8 256 8 256 5 256 0
left_s_i <class 'myhdl._Signal._Signal'>
sam_s_i <class 'myhdl._Signal._Signal'>
right_s_i <class 'myhdl._Signal._Signal'>
flgs_s_i <class 'myhdl._Signal._Signal'>
8 256 8 256 8 256 5 256 0
left_s_i <class 'myhdl._Signal._Signal'>
sam_s_i <class 'myhdl._Signal._Signal'>
right_s_i <class 'myhdl._Signal._Signal'>
flgs_s_i <class 'myhdl._Signal._Signal'>
entity jp_process is
    port (
        res_out_x: out signed (7 downto 0);
        left_s_i: in unsigned(2047 downto 0);
        sam_s_i: in unsigned(2047 downto 0);
        right_s_i: in unsigned(2047 downto 0);
        flgs_s_i: in unsigned(1279 downto 0);
        noupdate_s: out std_logic;
        update_s: in std_logic
    );
end entity jp_process;
Also working on a test bench
https://github.com/develone/jpeg-2000-test/blob/master/jpeg2k/parallel_jpeg/test_bench_array_jpeg.py
I have been told it might be difficult to work with signals that big.
Let me know if this works for you.


 Regards,


Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613


On Friday, February 13, 2015 5:53 AM, Henry Gomersall <he...@ca...> wrote:
 


I think I know the answer to this, but wanted to check.

I'm creating lots of instances of the same component (with different 
signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl 
file if every one has it's own process block.

I understand I could make this neater in raw VHDL (which I can do 
through MyHDL easily enough) with the generate keyword.

Is there a way to do a tight conversion for multiple equivalent 
instances? Is this one of the targets of MEP 110 
(http://dev.myhdl.org/meps/mep-110.html)?

Cheers,

Henry

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] register-file with variable register size

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

On 2/12/2015 1:40 PM, SHEN Chen wrote:
<snip>
>
> The controller ensures that no
> conflicting access to the register files would ever occur.
>
> I'm trying
> to implement this with ConcatSignal and interface (code at the end of
> the msg).
>

You can review the original MEP, it might give some insight
to the uses and limitations:
http://dev.myhdl.org/meps/mep-105.html

> The code for the controller accessing the 2-byte read-port
> is quite clean, but it gets muddy for the 2-byte write-port (regAw).
>

Yes, the read is clean because it can be handled by
getting references to the various signals.  The write
is a different case.  I think what you are looking for
is a method to map a bunch of signal references (your
named register) to the appropriate "mem" index.

I modified your code, generates a map and then the map
can assign all the named registers to the correct spot
(notice the use of ShadowSignal "()" in the map).

The updated code is here:
https://gist.github.com/cfelton/316bb5fce038e67dbbad


Hope that helps,
Chris

Re: [myhdl-list] register-file with variable register size

[SHEN C. <she...@co...>]

 

Hi Chris, 

In fact, I've read some of minnesota's source code
yesterday, and find it very inspiring. 

What I was trying to do is
somewhat similar, but if I understand the code correctly, you can not
write to the read-only register as a whole. 

For example, in
test_regfile.py we defined "status" as an 'ro' register, and declared a
few named bits. We can write to the individual bits, but not the
"status" register as a whole. 

In particular, we can not write the
"status" register through its address either, which I need in my
application. 

regards,
ShenChen 

On 2015-02-13 21:00, Christopher
Felton wrote: 

> I haven't completely gone through your example yet,
>
but I had a go at a register file abstraction awhile
> ago as well:
> 
>
https://github.com/cfelton/minnesota/blob/master/mn/system/regfile/_regfile.py
>

>
https://github.com/cfelton/minnesota/blob/master/test/test_system/test_regfile.py

> 
>
https://github.com/cfelton/minnesota/blob/master/mn/cores/spi/_regfile_def.pyMy
idea was that I could define a register definition
> for a *core* using
an object/dict and that would be it.
> 
> Maybe my **incomplete**
example will be helpful, maybe
> not.
> 
> Regards,
> Chris
> 
> On
2/12/15 10:42 PM, SHEN Chen wrote:
> 
>> I uploaded it to Gist/Github:
https://gist.github.com/hashhsah/f04de49838c1d4b0715c [4]regards,
shenchen On 2015-02-13 04:35, Christopher Felton wrote: 
>> 
>>>> I'm
trying to implement this with ConcatSignal and interface (code at the
end of the msg).
>>> Do you have a link to the code, the formatting
appears mangled (HTML email clients often remove whitespace). Regards,
Chris
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is
your hub for all things parallel software development, from weekly
thought leadership blogs to news, videos, case studies, tutorials and
more. Take a look and join the conversation
now.http://goparallel.sourceforge.net/ [1]
_______________________________________________ myhdl-list mailing list
myh...@li... [2] myh...@li...>
https://lists.sourceforge.net/lists/listinfo/myhdl-list [3]
>> -- SHEN
Chen General Manager --------------------------------- Cogenda Co Ltd
SISPARK II Room C102-1, 1355 Jinjihu Avenue, Suzhou, Jiangsu, China
Phone(Fax): +86 512 67900636 Homepage: http://www.cogenda.com [5]
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is
your hub for all things parallel software development, from weekly
thought leadership blogs to news, videos, case studies, tutorials and
more. Take a look and join the conversation now.
http://goparallel.sourceforge.net/ [6]
_______________________________________________ myhdl-list mailing list
myh...@li... [7]
https://lists.sourceforge.net/lists/listinfo/myhdl-list [8]
> 
>
------------------------------------------------------------------------------
>
Dive into the World of Parallel Programming. The Go Parallel Website,
>
sponsored by Intel and developed in partnership with Slashdot Media, is
your
> hub for all things parallel software development, from weekly
thought
> leadership blogs to news, videos, case studies, tutorials and
more. Take a
> look and join the conversation now.
http://goparallel.sourceforge.net/
>
_______________________________________________
> myhdl-list mailing
list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list

-- 




Links:
------
[1] http://goparallel.sourceforge.net/
[2]
mailto:myh...@li...
[3]
https://lists.sourceforge.net/lists/listinfo/myhdl-list
[4]
https://gist.github.com/hashhsah/f04de49838c1d4b0715c
[5]
http://www.cogenda.com
[6] http://goparallel.sourceforge.net/
[7]
mailto:myh...@li...
[8]
https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] multiple instantiations

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

I think I know the answer to this, but wanted to check.

I'm creating lots of instances of the same component (with different 
signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl 
file if every one has it's own process block.

I understand I could make this neater in raw VHDL (which I can do 
through MyHDL easily enough) with the generate keyword.

Is there a way to do a tight conversion for multiple equivalent 
instances? Is this one of the targets of MEP 110 
(http://dev.myhdl.org/meps/mep-110.html)?

Cheers,

Henry

Re: [myhdl-list] register-file with variable register size

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

I haven't completely gone through your example yet,
but I had a go at a register file abstraction awhile
ago as well:

https://github.com/cfelton/minnesota/blob/master/mn/system/regfile/_regfile.py

https://github.com/cfelton/minnesota/blob/master/test/test_system/test_regfile.py 


https://github.com/cfelton/minnesota/blob/master/mn/cores/spi/_regfile_def.py


My idea was that I could define a register definition
for a *core* using an object/dict and that would be it.

Maybe my **incomplete** example will be helpful, maybe
not.

Regards,
Chris

On 2/12/15 10:42 PM, SHEN Chen wrote:
> I uploaded it to Gist/Github:
> https://gist.github.com/hashhsah/f04de49838c1d4b0715c
>
> regards,
> shenchen
>
> On 2015-02-13 04:35, Christopher Felton wrote:
>
>>> I'm trying to implement this with ConcatSignal and interface (code at
>>> the end of the msg).
>> Do you have a link to the code, the formatting appears
>> mangled (HTML email clients often remove whitespace).
>>
>> Regards,
>> Chris
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now.http://goparallel.sourceforge.net/
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...  <mailto:myh...@li...>
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
> --
>
> SHEN Chen         General Manager
> ---------------------------------
> Cogenda Co Ltd
> SISPARK II Room C102-1, 1355 Jinjihu Avenue, Suzhou, Jiangsu, China
> Phone(Fax):  +86 512 67900636
> Homepage:  http://www.cogenda.com
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] register-file with variable register size

[SHEN C. <she...@co...>]

 

I uploaded it to Gist/Github:
https://gist.github.com/hashhsah/f04de49838c1d4b0715c


regards,
shenchen 

On 2015-02-13 04:35, Christopher Felton wrote:


>> I'm trying to implement this with ConcatSignal and interface (code
at the end of the msg).
> 
> Do you have a link to the code, the
formatting appears
> mangled (HTML email clients often remove
whitespace).
> 
> Regards,
> Chris
> 
>
------------------------------------------------------------------------------
>
Dive into the World of Parallel Programming. The Go Parallel Website,
>
sponsored by Intel and developed in partnership with Slashdot Media, is
your
> hub for all things parallel software development, from weekly
thought
> leadership blogs to news, videos, case studies, tutorials and
more. Take a
> look and join the conversation now.
http://goparallel.sourceforge.net/
>
_______________________________________________
> myhdl-list mailing
list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list

-- 

SHEN Chen
General Manager
---------------------------------
Cogenda Co Ltd
SISPARK
II Room C102-1, 1355 Jinjihu Avenue, Suzhou, Jiangsu, China
Phone(Fax):
+86 512 67900636
Homepage: http://www.cogenda.com
 

Re: [myhdl-list] register-file with variable register size

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

<snip>
>
> I'm trying
> to implement this with ConcatSignal and interface (code at the end of
> the msg).
>

Do you have a link to the code, the formatting appears
mangled (HTML email clients often remove whitespace).

Regards,
Chris

[myhdl-list] register-file with variable register size

[SHEN C. <she...@co...>]

 

Hi all, 

Suppose I have a register file organized in bytes, but
some of the registers actually span over multiple bytes. 

Depending on
the mode of operation, we will either access the named registers, or
access like a memory with address. 

The controller ensures that no
conflicting access to the register files would ever occur. 

I'm trying
to implement this with ConcatSignal and interface (code at the end of
the msg). 

The code for the controller accessing the 2-byte read-port
is quite clean, but it gets muddy for the 2-byte write-port (regAw).


Since ShadowSignal is read-only, I have to use two assignments, one
for each byte. 

Moreover, since method call is not convertible, I can
not call RegFile.writeA() in controller's write() process. 

Instead,
the two assignments must appear in the write() process. 

This, IMHO,
breaks the encapsulation of the RegFile class: only RegFile class should
know about the mapping between register name and their addresses. 

I
hope that either ShadowSignal could support write as well as read, or
method-calling became convertible. 

I wonder if these two features are
feasible and if there are better solutions? Thank you!


regards,
Shenchen 

#!/bin/env python

from myhdl import *

class
RegFile(object):
 def __init__(self):
 # actual memory storage

self._mem = [Signal(intbv(0)[8:]) for i in xrange(20)]

 # named
registers port for reading
 self.regA = ConcatSignal(*[self._mem[0+i]
for i in 0,1])
 self.regB = ConcatSignal(*[self._mem[2+i] for i in
0,1])

 # named registers port for writing
 self.regAw =
Signal(intbv(0)[16:])

 def writeA(self):
 self._mem[0+0].next =
self.regAw[16:8]
 self._mem[0+1].next = self.regAw[8:0]

def
controller(clk, rst, X, Z):
 reg = RegFile()

 @always_seq(clk.posedge,
reset=rst)
 def write():
 reg._mem[0+0].next = reg.regAw[16:8]

reg._mem[0+1].next = reg.regAw[8:0]

 #reg.writeA()

 @always_comb
 def
io():
 reg.regAw.next = X
 Z.next = reg.regA + reg.regB

 return
instances()

def test():
 clk = Signal(False)
 rst = ResetSignal(1,
active=0, async=True)
 x = Signal(intbv(0)[16:])
 y =
Signal(intbv(0)[16:])

 toVerilog.timescale = '1ns/1ps'

toVerilog(controller, clk, rst, x, y)

test()

-- 

SHEN Chen General
Manager
---------------------------------
Cogenda Co Ltd
SISPARK II Room
C102-1, 1355 Jinjihu Avenue, Suzhou, Jiangsu, China
Phone(Fax): +86 512
67900636
Homepage: http://www.cogenda.com
 

[myhdl-list] traceSignals and interfaces in 0.9-dev

[SHEN C. <she...@co...>]

 

Hi all, 

I started using the "interface" feature in 0.9-dev, and
really liked it. 

However, there are some quirks when I tried dumping
vcd using traceSignals(). 

Consider the three logically identical
versions of an adder listed at the end. The saved vcd contains different
set of variables: 

version 1: 

testbench
| - clk
| - xyz.x, 
| -
xyz.y,
| - xyz.z,
+- adder/
 | - clk
 | - xyz.x 
 | - xyz.y
 | - xyz.z


version 2: 

testbench
| - clk
| - xyz.x, 
| - xyz.y,
| - xyz.z,
+-
adder/
 | - clk 

version 3: 

testbench
| - clk
+- adder/
 | - clk


The simulation results of the three versions are all correct, only
that some variables in the interface are not saved in version 2 and 3.


Unfortunately, I personally prefer to write code in the style of
version 3, and really hope it to work. 

I am looking at the source code
of traceSignals() but haven't figured out what's gone wrong yet. Any
help will be appreciated. Thanks! 

regards,
shenchen 

====== version 1
====== 

from myhdl import *

class Adder(object):
 def __init__(self):

self.x = Signal(intbv(0)[8:])
 self.y = Signal(intbv(0)[4:])
 self.z =
Signal(intbv(0)[9:])

def AdderRTL(xyz, clk):
 @always(clk.posedge)
 def
hdl():
 xyz.z.next = xyz.x + xyz.y
 return hdl

def testbench():
 clk =
Signal(False)
 xyz = Adder()

 adder = AdderRTL(xyz,clk)


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

 @instance
 def
stimulus():
 yield clk.negedge
 xyz.x.next = 2
 xyz.y.next = 3
 yield
clk.posedge
 raise StopSimulation

 return clkgen, stimulus, adder

tb =
traceSignals(testbench)
sim =
Simulation(tb)
sim.run()

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

====== version 2 ======


from myhdl import *

class Adder(object):
 def __init__(self):
 self.x
= Signal(intbv(0)[8:])
 self.y = Signal(intbv(0)[4:])
 self.z =
Signal(intbv(0)[9:])

 def rtl(xyz, clk):
 @always(clk.posedge)
 def
hdl():
 xyz.z.next = xyz.x + xyz.y
 return hdl

def testbench():
 clk =
Signal(False)
 xyz = Adder()

 adder = xyz.rtl(clk)


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

 @instance
 def
stimulus():
 yield clk.negedge
 xyz.x.next = 2
 xyz.y.next = 3
 yield
clk.posedge
 raise StopSimulation

 return clkgen, stimulus, adder

tb =
traceSignals(testbench)
sim =
Simulation(tb)
sim.run()

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

====== version 3 ======


from myhdl import *

class Adder(object):
 def __init__(self):
 self.x
= Signal(intbv(0)[8:])
 self.y = Signal(intbv(0)[4:])
 self.z =
Signal(intbv(0)[9:])

 def rtl(xyz, clk):
 @always(clk.posedge)
 def
hdl():
 xyz.z.next = xyz.x + xyz.y
 return hdl

def testcase1():
 def
testbench():
 clk = Signal(False)
 xyz = Adder()

 adder =
xyz.rtl(clk)

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


@instance
 def stimulus():
 yield clk.negedge
 xyz.x.next = 2

xyz.y.next = 3
 yield clk.posedge
 raise StopSimulation

 return clkgen,
stimulus, adder

 tb = traceSignals(testbench)
 sim = Simulation(tb)

sim.run()

testcase1()

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

Re: [myhdl-list] myhdl.AlwaysCombError: signal (startmpy) used as inout in always_comb function argument

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

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


> >>
> >> Why have a single comb vs. two comb?
> >
> > Because they target the same outputs. I'll augment the simplified
> > example a bit:
> 
> This modified code isn't a good example because the
> second state-machine always overwrites the first, so
> you can eliminate the first state-machines assignments
> to /Status/.

Yes, that's what happens with untested small example code. But you could 
assume that the **Status** was for monitoring (using SignalTap or some 
other method), it would me make wonder what happened '2' and '3' 

> 
> You would need states in each state-machine that doesn't
> assign and doesn't overlap - but ugh how do you keep
> track of that as the complexity grows?
> 
In this particular case, see https://github.com/josyb/KalmanFilter,  I 
could have added a third state machine which together would use the 
shared resource on an exclusive basis and the first state machine would 
only deal the cards. 

If the complexity would grow above this, I'd consider building a 
microprogrammed machine ;)

Best regards,

Josy

Re: [myhdl-list] myhdl.AlwaysCombError: signal (startmpy) used as inout in always_comb function argument

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

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

> 
> <snip>
> >> I believe the inout comb detection is a mechanism to
> >> protect against unwanted comb feedback.  If you have
> >> a complicated  <at> always_comb it probably make sense to
> >> split it out rather than remove the comb feedback
> >> detection.
> >
> > What is **unwanted comb feedback**?
> 
> Combinational loops [1][2] as a result of a complicated
> expression.
> 
> > Is this in the Verilog LRM? Or is
> > the comb feedback in the code to protect us from ourselves? If it is 
not
> > against Verilog, the **comb feedback detection** should, IMHO, be
> > reworked. If Verilog has a problem with this ... you tell me.
> 
> It is not a Verilog thing and I am not 100% sure if the
> original design intent was to protect us from ourselves
> but that is my guess.  How / why should it be reworked?
> 
> >
> > Splitting my actual code in two processes would add clumsy 
workarounds,
> > making the code not any prettier.
> >
> 
> I'm not so sure about the dual-state machine driving
> same outputs.  It's interesting, it would be the
> equivalent of a single state-machine with two state
> registers, which is just another way of logically
> organizing a more complex set of states ... hmmmm
> 
> Regards,
> Chris
> 
> [1] 
> 
http://quartushelp.altera.com/13.1/mergedProjects/verify/da/comp_file_ru
les_loop.htm
> 
> [2] http://fpga-hdl.blogspot.com/2012/07/test.html

Chris,

you are a great source of knowledge (read this as praise)
[1] : Quartus will tell me when I'm (that) stupid. I have seen this 
warning once, when I made a **ring oscillator** to generate random 
numbers (based on one of their app-notes)
I posted the code for your perusal-> 
https://github.com/josyb/KalmanFilter
I've written it this way, as this is what I would have written in VHDL. 
One other example where I used this was for a DDR2 SDRAM controller 
where one state-machine handles the initialisation and the second 
handles the actual read/write/refresh operation. Of course this could be 
done in a single state machine, but this approach of divide and conquer 
generates smaller and faster code (which I can't prove right-away ...)

I think that the rework is actually removing the **check** as I showed. 
At least that is what I did locally. I'l see tomorrow how the VHDL 
synthesizes when plugged into the **real** project.

Regards,

Josy

Re: [myhdl-list] myhdl.AlwaysCombError: signal (startmpy) used as inout in always_comb function argument

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

On 2/11/2015 1:44 PM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> Why have a single comb vs. two comb?
>
> Because they target the same outputs. I'll augment the simplified
> example a bit:

This modified code isn't a good example because the
second state-machine always overwrites the first, so
you can eliminate the first state-machines assignments
to /Status/.

You would need states in each state-machine that doesn't
assign and doesn't overlap - but ugh how do you keep
track of that as the complexity grows?

Regards,
Chris

Re: [myhdl-list] myhdl.AlwaysCombError: signal (startmpy) used as inout in always_comb function argument

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

<snip>
>> I believe the inout comb detection is a mechanism to
>> protect against unwanted comb feedback.  If you have
>> a complicated  <at> always_comb it probably make sense to
>> split it out rather than remove the comb feedback
>> detection.
>
> What is **unwanted comb feedback**?

Combinational loops [1][2] as a result of a complicated
expression.

> Is this in the Verilog LRM? Or is
> the comb feedback in the code to protect us from ourselves? If it is not
> against Verilog, the **comb feedback detection** should, IMHO, be
> reworked. If Verilog has a problem with this ... you tell me.

It is not a Verilog thing and I am not 100% sure if the
original design intent was to protect us from ourselves
but that is my guess.  How / why should it be reworked?

>
> Splitting my actual code in two processes would add clumsy workarounds,
> making the code not any prettier.
>

I'm not so sure about the dual-state machine driving
same outputs.  It's interesting, it would be the
equivalent of a single state-machine with two state
registers, which is just another way of logically
organizing a more complex set of states ... hmmmm

Regards,
Chris

[1] 
http://quartushelp.altera.com/13.1/mergedProjects/verify/da/comp_file_rules_loop.htm

[2] http://fpga-hdl.blogspot.com/2012/07/test.html

Re: [myhdl-list] enums and non-local

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

On 2/11/2015 1:57 PM, Jose M. Gomez Cama wrote:
> Ups, you are right...
>
> 	Sorry
>

No problem!  Glad we could help.

Chris

Re: [myhdl-list] enums and non-local

[Jose M. G. C. <ch...@gm...>]

Ups, you are right...

	Sorry

> El 11/2/2015, a las 17:35, Christopher Felton <chr...@gm...> escribió:
> 
> <snip>
>> 
>> You're trying to assign state here:
>> 
>>          elif state == t_state.CALC:
>>              a.next = b
>>              state = t_state.WAIT
>> 
>> Perhaps you want `state.next = t_state.WAIT`?
>> 
> 
> Yup, what Henry said.
> 
> Regards,
> Chris
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] myhdl.AlwaysCombError: signal (startmpy) used as inout in always_comb function argument

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

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

> 
> Why have a single comb vs. two comb?

Because they target the same outputs. I'll augment the simplified 
example a bit:

def contrivedtwostatemachineexample( Clk, Reset,  StartP, Status, ... )
    states_first = enum( "IDLE" , "ONE" , "TWO")
    smfp, smfn = [Signal( states_first.IDLE ) for _ in range( 2 )]
    states_second = enum( "IDLE" , "BUSY")
    smfp, smfn = [Signal( states_second .IDLE ) for _ in range( 2 )]
    startsecond, donesecond = [Signal(bool(0)) _ for _ in range(2)}

     <at> always_comb
    def smcomb():
        startsecond.next = 0
        donesecond.next = 0
        Status.next = 0

        if smfp == states_first.IDLE:
           Status.next = 1
           if StartP:
               smfn.next = states_first.ONE
               startsecond.next = 1
           else:
               smfn.next = states_first.IDLE

        elif smfp == states_first.ONE:
           Status.next = 2
           if donesecond:
               smfn.next = states_first.TWO
               startsecond.next = 1
           else:
              smfn.next = states_first.ONE

        elif smfp == states_first.TWO:
           Status.next = 3
           if donesecond:
               smfn.next = states_first.IDLE
           else:
              smfn.next = states_first.TWO

       if smsp == states_second.IDLE:
           Status.next = 10
           if startsecond:
               smsn.next = states_second.BUSY
           else:
               smsn.next = states_second.IDLE

       elif smsp == states_second.BUSY:
           Status.next = 11
           donesecond.next = 1
           # must catch an immediate start command
           if startsecond:
               smsn.next = states_second.BUSY
           else:
               smsn.next = states_second.IDLE

     <at> always_seq(Clk.posedge, reset=Reset)
    def smprocess():
        smfp.next = smfn
        smsp.next = smsn

   return smcomb, smprocess

If we split it over two processes, VHDL will complain about multiple 
drivers ...

> 
>      def smcombfp():
>      ...
> 
>      def smcombsn():
>      ...
> 
> I believe the inout comb detection is a mechanism to
> protect against unwanted comb feedback.  If you have
> a complicated  <at> always_comb it probably make sense to
> split it out rather than remove the comb feedback
> detection.

What is **unwanted comb feedback**? Is this in the Verilog LRM? Or is 
the comb feedback in the code to protect us from ourselves? If it is not 
against Verilog, the **comb feedback detection** should, IMHO, be 
reworked. If Verilog has a problem with this ... you tell me.

Splitting my actual code in two processes would add clumsy workarounds, 
making the code not any prettier.

Regards,

Josy

Re: [myhdl-list] myhdl.AlwaysCombError: signal (startmpy) used as inout in always_comb function argument

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

On 2/11/2015 10:54 AM, Josy Boelen wrote:
<snip>
>> Do you have some example code?
>>
>> <snip>
> Henry,
>
> the code is a handful (as usual) but I made a simplified example (as
> Chris also likes to see ...):

:)

>
> def contrivedtwostatemachineexample( Clk, Reset,  StartP, ... )
<snip>
>
>      @always_comb
>      def smcomb():


Why have a single comb vs. two comb?

     def smcombfp():
     ...

     def smcombsn():
     ...

I believe the inout comb detection is a mechanism to
protect against unwanted comb feedback.  If you have
a complicated @always_comb it probably make sense to
split it out rather than remove the comb feedback
detection.

Regards,
Chris

Re: [myhdl-list] myhdl.AlwaysCombError: signal (startmpy) used as inout in always_comb function argument

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

Henry Gomersall <heng <at> cantab.net> writes:

> 
> On 11/02/15 15:41, Josy Boelen wrote:
> > In a module I have two state machines: one doing overall control and 
the
> > second doing a serial multiply. I (almost always) write two-process
> > state machine. As a result I have one  <at> always_comb where the 
the first
> > state machine issues a startpulse to the second and then waits for a
> > donepulse from the second to continue. Both state machine have some
> > (combinatorial or asynchronous) output signals in common so they 
have to
> > reside in the same (VHDL) process.
> <snip>
> 
> Do you have some example code?
> 
><snip>
Henry,

the code is a handful (as usual) but I made a simplified example (as 
Chris also likes to see ...):

def contrivedtwostatemachineexample( Clk, Reset,  StartP, ... )
    states_first = enum( "IDLE" , "ONE" , "TWO")
    smfp, smfn = [Signal( states_first.IDLE ) for _ in range( 2 )]
    states_second = enum( "IDLE" , "BUSY")
    smfp, smfn = [Signal( states_second .IDLE ) for _ in range( 2 )]
    startsecond, donesecond = [Signal(bool(0)) _ for _ in range(2)}
 

    @always_comb
    def smcomb():
        startsecond.next = 0
        donesecond.next = 0

        if smfp == states_first.IDLE:
            if StartP:
                smfn.next = states_first.ONE
                startsecond.next = 1
            else:
                smfn.next = states_first.IDLE

        elif smfp == states_first.ONE:
            if donesecond:
                smfn.next = states_first.TWO
                startsecond.next = 1
            else:
               smfn.next = states_first.ONE

        elif smfp == states_first.TWO:
            if donesecond:
                smfn.next = states_first.IDLE
            else:
               smfn.next = states_first.TWO


       if smsp == states_second.IDLE:
           if startsecond:
               smsn.next = states_second.BUSY
           else:
               smsn.next = states_second.IDLE
  
       elif smsp == states_second.BUSY:
           donesecond.next = 1
           # must catch an immediate start command
           if startsecond:
               smsn.next = states_second.BUSY
           else:
               smsn.next = states_second.IDLE
 
    @always_seq(Clk.posedge, reset=Reset)
    def smprocess():
        smfp.next = smfn
        smsp.next = smsn
     
   return smcomb, smprocess


You see that both **startsecond** and **donesecond** are written and 
read in the combinatorial process. MyHDL chokes on that, spitting out 
the AlwaysCombError message. But as the two signals in question are not 
**Ports** there is no real reason to do so, unless Verilog has a problem 
with it. Which is my original question: is this a problem in Verilog?

Regards,

Josy

Re: [myhdl-list] enums and non-local

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

<snip>
>
> You're trying to assign state here:
>
>           elif state == t_state.CALC:
>               a.next = b
>               state = t_state.WAIT
>
> Perhaps you want `state.next = t_state.WAIT`?
>

Yup, what Henry said.

Regards,
Chris

Re: [myhdl-list] enums and non-local

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

On 11/02/15 15:47, Jose M. Gomez Cama wrote:
> This is a piece of code that does not work. I think it is more or less equivalent to yours.
>
>
> from myhdl import *
>
> def test(clk, reset, a, b):
>      t_state = enum("WAIT", "CALC")
>      state = Signal(t_state.WAIT)
>      @always_seq(clk.posedge, reset)
>      def fsm():
>          if state == t_state.WAIT:
>              b.next = 0
>              state.next = t_state.CALC
>          elif state == t_state.CALC:
>              a.next = b
>              state = t_state.WAIT
>      return fsm
>
> clk = Signal(intbv(0)[1:])
> reset = ResetSignal(1, active=1, async=False)
> a = Signal(intbv(0)[1:])
> b = Signal(intbv(0)[1:])
>
> toVHDL(test, clk, reset, a, b)
>
> The error is:
>
> Local variable may be referenced before assignment: state

You're trying to assign state here:

         elif state == t_state.CALC:
             a.next = b
             state = t_state.WAIT

Perhaps you want `state.next = t_state.WAIT`?

Henry