<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]
<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.
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.
<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>
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]
<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