Stormwind_mobile has quit [Remote host closed the connection]
<Twix>
minicom, voltage divider for downtranslation from 3.3 V should work, at least for (very) low speed. But you have to provide a stabe 1.8 V supply for your flash. Using a glasgow board is a lot easier and works with (at least) 5 MHz :)
Stormwind_mobile has joined #glasgow
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 258 seconds]
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
midnight has quit [Ping timeout: 272 seconds]
sorear has quit [Read error: Connection reset by peer]
m4ssi has quit [Remote host closed the connection]
ExeciN has joined #glasgow
bvernoux has joined #glasgow
tomtastic has joined #glasgow
<electronic_eel>
esden: you showed a rendering of the case for glasgow in the stream yesterday, IIRC it was done by timon and is a work in progress
<electronic_eel>
one thing that I thought of was that the lvds connector in this rendering was accessible and open from the outside
<electronic_eel>
I'm not sure if that is a good idea, because the lvds interface is not well protected. it does not have esd protection and it has the internal 3v3 rail without further protection on it
<whitequark>
(fwiw i agree)
<whitequark>
the lvds connector is ... well it's kind of weird
<electronic_eel>
I think it should either be protected by some rubber clip on thing, or not even exposed through the case at all
<whitequark>
marcan didn't want to have any NC pins on the FPGA, which i respect
<whitequark>
but it never had a clearly defined purpose and story
<whitequark>
i'm not even entirely sure if we should populate it? given the connectors are all out of stock
<electronic_eel>
I consider it a secondary interface. it does not cost much to somehow break out free pins. but properly breaking them out in a well defined and future proof way is waay more effort
<whitequark>
yeah
<electronic_eel>
if someone wants to hack on it and knows how to handle it (like only connect/disconnect in unpowered state), I have not problems with it
<electronic_eel>
whitequark: currently we have a warning about the aux connectors not being kept for future revs. in the schematic. shouldn't we also add that for the lvds connector as it won't be in revD or revE according to current planning?
<whitequark>
electronic_eel: well, the situation is a bit different conceptually
<whitequark>
but not much for the end user
<whitequark>
i agree
<d1b2>
<esden> I have sourced connectors for the lads connector
<d1b2>
<esden> lvds
<electronic_eel>
you said you had some cheap Korean(?) manufacturer. is it from them?
<d1b2>
<esden> yes
<d1b2>
<esden> I have both ends of the connector
<d1b2>
<esden> and will be able to provide the mating connector to those that want to use that interface
<d1b2>
<ebb> Would this connector be usable on revC1 too?
<electronic_eel>
ebb: probably not, because revC1 doesn't have the alignment holes
<d1b2>
<esden> well... yes/no ... with modification you might be able to populate it ... if you cut of the alignment pegs
<d1b2>
<esden> I have added the alignment pins so that we get accurate alignment for test jig, as well as for mating boards people might want to connect to that interface
<d1b2>
<esden> We ended up exposing the lvds connector on the case, because we like the shallow depth of the case and it's aesthetic
<electronic_eel>
these type of connector works much better with the alignment holes
<d1b2>
<esden> also being able to access the lvds connector for expansion I think is a pretty big bonus
<d1b2>
<esden> and I think down the road it should be used for applets that don't need level shifting
<d1b2>
<esden> there is a long list of such interfaces too
<d1b2>
<esden> why waste the hardware resources...
<d1b2>
<ebb> electronic_eel - nod; it's a shame because I was going to use my (soon) revC1 for some LVDS stuff :P
<d1b2>
<ebb> Indeed esden
<electronic_eel>
as I said, I think it is not safe to expose it in the way it is now. you can just carefully cold-plug (glasgow completely disconnected) into it
<electronic_eel>
and it won't be on revD and revE, so any addons relying on this connector won't be usable with them, reducing the advantages of getting a revD or revE
<electronic_eel>
if it is exposed in the case, there should be some rubber protector that is clipped or screwed on top of the lvds connector to protect it when it is unused
<d1b2>
<esden> Sure I agree that it should probably at least be protected.
<d1b2>
<DX-MON> heya whitequark, I'm currently looking at the memory-prom applet and looking to get it working with latched shift registers. esden has, smartly suggested I run it past you, noting I plan to open a PR for it once done. I'm new to nmigen but familiar with Python and HDLs. My question for right now, other than are you ok with this, is about understanding where I can use Python if statements vs the nmigen If type
<d1b2>
<DX-MON> I'm looking to generate one version of the MemoryPROMBus FSM when no address chain latch pin is given, and a different one when it is
<d1b2>
<DX-MON> is sticking a Python if in the middle of an nmigen If block ok? (I'm assuming yes, but I want to be sure)
<d1b2>
<Attie> @DX-MON - can you use the attribute tests for reference (e.g: line 42)
<d1b2>
<DX-MON> ok, so that's fine even that deeply nested in nmigen with If statements, good to know
<whitequark>
DX-MON: can you explain why are you doing that?
<whitequark>
is there something address-related that the applet doesn't already support?
<d1b2>
<DX-MON> yeah
<whitequark>
what is it?
<d1b2>
<DX-MON> many modern latches have a latch pin which has to be pulsed, and not all memory devices that memory-prom can drive can tolerate the address pins changing while the address is being clocked out the shift register chain, making it desirable to use those kinds of latch
<d1b2>
<DX-MON> er.. many modern shift registers even
<d1b2>
<DX-MON> tired
<whitequark>
oh i see!
<d1b2>
<DX-MON> I'm aiming to add support for an expanded range of shift registers
<d1b2>
<DX-MON> not just ancient 7400 logic ones
<whitequark>
yeah, you can copy the existing code that uses optional pins
<d1b2>
<DX-MON> okie
<whitequark>
Python if in nMigen If is totally fine
<tnt>
DX-MON what kind of memory doesn't support its address lines changing ?
<whitequark>
i was foreseeing something like this for magic unlock sequences
<whitequark>
i've never seen one that would actually need latching yet
<tnt>
I was actually wondering if instead of going 0,1,2,3,... for the shifted in address, you could use a maximum length lfsr to only have to shift 1 bit to change the msbs of the addresses.
<whitequark>
yeah that's certainly possible
<whitequark>
i'm dealing with like 128kbit-2mbit flashes so it's not noticeable
<d1b2>
<DX-MON> so I haven't got any on hand, but I'm aware of devices for which fast twiddling of the address pins violates the timing constraints and can cause glitch usage if you hold the OE and CE pins low to put it in combinatorial operation
<d1b2>
<DX-MON> when trying to run a recovery on such a device, this would be bad news
<whitequark>
recovery currently pulses OE
<whitequark>
this is actually deliberate
<d1b2>
<DX-MON> it's CE being low that causes the problem
<whitequark>
OE and CE at the same time... I think the current logic does something like CE=OE|WE
<d1b2>
<DX-MON> ah, ok
<d1b2>
<DX-MON> still, my point about modern shift registers stands
<whitequark>
sure
<whitequark>
i've no issue with having this feature at all
<d1b2>
<Attie> for context: the one we were discussing yesterday, was the "standard" adapter with ZIF that supports 128k, 256k and 512k parts... the smaller parts have the ~PGM in place of an address bit, which must be maintained high at all times
<d1b2>
<Attie> a shift-then-latch approach allows that pin to be maintained at all times
<whitequark>
oh, right
<whitequark>
i recall encountering that
<whitequark>
on my ZIF adapter, i have three jumpers
<d1b2>
<Attie> yeah, that was the other option
sambristow_nz[m] has joined #glasgow
<d1b2>
<DX-MON> ah, thanks Attie for jogging my memory on the other reason for wanting latched SRs
<d1b2>
<DX-MON> when you've got a moment, whitequark, a quick review would be appreciated
<whitequark>
why do you disable the clock?
ExeciN has quit [Quit: so long king Bowser]
<d1b2>
<DX-MON> during the latch cycle? to prevent spurious bit shifting within the SR chain but maintain a long enough latch pulse to guarantee they operate correctly
<d1b2>
<DX-MON> I couldn't think of a better way to get a clock cycle wide latch pulse without introducing more new signals
<whitequark>
please do not do it this way.
<whitequark>
lemme see
<d1b2>
<DX-MON> ok, I'll rework that then with your guidance
<whitequark>
just to recheck, you want a sh_cyc long pulse on a-lat, right?
<whitequark>
after everything's shifted?
<d1b2>
<DX-MON> yeah
<d1b2>
<DX-MON> wait.. no, a two sh_cyc
<d1b2>
<DX-MON> seeing as the clock is generated on double sh_cyc
<d1b2>
<DX-MON> one period of that low, one period high
<whitequark>
one clock period
<d1b2>
<DX-MON> yeah
<d1b2>
<DX-MON> if not re-using a_clk, I could just add another Signal() that the latch state twiddles as-if a_clk in the shift state to get the right timing