Who from this crowd is going to be at FSiC 2026 (https://wiki.f-si.org/index.php/FSiC2026) in Ljubljana in three weeks? I see that at least @Leo Moser (mole99), @Simi, @Chips4Makers aka Staf Verhaegen and myself are giving presentations there. Anybody else presenting or attending?
I'm presenting work I did on a custom SRAM register file on sky130 and the test chips are currently with fedex which was supposed to delivery today but delayed it to tomorrow ... result of which will decide if my talk is going to be a post-mortem or not
Ha, very nice, did not know you're from here Yes, Christian from Winfab brought me the bonded samples on Friday. They are a little bit protective of their bonding machine at the moment, but as far as I know it's not used too much. And they seem to be getting a new semi-automated one soon (for some definition of soon). Then there's probably more availability and you have a fallback if one is temporarily out of order.
Yeah, I studied there INGI then ELEC (was still FSA at the time). And worked for intopix (a ucl spinoff) even before it was spunoff and I so I was in Maxwell for a year or so and also did some odd jobs for Quisquater and FX
now that I'm no longer actively suffering from whatever that bread contained, let's hurry back to get this serializer worked on before anything is too late for it.
VCO core, with enough fingers to let me tap off a single-finger feed to a clock tree without this causing undue load, probably do be aiming at exactly the 2.5 GHz though, maybe probably better like 3 GHz to handle a bit of layout parasitics and process variation.
Then clock buffer.
Then a latch fast enough to accomplish a DIV2 off of this.
Then a mux2 at least that would act as the final MUX in a C2 arrangement.
Then draw at least a plain serializer MUX tree up to have a fallback to submit; the base clock buf cells should be sufficient speed.
After, see how much time is left,
and see how good an inductor would be needed to clock the input-multiplexed current-mode C4 MUX (the pseudo-nmos style architecture of it).
If success, try to make an inductor that's good enough for pulling off a C4 architecture.
If success, go and implement the C4 with FIR taps furnished at the CLK/2 level (i.e., C8).
If inductor trials not success, instead go for some FIR taps at still CLK/2.
Gave a lightning talk at the Chicago Python Users Group (Chipy)
Hard to talk about much of anything in 5 min, but figured I'd share
https://youtu.be/0ROkPEg5Jl8
VCO core, with enough fingers to let me tap off a single-finger feed to a clock tree without this causing undue load, probably do be aiming at exactly the 2.5 GHz though, maybe probably better like 3 GHz to handle a bit of layout parasitics and process variation.
Then clock buffer.
Then a latch fast enough to accomplish a DIV2 off of this.
Then a mux2 at least that would act as the final MUX in a C2 arrangement.
Then draw at least a plain serializer MUX tree up to have a fallback to submit; the base clock buf cells should be sufficient speed.
After, see how much time is left,
and see how good an inductor would be needed to clock the input-multiplexed current-mode C4 MUX (the pseudo-nmos style architecture of it).
If success, try to make an inductor that's good enough for pulling off a C4 architecture.
If success, go and implement the C4 with FIR taps furnished at the CLK/2 level (i.e., C8).
If inductor trials not success, instead go for some FIR taps at still CLK/2.
forward device's drain current density oscillating between approximately 16 and 72 A/m
namibj
VCO core, with enough fingers to let me tap off a single-finger feed to a clock tree without this causing undue load, probably do be aiming at exactly the 2.5 GHz though, maybe probably better like 3 GHz to handle a bit of layout parasitics and process variation.
Then clock buffer.
Then a latch fast enough to accomplish a DIV2 off of this.
Then a mux2 at least that would act as the final MUX in a C2 arrangement.
Then draw at least a plain serializer MUX tree up to have a fallback to submit; the base clock buf cells should be sufficient speed.
After, see how much time is left,
and see how good an inductor would be needed to clock the input-multiplexed current-mode C4 MUX (the pseudo-nmos style architecture of it).
If success, try to make an inductor that's good enough for pulling off a C4 architecture.
If success, go and implement the C4 with FIR taps furnished at the CLK/2 level (i.e., C8).
If inductor trials not success, instead go for some FIR taps at still CLK/2.
16 half speed latches @ approx 100 mW each + 4 full-speed latches @ approx 400 mW each + 4 full-speed MUX2 @ somewhere_between_those each, so a "total" of 3.6 ~ 4.8 mW, not counting the clock feed (quadrature phases at both full clock and half clock), and not counting the output predriver limiting amplifier(edited)
I designed some silicon lol.
Maybe I will talk about it someday, this was more of an exercise than something I care about.
A portion of the above was to understand the toolchain so I could make this docker based starter thing.
Some people have asked me for it, so now it exist @carlfkhttps://github.com/evezor/wafer_space_docker_based_starter_kit
If someone would mind giving it a quick overview, that would be lovely.
Thanks and hope it's helpful!
@needsadrink|woke Tim is asking me to look into getting the old Skywater masks from the google mpw run.
Would you mind giving me a little assistance there? Please DM me.
Thanks
I'll ask and if I'm lucky I'll figure out how to remote into my workstation from the office
Would be awesome for the heatwave situation.
Should just need a sufficiently effective codec to keep my sanity despite the inevitable lag.
Extension for Visual Studio -
Verilog Extension for Visual Studio. (classifier extension).
Implements the Verilog Language Extension allowing user-definable
keyword colorization. Useful for FPGA, ASIC and other RTL development.