<_florent_>
I'm doing some clean up to miscope and have a question
<_florent_>
the mila configuration is exported to a .csv file
<_florent_>
I'm currently using backtrace[-1][0] to get the name of the signal, but this is not proper since when 2 or more signals have the same basename
<_florent_>
do you know what can I use instread to avoid that?
<sb0>
use the return_ns argument of verilog.convert, that gets you the "signal > unique name" dictionary used in the conversion
<_florent_>
thanks
aeris has quit [Quit: en a pas]
aeris has joined #m-labs
aeris has quit [Client Quit]
aeris has joined #m-labs
<sb0>
I see that Xilinx came again with a half-baked solution for dealing with DQS in the ISERDESE2
<sb0>
maybe in 50 years ddr3 will work reliably
<sb0>
"The OCLK clock input can be used to transfer strobe-based memory data onto a free-running clock domain. OCLK is a free-running FPGA clock at the same frequency as the strobe on the CLK input. [...] The timing of the domain transfer is set by the user by adjusting the CLK input (e.g., using IDELAY)."
<_florent_>
it's very interesting and they managed to simulate the phy with Icarus
sh4rm4 has joined #m-labs
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<sb0>
temperature compensation from the on-chip temperature sensor? MIG does that?
<sb0>
wtf
<sb0>
as I remember from the ddr3 datasheets, there are ample timing margins *if you use dqs correctly*, and I don't think this sort of active temperature compensation is necessary ...
<sb0>
the fundamental problem with those DDR3 designs is having good timing between the FPGA clock and the received data from the SDRAM. DQS is meant to help with that by having the SDRAM send a clock tightly timed to the data (because it's source synchronous, and because the DDR3 chips' DQS-to-data specs are tight). if all you're doing with that is register with DQS and re-register directly with the system clock, you're just moving the problem into the FP
<sb0>
GA, which is only marginally better...
<sb0>
it works by having those configurable delays, but 1) they are not voltage/temperature stable 2) the calibration process is a big mess
<sb0>
(re #1: mostly because the clock-to-DQS spec of the DDR3 chips is loose)
<sb0>
that temperature sensor thing of MIG looks disgusting
<sb0>
...things would have been MUCH simpler if xilinx provided some sort of FIFO you could clock DDR with DQS and read later with the system clock (assuming the latest possible arrival of DQS)
<sb0>
it's also kinda funny those xilinx designs run at a sluggish 1600Mbps/pin or so, and have this mountain of problems. GPUs are happy at 4500Mbps/pin with GDDR5 memory...
<sb0>
things would also been much simpler if dqs was free-running, btw
<_florent_>
I'd like to try the solution you described some time ago with IDDR2 and a soft FIFO using DQS to capture data, but didn't find time to implement it for now...
<sb0>
_florent_, btw, I think you should use BUFIO, not BUFG, for the high speed SERDES clocks