Giters

enjoy-digital / litex

Build your hardware, easily!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

clocker_storage_reg -> ODDR timing issue

Dolu1990 opened this issue · comments

commented

Hi,

Using python3 -m litex_boards.targets.digilent_nexys_video --cpu-type=naxriscv --bus-standard axi-lite --with-video-framebuffer --with-coherent-dma --with-sdcard --with-ethernet --xlen=64 --scala-args='rvc=true,rvf=true,rvd=true,alu-count=2,decode-count=2' --with-jtag-tap --sys-clk-freq 100000000 --cpu-count 2 --soc-json build/digilent_nexys_video/csr.json --update-repo no --load

(FPGA half full, 60K lut)
One timing issue I often hit is the following :
image
image

(the schematic show the path going through nas, but it isn't, probably some hierarchy flattening hallucinations ^^)

I'm not sure what to do about that path, it seems related to the sdcard. (ODDR goes to the sdcard)

Note, when the FPGA is less full, the timing is ok.

Regards
Dolu

commented

It seems that the clocker_storage combinatorialy drive the litex main internal memory bus read data, through quite some logic layers aswell :
image

This may be related to the timing issue, puting a lot of logic placement constraints on the clocker_storage to be "in the middle of them all, far from them all"

commented

Thanks @Dolu1990, I'll try to look at it soon.

commented

thanks ^^

Maybe the issue is more that the ODDR are combinatorialy connected to clocker_storage, and as the ODDR has a fixed location => long path

commented

Hi @Dolu1990,

I tried to do some timings improvements to LiteSDCard in this branch: https://github.com/enjoy-digital/litesdcard/commits/timing_improvements. I tested the build and no longer seems to see this path in the critical paths. This could be worth testing on your end. If this improve things, I'll try to integrate this properly.

commented
commented

Hi @gsomlo,

the changes done here do not affect the interface/use of the core, so this should not affect the linux driver changes.

commented

Thanks :D
I will test the changes ASAP (including the gbuf change)

commented

3c9b2410 is fine, debian run happily
8f15cbef (phy: Add buffers on SDPHYDATAW/R datapaths to improve timings.
) seems to break stuff, producing some instability on the sdcard access, which start to show up once in the kernel :
image

it isn't a 100% occurence bug.

wanna my to try parts of the commit 8f15cbef ?

commented

Thanks for the test. IIRC, the initial timing issue was on the CRC Inserter, before the PHY. So you can try to only keep the additional buffer on SDPHYDATAW and if still not working, only keep pipe_ready=True on it. (Set pipe_valid to False).

commented

Just tested.
Even with SDPHYDATAW pipe_ready= true (and the 3 other off) it create the issue.

About timings, it seems all good (without SDPHYDATAW / SDPHYDATAR buffers) (note i'm testing with the gbuf of #1813 (comment))

So i guess we can revert "phy: Add buffers on SDPHYDATAW/R datapaths to improve timings." and that's good to go.

Thanks :)

commented

@Dolu1990: Good, I'll do that yes then.