<pie_>
what do you call the cylindert that blow from toomuch current?
<pie_>
well not literally of course
<azonenberg_hk>
fuse
<azonenberg_hk>
And older config bits were literally that
<pie_>
ok good, i just ahvent been around english speaking people for too long :P
<pie_>
so i was unsure
<pie_>
yeah
<azonenberg_hk>
you'd apply like 12V or something to blow a link
<azonenberg_hk>
here's a closeup of some random gates, no idea what that part of the chip does
<pie_>
its gonna be neat for me to label all this stuff but i need to get into fab material lel
<azonenberg_hk>
but for example you can see the rightmost gate
<azonenberg_hk>
in the second row from the bottom
<azonenberg_hk>
is an inverter
<azonenberg_hk>
metal is gone but the transistors are visible
<azonenberg_hk>
nmos at top, pmos at bottom
<azonenberg_hk>
you can tell because the pfet is a wider channel to make up for higher Rds(on)
<azonenberg_hk>
in analog stuff this rule doesnt always hold but in digital 99.99% of the time it does
<azonenberg_hk>
Coloration in these images is mostly interference fringes in the glass layer, it's of no real use in RE other than to provide contrast
<azonenberg_hk>
white layer is poly, brownish is the actual transistors
<pie_>
btw something i havent read up on yet thats been bothering me
<azonenberg_hk>
then the red and blue background stuff is residue from the isolation oxide that wasnt fully etched off
<pie_>
poly vs monocrystalline silicon
<pie_>
why do you need one or the other type
<azonenberg_hk>
Monocrystalline is pretty much the only option for transistor channels, i dont understand all of the details of the physics
<azonenberg_hk>
but i think crossing grain boundaries messes things up
<azonenberg_hk>
And some properties of current flow work better along one crystal lattice axis or another
<pie_>
i think i read that the wafer is monocrystalline and you add poly with epitaxy for something or somethingÜ
<pie_>
_
<azonenberg_hk>
No
<pie_>
cant find my _
<pie_>
damn question mark lol
<azonenberg_hk>
the wafer is monocrystalline
<azonenberg_hk>
Epitaxy produces a monocrystalline layer of some material, which need not be silicon
<azonenberg_hk>
Poly is normally deposited by LPCVD of SiH4 plus an excess of O2
<azonenberg_hk>
the plasma dissociates the silane and you get SiH4 + 2O2 -> SiO2 + 2H2O
<azonenberg_hk>
sorry that's for oxide
<azonenberg_hk>
For poly you do SiH4 but no O2
<azonenberg_hk>
i forget if there's something to react with the H4 or if you just vent it as hydrogen gas
<azonenberg_hk>
In any case, what happens is you start with a few random atoms of silicon depositing on the gate oxide
<azonenberg_hk>
then as more stuff hits it it grows into crystals
<azonenberg_hk>
but since multiple crystals form simultaneously across the surface you get a polycrystalline material
<pie_>
wiki says "The monocrystalline form is used in the semiconductor device fabrication since grain boundaries would bring discontinuities and favor imperfections in the microstructure of silicon, such as impurities and crystallographic defects, which can have significant effects on the local electronic properties of the material. "
<azonenberg_hk>
My understanding is that the only reason poly-si is used for gates is that it's impractical to deposit a layer of monocrystalline silicon on top of a glass layer
<pie_>
so i guess its so that you dont have half a transistor behaving one way or half a gate behaving one way the other half another way
<azonenberg_hk>
in fact even poly has too high a resistance for most purposes
<azonenberg_hk>
so gates are normally made of poly with a metal silicide (e.g. cobalt silicide) on top of it
<azonenberg_hk>
It has higher electrical resistance than poly and is thus inferior for this application
<azonenberg_hk>
Amorphous silicon (non-crystalline, or ultra-tiny crystals a few atoms across) can be deposited by, i think, sputtering of a piece of silicon
<pie_>
i didnt know mono has lower R
<pie_>
isnt undoped Si an insulator regardless?
<pie_>
well hold on for a second
<azonenberg_hk>
Yes, but doped poly-si has lower resistance than doped a-si
<azonenberg_hk>
but higher than doped monocrystallined
<pie_>
ok
<azonenberg_hk>
also fyi all of the images i linked are CC-BY, copyright me
<azonenberg_hk>
So use them for anything you want as long as you provide attribution
<pie_>
btw is MEMS manufacturing essentially the same?
<pie_>
azonenberg_hk, yeah i always make sure to provide credit
<pie_>
azonenberg_hk, any chance you could upload an svg with the PIC labeled? :/ i can do it my self but it will be faster if you do it :P
<pie_>
azonenberg_hk, just the "low"res picture
<azonenberg_hk>
but it's on my laptop in the US
<azonenberg_hk>
i have an annotated verison
<pie_>
ah, well thanks anyway
<azonenberg_hk>
soo... :p
<azonenberg_hk>
I'm in hong kong until friday
<azonenberg_hk>
if you youtube search for me speaking at S4x16 last january
<azonenberg_hk>
i think there should be a slide of the chip marked up
<azonenberg_hk>
that you can sanity check against
<pie_>
ill do it if i feel alive enough at the end of this lol
<pie_>
sleep is for people not interested in silicon
<pie_>
fill me with shards of sweet digital love
<pie_>
i need to get me a half-a-wall-filling die shot poster at some point :P
<pie_>
i love the variety in these pictures
<pie_>
is MEMS manufacturing essentially the same as "normal" silicon?
<pie_>
maybe of my first quantum computer after it hits the market :P
<pie_>
nah, i just dont know what this code hopping stuf fis
<pie_>
oh jesus even the letters are vector graphics not even fonts
* pie_
trying to translate vector diagrams extracted from pdf
<azonenberg_hk>
whitequark: So i now have bitstream support for the DCMP in DCMP mode (not PWM) with all config options
<azonenberg_hk>
however right now input is only supported from the DCMPREF and DCMPMUX blocks
<azonenberg_hk>
Next step will be adding a parallel output port to the counter blocks so i can feed counters to the DCMP input
<azonenberg_hk>
Actually before i do that
<azonenberg_hk>
i have support for a bunch of additional clock sources now that i implemented GP_CLKBUF
<azonenberg_hk>
so i should add support for feeding GP_CLKBUF to GP_COUNT*
<pie_>
what is the fab in IC fab short for?
<azonenberg_hk>
fabrication
<pie_>
but what about when you use it as a noun
<pie_>
oh god how do i translate these....metallization....im probably coining new terms here lol
<pie_>
i mean there are probably existing translations i just dont know them
<lain>
facricator
<lain>
...
<lain>
fabricator*
<lain>
I should wake up before I type
<pie_>
ah that works i think thanks
<pie_>
heh, i cant type even if im awake
<lain>
hehe
<lain>
hokay.. time to shower, then head over to the datacenter / office
<pie_>
time.....to die
<azonenberg_hk>
So if i am reading the greenpak docs correctly
<azonenberg_hk>
the spi can be input or output
<azonenberg_hk>
but not both at once
<azonenberg_hk>
thats a little funny
<azonenberg_hk>
you can't, say, read the adc and write the pwm
<azonenberg_hk>
in the same bitsteam
<MikeFair>
azonenberg: that's kind of odd; the SPI thing is "wrong" in the sense that one of SPI's touted features is full duplex; but what a PWM and the ADC have to mutally exclude each other is a little funny
<azonenberg_hk>
MikeFair: yeah
<azonenberg_hk>
its not only half duplex
<azonenberg_hk>
it looks like the chip has to be programmed in the otp
<azonenberg_hk>
to either have the spi be read or write
<azonenberg_hk>
i have to test in hardware and confirm, the docs are a little confusing here
<MikeFair>
azonenberg: So it's like monoduplex?
<MikeFair>
err monoplex
<MikeFair>
that makes almost no sense at all; even if it's only occasional, you almost always have to get/send at least _some_ data from the slave
<azonenberg_hk>
yeah i am not certain yet but thats how it loks
<azonenberg_hk>
and lool
<MikeFair>
(that's assuming master mode; I think slave mode would be pretty much the same )
<azonenberg_hk>
This is slave mode
<azonenberg_hk>
it doesnt do master
<azonenberg_hk>
and, it looks like there is an option to use the raw spi data buffer as storage for old adc data
<azonenberg_hk>
iow disable spi and use that register to save the adc data as if you were sending it
<azonenberg_hk>
then diff that against current adc data with a DCMP
<MikeFair>
I've not worked with SPI much, but from what I've gathered, many devices have copied I2C's "send the reg address; the read/write" convention
<azonenberg_hk>
Not only that...
<azonenberg_hk>
I think there is a hack you can do
<azonenberg_hk>
to, with a cycle or two of latency
<azonenberg_hk>
use the spi data buffer (which supports parallel output to fabric)
<azonenberg_hk>
as a way to read the ADC to fabric
<azonenberg_hk>
or do parallel adc output to gpios
<azonenberg_hk>
i'll have to try this, lol
<azonenberg_hk>
on top of that, i think this means it will be possible to read a subset of the counter cells' internal state
<MikeFair>
azonenberg: That'd be an interesting thing to tie ADC output to LUT input
<azonenberg_hk>
normally the counters are black boxes that only output overflow flags
<MikeFair>
azonenberg: A voltage controlled state machine ;)
<azonenberg_hk>
But there is a parallel output from some counters to the DCMP and SPI blocks
<azonenberg_hk>
that doesn't go to fabric
<azonenberg_hk>
But if you can bounce it through the SPI core...
<azonenberg_hk>
i think you can get it to fabric
<azonenberg_hk>
not entirely sure what you'd do with that
<azonenberg_hk>
but i think it can be done
<MikeFair>
azonenberg: Do you use MyHDL?
<azonenberg_hk>
No
<MikeFair>
ok, just looking for opinions/consequences
<MikeFair>
I'd think that they'd have to make some way for bideirectional comms in the SPI implementation
<azonenberg_hk>
I dont think it exists due to routing limitations in the chip
<azonenberg_hk>
greenpak is extremely small and cost optimized
<MikeFair>
I assume I2C, being only clock/data and half-duplex doesn't have the same issue
<azonenberg_hk>
i'm already going all out crazy with some of the projects i've tried to fit in it
<azonenberg_hk>
greenpak5 has i2c and much better communications capability
<MikeFair>
azonenberg: Well there's minimal; then there's broken ;)
<azonenberg_hk>
but i want to finish dev of the tools for 4 first
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
azonenberg_hk has quit [Ping timeout: 260 seconds]
cr1901_modern has quit [Ping timeout: 260 seconds]
azonenberg_hk has joined ##openfpga
cr1901_modern has joined ##openfpga
massi has joined ##openfpga
X-Scale has quit [Read error: Connection reset by peer]
<rqou>
offtopic, asking again now that it's morning: anyone in the UK want to recommend a prepaid SIM card?
azonenberg_hk has quit [Read error: Connection reset by peer]
<pie_>
problem is i should already be done though lol
<pie_>
ah yeah i still gotta leech from your slides :P
<cr1901_modern>
Ahhh yes, a hackerspace in France has an Ikos Pegasus just sitting collecting dust :(
<cr1901_modern>
Forgot about that
<rvense>
my hackerspace has a through-plating rig that nobody really knows how to use
<MikeFair>
I was walking through some tutorials and quickly noticing how macro like many things are; in Verilog (iverilog specifically) will there be any preparser MACROS that could expand something like Mux_2_1 or Mux_4_1 to the right module? (Or would I have to run my own preparser thing fo that)
<MikeFair>
err Mux_4_2 i mean
<qu1j0t3>
.b 21
<qu1j0t3>
oops
* MikeFair
grins
* qu1j0t3
blushes
<azonenberg_hk>
MikeFair: i think you want parameters
<MikeFair>
azonenberg: Will those dynamically generate a module code block and test module?
<MikeFair>
I can see how Mux_2_1 and Mux_4_2 are not the same "module" they have different counts of in parameters (4 vs 7); but the logic for them seems like it could be autogenerated
<whitequark>
I *think* systemverilog arrays can do what you want
* MikeFair
is hoping to maximize laziness. :)
* MikeFair
is focusing on being grateful iverilog produces an error message at all over its content. :)
<cr1901_modern>
yosys error messages are really good as well. You get detailed error descriptions like "Syntax error"!
<whitequark>
... by design
<whitequark>
if you want good error messages, use iverilog
<cr1901_modern>
I know, it still doesn't make it less funny
<whitequark>
I mean, you can also implement nicer ones, which is (way bottom) on my TODO list
<whitequark>
error handling is the actual hard part of writing a compiler
<whitequark>
the rest is basically trivial
<MikeFair>
whitequark: Did you here of the "parrot" project?
<MikeFair>
whitequark: They make a bunch of grammar engine parsers for inventing new dynamic languages
<cr1901_modern>
I seem to recall you referenced a paper to impl error handling in pythonparser (to get "extra" information). But it's been a while...
<whitequark>
parser generators almost universally lead to bad errors that are impossible to tidy
<MikeFair>
I didn't think about it until earlier today; but they spend a good deal of time helping the language author easily test what state they are in and what kind of error message to produce
<azonenberg_hk>
cr1901_modern: i have been planning to write a linter for verilog
<whitequark>
there's an exception, menhir+merr for example, which brings good errors to LR(1) grammars, with some effort
<azonenberg_hk>
and improve yosys error messages
<azonenberg_hk>
they are not clifford's big priority
<MikeFair>
whitequark: This isn't a parser generator; it's a parser virtual machine
<whitequark>
Parrot has nothing to do with parsers, inherently, it's just yet another "one VM to rule them all" attempt
<whitequark>
it's closer to a JVM in the way it's (supposed to be) used
<MikeFair>
Well, like I said before, I'm focusing on the fact I can do this at all and being grateful for it
<whitequark>
the Parrot library also includes a bog-standard PEG parser generator
<whitequark>
(it's a generator because it outputs bytecode)
<whitequark>
PEG is a) slow b) pretty hostile to getting good error messages
<MikeFair>
whitequark: Well it's true, they have the VM under the hood; but it's focus on "interpretting your code" not compiling it -- so they have a great grammar engine for actually doing the parsing and executing it
<whitequark>
for some reason it is very "hip" these days
<azonenberg_hk>
whitequark: my main interest is not catching syntax errors
<azonenberg_hk>
it's catching stuff that is legal according to the LRM, but with high probability not what you intended
<azonenberg_hk>
aka, generating better warnings for catching unknown bugs is more of a priority than clearly explaining errors that correctly flag invalid syntax but do so in a difficult-to-read way
<whitequark>
azonenberg_hk: IME both are a large waste of time, but the latter is more of a waste of time for newcomers
<whitequark>
therefore I think the latter is more important if we're interested in promoting use of verilog
<whitequark>
(that's a big "if" :)
<azonenberg_hk>
whitequark: yeah but what i mean is
<azonenberg_hk>
i'd rather spend time fixing a syntax error that takes 10 minutes to identify
<cr1901_modern>
merr's approach skeeves me. Figure out what state of the parser given a bad program/error message? What happens if you get to an erroneous state but for the wrong reason/display the wrong error message?
<azonenberg_hk>
than let a bug slip into a release
<whitequark>
cr1901_modern: you're talking as if LR(1) was nondeterministic or something
<MikeFair>
azonenberg: There have definitely been a couple very obtuse and cryptic messages for me so far.
<cr1901_modern>
Well, TIL what a NFA is
<MikeFair>
always @(x,y); This essentially means that the code follwed by always statement will run ONLY when the values of the variable x or y changes.
<azonenberg_hk>
MikeFair: I consider that syntax deprecated and strongly recommend against ever using it
<azonenberg_hk>
always @(posedge foobar) for a clocked block
<azonenberg_hk>
always @(*) for combinatorial
<MikeFair>
This is combinational
<azonenberg_hk>
Yes
<MikeFair>
@(*) is exact syntax?
<azonenberg_hk>
* means "combinational for any signal used in the block" which is the actual hardware behavior
<azonenberg_hk>
While the always @(x,y) syntax is legal according to the language specification, it's super easy to forget an entry in the list
<azonenberg_hk>
and get sim-hardware mismatches
<azonenberg_hk>
The safest option is to never use it
* MikeFair
did that once already.
<azonenberg_hk>
* is less typing and less error-prone and gives the exact same result
<azonenberg_hk>
I've been collecting a list of verilog best practices for a while and one day hope to write a tool to automatically check them
<azonenberg_hk>
basically a static analyzer
<qu1j0t3>
:)
<MikeFair>
azonenberg: Just for my pedantic learning exercising; if I use 8 inputs in the module, and this particular logic only works with 3; does it fire when the other 5 change?
<azonenberg_hk>
But i have so many other things on my plate i never got past making the list
<qu1j0t3>
verilint
* azonenberg_hk
needs minions
<azonenberg_hk>
qu1j0t3: pm my other nick and i'll add it to the list of existing tools
<qu1j0t3>
azonenberg_hk: my uneducated opinion is that it might be more fruitful simply to develop higher level tools?
<azonenberg_hk>
Right now i am making a wishlist
<cr1901_modern>
whitequark: Do you remember the paper (assuming I'm remembering correctly) you looked at to implement error handling in pythonparser?
<azonenberg_hk>
the next step is to figure out which tools can check which errors
<azonenberg_hk>
and what new stuff has to be created if any
<qu1j0t3>
azonenberg_hk: Oh, there's an existing tool? I was just suggesting a name. :)
<azonenberg_hk>
oh
<azonenberg_hk>
lol
<azonenberg_hk>
i thought that was an existing tool you suggested
<qu1j0t3>
no.
<azonenberg_hk>
But yes i basically want a verilog linter
<qu1j0t3>
this topic has come up before here i think
<azonenberg_hk>
MikeFair: In hardware it's discrete gates and updates constantly
<qu1j0t3>
but most likely you're aware of every existing option
<azonenberg_hk>
in simulation it only fires when those 3 change
<azonenberg_hk>
This mismatch is essentially never desirable
<azonenberg_hk>
* correctly models the hardware behavior in all cases
<MikeFair>
azonenberg: Ahh in both cases "it does the right" because the lines either aren't connected or are properly ignored :)
<MikeFair>
me grins and wonders what other "bad practices" these tutorials are teaching him. :)
<whitequark>
cr1901_modern: pythonparser doesn't do error handling much
<azonenberg_hk>
MikeFair: With almost every language i learn
<azonenberg_hk>
after a couple of years and lessons from the school of hard knocks
<azonenberg_hk>
i begin to write my code in a strict subset of it
<azonenberg_hk>
banning certain features as too easy to misuse, and mandating certain other features
<azonenberg_hk>
for example in verilog the default behavior if you try to use a signal name that doesn't yet exist
<azonenberg_hk>
is to implicitly create a 1-bit wire by that name
<cr1901_modern>
I guess my memory's faulty, so I'll grep my logs at some point
<whitequark>
verilog is like extra disgusting
<azonenberg_hk>
so a one-character typo hooks you up to a new wire instead of erroring out
<MikeFair>
and it's funny, because what I was actaully going to say about that quote was "No that's about the clearest description of how to think about what "always" does that I've seen yet; ironic that it's called 'always' -- sounds more like 'onchange' to me"
<azonenberg_hk>
`default_nettype none
<azonenberg_hk>
at the top of each file, backtick included
<azonenberg_hk>
will turn this into a syntax error instead
<azonenberg_hk>
i cannot think of any situation where this is not the correct course of action, so in my code i mandate it
<MikeFair>
azonenberg: I totally require that!!! Got bit by that earlier -- this line was just "not responding"
<MikeFair>
Well hmm, must have been some other section of the code or an older version of verilog
<MikeFair>
I just got: Mux_4_2.v:9: error: Unable to bind wire/reg/memory `int1' in `mux2tb.uut'
<MikeFair>
without the directive
<MikeFair>
('int1' should have been 'in1')
<azonenberg_hk>
Without seeing the whole code i can't comment
<azonenberg_hk>
what i can say is, having that directive there will never break sanely written code
<azonenberg_hk>
and will correctly break buggy code
<azonenberg_hk>
there does exist sloppy verilog that relies on this behavior
<azonenberg_hk>
IMO, if you see code that relies on it, run for the hills :p
<MikeFair>
8D
<MikeFair>
Is there any particular reason I see vectors declared with odd seeming indexes: e.g. reg [4:1] x; wire [2:0] pcode;
<MikeFair>
why not keep them consistent using reg [3:0] x; or conversely wire [3:1] pcode; ?
<azonenberg_hk>
MikeFair: i'm quite curious where you saw such vectors used
<azonenberg_hk>
because i have never used anything but [x:0]
<MikeFair>
and earlier examples did it too
<azonenberg_hk>
my only guess is, they wanted to use it to reflect nonexistent bits
<azonenberg_hk>
like say 31:2 for a word-aligned memory address
<MikeFair>
Explaining that you can use [4:1] or [1:4] depending on what indeces you want MSB/LSB to be
<azonenberg_hk>
this was bit 31 is still bit 31 but you don't waste gates storing the last two
<azonenberg_hk>
And yeah, i understand that it's possible but 99.99% of code i've seen has always been bit 0 as LSB
<azonenberg_hk>
at least i have never seen any code doing it the opposite way
<MikeFair>
ok, it might be a convention they have for reg vs wire, but I haven't looked too closely at it
<azonenberg_hk>
extremely unlikely
<MikeFair>
or input vs output
<azonenberg_hk>
again, every piece of verilog i've ever read anywhere has used X:0 for both regs and wires
<azonenberg_hk>
and input vs output would make it super easy to use the wrong indexes
<azonenberg_hk>
it's a terrible idea :p
<azonenberg_hk>
The only use i can think of for it is declaring values that are missing the last few bits
<azonenberg_hk>
and if you just don't use those bits the synthesizer will optimize them out
<azonenberg_hk>
So there is no point
<MikeFair>
it makes no logical sense I can see yet; and I can only see screwing it up by having it mismatched this way; pick a way and stick to it; and in all likelihood 0 based indexing is "the right thing" (tm)
<MikeFair>
yeah; like you said ;)
<MikeFair>
Here's another kind of silly thing they do: `timescale 1ns / 1ps
<MikeFair>
In one of their examples they used: `timescale 1ns / 100ps which makes way more sense; when I looked at the output in GTKWave I had to scroll to over to clock 2000 before I saw anything
<MikeFair>
I thought I was doing something wrong until it clicked for me what I was actually looking at
<azonenberg_hk>
1ns/1ps is the only timescale i ever see used
<azonenberg_hk>
again, this is one of those things that should not even be configurable
<azonenberg_hk>
like default_nettype
<azonenberg_hk>
but since it is, you can at least mandate it by policy
<MikeFair>
Really, so does GTKWave have like a zoom out function or something?
<MikeFair>
1000 ticks per clock is a lot of nothing happening for a long time with these basic modules
<azonenberg_hk>
yes it has zoom
<azonenberg_hk>
dont remember the command
<azonenberg_hk>
but it's there
<MikeFair>
ok, I looked/tried for like 20 seconds
<MikeFair>
so I'll look more specifically
<cr1901_modern>
there should be a magnifying glass on the GUI
<azonenberg_hk>
aaand its 2300 and i havent been to the gym yet, lol