[myhdl-list] Re: ListElementNotUnique error

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

Jens Petter Abrahamsen wrote:
> Hi, I hope someone who knows more MyHDL/Python than myself can have a 
> look  at this:
> 
> I keep getting the following error from toVerilog():
> List contains Signals that are not unique to it
> 
> I have a list of signals. The signals are driven inside a module, 
> called  like this:
> 
>     signal_list = [Signal(intbv(0)[WIDTH:]) for i in range(NUMBER)]
>     insts = [module_name(signal_list[i]) for i in range(NUMBER)]
> 
> I want to compare the outputs from all the instances, to select the  
> highest one. So after the previous code, I add the following:
> 
>    @always(clk.negedge)
>     def select_best():
>         """Compare values and select the best one"""
>         best=0
>         for nr in range(NR_REGS):
>             if signal_list[nr] > signal_list[best]: # I have also tried  
> .val on them
>                 best=nr
> 
>     max.next = best
> 
> This gives me the ListElementNotUnique error from the toVerilog converter.
> 
> Is it not supposed to be possible? How should it be done?

Again, the problems is related to restrictions on how lists of signals
can be mapped to Verilog memories.

First, let me present something similar that does work :-)

     def compare(z, a, b):
         @always_comb
         def logic():
             if a > b:
                 z.next = a
             else:
                 z.next = b
         return logic

     def top(dout, din0, din1, din2, din3, clk):
         din = [din0, din1, din2, din3]
         max = [Signal(intbv(0)[4:]) for i in range(len(din))]
         max[0] = din[0]
         inst = [compare(max[i+1], max[i], din[i+1])
                     for i in range(len(din)-1)]
         dout = max[-1] # last in list

     return inst

Note how I can do all kinds of maniplations with lists. The difference
with your example is that list syntax is not used inside generator code.
All list handling is done before "elaboration", and thus before the
conversion starts. See the manual for more info on elaboration if
required.

The above example can be converted, while yours can't - but neither
could be done straightforwardly (= with similar constructs) in Verilog
directly. So we do gain something.

Verilog memories have all kinds of restrictions. Therefore, they
are in general avoided by the convertor. Instead, when a signal
is both in a list, and has a plain name at some other level in
the hierarchy, that name is used in the output, and no memory
is declared.

At first, I had actually done this differently, giving precence
to memory declarations (as is should be.) However, I had to back
off because of memory restrictions. For more info, see the
posts in this mailing list dated 08/09/2005, with subject:
"Ram inference from toVerilog output". The news url is:

   news://news.gmane.org:119/42F...@ja...

There is one exception: if you declare a list that contains
Signals that are not used in other hierarchical levels, you
can use it in your generator functions. In this way, you
can describe RAM structures. See also:

http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#mapping_a_list_of_signals_to_a_ram_memory

The convertor detects valid usage, and flags an error otherwise.
This is the error you see. I agree it seems mysterious, so
I'll have a thought of a better error name & explanation.

Regards,

Jan

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