victor82

The solution codes are not available as you can continuously update your solution.

The solution exposed don't seems competitive enough to solve with good rank the problem exposed here https://highload.fun/tasks/14

That site is really good to play with SIMD code.

Seems there is not bytearray implemented, can't test further :(

"but it worked fine before" talks about the observed behavior

It is not explained why points 31 to 36 are valid, unlike HDL synthesis tools, C compilers are pretty deterministic, same input same output, except timestamps, etc.

If an UB adopt X behavior one time, a reproducible build will take same X behavior the next time.

Of course I am not negating the fact that this undefined in the first instance nor condoning the UB usage.

Location: Santiago, Chile

Remote: Yes

Willing to relocate: to USA/Singapore/Netherlands/Australia/UAE/Germany

Technologies: FPGAs, Verilog, AmaranthHDL, C/C++, Python, Golang

Résumé/CV: https://www.linkedin.com/in/victor-mu%C3%B1oz-79955093/

Github: https://www.github.com/vmunoz82/

Email: who_hn11@avoid.contact

Looking for HFT/ultra low latency, RISC-V, RTL or high scalability related position.

Well, that code is module without any context (ie: connected to nothig), it just have 2 inputs (clk and rst), and an "output" with the current sum, after it reach the desired value it keep stuck there (until reset).

So as the simulation code shows, it just tick the clock (with the "yield" statement) and read the "output" register and print it.

Of course you could connect this "Project Euler 1 accelerator" to a CPU, a SoC or whatever, or just connect LEDs directly to "output"

You can avoid using abstractions and write it directly on the silicon, it's not really difficult, it turns into a bunch of muxes, registers and adders (as shown in the link below) and solves the problem in just 333 clock cycles, using a minimum of power

https://gist.github.com/vmunoz82/49de4c63bee1768283162ec5406...

  class Euler(Elaboratable):
    def __init__(self):
        self.output = Signal(19)

    def elaborate(self, platform):
        m = Module()

        count5 = Signal(3)
        c3, c5 = Signal(17), Signal(18)

        cond3, cond5 = (c3 < 1000) & (count5 != 0), (c5 < 1000) & (count5 < 3)

        m.d.sync += count5.eq(Mux(count5 == 4, 0, count5+1))
        m.d.sync += [
            c3.eq(c3+3),
            c5.eq(Mux(cond5, c5+5, c5))
        ]
        m.d.sync += self.output.eq(self.output +
                                   Mux(cond3, c3, 0)+Mux(cond5, c5, 0))
        return m

According to golem.de's report, Prodigy has its own VLIW ISA, and Qemu achieves compatibility with the other mentioned ISAs.

  Location: Chile
  Remote: Yes
  Willing to relocate: Could be, depends on the place and project
  Technologies: C, Golang, Python, VHDL, Verilog, Amaranth HDL, FPGAs
  Résumé/CV: https://www.linkedin.com/in/victor-mu%C3%B1oz-79955093/
  Email: victor at avoid dot contact
  Github: https://github.com/vmunoz82
 

If you are looking for hands on co-founder engineer, CTO, or want to implement algorithms in hardware, would be good to get in touch.

Thank you for sharing you all digital radio project!

It is a nice example of nMigen usage, sadly there are not many ultra-cheap FPGA boards with 5GHz SerDes to try it.

Thank you for the write-up, I love the way you use CMBC to construct your algorithm, seem like a way to synthesize code :) Thanks also for point CMBC, I was looking for something like that for years!

If you are already familiar with Python I could recommend start with this tutorial: https://github.com/RobertBaruch/nmigen-tutorial

Hi! your application system is kind of flawed, it don't offer you a form nor any chance to include your github link nor respond the questions.

What exactly you are looking for in Chile?, the applications just say "open application", and don't have the role description.