<cr1901_modern>
This is a dumb question but Lattice Crosslink != Crosslink NX, correct?
<sorear>
I would assume NX is being positioned as the newest member of the Crosslink product line
<sorear>
but product lines aren't real
dh73 has joined ##openfpga
rohitksingh has quit [Ping timeout: 260 seconds]
dh73 has quit [Quit: Leaving.]
craigjb has joined ##openfpga
rohitksingh has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
craigjb has quit [Ping timeout: 260 seconds]
craigjb has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
<daveshah>
Yes, CrossLink NX is a new part that is of interest because it is their first part in the 28nm generation
<daveshah>
There will most likely be iCE40 and ECP5 successors on this node released in 2020
<sorear>
ice40 successors, you say now
Asu has quit [Remote host closed the connection]
<sorear>
are they going to stick the iCE brand on something with no arch heritage?
Asu has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
<daveshah>
I've heard different things from different people so I don't know
<tnt>
Is there a good example of how to "wrap" existing verilog in migen for distribution ? (i.e. so that the verilog is packaged with it and things like that)
<omnitechnomancer>
looking at sim models is permissible?
<daveshah>
of course
<daveshah>
it would be pretty bloody hard to synthesise stuff correctly without
<whitequark>
huh I wonder what else you can do with CCU2s
<omnitechnomancer>
heh
<omnitechnomancer>
what is the C input used for?
<daveshah>
You could in theory get slightly more than the "LUT3 and LUT2" - it's really a LUT4 with a LUT2 tap but usually you tie the top input high to split the two functions
<daveshah>
C would be used for an adder/subtractor to do selective invert
<daveshah>
(shamelessly stolen image from somewhere)
<omnitechnomancer>
indeed
<omnitechnomancer>
Is the XOR gate always inline with the LUT output and the carry in just tied low usually?
<daveshah>
I would guess it looks something like that
<daveshah>
Carry in isn't really exposed in that way but I think disabling carry effectively ties it low
<omnitechnomancer>
it isnt exposed but there are the bits that enable the carrys right?
<daveshah>
Yeah
<omnitechnomancer>
I am just wondering since from my poking of hte LUT5 slices on eagle the "SUM" setting on some of the MUXes to select what is output from the F and FX outputs is the same as one of the other more normal settings, making me think that the sum function is always there but doesnt do anything unless in ripple mode
<omnitechnomancer>
I should probably get a sim model out of the thing to have a look at
<omnitechnomancer>
Ah its the MUX that picks the F output, has a setting for SUM, FUNC5 or LUTF
<omnitechnomancer>
but SUM and LUTF are the same
<omnitechnomancer>
the other one has the 3 distinct though its LUTG instead
<omnitechnomancer>
daveshah: does Lattice have Verilog black boxes for it's slices?
<daveshah>
White boxes in fact
<daveshah>
e.g. SCCU2C for a carry slice
<omnitechnomancer>
does it include the memory aspects on them?
<daveshah>
Yes, it does
<daveshah>
(that's called something like SRAMW and SDPRAM)
<omnitechnomancer>
oh no I mean like does it have a SLICE module
<omnitechnomancer>
that has all the things a slice does in it somehow?
<daveshah>
Not a single one but one for each mode
<daveshah>
the back annotation then chooses the right one
<omnitechnomancer>
It also has a DPRAM one that will correctly create DPRAM out of 2 mslices and an lslice
<omnitechnomancer>
I am also not sure how one is supposed to use that mslice cell since it gives you fco and fci but if you connect them wrong the software will fail an assertion and exit
eddyb has quit [Quit: killed]
jfng has quit [Quit: killed]
promach3 has quit [Quit: killed]
swedishhat[m] has quit [Quit: killed]
scream has quit [Quit: killed]
pepijndevos[m] has quit [Quit: killed]
nrossi has quit [Quit: killed]
henriknj has quit [Quit: killed]
synaption[m] has quit [Quit: killed]
xobs has quit [Quit: killed]
omnitechnomancer has quit [Quit: killed]
omnitechnomancer has joined ##openfpga
<omnitechnomancer>
daveshah: I actually think those memory related signals are for hooking up two mslices to one lslice and represent the fact that internally those are hooked up between the slices in ram mode
stefanct has quit [Ping timeout: 240 seconds]
ZombieChicken has quit [Ping timeout: 268 seconds]
stefanct has joined ##openfpga
_whitelogger has joined ##openfpga
<whitequark>
tpw_rules: sorry for dropping the ball on PR, will review and merge later today
Dolu has quit [Ping timeout: 265 seconds]
rohitksingh has quit [Ping timeout: 260 seconds]
<omnitechnomancer>
daveshah: I think the mslice ripple mode is likely very similar to the ecp5, there is a lut2 tap in the sim model, though it's inverted and conditioned on ripple mode
<daveshah>
Yep, sounds very similar
<omnitechnomancer>
The sim model has a mind boggling number of inversions :/
<daveshah>
I guess that is cmos for you
<omnitechnomancer>
also if I read it correctly the carry out is always the inverted carry in if not in ripple mode
<omnitechnomancer>
oh no that was the inverted sense carry out, the carry out just passes the carryin through in that case I guess
<omnitechnomancer>
and I was looking at intermediate signals
<omnitechnomancer>
it appears that the fco is either the fci or the carry out of hte top of the ripple stack depending on whether either LUT4 output was 0
<omnitechnomancer>
I also find it amusing that there is an _nn signal which if I read the convention correctly is double inverted
synaption[m] has joined ##openfpga
pepijndevos[m] has joined ##openfpga
henriknj has joined ##openfpga
nrossi has joined ##openfpga
swedishhat[m] has joined ##openfpga
xobs has joined ##openfpga
promach3 has joined ##openfpga
eddyb has joined ##openfpga
scream has joined ##openfpga
jfng has joined ##openfpga
<ZirconiumX>
omnitechnomancer: Why can't either Anlogic or Altera produce common sense carry logic?
<ZirconiumX>
(Altera have a full-adder that *sometimes* is inverted)
<whitequark>
patents might be involved
<whitequark>
iirc daveshah mentioned that ice40 carry logic specifically was designed to avoid patents
<omnitechnomancer>
ZirconiumX: I suspect the carry logic is pretty common sense but might have some equivalences or something in the sim model
<ZirconiumX>
If the full-adder is patented I have questions
<omnitechnomancer>
also the sim model looks like its built out of cells that are more complicated than the way they are used in this part
<ZirconiumX>
The Altera sim model does a fuckton of things
<daveshah>
whitequark: other way round I think, iCE40 carry logic is patented. I think it is unusual to save power
<daveshah>
The iCE40 carry logic is not very good, it can't do subtract without extra logic
X-Scale has quit [Ping timeout: 265 seconds]
stefanct has quit [Quit: quit]
genii has joined ##openfpga
stefanct has joined ##openfpga
stefanct has quit [Client Quit]
stefanct has joined ##openfpga
<whitequark>
ah
<whitequark>
yes, I really don't like that aspect of it
Asu` has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
<omnitechnomancer>
I suspect that the extra input that can be used to drive the DFF is also able to be used in the combining LUTs logic but some means, so that would mean the price for larger LUTs is fewer FFs unless you need exactly some subfunction of hte LUT
<daveshah>
That's quite common, for ECP5 the mux input is shared with the DFF input
<daveshah>
But you can drive the DFF from the logic function so it's not totally wasted
<daveshah>
Consider for example iCE40 has no direct DFF input, you have to go through the LUT
<ZirconiumX>
Something I found kind of amusing: an ALM has 8 input pins, but Quartus' routing report has an "ALMs unavailable due to LAB input limits", which leads me to believe that LABs are underprovisioned for routing
<mwk>
hmm, could be about FF inputs rather then LUT inputs?
<mwk>
like, clocks / resets / clock enables
<ZirconiumX>
I suppose it makes sense because in the average case you won't have full ALM utilisation
<ZirconiumX>
FF inputs are routed through the LUT inputs, as far as I can tell
<mwk>
no, I mean the other FF inputs
_whitelogger has joined ##openfpga
<omnitechnomancer>
arent the clk, ce, sr signals usually shared among some number of FFs?
Bird|ghosted has quit [Ping timeout: 265 seconds]
<omnitechnomancer>
yosys can do logic minimisation right?
<ZirconiumX>
That's what `opt` does, generally
<omnitechnomancer>
does it need a cell library for that?
<ZirconiumX>
It has its own
<omnitechnomancer>
I am contemplating feeding the sim model for the mslice into it and getting it to draw me a diagram
<ZirconiumX>
It'll need a cell library if the sim model uses it
<ZirconiumX>
If it's plain verilog it'll synth fine
<omnitechnomancer>
its plain verilog AFAIK
<omnitechnomancer>
I think it has a bunch of simulationish stuff in it
<omnitechnomancer>
mostly I just wonder if the SVG I get out of yosys will be easier to understand than the original
<omnitechnomancer>
actually, things like and and nand are not plain verilog right?
<ZirconiumX>
AFAIK they are
<omnitechnomancer>
ah okay, I do not know verilog :P
<omnitechnomancer>
I mean something like and(a, b, c)
<ZirconiumX>
Yep
<omnitechnomancer>
are tri1 and tri0 plain verilog?
<mwk>
omnitechnomancer: they are
<mwk>
not sure how well it is supposed for synthesis though
<omnitechnomancer>
but yosys doesnt like them
<mwk>
I guess yosys doesn't support these
<omnitechnomancer>
atleast the default read_verilog throws syntax error at me
<mwk>
hmm.
* mwk
checks
<omnitechnomancer>
actually it seems it breaks when you try to have an array of them?
<mwk>
so tri0/tri1 aren't supported, but wand/wor *nominally* are
<omnitechnomancer>
this is the line it doesnt like: tri1 [1:0] a,b,c,d,mi;
<mwk>
try using those instead? also, please report an issue
<mwk>
tri1 is *kind of* similar to wor
<omnitechnomancer>
is tri1 a tristate value?
<omnitechnomancer>
0 1 or undriven?
Dolu has joined ##openfpga
<omnitechnomancer>
is tri0 kind of similar to wand?
<omnitechnomancer>
though I guess a question is, in what cases are tri0 and tri1 different from wire?
<omnitechnomancer>
or just plain inputs?
<omnitechnomancer>
so they are weak pullups/pulldowns?
<omnitechnomancer>
what do specify blocks do?
<mwk>
tri0 is basically a plain wire with a pulldown
<mwk>
ie. with no active driver, its effective value is 0
<mwk>
tri1 is the opposite
<mwk>
wor/wand have stronger semantics
<mwk>
with wor, 1 drivers override 0 drivers
<mwk>
with wand, the other way around
<mwk>
hrmm, wait, did I lie about wor being similar to tri1
<omnitechnomancer>
So in my case since I just want to know what the logic looks like deleting the tri0 and tri1's regarding the inputs is fine
<mwk>
ah yes, pretty much
<mwk>
ok, ignore my commend about wor being similar to tri1, I messed up
<omnitechnomancer>
Yea I was wondering how a wired or would imply a pullup
<omnitechnomancer>
yosys doesnt seem to like the specify block in this sim model either
<mwk>
yeah, comment it out
<mwk>
it just describes timings
<omnitechnomancer>
it appears to set all the timings to 0
<daveshah>
That will be so they can be loaded from an sdf
<daveshah>
You still need the specify blocks even if the numbers come from an sdf
rombik_su has joined ##openfpga
<omnitechnomancer>
ah, cool
<omnitechnomancer>
what does it mean if flatten causes yosys to exit claiming that techmap yielded processes?
<daveshah>
It means you need a 'proc' before flatten
<omnitechnomancer>
and if I ran proc before flatten?
<daveshah>
Did you run hierarchy too?
<omnitechnomancer>
no
<omnitechnomancer>
lets try that
<daveshah>
Might need hierarchy -top <top> too
<omnitechnomancer>
that did it I think
<daveshah>
The problem is that without hierarchy parameters wouldn't have been resolved before proc; so any parameterised modules would be imported by flatten "unproc'd"
<daveshah>
But perhaps flatten needs '-autoproc' like techmap itself
<omnitechnomancer>
well the error message mentions autoproc but I assume that is because flatten just delegates to techmap for the actual work?
<daveshah>
Yes, flatten is just a wrapper around techmap
<daveshah>
effectively techmapping a design with itself
<daveshah>
*with its submodules
<omnitechnomancer>
I think to get meaningful diagrams out of this I will need to convert most of the attribute determined things with actual inputs since otherwise much of it simplifies out of existence in an annoying manner
<omnitechnomancer>
can you get it to not flatten something?
<daveshah>
Yes, you can use (* keep_hierarchy *) iirc
Jybz has joined ##openfpga
<omnitechnomancer>
actually just commenting out the cases that map the attributes to the signals should let me get a picture of what it looks like with them in
emeb has joined ##openfpga
<omnitechnomancer>
hmmm, how can I tell if an event list is synthesisable?
<omnitechnomancer>
apparently this makes yosys unhappy: always @( clk or negedge setn or negedge resetn or d_n)
<whitequark>
omnitechnomancer: what kind of storage element do you want?
<whitequark>
two clocks?
<omnitechnomancer>
its apparently trying to make a latch
<whitequark>
actually, no, that just doens't make sense
<omnitechnomancer>
I do not want it to synthesise it though
<omnitechnomancer>
but I understand it might not be able to reason about it
<whitequark>
1364.1 lays out the rules for event lists in synthesizable verilog
<omnitechnomancer>
here clk is not a clock but the enable for the latch
<omnitechnomancer>
whitequark: how would one write a latch with SR inputs in synthesisable verilog?
<whitequark>
1364.1 says nothing about latches with set/reset over enable
<whitequark>
so... you cannot
<whitequark>
(unless you use a vendor extension)
<mwk>
omnitechnomancer: it's not about just event list, it's about the meat of the process as well
<mwk>
what kind of latch do you want exactly? plain SR latch, or just D latch with SR inputs?
<mwk>
in the latter case: always @* if (R) Q <= 0; else if (S) Q <= 1; else if (E) Q <= D;
<omnitechnomancer>
I want yosys to read the sim model and draw me pictures
<mwk>
for plain SR latch, remove the last part
<mwk>
note that yosys doesn't support this properly yet, and it'll make a plain D latch with S/R emulation via logic (which is glitchy and doesn't really work)
<omnitechnomancer>
if its a problem I can probably just make a black box because I want to understand things rather than synthesise them
<mwk>
don't use posedge/negedge when you're not making an edge-sensitive storage device, just use combinatorial-style signal list (preferably @*)
<omnitechnomancer>
I suppose the actual silicon implementation probably has level based SR inputs anyway right?
<mwk>
well, if it's a latch, yes
<omnitechnomancer>
Well you get to pick between latch and ff, so it either has two, or it has something hooked up to be one or the other based on that config bit
<omnitechnomancer>
Ah I see, there is a bit that can be used to combine the two LUTs in an mslice into a LUT5 by using the mi input as the selector
dh73 has joined ##openfpga
<mwk>
omnitechnomancer: the usual implementation of a FF is just two latches glued together (with opposite gate polarity)
<mwk>
so when you configure it as a latch, you just bypass one of them
<omnitechnomancer>
indeed
<omnitechnomancer>
and the SR inputs just tap into the underlying SR latch structure?
<mwk>
correct
<mwk>
daveshah: hey, by any chance, are you at 36c3?
<daveshah>
No, not this year, haven't the energy
<mwk>
ack, understoof
<mwk>
understood
davidthings has joined ##openfpga
davidw has joined ##openfpga
davidw is now known as Guest21415
* rvense
is at the openfga table installing litex
<omnitechnomancer>
So ~(~a or ~b) is just a and b right?
<omnitechnomancer>
These sim models seem needlessly obtuse sometimes
<sorear>
yes
<sorear>
look up de morgan’s laws
<daveshah>
Some of the obtuseness is to do with x propagation, probably not this one though
<omnitechnomancer>
well this one writes an and as a nor of two inverted signals which seems strange to me
lexano has quit [Ping timeout: 240 seconds]
<omnitechnomancer>
but yea I guess the behaviour wrt the extra states might be a reason in most cases
lexano has joined ##openfpga
davidthings has quit [Quit: Leaving]
Guest21415 has quit [Quit: Leaving]
davidthings has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
davidthings has quit [Read error: Connection reset by peer]
davidthings has joined ##openfpga
pie_ has joined ##openfpga
AndrevS has joined ##openfpga
X-Scale has joined ##openfpga
Dolu has quit [Ping timeout: 265 seconds]
Jybz has quit [Quit: Konversation terminated!]
emeb_mac has joined ##openfpga
<TD-Linux>
thanks everyone for ruining my ability to read datasheets without spotting every latch vs flipflop typo
<OK_b00m3r>
:D
craigjb has quit [Ping timeout: 240 seconds]
<mwk>
...?
<whitequark>
is this related to the T-latch discussion earlier?
<TD-Linux>
but it's a very much a recurring theme, e.g. with whitequark's analysis of ice40(?) io cells from a while back
<mwk>
yeah, why the fuck can't the industry keep this straight
<sorear>
it's a "latch" as in "latchup"
<daveshah>
D-latch as in double latch :p
emeb_mac has quit [Quit: Leaving.]
dh73 has quit [Quit: Leaving.]
dh73 has joined ##openfpga
balrog has joined ##openfpga
<TD-Linux>
are there any fpga related talks this year? or is it solid crosslink-nx hacking
craigjb has joined ##openfpga
<TD-Linux>
daveshah, I see prjoxide is doubly oxidized :)
<daveshah>
indeed :)
<daveshah>
It's my first time and I'm enjoying it
<daveshah>
Surprised how easy the move from C++ has been really
<TD-Linux>
the api of libtrellis / liboxide is totally arbitrary, right? it's hidden behind the architecture api in nextpnr?
<daveshah>
Yes, that in one direction and the ecp{pack, unpack} command line tools in the other
<daveshah>
The idea is to have another command line tool in oxide (rust also) that spits out the bba for nextpnr; instead of a Python script that links against libtrellis like for ecp5
<daveshah>
That will remove any end user need to link against Python even at build time, which is much more of a PITA than its worth
<daveshah>
I've kept some Python (using pyo3 which isn't too bad) for fuzzing (writing the fuzzers is kind of nicer in an interpreted language imo) but that's a dev dependency only
<TD-Linux>
bonus points if it doesn't use an incredible amount of ram while doing so and not need the serialization during build
<daveshah>
Yeah aim is something fully deduplicated, I need to play with that some more
<daveshah>
If it all works out it shouldn't be too hard to backport ECP5 support to the new oxide framework too
<TD-Linux>
did you find anything out about the LUT5 yet?
<daveshah>
Nothing exciting - as far as I can tell it's just the two LUT4s and a mux
<daveshah>
the ECP5 had two LUT4s and two muxes (so you could also build LUT6s and LUT7s)
<daveshah>
so it is actually a step backwards
<TD-Linux>
ok. I was curious why they called a LUT5 when it has 3 inputs
<daveshah>
Which thing are you talking about?
<daveshah>
I guess that must be the MUX2 to build a LUT5
<TD-Linux>
ohhh I see now. on the datasheet they have a block called "LUT5 and carry" but they just mean "thing to make a LUT5"
<daveshah>
yeah
davidw has joined ##openfpga
davidw is now known as Guest90992
davidthings has quit [Ping timeout: 260 seconds]
AndrevS has quit [Quit: umount /dev/irc]
Guest90992 has quit [Quit: Leaving]
davidthings has joined ##openfpga
rombik_su has quit [Read error: Connection reset by peer]
Asu` has quit [Remote host closed the connection]
genii has quit [Quit: Hockey and beer time, not necessarily in that order..]
emeb has quit [Quit: Leaving.]
balrog has quit [Quit: Bye]
emeb_mac has joined ##openfpga
<TD-Linux>
very recent stm32s have a cool high-resolution timer feature that uses a calibrated delay line to get an effective multi-ghz timer. that's a feature I'd love to see on a fpga
<sorear>
so…a PLL with multiple taps?
<sorear>
not sure what interface you're describing exactly
<sorear>
would this be like "TDR with no extra parts"