03:27 <Sprite_tm> Hi all, n00b question: if I have a PLL like in the ECP5 that can generate multiple clock outputs with the same phase, if I generate a clock of, say, 48 and one of 96 MHz, do I still need to do full clock domain crossing? Or can I just make sure my signal is stable for 2 96MHz clock cycles for the 48MHz clock domain to read it and call it a day?

03:31 <flea86> Sprite_tm: If they're both coming from the same PLL, I'd imagine what you wrote working too.

03:33 <flea86> ie. at worst, slap in a few dual FFs and call it a day :)

03:55 <Sprite_tm> flea86: FFs? But but but... muh latency! :P

04:02 <flea86> hehe

04:02 <flea86> oh ffs xD

04:10 <Sprite_tm> Tbh, the reason I ask is because I'd like not to have the clock-sync FFs. As far as I can read, the PLL outputs should be synchroneous, making the two clocks be in the same clock domain and I think I also should not get any risk of metastability... so I can do without the FFs. But I have about zero experience with this scenario :)

04:14 <flea86> Sprite_tm: I'm by no means expert either. I avoid multiple clocks where possible myself...

04:15 <Sprite_tm> I kinda want them here... Risc5 at 48MHz, but 4-bit psram interface also at 48MHz... guess where the bandwidth bottleneck is :P

04:20 <flea86> hehe

04:20 <flea86> Sprite_tm: I don't envy your sitch there

04:20 <flea86> sprite_tm: Speaking of CPU cores, my 32-bit pipelined CPU is now working :D

04:21 <flea86> Runs at 100+ MHz on ECP5 with 8kB RAM/ROM and UART

04:23 <Sprite_tm> Grats! It doesn't happen to be RISCV by any chance?

04:24 <flea86> Well no, I wanted single-cycle 32-bit immediate register loads, as well as 1T branch and skip tasks without prediction :)

04:25 <flea86> RISCV needs two cycles for immediate loads IIRC

04:25 <flea86> *32bit immediate

04:27 <flea86> I modded my old Sweet32 CPU assembler to suit the new arch... it's a dirty hack tho

04:34 <tnt> Sprite_tm: no, you can get aways with much less in theory. _but_ ... nextpnr currently can't constraint clock domain path.

04:34 <tnt> err "cross-clock domain path"

04:49 <Sprite_tm> tnt: Erm, what does that mean in practice? It doesn't know the two clocks are related?

04:55 <tnt> Sprite_tm: yes and it won't do any analysis on that path (just report the max-delay but without pass/fail or attempt to optimize AFAIK).

04:56 <tnt> In general for those, I don't use a full cross clock, but I do make sure the output is a register and the input is either a register or a single LUT + FF.

04:56 <Sprite_tm> Hm, gotcha, good advice, thanks.

07:06 <sorear> risc5 and riscv are unrelatedly projects, and risc5/Project Oberon is much older so usurping the name is a dick move

07:12 <flea86> sorear: Oberon is quite an underrated effort IMHO.

07:36 <emily> sorear: ...but RISC-V is pronounced "risc five", right?

07:40 <flea86> emily: Indeed. He was comparing it to: https://www.astrobe.com/RISC5/ which is a very different CPU target.

07:41 <emily> yeah, but name clashes seem kind of unavoidable in that case ^^;

07:42 <flea86> eh, I've always known it as Oberon

07:42 <flea86> which is more than a CPU design

07:42 <flea86> I have it running on the ECP5 here :)

07:43 <flea86> https://github.com/Basman74/Oberon_SDRAM

08:04 <emily> ah, the ohm board looks nice -- those aren't currently available right?

08:08 <flea86> emily: I only have a few boards left on hand.

08:08 <emily> oh it's your board? cool ^^

08:08 <flea86> Yes it is (Thanks :-)

08:49 <futarisIRCcloud> Friendly reminder. #linux.conf.au CFP close soon, on 28 July.

11:36 <_whitenotifier-3> [Boneless-CPU] zignig synchronize pull request #4: directives bikeshed - https://git.io/fjXmy