profile
viewpoint

benreynwar/fft-dit-fpga 102

Verilog module for calculation of FFT.

benreynwar/fpga-sdrlib 14

Verilog modules for software-defined radio.

benreynwar/axilent 7

Python to AXI4

benreynwar/fusesoc_generators 2

Add generators to fusesoc so that depenedencies can be generated from generic parameters.

benreynwar/biopython 1

Official git repository for Biopython (converted from CVS)

benreynwar/fusesoc 1

FuseSoC is a package manager and a set of build tools for FPGA/ASIC development

PR opened YosysHQ/yosys

proc_prune: do not promote partially redundant assignments.

According to https://github.com/YosysHQ/yosys/issues/2035#issuecomment-634440650, the bug in #2035 requires intrusive changes to write_verilog to be properly fixed.

In the meantime, this PR proposes a workaround to proc_prune to avoid emitting the incriminated corner-case.

The source of the bug would still need to be fixed, but e.g. nMigen users will be able to use proc -nomux without hitting it.

+19 -16

0 comment

1 changed file

pr created time in 8 minutes

issue commentYosysHQ/nextpnr

ChipDBs build flag for windows

I'll submit a PR for it in the next few days.

davidcorrigan714

comment created time in 31 minutes

issue commentcocotb/cocotb

Remove ping_tun_tap example and documentation?

@marcinwoj Does that mean it works for you? I would be happy if it worked, even if it did require sudo (though Windows users are hung out to dry). Could you update the test and get it back into a working state? I updated it to run under Python 3, but it didn't detect any of the incoming packets (from the ping subprocess) as ICMP packets and then just hung. I'm not sure if I'm missing something? I've never been able to run it successfully.

ktbarrett

comment created time in an hour

issue commentcocotb/cocotb

Remove ping_tun_tap example and documentation?

I am also a big fan of this example, as I learned from that how to intercept packets and I used something similar in my designs.

Agree with @cmarqu this shows how powerful cocotb is to leverage the external environment and use cocotb more as a "glue" rather than a test generator.

ktbarrett

comment created time in 2 hours

issue commentgtkwave/gtkwave

Unable to compile the gtk3 version: unknown type name Window

#ifdef GDK_WINDOWING_X11 Window socket_xid; /* from main.c 241 / #else unsigned long socket_xid; / for windows compiles / #endif #else GdkNativeWindow socket_xid; / from main.c 241 */ #endif

...at the beginning of globals.h, please see if it compiles if you add that header like this, which would be safer:

#ifdef GDK_WINDOWING_X11 #include <X11/X.h> #endif

-Tony

 On Saturday, November 28, 2020, 04:18:29 AM EST, DDoSolitary <notifications@github.com> wrote:  

I'm trying compile gtkwave-gtk3 on Arch Linux but got a few errors: In file included from analyzer.c:15:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~In file included from bitvec.c:15:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~In file included from busy.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~In file included from color.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~In file included from ae2.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~In file included from globals.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~In file included from bsearch.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~In file included from debug.c:20:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~make[4]: *** [Makefile:629: busy.o] Error 1make[4]: *** Waiting for unfinished jobs....make[4]: *** [Makefile:629: color.o] Error 1make[4]: *** [Makefile:629: ae2.o] Error 1In file included from clipping.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~make[4]: *** [Makefile:629: bsearch.o] Error 1In file included from currenttime.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~make[4]: *** [Makefile:629: analyzer.o] Error 1make[4]: *** [Makefile:629: debug.o] Error 1make[4]: *** [Makefile:629: bitvec.o] Error 1make[4]: *** [Makefile:629: clipping.o] Error 1make[4]: *** [Makefile:629: globals.o] Error 1In file included from baseconvert.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~make[4]: *** [Makefile:629: currenttime.o] Error 1make[4]: *** [Makefile:629: baseconvert.o] Error 1In file included from discardbuttons.c:10:globals.h:603:1: error: unknown type name ‘Window’ 603 | Window socket_xid; /* from main.c 241 */ | ^~~~~~make[4]: *** [Makefile:629: discardbuttons.o] Error 1make[4]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107/src'make[3]: *** [Makefile:705: all-recursive] Error 1make[3]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107/src'make[2]: *** [Makefile:454: all] Error 2make[2]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107/src'make[1]: *** [Makefile:413: all-recursive] Error 1make[1]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107'make: *** [Makefile:353: all] Error 2 It seems that the source code uses the X11 Window type but doesn't include X11 headers. I can build it successfully after adding #include <X11/X.h> to the beginning of globals.h.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

DDoSolitary

comment created time in 5 hours

pull request commentcocotb/cocotb

Remove test_doctests and use 'pytest --doctest-modules' instead

Codecov Report

Merging #2237 (4a14681) into master (0a1c46a) will decrease coverage by 10.13%. The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##           master    #2237       +/-   ##
===========================================
- Coverage   65.86%   55.72%   -10.14%     
===========================================
  Files          47       47               
  Lines        7953     7872       -81     
  Branches     1324     1318        -6     
===========================================
- Hits         5238     4387      -851     
- Misses       2123     3032      +909     
+ Partials      592      453      -139     
Impacted Files Coverage Δ
cocotb/share/lib/vhpi/VhpiImpl.h 0.00% <0.00%> (-60.00%) :arrow_down:
cocotb/share/lib/vhpi/VhpiCbHdl.cpp 0.00% <0.00%> (-55.40%) :arrow_down:
cocotb/share/lib/vhpi/VhpiImpl.cpp 0.00% <0.00%> (-54.44%) :arrow_down:
cocotb/share/lib/utils/cocotb_utils.cpp 38.46% <0.00%> (-23.08%) :arrow_down:
cocotb/share/lib/vpi/VpiImpl.h 48.48% <0.00%> (-21.29%) :arrow_down:
cocotb/share/lib/gpi/GpiCommon.cpp 60.56% <0.00%> (-14.70%) :arrow_down:
cocotb/share/lib/gpi/gpi_priv.h 65.62% <0.00%> (-13.17%) :arrow_down:
cocotb/handle.py 72.34% <0.00%> (-11.12%) :arrow_down:
cocotb/share/lib/vpi/VpiCbHdl.cpp 62.25% <0.00%> (-8.09%) :arrow_down:
cocotb/share/lib/gpi/GpiCbHdl.cpp 72.00% <0.00%> (-5.34%) :arrow_down:
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 0a1c46a...4a14681. Read the comment docs.

ktbarrett

comment created time in 6 hours

PR opened cocotb/cocotb

Reviewers
Remove test_doctests and use 'pytest --doctest-modules' instead

Closes #1988.

+5 -24

0 comment

3 changed files

pr created time in 7 hours

issue commentcocotb/cocotb

Integrate pytest

@eric-wieser I think we can replace the regression manager with pytest using a somewhat similar approach. This depends on #791.

We could change the implementation of cocotb.test decorator to add the decorated test coroutine to a scheduler when called and also ensure tests start/end in normal mode. This would translate them to normal functions that pytest can run. With this solution pytest could also run undecorated non-coroutine functions if desired. We can also support running tests using pytest without a simulator, as long as those tests don't call into the simulator.

The end result would look very similar to what we have now, but we could extend it with pytest functionality

@pytest.parameterize("a", [1, 2, 3])
@cocotb.test()
async def test_thing(a):
    # do stuff ...
javValverde

comment created time in 7 hours

pull request commentcocotb/cocotb

Update some more tests for new syntax/conventions

Codecov Report

Merging #2236 (5031e73) into master (0a1c46a) will decrease coverage by 10.22%. The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##           master    #2236       +/-   ##
===========================================
- Coverage   65.86%   55.63%   -10.23%     
===========================================
  Files          47       47               
  Lines        7953     7844      -109     
  Branches     1324     1318        -6     
===========================================
- Hits         5238     4364      -874     
- Misses       2123     3025      +902     
+ Partials      592      455      -137     
Impacted Files Coverage Δ
cocotb/share/lib/vhpi/VhpiImpl.h 0.00% <0.00%> (-60.00%) :arrow_down:
cocotb/share/lib/vhpi/VhpiCbHdl.cpp 0.00% <0.00%> (-55.40%) :arrow_down:
cocotb/share/lib/vhpi/VhpiImpl.cpp 0.00% <0.00%> (-54.44%) :arrow_down:
cocotb/_py_compat.py 76.92% <0.00%> (-23.08%) :arrow_down:
cocotb/share/lib/utils/cocotb_utils.cpp 38.46% <0.00%> (-23.08%) :arrow_down:
cocotb/share/lib/vpi/VpiImpl.h 48.48% <0.00%> (-21.29%) :arrow_down:
cocotb/share/lib/gpi/GpiCommon.cpp 60.56% <0.00%> (-14.70%) :arrow_down:
cocotb/share/lib/gpi/gpi_priv.h 65.62% <0.00%> (-13.17%) :arrow_down:
cocotb/handle.py 72.34% <0.00%> (-11.12%) :arrow_down:
cocotb/share/lib/vpi/VpiCbHdl.cpp 62.25% <0.00%> (-8.09%) :arrow_down:
... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 0a1c46a...5031e73. Read the comment docs.

ktbarrett

comment created time in 7 hours

issue openedYosysHQ/nextpnr

Assigning to cell.bel from Python causes crash (generic arch)

I tried adding the following to generic/examples/simple_timing.py to constrain the I/O positions:

# apply IO constraints
io_constraints = {
    'leds[0]$iob': 'X1Y0_IO0',
    'leds[1]$iob': 'X2Y0_IO0',
    'leds[2]$iob': 'X3Y0_IO0',
    'leds[3]$iob': 'X4Y0_IO0',
    'leds[4]$iob': 'X5Y0_IO0',
    'leds[5]$iob': 'X6Y0_IO0',
    'leds[6]$iob': 'X7Y0_IO0',
    'leds[7]$iob': 'X8Y0_IO0',
    'clk$iob': 'X9Y0_IO0',
    'rst$iob': 'X10Y0_IO0',
}

for cname, cell in ctx.cells:
    if cell.type != "GENERIC_IOB":
        continue
    print('Assigning', cname, 'to', io_constraints[cname])
    # crashes:
    cell.bel = io_constraints[cname]
    # works:
    #cell.setAttr('BEL', io_constraints[cname])

Assigning to .bel directly causes a crash—not immediately, but later during placement, with this traceback

$ gdb -args nextpnr-generic  --pre-pack simple.py --pre-place simple_timing.py --json blinky.json --post-route bitstream.py --write pnrblinky.json
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
Reading symbols from nextpnr-generic...run
done.
(gdb) run
Starting program: /opt/yosys/bin/nextpnr-generic --pre-pack simple.py --pre-place simple_timing.py --json blinky.json --post-route bitstream.py --write pnrblinky.json
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".


Info: Packing constants..
Info: Packing IOs..
Info: Packing LUT-FFs..
Info: Packing non-LUT FFs..
Info: Checksum: 0xbfbc1d15

Info: Annotating ports with timing budgets for target frequency 12.00 MHz
Info: Checksum: 0xbfbc1d15

Info: Device utilisation:
Info:            GENERIC_IOB:    10/   84    11%
Info:          GENERIC_SLICE:    14/  800     1%

Assigning leds[2]$iob to X3Y0_IO0
Assigning leds[0]$iob to X1Y0_IO0
Assigning leds[6]$iob to X7Y0_IO0
Assigning leds[4]$iob to X5Y0_IO0
Assigning leds[7]$iob to X8Y0_IO0
Assigning clk$iob to X9Y0_IO0
Assigning leds[5]$iob to X6Y0_IO0
Assigning leds[3]$iob to X4Y0_IO0
Assigning rst$iob to X10Y0_IO0
Assigning leds[1]$iob to X2Y0_IO0
Info: Placed 0 cells based on constraints.
Info: Creating initial analytic placement for 12 cells, random placement wirelen = 207.
[New Thread 0x7fb625f1d0 (LWP 7062)]
Info:     at initial placer iter 0, wirelen = 27
[New Thread 0x7fb625f1d0 (LWP 7063)]
[Thread 0x7fb625f1d0 (LWP 7062) exited]
Info:     at initial placer iter 1, wirelen = 27
[New Thread 0x7fb625f1d0 (LWP 7064)]
[Thread 0x7fb625f1d0 (LWP 7063) exited]
Info:     at initial placer iter 2, wirelen = 27
[New Thread 0x7fb625f1d0 (LWP 7065)]
[Thread 0x7fb625f1d0 (LWP 7064) exited]
Info:     at initial placer iter 3, wirelen = 27
Info: Running main analytical placer.
[Thread 0x7fb625f1d0 (LWP 7065) exited]
Info:     at iteration #1, type GENERIC_SLICE: wirelen solved = 27, spread = 33, legal = 57; time = 0.00s
Info:     at iteration #2, type GENERIC_SLICE: wirelen solved = 27, spread = 34, legal = 66; time = 0.00s
Info:     at iteration #3, type GENERIC_SLICE: wirelen solved = 28, spread = 34, legal = 59; time = 0.00s
Info:     at iteration #4, type GENERIC_SLICE: wirelen solved = 29, spread = 34, legal = 55; time = 0.00s
Info:     at iteration #5, type GENERIC_SLICE: wirelen solved = 29, spread = 34, legal = 53; time = 0.00s
Info:     at iteration #6, type GENERIC_SLICE: wirelen solved = 27, spread = 34, legal = 55; time = 0.00s
Info:     at iteration #7, type GENERIC_SLICE: wirelen solved = 31, spread = 35, legal = 60; time = 0.00s
Info:     at iteration #8, type GENERIC_SLICE: wirelen solved = 32, spread = 40, legal = 66; time = 0.00s
Info:     at iteration #9, type GENERIC_SLICE: wirelen solved = 32, spread = 40, legal = 61; time = 0.00s
Info:     at iteration #10, type GENERIC_SLICE: wirelen solved = 32, spread = 39, legal = 61; time = 0.00s

Thread 1 "nextpnr-generic" received signal SIGSEGV, Segmentation fault.
0x000000555566460c in nextpnr_generic::Arch::unbindBel (this=0x55557326f0, bel=...) at /home/user/projects/fpga/ice/nextpnr/generic/arch.cc:302
302         bels.at(bel).bound_cell->bel = BelId();
(gdb) bt
#0  0x000000555566460c in nextpnr_generic::Arch::unbindBel (this=0x55557326f0, bel=...) at /home/user/projects/fpga/ice/nextpnr/generic/arch.cc:302
#1  0x00000055555d77d8 in nextpnr_generic::HeAPPlacer::place (this=this@entry=0x7fffffe400) at /home/user/projects/fpga/ice/nextpnr/common/placer_heap.cc:283
#2  0x00000055555c1f40 in nextpnr_generic::placer_heap (ctx=ctx@entry=0x55557326f0, cfg=...) at /home/user/projects/fpga/ice/nextpnr/common/placer_heap.cc:1726
#3  0x0000005555664230 in nextpnr_generic::Arch::place (this=0x55557326f0) at /home/user/projects/fpga/ice/nextpnr/generic/arch.cc:548
#4  0x0000005555583b68 in nextpnr_generic::CommandHandler::executeMain (this=this@entry=0x7fffffec90, ctx=std::unique_ptr<nextpnr_generic::Context> = {...}) at /home/user/projects/fpga/ice/nextpnr/common/command.cc:350
#5  0x0000005555585750 in nextpnr_generic::CommandHandler::exec (this=0x7fffffec90) at /home/user/projects/fpga/ice/nextpnr/common/command.cc:422
#6  0x0000005555579fc8 in main (argc=<optimized out>, argv=<optimized out>) at /home/user/projects/fpga/ice/nextpnr/generic/main.cc:72
(gdb)

The cell.setAttr works, and probably is the right way to do this, it's mostly that the error message could be better.

commit: 1afa494e69e3c8af3dd5d1685b9cd2b1d3bea4d0

created time in 9 hours

startedenjoy-digital/litex

started time in 9 hours

pull request commentYosysHQ/yosys

Fix firrtl backend subword assignment issue and missing wire definitions

@azidar we would appreciate if you could take a look at this PR and confirm if this is fine from your perspective. Thanks

sahandKashani

comment created time in 13 hours

issue openedgtkwave/gtkwave

Unable to compile the gtk3 version: unknown type name Window

I'm trying compile gtkwave-gtk3 on Arch Linux but got a few errors:

In file included from analyzer.c:15:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
In file included from bitvec.c:15:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
In file included from busy.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
In file included from color.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
In file included from ae2.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
In file included from globals.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
In file included from bsearch.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
In file included from debug.c:20:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
make[4]: *** [Makefile:629: busy.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [Makefile:629: color.o] Error 1
make[4]: *** [Makefile:629: ae2.o] Error 1
In file included from clipping.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
make[4]: *** [Makefile:629: bsearch.o] Error 1
In file included from currenttime.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
make[4]: *** [Makefile:629: analyzer.o] Error 1
make[4]: *** [Makefile:629: debug.o] Error 1
make[4]: *** [Makefile:629: bitvec.o] Error 1
make[4]: *** [Makefile:629: clipping.o] Error 1
make[4]: *** [Makefile:629: globals.o] Error 1
In file included from baseconvert.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
make[4]: *** [Makefile:629: currenttime.o] Error 1
make[4]: *** [Makefile:629: baseconvert.o] Error 1
In file included from discardbuttons.c:10:
globals.h:603:1: error: unknown type name ‘Window’
  603 | Window socket_xid; /* from main.c 241 */
      | ^~~~~~
make[4]: *** [Makefile:629: discardbuttons.o] Error 1
make[4]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107/src'
make[3]: *** [Makefile:705: all-recursive] Error 1
make[3]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107/src'
make[2]: *** [Makefile:454: all] Error 2
make[2]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107/src'
make[1]: *** [Makefile:413: all-recursive] Error 1
make[1]: Leaving directory '/build/gtkwave-gtk3/src/gtkwave-gtk3-3.3.107'
make: *** [Makefile:353: all] Error 2

It seems that the source code uses the X11 Window type but doesn't include X11 headers. I can build it successfully after adding #include <X11/X.h> to the beginning of globals.h.

created time in 13 hours

pull request commentMikePopoloski/slang

downgraded UnknownModule from error to warning, added ability to print to stderr

Codecov Report

Merging #370 (9b0055c) into master (96066aa) will not change coverage. The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #370   +/-   ##
=======================================
  Coverage   87.84%   87.84%           
=======================================
  Files         164      164           
  Lines       33372    33372           
=======================================
  Hits        29315    29315           
  Misses       4057     4057           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 96066aa...e67380a. Read the comment docs.

pistoletpierre

comment created time in 16 hours

issue commentYosysHQ/nextpnr

ChipDBs build flag for windows

The situation with WIN32 and _WIN32 is a bit complicated; in short, _WIN32 is always defined by a compiler targeting Windows, and WIN32 is defined somewhere else. That "somewhere else" is the project template in case of MSVC, and the system headers in case of MinGW.

Your conclusion is correct, common/embed.{cc,h} should use _WIN32 instead of WIN32.

davidcorrigan714

comment created time in 16 hours

issue openedYosysHQ/nextpnr

ChipDBs build flag for windows

I'm working on getting nextpnr & prjtrellis compiled on windows and I've made good progress except something seems off about loading the chipdbs - namely that it seems to take an extra compiler flag to make it work properly on windows. Browsing through the code I see it's looking for the WIN32 flag, which seems to pick the right loading function if I add it to the compiler command line, but maybe it should be _WIN32 to pick up windows builds automatically?

created time in 17 hours

PR opened MikePopoloski/slang

downgraded UnknownModule from error to warning

This is RE issue #332 (UnknownModule) (thank you - including the ports was a nice touch).

Unknown modules are common enough that it seems like a more appropriate default to have as a warning that can be upgraded (-Werror=unknown-module) to an error if needed.

+1 -1

0 comment

1 changed file

pr created time in 17 hours

issue closedMikePopoloski/slang

Ability to make "UnknownModule" error suppressible and include those instances in --ast-json output

I'm looking for a quick way to read in a design and get a complete list of instances in it. slang's --ast-json output + a bit of Python has gotten me 90% of the way there. The remaining 10% is dealing with undefined module instantiations. With what I'm doing it's more common than not to see instantiations of modules in a design for which HDL module definitions are either not available or deliberately excluded from a list of source files to read in and elaborate (standard cells, memories, other analog macros, submodules that have already been synthesized, etc...). One option is two make 2 passes: the first to get the list of errors and generate empty module definitions and the second to include the missing modules' generated empty definitions, The other is to add the ability to slang to treat undefined modules as black boxes, which seems like a good thing for it to be able to do.

I had a quick go at picking some potentially low-hanging fruit in slang/source/symbols/InstanceSymbols.cpp, but quickly realized that I was going to have to go down a rabbit hole to hack something together that would compile.

How long do you reckon it would take to become familiar enough with slang's structure to accomplish such a thing?

closed time in 21 hours

pistoletpierre

issue commentMikePopoloski/slang

Ability to make "UnknownModule" error suppressible and include those instances in --ast-json output

I added an UnknownModuleSymbol which should do what you want here.

pistoletpierre

comment created time in 21 hours

release MikePopoloski/slang

nightly

released time in a day

push eventMikePopoloski/slang

MikePopoloski

commit sha ced463d2eadcbe63476c121b2571dab67359f3b1

Split hierarchical value expressions out of NamedValueExpression into their own type

view details

MikePopoloski

commit sha 183b90cfa0421e9558378a2abc31938cacdcf366

Suppress lookup errors that find unknown modules

view details

MikePopoloski

commit sha 96066aa70302204fbaaccf96013982f9687cc656

Suppress errors related to hierarchical lookup within uninstantiated modules

view details

push time in a day

PR opened YosysHQ/yosys

Fix firrtl backend subword assignment issue and missing wire definitions

Hi,

Yosys represents ports as wires and output "ports" can therefore be referenced by other signals. Firrtl does not support this and there is a distinction between a wire and a port: An output port can only be written to and cannot be used as references in other signals' expressions. However, depending on the input circuit, yosys' compact representation may end up reusing output ports in expressions.

Consider the following circuit for example:

module  test(in_0, out_0);
    input  [3:0] in_0;
    output [3:0] out_0;

    wire [4:0] S;
    identity u0( .in_inner(in_0), .out_inner(S[3:0]) );
    assign out_0[3:1] = S[3:1];
    assign out_0[0] = S[4];
endmodule

module identity(in_inner, out_inner);
    input [3:0] in_inner;
    output [3:0] out_inner;
    assign out_inner = in_inner;
endmodule

If run through yosys with the following script:

read_verilog test.v
hierarchy -check -top test
opt_clean -purge
write_firrtl fir/test_subindex_assignment.fir

Then the following firrtl circuit is generated:

circuit test: 
  module identity: 
    input in_inner: UInt<4> 
    output out_inner: UInt<4> 

    wire _0: UInt<4>
    _0 <= in_inner
    out_inner <= bits(_0, 3, 0) 

  module test: 
    input in_0: UInt<4> 
    output out_0: UInt<4> 

    wire S: UInt<5> 
    wire _1: UInt<4>
    wire _2: UInt<1>
    wire _3: UInt<1> 
    _3 is invalid

    _1 <= cat(UInt<1>("h1"), bits(out_0, 3, 1))            <<< ERROR: Using "out_0" as an input here.
    _2 <= UInt<1>("h1")
    inst u0 of identity 
    u0.in_inner <= in_0 
    cat(bits(out_0, 3, 1), bits(S, 0, 0)) <= u0.out_inner  <<< ERROR: Subword assignment doesn't exist in firrtl.
    S <= cat(bits(_1, 3, 0), _3)                           <<< _3 is undefined.
    out_0 <= cat(_3, cat(_3, cat(_3, bits(_2, 0, 0))))     <<< _3 is undefined.

There are a few issues above:

  1. Signal S is based on _3 which is undefined.
  2. Firrtl doesn't support subword assignment and it isn't possible to write to a subset of a signal. Yet, there is a cat expression on the LHS of an assignment above.

This PR fixes the 1st problem by adding a missing condition when creating firrtl expressions. This PR handles the 2nd issue by rewriting the circuit to bring yosys' representation closer to that permitted by firrtl. I introduce a dedicated wire for each outgoing port of the module and this new intermediate wire is used as a placeholder for all existing references to RTLIL wires that represent output ports. We then connect this intermediate wire in a single assignment to the output port so the generated Firrtl is legal with no RHS references to the port name.

The changes in this PR cause the same input verilog circuit and yosys script to generate the following, now legal, firrtl circuit:

circuit test: 
  module identity: 
    input in_inner: UInt<4> 
    output out_inner: UInt<4> 

    wire _auto_firrtl_cc_99_rename_invalid_rhs_references_1: UInt<4> 
    wire _0: UInt<4>
    wire _1: UInt<4>

    _0 <= in_inner
    _1 <= _auto_firrtl_cc_99_rename_invalid_rhs_references_1

    _auto_firrtl_cc_99_rename_invalid_rhs_references_1 <= bits(_0, 3, 0) 
    out_inner <= bits(_1, 3, 0) 

  module test: 
    input in_0: UInt<4> 
    output out_0: UInt<4> 

    wire _auto_firrtl_cc_99_rename_invalid_rhs_references_2: UInt<4> 
    wire S: UInt<5> 
    wire _2: UInt<4>
    wire _3: UInt<1>
    wire _4: UInt<4>

    _2 <= cat(UInt<1>("h1"), bits(_auto_firrtl_cc_99_rename_invalid_rhs_references_2, 3, 1))
    _3 <= UInt<1>("h1")
    _4 <= _auto_firrtl_cc_99_rename_invalid_rhs_references_2

    inst u0 of identity 
    u0.in_inner <= in_0 
    _auto_firrtl_cc_99_rename_invalid_rhs_references_2 <= cat(bits(u0.out_inner, 3, 1), bits(_3, 0, 0)) 
    S <= cat(bits(_2, 3, 0), bits(u0.out_inner, 0, 0)) 
    out_0 <= bits(_4, 3, 0) 
+198 -54

0 comment

1 changed file

pr created time in a day

issue commentcocotb/cocotb

Remove ping_tun_tap example and documentation?

Matt's example has the disadvantage that it's not so ... graphic. :)

ktbarrett

comment created time in a day

PR opened cocotb/cocotb

Update some more tests for new syntax/conventions

Updated the issue-specific tests to use async/await, assert, and specify units in Timer. Passing specific exceptions to expect_error is #2223.

+96 -125

0 comment

13 changed files

pr created time in a day

pull request commentcocotb/cocotb

Remove ping TUN TAP example from repo and docs

We should get one more approval before removing it.

ktbarrett

comment created time in a day

push eventcocotb/cocotb

Kaleb Barrett

commit sha 0a1c46aa48d786a1df6fefedc756ba3f5c312a1f

Fix some sphinx warnings (#2235)

view details

push time in a day

PR merged cocotb/cocotb

Fix some sphinx warnings type:cleanup

The below warnings were generated by sphinx code in Python-land. This PR fixes these issues.

/home/kaleb/dev/cocotb/cocotb/decorators.py:docstring of cocotb.test:26: WARNING: Block quote ends without a blank line; unexpected unindent.
/home/kaleb/dev/cocotb/cocotb/drivers/amba.py:docstring of cocotb.drivers.amba.AXI4Master.write:5: WARNING: Unexpected indentation.
/home/kaleb/dev/cocotb/documentation/source/release_notes.rst:33: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/kaleb/dev/cocotb/documentation/source/release_notes.rst:64: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/kaleb/dev/cocotb/documentation/source/install_devel.rst:31: WARNING: undefined label: https://pip.pypa.io/en/stable/user_guide/#user-installs (if the link has no caption the label must precede a section header)
/home/kaleb/dev/cocotb/cocotb/monitors/__init__.py:docstring of cocotb.monitors.Monitor:3: WARNING: more than one target found for 'any' cross-reference 'coroutine': could be :std:term:`coroutine` or :py:class:`cocotb.coroutine`
+20 -15

1 comment

5 changed files

ktbarrett

pr closed time in a day

issue commentcocotb/cocotb

Remove ping_tun_tap example and documentation?

A similar example that doesn't require sudo permission would be nice. Either of the examples you mentioned would work. Matt's code is up to date, the JPEG encoder example is not.

ktbarrett

comment created time in a day

PR opened SymbiFlow/symbiflow-arch-defs

ioddr: fix techmap and fasm features

Signed-off-by: Alessandro Comodi acomodi@antmicro.com

This PR fixes some problems with the IDDR/ODDR techmapping:

  • ODDR:

    • The D2 input never got the correct inverted parameter
    • Incorrect assignment of constant values of the input ports. When a zero-constant was used, the signal should be bound to VCC and the cell inverter enabled
  • IDDR:

    • The SAME_EDGE_PIPELINED feature is enabled by default and it requires no fasm feature, but the techmapping incorrectly assigned either SAME_EDGE or OPPOSITE_EDGE with the result of never getting the SAME_EDGE_PIPELINED mode.

This change requires fixes in fasm2bels: https://github.com/SymbiFlow/symbiflow-xc-fasm2bels/pull/36. Without the fasm2bel fix for the EDGE feature, fasm2bels fails.

+33 -11

0 comment

2 changed files

pr created time in a day

MemberEvent
more