<pepijndevos>
I think I only updated it to my understanding of the CRC, the rest is copied from dave IIRC. He looked at Gowin before I started my internship. The amount of "like ECP5" I've seen during this project is almost comical.
<pepijndevos>
Usually when I'm completely puzzled by something I ask him how ECP5 does it... and that's generally a pretty good initial guess for how Gowin works.
<pepijndevos>
(if you have anything to add to that file from your experience, highly appreciated of course. you know much more about the jtag and crc bits than me)
<trabucayre>
Yes I've seen this page... But I need to reread :)
<trabucayre>
unfortunatly number of frames is the real number of frame in the bitstream, not for the FPGA
<trabucayre>
This why I have used idcode to hardcode correct size
<trabucayre>
Maybe I've somewhere some note about header... The challenge is to find where :)
<pepijndevos>
Lofty, I'm writing some documentation about the timing db... and I'm trying to reconstruct our reasoning about the order of timing info... and failing
<pepijndevos>
so for LUT A to F 1 and 3 vs 2 and 4 are identical, but in the dff 1 and 2 vs 3 and 4 are identical
<pepijndevos>
... how did you arrive at that order?
<pepijndevos>
that's the thing I want to document
<pepijndevos>
ah... I guess for LUT only the output matters, while for dff only the input matters? hmmmm, bit murky in my brain
<pepijndevos>
Lofty, ?
<Lofty>
Pretty much, yeah, pepijndevos
<Lofty>
To put it another way: what's the combinational output of a flop?
<Lofty>
It doesn't have one, by definition
<pepijndevos>
right
<Lofty>
So the variation *must* be the input
<Lofty>
Which leaves the LUT timing as dependent on the output by definition
<Lofty>
...
<Lofty>
by elimination
<Lofty>
I did not get much sleep last night
<pepijndevos>
yea... by elimination I'd agree, but combinational it definitely could have a different Rx Lx time
<pepijndevos>
I guess because it depends on the actual lookup table they just took the worst case there, because you cannot at compile time reason about that probably?
<pepijndevos>
Anyway, elimination is good enough for me
<Lofty>
Yeah, I'd imagine so
<pepijndevos>
I do think you got R/F backwards because 0.3 is the lower number and I'd expect it to be falling edge
<Lofty>
...No?
<Lofty>
But, eh, you're the one with a master's degree
<pepijndevos>
eh... a degree does not guarantee correctness. Why do you think the lower number is rising edge?
<Lofty>
I'd think the capacitance in the transistors having to discharge would make it slower
<pepijndevos>
So... okay let's imagine the depletion layer significantly changes the capacitance, but... hmm the integral of the capacitance during a transition is the same in both directions, so I don't think it matters
<pepijndevos>
But well, a bigger VGS increases the depletion region, so decreases the capacitance, and the PMOS is bigger so has bigger capacitance. So... when the input is low, the PMOS has the smallest capacitance, so according to that theory... yea for some given current the dv/dt is higher at the low end?
<pepijndevos>
Anyway, I think the dominant effect is that a PMOS is like 1/3 as effective as an NMOS, so you'd need to make it 3 times as big to have the same rise time, but yea this increases total capacitance and decreases speed, so I think what they do is compromise and do like a 2x PMOS to have it kinda in the same ballpark and decrease the total capacitance a bit.
<Lofty>
Well, LUTs are generally SRAM connected to pass transistors, rather than like multiplexers
<Lofty>
But yeah
<Claude>
Now throw cross conduction and the miller effect into it :)
<pepijndevos>
Be my guest, I'd be entertained :))
<Claude>
Depending what the goal of the process is (speed or low power) this something which definitely needs to be considered for CMOS
<pepijndevos>
Miller effect is just that the capacitor "appears bigger" due to feedback, right? Would that have an effect on rising vs falling edge? Hmmm
<Claude>
Yes , because when the high side pmos is still conducting (due to the artificially increased gate capacity) and the low side nmos is already in the analog mode region a large ammount of current flows
<pepijndevos>
Not sure I follow
<Claude>
But that applies more to output stages ..
<Claude>
Switching from 1 to 0 takes longer usually on outputs
<Claude>
So the falling edge timing on inputs needs a bit more relaxed
<Claude>
But I not that sure on CMOS actually .. we had that on BCD process on high voltage ASIC which probably looked way different. So ignore my babbling
<pepijndevos>
I'd like to understand though. The thing you were saying where a large amount of current flows
<pepijndevos>
Are you talking about an inverter during a falling edge, or some other scenario?
<kbeckmann>
pepijndevos: saw your tweet about fuzzing and that it takes more time etc. do you need some computing power? i have a threadripper (32core) that mostly idles right now. happy to run some stuff for you.
<Claude>
Ah ok , there is a certain ammount of current needed to charge/discharge the totem pole gate capacity. The miller effect makes the high side switch even slower than it already is (pmos ) . So while the nmos is already in its gate threshold region the pmos is still conducting
<pepijndevos>
kbeckmann, nah it's fine. Thanks though :)
<kbeckmann>
cool
<pepijndevos>
Am I wrong in assuming that given reasonable layout, the gate voltages on both devices are the same?
<Claude>
This varied a lot over temperature and process
<Claude>
So there is a certain band in which both conduct or start to conduct
<pepijndevos>
band... in time or input voltage?
<Claude>
Voltage
<pepijndevos>
Like... statically. okay yea
<pepijndevos>
Yea so you get some shoot through current during the switching where both devices are on
<pepijndevos>
or you called it cross conducting I think?
<Claude>
The edge slope and gate capacitance give the time component
<Claude>
Yes we said cross conduction to it
<pepijndevos>
Okay, yea I get there will be cross conduction during the transition... but why will it make the falling edge slower?
<Claude>
Because the high side output switch will conduct longer than its gate drive input signal
<Claude>
So the slope of the output , falling , is longer too
<Claude>
At least on BCD :) because of that , it was an motor drive ASIC, we had to add a lot of deadtime in software for the high side switch
<Claude>
Otherwise the external output h-bridge was "cross conducting" . But the more I think about it , it's probably really not relevant for an CMOS FPGA lut input :) hence just ignore my babbling
<pepijndevos>
yea, I think I get it but also... I kind of don't fundamentally get it. Like... I'm just trying to understand where the delay comes from... sure, there is capacitance, but say you instantaneously would impose a voltage at the gate, would there be a delay? No right? So is the secret in the parasitic inductance that connects the gates? Else I can't see how the PMOS would be "slower"
<pepijndevos>
Ah well... I guess I should do some simulations to see what happens to really understand it.
<pepijndevos>
Practically for now the main thing I care about is not getting the timing backwards haha
<pepijndevos>
So yea if this stuff only applies to BJT power electronics and stuff, and my original idea is in the first order kinda correct, I'll just roll with it for now.
<Claude>
Could , and likely it is, that I got it wrong back then :)