Friday, 2019-08-02

*** tpb has joined #tomu00:00
*** xkapastel has quit IRC03:41
*** xkapastel has joined #tomu04:21
mithroxobs: So, I'm just trying to figure out how to import Tomu designs into litex-buildenv05:11
xobsmithro: shouldn't you just need to comment out "lxbuildenv"?  Or create a dummy "" file that's empty.05:12
xobsThe next version of Foboot will use upstreamed modules, now that things are stabilizing.05:21
xobsBut the first thing I need to finish is the USB stack.05:21
xobsBy the way, is there any way to insert a reset into a Migen object?  I've tried ResetInserter, but it doesn't like the fact that there are already ResetInserters / clock domains that get crossed within the module.05:22
mithroxobs: ask in #LiteX or #m-labs05:50
mithroxobs: The lack of UART is the what I'm pondering...05:53
xobsOh, it assumes there's a uart? Can you #ifdef it out?05:55
_florent_xobs: i can try to help on the ResetInserter, is the code online?06:00
xobs_florent_: it is. I'm trying to add a ResetInserter to the entire USB block. It's because cocotb doesn't reset the simulator during runs, so I want to manually reset things.06:02
xobsIf I add reset signals by hand, it could add gates to the final design. I only need it for simulation.06:03
tpbTitle: valentyusb/ at 2b445108025d42ae0668f563d11826012b43a4d8 · xobs/valentyusb · GitHub (at
_florent_ok i see, in your cocotb simulation, are you using also simulating the iCE40PLL or are you exposing the different clock domains to the top?06:04
xobsI'm just doing a flopped output. No pll in there.06:05
xobsI do expose both clk12 and clk48 out the top, though.06:06
_florent_ok so, here i think you should add a rst48, rst12:
tpbTitle: valentyusb/ at 2b445108025d42ae0668f563d11826012b43a4d8 · xobs/valentyusb · GitHub (at
_florent_or just do a single reset06:07
_florent_and in your CRG, do something like06:08
tpbTitle: Snippet | IRCCloud (at
xobsI need to zero out various signals as part of the reset. For example, clearing byte counters and resetting fifos.06:09
_florent_and drive this rst signal with cocotb06:09
*** xkapastel has quit IRC07:51
*** W1lkins has quit IRC09:36
*** W1lkins has joined #tomu09:37
*** NeedNotApply has joined #tomu10:31
NeedNotApplyHave Fomu boards started shipping?10:33
xobsNeedNotApply: Hi!  I have an update pending with Crowd Supply right now.  They ought to be on their way to Portland now.  So... kinda?10:34
xobsThey've shipped from China, but not from Portland.10:34
NeedNotApplyAh, I see.10:35
NeedNotApplyCan't wait to get my hands on it. :>10:36
xobsI'm looking forward to that, too!10:39
*** jas4711 has quit IRC10:39
NeedNotApplyAlso this question might possibly be very stupid.10:44
NeedNotApplyAnd you should know I'm a newbie at hardware dev.10:44
NeedNotApply <- Is ALL OF THIS synthesized and uploaded into that tiny FPGA??10:45
tpbTitle: foboot/hw/rtl at master · im-tomu/foboot · GitHub (at
xobsThat's a good question!10:45
*** jas4711 has joined #tomu10:45
xobsThe answer is no, we only use 2-stage-1024-cache.v or 2-stage-1024-cache-debug.v.  And that forms the basis of the CPU.10:45
xobsSo if you're using it with the defaut "RISC-V" mode, you're actually using the CPU from plus a lot of glue, including the whole USB stack.10:46
tpbTitle: foboot/2-stage-1024-cache-debug.v at master · im-tomu/foboot · GitHub (at
NeedNotApplyI see. Still very impressive.10:47
NeedNotApplyI don't suppose this Verilog code is meant to be modifier by hand, is it?10:48
xobsNot at all.10:49
xobsThat's in an "rtl" directory because we pull it in from another project.10:49
xobsThe CPU comes from a different programming language called Scala, which generates a verilog file as an output:
tpbTitle: GitHub - SpinalHDL/VexRiscv: A FPGA friendly 32 bit RISC-V CPU implementation (at
NeedNotApplyAh, this makes a lot more sense.10:50
xobsIt's kind of like how you can write code in one programming language and link it in another language.  The universal "object code" format for hardware is Verilog.10:50
xobs(or VHDL)10:50
NeedNotApplyHow many cells or elements or LUTs or what-Lattice-calls-them does this use?10:53
xobsMore than I'd like.  We're almost full right now at 99%.10:54
xobsI'm working on trimming that back.  For example, the USB<->CPU pathway is entirely in LUTs right now, which is using up about 10% of that.10:55
NeedNotApplyI see. What frequency does the softcore run at?10:57
xobsRight now, 12 MHz.10:57
xobsThere's a lot of room for improvement.10:57
NeedNotApply12? There must be a hell of a critical path. :O11:00
xobsMostly it's because it's not a high-performance FPGA.  There's also some tuning that could be done in the pnr tool to get it to a faster frequency.11:02
xobsCurrently the critical path looks to be the 32-bit adder, though.11:02
NeedNotApplyI see.11:07
xobsWe might be able to get the softcore to run at 24 MHz.  That'll require experimentation.11:07
xobsBut I've been focusing on getting the USB stuff to be solid.11:08
NeedNotApplyYeah, getting it to work is more important than squeezing all the performance out of it.11:09
*** xkapastel has joined #tomu11:26
MadHackerxobs: Did you find your "insert a reset" thing? Can't just do self.cd_sys.rst.eq(1) if you want to trigger one?13:42
MadHackerOr, for that matter, set the reset= on the Signal() or reference the current clock domain's rst?13:42
xobsMadHacker: I'm not familiar with how that works.  How would that propagate down to reset the various registers to their initial values?13:43
MadHackerOK, so migen's Signal() has a default reset behaviour anyway.13:43
xobsI guess the question becomes -- how does that get turned into verilog?13:44
MadHackeralways @(posedge clk) begin if (sys_rst) begin signal=0 end else begin <whatever other .eq stuff you've specified for the signal> end end13:44
MadHacker(where sys_rst is your default ClockDomain()'s .rst but you can obviously specify others)13:45
tpbTitle: debian Pastezone (at
MadHackerNo else clause actually, it just relies on the sequence of operations, but the result is equivalent.13:51
MadHackerOh, sorry, maybe you're talking about driving reset. That ends up largely the same, but you're literally just turning sys_rst into an output.13:56
MadHacker(which is largely OK, as long as everyone agrees about who's driving it)13:57
MadHackerNow I try it, you can even be lazy. self.sync += [ ResetSignal().eq(1) ]14:00
xobsInteresting!  I didn't realize it worked that way.  That solves my problem very nicely.  And is basically what _florent_ was saying but I didn't understand how it was solving the problem.14:02
MadHackerYou might want to take your "real" reset signal and run it through an OR with a manually triggerable reset before distributing it to sys_rst, as a matter of practicality.14:03
*** emeb has joined #tomu14:45
*** xkapastel has quit IRC19:45
*** xkapastel has joined #tomu21:09
*** emeb has quit IRC21:43
*** emeb has joined #tomu21:48
*** Summertime has quit IRC22:36
*** Summertime has joined #tomu22:38

Generated by 2.13.1 by Marius Gedminas - find it at!