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 TBD
<_whitenotifier-5> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JtXQt
<_whitenotifier-5> [YoWASP/nextpnr] whitequark 1bbee31 - Update dependencies.
lf_ has joined #nmigen
lf has quit [Ping timeout: 260 seconds]
<_whitenotifier-5> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JtX7V
<_whitenotifier-5> [YoWASP/yosys] whitequark bc262a4 - Update dependencies.
<agg> i noticed yosys seems to detect nmigen FSMs but doesn't mark them as FSM state registers because "register has an initialization value", is that... ok?
<agg> (and therefore doesn't do fsm_extract/fsm_opt)
<whitequark> yes, this is expected
<whitequark> it is on my low priority todo list to fix that
<agg> got it, thanks
GenTooMan has quit [Quit: Leaving]
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
richbridger has joined #nmigen
aquijoule_ has quit [Ping timeout: 272 seconds]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
Bertl_oO is now known as Bertl_zZ
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
GenTooMan has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
jeanthom has joined #nmigen
jeanthom has quit [Read error: Connection reset by peer]
jeanthom has joined #nmigen
jeanthom has quit [Read error: Connection reset by peer]
pftbest has quit [Remote host closed the connection]
emeb_mac has quit [Quit: Leaving.]
pftbest has joined #nmigen
pftbest has quit [Ping timeout: 240 seconds]
chipmuenk has joined #nmigen
pftbest has joined #nmigen
jeanthom has joined #nmigen
FFY00 has quit [Ping timeout: 268 seconds]
jeanthom has quit [Ping timeout: 246 seconds]
EmilJ has quit [Remote host closed the connection]
EmilJ has joined #nmigen
nengel has joined #nmigen
nengel has quit [Quit: gone afk]
nengel has joined #nmigen
jeanthom has joined #nmigen
revolve has joined #nmigen
Bertl_zZ is now known as Bertl
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 240 seconds]
<d1b2> <286Tech> Do the Wishbone modules in nmigen-soc use Wishbone Classic only? Or can they also support Wishbone Pipelined?
aquijoule_ has joined #nmigen
richbridger has quit [Ping timeout: 272 seconds]
<d1b2> <286Tech> The context is that if I connect my CPU to my ROM module using Interfaces that I control myself, then I can issue a read every clock cycle. But when I do the same with a Decoder / Arbiter in between, I only get an ack every second clock cycle. This leads me to believe they are operating on classic mode.
<whitequark> the Decoder and Arbiter are IIRC written for the classic mode
<d1b2> <286Tech> And there's no pipeline mode support ATM, right?
nengel has quit [Quit: gone afk]
FFY00 has joined #nmigen
lambda has quit [Remote host closed the connection]
nengel has joined #nmigen
<jfng> 286Tech: the decoder and arbiter both support the optional STALL signal
<jfng> is there anything else needed to implement pipelined wishbone ? (i haven't tried it)
chipmuenk has joined #nmigen
lambda has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
<d1b2> <286Tech> @jfng I don't know. I keep my CYC and STB signals asserted and the ROM can read an address every clock cycle, so ACK should then stay asserted all the time. I'm not using the STALL signal.
<d1b2> <286Tech> I'm glad the classic mode implementation exists. I'll try and see if I can make it support pipelined mode as well.
<lkcl> 286Tech: this works multi-cycle so i believe the answer may be deduced "yes" https://git.libre-soc.org/?p=nmigen-soc.git;a=blob;f=nmigen_soc/wishbone/sram.py;hb=HEAD
jjeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
<d1b2> <286Tech> @lkcl The problem isn't the peripherals. My RAM and ROM modules can are single cycle. It's the Decoder and Arbiter in nmigen-soc that use wishbone classic, so they limit the throughput.
<d1b2> <286Tech> It's not a problem, I just have to come up with a different solution if I want pipeline mode.
emeb_mac has joined #nmigen
jjeanthom has quit [Ping timeout: 240 seconds]
jeanthom has joined #nmigen
<mithro> is d1b2 a bridge to discord / some other service?
<gatecat> it's a bridge to the 1bitsquared discord
gatecat has quit []
gatecat has joined #nmigen
gatecat has quit [Client Quit]
gatecat has joined #nmigen
bvernoux has joined #nmigen
<agg> if I have some word that changes sufficiently rarely, and a pulse when it changes, could I stick the pulse through a pulsesynchronizer and use the output pulse to capture the word into a register in a second clock domain, without needing 2ff or other cdc for the word itself?
<agg> it seems ok, but i've thought that before, heh
<modwizcode> agg: I'm certainly no expert but I think as long as you're sure that the word will never change in the first clock domain before enough cycles pass to complete the capture in the second I'm fairly certain that's safe
<modwizcode> The delay between changes in the first domain must be greater than the clocks to transfer to the second domain + 1 I think.
<agg> modwizcode: thanks! yea, it seems like doing this is at the heart of more complicated handshaking protocols where you just also make sure the source won't change by waiting for an ack back from the second domain
<modwizcode> Yeah I was going to say I'd just do that
<modwizcode> It's not much more complex I think and it saves you the headache of the uncertainty :)
<agg> but in this case I know the first domain changes on a fixed slow period and i don't want to ever miss it anyway
<agg> like, so long as the clock frequency ratio is good enough, it will definitely work, and if it isn't good enough, the whole thing will break with or without cdc issues because the second domain won't be able to keep up
<modwizcode> I was trying to think about the minimum latency and how clevercould be
<modwizcode> like if you always register the signal in the second domain every clock but block using it until the pulse comes through does that help
<modwizcode> but like that sounds very broken
<agg> hmm, thinking you could therefore use the word register output on the same cycle you receive the pulse, shaving off one cycle of latency?
<modwizcode> Yeah
<modwizcode> but I am almost positive it's unsafe
<modwizcode> Because you could have metastable bits
<modwizcode> I think anyway.
<agg> if there was a long latency for the pulse sync that might help, but by default it's just 2ff on the pulse, so you wouldn't have left enough time to sample all the bits of the word, I don't think
<modwizcode> For the same reason it's not safe to just register a multi-bit word in the first place.
<agg> yea
<agg> in my case I know that after getting the 'update' pulse from the first domain, the word definitely won't change for n clock cycles (because it's a deserialiser, basically)
<modwizcode> The only concern I'd have is that if you have the same clock freq but the phase isn't locked, you could end up with exactly aligned clocks every so often which means you probably need at least 1 more clock than you otherwise would, but you say it's not changing that fast anyway.
<modwizcode> Ah
<agg> what I should have asked is probably "what's the best way to get words from a higher-frequency deserialiser into a slower clock domain
<modwizcode> A fifo c;
<agg> ...but without using a fifo" :x
<agg> i don't need the queue, I know the slower domain will always be ready to receive the word, and i would rather avoid the extra resource use
<modwizcode> I've been somehow getting to do a lot of FPGA work recently that involves highspeed data transfer, without actually touching the serializer side of things. But I had to touch it recently and I was very happy that the transciever IP block could automatically add a fifo to handle the phase slack between TX & RX allowing the logic to safely use the TX clock
<modwizcode> Yeah for work I don't think we uh ever care about resource usage on the FPGA that much
<modwizcode> I think our FPGAs are constantly overprovisioned.
<agg> that's how the vendors like it, aiui
<modwizcode> With the fifo or the overprovisioning?
<agg> the overprovisioning :p
<modwizcode> Oh
<agg> mostly i am targetting an ecp5 but i really want this to fit on an ice40up5k and therein lies the timing issue
<modwizcode> Oh
<modwizcode> yeah
<agg> on the ecp5 this is all hilariously quick and easy
<agg> i just have the whole logic run at the bit rate, nbd
<agg> on the up5k i'm sort of scraping 5-10MHz below target, which is Probably Fine (tm) but it would be nice to run the logic slower and have more slack for adding stuff later
<modwizcode> I think I've never worked with anything more resource constrained than the Spartan 6 on the mojo v3 (first exposure to FPGAs I had and I touched very little with it, just basically implementing a quadrature to SPI thingy, easy for pretty much any FPGA I think)
<modwizcode> I don't really understand much about how to increase speeds if you're hitting limitations like that
<modwizcode> Like the only time I've had to deal with that recently is that the timing was hideous for a GbE module I was using, but it turns out the PnR runs in a stupid mode by default and also it needed a false path from the reset clock to the RX/TX clock ins.
<modwizcode> aka. I didn't really learn anything about solving the problem
<agg> hah, yea, my first bigger fpga project was on a cyclone iv and i just didn't care about timing at all, did some horrific stuff, and it all ran just fine
<agg> on this up5k my logic delay is like 1/3 of the total critical path length, the rest is just routing being slow and messy, so it's tricky to even begin to optimise
<modwizcode> I like asked my boss (since I started to dive into trying to setup input/output constraints on the ethernet which turned out to be meaningless) and he was basically like "do the false path thing and if it doesn't work then just hope it does"
<agg> hah
<modwizcode> He doesn't seem to care much for being detailed and full about timing constraints. but he kinda has a point, we don't really know the details of the path from the phy to the fpga on our eval board.
<jfng> 286Tech: that's weird. the arbiter and decoder both propagate cyc,stb and ack combinatorially, so i don't understand how a clock cycle of latency would be introduced.
<jfng> does the ROM interface see its CYC and STB lines asserted all the time ?
<modwizcode> the rom probably introduces it
<d1b2> <286Tech> @jfng Yes
<d1b2> <286Tech> I use an Arbiter with the ROM, so I use the bus of the arbiter. That sees it's cyc and stb asserted continuously.
<d1b2> <david.lenfesty> my work runs designs at like 90% utilization but they have extensive use of pblocks and some internal tooling to re-jig xilinx's tools to hit timing
<d1b2> <david.lenfesty> the general gist of what's been explained to me is constrain constrain constrain and try and get as many different passes as you can 😛
<d1b2> <286Tech> @modwizcode: If I directly connect my cpu to the rom, then I get a word each clock cycle, so it's not that.
<modwizcode> 286Tech: yeah I misremembered what you wrote initially
<d1b2> <286Tech> np 🙂
<jfng> does the problem also occur with only a single initiator (e.g. your cpu) added to the arbiter ?
Chips4Makers has quit [Remote host closed the connection]
<jfng> if you can provide a small repro of this behaviour, i'd be happy to investigate it
<d1b2> <286Tech> I'll make my github project public then
<d1b2> <286Tech> I only have a single initiator which is the cpu, and one target which is the rom.
<d1b2> <286Tech> It's the interconnect branch. I think the names speak for themselves.
<d1b2> <286Tech> In cpu.main() you can see how I used to hook up the cpu directly to the rom, and how I hook them up now with Interconnect.
<d1b2> <286Tech> I most likely did something wrong though 😂
<jfng> thanks ! i'll take a look in a moment
<d1b2> <286Tech> Thanks for your time!
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
Bertl is now known as Bertl_oO
Chips4Makers has joined #nmigen
<d1b2> <286Tech> @jfng: Oh btw, to generate a binary file with a program, just run:
<d1b2> <286Tech> cd programs && riscv64-unknown-elf-as -c count.s && riscv64-unknown-elf-objcopy -O binary a.out hex.bin && .. && python cpu.py
<cr1901_modern> What does "-c" do? Compile only? And objcopy still works on the result?
FFY00 has quit [Ping timeout: 268 seconds]
FFY00 has joined #nmigen
<modwizcode> compile only
<modwizcode> it produces a binary with symbols
<modwizcode> that's why objcopy still works easily
<modwizcode> also usually I wouldn't use riscv64-unknown-elf-as directly I usually funnel through gcc for... reasons.
<d1b2> <286Tech> Eh, it's just the way I do it 😛
<d1b2> <286Tech> I was using python functions to hand assemble instructions...
<d1b2> <286Tech> Calculating relative addresses by hand sucks 😂
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
<jfng> these two assignments will toggle ack every clock cycle when cyc/stb are held high, because the second one will take precedence over the first
<d1b2> <286Tech> Ok, let me free up both of my hands...
<d1b2> <286Tech> ... to do a DOUBLE FACE PALM!
<jfng> :p it happens
<d1b2> <286Tech> Wait, how did it work before then?! That makes no sense 😂
<d1b2> <286Tech> Lesson here is: quadruple check when someone says your code might me wrong before you confidently say that it works correctly!
<d1b2> <286Tech> But doesn't this also mean that Decoder and Arbiter actually don't implement wishbone classic, but wishbone pipeline instead?
<d1b2> <286Tech> I thought classic mode required dropping cyc, stb, and ack after a successful transfer.
<jfng> i think they are flexible enough to accomodate classic/pipelined/registered feedback wishbone
<d1b2> <286Tech> Most likely.
<jfng> yeah, not dropping stb after an ack is not exactly classic WB, (though it's legit if you're in a burst in registered feedback mode)
<d1b2> <286Tech> I've never used wishbone before, but had read about it. I only paid attention to pipeline mode since it has a higher throughput.
<d1b2> <286Tech> Thanks for taking the time to wade through my "wonderful" implementation 😄
<jfng> np, good luck with your cpu !
chipmuenk has quit [Quit: chipmuenk]
Bertl_oO is now known as Bertl
bvernoux has quit [Quit: Leaving]
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
nengel has quit [Quit: gone afk]
pftbest has quit [Remote host closed the connection]
emeb has left #nmigen [#nmigen]
pftbest has joined #nmigen
pftbest has quit [Read error: Connection reset by peer]
pftbest has joined #nmigen
pftbest has quit [Ping timeout: 260 seconds]