gpmc seems to occasionally mis-time address/data

[osresearch]

I've been trying to track down why sdram results are sometimes wrong (issue #7) and think it might be due to gpmc occasionally mis-timing data and address. I modified the examples/sdram/top.v to require the top 8-bits of the commands to have a magic value and log any writes to gpmc address 0 that don't have those bits.

For a while everything is fine, but then a spurious value shows up, usually with some bits of the previous write.

icetime is reporting that we're meeting the 100 MHz timing goal (9.08 ns / 110.08 MHz), so I think it is related to the clock-crossing in gpmc.

[pmezydlo]

On first BW revision, during devlopment most of examples gpmc clock was 100MHz then all worked fine but on second BW revision I met firsts similar issues. I moved clock to 200MHz issue was fixed but probably not for all cases. synchronization two different clocks is dificult and I'm not sure if It works correctly. I will try take a look on it in this week. pon., 9 lip 2018 o 22:56 Trammell Hudson <notifications@github.com> napisał(a):

…

I've been trying to track down why sdram results are sometimes wrong (issue #7 <#7>) and think it might be due to gpmc occasionally mis-timing data and address. I modified the examples/sdram/top.v to require the top 8-bits of the commands to have a magic value and log any writes to gpmc address 0 that don't have those bits. For a while everything is fine, but then a spurious value shows up, usually with some bits of the previous write. icetime is reporting that we're meeting the 100 MHz timing goal (9.08 ns / 110.08 MHz), so I think it is related to the clock-crossing in gpmc. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANKxSAXlUHEXndQ4KQzk8d0r64VgvKFjks5uE8NngaJpZM4VIYCu> .

[osresearch]

Did you verify with icetime that you could run at 200 MHz? With only four levels I'm barely over 100 MHz (if I'm using the tool correctly):

icetime \
	-d hx8k \
	-p pinmap.pcf \
	-P tq144:4k \
	-C /usr/share/icestorm/chipdb-8k.txt \
	-r sdram.timing \
	-t sdram.asc
[...]
Resolvable net names on path:
     0.640 ns ..  1.229 ns sdram_controller_1.state[2]
     1.678 ns ..  2.267 ns $abc$7347$n238
     2.667 ns ..  4.518 ns $abc$7347$n237
     4.897 ns ..  6.089 ns $abc$7347$n391
     6.405 ns ..  8.804 ns sdram_addr[10]$2

Total number of logic levels: 5
Total path delay: 8.87 ns (112.69 MHz)

[pmezydlo]

I tested it on real hardware and debugging based on output from oscilloscope, I did not use icetime yet. pon., 9 lip 2018 o 23:32 Trammell Hudson <notifications@github.com> napisał(a):

…

Did you verify with icetime that you could run at 200 MHz? With only four levels I'm barely over 100 MHz (if I'm using the tool correctly): icetime \ -d hx8k \ -p pinmap.pcf \ -P tq144:4k \ -C /usr/share/icestorm/chipdb-8k.txt \ -r sdram.timing \ -t sdram.asc [...] Resolvable net names on path: 0.640 ns .. 1.229 ns sdram_controller_1.state[2] 1.678 ns .. 2.267 ns $abc$7347$n238 2.667 ns .. 4.518 ns $abc$7347$n237 4.897 ns .. 6.089 ns $abc$7347$n391 6.405 ns .. 8.804 ns sdram_addr[10]$2 Total number of logic levels: 5 Total path delay: 8.87 ns (112.69 MHz) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANKxSGKA_fJID4NUuyI9kJo1JULuRPasks5uE8v-gaJpZM4VIYCu> .

[osresearch]

Using the 200 MHz PLL I see the same sort of behaviour with wrong values being written into the GPMC registers. I don't have my fast scope with me to watch it on the PMOD port, so I'm debuggng via FIFO and poking at things.

[osresearch]

With this version of gpmc-sync.v my random GPMC read/write test returns zero errors. Previously it was seeing around 1-3% error rates. https://github.com/osresearch/BeagleWire/blob/6dc055f7da8b8e1d95037da198cb332f1fa605ae/components/gpmc-sync.v

I'm working on a GPMC and bridge cleanup branch. Hoping to get the SDRAM working reliably as part of the commit and will put together a pull request once it works.

[osresearch]

GPMC top.v: https://github.com/osresearch/BeagleWire/blob/bridge-cleanup/examples/gpmc/top.v
Random gpmc test: https://github.com/osresearch/BeagleWire/blob/bridge-cleanup/bridge_lib/gpmc.c

[osresearch]

I added timing into the gpmc test:

write 4194304 words in 1.181069 sec = 3.551 MT/s
read  4194304 words in 1.813794 sec = 2.312 MT/s errors=0

So I guess this means it takes about 7 GPMC clock cycles (at 25 MHz) per write and 10 for reads.

[ombhilare999]

The old gpmc converter IP is changed, now we are converting gpmc to wishbone.
The converter IP can be found here: https://github.com/BeagleWire/BeagleWire/blob/testing/components/gpmc_to_wishbone.v
The example for IP use with instructions: https://github.com/BeagleWire/BeagleWire/tree/testing/examples/arm_blink_leds
Docs of beaglewire are here: https://beaglewire.github.io/

With these new changes, there should be no issue now. But if again found I will reopen the thread, thank you.

regards,
Omkar Bhilare
ombhilare999@gmail.com