<pie_> im basically just saying what you said again: so i can feed TRIGGER, LED, and CLK to everything, and switch to individual flip-flops with enables
<pie_> and then just enable a flipflop when i want to do something (?)
<pie_> Is there some other terminology for "enable"? I don't see anything in the kicad library.
<pie_> alternatively, a latch might be able to do the same thing?
<pie_> nevermind about the latch.
<pie_> ugh. i need to get some sleep. the enable is basically the clock.
<pie_> daveshah: yup, i did the clock only muxing now c: much cleaner
<pie_> not sure how i missed that
Flea86 has joined ##openfpga
<SolraBizna> I'm dumb. if `ftdi_read_data` returned 0, I slept for 1 millisecond and... returned without trying again
* pie_ pats SolraBizna :p
<pie_> so ... i just... stick something like this on my stuff and it will be esd safe? http://www.st.com/resource/en/datasheet/esda6v1-5sc6.pdf
Ellied has quit [Quit: WeeChat 2.2]
<Flea86> pie_: Nothing is truly 'ESD safe'... but that device you've linked may likely help a lot.
<Flea86> Certainly make your design easier to manhandle without zapping it
lovepon has quit [Ping timeout: 260 seconds]
<pie_> Flea86: problem is im not very knowledgeable :p
<pie_> gonna go through azonenbergs checklist in a bit
<pie_> i have a minor thing im not sure what to do about. I added an and gate between DETECT and the LED flip-flop output, so that the led is automatically turned off when you unplug the connector
<pie_> should i just omit the extra hardware and just do it in the microcontroller?
<pie_> it could be more flexible that way I guess, and less possibilities for hardware problems
<SolraBizna> is it a safety issue?
genii has quit [Remote host closed the connection]
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
lovepon has joined ##openfpga
mwk has quit [Ping timeout: 252 seconds]
mwk has joined ##openfpga
television has quit [Quit: enabling client certs]
marcan_ has joined ##openfpga
television has joined ##openfpga
television has quit [Changing host]
television has joined ##openfpga
marcan has quit [Read error: Connection reset by peer]
marcan_ is now known as marcan
_whitelogger has joined ##openfpga
rohitksingh_work has joined ##openfpga
Bike has quit [Quit: Lost terminal]
jevinskie has quit [Quit: Textual IRC Client: www.textualapp.com]
jevinskie has joined ##openfpga
<whitequark> my PCIe PHY has LinkUp=1 !!
<SolraBizna> !!!
<SolraBizna> This is on an ECP5, right?
<whitequark> yes
<SolraBizna> So, soon, with open tools, we'll have the ability to use DDR3 memory and PCI Express with the ECP5...
<SolraBizna> That is really tubular.
<whitequark> for some values of soon
<SolraBizna> Soon™
<tnt> \o/
m4ssi has joined ##openfpga
Mimoja has joined ##openfpga
<Flea86> whitequark: That's very cool.
<Flea86> whitequark: Last time I used ECP5 serdes, it was via a non-free Diamond license..
<Flea86> Very first thing I did, was test out the maximum bandwidth of my (then) new DSO... turns out there's no free lunch above 1GHz heh
<whitequark> Flea86: well, I do use Diamond
<whitequark> no comment on licenses
<Flea86> oh ok
<_whitenotifier> [whitequark/Yumewatari] whitequark pushed 2 commits to master [+3/-1/±8] https://git.io/fpRCj
<_whitenotifier> [whitequark/Yumewatari] whitequark ee6c432 - gateware.debug: implement a timestamped ring buffer.
<_whitenotifier> [whitequark/Yumewatari] whitequark 4952176 - gateware.phy: implement most Detect, Polling and Configuration states.
<Flea86> Unfortunately, I no longer have access to non-free Diamond at this point, so all of my early Ohm board prototypes with u.FL breakout are no longer useable to me
<whitequark> Flea86: let me pm
<azonenberg_work> Flea86: that was one of the things that drew me to xilinx at first
<azonenberg_work> serdes-capable parts in the free tools
Mimoja has quit [Quit: The Lounge - https://thelounge.github.io]
<whitequark> oh I should try my current code with trellis
<daveshah> whitequark: you might get a small timing boost from removing -nomux and using this nextpnr
<_whitenotifier> [whitequark/Yumewatari] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fpRWO
<_whitenotifier> [whitequark/Yumewatari] whitequark 842ef3f - gateware.phy: fix typo.
<whitequark> daveshah: lemme see
<whitequark> daveshah: are "ECP5 timing improvements" merged?
<Flea86> azonenberg_work: Yeah, I almost jumped to Xilinx A7 before revamping my Ohm board with Lattice again...
<daveshah> whitequark: yes they are now
<whitequark> sigh, time to rebuild bbas again
<whitequark> y'all should really do something about it
<daveshah> There's not much to do tbh
Mimoja has joined ##openfpga
<daveshah> Half the time is just spent building the full routing graph which can't really be chopped down
<whitequark> hm, ok
<daveshah> I think we'll just have to start providing prebuilt bbas
<daveshah> But that does need all the associated infrastructure and gets a bit complicated dealing with branches etc
<whitequark> use git-lfs?
<whitequark> seems like it'd be ideal
<daveshah> Yes, although they would compress so well you might even get away with plain git
<SolraBizna> is that one of those things that will lead to non-shallow `git clone` taking an incredibly long time?
<whitequark> unlikely
<tnt> oh really you need a license in diamond to use the ecp5 serdes, maybe I should have read about that before buying the board :
<daveshah> The boards include a diamond license
<Flea86> ^
<daveshah> Or you can use the serdes support in Trellis
<whitequark> or you can look at your PM
<Flea86> daveshah: serdes support is there already? wow...
<daveshah> Quite experimental but does work
<Flea86> Ok many thanks :D
<tnt> daveshah: yeah, that was the plan, but I haven't tried treillis yet at all and given this is my first experience with serdes at all, I wanted to at least have the option to test with diamond to remove one unknown :p
<whitequark> btw the SERDES works quite reliably in trellis
<whitequark> I have not found any issues that could be attributable to trellis
<whitequark> it *is* rather underdocumented
<daveshah> the bigger problem is nextpnr and Yosys are a bit too slow for most serdes designs
<Flea86> tnt: You should get a 12-month limited non-free licence with your board
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
<azonenberg_work> daveshah: are the official tools faster?
<azonenberg_work> because my experience with the xilinx tools, at least, is that they're sloooooow
<azonenberg_work> or do you mean inadequate QoR, not how long it takes to PAR?
<whitequark> yes
<whitequark> the resulting design is slow
<whitequark> it's actually catching up pretty nicely with Diamond
<azonenberg_work> ah ok
<azonenberg_work> i was going to say, i thought the general rule for f/oss fpga tools was that they run fast but deliver inferior qor
<whitequark> they are about as fast now, actually
<whitequark> give or take
<whitequark> runtime wise
<daveshah> Diamond is faster than icecube and nextpnr is much slower than arachne
<whitequark> though I don't remember if I build at -O3 or not
<daveshah> Should be the default
<daveshah> We really need to get rid of the shitty SA placer tbh
<whitequark> Info: 1.7 ns logic, 4.8 ns routing
<whitequark> hm
<daveshah> This is probably mostly down to bad placement
<daveshah> I think adding some kind of concept of criticality to the placer might help designs like this
<whitequark> yeah I can see that
<whitequark> criticality?
<daveshah> Where there are probably only a few critical paths and the important thing is to minimise those
* whitequark imagines the demon core
<whitequark> oh.
<daveshah> whitequark: can't get Yumewatari to work with Diamond here :(
<whitequark> :S
<daveshah> running `sample` either just hangs or produces nonsense like thise
<whitequark> that's not nonsense
<whitequark> well, not exaclty
<whitequark> I've seen this
<whitequark> looks like receiver detection doesn't work...
<daveshah> whitequark: enabling equalisation (p_CH0_REQ_EN = "0b1",) changes things a bit
<whitequark> ooh interesting
<whitequark> sample a few more times
<whitequark> weird
<whitequark> so this waits for TS2 Link=PAD Lane=PAD
<whitequark> not sure why it odesn't receive that
<whitequark> could behm
<daveshah> that was on the x86
<whitequark> transmitter settings being worng
<daveshah> seeing less on the tx2
<daveshah> no green LED and sample just hanging
<whitequark> wtf
<daveshah> but the tx2 is cursed
<whitequark> oh
<whitequark> that sounds like
<whitequark> no clock
<whitequark> sample runs off pcie clock
<whitequark> which i should actually fix
<whitequark> with a pulse synchronizer and stuff
<daveshah> I am seeing the red LEDs blinking
<daveshah> I am pretty sure I've measured a PCIe clock on the tx2
<daveshah> but it might be discontinuous
<whitequark> I mean not refclk but data clock
<tnt> What board are you guys using btw ?
<daveshah> ah
<whitequark> versa ecp5
<daveshah> ecp5-5g versa
<tnt> tx
<daveshah> oh, I loaded the bitstream again on the versa with tx2 and now the green LED has come on
<daveshah> sample now gives
<whitequark> interesting
<whitequark> that's actually better
<daveshah> running again
<_whitenotifier> [whitequark/Yumewatari] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fpRRR
<_whitenotifier> [whitequark/Yumewatari] whitequark 802dd8a - testbench.ltssm: fix time delta calculation.
<whitequark> yeah so it never progresses to Linkwidth.Start
<whitequark> any chance you can find a 2.5 GHz scope? :P
<daveshah> heh, just got a Linkwidth.Start running enough times
<whitequark> hm but it still timeouts
<daveshah> doubt it on the scope front :(
<whitequark> wonder why that happens
<whitequark> needs better debugging :S
<daveshah> best possibility will be Vienna in January
<daveshah> I let it stew a bit and it looks good now???
<daveshah> suspect the problem is electrical in nature
<whitequark> oh
<whitequark> oh I knwo what this is
<whitequark> TX common mode voltage
<whitequark> I had a FIXME but I erased it for reasons
<zkms> whats the issue with tx common mode voltage?
<daveshah> whitequark: wtf the trellis bitstream is working now
* daveshah is confused
* daveshah hurts itself in its confusion
<whitequark> wtf
<whitequark> interesting
<whitequark> zkms: the transceiver needs certain common mode voltage to operate
<whitequark> it's related to the driver technology but i don't know anything beyond that
<daveshah> the trellis bitstream does seem more dodgy for sure
GuzTech has joined ##openfpga
<daveshah> whitequark: is it valid for the tx clk input to be connected to the rx clk output?
<whitequark> daveshah: it should be
<whitequark> it's the fpga bridge input clock
<daveshah> For some reason TN1261 seems to show the Tx clock connected to both
<daveshah> But I agree it shouldn't make a difference in theory
<whitequark> try changing it?
<daveshah> afk for a few hours now
<daveshah> Will investigate when I'm back
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
lovepon has quit [Ping timeout: 260 seconds]
Bike has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
<_whitenotifier> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fpRVh
<_whitenotifier> [whitequark/Glasgow] whitequark 1fbf976 - gateware.fx2: `async` became a reserved word.
<_whitenotifier> [Glasgow] whitequark closed issue #78: async has become a reserved keyword in Python 3.7 - https://git.io/fpBNE
<_whitenotifier> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fpRwu
<_whitenotifier> [whitequark/Glasgow] whitequark 1966293 - firmware: fix illegal IOx manipulation.
<_whitenotifier> [Glasgow] whitequark closed issue #77: Illegal IOx assignments - https://git.io/fpBQh
rk[ghost] has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
GuzTech has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
genii has joined ##openfpga
Eduardo20 has joined ##openfpga
Eduardo20 has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Ping timeout: 268 seconds]
rohitksingh has joined ##openfpga
Eduardo_ has joined ##openfpga
<Eduardo_> Tesr
Eduardo_ has quit [Client Quit]
<daveshah> tesr [sic
<daveshah> passed
GenTooMan has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pie_> SolraBizna: its not a safety issue
<SolraBizna> then, follow your heart
m4ssi has quit [Remote host closed the connection]
gnufan has left ##openfpga [##openfpga]
emeb has joined ##openfpga
cyrozap has quit [Ping timeout: 252 seconds]
cyrozap has joined ##openfpga
pie_ has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Remote host closed the connection]
jevinskie has joined ##openfpga
<_whitenotifier> [whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fp0Jq
<_whitenotifier> [whitequark/Glasgow] marcan 0a295a5 - revC: I/O buffer B routing
kehribar has joined ##openfpga
<kehribar> Hi all. I started an STM32F042 (TSSOP20 pin, ~1.5$, hardware USB) based ICE40 programmer / data interface framework project.
<kehribar> My aim is to replace "Oh, I need to use FT2232 to program the FPGA" type of idea with a low-cost alternative.
<kehribar> Data transfer speed is around couple hundred kilobytes. I did some benchmarks for the USB peripheral and it can be found from https://github.com/kehribar/stm32f042_usb_benchmark
<kehribar> Actual project repo link is: https://github.com/kehribar/ice40helper
<kehribar> Right now, I can program an HX1K over USB in around 180ms. (Non volatile configuration)
<kehribar> I'm planning to add SPI flash programming to allow non-volatile configurations as well.
<kehribar> Right now, I'm using Olimex HX1K board with no modifications and a STM32 Nucleo board but I'm planning to create an STM + UP5K example hardware design soon.
<Zorix> ah cool
kehribar_ has joined ##openfpga
<Zorix> kehribar_, [16:11] <Zorix> you have a hardcoded path in your makefile... https://github.com/kehribar/ice40helper/blob/c373acf107caa242c9b4bea5c5047b5246072777/firmware/Makefile#L26
lovepon has joined ##openfpga
<SolraBizna> achievable or not: FIFO with unrelated input and output clocks
<sensille> async fifo? sure
<SolraBizna> okay, so I'm just bad at it then :D
<daveshah> The gray code for the pointers is the important bits
<azonenberg_work> there's a bunch of different kinds of async fifo
<azonenberg_work> gray code is one of a couple implementations
<azonenberg_work> Another one i've done is to use a handshake synchronizer to push pointers between clock domains
<azonenberg_work> This has slightly higher latency but there are times when it's the better option
<azonenberg_work> for example, if you have a commit/drop style function on the fifo where you need to push several words of data but not have the other domain see them until you've verified a checksum or something
<SolraBizna> that's a very good article
<sensille> ZipCPU: ^^
<ZipCPU> Thank you!
<SolraBizna> would I be able to do this formal verification stuff with just yosys / iverilog?
<daveshah> iverilog isn't involved in the formal verification flow
<SolraBizna> (meant / as or)
<daveshah> It is much easier to work with for formal than Yosys on its own
<daveshah> You will almost certainly want SymbiYosys too
m4ssi has joined ##openfpga
<tnt> Mmm, nextpnr decided to promote 4 reset signals to globals. But I already had 1 global for reset, so obviously it failed to place it.
kehribar_ has quit [Ping timeout: 240 seconds]
kehribar has quit [Ping timeout: 240 seconds]
<SolraBizna> well, if I want to finish this in time for the contest, I don't have time to figure out the (insanely useful-looking) formal verification part >_<
<SolraBizna> I didn't even know there were free tools for doing that
<Bob_Dole> I thought I told you about it
<SolraBizna> people tell me lots of things
<SolraBizna> (still an open question: whether I even want to enter, since all I'm doing is making a naive 4-stage pipeline)
<tnt> btw, I have some spares glasgow rev.b PCBs if anyone is interested in a assembling one.
m4ssi has quit [Remote host closed the connection]
Miyu has quit [Ping timeout: 250 seconds]