cfelton / rhea

A collection of MyHDL cores and tools for complex digital circuit design

NOTE the following is a work-in-progress (WIP) and has not reached a minor release point. If you happen to come across this public repository feel free to try it out and contribute. This repository will be unstable until the first minor release 0.1. This repository is a merge of the mn and gizflo projects.

rhea

The rhea python package is a collection of HDL cores written in MyHDL. The rhea package also includes a small set of utilities to augment the myhdl types and functions as well as FPGA build automation tools.

the name

Pronounced ray (as in ray-gun), just a random name and not pronounced the same as the bird or moon.

dependencies

• myhdl currently 1.0dev (pre-release)
• pytest for the test suite
• Pillow >= 2.9, some video tests utilize the imaging library
• FPGA vendor tools, only for automated build tools.

documenation and resources

If you are not familiar with myhdl starting with the myhdl manual and examples is recommended. General myhdl questions can be answered on the #myhdl IRC channel or on the myhdl mailing-list.
I am often available to answer rhea specific questions on the previously mentioned communications or the rhea gitter can be used.

general comments

IMPORTANT NOTE this repository is under development and is using features from a development version of MyHDL (1.0dev). If you wish to try out this package get the development myhdl (you will need to clone it and install the source). The first rhea release will not occur until myhdl 1.0 is released (probably much later).

Getting close to the fist minor release. The first minor release will contain a small collection of documented cores and frameworks (see below).

This code/package is licensed under the MIT license. This allows anyone to use the package in their projects with no limitations.
Questions and other license options email me.

The following are the definition of some terms used in this README :

• cores : the building blocks of a system. Also, know as IP (intellectual property).

• system : the digital design being implement, synonymous with system-on-a-chip, not using the term system-on-a-chip (SoC) because SoC it is typically reserved for systems that contains a CPU. In this document and the example the system can be a SoC or other complex digital design.

• register : collection of bits that retain state.

• register file : collection of same-sized registers, a register file is organized into read-write entities and read-only entities. A register-file is a programming/configuration interface to a core.

• CSR: control and status registers also known as config and status.
  This term is commonly used for the memory-mapped interface to the cores.

getting started

To get started with the latest version (repo version) checkout out the code and run setup in develop mode. The dependencies listed above need to be installed.

Install the latest myhdl.

  >> git clone https://github.com/jandecaluwe/myhdl
  >> sudo python setup.py install
  >> cd ..

or

  >> pip install git+https://github.com/jandecaluwe/myhdl

After the dependencies have been installed clone this repository to get started.

  >> git clone https://github.com/cfelton/rhea
  >> cd rhea
  # requires setuptools
  >> sudo python setup.py develop

running tests

The tests can be run from the test directory.

  # attempt to run the tests
  >> cd test
  >> py.test

generating bitstreams

If FPGA vendor tools (Xilinx, Altera, Lattice, Yosys) are installed the build examples can be run to generate bitstreams.

  # try to compile one of the examples 
  # (requires FPGA tools installed)
  >> cd ../examples/build/
  >> python ex_xula.py

test

The test directory contains test for the different cores in the package.

Run the tests in the test directory:

>> cd test
>> py.test

Run the tests in the examples directory:

>> cd examples
>> py.test

examples

In the example directory are projects that demonstrate how to build systems using the cores and various tools and target a particular FPGA development board. The examples/build contains LED blinky examples for many different boards.

cores

The following is a list of cores being developed for the 0.1 release, an [x] indicates the core has been completed and verified on an FPGA development board.

• sync FIFO
• async FIFO
• UART lite
• byte-stream to bus-transaction
• SPI controller
• SDRAM controller
• VGA
• LT24 LCD controller
• HDMI
• Ethernet MAC
• PRBS tester (generator and checker)
• ADC 128x022 interface
• ADXL345 interface
• *USB: usbp FX2 interface
• *USB: fpgalink FX2 interface

* Complete but dysfunctional. These are old cores that were working on an FPGA, at one point in time, but have not been updated in ages.

rhea's Issues

instructions: xula_blinky_host.py on raspberry pi 3B [solved]

Update
Issue has been resolved, see my last two posts

Dear all,

I am trying to get xula_blinky_host.py working with a; Raspberry Pi 3B, Xula2-lx25, StickIt!-LedDigits and the Stickit!-MB v4.
I have inserted the LedDigits in PM2. I am able to to run the LedDigitsTest, after changing the LedDigitsTest.UCF using xsconnect.
I have verified the UART pins are working, by connecting chan 14 and 15 on the stickit board.
I communicated via minicom and checked if I could receive echoes.
I am able to create a bitstream from xula_blinky_host. If I upload this bitstream; nothing happens.
The LedDigits module is off. This is not what i expect.
I thought data could be written via uart to the xula2 and this would appear on the leddigit board on PM2. I can't write data.

Do the authors, @cfelton and @forumulator , have any advice on how to proceed!? Which settings should I use in minicom!? Should I try the example with a raspberry pi 2? What setup was used to verify the code!?

Notes:
I use ubuntu 16.04.1, have a jumper on 5V-PWR and a jumper on GPIO-5V. The xula2-lx25 is connected via USB to the raspberry pi 3 or a raspberry pi 2 (tested both).
I can only change the EEPROM via the Raspberry Pi 2.
Similar question was asked in feb 2016 at the Xilinx forum.

Keep up the good work,

Rik

spi_slave_fifo_async

Abstract: Use fifo_async instead of fifo_sync in spi slave

Hi,

I am trying to edit spi_slave_fifo to sli_slave_fyfo_async, since I think that I need different clocks in read and write.
I have made a try, and in simulation it works, but it doesn't work on the real board.

I am quite new in FPGA development, so baybe I just made a naive mistake...
Or maybe I have to re-check things since I am synthesising with a different tool.

Can you please give a look? Or give me a hint where the problem may be

here is a link to the main module
https://github.com/mngr0/rhea/blob/development/test/test_cores/test_spi/spi_slave_pulsegen.py

and here is a link to spi_slave_fifo_async
https://github.com/mngr0/rhea/blob/development/rhea/cores/spi/spi_slave_fifo_async.py

run "make test-pulse" to test and generate wave file

Background project:
I am working on a FULLY open source project, so I am using icestorm (arachne-pnr and yosys) to program a Lattice ICE40.
The project is about controlling a stepper motor given commanded position via SPI

Check that the "tools" are accessible before running

Check that the tools are accessible before trying to execute a toolflow.

Can't make blinky work on Mojo v3.

I am very new to the FPGA world so I might have done something stupid :)

My source file is:

from myhdl import always, always_comb, always_seq, Signal, ResetSignal, toVerilog, toVHDL, delay, traceSignals, Simulation, now, intbv, concat

from pprint import pprint
import rhea.build as build
from rhea.build.boards import get_board

def blinky(led, clock, reset=None):
  assert len(led) >= 2

  nled = len(led)
  maxcnt = int(clock.frequency)
  cnt = Signal(intbv(0,min=0,max=maxcnt))
  toggle = Signal(bool(0))

  @always_seq(clock.posedge, reset=reset)
  def rtl():
    if cnt == maxcnt-1:
      cnt.next = 0
      toggle.next = not toggle
    else:
      cnt.next = cnt + 1

  @always_comb
  def rtl_assign():
    led.next[0] = toggle
    led.next[1] = not toggle
    for ii in range(2, nled):
      led.next[ii] = 0

  if reset is None:
    reset = ResetSignal(0, active=0, async=False)

    @always(clock.posedge)
    def rtl_reset():
      reset.next = not reset.active
    g = (rtl, rtl_assign, rtl_reset,)
  else:
    g = (rtl, rtl_assign,)

  return g

def run_mojo():
  brd = get_board('mojo')
  flow = brd.get_flow(top=blinky)
  flow.run()
  info = flow.get_utilization()
  pprint(info)

if __name__ == '__main__':
  run_mojo()

my build file:

#!/bin/bash
. /opt/Xilinx/14.7/ISE_DS/settings64.sh
python chenil.py
promgen -u 0 xilinx/mojov3.bit -b -p bin -w

Note: I have tried to generate directly the .bin too by adding the line to the tcl script in ise.py:
self.tcl_script += 'project set "Create Binary Configuration File" "true" -process "Generate Programming File"\n'

Then I run mojov3.bin with mojo-loader but nothing happens, the DONE led is not even light up as it does when I load a correct .bin.

ClockManagement's clocks[n] is not driven on Xilinx parts - though ClockManagement's clocksout(n) is.

ClockManagement's clocks[n] is not driven on Xilinx parts - though ClockManagement's clocksout(n) is.

The title says it all, I have reproduced this on both Zybo and CMod_A7 device_primitives tests.

*** For Zybo:

in zybo_device_primitives.py change

    clock1 = clkmgmt.clocksout(0)

to:

   clock1 = clkmgmt.clocks[0]

and then do a:

python zybo_device_primitives.py --build

and flash the device. Note that the corresponding led stays unlit.

This has also been verified to fail on the cmoda7 hardware by making a similar change.

Vivido 2016.2 and ISE 14.7 can't process generated .tcl files with absolute paths or spaces on windows 10

Generated a simple switches to leds program for zybo, and the following bit of the flow:

vivado -mode batch -source Z:\Dropbox\Projects\PU\build\pu.tcl

resulted in the following output:

# add_files Z:\Dropbox\Projects\PU\build\pu.v ERROR: [Vivado 12-172] File or Directory 'Z:DropboxProjectsPuildpu.v' does not exist

The offending line of the TCL file:

add_files Z:\Dropbox\Projects\PU\build\pu.v

The same issue happens for all other paths in the file, and is corrected by changing the paths to forward slashes. (Which the vivido gui seems to do in it's own 'choose a file' dialogs).

Fix incoming shortly.

sdram controller

Abstract
Conversion is not possible sdram_sdr_controller is not finished

Dear all,

I am trying to test the rhea sdram controller on the xula2-lx25. I have already done a successful test with the sdram controller of @udara28, see sdram controlller, who was coached in a Google Summer code 2015 by @devbisme.
The sdram interface of udara is similar to the sdram interface of @cfelton see here; both are based upon xesscorp.
I am, however, unable to get a conversion with rhea.

from myhdl import instances, always_seq, block, Signal, ResetSignal
from rhea.system import Wishbone
from rhea import Global
from rhea.cores.sdram import SDRAMInterface, sdram_sdr_controller


@block
def sdramtest(clock, clock_sdram, reset):
    # Interfaces to the modules
    glbl=Global(clock=clock, reset=reset)
    ixbus=Wishbone(glbl=glbl, data_width=16,address_width=12) #see: Winboad_W9812G6JH_75
    exbus=SDRAMInterface()
    exbus.clk=clock_sdram  # TODO: The sdram clock should be linked somehow to the xula clock
    tbdut=sdram_sdr_controller(clock,reset,ibus=ixbus,extram=exbus)

    return instances()

if __name__=="__main__":
    clock=Signal(bool(0))
    clock_sdram = Signal(bool(0))
    reset=ResetSignal(1,active=0,async=True)
    inst=sdramtest(clock, clock_sdram, reset)
    inst.convert(hdl='Verilog')

The code fails AttributeError: 'SDRAMInterface' object has no attribute 'lock'.

In sdram_sdr_controller:
line 60: sdram.lock but SDRAMInterface does not have this attribute
line 81: In line 81 of sdram_sdr_controller, the following default portmap is defined;
'extmem': SDRAMInterface(clock)
However; SDRAMInterface does not accept clock.

Furthermore, in Rhea's SDRAMInterface, the functions load_mode and precharge are not present. Rhea does seem to have a placeholder for them in the dictionary "Commands"; LMR and PRE, i.e. Load Mode Register and Precharge. Rhea also defines two types of writes; controller side and a side identified as _. The functions _read and _write are slightly different from read and write in Udara's work.

Conclusion
Conversion is not possible sdram_sdr_controller is not finished

[enhancement] Provide board definition and blinky example for Red Pitaya

I would like to try getting rhea to work (board definition and blinky) with the Red Pitaya board (http://redpitaya.com/). I will try an implementation myself, but I would appreciate some feedback if others have already made some experience with it. So let me know if you have tried something!

Support Diligent Adept's 'djtgcfg' utility for flow.program() on applicable Diligent boards

@cfelton

What do you think of the idea of adding programming support to flow.program() for Diligent boards through their command line djtgcfg utility? (supports windows and linux). If you're good with it, how do you think it would fit abstraction wise? It seems like boards that support it shouldn't duplicate the functionality. (though I imagine it would only be a couple of lines of code to add it)

Outside Interfacing

I'm not sure if this is myhdl proper or a thing for rhea ...

What I would like to able to do is interface a running myhdl simulation to the network. Have the exposed objects (serial port, cso, memory maps, etc ... ) to a udp port.

Exposed a a packet interface udp <---> serial port. That way data capture and control commands can be issued remotely to the simulation.

From my reading of the code , this would need to be some inside the simulation loop , kind of like the cosimulation subsytem.

Thoughts ?

fix test_emesh_fifo test

This test started failing in Python 2.7 only. The test has been marked ax xfail for now, it is a non-critical test but it should be determined what change caused the test to start failing.

Add a digilent basys3 board definition

Add a basys3 board definition to the board definition collection in rhea.build.boards.xilinx and corresponding tests and blinky example (rhea.examples.basys3.blinky).

The example should be verified on the hardware.

Change GPIO pin assignments to Peripheral based devices vs FPGA based.

After running into some small issues converting the de0nano for the de1_SoC board. I noticed that the LT24LCD pins are hard coded into de0nano pin definition file.

In my opinion, these pins should not be put here. Since these pins are connected to a peripheral board. It should be flexible upon which board you use.
(Said another way, the GPIO pins should be defined by the peripheral you use, Not the FPGA board)

I am proposing a new file called "lt24lcdpins.py" under the directory rhea-master/rhea/cores/video/lcd...
this file will linkup with the dedicated pins on the de0nano or de1_SoC GPIO[0/1] pins.
The user will define which GPIO to use (eg 0 or 1), in the examples directory under the board
definitions de1_Soc_lt24lcd.py file, in the examples directory.

Please let me know your feedback, Or a better location to put this type of file.
Thanks. MikeK

fifo_syncers cleanup

The fifo_syncers.py module needs a little cleanup:

1. remove the m_ from the functions (myhdl module names).
2. PEP8 the code, make the signal and variable names full words.
3. make the resync parameterizable sync_reset(clock, reset_in, reset_out, synclen=2)
4. add doc-strings.

You will need to search the code and find where the modules were used and updated for the new names.

After the changes, make sure and run the regression tests

cd rhea/test/test_cores/test_fifo
py.test

You can run all the tests from rhea/test but note, currently when running all tests py.test is 10x slower than explicitly running the tests. Use make test to run the tests without py.test.

UART lite modifications

The following clean-up needs to be done to the UART module.

1. Change the fifo port interface to use a single fifobus. The write side of the FIFOBus will write to the TX fifo and the read side of the fifobus will read from the RX fifo. Internally the TX read and RX write will be accessed via another FIFOBus interface.
2. Update the doc strings to use the Google doc format.
3. Add documentation to the sphinx docs, bare minimum include the autodocs of the uartlite module.
4. Make sure the code is PEP8.

Would be nice if Clock() type exposed 'clock ticks' to 'simulation ticks' ratio.

This would be particularly useful for being able to delay a certain number of clock ticks. Adding a delay() generator method to the clock type would be another means of exposing this.

ex:

something.next = False
yield glbl.clock.delay(1)
something.next = True

Complete the fifo tests

In the test_ffifo.py complete the following test cases:

            # @todo: test overflows
            # @todo: test underflows
            # @todo: test write / read same time

ClockManagement's 'enable' parameter is not implemented on Xilinx parts

Is it me, or is there some Altera favoritism going on in Rhea? :)

ClockManagement's 'enable' signal is not implemented on Xilinx parts, though it is on Altera parts and the Simulator. This should be consistent for Xilinx and other brands of parts as well.

Ways I can think of to do this:

• Adding clock control units to the outputs of the Xilinx MMCM_BASE - would need more than one
• Somehow provide an error when enable is assigned on non supported hardware.
• (personal preference) Removing the 'enable' signal altogether

Thoughts?

travis-ci build matrix

Need to add travis-ci build matrix to run some of the targets with coverage and some without, pypy runs unbearably slow with coverage. Also, only run the long sims with pypy and the latest py3 version. Coverage only needs to be run with the latest py3 version and the long sims.

[bug] device_clock_mgmt_prim() will not convert due to using unsupported myhdl features.

This one is a little odd. I was trying to get clock management to synthesize, but kept getting:

File "C:\Users\nshaffner\AppData\Local\Continuum\Anaconda3\lib\site-packages\myhdl-1.0.dev0-py3.5.egg\myhdl\conversion_analyze.py", line 203, in visit_Tuple
self.raiseError(node, _error.NotSupported, "tuple assignment")
File "C:\Users\nshaffner\AppData\Local\Continuum\Anaconda3\lib\site-packages\myhdl-1.0.dev0-py3.5.egg\myhdl\conversion_misc.py", line 148, in raiseError
raise ConversionError(kind, msg, info)
myhdl.ConversionError: in file C:\Users\nshaffner\AppData\Local\Continuum\Anaconda3\lib\site-packages\rhea-0.0.1-py3.5.egg\rhea\vendor\device_clock_mgmt_prim.py, line 62:
Not supported: tuple assignment

the code in question is: (device_clock_mgmt_prim.py, line 62)

    @always_comb
    def clk_assign():
        clkmgmt.clockin_out.next = clockin
        for ii, clk in enumerate(clkmgmt.clocks):
            clocksout.next[ii] = clk

The error makes sense according to myHDL's documentation disallows it: (http://docs.myhdl.org/en/stable/manual/conversion.html)

for
The only supported iteration scheme is iterating through sequences of integers returned by built-in > function range() or MyHDL function downrange(). The optional else clause is not supported.

HOWEVER, strangely, test/test_vendor/test_device_clock_mgmt.py succeeds.

So the reason it succeeds is that it runs a simulation prior to conversion, and uses the same clock management object. (simulation apparently has no qualms about tuple assignment). It seems that the simulation is causing the clock management object to be elaborated, and then when it gets to the conversion part, it reuses the same object, the for() has already been expanded. If you remove the simulation step right before the conversion, the test will fail with the same error as above due to the lack of a prior side effecting elaboration step.

Suggestion:

• Alter test_device_clock_mgmt.py to seperate simulation and conversion steps (use different block objects)
• Alter (device_clock_mgmt_prim.py, line 62) to only use range or downrange in it's for statement, and index into the clocks array directly.

[enhancement] create a skipif synthesis tool not available

Currently majority of the build tests (vendor syn+par) have to be run manually, need to generate tests so the tests will be run automatically. Most of these tests will need to be skipped in travis-ci because the vendor tools (ise, quartus, vivado) will not be available.

Symbol 'MMCME2_BASE' is not supported in target 'spartan6'.

@cfelton, it would be nice to have ClockManagement for the spartan 6 series - likely the most popular hobbiest FPGA in the Xilinx line. However, it seems that the MMCME2_BASE is 7 series logic only.

Digging around in some Xilinx docs, I found clock managers corresponding to different parts:

7 Series: MMCME2_BASE, MMCME2_ADV
Virtex-5: DCM_BASE, DCM_ADV
Spartan 3: DCM_SP
Spartan 6: DCM_SP, DCM_CLKGEN

Thats a fair number of different implementations. I suspect that the the current vendor/ clock management code needs some decisions on how to cleanly factor in a larger variety of clock managers. It seems a little odd to me that this is in vendor, rather than system or build. (Maybe inside FPGA objects, similar to how the boards are arranged?) Just a thought.

Long simulation tests

Some of the tests in the test suite take considerable time to execute. To manage the long simulations in the test suite the long tests should be marked. This change should mark the long running "full" tests as long_test skip_long_sim_test. The pytest package has a mechanism to mark certain test and select when these are run. The "long" tests will not be run normally but they can be run manually for additional test coverage or run only with pypy in travis.

Currently, many of these tests are skipped (pytest.mark.skip(True)). These are the tests that need to be dealt with.

It would be nice if clocks could generate architecture specific clock tiles as needed.

It would be nice if Rhea's clocks could generate architecture specific clock tiles as needed.

For example, given a hardware_clock specified in a board definition file with a frequency of 12mhz, I want to create a derived_clock of 48mhz (and have rhea automatically set up the clock tile for me)

derived_clock = hardware_clock.create_derived_clock(frequency=48e6)

During vhdl / verilog conversion:

• verification would occur that the frequency could be synthesized by the clock tiles available in the particular part.
• The particular set of multiplies / divides would be set up - and otherwise configuring the clock tile.
• part specific verilog / vhdl would be emitted to specify the clock tile.

Implementation wise, I imagine there would need to be FPGA part specification classes, much like the board files have. I imagine these FPGA classes would contain their various clock resources and contain code to set up the multipliers and dividers and emit the code. I can also imagine the possibility for these FPGA specifications being used in the future for specifying other implementation specific hardware (serdes, clock buffers, etc)

Thoughts?

Rename the attributes in the FIFOBus interface

The attributes (Signals) in the FIFOBus interface originally used abbreviations. Modify the attributes to use the full word.

Example,

self.write = ...
self.writedata = ...
self.read = ...
self.readdata = ...

vga: use the timing parameter class vs. function

Setting and verifying the VGA timing parameters should be done with the VGATimingParameter class. This will be a change to how the vga core is used, first the timing object will be created and passed to the core.

timing = VGATimingParameters(resolution=(640, 480))
vga_inst = vga_sync(glbl, vga, video_mem, timing)

Would be nice if flow.run() provided board information to the top module for things like ClockManagement

Suppose I'm building a design like so:

    board = rhea.build.boards.get_board("cmoda7_35t")
    flow = board.get_flow(top=top_cmoda7_35t)
    flow.run()

If (for example) I'm using a ClockManagement module, I've currently got to hard-code the vendor string in the top implementation:

@myhdl.block
def top_cmoda7_35t(clock, led, btn, uart_rxd_out, uart_txd_in):

    reset = Reset(0, active=0, async=True)
    clkmgmt = ClockManagement(clock, resetext, output_frequencies=(125e6,))
    clkmgmt.vendor = 'xilinx'
[...]

it would be nice if I didn't have to hardcode the clkmgmt.vendor = 'xilinx', but instead had access to the board instance being used to portmap this guy, so I could just pull it from board.vendor. (clkmgmt.vendor = board.vendor) Perhaps board could be mapped into the function call similarly to the way the ports are, so you could instead do:

@myhdl.block
def top_cmoda7_35t(board, clock, led, btn, uart_rxd_out, uart_txd_in):

    reset = Reset(0, active=0, async=True)
    clkmgmt = ClockManagement(clock, resetext, output_frequencies=(125e6,))
    clkmgmt.vendor = board.vendor
[...]

Thoughts?

register file example

I am trying out the test/test_system/test_regfile.py test case, and have some doubts about the converted verilog/vhdl.

There is a process that read from *_assign_namedbits0_wbits[ii] signals:

always @(memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[0], memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[1], memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[2], memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[3], memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[4], memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[5], memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[6], memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[7]) begin: PERIPHERAL_TOP_MEMMAP_PERIPHERAL1_WISHBONE6_ADD0_WISHBONE7_PERIPHERAL_REGFILE0_REGISTERFILE2_GET_ASSIGNS0_REGISTER4_ASSIGN_NAMEDBITS0_BEH_ASSIGN
    integer ii;
    for (ii=0; ii<8; ii=ii+1) begin
        memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_rl[4][ii] = memmap_peripheral1_Wishbone6_add0_Wishbone7_peripheral_regfile0_RegisterFile2_get_assigns0_Register4_assign_namedbits0_wbits[ii];
    end
end

Since *_assign_namedbits0_wbits[ii] contains some ShadowSignals of the named bits, I'm expecting some continuous assignment statements that writes to *_assign_namedbits0_wbits[ii]. However, the assignments are missing.

I wonder if this is expected behavior, a bug in rhea, or a regression in myhdl?
btw, using github master of both myhdl and rhea.