<sb0>
what's the expected contents of a ddr3 memory after a reset? micron datasheet says it's undefined, a freescale pdf says reset is destructive to the memory contents - is it typically 0?
<sb0>
yes
<sb0>
you need to toggle DQS once before the actual write, and once after. I guess toggling 4x before and after shouldn't hurt, since the dram isn't driving those pins and should ignore it outside of the window of the write command(s)
<_florent_>
I think it's undefined, at least micron model return undefined values after reset
<_florent_>
ok I understand so last_wrdata_en[1] is the center of the window where data are really outputed
<sb0>
right now I'm reading solid zeros on the board (I used to read some random 1s when lasmicon kept reset asserted), but it's hard to tell if I'm reading zeros from the memory array (and writes don't work at all) or if I'm not reading at all
<_florent_>
hmm ok, but I'm seeing others issues on simulation that I'm trying to fix
<_florent_>
for example oe is in fact too early
<sb0>
_florent_, ([1] at center) yes. you should check the DQS pattern though, it's hard to tell if it's correct especially with the xilinx doc and this imbecilic secureip model
<_florent_>
and I have to increase write_latency to 2 to really have CWL of 6, with write_latency of 1 we have CWL of 2
<sb0>
yes, oe should be too early by 3 SDRAM cycle, but that should not hurt
<_florent_>
currently oe seems to early by 11 SDRAM cycles
<_florent_>
but I'm going to fix that
<sb0>
don't the serdes have 2 system clock cycles of latency?
<sb0>
that they also apply to oe?
sh[4]rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 260 seconds]
<_florent_>
on my simulation, between oe and dqs pin toggling I have 1 ddr clock cycle
<sb0>
ah. well, that could explain why things don't work then :)
<sb0>
I was assuming the same latency for OE through the SERDES as for data
<_florent_>
yes it's not worth spending time doing hardware test for now
xiangfu has quit [Ping timeout: 272 seconds]
xiangfu has joined #m-labs
xiangfu has quit [Remote host closed the connection]
MY123 has joined #m-labs
<ysionneau>
funny you can buy "verified for one bitstream" Kintex 7 or Virtex 7 FPGA which cost smth like 35% less
<ysionneau>
I guess they take faulty chips which have small defects and try to sell them anyway depending on what FPGA resource you use in your bitstream
<ysionneau>
I like the "EasyPath-7 devices are FPGAs that have b
<ysionneau>
een custom tested fo
<ysionneau>
r a specific customer
<ysionneau>
application"
<larsc>
yea...
<ysionneau>
which means "the device is production garbage which is faulty, but some part still works so you can buy it cheaper"
<larsc>
you have to run a tool that basically does a memtest
<larsc>
you send the result of that to xilinx
<ysionneau>
you have used such chips?
<larsc>
they send you a file back
<larsc>
you use that file when you generate your bitstream
<larsc>
and the bistream will only work with that one fpga
<larsc>
that's ultrascale though
<ysionneau>
I think ultrascale is != than EasyPath
<larsc>
and as far as I understand it for all ultrascale devices
<MY123>
It is a bad idea like A-class SD cards.
<larsc>
its good if it increases yield
<larsc>
but bad if you can no longer redistribute bitstreams
<MY123>
I think that there is no FPGA with an open-source synthetiser yet.
<MY123>
Complete for ASICs but bad for FPGAs (no format docs) .
<MY123>
*
<ysionneau>
ah?
<ysionneau>
I thought it was functional for FPGA as well
<ysionneau>
like you synthetize, you generate some file, you put that file as input of the proprietary PAR tool and it works
<larsc>
yea, it works
<MY123>
Did not get it to work, where is the PAR tool !
<MY123>
*?
<larsc>
although it is not on par (excuse the pun) with the vendor synthetizers
<ysionneau>
there is no PAR tool in yosys
<ysionneau>
yosys does only synthesis
<ysionneau>
PAR tool is provided by FPGA vendor
<ysionneau>
in ISE or Quartus or whatever
<ysionneau>
larsc: nice one =)
<MY123>
Did not find the Xilinx PAR tool for ARM Linux.
<ysionneau>
ARM Linux ?
<MY123>
(may be nowhere )
<ysionneau>
they provide x86_64 and i386 I think and that's it
<ysionneau>
why would you want to use an ARM "workstation" to do FPGA work?
<ysionneau>
(and they provide linux and windows)
<MY123>
ysionneau: I'm nearly always out of the house, and can't carry a workstation. ( does not have a laptop)
<ysionneau>
to do FPGA work I think you should buy a small x86_64 laptop
<ysionneau>
I think sb0 has a small laptop he carries with him maybe you can ask him which one it is
<ysionneau>
or you can use your ARM stuff but you will just do simulation (iverilog+Migen)
<MY123>
For a laptop, buying a x86 one without paying the Windows license is a challenge ...
<ysionneau>
or .... you can run an x86 virtualmachine (qemu) in your ARM laptop to run ISE, but I guess it will be veeeeeeeeeery slow
<ysionneau>
humm in some countries now you can buy with the windows license and then ask for a refund
<ysionneau>
or you can buy online maybe from dell or something
<MY123>
ysionneau: In France, it is to the court (bad choice). Tried qemu but takes a few hours to start ISE. Dell needs buying more than two machines.
<sb0>
MY123, if you want to go the fpga bitstream reverse engineering route, Wolfgang started this https://github.com/Wolfgang-Spraul/fpgatools but unfortunately stopped abruptly shortly after
<MY123>
sb0: Mosis is a good solution but does not like to buy 500 ASICs until I get it working.
<sb0>
hmm last time I checked you could buy 10 on mosis
<MY123>
sb0: I'm talking about buying an ASIC which finally has a design fault.
<sb0>
no pain, no gain
<MY123>
Why Milkymist was not ASICed ?
<larsc>
MY123: are you going to pay for it?
FabM has quit [Read error: Connection reset by peer]
<larsc>
why have I not seen this before foo[x+:y] is equivalent to foo[x+y-1:y]
<GitHub51>
[misoc] sbourdeauducq pushed 4 new commits to master: http://git.io/AqMmCQ
<GitHub51>
misoc/master bb85f29 Florent Kermarrec: k7ddrphy: fix write_latency and take care of OSERDESE2 latency on oe
<GitHub51>
misoc/master acbba37 Florent Kermarrec: k7ddrphy: set bitslip to 0 on ISERDESE2 (needed at least for sim)
<GitHub51>
misoc/master 2e4bfe1 Florent Kermarrec: k7ddrphy: add ODELAYE2 on dm path to match dq path (ODELAYE2 even configure with a delay of 0 generates a delay)
fengling has quit [Ping timeout: 264 seconds]
<sb0>
MY123, it was already too low volume for fpga
<sb0>
grmbl opencores still ask you to login to download stuff