sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
jbqubit has quit [Ping timeout: 260 seconds]
fengling has joined #m-labs
sandeepkr has joined #m-labs
sandeepkr has quit [Ping timeout: 244 seconds]
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
rohitksingh_work has joined #m-labs
mumptai has joined #m-labs
balrog has quit [Ping timeout: 248 seconds]
balrog has joined #m-labs
<whitequark>
sb0: do I understand correctly that wishbone registered feedback is used to break up the long CPU -> peripheral -> CPU path into two halves, to improve timings?
<whitequark>
and it generally makes sense to either use it everywhere in your design or nowhere?
<sb0>
yes
<sb0>
well it makes sense to use it everywhere
<whitequark>
ok
<sb0>
justified (i.e. non toy project/opencores) use cases for non registered are very limited
<whitequark>
I have some weird problem on this ice40 board
<whitequark>
the CPU doesn't start up unless I add an external reset and poke it (by e.g. touching the wire to GND manually)
<whitequark>
adding a POR domain with a counter that counts to 1024 and then resets the SYS domain doesn't change anything
<whitequark>
it basically never starts running by itself, whereas with this external reset it always does
<sb0>
is your POR actually working? can you see it on a scope?
<whitequark>
it doesn't
<whitequark>
well, not on the FPGA, in simulation everything works...
<whitequark>
hm, let me try something
<whitequark>
sb0: it was working but I accidentally inverted the polarity.
<whitequark>
it works with my POR.
<whitequark>
is it a known fact that built-in FPGA reset works badly?
<whitequark>
or is it just iCE40 that's broken?
mumptai has quit [Quit: Verlassend]
<sb0>
what is "built-in FPGA reset"?
<sb0>
initializing registers from the bitstream?
<sb0>
you have to be a bit careful with that yes, just as you have to be careful when to deassert a reset signal
<sb0>
also mor1kx/lm32 are verilog and suffer from the "initialization fiasco"
<sb0>
if you have a design with multiple asynchronous clock domains, using bitstream register init alone may be tricky or impossible
<whitequark>
ok I see
<whitequark>
and yes, ice40 has a built-in power-on reset (which they call so) that it uses to initialize the registers
<sb0>
how does it handle multiple clock domains?
sandeepkr has quit [Read error: Connection reset by peer]
<whitequark>
it doesn't
<sb0>
Xilinx also has a global reset, but it's of limited use, due to multiclock reset deassertion issues
<sb0>
they probably ought to scrap those features
<_florent_>
whitequark: are you using yosys to generate the iCE40 bitstream? (just curious)
<whitequark>
yep
<_florent_>
how long does it takes to generate you SoC design with mor1kx?
<whitequark>
11s in synthesis, 53s total on my ivy bridge i7 laptop
<whitequark>
sb0: oh and yes, you are right, these iCE40 FPGAs are good for nothing. the minimal mor1kx config (http://hastebin.com/lihezaralu.pl) takes just over 2000 slices, and it runs at a breakneck 25MHz
<sb0>
xilinx even let you drive that global reset from user designs
<sb0>
I wonder how this is supposed to work
<sb0>
it sounds more like a "corrupt the state of your design" signal to me
<whitequark>
maybe they have a reset generator there?
<sb0>
but you need a reset generator per clock domain.
<sb0>
and the fpga isn't going to guess how those clock domains are defined and how resets between them should be handled
<whitequark>
so could you rely on the global reset to initialize everything, and then ungate the clocks in whatever sequence makes sense?
<sb0>
if you do gated clocks, and synchronize the degating with the global reset, yes that works
<whitequark>
and presumably the benefit is that you don't have to route around resets per your clock domain
<whitequark>
I'm not sure how much impact that has in practice
<whitequark>
_florent_: actually this might be a debug build of yosys and arachne
<sb0>
I haven't seen FPGA designs using gated clocks to synchronize resets
<sb0>
but I have rarely seen FPGA designs without broken reset synchronization either
<whitequark>
_florent_: ah no, debug build of yosys, release build of arachne. so 40s for PAR is about right.
<_florent_>
whitequark: thanks for the results, that's fast. Yosys/ICE40 can be interesting for really small designs
<whitequark>
_florent_: that's *fast*?
<sb0>
compile time i guess
<sb0>
compared to the xilinx bloatware
<whitequark>
yeah
<whitequark>
that's very slow
<whitequark>
I should profile arachne
<_florent_>
whitequark: yes compile time compared to Xilinx
<whitequark>
you mean xilinx is even worse on such small designs? that's depressing
<_florent_>
whitequark: results are better with Vivado, but with ISE even a really small design was a least a few minutes...
<whitequark>
wow
<larsc>
speaking of taking a long time, I'm trying to enable zcu102 support in my Vivado installation. The guide says to run the enable_beta_device command
<larsc>
what they don't tell you that the command takes 10 minutes
<larsc>
each time you open vivado
<larsc>
wtf?
<whitequark>
what does `perf top` say?
<larsc>
"productivity multiplied" ...
<larsc>
whitequark: I don't know, the workaround is to use enable_beta_device partnumber
<larsc>
but that of course is not in the guide
<whitequark>
dreadful
<whitequark>
why do people tolerate this
<larsc>
I don't even understand how this could take 10 minutes in the first place
<whitequark>
accidentally quadratic something?
<larsc>
probably n**n
<sb0>
whitequark, people tolerate this because the alternative is those puny ice40 that run a design 10x slower
<whitequark>
sb0: why don't those large customers of xilinx put some pressure on them?
<sb0>
whitequark, btw, what sort of frequency is the mass spectrometer tube supposed to run at?
<whitequark>
well, I can't give you exact numbers until I know for sure what's the diameter of the rods
<whitequark>
but think somewhere between 1 and 6 MHz, maybe 3
<whitequark>
what does that change?
<sb0>
how do you plan on generating those?
<whitequark>
grab the cheapest DDS devboard I can find
<whitequark>
the 2nd one seems unimplementable in an FPGA
<sb0>
whitequark, there's an arbiter between the two masters.
<sb0>
those diagrams are copy-paste from the wishbone specification document, which is very obtuse and I recommend ignoring
<sb0>
the "pipeline" is just cores making regular point-to-point wishbone transactions
<whitequark>
oh.
<whitequark>
that's a very unhelpful way of putting it
<sb0>
yes, the whole wishbone doc is like that
<sb0>
the doc also has this weird license
<sb0>
"The Publisher grants you the following rights for re-distribution of this ebook. [NO] Can be submitted to article directories (even YOURS) IF at least half is rewritten! [NO] Can be offered through auction sites. etc"
<whitequark>
sb0: what's "cti" and "bte" in wishbone.Interface ?
<sb0>
burst control signals
<sb0>
you can ignore for simple designs
<whitequark>
yeah
fengling has quit [Ping timeout: 268 seconds]
<whitequark>
sb0: so if I use registered feedback, access takes two cycles but the critical path is cut in hakf
<whitequark>
*half
<whitequark>
what's the benefit?
<sb0>
it doesn't slow down the rest of your design
<sb0>
only the bus is slow. and you can make it less slow by using bursts.
<whitequark>
oh
<larsc>
well, you can't really burst mmio register access
<whitequark>
why not, actually?
<larsc>
hm, maybe you can
<larsc>
depends on the barrier implementation of the CPU