<_florent_>
Providing deterministic latency with SDRAM can indeed be tricky due to refresh but there are technique to mitigate the impacts (ex postpone them)
<_florent_>
the data should stay in SDRAM without corruption for at least a few seconds
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
FabM has joined #litex
FabM has joined #litex
<kbeckmann>
thanks, i will give it a shot later today :)
<_florent_>
nice project BTW!
<_florent_>
what's the maximal expected latency for the N64 accesses?
<kbeckmann>
thanks! it seems to be around 300ns. there is a way to get slower accesses but it would be fun to stay compatible with the default config.
<kbeckmann>
i am targeting an ECP5 speedgrade 6, so i'll probably keep the system clock at around 50 MHz and run the SDRAM with 1:2 gearing. currently i am doing 32 bit reads but it probably makes more sense to go for raw 16 bit accesses since that's the width of the n64 cartridge bus and the physical SDRAM, maybe i can save a few cycles going for that.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt>
300 ns should be plenty of time, even running the SDRAM at 50 MHz.
<tnt>
You can operate down to CL=1 at that frequency.
<tnt>
"<ACTIVE> <READ> <NOP (grab data)> <NOP (auto-precharge)> <AUTO-REFRESH> <NOP> <NOP> <NOP>" that cycle can be repeated (at 50 MHz), includes continuous refresh and is only 160 ns. And if you don't need the refresh at that time, you can sneak in a R/W for CPU.
<kbeckmann>
ah, good to know!
<tnt>
What speedgrade did you use btw ?
<kbeckmann>
right now i just use a more or less "random" SDRAM that i had around. K4S561632J-UC75
<tnt>
arf, that's the slowest there is, might need a couple more cycles.
<kbeckmann>
ah i see. i need to get a better understanding of what to look for in SDRAMs.
<tnt>
-6 or -6A :)
<kbeckmann>
this is just on an old board that i made a few years ago. the project will use whatever is suitable :). haven't finished the design.
<kbeckmann>
alright
<tnt>
I'm surprised you have that long TBH. At 300 ns, you could use one of those SPI PSRAM and be fast enough.
<RaYmAn_>
I think those SDRAM chips there was some random aliexpress purchase at like 2$ for 10 so can't expect much =P
RaYmAn_ is now known as RaYmAn
<kbeckmann>
ah that's right. literally random sdram :).
<kbeckmann>
i have a bunch of those PSRAMs as PMODs so that should be easy to set up. could use two in parallel
<tnt>
You have time to grab the 16 bits from a single one.
<kbeckmann>
cool. might give it a shot after work today
<_florent_>
kbeckmann: the 300ns also seems high, I'm not familiar with the N64, but just looked at a N64 cart
<_florent_>
the latency of the MX23L6402-35E seems to be around 100-150ns
<kbeckmann>
it could be that the latency requirements are more relaxed during the early boot. the bootloader loads 1MB of the ROM into RAM and executes from there. later, maybe the program can do faster accesses later on, i'm not sure.
<kbeckmann>
during this phase, i could also start the read when i have received the address but before the read signal is sent, and then i'd have the data ready immediately when the read pin toggles. however, it seems that this is just a special case during boot.
<_florent_>
that would indeed be nice to sniff the access after boot to be sure of minimal latency you have to emulate (if the info is not already available somewhere)
C-Man has joined #litex
<Melkhior>
kbeckmann:I'm not a HW guy, but why not HyperRam? From my (limited) understanding, it should be smaller/faster/easier than SDRAM
<RaYmAn>
might not matter but isn't it also fairly high latency?
<zyp>
with the HyperRAMX2 module hooked up to a W956A8MBYA5I I measured 16 cycles of latency at the wishbone bus
<zyp>
at the 75 MHz I ran it at, that's 213ns, but I figure it'll do the same number of cycles at 100 MHz, bringing it down to 160ns
<zyp>
(those numbers are wishbone clock, hyperram clock is twice that)
C-Man has quit [Ping timeout: 244 seconds]
C-Man has joined #litex
peepsalot has quit [Ping timeout: 244 seconds]
a3f has quit [Quit: Bridge terminating on SIGTERM]
jryans has quit [Quit: Bridge terminating on SIGTERM]
promach[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
dcallagh has quit [Quit: Bridge terminating on SIGTERM]
CarlosEDP has quit [Quit: Bridge terminating on SIGTERM]
kaji has quit [Quit: Bridge terminating on SIGTERM]
leons has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
vomoniyi[m] has quit [Quit: Bridge terminating on SIGTERM]
david-sawatzke[m has quit [Quit: Bridge terminating on SIGTERM]
OmkarBhilare[m] has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
DerekKozel[m] has quit [Quit: Bridge terminating on SIGTERM]
jryans has joined #litex
shoragan[m] has joined #litex
dcallagh has joined #litex
jevinskie[m] has joined #litex
CarlosEDP has joined #litex
kaji has joined #litex
promach[m] has joined #litex
leons has joined #litex
sajattack[m] has joined #litex
vomoniyi[m] has joined #litex
DerekKozel[m] has joined #litex
david-sawatzke[m has joined #litex
OmkarBhilare[m] has joined #litex
a3f has joined #litex
peepsalot has joined #litex
FabM has quit [Ping timeout: 244 seconds]
alainlou has joined #litex
<Melkhior>
_florent_: hypothetically, if I wanted to connect a SATA device to a LiteSata controller in an Artix-7, is there something comlpex to do ? Or would I just connect a MGT_TX to SATA_TX, MGT_RX to SATA_RX, and have a set of 10 nF coupling capacitors?
<Melkhior>
do the TX and RX pair need to be length-matched to each other, or does it not matter (i.e. they just need the + and - to be matched)
<Melkhior>
... and is it MGT_TX to SATA_TX (pins 2/3), or SATA_RX (pins 5/6) - I can never figure out if RX/TX is from the PoV of the device (RX to RX), the host (RX to RX as well), or both (RX to TX, i.e. serial lines)
<Melkhior>
TIA
Martoni42 has joined #litex
<jevinskie[m]>
Is it possible to submit read commands in all four phases of DFI in a single cycle or do I have to always submit reads only on the “read phase” (and likewise for the write phase)?
<_florent_>
Melkhior: SATA is in fact very easy to add to an Artix-7, the coupling is generally already present in the device so not required
<_florent_>
PCIe --> PCIe Riser --> USB3 cable --> SATA
<_florent_>
you can also swap P/N, the core will detect it
<Melkhior>
_florent_: thx, it's swapping RX/TX I'm worried about mostly, as I understand those MGT pins are one-way ?
<_florent_>
and length matching is not required between TX/RX (only between P/N of a pair)
<_florent_>
the MGT pins are on-way yes, so TX of the FPGA to the RX of the Device, TX of the Device to the RX of the FPGA
<Melkhior>
OK... but when I see a diagram for the pins of PCB-side socket, do they show device-side or host-side? I always find this confusing for some reason :-/
<Melkhior>
They say 'A' (pins 2&3) is TX, so it should go the the MGT_TX of the FPGA ?
<Melkhior>
sorry, MGT_*RX* of the FPGA ?
<Melkhior>
to match RX with TX
<Melkhior>
Unless it's TX from the host PoV ... that's what I like SBus, big parallel thingy with no +/- or RX/TX :-)
<Melkhior>
Thanks for the answers, clearer in my head and I know what I need to look for in more details
<Melkhior>
Should I go mad(der) and do a SBusFPGA V2 with SATA and HDMI
<Melkhior>
:-)
<Melkhior>
By then I guess there will be a Wishbone PCIe root complex in Litex, and i'll want to add PCIe as well :-)
<Melkhior>
Oh perfect thanks ! So the FPGA's MGT_TX goes to A, the FPGA MGT_RX goes to B, and they can be length-mismatched
<Melkhior>
as long as the pair is properly done
<Melkhior>
so SATA is probably not hard on a PCB, even with the decoupling capacitors, if there's enough room
<Melkhior>
THX again :-)
<_florent_>
Melkhior: that's the nice thing with serial links: the core can be complex but it simplifies the hardware :)
<Melkhior>
_florent_: suits me fine - as you're the one doing the core and I'm the one doing the HW ;-)
<Melkhior>
And indeed, routing the 28 adress, 32 data, clock and other assorted signals of SBus is not the easiest part...
<Melkhior>
Buf I were to do a 'high-speed serial' version of my design, I'd probably need to use something like a Trenz TE0712, and the 'peripheral' would be more powerful than the host with an Artix-7 100T-2 ...
<Melkhior>
First, I need to get back the V1.2 from Seeed and make sure it works, in particular the USB stuff
<somlo>
hmmm, I wonder if the "Xilinx FMC XM 104" card should allow me to use litesata with LiteX, without having to solder anything (https://www.xilinx.com/products/boards-and-kits/hw-fmc-xm104-g.html) -- at least it's sub-$1000, cheaper than the dgway board I saw used previously...
<_florent_>
happy to send you one once validated if you want to work on the LiteSATA linux driver :)
<somlo>
hmm... sounds interesting :)
<somlo>
btw, I seem to recall that the lambdaconcept ecpix5 board has a sata connector out of the box -- was the issue that litesata isn't currently supported on ecp5, or did I misunderstand that part ?
<Melkhior>
_florent_: dumb question about those drivers; wouldn't it be "easier" to re-use a standard driver by emulating an existing controller or a standard like AHCI ?
<Melkhior>
Having out-of-the-box support for the OHCI USB was a boon - I could assume the driver was working when working on my bridge
<Melkhior>
(but then, I have no idea how complex AHCI is...)
Martoni42 has quit [Ping timeout: 240 seconds]
<tpw_rules>
_florent_: i re-installed litex from scratch and tried to build the crossover uart for the cle-215 with vivado 2018.2 and it still dies with the set_clock_group command because there's no clock named 'main_crg_clkout0'
<tpw_rules>
i'm puzzled that you say it works
pftbest has quit [Remote host closed the connection]