<f003brv>
just as a high level view, what is generally the most looked at metric
<f003brv>
for comparison?
<f003brv>
or does it vary by application
<f003brv>
also is clb flip flop different than just clb
<sorear>
not sure what you mean by "comparison"
<f003brv>
nvm
<f003brv>
i think the metric i am looking for though is clb
<f003brv>
it only says clb flip-flop
<f003brv>
not sure how that, slices, and logic-cell relate to clb
<f003brv>
it doesn't say how many clbs this fpga has
<f003brv>
is it just slices / 2 = number of clb
<f003brv>
it says 2 slices per clb
<f003brv>
sorear any input? if not all good
<sorear>
the pdf I just linked tells you how clbs and slices are related
<sorear>
figure 1-1
<f003brv>
indeed
<f003brv>
i see two slices in that clb
<f003brv>
was just confirming
<f003brv>
that i assumed correctly about how many clbs
<f003brv>
it only says how many slices my fpga has
<f003brv>
but not how many clbs :/
<sorear>
I've never touched any of that so I can't say anything more definite than what's in the manuals
Degi has quit [Ping timeout: 240 seconds]
<f003brv>
ok no worries
<f003brv>
thanks for your help
<f003brv>
how's openfpga going btw
<f003brv>
I've been here before, but you probably won't remember me
<f003brv>
it's been a couple years now
Degi has joined ##openfpga
f003brv has quit [Remote host closed the connection]
lambda has quit [Ping timeout: 246 seconds]
lambda has joined ##openfpga
____ has joined ##openfpga
<tnt>
daveshah: Is there any way to pass some information/flag/config from the command line to a python script (pre-place/pre-pack/..) in next-pnr ?
pie_[bnc] has quit [Ping timeout: 260 seconds]
<daveshah>
tnt: no nothing like that atm, environment variables and os.environ should work though
pie_[bnc] has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
<tnt>
daveshah: Oh, yeah, good idea, I hadn't thought of that.
OmniMancer1 has joined ##openfpga
OmniMancer has quit [Ping timeout: 244 seconds]
edmund_ has joined ##openfpga
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
Asu has joined ##openfpga
m4ssi has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
Bike has joined ##openfpga
genii has joined ##openfpga
gregdavill has quit [Ping timeout: 240 seconds]
edmund_ has quit [Ping timeout: 258 seconds]
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
mkru has joined ##openfpga
mkru_ has joined ##openfpga
mkru has quit [Quit: Leaving]
mkru_ has quit [Quit: Leaving]
edmund_ has joined ##openfpga
emeb has joined ##openfpga
OmniMancer1 has quit [Quit: Leaving.]
jfcaron_ has joined ##openfpga
jfcaron_ is now known as jfcaron
renze is now known as cybersloth
jfcaron_ has joined ##openfpga
jfcaron has quit [Ping timeout: 260 seconds]
jn___ has quit [Quit: jn___]
jn__ has joined ##openfpga
m_w has joined ##openfpga
<agg>
how much difference does routing the clock of some synchronous interface to a GBIN on my iCE40 make, vs a non-GB IO?
<agg>
i appreciate it means the clock can directly drive a GBUF which is directly connected to the clock on lots of flops
<agg>
but what do I sacrifice by not doing so? timing slack / variation between routing seeds / ?
<daveshah>
Variation is the big problem
<agg>
variation just from bitstream to bitstream, or of clock arrival time between different flops, or..?
<agg>
if it just means spending more time finding a good seed that's not so bad
<daveshah>
Bitstream to bitstream
<daveshah>
You are going to get very frustrated when small things break the design
<zyp>
when small things can break the design, I'd call it fragile, and fragility is bad
<agg>
hmm, trading off pcb designer (me) frustration vs gateware developer (also me) frustration
<agg>
i will continue to attempt to get it to the gbin pin then, thanks for the advice!
<tnt>
does the phase of the clock matter at all ?
<tnt>
as in ... are some data bus captured from that clock ?
<agg>
yes
<agg>
this is a clock for a parallel data interface
<tnt>
ok, then yeah, it's probably worth it to use a GBIN.
<agg>
my understanding is that each GBINn maps to specific GBUFn, and the router can use any GBUFn for things like clock or reset?
<tnt>
what's the clock frequency ?
<tnt>
yeah each GBIN maps to a global net.
<agg>
so e.g. in my design i have this clock going to some GBIN3, so GBUF3 would probably get used for the clocks on the relevant flops, but i don't use gbin2, so the router could use gbuf2 to drive some other high-fanout signal?
<agg>
if i could hit 84MHz on this iCE40HX i'd be pleased
<tnt>
Yes (for your gb question).
<agg>
56MHz would be fine if not
<agg>
but given previously i've run my entire ip stack at 100MHz it seemed feasible
<agg>
(however the rmii is only 50MHz so...)
<agg>
(cool, thanks! I hadn't really appreciated that it's 1:1 between gbins and gbufs)
<tnt>
if you plan on using the pll you also need to be careful not to use the gbin that used the same gbus as the pll outputs for instance ... details like that ...
<agg>
that snag i am aware of :) not that they document it very well at all
<agg>
or like.... document which I/O is the pll cell
<agg>
I think I ended up using the icestorm files to check?
<agg>
i have my core clock input going to the pll input gbin and am avoiding the other one
<agg>
since you also can't use the _other_ PLL pin if you use the first one in PLLPAD mode, iirc
<tnt>
you can use it if you're not using the second pll output. and if you are using the second output, then you can only use the pin as output and not input.
<agg>
i didn't realise you could use those pins as PLL outputs directly, even
<tnt>
no, you can't use them as pll output, not what I meant.
<agg>
good, i'm less confused then :p
<tnt>
I mean, if the pll output is connected to anything in your design, then you can't use the pin as input in your design.
<agg>
can't use it as a GBIN or as an input at all?
<tnt>
That's because the PLL output path (from pll to fabric) re-uses the path that's normally used from pad to fabric.
<tnt>
as input at all.
<agg>
hmm, I thought I had successfully used SB_PLL40_CORE with an input signal that came from the PLL's GBIN pin and drove that GBUF but I might well be misremembering
<agg>
can each PLL use either of its GBINs?
<agg>
(in SB_PLL40_CORE mode)
<tnt>
if you use the PLL40_CORE you can't use any of it's GBIN.
<agg>
ok, and if you use _PAD, can you feed the clock source to either of the two GBIN?
<tnt>
no, only the first one.
<agg>
and if you're using PLL40_PAD and the first GBIN is your clock signal, the second GBIN can only be used as an output?
<tnt>
yes
<agg>
it's a pretty solid set of traps for the unwary, I don't know why it's so vaguely/not documented in the datasheet/anywhere
<agg>
all my designs so far i've fed one clock to one pll gbin and left the other three pll gbins nc
<agg>
how do you know which is the one gbin that the PLL40_PAD can use?
<tnt>
See the gist above, it's the "PLL_A" paths.
<agg>
aah, I see, I misread that as "PLL A" and "PLL B"
<tnt>
yeah, no, the x/y coordinate denote which PLL it is :p
<agg>
but of course 16/33 and 16/0 are the actual PLLs
<agg>
yep
<agg>
what is PLL_B used for?
<agg>
oh
<agg>
that's the path the PLL uses to drive the second PLL output into the GBUF?
<agg>
PLLOUTGLOBALB in SB_PLL40_2F_PAD sort of thing
<tnt>
yup
<agg>
aah, and hence why you can't use the pin as an input, because the pll takes over driving that input path
<tnt>
exactly
<agg>
cool
<agg>
thanks! i had a vague idea before but it makes a lot more sense now
<tnt>
when you start to understand how things are wired, it kind of makes sense :p
<agg>
yea! if only there was a diagram in the docs :p
<tnt>
The thing that confused me the most is that the SB_GB buffer at a location (like 16/33) doesn't drive the same global net as the SB_IO_GB at that location.
<tnt>
like if you lock a SB_GB to X16/Y33 it will drive global net 4 but a SB_GB_IO at X16/Y33/io1 will drive global net 7
<daveshah>
I remember this really tripped me up when adding the ice40up to icestorm
<daveshah>
Its most strange
<agg>
so GBIN0 drives GBUF7, GBIN1 drives GBUF2, ..???
<agg>
bizarre
<tnt>
huh, I never use the number that's on the pinout/datasheet, I look at the IO site.