<whitequark>
mithro: dm me login:password for notifier
lolsborn has quit [Quit: ZNC 1.6.3+deb1ubuntu0.2 - http://znc.in]
lolsborn has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
<mwk>
so, who here needs a CCC voucher?
lolsborn has quit [Ping timeout: 265 seconds]
<kc8apf>
I would like to go once. Probably once my kids are in college.
davidw has joined ##openfpga
davidthings has quit [Remote host closed the connection]
davidw is now known as Guest68517
emeb_mac has quit [Quit: Leaving.]
Guest68517 has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
fsasm has joined ##openfpga
freemint has joined ##openfpga
Jybz has joined ##openfpga
Asu has joined ##openfpga
rombik_su has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
Richard_Simmons has quit [Ping timeout: 264 seconds]
ym has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
X-Scale has joined ##openfpga
freemint has joined ##openfpga
freemint has quit [Remote host closed the connection]
freeemint has joined ##openfpga
fsasm_ has joined ##openfpga
fsasm has quit [Ping timeout: 265 seconds]
emeb_mac has joined ##openfpga
Guest68517 has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<tnt>
Has anyone tried configuring an ecp5 from psram ?
<daveshah>
No, I did look into it though. From memory PSRAMs have a maximum CS low time due to the refresh requirement that wouldn't be met
<daveshah>
Not sure whether that actually matters irl though
<daveshah>
Command set looked fine
<tnt>
Ah yeah ... the ecp5 reads everything at once without pauses ?
<daveshah>
I think so
fibmod has quit [Ping timeout: 244 seconds]
fibmod has joined ##openfpga
freeemint has quit [Remote host closed the connection]
freemint__ has joined ##openfpga
Guest68517 is now known as davidthings
OmniMancer has joined ##openfpga
freemint__ has quit [Ping timeout: 245 seconds]
<OmniMancer>
daveshah: I notice the page on project Trellis database development you pointed me to mentions that the fuzzer determines what to do with a bit change depending on whether it is within the tile(s) of interest, how is the region of bitstream affecting a given tile determined?
<daveshah>
This was parsed from one of the textual forms of a bitstream that Diamond creates
<OmniMancer>
When it mentions an empty bitstream for comparison is that a bitstream generated from a completely empty design?
<daveshah>
Yes
<OmniMancer>
I am not certain that the Anlogic tools have as convenient a means to determine which PIPs exist
<daveshah>
It might be a case of creating some complex designs and looking at the set of pips used
<daveshah>
There's likely a regular structure between tiles too
<daveshah>
fwiw, Anlogic pnl looked pretty isomorphic to Lattice ncl
<OmniMancer>
Yes I noticed that so that will likely aid greatly, but I have not noticed anything obvious that will list pips that exist, but maybe I have not looked hard enough, I do not have significant experience in that area
Bob_Dole has joined ##openfpga
Thorn has quit [Remote host closed the connection]
<OmniMancer>
daveshah: I see the existing stuff that has been started for tilegrid stuff seems to record two values that are given from the log for each instance, wl_beg and bl_beg which seem to have some kind of correlation to where the instance is in the grid but I am not sure what they mean exactly
<OmniMancer>
rombik_su: indeed, I have found that, it is what I have been looking at
<daveshah>
OmniMancer: sounds like that refers to the config SRAM structure in the FPGA
<daveshah>
wl=wordline, bl=bitline, at a first guess
<daveshah>
each tile probably occupies a 2D rectangle inside that SRAM, so has a start and end wordline and bitline
<OmniMancer>
That is likely the case, there are a bunch of instance types that seem to have 0 for both though, which is a bit strange
<daveshah>
There might be some tiles that are used for padding with no bitstream data behind them
<daveshah>
Or, those values are not always correct....
<OmniMancer>
Yea, the IO tiles seem to exhibit this, but I will do some scripting to check which tiles have that property
<OmniMancer>
It appears that things like the IO tiles, the dsp, plls and gclk spines have this property, so it might be that their config does not reside in the same SRAM as the main logic config? or they have just not been marked
<daveshah>
It's also possible that their configuration is not a contiguous region but more split around, so the property doesn't make sense
pie_ has quit [Ping timeout: 245 seconds]
<OmniMancer>
Indeed, like IOs may only have relatively few config bits I guess so likely just use registers for them?
freemint has joined ##openfpga
<daveshah>
Seems plausible
<OmniMancer>
The plb tiles seem to have a regular pattern to these numbers that correlates with their tile location
<OmniMancer>
PLB I assume is Programmable Logic Block, what would PIB mean then?
<OmniMancer>
Interconnect I suppose
<daveshah>
Yes, sounds like it
<tnt>
whitequark: Did you test your nmigen DDR IO in real hardware ? Given how ODDRX1F is vastly different from ICE40 DDR output, I'm not sure how they'd be equivalent unless I'm missing something here.
<tnt>
Yes, to make it 'same_edge', but that's "fair" and not unexpected. But AFAICT the ECP5 has 3 registers too much ... 2 in the D0 path and 1 in the D1 path.
<daveshah>
it's still Yes
<daveshah>
*yes, there's still a latency difference
<daveshah>
I may have misled wq in the past on this one
<tnt>
And tristate doesn't do DDR right, so I need to use OFS1P3BX for the tristate and somehow make sure I match the latency with fabric FF.
<daveshah>
Yeah
<OmniMancer>
It appears that there is either a PIB or a PLB in each tile position, which makes sense since there are no logic tiles in the outer edge where the IO stuff is or the few columns where the blockrams live
<daveshah>
this is a timing diagram made from the ODDRX1F sim model btw
<daveshah>
OmniMancer: ECP5 looks fairly similar, in the case of the ECP5 the logic tiles have interconnect built in so no CIB (PIB in Anlogic terms) is needed. All other functions need a CIB to connect them to the fabric
<daveshah>
In the case of the ECP5 there is a ring of interconnect between the logic and the IO tiles
<tnt>
daveshah: yeah, that's exactly what I'm doing now, running it in a simulator to see how it behaves :)
<whitequark>
tnt: I did a quick check, and I also recall having this exact concern earlier, and looking through the docs, and concluding my impl is correct
<whitequark>
might have well been wrong
<daveshah>
I think the nMigen input DDR is fine
<daveshah>
Whereas output DDR will have two cycles more latency on ECP5 than iCE40
<OmniMancer>
daveshah: indeed it does look similar to what I have seen from the trellis diagrams and vaguely similar to the xilinx ones too, I think the x y coords of the outer ring of PIBs is the same as the IO tiles in that ring
<OmniMancer>
The bl_beg values for a given column of PIB/PLBs seem to increment by 54 each row, the wl_beg seems to increase with column number but not as uniformly
<tnt>
daveshah: yup for input it's indeed the same as Xilinx SAME_EDGE_PIPELINED and matches nmigen's ice40 impl.
<whitequark>
interesting
<whitequark>
so I long had the plan to add a i_latency / o_latency attribute to Pin()
<whitequark>
and it might need to happen faster
<daveshah>
I have a feeling that would be needed for higher gearing, where there's more room for variation between families
<whitequark>
yes
<whitequark>
that was the plan
<tpw_rules>
whitequark: are you by any chance in a boneless cpu mood
<whitequark>
tpw_rules: sorry, i'm really tired right now, and need to get some sleep soon
<tpw_rules>
that's alright
<tpw_rules>
i'll probably be updating the manual PR soon, but you can deal with it when you have time/energy
<OmniMancer>
daveshah: I suspect that the wl_beg might correspond to the frame number and the bl_beg to the bit number in that frame
<OmniMancer>
The plb and pibs under this assumption seem to be 54 bits high, but there are 2 extra bits around the rows with the gclk spines in them so I suspect those might be 2 bits high, though even then that leaves 12 bits in the frame unaccounted for
<tnt>
Mmm, apparently there are some constrains on what reset you can use for all those IO blocks ... it'd be nice if they were explained somewhere. Diamond says "not compatible" but ... no details whatsoever about why
<tnt>
" EHXPLLL 'sysmgr_I/pll_I' output CLKOP with -180 degree phase shift should not be used as the feedback signal (FEEDBK_PATH = INT_OP)."
<daveshah>
From memory, Diamond is a lot more fussy than the hardware actually allows for no real reason
<daveshah>
As for the PLL, I need to look into that. I'm sure ecppll used to work with Diamond
<tnt>
ecppll actually states : // diamond 3.10 or higher is likely to abort with error about unable to use feedback signal
<daveshah>
Right, I think that comment was added by emard who was the last person to work on it
<daveshah>
I guess it used to work on 3.9 then
<tnt>
I tweaked CPHASE manually until it accepted it ...
laintoo has joined ##openfpga
laintoo has quit [Client Quit]
laintoo has joined ##openfpga
lain has quit [Quit: despaghettification]
<tnt>
For the life of me I can't get Diamond to actually use my IO registers at all ...
<tnt>
I disconnected all resets and it still complains the connections aren't compatible FFS.
zng has quit [Read error: Connection reset by peer]
zng has joined ##openfpga
<daveshah>
I don't think I've ever got ODDR+tristate register to actually work in Diamond
<daveshah>
This is definitely just a Diamond bug, the hardware is fine (you can even create it at the post-pnr level using ncl)
<tnt>
First time I actually use diamond and it's weird ... like ... I add a clock-to-out constraint. And that ends up in 'setup time' analysis and not io timing analysis ? what ...
<tnt>
even the formatting of the report is aweful, it's hard to know where one path begin and the other ends.
<tnt>
how does anyone uses this.
<OmniMancer>
daveshah: the ncl files for lattice give the lut config in bits right?
<daveshah>
No, they give it using a kind of logic expression
<daveshah>
So the fuzzer has to format it that way
<OmniMancer>
ah okay that makes sense, I was worried when I saw such in the pnl file
* tnt
wishes the flash manufacturer provided a minimum-clock-to-out and not just a max ...
<tnt>
Oh micron does ... 0ns how generous of them.
Asu has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
<OmniMancer>
daveshah: I think I am going to try and port some of the fuzzing framework stuff from project trellis later
<tnt>
Does nextpnr support configuring drive strength of IOs ?
<daveshah>
I don't think so
<daveshah>
I seem to remember some issue with drive strength vs voltage bits that I didn't figure out
<daveshah>
Need to go back and look at some point
<tnt>
Damn, I sure could use those 500 ps of margin.
<tnt>
Do you know what settings it uses ?
<daveshah>
For 3.3V yes
<tnt>
YEah, 3v3, what drive strength is it fixed at ?
<daveshah>
Oh I thought you meant how the bits map
<daveshah>
Let me check
<daveshah>
Looks like 8mA
<tnt>
Ok, but for 3v3 you know the bits to change to get other values ?
<daveshah>
Yes
lain has joined ##openfpga
<daveshah>
Hang on, I can do a nextpnr patch if you need it
<tnt>
Depends on how much work it is :) I'm not sure yet if I'll need it or not, so if you just have something I can hack in the .config file to change them manually, I can test if it's needed or not.
<tnt>
otoh, if it takes you the same time to do the patch or explain me how to do changes manually ...
<daveshah>
It's 3 lines
<daveshah>
most of which are the warning for modes other than 3v3
<tnt>
ah well, I'll take the patch then :)
<daveshah>
tnt: done
<tnt>
daveshah: \o/ Thanks !
<daveshah>
bad news - I changed constids an hour earlier so you'll probably have to wait 5 minutes for your build now
<tnt>
I think you're overestimating my laptop :)
OmniMancer has quit [Quit: Leaving.]
Jybz has quit [Quit: Konversation terminated!]
fsasm_ has quit [Ping timeout: 265 seconds]
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
rombik_su has quit [Quit: Leaving]
Asu has quit [Remote host closed the connection]
davidthings has quit [Read error: Connection reset by peer]
<emily>
daveshah: nextpnr takes like 30+ minutes to build on my laptops T_T
<emily>
and there's no meaningful build caching when hacking on the nixpkgs derivation because they're pure/sandboxed