hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
mumptai_ has quit [Read error: Connection reset by peer]
mumptai_ has joined ##openfpga
emeb has joined ##openfpga
jaseg has quit [Ping timeout: 246 seconds]
jaseg has joined ##openfpga
parport0 has quit [Ping timeout: 258 seconds]
OmniMancer has quit [Quit: Leaving.]
parport0 has joined ##openfpga
parport0 has quit [Ping timeout: 256 seconds]
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined ##openfpga
jfcaron_ has joined ##openfpga
kmehall_ has quit [Remote host closed the connection]
kmehall has joined ##openfpga
parport0 has joined ##openfpga
<emeb>
More interesting things in the tale of the SB_I2C core - using the first core (address 7:4 = 0001) I had SDA and SCL routed to pins 45/47 of the sg48 package and any time I put a load on the SCL pin (even just a 10:1 scope probe) the outputs would get trashed. SCL would not stop running and SDA data was garbled. With unloaded SCL the SDA data looked right.
<emeb>
Seemed like there was some sort of timing issue on SCL, so for grins I relocated the outputs to pins 21/19. Now loading the SCL pin doesn't cause problems.
<emeb>
So the lesson here is that the SB_I2C core seems to rely on the SCL signal feedback for some of its internal timing and if the routing delay isn't what it expects then you'll get bizarre behavior.
<tnt>
Note that all timing info is missing for SB_I2C (among other).
<whitequark>
wtf
<tnt>
No one bothered to extract it and fill it in icestorm ...
<tnt>
and to support clock stretching I would expect the core to have to look at the SCL state indeed.
<emeb>
FWIW I've got clock stretching disabled in the control reg.
<tnt>
and you instanciated the SB_IO ?
<emeb>
Ys
<emeb>
yes
<tnt>
weird ... I mean, a 10:1 probe shouldn't even change the state of the pin.
parport0 has quit [Ping timeout: 256 seconds]
<emeb>
exactly - just changes the slew rate slightly
<whitequark>
so many bugs in i2c cores
<tnt>
Wait ... 45/47, aren't those the RGB outputs ?
<emeb>
no - those are 39/40/41
<tnt>
Oh ok, sorry, bad memory on my part.
<daveshah>
There are supposed to be some dedicated connections between the I2C core and some pins in silicon
<daveshah>
They are never used by icecube, so not in icestorm/nextpnr either
<daveshah>
This is apparently because they forgot a level shifter
<emeb>
interesting. ISTR that the Ultra parts had a special I2C deglitcher core too.
<emeb>
but not the Ultra Plus
<daveshah>
so would result in damage if used (apparently only if the I2C pullup resistor was on the strong side but idk if this is true from my knowledge of the IO structure)
<emeb>
oh fun!
<daveshah>
the source for this is not the most reliable person in the world, and probably the story came through a couple of FAEs
<daveshah>
so I wouldn't guarantee it's accuracy
<emeb>
there are many stories.
<daveshah>
but it is definitely true that there is some evidence of dedicated I2C pin routing, that is never used by icecube, based on some of the config bits names
<emeb>
need to get Ken Shirriff to do some RE on the die to find out where it goes.
<daveshah>
cbit2usealt_in_0 and 1 in some IO tiles - seems like the fabric route is considered the "alternate" route compared to the broken hard route
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt>
Still waiting for die shots ... there was some teaser on twitter but never saw the full highres set.
<ross_s>
My assumption is that the localparam is sized to the width of the largest arg, instead of the resultant value
<ross_s>
so using it for comparisons against registers sized using the clog2 of its value is a warning
<ross_s>
which is somewhat irritating
<daveshah>
imo, requiring two sides of < to be the same width is overly fussy in the first place
<ross_s>
I agree, but verilator is quite fussy about it
parport0 has quit [Ping timeout: 264 seconds]
<ross_s>
I suppose I can do this
<tnt>
ross_s: the way I avoid that is to not use '<' :p instead I init the register to PRESCALER, then decrement it until the MSB overflow and that's the 'tick' output of your prescaler.
indy has quit [Read error: Connection reset by peer]
parport0 has joined ##openfpga
<emeb>
OK - with pins moved and an I2C device on the bus I can now see proper transactions and ACK/NACK behavior from the target. I2C driver code is not detecting the NACK condition though, so need to see what I'm missing there...
hackkitten has quit [Read error: Connection reset by peer]
hackkitten has joined ##openfpga
parport0 has quit [Ping timeout: 260 seconds]
<emeb>
working fine now - just a different combination of status bits to look for.
<TD-Linux>
press release based reverse engineering, 10/10
<emeb>
More SB_I2C fun - trying to get slave mode working. The documentation of the SADDR reg is horrible.
<emeb>
of the 7-bit bus address, the docs imply only bits 6-2 are used.
parport0 has joined ##openfpga
<emeb>
looks like a copypasta error from FIFO mode - just chopped the bottom 2 bits off.
<daveshah>
Yeah some of them are hardcoded iirc
<emeb>
Oh - so there are some addresses that are unusable then.
<emeb>
any idea what the hardcoded values are?
<daveshah>
01 and 10 for the LSBs
<daveshah>
based on a quick skim of the docs
<daveshah>
It depends on the physical location
<daveshah>
idk if nextpnr actually implements this properly
parport0 has quit [Ping timeout: 258 seconds]
<emeb>
OK thx. I'll try all combos
m4ssi has quit [Remote host closed the connection]
parport0 has joined ##openfpga
<emeb>
Seems like the fixed bits are behaving as expected. slave RX not very reliable, but it's working sometimes.
<daveshah>
I have absolutely no idea why Lattice thought fixing some address bits was a good idea
<emeb>
It's pretty silly. Makes these ports a lot harder to use.
<emeb>
I'm trying to make an emulator for another device with a fixed address and that means I can't use one of the cores for this application.
<daveshah>
At least you can use one of them
<emeb>
yeah
<daveshah>
There's a 50/50 chance neither work
<daveshah>
And emulating an existing device must be a fairly common use case for a small glue FPGA
parport0 has quit [Ping timeout: 260 seconds]
<emeb>
exactly
<awygle>
Oh wow I didn't realize that prjoxide was a) that much of a going concern or b) written in Rust lol
<awygle>
Is this your first major rust project dave? If so, how do you like it?
<daveshah>
I guess similar thoughts to a lot of people, some things are nice, some are a bit annoying
<awygle>
Well sure but that's just, like, life, yknow?
<awygle>
Anything in particular?
<agg>
ugh, why does the ecp5 12/25f bond out different pins than the 45f in the same package on a handful of pins...
Asu has quit [Ping timeout: 265 seconds]
emeb has quit [Quit: Leaving.]
Maylay has quit [Ping timeout: 240 seconds]
Maylay has joined ##openfpga
<mithro>
I just got a nice email from Xilinx -- "The request for the Xilinx Unisim Library to be published as open source has been hosted on GitHub with the Apache 2.0 license here: https://github.com/Xilinx/XilinxUnisimLibrary -- The repo is marked as ‘archived’, but it obviously can be forked for further development by the community. "