<SolraBizna> I accidentally did `make -j8` when building nextpnr on my two-core, 3GB laptop
<pie_> gruetzkopf: so nothing :p have fun :S
<pie_> * :D
pie_ has quit [Changing host]
pie_ has joined ##openfpga
pie_ has joined ##openfpga
<tnt> cr1901_modern: and I just made them a bit larger :p
vup has quit [Quit: The Lounge - https://thelounge.github.io]
vup has joined ##openfpga
genii has quit [Remote host closed the connection]
<SolraBizna> where has 'bx been my whole life
<cr1901_modern> tinyfpga bx?
<whitequark> verilog thing
<SolraBizna> I've been writing 32'b XXXXXXXX... like a fool
azonenberg_work has quit [Read error: Connection reset by peer]
* SolraBizna goes back in time and hits self over head for thinking "I'll learn gtkwave later, it's not important right now"
<pie_> now repeat with everything ever?
<pie_> SolraBizna poofs out of existence
<Bob_Dole> SolraBizna, you seem to have really taken to FPGAs, after spending so long thinking you'd do everything with discrete logic components.
<pie_> enlightenment?
azonenberg_work has joined ##openfpga
Miyu has quit [Ping timeout: 264 seconds]
<SolraBizna> a lot of things had to come together for it to be a real option for me
<tnt> SolraBizna: did you get anywhere with RGBA support btw ?
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
<SolraBizna> I haven't made any further progress
<SolraBizna> I managed to do everything but prevent it from creating SB_IOs for the RGBx pins (I think)
<SolraBizna> I know where the change needs to be made
<tnt> Note that you can also rip the SB_IOs up once your pack the hard-ip
<SolraBizna> it sounds like you'd be more able to finish this than I am
<tnt> heh, well I'd like to finish the PLL thing first :p
<SolraBizna> https://bunker.tejat.net/private/eph/so_far.txt ← here's what I have, in case you finish that and go for an encore :P
lovepon has joined ##openfpga
Bike has quit [Quit: Lost terminal]
oeuf is now known as egg|zzz|egg
<mithro> Anyone know what I'm doing wrong with nextpnr here -> https://github.com/YosysHQ/nextpnr/issues/120 ?
<mithro> tinyfpga: Started hitting your usb stack with a stick here -> https://github.com/mithro/valentyusb -- Did you ever actually build + run it on hardware? If so were you using icecube2 or something because nextpnr only *just* got multi-clock domain support, right?
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined ##openfpga
<tinyfpga> mithro: I had it running on the fomu prototypes...i compiled with synplify on icecube2
<mithro> Okay, I'll give ice cube a try
lovepon has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
m4ssi has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 244 seconds]
<SolraBizna> oh no, now I'm seeing `<=` as nonblocking assignment in my C code
<daveshah> :D
<sensille> that would be nice
<azonenberg_work> SolraBizna: i do curly braces in hdl and begin/end in C++ often
<azonenberg_work> when switching back and forth between the two
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
<tnt> mithro: in your example you have "assign mux_payload_data = {usb_d_n, usb_d_p};" which also accesses the PACKAGE_PIN.
<daveshah> I could swear I added a trap for that case in nextpnr
<daveshah> Obviously it's not working for some reason
Maylay has quit [Ping timeout: 268 seconds]
<tnt> log_error("PACKAGE_PIN of SB_IO '%s' connected to more than a single top level IO.\n",
Maylay has joined ##openfpga
<daveshah> tnt: Yes, I think we trap that case but not package pin to logic
<tnt> Basically "sb = net_only_drives(ctx, ci->ports.at(ctx->id("O")).net, is_sb_io, ctx->id("PACKAGE_PIN"), true, ci);" returns nullptr in this case (in pack.cc:~414)
mwk has quit [Ping timeout: 252 seconds]
mwk has joined ##openfpga
<tnt> daveshah: btw, completely unrelated, but I've been trying to understand when the IoCtrl.IE_{0,1} need to be asserted. If the IO is used as an input, that's the obvious case. But the interaction with PLL isn't obvious. What if the IO cell where the PLL is doesn't have its IO used (and pll is fed from REFERENCECLK). Do they need to be enabled ?
<daveshah> I believe they do
[X-Scale] has joined ##openfpga
gnufan has quit [Ping timeout: 268 seconds]
X-Scale has quit [Ping timeout: 268 seconds]
<tnt> And even if global out is used (rather than the fabric out that use the IO 'input path') ? Because if I use global output B, should I enable the IE pin corresponding to the B output ?
[X-Scale] is now known as X-Scale
kuldeep has quit [Ping timeout: 268 seconds]
<daveshah> tnt: Yes, that is my understanding
kuldeep has joined ##openfpga
<tnt> ok, tx.
azonenberg_work has quit [Ping timeout: 240 seconds]
Bike has joined ##openfpga
kehribar has joined ##openfpga
<kehribar> To anyone looking for 'simple' verilog simulation example: https://github.com/kehribar/verilog-osx. It is applicable to Linux as well.
<s_frit> kehribar: nice one :)
azonenberg_work has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 246 seconds]
Bike is now known as Bicyclidine
Ultrasauce has quit [Ping timeout: 250 seconds]
Ultrasauce has joined ##openfpga
ZipCPU has quit [Ping timeout: 240 seconds]
gnufan has joined ##openfpga
ZipCPU has joined ##openfpga
<tnt> daveshah: mmm, I did a few tests with icecube and AFAICT the IE bit really only control the physical pad input buffer. i.e. icecube only enables it if something is coming from that pad. If you have the clock coming to the PLL to reference clock from another pad and output to both local outputs, both IE bits of the IO cell where the PLL is stay disabled.
<daveshah> Ah right
<daveshah> arachne-pnr always enables them afail
<daveshah> *afaik
emily has quit [Quit: Lost terminal]
rohitksingh has joined ##openfpga
Miyu has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
emily has joined ##openfpga
pie__ has joined ##openfpga
<pie__> kc8apf: hey, do you know what a logic output optocoupler is?
<pie__> also the relays are 5v, which is fine for arduino, but i want to avoid relays
<qu1j0t3> pie__: why do you want to avoid relays?
<qu1j0t3> pie__: also, if you install an optocoupler, what are you goign to use for switching? a FET?
<qu1j0t3> pie__: maybe you should start with a relay then upgrade later?
<qu1j0t3> pie__: re choosing an optocoupler, get familiar with digikey's search :) I can help
rohitksingh has joined ##openfpga
<pie__> poking around mouser right now
<pie__> qu1j0t3: not sure what you mean about what to use for switching
<pie__> just the digital line of the microcontroller? i dont need to switch a large load on the isolator output
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kc8apf> pie__: I can guess but I haven't heard that term specifically
<pie__> aaaand i have to run off in a few minutes
<pie__> kc8apf: i just went with the same category the device you linked was in, but limited it to DIP stuff, how do i narrow down the remaining 1400 results?
<kc8apf> did you figure out what your colleagues mean by "shorting" the pins
<pie__> no. i was about to go ask the guy. i mean i know for a fact they meant literally shorting them, because relays
<kc8apf> right, but is 100nA "off" enough
<kc8apf> or go with a relay+driver and be done with it
<qu1j0t3> pie__: I mean the actual switch
<qu1j0t3> and yeah what kc8apf asked
<pie__> ok, i found the guy
<pie__> he says it should be perfectly fine
<pie__> to use an optocoupler
<pie__> looks like we might have some stuff already
<pie__> well, thnaks again, time for me to work on this for a bit
<tnt> daveshah: bitstream.cc has CR/LF endings :/ How do you feel about whitespace change commits ?
<daveshah> yes, go ahead
<daveshah> I don't know how that happened
<pie__> we have some of these, im going to try to make a breakout board https://www.digikey.com/product-detail/en/texas-instruments/ISO7320FCDR/296-42101-1-ND/5252854
<pie__> gonna check the datasheet first though
* pie__ is kind of hyped that he's making a thing
<qu1j0t3> pie__: You can't just pick a through-hole part?
<pie__> qu1j0t3: i probably can, but id have to wait for the order to come in. eh. we're done for the day anyway so ill have to continue on monday
<qu1j0t3> pie__: that provides isolation but what is going to do the switching?
<pie__> qu1j0t3: yeah he said id probably have to use a FET as well. but i dont get it. isnt the whole point that you can switch stuff with the isolator
<qu1j0t3> no
<qu1j0t3> in fact this may not work
<qu1j0t3> well, you can use the isolator on the FET control
<qu1j0t3> but i guess you already intended that
<qu1j0t3> that will emulate what the relay does, then you need a FET with suitable properties (there are logic level ones, and also check the on-resistance as kc8apf says)
<qu1j0t3> relay on-resistance is usually < 200 mΩ
pie__ has quit [Ping timeout: 256 seconds]
<tnt> cr1901_modern: If you're feeling brave you could try : https://github.com/smunaut/nextpnr/tree/ice40_pll_global and see if that fixeds your PLL issues.
<tnt> I think it's ready and working ... but needs review and testing :)
rohitksingh has quit [Ping timeout: 268 seconds]
rohitksingh has joined ##openfpga
Miyu has quit [Read error: Connection reset by peer]
<tnt> daveshah: and of course, if you want to have a look and comment, that'd be welcome too :p
<daveshah> tnt: the bitstream and database stuff looks good to me
<daveshah> ping q3k
<daveshah> who wrote the original PLL code
rohitksingh has quit [Ping timeout: 246 seconds]
genii has joined ##openfpga
kehribar has quit [Ping timeout: 250 seconds]
jevinskie has joined ##openfpga
emeb has joined ##openfpga
<q3k> tnt: would you mind creating a pull request so we can review the change there?
rohitksingh has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
kehribar has joined ##openfpga
<cr1901_modern> tnt: I'll pull your changes and see what happens
<cr1901_modern> oh of course all the dbs are being rebuilt
<qu1j0t3> /b 13
kehribar has quit [Ping timeout: 252 seconds]
Miyu has joined ##openfpga
kehribar has joined ##openfpga
<tnt> q3k: sure
kehribar has quit [Ping timeout: 272 seconds]
<tnt> SolraBizna: did you push your RGB support work somewhere ?
<cr1901_modern> tnt: Still building. Only using 1 thread to be safe, so yes nextpnr takes a while if the dbs have to be rebuilt
<tnt> cr1901_modern: hehe, yeah, same here.
<cr1901_modern> 1 thread is safe, 2 threads also always works, 3 threads will at best go to swap at worst crash the system.
<cr1901_modern> It's like the ackermann function for threads
<cr1901_modern> tnt http://ix.io/1s7P
<cr1901_modern> what did I do wrong?
<cr1901_modern> It's not an assertion failure anymore at least
<tnt> is your clock input on the PAD dedicated to the PLL btw ?
<cr1901_modern> .REFERENCECLK(clk16_1),
<cr1901_modern> Meaning I have NFI
<cr1901_modern> tnt: I'
<cr1901_modern> m using the same verilog as this file: https://github.com/YosysHQ/nextpnr/issues/69#issue-356990250
<tnt> mm, ok. I tried your pll-crash2.zip, not this one.
<tnt> cr1901_modern: Ah well ... you really shouldn't follow a .PLLOUTGLOBAL by a SB_GB :)
<tnt> cr1901_modern: but at least now if you use PLLOUTGLOBAL, it will actually be a global.
<cr1901_modern> tnt: Fair enough. But pll_crash2 isn't fixed either
<tnt> cr1901_modern: oh damnit ... still doesn't blink ?
<cr1901_modern> indeed, no blinky
<tnt> can you route the LOCK output of a PLL to a LED ?
<tnt> I'm wondering if the issue is the PLL not locking or not getting the clock. Or the PLL output not getting to the LED.
<daveshah> I would guess the problem is the PLL not locking
<daveshah> nextpnr *should* always insert a route through LUT for the PLL LOCK output as needed
Miyu has quit [Read error: Connection reset by peer]
<cr1901_modern> LED isn't active
<cr1901_modern> Verilog input http://ix.io/1s7X
<tnt> cr1901_modern: can you try to remove the SB_GB and use PLLOUTPUTGLOBAL ?
<tnt> (oh wait, nm, if the pll doesn't lock it won't change anything)
<cr1901_modern> tnt: http://gopher.wdj-consulting.com:70/store/build-pll.zip All files if you're interested
<daveshah> cr1901_modern: can you also try tying BYPASS to 1'b0
<cr1901_modern> including the textual repr
<cr1901_modern> is that a parameter or input?
<daveshah> input
<daveshah> I don't think it will make a difference
<daveshah> but worth a shot
<tnt> I never tried a _CORE PLL yet actually. All the boards I have use the dedicated PAD input.
<daveshah> I think q3k has tested one
<cr1901_modern> No change
<q3k> the icestick has no PAD input for the PLL
<daveshah> cr1901_modern: what about adding .FEEDBACK_PATH("SIMPLE") to the params?
<cr1901_modern> No change
<cr1901_modern> Why not just look at what arachne does?
Miyu has joined ##openfpga
<cr1901_modern> (for the record, with all the changes thus far, arachne locks fine)
<tnt> Well the code base are not that easy to compare unfortunately, they work in pretty different ways. i tried comparing the bitstream outputs and didn't really see anything fundamentally wrong.
<tnt> (logic and routing gets placed differently so you have plenty of differences, spotting the relevant ones is not immediate)
<tnt> Arf, didn't even place the PLL at the same site.
<shapr> rvense: I did ask for C source to transfer data to the beaglewire ram: https://github.com/pmezydlo/BeagleWire/issues/15
<shapr> but haven't gotten a response
rohitksingh has quit [Ping timeout: 245 seconds]
<tnt> The nextpnr bitstream has a bunch of "ColBufCtrl glb_netwk_N" ... no idea what that means, but that's a difference that jumps out.
<daveshah> They are set when you use the global network in a column
<daveshah> I think nextpnr just sets all of them whereas arachne-pnr only sets the strictly needed ones
<daveshah> That should probably be fixed as it will have a small effect on power consumption
<rvense> shapr: nice! i think i'll get one of the boards soon
m4ssi has joined ##openfpga
Morn_ has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
<tnt> daveshah: in icebox_explain, will the config bits show up in the tile they actually control or in the tile they're stored in ?
<daveshah> tnt: the tile they are stored in
<SolraBizna> tnt: https://bunker.tejat.net/private/eph/so_far.txt ← this was it, didn't seem worth forking and pushing for
<SolraBizna> that plus "fixing" pack_io in ice40/pack.cc should be all that's needed[citation needed]
<tnt> daveshah: any idea of why this mess ? (of storing stuff at random places ?!?)
<daveshah> why? almost certainly because of Lattice buying SB and all their engineers leaving
<SolraBizna> CRAM bit physical positions probably got forced into whatever fit the physical layout of the rest of the FPGA rather than the other way around
azonenberg_work has quit [Ping timeout: 272 seconds]
<tnt> So one difference I can't explain yet between arachne and nextpnr is PLL PLLCONFIG_5 bit in .io_tile 18 0
m4ssi has quit [Remote host closed the connection]
<tnt> Which is the feedback path selection bit ...
<tnt> adding .FEEDBACK_PATH("SIMPLE") makes both bitstream output the same thing for that bit.
<tnt> cr1901_modern: could you try these 3 : http://246tnt.com/files/pll/ ?
kehribar has joined ##openfpga
<cr1901_modern> tnt: Will do in a bit
<tnt> cr1901_modern: is your target a tinyfpga bx ?
kehribar has quit [Ping timeout: 272 seconds]
<cr1901_modern> tnt: yes
esden has quit [Quit: ZNC - http://znc.sourceforge.net]
<tnt> I just remembered I actually have one of those :p
esden_cloud_ is now known as esden
kehribar has joined ##openfpga
<tnt> Huh, interesting ... So I found several issues:
<tnt> - Handling of unused SB_IO is wrong, the IE bit is set without accounting for 1k vs other difference in polarity and so we just enable all input buffers ... not great, but not the cause of the issue
<tnt> - Feedpack path default is not SIMPLE in next-pnr, not sure where that comes from. But putting 'SIMPLE' explicitely in the verilog fixes that
kehribar has quit [Ping timeout: 252 seconds]
<tnt> - next-pnr will by some weird code, end up placing that PLL in the bottom PLL in that device. Arachne will place it in the top one. And as it turns out, if you tell next-pnr to use the top PLL, it works fine !!?
<daveshah> Oh, shit
<daveshah> The bottom PLL is unavailable in that package
<daveshah> nextpnr doesn't take that into account
<daveshah> This would need handling of the "locked" statement in the chipdb
<tnt> Ah well, at least that explains it :)
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
<tnt> grepping chipdb-8k.txt for 'locked' doesn't turn up anything
<tnt> oh nm ... case insensitive
<cr1901_modern> >The bottom PLL is unavailable in that package
<cr1901_modern> Ahhh, that would explain a lot
<tnt> I'm wondering how/why that is the case. They did a different die just for that ?
<tnt> or didn't bondd vcc_pll to it maybe.
indy has joined ##openfpga
<tnt> Arf, adding a BEL constraint to the PLL actually triggers an ASSERT in next pnr :/
<tnt> this contains more than needed (it's my 'wip' tree), but it will work with it.
<tnt> It doesn't actually exclude the 'LOCKED' pll but it uses the first it finds. Also to be safe you can explicitely constrain it in the code like : (* BEL="X16/Y0/pll_3" *) SB_PLL40_CORE #( ...
esden has quit []
esden has joined ##openfpga
<tnt> The PLL placement algo is ... well ... non-existent really. But OTOH given most chips only have one, spending time in refining it for all cases seems a bit of a low priority
azonenberg_work has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 276 seconds]
SpaceCoaster has joined ##openfpga