emeb_mac has joined ##openfpga
futarisIRCcloud has joined ##openfpga
<bubble_buster> daveshah: as an update on LegUp: I emailed prof Anderson and Andrew Canis about opening up a github repo for LegUp, they said no because they're concerned about commercial use
<TD-Linux> the license was already a nonstarter wasn't it?
<bubble_buster> the license says can't be redistributed without written permission
<bubble_buster> so I'm seeking written permission
<bubble_buster> I've responded that I could include their license in the repo which should afford the same protection as the current setup - code is available to download from a website and the license is clearly visible when you download
azonenberg_work has joined ##openfpga
<TD-Linux> hmm speaking of licenses I didn't read the ulx3s license closely and it's kinda weird
<TD-Linux> The logotypes "EMARD", "RADIONA" and "FER" shall remain unmodified, visible, and in the original location, shape and size on the top PCB silkscreen layer.
<TD-Linux> what does that mean for the footprint libraries
azonenberg_work has quit [Ping timeout: 245 seconds]
unixb0y has quit [Ping timeout: 246 seconds]
unixb0y has joined ##openfpga
zng has quit [Quit: ZNC 1.7.2 - https://znc.in]
flea86 has joined ##openfpga
zng has joined ##openfpga
<Finde> bubble_buster: my groupmate asked in person at OSDA and was told they don't have any intent to change the licence either :(
emeb has left ##openfpga [##openfpga]
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 250 seconds]
<azonenberg> bubble_buster: so basically the project is dead
<bubble_buster> their project or my project?
<azonenberg> Theirs
<azonenberg> Stuck in commercial hell
<bubble_buster> ah, the open source version, pretty much, though they did say they were interested in publishing my version
<bubble_buster> but yeah, they're still actively developing it, just not as open source
<bubble_buster> I would hope that after several years of closed-source development by a team of programmers, they wouldn't be worried about competition from the older version with a restrictive license attached
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
zem has quit [Ping timeout: 246 seconds]
zem has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
m4ssi has joined ##openfpga
qualia has quit [Ping timeout: 245 seconds]
qualia has joined ##openfpga
OmniMancer has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
catplant has quit [Remote host closed the connection]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
OmniMancer has quit [Quit: Leaving.]
rohitksingh_work has quit [Read error: Connection reset by peer]
genii has joined ##openfpga
rohitksingh has joined ##openfpga
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
zem has quit [Ping timeout: 250 seconds]
zem has joined ##openfpga
emeb_mac has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fjLti
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 6e44cfb - gateware.i2c: load new data after each byte is read.
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 6516cb8 - gateware.i2c: fix fencepost error in reads.
<_whitenotifier-1> [Glasgow] whitequark commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLtd
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fjLqI
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark e54f293 - gateware.registers: generalize to any bit width.
grantsmith has quit [Quit: ZNC - http://znc.in]
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjLqo
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark ffbae8a - applet.internal.benchmark: add a counter, for debugging.
grantsmith has joined ##openfpga
grantsmith has quit [Changing host]
grantsmith has joined ##openfpga
emeb has joined ##openfpga
ayjay_t has joined ##openfpga
emeb_mac has quit [Remote host closed the connection]
<_whitenotifier-1> [Glasgow] marcan commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLmO
<emeb> daveshah: I just ran icebox_vlog on a up5k design with SB_SPI in it, but there was no SB_SPI instance in the resulting structural verilog. Is that unsupported?
<daveshah> Indeed it is unsupported
mwk has quit [Disconnected by services]
<emeb> daveshah: OK, thx. Not a big deal. I'm trying to debug a situation where some signals out of the SB_SPI block appear to be incorrectly miswired. My verilog input appears correct and the outputs taken individually seem OK, but when they're run through an IOB to generate a bidir signal some of them seem to be tied together.
mwk has joined ##openfpga
<tnt> emeb: icebox vlog should still contains all the wires and so you see what's connected where.
<emeb> tnt: yes, it does - I can see that that mo/moe & so/soe signals are unique and connect to separate IOB equivalent ckts.
<tnt> below each wire you have comments with all the internal names like 'sp4_r_v_b_33' ... and in the chipdb.tx you can find the correct SB_SPI and see which port is connected to what.
<tnt> emeb: are you sure your issue is not programming the core incorrectly ?
<emeb> tnt: I'm wondering about that. I looked through the appnote to see if there was a control setting that would make MISO = MOSI
<emeb> didn't see anything obvious.
zkms has joined ##openfpga
<tnt> well there is the bit that controls if the core is in master or slave move.
<tnt> s/move/mode/
<emeb> Yes - I am setting that for master mode
<emeb> and I can see that the SOE signal is not asserted
<emeb> yet the MISO output is being driven!
<tnt> are you sure it's not just the pullup ?
<tnt> also, how do you know it's driven ?
<emeb> because I put a 560ohm resistor to ground on that pin and then watch it with the scope
<emeb> and it's got strong hi/lo levels
<tnt> and it's not whatever slave device you have on the bus driving it ?
<emeb> that perfectly follow the MOSI pin
<tnt> ... or a short
<emeb> I routed that signal to an unused pin
<emeb> the behavior follows the signal, regardless of which pins I route it to
<emeb> So then I tied the off the output enable on the IOB instance and then I see correct behavior - high impedance on the signal (as verified w/ a resistor load) and proper reading of input state.
<emeb> So my workaround is to tie that OE signal off and force that pin to be input. Since I don't plan to use this in slave mode for this application that's not a problem.
<emeb> But it does make me wonder what's going on.
<tnt> emeb: what do you write to CR1 ?
<emeb> SPICR1 = 0x80
<emeb> SPICR2 = 0xc0
<tnt> emeb: is your code on github ?
<tnt> (the hw)
<emeb> and the software driver is here -> https://github.com/emeb/up5k_basic/blob/master/cc65/spi.s
<tnt> scsni_0 should be hardwired to 0
<whitequark> i'm curious, why are you using SB_SPI?
<tnt> it's only for when the core is used as slave.
<emeb> whitequark: because it's there. :)
<tnt> whitequark: it connected to the internal wishbone, takes no logic and I use it purely for initial boot and DFU so perf doesn't matter and I'd rather spare the LUTs.
<whitequark> ahhh you're connecting it to wishbone
<whitequark> that makes sense i guess
<tnt> yeah, using it outside of a softcore would make no sense ... you'd waste logic just to create all the logic to write to the bus you might as well do spi manually.
<emeb> tnt: tying scsni = 0 doesn't fix the issue
<tnt> really ? well that's a surprise ... (because that line pretty much directly ties to the MISO OE signal ...)
<emeb> tnt: docs say it's active low. trying it w/ 1
<emeb> tnt: hah! that fixed it.
<emeb> what did you do in yours?
azonenberg_work has joined ##openfpga
<emeb> tnt: looked at your code (from yesterday's link) - you tied it to 1 also.
<tnt> Oh yeah, misread the logic, nm :p
<emeb> :)
<emeb> tnt: thanks for the review & help. all better now. \o/
rohitksingh has joined ##openfpga
<tnt> emeb: np. The radiant sim models have proven useful in understanding ... many of the 'reserved' bits actually do things :p
<tnt> like for instance if you set 0x04 in CR1 that would disable the scsn signal via software.
<emeb> tnt: aha - I haven't looked at those yet. sounds like they're a good resource.
<emeb> tnt: so CR1 bit 2 would be equivalent to tying scni = 1?
<tnt> yes
<emeb> sounds like that would be a good thing to have documented :P
<tnt> (at least according to the sim model ... maybe they don't match the actual hw).
<emeb> I'll give it a try.
<emeb> tnt: CR1 bit 2 works as you suggested.
<emeb> so I can leave scsni hooked up and set that bit in the init routine and leave slave mode as an option w/o rebuilding the bitstream.
<tnt> :)
<emeb> now just need to figure out why I can't talk to the SPI flash chip - sending command AB to read ID doesn't seem to work.
<tnt> emeb: did you use the -s option to icepack ?
<tnt> to prevent the ice40 from putting the flash chip into deep-sleep ?
<tnt> (else you need to first send wake up command)
<emeb> tnt: ah, no.
<emeb> but ISTR that AB is supposed to be a wake-up too. Need to revisit.
<tnt> Ah yeah, indeed AB is the wakeup command :p
Asu has joined ##openfpga
<emeb> ok - ID working. wasn't providing enough dummy clocks. :P
<emeb> and -s was not needed - sufficient duration after AB cmd to dummy clocks that it meets wakeup time.
<emeb> (in my application at least)
m4ssi has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 250 seconds]
OnlineDater has quit [Quit: Leaving]
<_whitenotifier-1> [Glasgow] electroniceel synchronize pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjI5Z
<emeb> tnt: running CPU and system bus clock at 16MHz best SPI rate I can get is ~ 4.5us/byte
<_whitenotifier-1> [Glasgow] electroniceel commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLsG
<emeb> tnt: delays due to SPI baud rate divider of 3, wishbone bus ACK delay of 2 clocks for every transaction and 6502 instruction (in)efficiency.
<emeb> tried faster SPI clocks w/ lower baud rate divider but the SPI core starts doing weird things.
<emeb> So, stuck with ~200kBps
* emeb ponders SPI DMA. ;)
<Hellsenberg> sounds cursed
<tnt> emeb: what's the clock rate of the 6502 ?
<emeb> tnt: also 16MHz
<tnt> well, you should be able to at least reduce that to 2 us or so in burst.
<tnt> but after that that's just the max speed of a 4 MHz SPI bus ...
<tnt> only option would be to run the spi core faster and cross clock.
<tnt> but as I mentionned, this is definitely not performance oriented. For that you might want to look at either zipcpu's core of the one in the picorv32.
<emeb> tnt: yeah - with some loop unrolling in the driver code, etc. it might be possible to make it go faster.
<tnt> emeb: what does your sw looks like ?
<tnt> oh nm, saw the link above.
<tnt> Ah yeah, that's not optimal
<tnt> you need to basically "queue" one TX in advance to RX.
<tnt> so for 4 bytes it'd be : TX TX RX TX RX TX RX RX
<tnt> this minimizes the dead time on the SPI bus itself.
<emeb> I see.
<emeb> that requires some fancy pointer work in the buffer load/store operations that might cancel out the bus queueing benefits...
<emeb> but worth playing around with for giggles.
<tnt> I tested that and I can get almost no dead time. However in the end, I reverted to only using RXRDY just for simplicity and because I didn't care about the perfomance. I only load 32k at boot time.
<emeb> yeah - it's mostly an academic exercise.
<emeb> I'm not under any time constraints.
<tnt> What I did is also write a dedicated 'flash read' that just sends the command and address (and doesn't care about the RX bytes), then TX only 0x00 and does RX bytes only.
<emeb> Yeah, for unidirectional transactions you can definitely optimize.
<_whitenotifier-1> [Glasgow] marcan commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLs6
<_whitenotifier-1> [Glasgow] whitequark commented on pull request #120: revC1: add io port pinout to back silkscreen - https://git.io/fjLsi
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
wpwrak has quit [Ping timeout: 245 seconds]
wpwrak has joined ##openfpga
<bubble_buster> just went to a talk on using majority-inverter graphs instead of and-inverter graphs for synthesis https://msoeken.github.io/papers/2016_nanoarch.pdf
<bubble_buster> they get exciting improvements in timing and area over traditional AIG/BDD methods
<bubble_buster> might be interesting to try in yosys
<whitequark> how does it compare to LUT synthesis?
<whitequark> oh I see, it's not an FPGA tech
<whitequark> emily: ^
<emily> :o
<bubble_buster> it's interesting, they actually figured out they could use multigate transistors to make very efficient standard cells for things like xor and majority which are bulky in CMOS
<bubble_buster> so they came up with this new MIG logic to synthesize for those cells
<bubble_buster> then they realized it actually improved results for standard CMOS libraries too
<bubble_buster> so maybe it has potential for LUTs? idk
<daveshah> iCE40 carry logic is a majority function
<daveshah> fwiw
<bubble_buster> the logic gives a path to every equivalent expression, which AIG/BDD does not
<bubble_buster> so it's easier to search the space
<whitequark> bubble_buster: the nice thing about LUT synthesis is that it's polynomial time
<bubble_buster> like the mapping part?
<whitequark> yeah
<bubble_buster> I think there are earlier stages of synthesis which use AIG/BDD/other models which would be agnostic to LUT vs CMOS
<whitequark> well I'm trying to avoid going through AIGs
<whitequark> sure, you could use AIGs and then map them to LUTs, but you could also not do that in the first place
<whitequark> which makes a few things nicer
<bubble_buster> I see
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
genii has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
emeb_mac has joined ##openfpga
genii has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+1/-1/±4] https://git.io/fjLZd
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 2520d9f - fx2.FX2Arbiter→fx2_crossbar.FX2Crossbar
genii has quit [Remote host closed the connection]
futarisIRCcloud has joined ##openfpga
Bike has joined ##openfpga
_whitelogger has joined ##openfpga