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

Samuel Falvo II sam.falvo at gmail.com
Mon Jul 15 02:10:19 BST 2019


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


More information about the libre-riscv-dev mailing list