profile
viewpoint
whitequark whitequark http://lab.whitequark.org technology is beautiful even when it brings destruction and death; accept the beauty but look well beyond it

llvm/llvm-project 6807

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

ocaml-community/utop 627

Universal toplevel for OCaml

ocaml-ppx/ppx_deriving 306

Type-driven code generation for OCaml >=4.02

azonenberg/openfpga 227

Open FPGA tools

lambdaconcept/minerva 154

A 32-bit RISC-V soft processor

ocaml-cross/opam-cross-android 93

An OCaml cross-toolchain for Android and several useful libraries

ocaml-cross/opam-cross-windows 82

An OCaml cross-toolchain for Windows and several useful libraries

inossidabile/heimdallr 79

Deprecated in favor of Protector ⬆

ocaml-community/cppo 78

C-style preprocessor for OCaml

neelance/ffi_gen 77

A generator for Ruby FFI bindings, directly from header files via LLVM's Clang compiler

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 13 hours

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 13 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 a day

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 a day

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 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 2 days

startedwhitequark/binja_itanium_cxx_abi

started time in 2 days

startedwhitequark/binja_itanium_cxx_abi

started time in 2 days

startedwhitequark/parser

started time in 2 days

pull request commentnmigen/nmigen-boards

Add OLED connector SPIResource for ULX3S

Clean version of https://github.com/nmigen/nmigen-boards/pull/104

GuzTech

comment created time in 3 days

PR opened nmigen/nmigen-boards

Add OLED connector SPIResource for ULX3S
+8 -0

0 comment

1 changed file

pr created time in 3 days

pull request commentnmigen/nmigen-boards

Add OLED connector to ulx3s.py

Ok so now that the function names are properly changed, this PR should be able to get merged... except that I had to remove my fork of the repo for the previous PR. I don't really do much with PRs so I screwed this one up as well :S

I'll create a new PR with the suggestions from this PR, and if/when it gets merged, we can close this one.

GuzTech

comment created time in 3 days

issue commentocaml-ppx/ppx_derivers

Is this required after porting ppx_deriving to ppx[lib]?

It shouldn't be, but archiving the repo might break some links from the opam repo. Could put it read-only though. I can't remember how to do that, but will look into it when I get a minute.

XVilka

comment created time in 3 days

push eventYosysHQ/nextpnr

David Shah

commit sha 1afa494e69e3c8af3dd5d1685b9cd2b1d3bea4d0

clangformat Signed-off-by: David Shah <dave@ds0.me>

view details

push time in 3 days

delete branch YosysHQ/nextpnr

delete branch : dave/improved-check

delete time in 3 days

push eventYosysHQ/nextpnr

David Shah

commit sha 70de8b3a03a62cd1be8732cf5916800322a12a17

nextpnr: Improve error reporting in Context::check Signed-off-by: David Shah <dave@ds0.me>

view details

David Shah

commit sha 839fbb3fe9da4f148f4283b94e4d4b1c048a240d

Merge pull request #520 from YosysHQ/dave/improved-check nextpnr: Improve error reporting in Context::check

view details

push time in 3 days

push eventYosysHQ/nextpnr

David Shah

commit sha e9a388a6a9ff1a763cdb5911ccb496e94a84953b

nexus: Fix db integrity check Signed-off-by: David Shah <dave@ds0.me>

view details

push time in 3 days

PR opened YosysHQ/yosys

Return correct modname when found in cache.

Fixes #2451 where otherwise equal submodules were showing different types.

+1 -0

0 comment

1 changed file

pr created time in 3 days

create barnchYosysHQ/nextpnr

branch : dave/improved-check

created branch time in 3 days

fork KazamoriMasaki/picobit

A Compact Scheme System for Microcontrollers

fork in 3 days

startedwhitequark/ulex

started time in 3 days

push eventYosysHQ/yosys

Yosys Bot

commit sha 2116c585810cddb73777b46ea9aad0d6d511d82b

Bump version

view details

push time in 3 days

pull request commentnmigen/nmigen-boards

Change Resource function parameter names to reflect polarity

Maybe there is an issue with SDCardResources where dat3 can both be active-high and active-low. I've kept it as it was.

GuzTech

comment created time in 3 days

Pull request review commentnmigen/nmigen-boards

Change Resource function parameter names to reflect polarity

 def UARTResource(*args, rx, tx, rts=None, cts=None, dtr=None, dsr=None, dcd=None     return Resource.family(*args, default_name="uart", ios=io)  -def IrDAResource(number, *, rx, tx, en=None, sd=None,+def IrDAResource(number, *, rx, tx, en=None, sd_n=None,

I've reverted the change.

GuzTech

comment created time in 3 days

PR closed nmigen/nmigen-boards

Change signal names to match polarity

This commit adds the _n suffix to signal names and function parameters that use PinsN. It also changes the default reset signal name where necessary to reflect the _n suffix.

+208 -208

5 comments

23 changed files

GuzTech

pr closed time in 3 days

pull request commentnmigen/nmigen-boards

Change signal names to match polarity

Ok, then the change should be smaller than what I've done here. The function parameters should reflect the polarity, and any board file that uses these functions should have their parameter names updated, but the rest of the signal names should be untouched.

Let me start over with the commit and PR in order not to pollute the log history with reverts and such.

GuzTech

comment created time in 4 days

pull request commentnmigen/nmigen-boards

Change signal names to match polarity

Ah, you want to keep the signal names the same, but only change the user-facing function parameter names?

GuzTech

comment created time in 4 days

more