<emeb_mac> nice!
<emeb_mac> think I'm going to put a timeout in my wb master so it doesn't hang the CPU forever if it doesn't get an ACK
emeb has joined ##openfpga
OmniMancer has joined ##openfpga
<emeb_mac> aha - accessing a SB_SPI register that isn't listed in the documentation will result in no ACK, but reading writing legal registers works.
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 246 seconds]
fseidel has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
noobineer has quit [Ping timeout: 245 seconds]
noobineer has joined ##openfpga
emeb has left ##openfpga [##openfpga]
futarisIRCcloud has joined ##openfpga
_whitelogger has joined ##openfpga
flea86 has joined ##openfpga
Laksen has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 246 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
zem has quit [Ping timeout: 246 seconds]
zem has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
<emeb_mac> yay - now successfully reading / writing SB_SPI registers from the 6502
<emeb_mac> bugs in my 6502/wishbone bridge. :P
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt> emeb_mac: nice :)
<emeb_mac> it's actually pretty simple. just dumb typos.
<emeb_mac> now need to figure out how to configure it
<tnt> Yeah, I'm still trying to figure that out :/
<emeb_mac> tnt: you said something above about the CS signals being swapped - was that true or was it just inverting the register bits?
<tnt> invert the register bits.
<emeb_mac> kk
<tnt> So, the default value should actually be 0x0f and then set to 0x0e if you want ot enable CS_n[0] for instance
<emeb_mac> yeah - that makes sense.
<emeb_mac> reading the docs about the SPICSR
<emeb_mac> wtf: "Bits [3:1] may be connected to any I/O pin via the FPGA fabric. Bit 0 has a pre-assigned pin location."
<tnt> Yeah, don't think it matters because we re-route everything to the fabric.
<emeb_mac> yeah, nextpnr didn't complain about my .pcf assignments
<tnt> it's just that cs0 is the only one that can be used with direct hw connection, the others can't.
<emeb_mac> ok
<emeb_mac> gn
emeb_mac has quit [Ping timeout: 250 seconds]
futarisIRCcloud has joined ##openfpga
rohitksingh has joined ##openfpga
scrts has quit [Ping timeout: 245 seconds]
scrts has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
scrts has quit [Ping timeout: 245 seconds]
scrts has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Asu has joined ##openfpga
scrts has quit [Ping timeout: 272 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
scrts has joined ##openfpga
rohitksingh has quit [Ping timeout: 255 seconds]
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 250 seconds]
scrts has joined ##openfpga
futarisIRCcloud has joined ##openfpga
Laksen has joined ##openfpga
sgstair has quit [Read error: Connection reset by peer]
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
ayjay_t has quit [Quit: leaving]
lutsabound has joined ##openfpga
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
emeb has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<tnt> emeb: I got the spi core do what I want (more or less) now.
<emeb> tnt: awesome!
<emeb> tnt: working on some 6502 assy to initialize it and try some transactions
<tnt> That's the init
<tnt> I'm writing up a pseudo code of my spi_xfer function
<emeb> tnt: that will be handy to see.
<emeb> encouraging that the tools are able to hook it up in a functional condition.
<emeb> tnt: interesting how the rx value isn't available until the next tx
<tnt> so the general idea is that clearing of the bits in SPICSR puts the core in active mode. it will assrt the selected CS whenever it gets the first byte.
<emeb> yeah - I was noticing that feature.
<emeb> very different from most MCU-based SPI ports I've used which just leave the CS handling to the higher levels
<tnt> emeb: yeah, it makes sense because you first fill SPITXDR. Then that register gets transferred into the shift register and you can already write the next TX byte. But of course at that point the shift register hasn't shifted anything yet, so you can't RX anything yet ...
<emeb> tnt: ah, true. if you're keying off the tx empty flag.
<emeb> but if you waited for rx full then there would be needless gaps.
<tnt> you can simplify the logic a bit and just wait for RXRDY and when it's high you know you can both read a byte and write the next but you have a bit more dead time between bytes
<emeb> :)
<tnt> As it is I still have dead time because I only divide the bus frequency by 4 and the softcore can't keep up.
<emeb> what clock rate do you give the spi core?
<tnt> atm, 12 MHz
<tnt> I haven't put a pll in that design yet so it's just the xtal frequency.
<emeb> so 3MHz SPI sclk then
<tnt> yes
<tnt> apparently you need to at least divide by 4.
<emeb> I read something about that - has to do with the auto CS logic IIRC
<tnt> the 'cs hold' thing ... but ... if you don't use that feature, the core is basically unusable AFAICT because if it doesn't have any new data to TX, it just repeats the previous one !?!?
<emeb> ugh - "feature"
<tnt> mm, you can actually divide by 3, that still works. div-by-2 doesn't.
<tnt> but ... tha really just increase the dead time, so not much point.
<tnt> Anyway, I don't really care about speed here, I just wanted to be very small and use basically no-logic. If I wanted a high efficiency core, I'd use quad-spi ddr mode and all that stuff.
sgstair has joined ##openfpga
<emeb> heh, yeah.
<emeb> iirc you're trying to get access to read the flash chip for loading data after the system has started up.
<emeb> since the original spi ifc in cliffords picorv just worked at init time
<tnt> the spi in the picrorv does XIP so it can execute code from flash, but it's not super fast to do so and the core is also not that small. I have a risc-v design where I put my own minimal spi flash loader to 'boot' the picorv32 from flash (preloading a spram).
<tnt> But here it's not actually for the picorv32 but for my own 16-bit softcore.
<emeb> ah ok
<tnt> It has a 'peculiar' bootsequence :
<tnt> Basically it can only execute code from its main SPRAM.
<tnt> but of course ... it's not initialized, and I didn't want to pay the code of another mux in the adress path for boot.
<emeb> make sense
<emeb> interesting - was just looking at the docs for the i2c and spi WRT the BUS_ADDR74 - seems there's a documentation error
<tnt> So, for program space it has a SPRAM + a 16 word ROM. That ROM is the first-stage-boot-loader. It reads the 256 words from the data ram (which is initialized) and copies it to the program ram using the cpu itself.
<emeb> they have the same BUS_ADDR74 value 0b0001 listed for both a SPI core and an I2C core.
<tnt> And then that 256 words is the second stage bootloader which will use the hard-spi IP to populate the rest of the SPRAM with the full app from flash.
<tnt> Yeah, that doc error is documented , I've seen a comment when implementing it.
<emeb> ok
<tnt> btw, I also connected the LEDDA_IP, it's fun to make the led breathe with no cpu involvement beyong loading registers.
<emeb> hah, cute.
<emeb> I've not played with that.
rohitksingh has quit [Ping timeout: 246 seconds]
dingwat has left ##openfpga [##openfpga]
<emeb> w00t - getting activity on spi cs & sclk.
mietek has joined ##openfpga
<emeb> cs looks like it needs a pullup though - goes hi-z when inactive.
<emeb> must have misunderstood the MCSNO0 / MCSNOE0 hookups
<mietek> why is level shifting such a difficult topic?
<emeb> depends what you're level shifting
<mietek> bidirectional 5V and 3.3V
<tnt> emeb: I enable the IO pull up.
<emeb> makes sense
<tnt> emeb: other option is to actualy not use the OE signal at all and force CS to always be an output.
<emeb> tnt: that's what I was thinking, but pullup works too.
<emeb> tnt: or make the OE depend on master/slave hookup.
<emeb> but that would need separate control bit.
<emeb> but since I don't plan to use slave mode...
<mietek> people seem to keep saying that there are no good off-the-shelf bidirectional level shifters
<emeb> mietek: it's a tough problem
<mietek> but what about something like the TXS0108?
<mietek> it’s supposedly designed to deal with open-collector
<emeb> mietek: those are useful mostly for open-drain signals like I2C
<mietek> yes, i need to deal with an open-collector bus signal
<tnt> mietek: don't use bidirectional auto-sensing converters.
<mietek> why?
<mietek> what’s wrong with a product that seems to be made precisely for this use case?
<tnt> the metric shit-ton of small prints in the datasheet that if you misread or misunderstand one will screw up your application.
<tnt> dedicated i2c converters being the 'exception' (but they're often not general purpose bidir converters, they're _meant_ for i2c and nothing else).
<mietek> okay. so do you suggest a direction-controlled level shifter?
<tnt> and even then you better be careful.
<emeb> if you know the direction then it's a better sol'n
<emeb> no ambiguity
<tnt> mietek: what's the application ?
<mietek> "open-collector signal pulled up to +5V"
<tnt> ok, so open collector is actually the easy case.
<tnt> the circuit in the sparkfun board should work fine.
<tnt> but for instance a TXS0108 would definitely not because somewhere in there it says "oh yeah if you have any pull ups on the line, this isn't going to work".
<tnt> (oh, I might have that chip confused though)
<mietek> people say the sparkfun circuit is too slow
<mietek> ADB is pretty slow
<mietek> but i don’t know if it’s slow enough
<tnt> what do you want to connect it to ?
<tnt> because you might not even need any of this ...
<tnt> like if it's to connect to a fpga or to a uc, just use two IO. One driving a mosfet if you want to force it low and another IO as input through a divider to 'sense' the current state.
<mietek> that may seem simpler to you, but i only understand some of the words you used :)
<mietek> a teensy 3.6 acting as a USB host
<mietek> it operates on 3.3V
<emeb> doesn't teensy have 5V tolerant I/O pins?
<mietek> not this one, unfortunately
<mietek> you can see it on https://www.pjrc.com/teensy/
<mietek> and only this one can be a USB host
<tnt> if you look at page 293 of the book you sent, that's actually exactly what they're doing.
<tnt> you have one of the teensy output connected to a transistor or nmos to pull the line low, that's your "output pin".
<tnt> And then through a resistor divider, you can sense the current state of the line while ensuring your teensy never sees more then 3v3. That's your "input pin".
<mietek> the circuit in the book works with 5V signals, right?
<mietek> i understand there are two output pins, marked ADBO and /ADBO
<mietek> for reference:
<mietek> tnt: by "nmos" you mean n-channel MOSFET?
<tnt> yeah.
<tnt> mietek: yeah, forget ABDO ... not sure why they even have it. /ADBO is what I meant.
<mietek> okay, and 2N3904 is a transistor
<mietek> unfortunately i have lots of stupid questions
<tnt> yeah, but I'd recommend to go with a mosfet. I guess back in their days, it was TTL stuff ...
<mietek> i appreciate your advice, but i don’t know enough to apply it.
<mietek> you seem to be saying, pick any mosfet
<tnt> pretty much yeah.
<tnt> just sear 'small signal nmos' in whatever package you want and 99.9% chance that the cheapest will work just fine.
<tnt> you need to switch 10 mA at 125 kHz ... it's not exactly pushing the limits of modern tech.
<emeb> tnt: have your patches to nextpnr for the SB_SPI and SB_I2C been accepted in mainline yet?
<mietek> tnt: http://aldinc.com/pdf/ALD1105.pdf ? comes in PDIP so easy to handle without a board
<mietek> also has both N-channel and P-channel, and i don’t know which one is needed
<tnt> emeb: no PR is still open
<tnt> mietek: that's a 4 eur precision matched pair.
<tnt> mietek: 2N7000
<tnt> or BS170
<tnt> although ideally we'd need to extract the timing data ...
<tnt> I have no clue how to do that though.
<emeb> tnt: yeah - fortunately things seem to work w/o it.
<emeb> tnt: pushed my SPI changes into my github repo -> https://github.com/emeb/up5k_basic/blob/master/src/system_bus.v
<tnt> emeb: btw, I found out recently you can do stuff like https://pastebin.com/pDaguhes
<emeb> tnt: ah nice - arrays of instances.
Forty-Bot has joined ##openfpga
<emeb> I used those long ago but forgot about it since lately I mostly do infers
<mietek> tnt: does the nmos need to be connected through a resistor as in the circuit from the book? (1 kOhm there)
<mietek> tnt: what is the function of the 470 Ohm resistor in the circuit? (it‘s not for voltage division there, right)
<Forty-Bot> I am trying to add verilator to my project, but it isn't referring to my sources correctly https://bpaste.net/show/14d82c28b204
<Forty-Bot> specifically, -Mdir does not appear to add any prefixes to the sources
<Forty-Bot> one option would be to use absolute paths when specifying sources, but perhaps there is a verilator option I am missing
<emeb> I've got a "lint" target in my makefile that uses Verilator
<emeb> pretty simple setup, but it works.
<Forty-Bot> emeb: the verilator bit works; it's using the generated makefile that's the problem
<emeb> uses relative paths from working dir though - not quite what you're trying to do.
<emeb> ah - I'm just linting - not using the output.
<ZipCPU> Forty-Bot: I rarely use the -exe option, choosing instead to run a separate compile for the Verilated sources
<Forty-Bot> hm, I was just modifying this from the example makefile they provide
<Forty-Bot> ok, so when you call verilator without --exe it compiles some stuff and then archives it
<Forty-Bot> so how would I run tests?
<tnt> mietek: no you skip the 1k
<tnt> mietek: the 470 ohm is the pull-up for the open-drain bus
<ZipCPU> Forty-Bot: The tutorial discusses that in detail.
<ZipCPU> By the end of the 3rd lesson, you should be a bit more comfortable. The lessons themselves consist of Verilog + Verilator + SymbiYosys.
<Forty-Bot> ok, so you compile your testbench and link it against the .a?
<Forty-Bot> then run that part
<mietek> tnt: okay, thanks. i see i can use a pair of 1680 ohm and 3240 ohm resistors for the voltage divider. i understand the voltage divider will go between the pull-up and the bus, right?
<ZipCPU> Forty-Bot: Yes. That's how I do it.
Asu` has joined ##openfpga
<tnt> mietek: huh .. no ? it'll go from the bus to GND and the midpoint to the teensy. Also given the bus is not that low impedance (470 ohm) you want a diviver much higher, something in the 10k-100k range.
<mietek> tnt: could an internal pull-up work here?
<tnt> mietek: no
Asu has quit [Ping timeout: 250 seconds]
<mietek> tnt: so you’re saying, use something like 17k and 33k resistors for the divider, and what value for a pullup?
<tnt> 470 ohm
<mietek> thanks. any recommendations for what to read so that i can avoid asking such basic questions in the future?
Cerpin has joined ##openfpga
<tnt> No idea ... I learned all the basic stuff when I was barely a teen, in the days of electronics magazine by reading up the circuit descriptions of the projects they published each months .... (and then later on a few electronics courses at uni).
<tnt> I'm not sure if there still are magazines like that.
<tnt> elektor still exists but not sure about the content.
<mietek> right
<tnt> I think I heard good things about "Learning the Art of Electronics"
<mietek> what should be the wattage of the resistors?
<tnt> well .. U = R * I and P = U * I and R = 470 ohm, U = 5V so you get P from that
ym has quit [Remote host closed the connection]
<mietek> i see. thanks again
<tnt> Just looked at the online preview of that book and it indeeds seems to be very nice and cover a wide range of topic going all the way to verilog as well ...
<mietek> unrelated: when a desoldering bulb fills up, is it meant to be thrown away, or is there a clever way to empty it?
<tnt> what's a desoldering bulb ?
<mietek> https://pinballrehab.com/images/articles/terryb/desoldering-tools.jpg — like the red thing in this picture
<mietek> i found it easier to use than a solder sucker (the big thing)
<tnt> huh, never saw that before, no idea.
<azonenberg> i used to use suckers a lot
<azonenberg> now i use braid for everything
<azonenberg> works so much better
<tnt> yeah I use braid and actual desoldering gun for through-hole
<emeb> mietek: usually the solder in a sucker/bulb is kinda powdery. You should be able to just shake it out.
<mietek> hmm.
<whitequark> azonenberg: there is a serious issue with braid
<whitequark> tearing off the pads if it gets stuck to the pad because of heatsinking
<whitequark> suckers can't really do this by design
<azonenberg> whitequark: that's why you don't put any force on the braid
<azonenberg> hold loosely with tweezers and move super gently
<mietek> i also use braid, and it does get stuck sometimes
<azonenberg> yes it gets stuck
<azonenberg> But as soon as that happens you take corrective action, you don;'t force it
<mietek> it’s true, i haven’t pulled off any pads with the braid yet
<azonenberg> I think it's more of a technique issue than a tooling issue
<azonenberg> i'm not denying it can happen, but i consider that operator error
<mietek> on the other hand, i like the desoldering bulb for removing larger amounts of solder
<mietek> which would involve using a large amount of braid
<azonenberg> also it's very hard to get super planar results with a sucker
<azonenberg> e.g. for putting a BGA down on top
<mietek> so, first the bulb, then the braid
<azonenberg> or even a QFN
<mietek> i’m mostly reworking old things. so it’s through-hole and sometimes it really doesn’t want to let go without a large amount of added solder
<azonenberg> ah ok, yeah i do almost 100% SMT these days
<azonenberg> when possible i don't even use QFP/SOIC/SOP
<azonenberg> QFN and BGA are my preferred packages
<tnt> 01005 standard passive size too ?
<azonenberg> tnt: no, lol
<azonenberg> my default passive is 0402, i freely use 0201 when given a good reason
<azonenberg> for example in FREESAMPLE an 0201 is a pretty close match to my 50 ohm traces
<azonenberg> so i dont need to do any plane cutouts to impedance match
<whitequark> 18:36 < azonenberg> whitequark: that's why you don't put any force on the braid
<whitequark> accidents happen
<azonenberg> i also am using 0201 for parasitic reasons decoupling some 0.5mm QFNs on the top layer to get super small loop areas
<whitequark> like, you don't need to want to put force on the braid, your hand can twitch a bit
<whitequark> and the pad is gone
<azonenberg> whitequark: maybe your hands are shakier than mine?
<azonenberg> not a problem i've ever observed
<azonenberg> Not saying you're wrong, but i havent seen it happen
<whitequark> azonenberg: clomipramine gives me severe hand tremors, and even without that it happens occasionally
<whitequark> it'll also become worse with age
<whitequark> anyway, there's really no replacement to braid for SMT work
<whitequark> but i wish there was
<whitequark> cranking up the heat does help to an extent
<whitequark> but that tends to go very badly on old PCBs as well
<TD-Linux> yeah I've also taken pads off with braid. it's rare and kinda depends on the pcb construction
<TD-Linux> suckers are hard to beat for through hole though
<azonenberg> If you're using cheap boards or excessive heat, pads are more likely to delaminate
<azonenberg> TD-Linux: yeah i just avoid PTH like the plague these days :p
<whitequark> azonenberg: i do not have the choice of which boards to use
<whitequark> when i rework some weird shit from 10 or 20 years ago
<whitequark> azonenberg: most of the time when i rework BGA
<whitequark> it's because i don't know the PCB layout and/or the ballout
<TD-Linux> some sort of jig to hold the braid on both sides to pull it away without peeling action might b nice
<azonenberg> whitequark: yeah very different set of problems
<azonenberg> most of my rework is ECOs on buggy brand-new designs
<whitequark> azonenberg: also you can spend basically inf$ on your designs
<azonenberg> whitequark: what, and m-labs stuff is cheap?
<whitequark> your budget on one PCB is more than my yearly PCB budget
<whitequark> oh, i don't do hardware design for m-labs
<azonenberg> i've seen the giant fpgas sb0 puts on those things
<Forty-Bot> ended up just using absiolute paths
<whitequark> yeah no, those things cost many thousands of dollars
<Forty-Bot> let verilator handle the -Is
<whitequark> and work quite badly anyway
<azonenberg> Lol
<whitequark> rgmii clock on a non clock capable ball...
<azonenberg> ...
<whitequark> then a rework that would cause different boards to have non-matching phase
<azonenberg> Anyway, FREESAMPLE is going to be an expensive board, no doubt about that, but also consider how long i've been working on it
<whitequark> then some vivado bug that would make it work only when the mmcm is constrained to one specific loc
<whitequark> and even then needed a lot of brute force
<azonenberg> The original numerical modeling of the design started in mid November
<whitequark> doesn't make me work with xilinx tools any more
<azonenberg> And I probably won't have the board done and ready for tapeout until mid April at the earliest
<azonenberg> That's five months for one board, so $1K of parts amortized over that is only $200 a month - and that's before you consider that I'll be getting samples from AD for a $200 delay line and probably some other high-dollar parts
<azonenberg> So it will probably only cost me $600 or so plus the PCB
<azonenberg> For somebody on a full time tech income $600 amortized over five months is pocket change
zem has quit [Ping timeout: 255 seconds]
zem has joined ##openfpga
m4ssi has joined ##openfpga
<tnt> daveshah: is the meaning of TMG_xxx explained somewhere ? Like what's TMG_ENDPOINT for instance ? I thought that was 'lookup in the timing.txt file' ...
m4ssi has quit [Remote host closed the connection]
<tnt> tx
m4ssi has joined ##openfpga
<emeb> tnt: lol @ driving the SB_SPI via BASIC. So. Very. Slow. :P
sorear has quit [Ping timeout: 252 seconds]
sorear has joined ##openfpga
pointfree has quit [Ping timeout: 252 seconds]
pointfree has joined ##openfpga
lutsabound has quit [Quit: Connection closed for inactivity]
lutsabound has joined ##openfpga
<tnt> emeb: lol
<tnt> emeb: with peek/poke or did you add custom commands to the basic ?
<emeb> tnt: peek/poke :)
<emeb> I actually did write some assembly to do it too.
Laksen has quit [Quit: Leaving]
Asu` has quit [Quit: Konversation terminated!]
m4ssi has quit [Remote host closed the connection]
grantsmith has quit [Quit: ZNC - http://znc.in]
grantsmith has joined ##openfpga
futarisIRCcloud has joined ##openfpga