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