electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
levi has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
jeanthom has joined #nmigen
Asu has joined #nmigen
<DaKnig>
how would I integrate parts from other langs, like verilog/vhdl? compile the nmigen to verilog then use the gui tools of vivado to include this as part of the project?
<DaKnig>
is there a better way?
<whitequark>
with open("foo.v") as f: platform.add_file("foo.v", f)
<ktemkin>
whitequark: I have a handful of board definitions to dump into nmigen_boards; I'm going to PR the first couple one-at-a-time before I PR the rest so if there are things wrong with the first ones, I can change the rest before making them your problem =P
<trabucayre>
ktemkin: I like your PR, especially the first point in the message and toolchain_program :)
<FL4SHK>
considering whether or not to include a `defer` statement in my assembler
<FL4SHK>
I think I want to include that later
<FL4SHK>
I'd certainly like to include stuff for function calls
<FL4SHK>
Honestly what may make the most sense is to just build a Binutils port
<FL4SHK>
I need practice with that, anyway
emeb has joined #nmigen
awe00 has joined #nmigen
xax37 has joined #nmigen
<xax37>
hello, I am having trouble getting an fsm state from the simulation. anyone have any pointers?
<Lofty>
xax37: It'll be in the VCD at least
<DaKnig>
how can I change the name of a Module (or an instance of such a Module) in the verilog output?
<xax37>
yes, I have that already and its good, but I want to do tests in the simulation without the vcd
<awygle>
This can be done but it's somewhat obtuse
<awygle>
You can see an example in the nmigen test suite
<vup>
DaKnig: for submodules you can use `m.submodules.your_name = SomeModule(...)`, for the toplevel module, `verilog.convert(Top(), name="YourName")`
<vup>
(or `m.submodules["your_name"] = SomeModule(...)`, which can be handy for example for loops that generated submodules)
awe00 has quit [Ping timeout: 240 seconds]
xax37 has quit [Ping timeout: 245 seconds]
awe00 has joined #nmigen
cr1901_modern has quit [Read error: Connection reset by peer]
awe00 has quit [Quit: WeeChat 2.9]
xax37 has joined #nmigen
cr1901_modern has joined #nmigen
<xax37>
awygle: the closest example I could find is in test_fsm.py, but it uses FSM() instead of m.FSM() which gives me AttributeError: __enter_ when i do with ...:
<xax37>
awygle: I can't find an exmple or a way to use FSM as documented "with m.FSM():" and yield fsm.state (and fsm.decoding[state]) in simulation
<awygle>
tbh whitequark explained this to me a while back but I gave up on it
<awygle>
But if you look at test_fsm_basic in test/test_hdl_dsl.py you'll see the "find_generated" call that gets you access to the state signal
<whitequark>
the path you pass to .find_generate is the name (or index, for unnamed ones) of every module that contains the FSM, from outermost to innermost
<whitequark>
does this make sense?
<xax37>
whitequark: I'll give it a try, thx
<awygle>
whitequark: a question of intent - am I correct that the Fragment infrastructure would not, in an ideal world, be interacted with by users? or is it a public API? Z
<whitequark>
generally former
<whitequark>
one day, when it is no longer awful, it might become latter
<whitequark>
long ago, i thought it is not awful. i was wrong
<xax37>
whitequark: works perfectly! thank you.
<awygle>
OK, cool, that's what I figured (except the last bit lol)
<awygle>
What would it be used for as a public API?
<whitequark>
things like external linters
<awygle>
ah yes
<awygle>
how's your eeprom-ing going?
<FL4SHK>
I need to get like, a parallel EEPROM at some point
<tpw_rules>
are records still the thing for passing around related groups of signals? i seem to remember something about how they weren't great?
<FL4SHK>
tpw_rules: only for a little while longer
emeb has quit [Quit: Leaving.]
<FL4SHK>
switch to PackedStruct once that becomes a thing
<whitequark>
awygle: i think i'm getting some idea of how this works
<whitequark>
not enough to write a published lab note
jeanthom has quit [Ping timeout: 256 seconds]
<awygle>
Well I look forward to reading it when it's done
xax37 has quit [Remote host closed the connection]
<whitequark>
:)
<whitequark>
right now i'm a bit confused by different behavior of EPROM vs EEPROM
<FL4SHK>
EPROMs, tmk, are not erasable besides with a UV light
<whitequark>
sorry, you didn't have context for this
<FL4SHK>
ah
<whitequark>
what i mean is that i'm investigating bitrotted EPROMs/EEPROMs and they bitrot differently
<FL4SHK>
ahhhh
<whitequark>
EEPROMs bitrot like you'd normally expect
<whitequark>
you lower Vcc (thus Vth) and they start reading fine
<whitequark>
EPROMs... i don't even know
<FL4SHK>
I'm trying to make a Binutils port for my newest CPU
<FL4SHK>
going to port GCC also... eventually
<FL4SHK>
...so I'm back into using C
<FL4SHK>
I'd rather write C++
<awygle>
"more like eeh-proms, amirite" no shut up Bad Joke Brain
<Lofty>
"Things were simpler in the past"
<Lofty>
E[E]PROMS: "yeah, no"
<FL4SHK>
the "EE" in "EEPROM" stands for "Electrical Engineer"
<FL4SHK>
Electrical Engineer Programmable Read Only Memory
<tpw_rules>
i guess light leaking in would have the same effect as age?
<whitequark>
tpw_rules: not necessarily
<whitequark>
though i do think it's plausible
<tpw_rules>
then is that the difference?
<tpw_rules>
like i thought both caused loss of trapped electrons
<whitequark>
the difference is in the specific ways unstable reads manifest
<tpw_rules>
where are these decaying memories coming from out of curiosity
<whitequark>
literal garbage my roommate brought home
<whitequark>
some sort of... industrial pc control thingy from 1995
<tpw_rules>
i should have figured
<whitequark>
with a z8018008
<whitequark>
i have no idea
<whitequark>
it runs basic
<whitequark>
only one of them even boots, the other had a bitrotten *GAL*
<whitequark>
which is how this all started
<tpw_rules>
a what
<tpw_rules>
z180>?
<whitequark>
GAL/PAL
<tpw_rules>
no the microprocessor
<whitequark>
like... you know CPLD? that but without the C
<whitequark>
oh
<whitequark>
oh yeah it's a z80
<tpw_rules>
i find it funny how far zilog fell
<awygle>
i was wondering if you had a specific goal for this or if this was "brain grabbed a thing won't let go"
<tpw_rules>
if it's industrial, i wonder if severe heat contributed
<whitequark>
it's not very industrial
<tpw_rules>
i wouldn't have expected a 1995 thing to rot yet
<whitequark>
in this case it was used in a distinctly commercial setting
<whitequark>
it has a GPS, a commercial radio connector, and a panic button (?)
<awygle>
how can there be so much shit in my lab notebook that i have zero memory of writing/drawing
<whitequark>
awygle: that's what it's for!!
<awygle>
.. ok, fair
<tpw_rules>
do you have tips on getting into lab notebooks
<whitequark>
tpw_rules: ... yeah lol sorry i somehow assumed you don't know what a CPLD is, my bad
<awygle>
i mostly think of it as a kind of externalized working memory tbh
<awygle>
i have a hard time thinking without a pen in my hand
<whitequark>
lab notebooks, i think of mine as a relatively low effort thing where i just record stuff i feel like recording (but it's online)
<whitequark>
it used to be just zero effort
<whitequark>
but then people got like, all interested in it
<tpw_rules>
i never really record anything but i probably should
<tpw_rules>
i kind of want that as a bit of a resume
<awygle>
you're too interesting wq, it's your curse
<whitequark>
it can be draining at time
<whitequark>
*times
<tpw_rules>
i haven't worked out how to extend my head capacity i guess is the problem
<tpw_rules>
i just swap like mad
<awygle>
meanwhile mine is a physical notebook that i draw diagrams and stuff in, and sometimes i'll think "huh i should make this a blog post" but then i'd have to finish setting up a blog so i don't
<FL4SHK>
I haven't finished setting up my blog, either
<tpw_rules>
part of the problem is my handwriting is so bad the physical notes are unintelligible without at least a little bit of the short term memory
<whitequark>
awygle: tpw_rules: for example, one thing that EEPROMs do is have the outputs oscillate or be unstable, and this seems to be very nicely explained by a theory of "output buffers have input near Vth, are metastable, either resolve one way or around or ... start oscillating"
<whitequark>
but EPROMs? those don't do that
<whitequark>
by which i mean, EEPROMs seem to be completely stochastic in nature
<FL4SHK>
I wish my EE foo were as good as yours, whitequark
<FL4SHK>
I don't know what Vth is
<awygle>
V threshold
<awygle>
the transition point
<FL4SHK>
I only vaguely recall what that means
<whitequark>
^
<FL4SHK>
transition from low to high?
<awygle>
yup
<FL4SHK>
ah
<FL4SHK>
I don't have a clue how to deal with like, setup time and hold time
<whitequark>
i read the datasheet
<tpw_rules>
i don't know that much about the internals of either type. i guess for some reason they must have schmitt trigger buffers
<awygle>
just takes learning. fuck it up a few dozen times.
<FL4SHK>
I did recently learn how to solder
<tpw_rules>
but that doesn't make much sense for the main array
<FL4SHK>
it's so much easier than I was expecting
<whitequark>
tpw_rules: the atmel EEPROMs definitely do *not* have schmitt trigger buffers because their output buffers will happily start oscillating in the right conditions
<FL4SHK>
I had to solder a headphone jack to a breakout board
<awygle>
yeah i was gonna say i don't know enough about EEPROMs or EPROMs to say for sure but i wouldn't be at all surprised to learn they were quite different internally
<FL4SHK>
EEPROMs are like... flash memory
<tpw_rules>
poor talking skills again: the eproms must have them
<FL4SHK>
maybe I should adopt them
<whitequark>
hang on. i made a dumb mistake. please do s/EEPROM/Flash/ everywhere above
<whitequark>
i keep forgetting that this chip i'm poking is 29x and not 28x
<tpw_rules>
there goes my other theory that the erase mechanism required different buffers then
<whitequark>
i don't actually know how EEPROMs behave
<tpw_rules>
because it's much less discriminatory in flash so i don't think the regular array lines are exposed to it
<whitequark>
i only have UV EPROMs and Flash
<awygle>
are the eproms you have cmos, nmos, or pmos?
* whitequark
stares at the docs for the board
<whitequark>
you know, it's not my fault that i keep calling it "EEPROM", the vendor of the device calls the flash chip "EEPROM"
<awygle>
yeah they do that a lot
<awygle>
it's not technically untrue but it sure is misleading
<tpw_rules>
wasn't it a trademark almost back then?
<awygle>
seems like NOR Flash == EEPROM these days
<whitequark>
awygle: lemme get the label off this one
<whitequark>
one is m27c256b
<whitequark>
this one is CMOS
<awygle>
yeah, 27C is almost certainly cmos
<whitequark>
i'm like 80% sure the other is also CMOS
<awygle>
well so much for the "nmos acts differently under decay than cmos does"
<awygle>
theory
<d1b2>
<286Tech> I'm literally holding an AMD 27C512 in my hand right now, and I see talk about an AMD 27C256 here...
<d1b2>
<286Tech> Wow, timing
<whitequark>
username checks out :p
<whitequark>
so the thing about the UV EPROM is that the fault pattern is very different
<whitequark>
it seems that most bytes read either 0x00 or 0xff
<whitequark>
though there are some outliers
<d1b2>
<emeb> Would be an interesting experiment to program an EPROM with a known pattern, then expose it to UV while continuously reading it - see what the decay looks like.
<whitequark>
the other thing is that i can get a flash to give me an indeterminate value "in the act"
<whitequark>
very easily
<whitequark>
but i have so far not managed to get an EPROM to give me an indeterminate value based on an earlier search
<whitequark>
oh! caught it
chipmuenk has joined #nmigen
<whitequark>
... it seems to require a long burst of reads
* awygle
hits issue #381 again
<whitequark>
okay, we can discuss that tomorrow
<whitequark>
i mean, i tried to discuss it on the previous meeting
<awygle>
you did, you tried so hard in fact that you referred to a different issue by that number :p
<whitequark>
:/
<awygle>
s'all good wq, there's no hurry
<whitequark>
alrighty
<awygle>
are we still doing the "devs only" meeting tomorrow?
<awygle>
speaking of meetings
<whitequark>
yep
<awygle>
(i cannot _believe_ tomorrow is monday already. criminy.)
<whitequark>
awygle: okay, it seems that the "bitrotten EPROMs" i had were just bad decoupling
<whitequark>
i lowered the address shift frequency and those failures went away
<whitequark>
plus they made no sense statistically in first place
<awygle>
time to shine a very weak UV light on it?
<whitequark>
ehhh, i can leave that until some later time
<whitequark>
i feel like i don't understand flash rot yet
<awygle>
it's pretty impressive that a chip as old as i am hasn't lost data tbh
<awygle>
i've lost tons of data :p (tho admittedly i have several other functions)
<awygle>
wow i completely forgot FSM.ongoing was a thing
<awygle>
whitequark: Assert is a no-op if you're not in either simulation or formal, right?
<whitequark>
no
<whitequark>
it's a synthesis error and simulation error
<whitequark>
this is ... probably not the best way to handle it
<whitequark>
in general, nmigen formal is very immature
<whitequark>
i would consider it a preview
<awygle>
ah, ok
<ktemkin>
now you’re tempting me to babble about flash and EPROMs
<whitequark>
pls do!!
<ktemkin>
when I’m not supposed to be napping, I totally will
<awygle>
(gene wilder voice) no. stop. don't. come back.
<whitequark>
awygle: okay, so! i think i managed to significantly or fully recover the data flash from one of the cursed devices
<whitequark>
at least all of the things that look like they ought to be english ascii strings do look like english ascii strings now
<whitequark>
and the bit statistics, at first glance, seems rigt
<whitequark>
(i gotta compute that at some point)
<awygle>
nice!
<whitequark>
plot twist
<whitequark>
i had to read this 5V flash at 3V6
* awygle
is now trapped watching gene wilder videos on youtube
<ktemkin>
tired brain vaguely wonders if leakage currents result in trapped carriers over a long period of disuse
<whitequark>
awygle: ... huh
<ktemkin>
I should never check IRC from my phone; it’s the enemy of sleep and the source of stupid ideas
<whitequark>
so remember i mentioned signal integrity issues?
<whitequark>
the ST EPROM doesn't have them. the AMD one does
<whitequark>
the data is exactly same, too
<awygle>
Interesting
<awygle>
You can't really complain, they must be well past their service life lol
<whitequark>
i can't tell if this is just my crappy circuitry or if it's a real difference
<whitequark>
i *think* the former
<awygle>
I think I am finally done rewriting my DDR2 controller
<whitequark>
niiiice
<awygle>
Third design iteration always seems to be the charm lol
<whitequark>
awygle: so, one of the data flashes reads fine at 3.40V (with more confidence than previous 3.6V number), the other at 3.25V
<whitequark>
i'm not entirely sure how old are these exactly (or at least, when were they last programmed)
Asu has quit [Remote host closed the connection]
<ktemkin>
oh, by the way, I don’t know if you postulated a good theory for why the outputs wound up oscillating in lockstep during your astable reads
<whitequark>
ktemkin: oh, i have two possible reasons
<whitequark>
the first one is that they're just physically close
<whitequark>
the second one is that given the massive inductance of my awful wiring, vcc appreciably oscillates, too, and the buffers end up resonant with some passives on the board
<whitequark>
i think the second one is at least a significant contributor because when i added a small decoupling cap, oscillations got a whole lot worse
<whitequark>
like an order of magnitude
<ktemkin>
but it strikes me as likely coupling via the supplies; since during the astable states you’re effectively turning on both logic network partially, drawing more than typical stable-state current; this in turn would cause threshold oscillations for the other signals
<whitequark>
right, so my question is basically "is it coupling on chip or off chip"
<whitequark>
as in "would they still oscillate if my board wasn't awful or not"
<ktemkin>
(typing slowly from phone)
* whitequark
nods
<ktemkin>
I’m going to guess the supply input impedance is significant enough that you’d still see appreciable internal VCC swings when the buffer’s pull-up and pull-down transistors are on
<whitequark>
mhm, so you're saying that i would still observe this with a better laid out board, right?
<ktemkin>
I’d think
<whitequark>
yeah, makes sense; i should check that at some point
<ktemkin>
I’m guessing that your single-signal oscillation stays around without settling as well as it does because the threshold of the signal itself is being modulated
<whitequark>
yeah
<whitequark>
fwiw, i took some new captures, and for some reason (i moved things around?) the oscillation is really pronounced there
<whitequark>
i get actual rail to rail 26-28 MHz oscillation
<whitequark>
instead of Voh
<ktemkin>
huh
<whitequark>
not on every word
<whitequark>
but on a significant proportion of
<whitequark>
what i also found amusing is that apparently the oscillator has enough short-term stability that glasgow sampling it with an xtal derived clock actually usually samples it in the same point
<whitequark>
well, enough to make me wonder why i get stable reads when i *clearly see the huge sine wave on the scope*
<whitequark>
(i think that changing address pins resets its phase or something like that?)
<ktemkin>
you’re probing at the Glasgow side?
<whitequark>
at the flash pin
<d1b2>
<Hardkrash> Can you get 5 to 10 turn to fine magnet wire around the pin
<ktemkin>
I mean, chances are the oscillations you’re seeing are getting smoothed out a bit by the mass of wiring on their way over to the glasgow
<whitequark>
ah, also possible
<whitequark>
i did observe glasgow sampling at weird points with different gateware thoug
<ktemkin>
dunno if they’d be smoothed our enough, but if the setup is the one I saw on twitter a bit ago it looked very capacitive and inductive =P
<ktemkin>
*out
<whitequark>
right, yeah
<whitequark>
i should check more carefully
<ktemkin>
(anyways, I should actually nap; I’m pretty sure $girlfriend is rolling her eyes at me for doing the whole “Kate checks her phone repeatedly in bed” thing)
<lkcl>
ktemkin: lol
<whitequark>
good night!
<lkcl>
always amazes me, online communities being in different timezones
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<awygle>
whitequark: nmigen Switch/Case makes a priority encoder right? which cases take precedence if multiple match?
<whitequark>
yes, first one does
<whitequark>
the same as most other pattern matching constructs, eg rust
<awygle>
ok, cool
<awygle>
(it could easily have been last-wins, since that's how e.g. multiple assignments work)
<whitequark>
mhm, that's true
<tpw_rules>
but not if-elseif
<awygle>
if/else ladders are inherently unambiguous though
<tpw_rules>
as a software person and chronic python addict i've always treated switch/case as just a different flavor of if-elseif
<awygle>
i have always thought of switch as the non-priority version of if-else, personally
<awygle>
i think conflicting case statements should be a hard error
<hell__>
see Ada
<whitequark>
Switch is a way of writing If match/Elif match/Else concisely
<hell__>
IIRC in Ada not handling some case is an error
<whitequark>
i think it is not unreasonable to add some sort of an attribute that requires the switch to be either full or with no overlapping cases
<whitequark>
hell__: rust too, that's common. ocaml gives you a warning that most people (i think) convert to error
<awygle>
oh no lol full_case parallel_case
<whitequark>
awygle: no, that's the *opposite* of those attributes