01:50 <_whitenotifier> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/yosys/compare/ffe8ccfaacc6...829ba1d19f36

01:50 <_whitenotifier> [YoWASP/yosys] whitequark 829ba1d - Update dependencies.

03:27 <KiranShila[m]> What is the equivalent way of doing `fs_shift5_model_o <= repeat (5) @(posedge clk) fs_model_o;`?

03:58 <whitequark> there isn't; is that even synthesizable?

03:59 <whitequark> (I'm guessing you are writing a testbench, but just to make sure)

03:59 <tpw_rules> i think it's a little undocumented, and i'm not confident i understand your verilog, but maybe m.d.sync += fs_shift5_model_0.eq(Past(fs_model_o, 5))?

03:59 <KiranShila[m]> I’m also not very familiar with verilog, but I saw this as an example to create a 5 cycle delay

04:01 <KiranShila[m]> I grabbed it from here https://verificationacademy.com/forums/systemverilog/signal-delay-x-clock-cycles-system-verilog

04:02 <whitequark> I think that might not be synthesizable

04:02 <KiranShila[m]> Haha alright

04:03 <KiranShila[m]> Is there another way you’d recommend creating a n-cycle delay?

04:03 <whitequark> so it boils down to creating a chain of n flops, right?

04:03 <KiranShila[m]> Right

04:04 <whitequark> you can do this by creating n Signals, or a n-bit Signa

04:04 <whitequark> s/Signa/Signal/

04:04 <whitequark> Amaranth is a low-level language that doesn't have things like inference from behavioral constructs

04:04 <whitequark> if you want a few flops, you have to define them yourself, essentially

04:05 <KiranShila[m]> Ah the n bit signal makes sense, then do shifts every cycle

04:05 <KiranShila[m]> I’ll give that a shot

04:06 <whitequark> yeah. `m.d.sync += Cat(o, shreg).eq(shreg, i)`

04:06 <whitequark> * Cat(o, shreg).eq(Cat(shreg, i), * shreg, i))`

05:58 <KiranShila[m]> is there any way to prevent the creation of duplicate identical modules in the emitted verilog?

06:00 <KiranShila[m]> For example, I have two instances of a the same module in my circuit, each of which have their own submodules. Then, after generating verilog, I end up with a module definition for every submodule and for every child submodule, etc.

06:01 <whitequark> no

06:02 <whitequark> what Amaranth emits is essentially equivalent to a post-elaboration Verilog netlist; that is, a Verilog toolchain creates the same representation internally almost immediately after it reads your source code

06:03 <whitequark> you can think of the Amaranth Verilog output being slightly more preprocessed than the hand-written Verilog you would normally feed to a toolchain

06:06 <KiranShila[m]> Makes sense

06:06 <KiranShila[m]> The escaped names break the perl library I was using to split the modules, which I suppose makes sense because then the filenames would get kinda hairy

06:07 <whitequark> I think that is strictly a bug in the Perl library

06:07 <whitequark> the escaped names are a Verilog-1995 feature

06:07 <KiranShila[m]> Yeah of course

06:07 <KiranShila[m]> I think I'm XY Problem-ing myself here trying to split the modules

06:08 <KiranShila[m]> The only reason I was doing it was because I'm using the output as a black box in (god forgive me) Simulink

06:08 <whitequark> the desire to have split verilog output is a common one but unfortunately the current architecture is not conducive to it

06:08 <whitequark> it will be eventually implemented

13:44 <bentomo> Nah nothing that extreme, I just want to comply with open source licensing and give credit where it's due.