| *** tpb has joined #tomu | 00:00 | |
| *** xkapastel has quit IRC | 03:41 | |
| *** xkapastel has joined #tomu | 04:21 | |
| mithro | xobs: So, I'm just trying to figure out how to import Tomu designs into litex-buildenv | 05:11 |
|---|---|---|
| xobs | mithro: shouldn't you just need to comment out "lxbuildenv"? Or create a dummy "lxbuildenv.py" file that's empty. | 05:12 |
| xobs | The next version of Foboot will use upstreamed modules, now that things are stabilizing. | 05:21 |
| xobs | But the first thing I need to finish is the USB stack. | 05:21 |
| xobs | By 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 |
| mithro | xobs: ask in #LiteX or #m-labs | 05:50 |
| mithro | xobs: The lack of UART is the what I'm pondering... | 05:53 |
| xobs | Oh, 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 |
| xobs | If I add reset signals by hand, it could add gates to the final design. I only need it for simulation. | 06:03 |
| xobs | https://github.com/xobs/valentyusb/blob/2b445108025d42ae0668f563d11826012b43a4d8/cocotb-simulate.py#L151 | 06:04 |
| tpb | Title: valentyusb/cocotb-simulate.py at 2b445108025d42ae0668f563d11826012b43a4d8 · xobs/valentyusb · GitHub (at github.com) | 06:04 |
| _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 |
| xobs | I'm just doing a flopped output. No pll in there. | 06:05 |
| xobs | I do expose both clk12 and clk48 out the top, though. | 06:06 |
| _florent_ | ok so, here i think you should add a rst48, rst12: https://github.com/xobs/valentyusb/blob/2b445108025d42ae0668f563d11826012b43a4d8/cocotb-simulate.py#L58-L61 | 06:06 |
| tpb | Title: valentyusb/cocotb-simulate.py at 2b445108025d42ae0668f563d11826012b43a4d8 · xobs/valentyusb · GitHub (at github.com) | 06:06 |
| _florent_ | or just do a single reset | 06:07 |
| _florent_ | and in your CRG, do something like | 06:08 |
| _florent_ | https://www.irccloud.com/pastebin/YmHhpNkj/ | 06:08 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 06:08 |
| xobs | I 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 cocotb | 06:09 |
| *** xkapastel has quit IRC | 07:51 | |
| *** W1lkins has quit IRC | 09:36 | |
| *** W1lkins has joined #tomu | 09:37 | |
| *** NeedNotApply has joined #tomu | 10:31 | |
| NeedNotApply | Hello. | 10:32 |
| NeedNotApply | Have Fomu boards started shipping? | 10:33 |
| xobs | NeedNotApply: 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 |
| xobs | They've shipped from China, but not from Portland. | 10:34 |
| NeedNotApply | Ah, I see. | 10:35 |
| NeedNotApply | Can't wait to get my hands on it. :> | 10:36 |
| xobs | I'm looking forward to that, too! | 10:39 |
| *** jas4711 has quit IRC | 10:39 | |
| NeedNotApply | Also this question might possibly be very stupid. | 10:44 |
| NeedNotApply | And you should know I'm a newbie at hardware dev. | 10:44 |
| NeedNotApply | https://github.com/im-tomu/foboot/tree/master/hw/rtl <- Is ALL OF THIS synthesized and uploaded into that tiny FPGA?? | 10:45 |
| tpb | Title: foboot/hw/rtl at master · im-tomu/foboot · GitHub (at github.com) | 10:45 |
| xobs | That's a good question! | 10:45 |
| *** jas4711 has joined #tomu | 10:45 | |
| xobs | The 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 |
| xobs | So if you're using it with the defaut "RISC-V" mode, you're actually using the CPU from https://github.com/im-tomu/foboot/blob/master/hw/rtl/2-stage-1024-cache-debug.v plus a lot of glue, including the whole USB stack. | 10:46 |
| tpb | Title: foboot/2-stage-1024-cache-debug.v at master · im-tomu/foboot · GitHub (at github.com) | 10:46 |
| NeedNotApply | I see. Still very impressive. | 10:47 |
| NeedNotApply | I don't suppose this Verilog code is meant to be modifier by hand, is it? | 10:48 |
| xobs | Not at all. | 10:49 |
| xobs | That's in an "rtl" directory because we pull it in from another project. | 10:49 |
| xobs | The CPU comes from a different programming language called Scala, which generates a verilog file as an output: https://github.com/SpinalHDL/VexRiscv | 10:49 |
| tpb | Title: GitHub - SpinalHDL/VexRiscv: A FPGA friendly 32 bit RISC-V CPU implementation (at github.com) | 10:49 |
| NeedNotApply | Ah, this makes a lot more sense. | 10:50 |
| xobs | It'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 |
| NeedNotApply | Awesome. | 10:51 |
| NeedNotApply | How many cells or elements or LUTs or what-Lattice-calls-them does this use? | 10:53 |
| xobs | More than I'd like. We're almost full right now at 99%. | 10:54 |
| NeedNotApply | Ow. | 10:54 |
| xobs | I'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 |
| NeedNotApply | I see. What frequency does the softcore run at? | 10:57 |
| xobs | Right now, 12 MHz. | 10:57 |
| xobs | There's a lot of room for improvement. | 10:57 |
| NeedNotApply | 12? There must be a hell of a critical path. :O | 11:00 |
| xobs | Mostly 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 |
| xobs | Currently the critical path looks to be the 32-bit adder, though. | 11:02 |
| NeedNotApply | I see. | 11:07 |
| xobs | We might be able to get the softcore to run at 24 MHz. That'll require experimentation. | 11:07 |
| xobs | But I've been focusing on getting the USB stuff to be solid. | 11:08 |
| NeedNotApply | Yeah, getting it to work is more important than squeezing all the performance out of it. | 11:09 |
| *** xkapastel has joined #tomu | 11:26 | |
| MadHacker | xobs: 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 |
| MadHacker | Or, for that matter, set the reset= on the Signal() or reference the current clock domain's rst? | 13:42 |
| xobs | MadHacker: I'm not familiar with how that works. How would that propagate down to reset the various registers to their initial values? | 13:43 |
| MadHacker | OK, so migen's Signal() has a default reset behaviour anyway. | 13:43 |
| xobs | I guess the question becomes -- how does that get turned into verilog? | 13:44 |
| MadHacker | always @(posedge clk) begin if (sys_rst) begin signal=0 end else begin <whatever other .eq stuff you've specified for the signal> end end | 13:44 |
| MadHacker | (where sys_rst is your default ClockDomain()'s .rst but you can obviously specify others) | 13:45 |
| MadHacker | https://paste.debian.net/1094034/ | 13:50 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 13:50 |
| MadHacker | No else clause actually, it just relies on the sequence of operations, but the result is equivalent. | 13:51 |
| MadHacker | Oh, 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 |
| MadHacker | Now I try it, you can even be lazy. self.sync += [ ResetSignal().eq(1) ] | 14:00 |
| xobs | Interesting! 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 |
| MadHacker | You 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 #tomu | 14:45 | |
| *** xkapastel has quit IRC | 19:45 | |
| *** xkapastel has joined #tomu | 21:09 | |
| *** emeb has quit IRC | 21:43 | |
| *** emeb has joined #tomu | 21:48 | |
| *** Summertime has quit IRC | 22:36 | |
| *** Summertime has joined #tomu | 22:38 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!