[libre-riscv-dev] Fwd: Connecting records to records?

[Samuel Falvo II]

That seems to be working for now!  Thanks!!

(Of course, the one place I *didn't* check was the library source itself...)

On Sun, Jul 14, 2019 at 6:06 PM Jacob Lifshay <programmerjake at gmail.com>
wrote:

> try Record.connect?
>
>
> https://github.com/m-labs/nmigen/blob/ff343d5cf0c57d1e21552e1033c0ae4bb13d78ae/nmigen/hdl/rec.py#L179
>
> On Sun, Jul 14, 2019, 18:03 Samuel Falvo II <sam.falvo at gmail.com> wrote:
>
> > I'm widening the audience to this question in the hopes that someone has
> > some insight on this issue.  Originally sent to just Luke, but this seems
> > like a question which is of more general interest.
> >
> > For my KCP53010 design, I'm looking to wrap a memory interface into a
> > record so I can easily connect one record to another.  nmigen apparently
> > doesn't know how to do this, however.  When I run a simulation, I see
> > messages like this:
> >
> > (env3) [kc5tja at gienah cpu]$ python -m unittest -v test_add_store_cu
> > test_add_store_cu_formally (test_add_store_cu.AddStoreCUTestCase) ...
> >
> >
> /home/kc5tja/projects/kestrel-3/trunk/cores/env3/lib/python3.6/site-packages/nmigen-0.1-py3.6.egg/nmigen/hdl/rec.py:84:
> > DriverConflict: Signal '(sig opcode)' is driven from multiple fragments:
> > top, top.dut; hierarchy will be flattened
> >   self.fields[field_name] = Signal(field_shape, name=concat(name,
> > field_name))
> >
> > This appears to be treated as a warning, rather than an error; still, it
> > didn't happen before, and would like to correct the code so that this
> > message isn't displayed anymore.
> >
> > Consider this contrived, simplified pseudo-code which I hypothesize is
> > causing the problem:
> >
> > m_layout = [('a', 1, DIR_FANIN), ('b', 1, DIR_FANOUT)]
> > s_layout = [('a', 1, DIR_FANOUT), ('b', 1, DIR_FANIN)]
> >
> > class Interface(Record):
> >   def __init__(self, layout):
> >     super().__init__(layout)
> >
> > x = Interface(m_layout) # master
> > y = Interface(s_layout) # slave
> >
> > comb += x.eq(y)  # <-- appears to result in multiple drivers for the same
> > signals when elaborated.
> >
> > In your experience, what is the proper approach to solving this problem?
> > So far, I've found no evidence that this is even supported in the test
> > cases in nmigen.  Am I missing something obvious?
> >
> > Per Luke's suggestion, I have tried the following as well:
> >
> > comb += Cat(x).eq(Cat(y))
> >
> > but this continues to yield the same error/warning message.
> >
> > Thanks for any help.
> >
> > --
> > Samuel A. Falvo II
> > _______________________________________________
> > libre-riscv-dev mailing list
> > libre-riscv-dev at lists.libre-riscv.org
> > http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
> >
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
Samuel A. Falvo II