Laksen has quit [Remote host closed the connection]
noobineer has joined ##openfpga
Stary has quit [Ping timeout: 252 seconds]
Stary has joined ##openfpga
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
edef has left ##openfpga [##openfpga]
dj_pi has joined ##openfpga
wren6991 has joined ##openfpga
<wren6991>
Oh, SB_IO behaviour was already well-known?
<wren6991>
I'm ignorant of this kind of thing, I was just going off the LP/HX datasheet!
<sorear>
it's not well known if it's just something in people's heads
<sorear>
it's not well known if it's only documented in the comments to one ticket in the old icestorm repo
OmniMancer has joined ##openfpga
gsi__ has joined ##openfpga
<wren6991>
Ah okay
<wren6991>
I guess equally it's not super well-known if it's just on one Yosys PR and in one simlib -- do we have even just a wiki to write this stuff down in?
gsi_ has quit [Ping timeout: 246 seconds]
noobineer has quit [Ping timeout: 255 seconds]
<wren6991>
For example I found out about the iCE40 BRAM power on issue by chance after seeing someone mention it on twitter, and then realised it explained difficulties I had bringing up a board (logic all seemed to work, BRAM contents invalid. Naturally assumed FPGA not at fault and checked everywhere else)
<wren6991>
Feels like there is a huge amount of knowledge in the community but it's hard to find some of it
<wren6991>
Ideally Lattice would publish errata but I'm not waiting for miracles :D
<dj_pi>
wren6991, your BRAM issues related to sequencing of the rails? i have never used lattice but i know with xilinx if you don't bring up the rails in the correct sequence it can lead to weird latching issues
<wren6991>
iCE40 just has the one core supply, and the VDDIOs
<wren6991>
The issue as I've seen described elsewhere is just that, if you access the BRAMs during the first 3 us after config, you get garbage
<dj_pi>
ah....then yeah....nevermind :)
<wren6991>
so you need a counter in your reset generator
<sorear>
that's what I was referencing with the second comment
<dj_pi>
yeah...was going to say...internal undocumented state machine at that point?
<sorear>
people other than me are bizarrely fine with this state of affairs?
<dj_pi>
i know with xilinx fifo's i've had to put in a delay before writing/reading data to them
<dj_pi>
(upon reset)
<wren6991>
sorear: ah I see what you meant. The problem is I have no idea how many of these things there are :D
<wren6991>
dj_pi: the rails were the first place I looked, and I tied myself in knots trying to get the ripple waaay down on my SMPS
<dj_pi>
yeah...i hear you man. i was about to populate the fpga portion of a board i'm bringing up and i ended up having a dead short on my supply to my pmic
<wren6991>
o o f
<dj_pi>
was about to start tearing apart the fpga portion but turns out it was a simple 8051 uC that i put on there where i hooked up what i thought was a VREF in to the uC which was actually VREF out
<wren6991>
what package was the PMIC?
<wren6991>
oh
<dj_pi>
was working for most of the board and it finally manifested...
<dj_pi>
i tore the PMIC apart piece by piece...even the connector....finally the only place raw power was going in was to this uC
<dj_pi>
i was able to jtag in to the fpga today as well as all the other devices on the board....so time for beers :)
<wren6991>
aaaaayyy
<wren6991>
congrats :)
<dj_pi>
thanks man
<wren6991>
what is this board?
<dj_pi>
it's for my main job...i can't really say much but i am working on high power inverter design
<dj_pi>
this board has a TI PMIC, SiLabs 8051, TI TMS320 uC/DSP, and Xilinx FPGA
<dj_pi>
along with a lot of other shit
<wren6991>
That is an intense amount of processing power and configurable logic for an inverter! Sounds like fun
<dj_pi>
thanks...yes...it is
<dj_pi>
it's kind of a 'platform' that can handle many different applications thrown at it
genii has quit [Remote host closed the connection]
Bike has quit [Quit: Lost terminal]
dj_pi has quit [Ping timeout: 246 seconds]
gsi__ is now known as gsi_
<tnt>
wren6991: then BRAM issue is actually in the lattice docs. There is one sentence somewhere that says you need to wait xxxx amount ... easy to miss :p
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<wren6991>
Wat
<wren6991>
let me look for that, I haven't seen it :D
<wren6991>
... Where? It's not in the LP/HX datasheet or the memory technote TN1250
<wren6991>
All I see is a comment about there being no reset on RDATA, which is expected
<tnt>
and I seem to remember at the time that I indeed found the reference, but I can't find it again :/
<emeb_mac>
that BRAM startup delay thing bit me too. daveshah set me straight.
<tnt>
I never noticed it :)... pretty much all my design have a PLL where I wait for the LOCK + reset counter.
<wren6991>
I also just scanned through the whole of TN1248 iCE40 Programming and Configuration
<wren6991>
nothing! Is it maybe added just to the UltraPlus datasheet as an ass-cover?
<wren6991>
tnt: ah. See I deliberately did not use a PLL during bringup as they need external power supply filtering and I wanted to cut down on unknowns.
<wren6991>
So I was hitting the BRAM on the first cycle after config
<wren6991>
Oh this is weird: "It is a known issue that iCE40 block rams do read zeros during the first few clock cycles when booting in SRAM mode (see cliffordwolf/icestorm#76)." https://github.com/cliffordwolf/icotools/issues/2
<wren6991>
I wasn't getting zeroes, I was getting garbage data, often it involved the first memory word repeated a few times, and then garbled mixes of memory words
<wren6991>
I stripped my design down to the point where it was just a BRAM, a counter and a bpmc modulator squirting BRAM data out of a pin. Never changed the results I got. I was configuring the iCE40 in slave mode
<wren6991>
Also that reference to the chat log leaves me with more questions. You need some number of dummy clocks on the end of your SPI config sequence, which I had. whitequark seemed to suggest these are related to BRAM access in some way? Does that mean that my logic is running before the end of the vendor-prescribed config process, and if so, wtf?
<wren6991>
Not mentioned here either: "SiliconBlue ICE™ Technology Library Version 2.3"
<whitequark>
that's how i interpreted those clocks
<whitequark>
but i am no longer convinced that's correct
<whitequark>
i may have just misinterpreted things, andprobably did in this case
<wren6991>
whitequark: :(
<wren6991>
It's not in the UP datasheet either
<wren6991>
either way I've looked through 5 pieces of documentation now and it ought to be in all of them
<tnt>
I'm wondering if the internal logic "starts" when CDONE goes high ... which would mean for instance that the logic starts before all the IOs are actually under user control.
<whitequark>
yep
<whitequark>
this is just... lattice
<wren6991>
tnt: yeah that's what I was wondering.
<wren6991>
It's not too hard to check but I am burnt out on this stupid BRAM issue
<whitequark>
that's understandable
<whitequark>
when i first hit it i added a global reset more or less at random
<wren6991>
* wren6991 lied, he wants to check
<whitequark>
and lucked into having working designs without knowing the exact reason
<wren6991>
damn how do I do that asterisk thing
<whitequark>
/me
* wren6991
<wren6991>
nice
<whitequark>
I think CDONE is the same signal as the one that enables IO to be under user control
rohitksingh has joined ##openfpga
<whitequark>
but I'm not sure how this interacts with clocks
<wren6991>
whitequark: that's good to (potentially) know. I was going to just stick in a bitstream that did various things to some pins and then do a capture of that against the config interface
<wren6991>
e.g. a 1 pin, a 0 pin and a toggling pin
<wren6991>
I need to go and solder some wires back onto my tinyfpga bx though
<whitequark>
there's definitely a signal that enables IOs to be under user control
<whitequark>
I'm not 100% sure it's the same as CDONE
<whitequark>
but it seems logical
<wren6991>
It rings a bell wrt something in TN1248
<tnt>
not for the dual use pins.
<wren6991>
TN1248 page 7:
<wren6991>
The PIO pins activate according to their configured function after 49 configuration clock cycles. The internal oscilla- tor is the configuration clock source for the SPI Master Configuration Interface and when configuring from Nonvola- tile Configuration Memory (NVCM). When using the SPI Peripheral Configuration Interface, the configuration clock source is the SPI_SCK clock input pin.
<tnt>
actually not for the others either.
<tnt>
wren6991: go to the bottom of page 2.
<tnt>
the "normal" ios will be released after 17 cycles.
<wren6991>
oops my bad, thank you
<tnt>
But what I don't know if is the internal logic starts directly after CDONE is high or if there is a delay as well.
<wren6991>
It's easy to check
<wren6991>
Have an LFSR attached to a pin
<wren6991>
observe first n bits coming out of the PIO
<wren6991>
that tells you LFSR state, which tells you how long it has been running
<whitequark>
tnt: ohhhhh
<whitequark>
17 clocks
<wren6991>
or a counter I guess too :)
<whitequark>
tnt: well that explains some behavior i have seen.
<whitequark>
thanks.
<whitequark>
i can't read.
<wren6991>
me neither apparently
<whitequark>
in fairness, lattice's docs require a PhD in reading.
<wren6991>
a postdoc in patience
<wren6991>
Just realised the HX8k-EVN has a jumper for disconnecting SS_N from the flash. Uh? I thought it was sampled on rising edge of CRESETN only
<wren6991>
And I remember thinking "hey that's a really smart design, it means you can leave the flash permanently disconnected and just deassert SS_N"
<whitequark>
i'm not sure i get it
<wren6991>
If you have a board with a SPI flash on it for bitstream, but you want to do slave-mode config as well
<wren6991>
the sequence would be CRESETN low, SS_N low, CRESETN high, SS_N high
<wren6991>
and now FPGA is in slave mode and flash is deselected
<wren6991>
I thought that was their intention, but the board guide tells you to disconnect the flash CS
<wren6991>
It's like the ASIC guys did something really smart but it was lost in internal communication
<tnt>
mmm, interesting, I had never noticed that this was possible ...
<whitequark>
ooh
<emeb_mac>
I've been doing that on my board for a while. works just fine.
<emeb_mac>
but I've also found that I don't need to disconnect the flash CS and I can still slave config the FPGA since in slave mode the FPGAs SO line never wiggles the flash doesn't see any valid commands to get on the bus and thus there's no contention.
<wren6991>
Oooh that's true
<emeb_mac>
on the lattice devboard you still need to move the dual jumpers 90deg to swap the SO/SI lines though, so that's a bit of a PITA.
<emeb_mac>
I've got a custom SPI board in the works that has analog muxing in the SO/SI lines so that I don't have to manually move anything.
<emeb_mac>
(some MCUs have the muxing built-in, but the STM32 I'm using doesn't allow that)
<wren6991>
Yeah I don't get why they did that, can't you swap the input and output on MPSSE?
<emeb_mac>
dunno - my FTDI board went toes-up and I haven't gotten a new one.
<wren6991>
I was just looking at the schematic now cause I wanted to know if there was a testpoint for CDONE, that's all
<wren6991>
answer: no, time for soldering
<tnt>
no you can't swap pins in mpsee mode.
m4ssi has joined ##openfpga
<emeb_mac>
hmm... oshpark says they shipped my SPI boards. don't recall getting a notice. weird.
<wren6991>
But their approach is fingerprinting which bits have a predictable initial state at power on, independent of temperature, voltage conditions, and then presumably putting that in some nonvolatile storage
<wren6991>
at which point, why not just generate a random key with a TRNG and store that in nonvolatile storage?
<wren6991>
Am I right that UP5k has two user oscillators? Could potentially get kb/s of true random output by racing those against each other
<TD-Linux>
whoa til about the bram thing
<whitequark>
probably susceptible to tampering
<TD-Linux>
given that yosys can infer bram, does that mean my design randomly won't work if I don't use a pll?
<TD-Linux>
er if I'm reading this right it's ok for spi flash load
<wren6991>
TD-Linux: I think the important feature is that you have a long delay in your global reset. The PLL thing was just that, if you use PLL lock as an input to your reset generator, it creates such a delay
<wren6991>
not sure, but I've only seen it with slave-mode config
<TD-Linux>
I have been just relying on the migen system wide reset which won't have a delay
<wren6991>
Do you rely on a preload to set the initial BRAM contents? I think that is the part that breaks
<TD-Linux>
no, as long as yosys can't infer an automatically loaded bram (but can't it?)
<wren6991>
Agh actually that last part is probably not true after re-reading Clifford's comments on the icestorm ticket, sorry :S
<wren6991>
It will certainly infer that for initial $readmemh();
<wren6991>
And potentially other initial statements which set constants.
<daveshah>
It will infer it in other circumstances too like multiple initals and for loops
<wren6991>
I also think Yosys is pretty aggressive about BRAM inference, I think the default threshold is something like 2% utilisation?
<wren6991>
ah thanks daveshah
<daveshah>
Yes 2%
<daveshah>
It would probably be good to have different thresholds for ROMs (which map fairly well to LUTs when small) and RAMs (which are pretty expensive)
<TD-Linux>
can anyone confirm that I'm reading this right and it's not an issue if you initialize from spi flash?
emeb_mac has joined ##openfpga
<daveshah>
TD-Linux: I'm not sure if that's been tested
<daveshah>
I suspect it affects all modes of configuration though
<TD-Linux>
does it make sense to have migen automatically create a reset delay counter to fix this?