<azonenberg>
whitequark: sounds like a big fpga vcore supply
<whitequark>
azonenberg: correction: I'm thinking of dropping either 5 or 12
<whitequark>
and yes, it's almost correct
<whitequark>
I finally obtained the docs to the desired PLX switch
<whitequark>
it needs less than 300 mW on 1V8 and almost 10 amps on 0.9 VDD and VDDA
<whitequark>
bizarrely the datasheet says that "most people connect VDD and VDDA together"
<azonenberg>
why is that bizarre?
<whitequark>
I'd expect at least a filter in between
<azonenberg>
guess it depends on how sensitive the analog rail is / how noisy the digital is
<sorear>
still kinda mad that CMOS people decided the positive terminal should be "drain". I don't care if it's more "correct" re. majority carriers in silicon, it's inconsistent with everything else in EE
<azonenberg>
sorear: i think the term originally came from NMOS logic, where it was technically correct
<azonenberg>
i.e. source at ground, drain pulled up
<azonenberg>
then people were used to those terms and they stuck when people when to cmos
<sorear>
pretend I said "carriers of higher mobility"
m_w has quit [Ping timeout: 268 seconds]
jevinskie has joined ##openfpga
AndresNavarro has quit [Ping timeout: 255 seconds]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 245 seconds]
_whitelogger has joined ##openfpga
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_wor1 has quit [Client Quit]
rohitksingh_work has quit [Ping timeout: 246 seconds]
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
jevinski_ has quit [Read error: Connection reset by peer]
jevinskie has joined ##openfpga
<kc8apf>
whitequark: vicor PoL parts
rohitksingh has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
ZipCPU has quit [Ping timeout: 252 seconds]
ZipCPU has joined ##openfpga
Thorn has joined ##openfpga
m4ssi has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
scrts has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
<_whitenotifier-9>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhd5O
<miek>
is there some more info on the level shifter brokenness somewhere?
<tnt>
miek: you can't have pull-ups/pull-down on any of the lines you connect to basically.
<tnt>
That messes with the FXMA automatic direction sensing. It's documented in the FXMA datasheet.
<miek>
ah ok
<miek>
cheers
<whitequark>
tnt: it's not just that, unfortunately
<whitequark>
FXMA's strong drivers cause severe glitches on *adjacent* circuits
<tnt>
miek: One thing I did on mine it remove the fxma and bridge over that with a 0R resistor pack. That makes the bank 3v3 only, but it works more reliably in those cases.
<whitequark>
so e.g. if you read 4 GB from a NAND, a few bytes there will be bad because it's NAND, and a bunch more will be corrupted in chunks that usually end at page boundary
<whitequark>
that's because transitions on some control or data lines triggered spurious command cycles or something similar
<whitequark>
revB was supposed to fix that by slew rate limiting. it didn't work
<tnt>
whitequark: huh ? I mean, series resitors should have taken care of that, unless those adjacent lines are especially high impedance. Wouldn't have expected that.
<whitequark>
I don't know why it didn't help.
<whitequark>
it should have. but I still observe the same problem.
<whitequark>
and it can be solved by physically separating the wires towards the DUT such that they have large spacing.
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
Miyu has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Ping timeout: 255 seconds]
rohitksingh has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
reportingsjr has quit [Ping timeout: 246 seconds]
reportingsjr has joined ##openfpga
keesj has quit [Ping timeout: 268 seconds]
<azonenberg>
whitequark: are you still having problems with the auto sensing level shifters?
Morn_ has quit [Ping timeout: 250 seconds]
<whitequark>
azonenberg: i just tried if the workaround we made for that in revB would work
<whitequark>
it did not
<azonenberg>
:(
<whitequark>
i don't know why and i am not interested in investing a second more of my time into that shitty chip
<whitequark>
i will never use it again in any design
<whitequark>
or anything with that topology
<whitequark>
anyway
<azonenberg>
So you're going to move to explicit direction signals?
<whitequark>
already did
<whitequark>
already got revC boards
<azonenberg>
reinventing starshipraider much? :p
<whitequark>
already verified that they work extremely well
<whitequark>
i mean we kind of established it long ago that glasgow is a $50 SSR with far more powerful reconfiguration
<whitequark>
glasgow is mostly software
<whitequark>
unlike SSR, glasgow is impossible without migen and yosys
<azonenberg>
Yep
<whitequark>
i actually think there's a rather large gap conceptually between them now
<azonenberg>
SSR is intended to be something you throw on a LAN and just stream data to
<whitequark>
even if the hardware is similar
<whitequark>
i mean, revE will literally have a LAN port and a USB LAN port
<whitequark>
but it would still have the same dynamic reconfigurability
<whitequark>
just not via bare USB because USB sucks
Morn_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
keesj has joined ##openfpga
<_whitenotifier-9>
[whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhdpe
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitksingh has quit [Ping timeout: 244 seconds]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 246 seconds]
azonenberg_work has joined ##openfpga
rohitksingh has joined ##openfpga
genii has joined ##openfpga
gsi__ is now known as gsi_
tms_ has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
show1 has quit [Quit: WeeChat 2.3]
mumptai has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
m_w has quit [Quit: Leaving]
<somlo>
I've been poking around migen, litex, and litedram, and had it spit out an example SoC. I noticed a lot of nonblocking assignments inside combinational ( "always @(*)" ) blocks. E.g. "always @(*) begin foo <= 3'b0; if (bar) foo <= a; else foo <= b; end"
<somlo>
Is there an effective difference between "<=" and blocking "=" in this kind of context? Feels to me like more of a stylistic thing... I've been digging around the Web and use of nonblocking "<=" inside combinational always[_comb] is not frequent, nor well explained...
<Finde>
doesn't verilator complain about doing that
<somlo>
haven't made it to where verilator would complain, just looking at the generated .v file for now :)
<Finde>
I don't have a log to hand but I seem to recall that it's one of those things it thinks are bad
<somlo>
I remember being told "don't do that" in my digital design class a while back. Which is why I got hung up on it and started trying to understand if it actually means anything special
<somlo>
Finde: at least your example is sequential (maybe not w.r.t a bona fide clock, but still only "when some event happens")
<Finde>
that's what scares me more about it haha
<somlo>
well yeah, but it's not "weird" from a language usage POV
<somlo>
doing "<=" inside an "always @(*)" or "always_comb" is unusual Verilog, not "merely" unusual design-wise :)
show1 has joined ##openfpga
<Finde>
it's against our coding style
<Finde>
but that block is something we inherited in
emeb_mac has joined ##openfpga
<somlo>
just staring at the code stupidly, your "possible triggers" are nonblockingly set two blocks down in an always @(posedge clk), so *effectively* your block can only happen on a clock posedge as well
<Finde>
which is probably the only reason it synthesises in a sane way to FPGA
<somlo>
could be rewritten that way relatively pain-free (easy for me to say, I know :) )
<Finde>
of course since vivado produces roughly four billion warnings so who knows if it complains about these lines in particular
<somlo>
I think my problem is one of "language lawyering" rather than a design question :)
<Finde>
basically I'd also have expected if you're going to produce sane verilog that you'd avoid the construct you're seeing
<Finde>
but "sane verilog" :|
emeb_mac has quit [Client Quit]
show1 has quit [Quit: WeeChat 2.4]
show1 has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
emily is now known as emilazy
emily has joined ##openfpga
moho1 has quit [Ping timeout: 268 seconds]
emilazy has quit [Quit: leaving]
emily has quit [Remote host closed the connection]
emily has joined ##openfpga
m4ssi has joined ##openfpga
moho1 has joined ##openfpga
emeb has joined ##openfpga
moho1 has quit [Quit: WeeChat 2.2]
moho1 has joined ##openfpga
<sorear>
I took a look at the @antmicro vexriscv fork and linux build system and I don't fully understand what the scope of that is supposed to be. They have a software-managed TLB in the core and a trap handler in their U-Boot fork (fine so far…) but the trap handler just conjures physical addresses out of the air, it doesn't seem to be even attempting to walk a page table
<Miyu>
anyone has copy of the 25k or so ECP5 .bba file imported with a recent version of the Python import script?
<Miyu>
I just ported said script to a C++ utility, and want to make sure it produces the same output :)