ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting October 5th
<d1b2> <dub_dub_11> hmm
<d1b2> <dub_dub_11> still struggling
<d1b2> <dub_dub_11> cause my other code uses sync
<d1b2> <dub_dub_11> change the clock signal of sync, but still use it to drive the pll
<_whitenotifier-f> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JTec6
<_whitenotifier-f> [YoWASP/yosys] whitequark 0ac2510 - Update dependencies.
<d1b2> <dub_dub_11> > That being said, what do you plan to do with the PLL? If you want to drive all your logic from it, you can use DomainRenamer to let the relevant logic use the sync domain @Lofty#0000 I can't find any example of this :/
<d1b2> <dub_dub_11> only the test cases
<d1b2> <dub_dub_11> now it's breaking the PLL 😦
<d1b2> <dub_dub_11> the PLL has to be driven directly by an output pin
<d1b2> <dub_dub_11> verilog always @* begin clk = 1'h0; clk = clk50_0__i; but this generated code makes it a combinational cell
<d1b2> <dub_dub_11> so it can't synthesise
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #nmigen
bmartin427 has quit [Quit: Leaving]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting October 12th
_whitelogger has joined #nmigen
chipmuenk has joined #nmigen
hitomi2509 has joined #nmigen
hitomi2509 has quit [Read error: Connection reset by peer]
hitomi2509 has joined #nmigen
emeb_mac has joined #nmigen
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
emeb_mac has quit [Quit: Leaving.]
emeb has quit [Quit: Leaving.]
Asu has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 264 seconds]
emily has quit [Quit: killed]
jfng has quit [Quit: killed]
cesar[m]1 has quit [Quit: killed]
cesar[m] has joined #nmigen
pepijndevos has quit [Ping timeout: 260 seconds]
pepijndevos has joined #nmigen
pepijndevos has quit [Max SendQ exceeded]
pepijndevos has joined #nmigen
emily has joined #nmigen
jfng has joined #nmigen
_whitelogger has joined #nmigen
jeanthom has quit [Remote host closed the connection]
Chips4Makers has joined #nmigen
jeanthom has joined #nmigen
chipmuenk has joined #nmigen
<_whitenotifier-f> [nmigen-boards] whitequark commented on pull request #116: Genesys2 fixes - https://git.io/JTv38
<_whitenotifier-f> [nmigen-boards] whitequark closed pull request #116: Genesys2 fixes - https://git.io/JUha0
<_whitenotifier-f> [nmigen/nmigen-boards] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JTv34
<_whitenotifier-f> [nmigen/nmigen-boards] ktemkin 65fc46c - genesys2: correctly specify I/O attributes for VADJ banks
<_whitenotifier-f> [nmigen/nmigen-boards] ktemkin 0e95118 - genesys2: convert `ulpi` to ULPIResource
jeanthom has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<d1b2> <dub_dub_11> compiling for Cyclone V still creates these LUTs in the clock path, but the newer PLLs don't seem to mind being driventhrough a comb block
<d1b2> <dub_dub_11> so I guess it's partly a quartus issue for inferring LOGIC_CELL_COMB blocks from the buffers
<d1b2> <dub_dub_11> but also the generated nmigen code is causing a problem by confusing quartus
<d1b2> <dub_dub_11> even if a request a pin, it still ends up with buffers
chipmuenk has quit [Quit: chipmuenk]
emeb has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
chipmuenk has joined #nmigen
<d1b2> <dub_dub_11> Quartus automatically puts input buffers, so I don't think it is necessary to explicitly instantiate them (and they seem to be causing this issue)
<d1b2> <dub_dub_11> or at least there needs to be a way to bypass it
hitomi2509 has quit [Quit: Nettalk6 - www.ntalk.de]
jeanthom has joined #nmigen
jeanthom has quit [Quit: Leaving]
emeb_mac has joined #nmigen
emeb_mac has quit [Client Quit]
emeb_mac has joined #nmigen
danfoster has quit [Quit: Textual IRC Client: www.textualapp.com]
<awygle> i wonder if it would be beneficial to have a tracking issue for the most important docs things
<awygle> most important and/or least discoverable
<awygle> that could serve as both tracking and as a stopgap place to direct people when they have questions about the top 5 or so most common things
<awygle> (this is inspired by telling dub_dub_11 about dir='-' out of band, re: the above convo)
<d1b2> <dub_dub_11> when I compiled for a cyclone V and checked the technology map, it had the same issue that the input clock went through LUTs and into the PLL. The only reason it worked is because Cyclone V allows this but Stratix IV doesn't, so it might be worth changing IntelPlatform
<d1b2> <dub_dub_11> so that when the default_clock is requested it uses dir="-"
<awygle> Lofty: ^ thoughts? you're the expert here
<Lofty> Uuuuuuh
<Lofty> Brain no worky rn
<Lofty> ... Yeah, uh. I'm Ravenslofty#9170 on Discord, you can poke me there, and maybe I'll remember to respond
<Lofty> I know there are other problems with I/O buffers, but nMigen kinda requires them in various cases
chipmuenk has quit [Quit: chipmuenk]
<FL4SHK> now that I'm done *finally* getting my 3D printer level and working
<FL4SHK> I'm going to finally finish my long udiv module
<FL4SHK> should end up being pretty fast (other than the fact that it won't be pipelined)
<FL4SHK> how do I access cxxsim?
<awygle> theres a branch
<_whitenotifier-f> [nmigen] H-S-S-11 opened issue #503: Accessing input pin directly (Intel) - https://git.io/JTvhC
<FL4SHK> I see
<_whitenotifier-f> [nmigen] whitequark commented on issue #503: Accessing input pin directly (Intel) - https://git.io/JTfeO
<whitequark> awygle: yeah go ahead and create the issues if you'd like, no objection
<awygle> whitequark: will do
<_whitenotifier-f> [nmigen] H-S-S-11 commented on issue #503: Accessing input pin directly (Intel) - https://git.io/JTfv2
<_whitenotifier-f> [nmigen] whitequark commented on issue #503: Accessing input pin directly (Intel) - https://git.io/JTfv6
<_whitenotifier-f> [nmigen] H-S-S-11 edited issue #503: Accessing input pin directly (Intel) - https://git.io/JTvhC
<_whitenotifier-f> [nmigen] whitequark edited a comment on issue #503: Accessing input pin directly (Intel) - https://git.io/JTfv6
<_whitenotifier-f> [nmigen] H-S-S-11 commented on issue #503: Accessing input pin directly (Intel) - https://git.io/JTfvp
<_whitenotifier-f> [nmigen] H-S-S-11 closed issue #503: Accessing input pin directly (Intel) - https://git.io/JTvhC
<_whitenotifier-f> [nmigen] whitequark edited a comment on issue #503: Accessing input pin directly (Intel) - https://git.io/JTfv6
<_whitenotifier-f> [nmigen] whitequark commented on issue #503: Accessing input pin directly (Intel) - https://git.io/JTffO
happycube has quit [Ping timeout: 265 seconds]
happycube has joined #nmigen
<_whitenotifier-f> [nmigen] H-S-S-11 commented on issue #503: Accessing input pin directly (Intel) - https://git.io/JTffr
emeb has quit [Quit: Leaving.]
Asuu has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
<_whitenotifier-f> [nmigen] alanvgreen commented on issue #425: Support for PLL primitives - https://git.io/JTfmC
<_whitenotifier-f> [nmigen] whitequark commented on issue #425: Support for PLL primitives - https://git.io/JTfYk
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
Asuu has quit [Remote host closed the connection]