17:09 <pie__> xpost https://spectrum.ieee.org/nanoclast/semiconductors/design/xray-tech-lays-chip-secrets-bare

17:34 <qu1j0t3> woo

20:04 <tnt> Damn, the ice40 io primitives are so much more readable than the ecp5. Like ... OFS1P3DX good luck intuitively knowing what this does :p

20:05 <daveshah> I believe the naming scheme comes from AT&T originally

20:05 <daveshah> Same as the FFs

20:05 <daveshah> nextpnr support isn't finished for them yet (did the fuzzing a couple of weeks ago)

20:06 <daveshah> But I think there should be an attribute to pack normal FFs to IO too

20:06 <tnt> Oh, I guess I'm lucky I haven't had issues so far then.

20:06 <daveshah> tbf, Diamond converts them to regular FFs half the time anyway

20:07 <daveshah> Even when I think the hardware should be able to pack them

20:07 <tnt> yeah, an attribute would be nice. But it should then _error_ out if the packing fails.

20:07 <tnt> because my io timing would be screwed up otherwise ...

20:07 <daveshah> Yes

20:08 <tnt> Do you know how USRMCLK works wrt to that btw ? Can I use a OFS1P3DX ? Or am I stuck with a fabric FF and hope it works out ?

20:09 <mwk> hmm, what's the deal with not packing flops to IO by default, anyway?

20:09 <mwk> xilinx wnats you to use a special option/attribute to even consider that

20:09 <mwk> is there some disadvantage?

20:10 <tnt> could be harder to meet timing for the flop since it's "further away".

20:12 <tnt> Also, for instance on the ice40, clock is shared inside an IO tile, so which one do you pick if you use a different clock ?

20:14 <tnt> In general the IO regs are so differents, I'm really not a fan of the tool taking decisions for me. Either it's a path that's critical and the designer should actually pay attention to it and see what's the best course of action. Or it's a path that doesn't matter and then it can stay in the fabric ...

20:14 <daveshah> tnt: no IO flip flops with USRMCLK

20:14 <tnt> daveshah: that's what I feared.

20:14 <daveshah> It doesn't have any kind of IOLOGIC attached

20:15 <daveshah> Even more annoying is it means no using a DDR block to create a clock

20:15 <rombik_su> I guess that depends on specified input/output delay. FF in IOB have fixed path so it's will meet your timing specs or not, but in case when FF in fabric, software can push FF around to accomodate for i.e. larger input delays.

20:17 <tnt> rombik_su: I haven't tried on vivado, but ISE sure didn't try to change the internal FF location to meed the io delays ... it just placed, then checked the constraints. So the only way was to make sure you used the IO regs and appropriate phased clocks or whatever to meet your needs.

20:18 <tnt> daveshah: yeah, I feel like you're better off connecting a gpio to the spi clock if you intend to use the flash non-trivially.

20:29 <rombik_su> tnt: I was playing with input timing in Vivado recently, it felt like it can do this with input FFs placed in fabric.

20:33 <tnt> interesting. Although, I'm not sure I'd consider that really good practice anyway. IDELAY seems like a much better idea.

20:33 <tnt> But heh, sometimes you have no choice and if the tool can handle it, nice.

20:39 <rombik_su> I think, using IDELAY makes more sense when you using IDDR/ISERDES/IOB FF/etc, because it max out at IIRC ~1.5ns (on 7-series) and you can pick up another 1-2 ns jumping from IOBs to fabric endpoint.

20:41 <rombik_su> Vivado is advertised to be timing-aware from top to bottom, so... But I would like to be corrected by Vivado experts on this one.