ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting September 7th
<DaKnig> isn't it redundant to have an AsyncFIFO with just one stage to cross clock domains?
<_whitenotifier-f> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1]
<_whitenotifier-f> [YoWASP/nextpnr] whitequark 2d4fa56 - Update dependencies.
emeb has quit [Quit: Leaving.]
<DaKnig> so Memory works the same way as AsyncFIFO, right? you specify the clock domain of the port, then in the comb domain specify the addr (and data in case it's a write port), then one clock later it updates (or reads the value out in read ports)
<DaKnig> is that correct?
<yuriks> DaKnig: clock-domain crossing is enough of a chore/footgun that it might still make sense to use an async fifo for it. that neatly prevents you from being tempted to do anything wrong :P
<DaKnig> ok
<DaKnig> will do
_whitelogger has joined #nmigen
_whitelogger has joined #nmigen
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
electronic_eel_ has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
_whitelogger has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jeanthom has joined #nmigen
zignig has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
Asu has joined #nmigen
* zignig spends 4 hours chasing a missing line of code.
* zignig has luna-usb-acm > boneless , RX only.
_whitelogger has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 256 seconds]
jeanthom has joined #nmigen
<Degi> Can I nest FSMs?
<Lofty> Degi: as far as I know, no
<Degi> Awwh okay
<Lofty> Since FSMs work by a context manager I'm not sure if nMigen has enough context to distinguish an inner Case from an outer Case
<Lofty> Easiest way is to just try it though
<Degi> Hm distinguishing the cases isnt too important, but I need to keep their states separate and only do the inner FSM if the outer FSM is in the right state. But I can implement it using two FSMs and a few signals I think
<Lofty> You can have multiple FSMs
<Lofty> Just not nested FSMs
<Degi> Yes, that's what I will do then
jeanthom has quit [Ping timeout: 260 seconds]
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern has joined #nmigen
<DaKnig> I am confused about how Memory works. I thought you just read and write to the rd/wr ports in the right clock domain and it would detect this to know when to update the internal memory/data port? but it does not look like it works this way
<lkcl> the read and write ports, as returned from read_port and write_port, are actual submodules.
<DaKnig> I read that example, does not mean much to me
<lkcl> ok would you like a more complex one? :)
<DaKnig> yes
<DaKnig> please
<lkcl> ok 1 sec
<DaKnig> if possible, with explicit time domains
<lkcl> that's a "wrapped" one that has a port-forwarding "bypass" on it, so that if write comes in on the same cycle as read, the read data is returned from the *write incoming data*, *not* the actual Memory.
<lkcl> why?
<lkcl> because reads - and writes - are one cycle *late*.
<lkcl> for a synchronous Memory, you initiate a read, the response is valid on the output bus *one cycle later*
<DaKnig> this "self.synched" param determines if the read port is synchronous (data arrives a clock later) or async (data is available immediately) right?
<lkcl> something like that, yes.
<lkcl> one of them will be mapped to FPGA BRAM
<lkcl> the other will not
<DaKnig> in series 7 FPGAs apparently it might map to distributed RAM for async read ports (this even takes less resources!)
<DaKnig> sometimes it would also detect sync reads as distributed ram, so it might not be always bram even if it meats all the criteria
<lkcl> you get the general idea, at least
<lkcl> also, see these:
<lkcl> unit test....;a=blob;f=src/soc/bus/test/;h=d1a6d63ae795889a566c25b1e1ad4a15a41b66d9;hb=HEAD
<lkcl> associated code....;a=blob;f=nmigen_soc/wishbone/;h=22b0efdd330f2af99dc25bcdc0133f95b0e59957;hb=9762a3c9a014c6ab6cb8f70a09bdcd0f7a8a3e6d
<lkcl> that's a Memory connected to a Wishbone bus.
<DaKnig> lkcl: I dont see the thing being used
<lkcl> the Memory is created in the unit test
<DaKnig> where do you assign the read port addr and read the data?
<lkcl> line 75 creates the read port
<lkcl> line 82 creates the write port
<lkcl> line 77 assigns the read port addr
<lkcl> line 78 reads the data
<lkcl> i deliberately create the possibility of delayed "ack" for test purposes (using that counter)
<lkcl> so ignore that
<DaKnig> ok so you assign addr, data with comb... ok
<DaKnig> and the Memory module inside deals with the logic required for the updates to happen at the right clock domain
<DaKnig> did I get that one correctly?
XgF has quit [Quit: - Chat comfortably. Anywhere.]
XgF has joined #nmigen
_whitelogger has joined #nmigen
cr1901_modern has quit [Ping timeout: 256 seconds]
emeb has joined #nmigen
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
lkcl has quit [Ping timeout: 265 seconds]
lkcl has joined #nmigen
peeps[zen] is now known as peepsalot
SpaceCoaster has quit [Ping timeout: 244 seconds]
SpaceCoaster has joined #nmigen
<_whitenotifier-f> [nmigen-boards] peteut synchronize pull request #109: genesys2: employ ULPI resource. -
<_whitenotifier-f> [nmigen-boards] peteut commented on pull request #109: genesys2: employ ULPI resource. -
Asuu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
SpaceCoaster_ has joined #nmigen
SpaceCoaster has quit [Ping timeout: 258 seconds]
SpaceCoaster has joined #nmigen
SpaceCoaster_ has quit [Ping timeout: 260 seconds]
BracketMaster has joined #nmigen
<BracketMaster> Degi, Lofty, ^^ I've had no issues nesting FSMs...
<DaKnig> why do you need to nest those FSMs?
BracketMaster has quit [Ping timeout: 256 seconds]
BracketMaster has joined #nmigen
<BracketMaster> I have an FSM that manages a serial link
<BracketMaster> it has a download state
<BracketMaster> and in that download state it has a wait, first, and last state
BracketMaster has quit [Ping timeout: 256 seconds]
BracketMaster has joined #nmigen
Asuu has quit [Remote host closed the connection]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Excess Flood]
emeb has quit [Ping timeout: 246 seconds]
emeb has joined #nmigen
BracketMaster has quit [Ping timeout: 240 seconds]
ademski has joined #nmigen
zignig has quit [Remote host closed the connection]
futarisIRCcloud has joined #nmigen
BracketMaster has joined #nmigen