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