_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
<jevinskie[m]> I found the same experience to be exhilarating :)
toshywoshy has quit [Ping timeout: 260 seconds]
toshywoshy has joined #litex
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #litex
genpaku has quit [Ping timeout: 272 seconds]
genpaku has joined #litex
davebee has joined #litex
<davebee> Litex uses a gcc cross-compiler : I'm using litex/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14 so you need to build your C code using eg litex/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14/bin/riscv64-unknown-elf-gcc
<davebee> I'm building my application code using scons, so I set the toolchain to point to the programs in the bin directory.
<davebee> I have a question on the vexriscv. Not sure if this is the right place to ask it. I had an error caused by a misaligned data read. This causes an exception. How should this be handled? Simply detecting it and calling a software break would be enough, but I'm not sure I can tell that what exception source is for this error.
<davebee> It is encoded in the mcause register. Sorry for the noise.
betocool has joined #litex
<betocool> Hey all, I have a question (or push in the right direction!) about the litedram module. My goal is to implement the neorv32 processor with my own customisations and the wishbone interface to the SDRAM on a Cyclone IV De0Nano. I found a project which does all that, but the SDRAM module is discontinued as IP block in Quartus.
<betocool> I was able to generate a .v file by creating a new yaml file with the IS42S16160 module just for fun. Had to change a few things on the gen.py file to get that running but it seems to have worked, because it generated a litedram_core.v file and did not complain.
<betocool> But I'm confused about the settings on the Yaml file, because the dictionary for other DRAM chips offers Wishbone, AXI, native and FIFO user ports. How do I tell the "gen.py" file that I really only need wishbone? I could not find those settings in the other build parameters.
davebee has quit [Quit: Leaving]
<betocool> I'm still getting my head around how all goes together. It'll take me a while, but I'm sure I'll get there. As for the motivation why? Well... I would just like to mix and match, that's all!
<betocool> Also... what's the point of the UART setting in the config file?
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
betocool has quit [Quit: Client closed]
genpaku has quit [Remote host closed the connection]
genpaku has joined #litex
FabM has quit [Quit: Leaving]
genpaku has quit [Quit: leaving]
genpaku has joined #litex
Johnsel has joined #litex
subthreshold has joined #litex
<subthreshold> Hi, it's been a while! I just wanted to ask a quick question - the way the LiteDRAM memory controller is designed, it doesn't operate in terms of DFI "frequency" ratios right?
<subthreshold> Namely, all the timing controllers seem to be operating off the JEDEC nck specification, which means that it's counting in terms of clock domain of the DRAM?
<subthreshold> Where as in a DFI system, the MC could potentially be operating at 1/2 or 1/4 speed of the DRAM domain.
<johnsel92[m]> afaik (and that is not a lot) the pll to DRAM clock derivation happens automagically
<johnsel92[m]> there are option to run the DRAM in SDR or DDR modes
<johnsel92[m]> maybe the example implementations for the platform/boards show you how to do what you want
<johnsel92[m]> specifically #38-47 and #61-71
<johnsel92[m]> module = AS4C128M16(sys_clk_freq, "1:4"),
<johnsel92[m]> * ```
<johnsel92[m]> ```
<johnsel92[m]> module = AS4C128M16(sys_clk_freq, "1:4"),
<johnsel92[m]> * ```#70
<johnsel92[m]> ```
<johnsel92[m]> AS4C128M16(sys_clk_freq, "1:4"),
<subthreshold> Gotcha. I noticed these too, but I was confused about how the MC tracks timing parameters in cases where 1:4 is used.
<johnsel92[m]> * ```
<johnsel92[m]> AS4C128M16(sys_clk_freq, "1:4"),
<johnsel92[m]> ```
<subthreshold> Let me pull up something
<subthreshold> 144- 148
<subthreshold>         # tWTP (write-to-precharge) controller -----------------------------------------------------
<subthreshold>         write_latency = math.ceil(settings.phy.cwl / settings.phy.nphases)
<subthreshold>         precharge_time = write_latency + settings.timing.tWR + settings.timing.tCCD # AL=0
<subthreshold>         self.submodules.twtpcon = twtpcon = tXXDController(precharge_time)
<subthreshold>         self.comb += twtpcon.valid.eq(cmd.valid & cmd.ready & cmd.is_write)
<subthreshold> WL is originally specified in terms of no. of CK cycles in terms of the PHY+DRAM Device Time Domain
<subthreshold> if there's a 1:4 ratio, then dividing this by 4 converts it to the number of clock cycles in the MC Domain
<tpb> Title: LimeSDR Mini 2.0 - LiteX Support | Crowd Supply (at www.crowdsupply.com)
<subthreshold> But TWR isn't divided by 4!
<subthreshold> and neither is TCCD
<subthreshold> so I am attempitng to figure out what domain these TXXD controllers are operating on in a ratio'ed system
<subthreshold> and why some parameters are divided down by nphases while others aren't, if that makes sense.
genpaku has quit [Quit: leaving]
<johnsel92[m]> honestly this goes beyond my knowledge I was able to use things successfully without understanding these details, but perhaps it helps to know that there is a lot of functionality implemented in e.g. https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/dfi.py#L107
<johnsel92[m]> based on my understanding these values are precalculated either in that file or in one of it's sibling files
<subthreshold> Gotcha, I would like to make the MC fully DFI compatible
<subthreshold> and thats why I'm examining these parameters
<subthreshold> is there someone else who would know about this in greater depth, perhaps florent?
<johnsel92[m]> undoubtedly, the commit logs show who contributed what
<subthreshold> Got it, thanks a lot John
<johnsel92[m]> you are welcome, and there are several files called dfi/dfii that most likely are related to what you are looking for
<johnsel92[m]> and perhaps it's useful to realise that as it's python you can step through the code while it's running and inspect variables with a debugger
<johnsel92[m]> you can easily build some device and hook a debugger up to see what comes from where
<subthreshold> (y) , though I suspect this may be more of an architectural point than anything.
<subthreshold> Hi _florent_, I just wanted to ask a quick question about the way the LiteDRAM memory controller is designed. Walking through the code, I see there is a partial implementation of DFI, and that there are phases and frequency ratios supported. However, the timing controllers are all defined in terms of "NCK" from JEDEC. In a frequency ratio system
<subthreshold> (e.g., 1:4), this would be on the PHY+Memory domain. However, the MC timing controllers seem to work off this domain already.
<subthreshold>         # tWTP (write-to-precharge) controller -----------------------------------------------------
<subthreshold>         write_latency = math.ceil(settings.phy.cwl / settings.phy.nphases)
<subthreshold>         precharge_time = write_latency + settings.timing.tWR + settings.timing.tCCD # AL=0
<subthreshold>         self.submodules.twtpcon = twtpcon = tXXDController(precharge_time)
<subthreshold>         self.comb += twtpcon.valid.eq(cmd.valid & cmd.ready & cmd.is_write)
<subthreshold> write_latency/ nphases makes sense, but why isn't the same applied to tWR? Does this mean that in general the MC needs to be running on a 1:1 with the PHY+MC in this implementation?
<johnsel92[m]> so just to be sure, you're not looking for: https://github.com/enjoy-digital/litedram/blob/master/litedram/modules.py#L493
<johnsel92[m]> _TechnologyTimings(tREFI=64e6/4096, tWTR=(2, None), tCCD=(1, None), tRRD=(None, 14))
<johnsel92[m]> _SpeedgradeTimings(tRP=22, tRCD=21, tWR=20, tRFC=(None, 63), tFAW=None, tRAS=42)
<subthreshold> No, those are spec sheet parameters which I have as well.
<johnsel92[m]> those, right?
<subthreshold> it's the question of the domain on which they're counted in a DFI5.1 ratio'ed system.
<subthreshold> Because a ratio'ed system would have MC running at say, 1/4 speed of PHY+Memory.
<subthreshold> In this case you cannot count those parameters in TCCD but must instead divide by 4 to convert it to MC domain
<subthreshold> count those parameters in NCK*
<subthreshold> but I don't see this happening. Which makes me confused about how the phases were implemented to begin with.