freemint has quit [Remote host closed the connection]
Maylay has quit [Excess Flood]
freemint has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
Maylay has joined ##openfpga
Maylay has quit [Excess Flood]
Maylay has joined ##openfpga
nrossi has joined ##openfpga
Maylay has quit [Excess Flood]
Maylay has joined ##openfpga
Maylay has quit [Excess Flood]
Maylay has joined ##openfpga
Maylay has quit [Excess Flood]
Maylay has joined ##openfpga
Maylay has quit [Quit: No Ping reply in 300 seconds.]
Maylay has joined ##openfpga
Maylay has quit [Ping timeout: 265 seconds]
Maylay has joined ##openfpga
<mithro>
The more and more I get involved with ASIC design, the more and more I'm surprised we have working devices at all. Not because of physics, not because of the complexity in dealing with 10 million transistors. More because we barely make working software with current best development practices, yet EDA and ASIC people are still using 1980 "best" practices....
Maylay has quit [Excess Flood]
Maylay has joined ##openfpga
<sorear>
are current best development practices actually better, or do we just think they're better because they're current best development practices
<sorear>
there was a lot of working software already in the 60s
Maylay has quit [Excess Flood]
Maylay has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
Maylay has quit [Remote host closed the connection]
whitequark has quit [Ping timeout: 252 seconds]
whitequark has joined ##openfpga
<pie_>
sorear: probably using several of the current best development practices
<pie_>
...tbf stacks were simpler too?
<pie_>
that we dont use
<pie_>
(i mean, idk)
freeemint has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
Maylay has joined ##openfpga
<TD-Linux>
as a retro computing connoisseur, I can attest that software was just as bad then
Bike has quit [Quit: Lost terminal]
Maylay has quit [Quit: No Ping reply in 300 seconds.]
Maylay has joined ##openfpga
<pie_>
oops
<OK_b00m3r>
sorear: things like easily accessible high quality version control do make a difference, i believe. before 2000 that wasn't anywhere near as accessible. and I can name quite a few other things that have changed in 30 years
<OK_b00m3r>
however, we are still in a deep crisis... :D
<OK_b00m3r>
but not for want of good tools
<OK_b00m3r>
for want of good culture and organisational maturity imho
rohitksingh has quit [Ping timeout: 240 seconds]
freeemint has quit [Ping timeout: 250 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 250 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
OmniMancer has joined ##openfpga
m4ssi has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
<whitequark>
it's not like tools can't drive culture
<whitequark>
accessible tools often enable cultural shifts. you've mentioned it yourself: version control
<whitequark>
package managers enable code reuse
<whitequark>
daveshah: so i'm thinking about maybe reverse engineering iceMACH 4A5
freeemint has joined ##openfpga
marcan has quit [*.net *.split]
awordnot has quit [*.net *.split]
simeonm has quit [*.net *.split]
fseidel has quit [*.net *.split]
pakesson_ has quit [*.net *.split]
Mimoja has quit [*.net *.split]
danilonc has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
GityUpNow has quit [*.net *.split]
duck2 has quit [*.net *.split]
fseidel has joined ##openfpga
simeonm has joined ##openfpga
awordnot has joined ##openfpga
Mimoja has joined ##openfpga
pakesson_ has joined ##openfpga
danilonc has joined ##openfpga
kbeckmann has joined ##openfpga
duck2 has joined ##openfpga
GityUpNow has joined ##openfpga
marcan has joined ##openfpga
freeemint has quit [Ping timeout: 240 seconds]
<juri_>
too many tools are preventing our culture from gaining power. with each of us on different dev boards with different tool, all we are able to do is consume, then buy a different one, and consume again.
<mwk>
um what?
Bob_Dole has joined ##openfpga
ZombieChicken has quit [Ping timeout: 268 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 265 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 252 seconds]
<OK_b00m3r>
whitequark: Yes, agreed
<OK_b00m3r>
whitequark: but tool existence alone isn't enough, ime
<zignig>
OK_b00m3r: those tools take time to mature , the important thing is to try them out and see what you can build.
<zignig>
building more tools with those tools is where the momentum comes from.
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 245 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 245 seconds]
freeemint has joined ##openfpga
freeemint has quit [Ping timeout: 245 seconds]
freeemint has joined ##openfpga
freeemint has quit [Remote host closed the connection]
freeemint has joined ##openfpga
freeemint has quit [Remote host closed the connection]
freeemint has joined ##openfpga
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 268 seconds]
<OmniMancer>
daveshah: did you get the indexing suite headers from ms bond?
<daveshah>
Yeah
<daveshah>
I think so
<whitequark>
oh oops i blinked
<whitequark>
daveshah: about iceMACH 4A5: what do you think would be the best approach? I'm not sure how fuzzers would work for CPLDs
<whitequark>
but that might be just because I don't fully understand how they work for FPGAs
<daveshah>
I guess rqou/azonenberg have experience there
<daveshah>
I guess a lot of the high level techniques are quite similar
<whitequark>
right. there are some muxes in it that'd be easy to enumerate, and some I don't really know how to get at
<azonenberg>
daveshah: i had comments in the coolrunner bitstream which helped a lot (it's ascii text based)
<whitequark>
cross-PLA connections being one of them
<azonenberg>
i also did a fair bit of silicon RE
<azonenberg>
to figure out the crossbar config
<whitequark>
ok that's cheating. I don't even have any of the silicon
freeemint has quit [Ping timeout: 250 seconds]
<daveshah>
Stuff like FF and IO config would be the same as an FPGA fuzzing wise too
<whitequark>
they have something weird going on with the cheapest device in series
<whitequark>
and something else weird going on with the "IO:macrocell ratio"
<whitequark>
there's also something really weird going on with "asynchronous macrocell mode", which lets you use latches but reduces the amount of product terms
<mwk>
d-do they simulate a latch with combinatorial logic
<whitequark>
you don't even need a storage element enabled, and in fact comb functions should use the "synchronous macrocell mode"
<whitequark>
I have no idea?
<sorear>
all I’m looking for is a cpld with the ability to represent all 128-input boolean functions, is that such a hard problem? /joke
<whitequark>
Fig 5b suggests that... maybe?
<whitequark>
I... think they reroute the product term that goes to the "asynchronous preset" signal to the FF clock in "asynchronous mode"
<whitequark>
but I have no idea why that would cut two product terms off the preceding comb function
<OmniMancer>
seems weird
<OmniMancer>
latches count as async?
<OmniMancer>
daveshah: does the DatabasePath actually get used for anything?
Marex has quit [*.net *.split]
moho1 has quit [*.net *.split]
forrestv has quit [*.net *.split]
dfgg has quit [*.net *.split]
<whitequark>
I wonder if the M4A-32/32 device (the cheapest one) is more like two of their PALs strapped together
moho1 has joined ##openfpga
forrestv has joined ##openfpga
dfgg has joined ##openfpga
Marex has joined ##openfpga
moho1 has quit [*.net *.split]
Marex has quit [*.net *.split]
forrestv has quit [*.net *.split]
dfgg has quit [*.net *.split]
<whitequark>
hm
<whitequark>
the 66-bit blocks in the JED file are probably the product terms
moho1 has joined ##openfpga
Marex has joined ##openfpga
dfgg has joined ##openfpga
forrestv has joined ##openfpga
<whitequark>
there are 4 comb inputs per macrocell and 1 OE per two macrocells, and I see 11 rows per macrocell pair
<OmniMancer>
I am sometimes confused why some of the tools decide to use the SoP logic expression for some LUTs and just bits or numbers for others
<whitequark>
wait is it literally laid out the same as the datasheet figure?
<whitequark>
they even helpfully numbered the rows
<OmniMancer>
what is an OE?
<whitequark>
output enable
<OmniMancer>
thanks
<OmniMancer>
I thought it might be that but the usage felt weird
<azonenberg>
whitequark: which cpld is this?
<whitequark>
ispMACH 4A
<whitequark>
the last true 5V CPLD still in production and not NRND
<whitequark>
I was shocked to find out there are any left
<q3k>
one of the products i worked on used an ispMACH4000Z, should've reverse engineered it instead of spending time on dealing with garbage windows software for it
<whitequark>
i think 4000 and 4A *might* be similar internally?
<whitequark>
i still can't figure out if 4A is a part of 4000 series or not
<whitequark>
i'm not sure if lattice can figure it out either
<q3k>
sounds about right
<whitequark>
would be neat if they are similar
<q3k>
fwiw i do have a working isplever-in-wine-in-docker setup if you want it for fuzzing
<whitequark>
because 4000Z isn't even "mature"
<whitequark>
oh i have isplever working in wine
<whitequark>
just not synplify
<whitequark>
but i don't really care about synplify
<whitequark>
i can just generate EDIF, probably even with yosys
<q3k>
i don't remember if this used synplify or LSE or what, but it does verilog-to-jedec
<whitequark>
it has both synplify and lse but i think the mach series can only use synplify
<q3k>
this certainly worked with the 4000Z
<whitequark>
it's probably something fucked about my wine setup
* whitequark
looks at the datasheet
<whitequark>
I... can't tell if they have the same design and the docs are just gratuitously changed, or if it's a different device
<whitequark>
they're definitely similar
<whitequark>
ok no, the term sizes are very different
<whitequark>
the basic architecture seems almost identical
<whitequark>
oh, the new docs are way more coherent
<whitequark>
ohhhhh
<whitequark>
I figured out what the heck "asynchronous mode" is
<whitequark>
so the register can be configured as a DFF or DLATCH
<OmniMancer>
and asynch is a latch?
<whitequark>
no
<whitequark>
I think the async mode only gives you SR and JK latches
genii has joined ##openfpga
<OmniMancer>
makes some sense
<mwk>
JK isn't a latch though, it has to be a flip-flop
<OmniMancer>
is a latch not composed of an SR flip-flop?
<mwk>
no
<whitequark>
mwk: I... think they actually mean a JK latch
<whitequark>
like, they say it oscillates with J=K=1
<whitequark>
"the use is inadvisable"
<mwk>
whitequark: ... what
<mwk>
"inadvisable" — that I can agree with
<whitequark>
The flip-flop can be configured as a D-type or T-type latch. J-K or S-R registers can be synthesized. The
<whitequark>
primary flip-flop configurations are shown in Figure 6, although others are possible. Flip-flop functionality
<whitequark>
is defined in Table 8. Note that a J-K latch is inadvisable as it will cause oscillation if both J and K inputs
<whitequark>
are HIGH.
<mwk>
alright
<mwk>
I take it back
<mwk>
JK can be a latch, if you're stark raving insane
<mwk>
also uh
<mwk>
"T-type latch"
<mwk>
it's... at least JK latch has some sense as long as you're not actually using both J and K at once, but a "T latch"?!?
<whitequark>
I have no idea?
<OmniMancer>
for some reason I associate flip-flop with SR-latch
<whitequark>
I think they mean TFF when they say T-latch
<whitequark>
the storage element is described as ... hm
<whitequark>
ok you know what
<whitequark>
it might actually be a T latch
<whitequark>
what the fuck is a T-latch
<mwk>
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<mwk>
whitequark: well umm by obvious analogy
<mwk>
it's a thing that keeps its value when gate is 0
<mwk>
and oscilates like mad when it's 1
<azonenberg>
lolol
<whitequark>
well yes but
<whitequark>
why
<whitequark>
I *have* to get some silicon now
<mwk>
my thoughts exactly
<OmniMancer>
mwk: for all your metastability needs?
<OK_b00m3r>
:)
<OK_b00m3r>
Precision Metastability Source
<OmniMancer>
Need a programmable logic device that contains a pulse generator that generates pulses specifically just long enough to half set an RS-latch in the device
<sorear>
isn’t the oscillaty part of a PLL just a T latch
<OmniMancer>
sorear: I think its usually a ring oscillator
<OmniMancer>
an odd length loop of inverters?
<azonenberg>
that's a DPLL (digital PLL)
<azonenberg>
a normal PLL is usually an L-C tank or similar based VCO
<OmniMancer>
yes assuming a digital one not a radio one
<azonenberg>
with an analog charge pump to bump the voltage up or down
<azonenberg>
a lot of high end serdes at least use LC plls
<azonenberg>
less jitter i think
<OmniMancer>
ah, interesting
<whitequark>
azonenberg: wait what
<whitequark>
I assumed a DPLL is a fully synchronous circuit
<OmniMancer>
not it uses a ring oscillator as its VCO
<azonenberg>
There's multiple ways to do those too
<OmniMancer>
indeed
<azonenberg>
for example a spartan6 DCM is, afaik, a PLL using a ring oscillator but it adjusts the oscillator period by just muxing inverter stages in and out of the delay line
<OmniMancer>
whitequark: how would you multiply frequencies with a fully synchronous circuit?
<azonenberg>
so you get horrible jitter
<OmniMancer>
erg
<azonenberg>
i think you can get better results if you use some kind of bias voltage to adjust the inverter delay while having a fixed length chain
<OmniMancer>
AFAIK ring oscillators do function as VCOs but no direct experience
<azonenberg>
but my understanding is the most stable plls are lc based, or possibly a quartz resonator with a control voltage
<azonenberg>
OmniMancer: what i meant is, you can make it be a VCO, or you can have an all digital varaible speed ring oscillator
<azonenberg>
where you just change the number of taps in the loop
<azonenberg>
the latter is compatible with a pure digital process using foundry cells only, but jitters way worse
<whitequark>
OmniMancer: you oversample
<azonenberg>
whitequark: that's basically a software PLL then
<whitequark>
yes
<whitequark>
I was misusing the term "DPLL" then
<azonenberg>
using an NCO derived from the refclk
<azonenberg>
but you can't make a pll running faster than your reference that way
<azonenberg>
all you can do is phase lock to an external input +/- one cycle of your input clock
<cr1901_modern>
azonenberg: You need a varactor for the "C" part of the LC in a VCO
<OmniMancer>
whitequark: I mean you have a clock at N Hz, how do you generate a clock at 2*N Hz with no other inputs with a fully synchronous circuit?
<azonenberg>
OmniMancer: actually i think you can frequency double using pos/negedge ffs and some combinatorial xors
<azonenberg>
but i wouldnt recommend it :p
<OmniMancer>
that sounds like a dubious prospect, but I will give you that
<whitequark>
OmniMancer: you can't
<whitequark>
it's not a frequency multiplier, it's a phase locked loop
<OmniMancer>
Sorry, I see above the differing interpretation of DPLL
<azonenberg>
yeah basically its just a question of what your resonant element is
<azonenberg>
If it's an NCO, you can be synchronous
<OmniMancer>
well phase locked loops are often used to do frequency multiplication
<cr1901_modern>
My understanding is that a DPLL has an analog VCO- it's only the phase detector that differs (ADPLL has an NCO)
<OmniMancer>
I have done a PLL like structure in synchronous logic with NCOs for doing MSK demodulation for my final year uni project
<whitequark>
cr1901_modern: interesting
<OmniMancer>
yea you can build different phase detectors if you only care about square waves
<cr1901_modern>
An analog PLL uses a multiplier and relies on one of the trig identities to extract the phase difference. A DPLL uses an edge detector (XOR, or Phase-Freq Detector)
<OmniMancer>
yes multiplier sin phase detector
<whitequark>
azonenberg: any ideas for REing the switch matrix of M4A?
<OmniMancer>
analog PLL used for carrier recovery usually also includes a non-linear function on the input to make the carrier obvious
<cr1901_modern>
Yea I don't remember how Costas PLL works
<cr1901_modern>
if that's what you mean
<OmniMancer>
yea I think what I did was some kind of Costas loop
<OmniMancer>
though that is also recovering clock as well I think
<azonenberg>
whitequark: not without spending a bit of time reading about the architecture
<OmniMancer>
oh no it just does carrier, but the variant I did was also producing the clock I think
<OmniMancer>
And I think Costas PLLs can be used as demodulators themselves
<whitequark>
azonenberg: there is nothing interesting in the docs besides "100% routability"
emeb has joined ##openfpga
<azonenberg>
whitequark: Hmmm
<azonenberg>
do they mean every subset of inputs can be routed to some outputs? or every input can be routed to every output
<azonenberg>
my guess is its a sparse crossbar, full ones are huge
<whitequark>
>— Central, input and output switch matrices for 100% routability and 100% pin-out retention
<whitequark>
is what it says
<whitequark>
the input and output switch matrices are fully described
<azonenberg>
are there actually 3 crossbars?
<azonenberg>
ah ok
<azonenberg>
so there are, but you only have to RE one
<whitequark>
output switch matrix is a 1:8 mux for every IOB
<azonenberg>
Is this a PLA based cpld like coolrunner?
<whitequark>
input switch matrix is 2 or 3 1:2 muxes depending on sub-family
<azonenberg>
sources -> matrix -> and array -> or array?
<azonenberg>
with and/or both programmable?
<whitequark>
nope
<azonenberg>
so fixed or array and programmable and?
<whitequark>
multiple choices for fixed or array
<azonenberg>
ok
<azonenberg>
So i guess the first thing to do is, generate a bunch of random test bitstreams
<whitequark>
there's also a cascade function
<azonenberg>
and try to figure out which crossbar channel is used for each thing
<whitequark>
oh it says that in the jed
<azonenberg>
basically, you want to enumerate a subset of the possible paths through the crossbar
<whitequark>
NOTE Interleaved Central Switch Matrices for BLOCKS 0 and 3 *
<azonenberg>
So 0 and 3 share common inputs
<azonenberg>
then you have left-going and right-going outputs
<azonenberg>
that sounds exactly like coolrunner
<azonenberg>
my conjecture is that the routing fabric will be quite similar
<azonenberg>
you're going to have a big bus on the top layer
<azonenberg>
via-programmed muxes selecting N of those K inputs
<azonenberg>
then one-hot pass transistors to enable one of those N each to left and right
<azonenberg>
and lol
<azonenberg>
that drawing looks like it's the exact physical die floorplan
<whitequark>
I am pretty sure it is
<OmniMancer>
daveshah: thanks for the update, you might want to change the message in the .h files to reference the subset of COPYING instead of LICENSE?
<azonenberg>
while i'm not expecting an identical architecture i think it's going to be close enough to give you some good insights
<whitequark>
azonenberg: neeat
<whitequark>
re crossbar: yes, I figured that's approx how it worked
<whitequark>
ice40 has this sort of architecture too
<azonenberg>
my point is, this is bitstream mapped directly to silicon for a similar design
<azonenberg>
really big parts might have a multilevel tree
<azonenberg>
but your cpld is about the size of a coolrunner
<azonenberg>
So basically what you need to do is, if you want to black box it
<whitequark>
that's the second smallest part
<azonenberg>
start generating random bitstreams and collecting data
<whitequark>
their biggest parts don't fit on one page
<whitequark>
they have to use "detail A" on block diagram
<whitequark>
512 macrocells, hm
<azonenberg>
you want to make a big list, for each possible input to the crossbar
<azonenberg>
what crossbar outputs has it been seen used in?
<azonenberg>
or transpose the matrix... for each crossbar output, what inputs have you seen there?
<azonenberg>
And, for each in-out combination, what was the bitstream coding?
<azonenberg>
you can design targeted fuzzing cases later on, right now you just want to find a subset of the legal paths to figure out the architecture
dh73 has joined ##openfpga
<whitequark>
wait
<whitequark>
what the fuck
<azonenberg>
?
<whitequark>
it writes a report where it describes the configuration of every crossbar mux
<azonenberg>
Why reverse when the tools don't keep secrets? lol
<azonenberg>
does not surprise me, the coolrunner reports were extremely verbose too
<whitequark>
hm, so I can easily pin a signal to one specific CSM input
<azonenberg>
Yep
<azonenberg>
Pinning the outputs is where it gets hard
<azonenberg>
i gave up on that on coolrunner after figuring out maybe 1/3 of the matrix by looking at bitstreams, i couldnt figure out how to craft pathological enough configurations to generate the last few
<whitequark>
oic
<azonenberg>
I knew the full configuration table was in an ISE data file but for EULA reasons i didnt want to use that
<azonenberg>
so i needed a cleanly derived source for the data
<azonenberg>
and i was teaching the hardware RE class at the time
<azonenberg>
so i had an obvious path forward
<azonenberg>
at the time i also didn't understand the sparse crossbar structure
<azonenberg>
once i looked at the layout it made total sens
OmniMancer has quit [Quit: Leaving.]
<whitequark>
hm
<whitequark>
azonenberg: so I think I understand how half of it worsk
<whitequark>
on the 64/32, there are 33 muxes per PLA, 66 interleaved muxes total, the muxes are 9:1, there are 9 rows per CSM block in JED file
m4ssi has quit [Remote host closed the connection]
<whitequark>
so the JED file is structured as (66+14)x9
<whitequark>
it looks like there are in fact 33 one-hot muxes per PLA in each CSM block
<azonenberg>
Nine makes perfect sense
<azonenberg>
because the switch matrix is 98 inputs
<whitequark>
what I don't understand is
<azonenberg>
So i'm gonna hazard a guess that you have ground, two clocks, and 96 signals for a total of 99 inputs to the fabric
<whitequark>
what the heck is the 14x9 block doing?
<azonenberg>
The 99 inputs are divided into 9 groups of 11 signals
<azonenberg>
nine 11:1 mask programmed muxes as the first level of the tree, then a 9:1 one hot mux for the second
<azonenberg>
as soon as i saw the 98 inputs i saw the symmetry there, 99 is a nice number for a 2 level mux tree
<azonenberg>
The 14x9 is a big question, i agree
<whitequark>
it appears to be organized as 7x2x9
<whitequark>
hmmm
<whitequark>
maybe that's the input switch matrix?
<whitequark>
it has 3 inputs per macrocell pair
emeb has quit [Quit: Leaving.]
<whitequark>
the input switch matrix needs at most 1 bit per input, as described
<whitequark>
>As discussed above, it is impossible to over-charge or over-discharge the programming cell since
<whitequark>
the mechanism is self-limiting.
<whitequark>
oh
<whitequark>
oh Lattice bought Vantis from AMD
<whitequark>
ok that explains why the datasheets for M4 and MACH4000Z are totally different
<whitequark>
>The same fitter technology included in MACHXL software is seamlessly incorporated into thirdparty tools from leading CAE vendors such as Synario, Viewlogic, Mentor Graphics, Cadence and
<whitequark>
MINC. Interface kits and MACHXL configurations are also available to support design entry and
<whitequark>
verification with other leading vendors such as Synopsys, Exemplar, OrCAD, Synplicity and Model
<whitequark>
Technology. These MACHXL configurations and interfaces accept EDIF 2.0.0 netlists, generate
<whitequark>
JEDEC files for MACH devices, and create industry-standard SDF, VITAL-compliant VHDL and
<whitequark>
Verilog output files for design simulation.
<whitequark>
which were spun off as Vantis and which Lattice then bought
<whitequark>
cr1901_modern: hahaha, the fitter for M4A is apparently a direct descendant of the fitter made by AMD in the early 90s. it runs on DOS, of course
<whitequark>
I think they just rebuilt it for win32
<whitequark>
I wonder if you could just give it the data files from ispLEVER
<cr1901_modern>
At least you're having good luck w/ the lineage of the M4A. Both ECP5 and Mach use NeoCAD format, and AFAICT (daveshah feel free to correct me), it's been trial and error operating on those files since it's not documented at all.
<whitequark>
MachXO?
<cr1901_modern>
yes, MachXO{1,2,3}
<whitequark>
MACH seems to have absolutely nothing in common with MachXO