00:21 <_whitenotifier-1> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JaG0b

00:21 <_whitenotifier-1> [YoWASP/nextpnr] whitequark fbedbc9 - Update dependencies.

09:41 <lkcl> vup: apparently you can https://stackoverflow.com/questions/13685920/install-specific-git-commit-with-pip

09:41 <vup> You can, I said you cannot depend on a git version on pypi

09:41 <lkcl> i've seen requirements.txt list specific git revision numbers, i'm reasonably sure i've seen symbiflow's requirements.txt for pip3

09:41 <lkcl> ah no

09:42 <lkcl> yes, because pypi does not contain git repositories, it contains [totally insecure, non-signed] release archives

09:43 <lkcl> so you could target "https://github.com/nmigen/nmigen.git?blahblah=commitrevisionchecksum" as the dependency

09:43 <lkcl> (which does exactly what is required)

09:46 <lkcl> FL4SHK, if you want, *when* the reset signal goes high, for a given Signal's reset *value* to be non-zero, use "reset={thevalue}"

09:47 <lkcl> acdc = Signal(name="wholelotofrosie", reset=4239566)

11:11 <FL4SHK> lkcl: I am aware of `reset=whatever`

11:35 <FL4SHK> lkcl: did you hear that I got the packed records and packed arrays work?

11:36 <FL4SHK> It's super exciting!

11:51 <lkcl> FL4SHK, nice. love to see an example online somewhere.

11:51 <FL4SHK> lkcl: does my source code count?

11:51 <lkcl> of course! :)

11:51 <FL4SHK> It uses a similar interface to `Record` and `Layout`, but it's slightly different.

11:52 <FL4SHK> https://github.com/fl4shk/volt32_console/blob/master/hw/src/general/tests/container_types_mods.py

11:53 <lkcl> ahh btw, is this for Packed SIMD?

11:53 <FL4SHK> Is it?

11:53 <FL4SHK> It's for anything that needs a record.

11:53 <lkcl> Vector (parallel) ALU operations?

11:53 <lkcl> VectorAddBus looks like it is

11:54 <lkcl> FL4SHK, there's 18 months behind this https://libre-soc.org/3d_gpu/architecture/dynamic_simd/

11:55 <FL4SHK> lkcl: this isn't specificially for SIMD stuff.

12:39 <kaucasus> Hi folks, I'm doing my thesis on nmigen. I've got a small question. Currently trying to make a demo to show to the promotors. This means that my code should run on a FPGA dev board. We've made a board file, and uploading a blinky works. Now we want to do the following: depending on the

12:39 <kaucasus> * Sorry, found out shift+enter didn't work

12:40 <kaucasus> * depending on the state of a switch, either select the regular, default clock, or make the clock a pushbutton, so that we can "step" through our demo so that it doesn't run at full speed

12:40 <kaucasus> Is that possible to do? We're currently very new, and it isn't directly clear how to do it.

12:41 <FL4SHK> kaucasus: can't you use an enable?

12:41 <FL4SHK> oh

12:42 <FL4SHK> kaucasus: can't you use an enable of some sort?

12:43 <FL4SHK> I'm not sure if you need to handle switch bounce or not.

12:43 <kaucasus> Probably! But how would you go on to do that? Because as far as I understand, nmigen uses the clock resource defined in your boardfile for the sync domain

12:43 <FL4SHK> Do you need to specifically generate a clock?

12:44 <kaucasus> not really, we just wanna step through the code, or choose free running otherwise

12:44 <FL4SHK> Stepping through the code could, potentially, be done with `if (button down this cycle && button up last cycle)`

12:45 <FL4SHK> I don't know if you need ot handle switch bounce or not

12:45 <FL4SHK> you may havve to handle that as well.

12:45 <kaucasus> Yeah, that'll probably be necessary

12:45 <FL4SHK> I think ti depends on your dev board.

12:47 <kaucasus> But do we need to structure our code differently then? Because it's not entirely clear to me how you'd change your regular sync code/domain to using the button

12:48 <FL4SHK> instead of `@(posedge button)` it becomes `@(posedge clk) if (button active)`

12:49 <FL4SHK> I don't know how you even do `@(posedge button)` in nMigen.

12:49 <FL4SHK> It's easy in, say, SV.

12:50 <miek> you can put all of your code in a Module and wrap it with EnableInserter

12:50 <kaucasus> So we need to alter the verilog behind the fact? Because currently it's very nice we can just use the integrated tools to directly synthesise and make a bitfile without futzing around

12:50 <FL4SHK> I don't think you have to alter the Verilog.

12:51 <FL4SHK> synth tools generally want to know which of your signals as clock signals.

12:51 <FL4SHK> Simulation is probably the only place you can do `@(posedge button)`

12:53 <vup> you can just create a new `ClockDomain("name")`, add it to `m.domains` and then drive it from the button: `m.d.comb += ClockSignal("name").eq(the_button_signal)`, after that you can use `m.d.name += ...` to use your new domain

12:54 <kaucasus> ahhh yeah, that could work!

12:54 <FL4SHK> vup: so how does that handle clock constraints in the synth tool?

12:55 <vup> FL4SHK: you can use `platform.add_clock_constraint(domain.clk, frequency)` to add a clock constraint

12:56 <FL4SHK> I see.

12:58 <FL4SHK> vup: what about how it's not a consistent clock?

12:59 <vup> unless you plan on sending the clock to a PLL it should not really matter

12:59 <vup> (you of course want to specify the maximum frequency you think you will get)

12:59 <FL4SHK> Ah, I see. This is news to me

13:00 <vup> most tools also support specifying jitter, but I don't think nmigen has abstractions for that currently

14:35 <whitequark> you don't want to ever use `@(posedge button)`

14:36 <whitequark> you want to debounce first, otherwise you'll get unpredictable results

14:45 <saki> What's the suggestion manner for setting up PLLs/clock management?

14:46 <whitequark> you can use `Instance` to invoke FPGA primitives directly

14:47 <saki> Okay, that's where I was going, but wasn't sure if there was something baked in I missed. Thanks!

15:37 <kaucasus> Hey hey, I'm still a bit stuck with my problem from earlier. Currently I've got this as the minimal code: https://pastebin.com/zdxRXE6Q

15:38 <kaucasus> Obviously it doesn't quite work, but I'm having trouble "changing" the sync domain depending on the value a switch has

15:40 <vup> unless you specify `local=True` when you create a `ClockDomain` they are global

15:41 <vup> so to achieve what you are going for the easiest option is probably to create two clock domains (+ the default sync once)

15:41 <vup> one clock domain that is fed by the button

15:42 <vup> and one clock domain that depending on the state of the switch is either fed by the button clock domain or the default sync domain

15:43 <vup> finally you can swap out which clock domain corresponds to `sync` for the `Blinky` module by using `DomainRenamer` (like `DomainRenamer("button_or_default_sync")(Blinky())`)

15:43 <kaucasus> and should I then change the submodule (in this case the Blinky class) that every call to m.d.sync be replaced to m.d.button_or_sync?

15:44 <vup> thats would be the alternative to using `DomainRenamer`, but using `sync` + `DomainRenamer` is more commonly used

15:44 <kaucasus> ahhhh DomainRenamer! That sounds like the class I would be looking for! Thanks, still new to nmigen and finding out about all the internals