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.

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

@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.

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.

#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 <[email protected]> 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.

Codecov Report

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

@@             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     

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.

Closes #1988.

@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 ...

Codecov Report

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

@@             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     

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.

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

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

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.

Codecov Report

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

@@           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.

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.

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?

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.

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?

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

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) 

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

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

We should get one more approval before removing it.

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`

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.

Signed-off-by: Alessandro Comodi [email protected]

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.