clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
tpb has joined #yosys
emeb has left #yosys [#yosys]
umarcor has quit [Ping timeout: 240 seconds]
citypw has joined #yosys
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter has joined #yosys
tpb has quit [Disconnected by services]
tpb has joined #yosys
<Xark> mrec: I believe it will work with Lattice tools, they are not super picky (default FT232H or FT2232H).
awordnot has quit [Ping timeout: 240 seconds]
awordnot has joined #yosys
Jybz has joined #yosys
emeb_mac has quit [Quit: Leaving.]
cr1901_modern has quit [Ping timeout: 268 seconds]
cr1901_modern has joined #yosys
adjtm_ has quit [Ping timeout: 240 seconds]
m4ssi has joined #yosys
adjtm_ has joined #yosys
dys has quit [Ping timeout: 240 seconds]
adjtm_ has quit [Quit: Leaving]
adjtm has joined #yosys
fsasm has joined #yosys
Stary has quit [Ping timeout: 264 seconds]
alexhw has joined #yosys
Stary has joined #yosys
craigo has quit [Ping timeout: 240 seconds]
dys has joined #yosys
<mrec> which vendor/product id should the FT 2232 device have?
adjtm has quit [Ping timeout: 240 seconds]
<mrec> ok the evb uses 6010 as productid
<mrec> operation unsuccessful... what a shit this ftdi <-> ICE40 coupling
<ZipCPU> mrec: Language, please
adjtm has joined #yosys
jakobwenzel has quit [Remote host closed the connection]
jakobwenzel has joined #yosys
sandeepkr_ has joined #yosys
pacak has quit [Remote host closed the connection]
pacak has joined #yosys
emeb has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
fsasm has quit [Ping timeout: 264 seconds]
adjtm has quit [Ping timeout: 264 seconds]
fsasm has joined #yosys
m4ssi has quit [Remote host closed the connection]
adjtm has joined #yosys
fsasm has quit [Ping timeout: 240 seconds]
Jibz has joined #yosys
Jibz has quit [Client Quit]
Jibz has joined #yosys
Jybz has quit [Ping timeout: 276 seconds]
Jibz has quit [Client Quit]
Jybz has joined #yosys
tmeissner has joined #yosys
<mrec> can anyone recommend a chip adapter for the ice40up5? I think it's best to programm it before placing it.
<daveshah> Probably best to see what Lattice have
<daveshah> I presume you want to program nvcm then, that's quite specialised
<mrec> I'm having too many problems with incircuit programming, I have a clock signal on MOSI or MISO...
<mrec> so I guess something's connected inside the FPGA that should not be connected.
<tnt> ?!
<tnt> during programming the fpga is held in reset, it won't do anything.
<whitequark> tnt: that is not the case
<whitequark> while the FPGA is programmed, LEDs on glasgow blink for example
<whitequark> i think that while the user logic is held in reset, the reconfiguring process itself can cause glitches
<whitequark> on comb signals
<tnt> But during configuration the IO ports should be disabled and held in their Z / weak-pull-up state.
<mwk> huh, doesn't ice40 force-tristate all IOs?
<tnt> I think they will switch between Z and weak-pull ups before the config is finished, but they should never be fully driven.
<whitequark> ohhh
<whitequark> yeah, that is probably what's happening then
<mrec> the best for me would be if that chip would have a simple i2c interface for uploading the image... at least that could get me started with the rest of the board
<daveshah> iCE40 SPI is simpler than I2C, tbh
<mrec> not if you don't have an SPI interface on the rest of the board
<tpb> Title: icebreaker/icebreaker-sch.pdf at master · icebreaker-fpga/icebreaker · GitHub (at github.com)
<mrec> ADBUS3, ADBUS4 does anyone know what's used for temporary programming?
<mrec> (I guess and hope it's adbus4)
<mrec> well it's not working anyway.
<tnt> You can't do SRAM programming the way the icebreaker is wired.
<tnt> you can only program the flash
<tnt> you need to swap the data line (miso/mosi) because the ftdi can't do that and you also need to make sure if you have a flash chip as well on there that its CS line will be disconnected from the fpga cs line.
Jybz has quit [Ping timeout: 240 seconds]
<mrec> I just took it as reference for wiring up from the FTDI (which I have disconnected from an ICE40HX8K)
<mrec> but there's still something wrong and it's not the swapped MOSI/MISO port
umarcor|2 has joined #yosys
<mrec> is there any fool proof documentation out there which pins of the ftdi need a pull up and which don't for programming the ice40 part?
<mrec> I'm only pulling up cdone and creset at the moment
<cr1901_modern> I wonder how icestick permits SRAM programming by removing a single resistor if the lines have to be swapped too...
<daveshah> Perhaps using bitbang rather than full MPSSE?
captain_morgan2 has quit [Ping timeout: 276 seconds]
captain_morgan2 has joined #yosys
<tnt> mrec: TN1248
<tnt> cr1901_modern: where did you see that ?
<mrec> I just found something...
<mrec> need to re-wire the FTDI to my board
<mrec> sclk and si are swapped hopefully that's it
<mrec> it's already wrong in my schematic
snajpa has joined #yosys
<snajpa> has anyone tried building the LiteX ethernet soc for ECP5? https://github.com/enjoy-digital/versa_ecp5
<tpb> Title: GitHub - enjoy-digital/versa_ecp5: Versa ECP5 SoC based on LiteX (at github.com)
<snajpa> I mean, recently enough
<snajpa> Info: Max frequency for clock '$glbnet$eth_clocks0_rx': 103.91 MHz (FAIL at 125.00 MHz)
<snajpa> I can't get above 118 MHz with prjtrellis
<daveshah> Yes, this is a known issue, its always done this
<snajpa> I see :)
<snajpa> I've only seen the issue for the rmii_test
<snajpa> *rgmii_test
<daveshah> Yes, that's the one design that fails
<daveshah> Doing the entire gigabit Ethernet stack with an 8 bit data path pushes an ECP5 a bit
<snajpa> while :; do ./versa_ecp5.py ethernet --toolchain trellis && echo OK && break; done # no luck
<daveshah> I've never seen it pass either
<daveshah> It works fine
<daveshah> The timing model Trellis uses is quite conservative anyway
<snajpa> aha, so it does output the gateware? I didn't actually check
<daveshah> No because the LiteX script stops
<daveshah> Just rerun the ecppack line
<snajpa> ok thanks a lot :)
<mrec> well whatever I rewire not working of course seems like the up5k is not meant for me.
<mrec> terrible chip
dys has quit [Ping timeout: 264 seconds]
dys has joined #yosys
<snajpa> tftp booted, yay \o/
<snajpa> now all the new stuff, hook this up with SD emulator from Google Vault
<snajpa> I wonder how does one simulate so complex designs - only short parts of the wave traces should be relevant... should be fun :)
<mrec> what is that stupid device detection doing? just checking cdone or what?
<daveshah> In what, iceprog? Yes
<daveshah> It doesn't try and do any kind of ID read - I'm not even sure if iCE40s support such a thing
<mrec> do you remember is there anything important that has to be taken care about when programming the sram?
<mrec> I just can't figure out what's wrong with my setup
<daveshah> No, the only thing I can think of is MOSI and MISO the wrong way round
<daveshah> But in the worst case you can always try both options
<daveshah> and just to check you are doing iceprog -S?
emeb_mac has joined #yosys
<mrec> VPP_2V5 is wired to 3V3 is that a problem? the datasheet says 3v3 is okay
<daveshah> 3V3 is fine
<mrec> I'm actually using the lattice windows tool
<daveshah> Ah right
<daveshah> That tends to be pretty unfussy about wiring too
<daveshah> What's the exact error it gives?
<mrec> it can't detect the device
<cr1901_modern> tnt: I misremembered about icestick. "iceprog --help", one of the last paragraphs explains how to do sram programming w/ icestick
<mrec> it detects the ftdi of course
<daveshah> CRESET and SS are both connected?
<tnt> mrec: are you sure it does SRAM programming ?
<mrec> tnt: that's what I would like it to do
<daveshah> I'm sure I've done SRAM programming with the Lattice tools once
<daveshah> Indeed it's an official option on the dev kits too
<mrec> creset and cdone are wired up
<mrec> and pulled to 3v3 using 10k
<tnt> which software are you using exactly ?
<mrec> the windows programming tool that comes with radiant
<mrec> is there any basic way to check if things are wired up correctly?
<mrec> the chip is not getting hot :-)
<tnt> Can you post screenshot of your configuration for the programmer ?
<mrec> just saw that spi clock is supposed to have a pullup too
<mrec> and ss_b
<mrec> I'm just jumpwiring the ICE40HX evb
<mrec> I desoldered the R0 resistors
<mrec> which is R1-R6 I think
<tnt> Radiant is for UP5k only ... does the programming sofware even work for a HX ?!?
<mrec> the ice40hx evb is a ft2232 <-> ice40hx board, the ice40hx8k is disconnected
<mrec> so I'm just using the ADBUSn connections of the ft2232 of that board
tmeissner has quit [Quit: Textual IRC Client: www.textualapp.com]
<mrec> ok I should just not assume that anything will be correct...
<mrec> the FTDI is not pulling SSB to ground leaving the chip in SPI master mode
<mrec> now the question is ... what needs to be fulfilled first .. cdone or ssb?
<daveshah> I think that ssb needs to be low when *creset* is pulled low
<daveshah> Or before it goes high again anyway
<mrec> it's not even pulling creset low
<daveshah> cdone is pulled low by the fpga, not by the programmer
<mrec> cdone is low permanently
<daveshah> That means the fpga isn't configured, as expected
<daveshah> I would expect creset to be being pulled down and back high
<daveshah> With ssb low by the time that creset goes high if not before, and ssb staying low while the programmer talks to the chip
<mrec> it's definitely not getting pulled low
<mrec> and it writes device detection failed... so the question is what is that firmware tool checking
<daveshah> Is there any activity on any of the signals?
<daveshah> Is it possible the wrong FTDI interface has been selected (B instead of A) - istr Diamond sometimes showed both
<tpb> Title: GoJimmyPi: Programming the Lattice Semiconductor FPGA iCE40 Ultra Plus Breakout Board iCE40UP5K-B-EVN (at gojimmypi.blogspot.com)
<mrec> In the end I was eventually successful, but I don't think the iCE40UP5K is for everyone.
<mrec> :-)
adjtm_ has joined #yosys
<mrec> FTUSB-1 is triggering a reset
<mrec> FTUSB-0 is not
<mrec> ok back to rewiring
<mrec> that's it
<mrec> it works now...
<mrec> thought the HW is the problem while the software setting was it somewhat thanks for the reset hint
<mrec> I cannot remember that I have ever set the port to FTUSB-1 when uploading the configuration
<mrec> suddenly it's needed
<mrec> guess if I would have gone with the linux tool it would have worked from the beginning on ...
gnufan_home has joined #yosys
adjtm has quit [Quit: Leaving]
forksand has joined #yosys
gnufan_home has quit [Quit: Leaving.]
emeb has quit [Quit: Leaving.]
tpb has quit [Remote host closed the connection]