<sb0>
i've been wondering how intel & co managed to get ddr3 to work reliably with so many configurations. obviously the answer is: they don't.
<sb0>
I'm not sure of the DRAM or the controller is responsible for those bugs...
<whitequark>
i would think DRAM?
<whitequark>
i mean, otherwise how would it be bank-dependent
<felix_>
thats a problem with the dram, not with the memory controller
<felix_>
those memory controllers only work reliable, since they do quite a bit of link training
<sb0>
DDR3 has a "rolling time window in which you can send at most 4 activates" (or things break due to on-chip power distribution issues in the DRAM)
<sb0>
the controller is responsible for respecting this specification
<cr1901_modern>
Can the DRAM itself signal back "time's up, don't send more activates"?
<sb0>
"link training" is independent from that
<sb0>
no, it doesn't
<sb0>
DRAMs are dumb device, the controller must do most of the work
<sb0>
also, reading a "activate ok" feedback signal from the DRAM would significantly increase latency, given the speed at which those things operate
<whitequark>
would it really? the actual DRAM is something like 133MHz
<whitequark>
hm, right, that actually makes it worse
<sb0>
the command bus operates at half the data rate. so still quite fast...
<sb0>
the actual DRAM is asynchronous
<cr1901_modern>
ahhh
<cr1901_modern>
I thought it would be as simple as adding "a counter that starts counting on receipt of first activate", but if it's async
<felix_>
yeah, those memeory controllers in recent cpus have to pay attention to a lot of stuff. but sadly most vendors have become quite secretive about how their memory controller work exactly
<sb0>
same for CPU cores and everything else
<cr1901_modern>
The overwhelming complexity seems to be the cost of getting good performance. It's like 100's the complexity for 2's the speedup
<sb0>
a OOO x86 core is certainly an even bigger mess than a DDR3 controller
<sb0>
then add a few other pieces of overengineered crap on the same chip, like USB3, PCIe, ...
<cr1901_modern>
I miss serial and parallel ports
<cr1901_modern>
At least it doesn't require me to read a 700-page specification to use them.
<cr1901_modern>
or create hardware that interfaces to them.
<cr1901_modern>
The other problem with USB I can think of, is that the USB consortium has explicitly said they won't support hobbyists looking to make low-run products.
<sb0>
really? hobby/maker stuff is the cool thing with intel right now
<sb0>
bah, that's a small problem. i don't think you can get prosecuted for squatting a VID...
<cr1901_modern>
Btw, the hobbyist vendor ID is 6666. It's an "open secret".
<cr1901_modern>
sb0: Maybe not where you live. But I suspect if I tried to pull something like that, I would be up to my eyeballs in legal fees before I could even get the first prototypes out the door XD
<sb0>
the only thing they can assert against you is trademark infrigement. just don't put the USB logo on your device
<whitequark>
plenty of companies will give you a PID
<cr1901_modern>
I guess they expand their list as needed then/don't show the free PIDs
<cr1901_modern>
I interpreted the list last I checked as: "Oh, everyone reserved a PID on the chart, no more PIDs :("
<cr1901_modern>
Anyways it doesn't matter. I was wrong- the situation isn't as bad as I thought
<cr1901_modern>
sb0: The IPC code is fully complete for Windows. All the simulations in the examples directory run properly. Each packet sends its length ahead of time to fake SOCK_SEQPACKET.
early has quit [Ping timeout: 248 seconds]
<cr1901_modern>
And on that note- bedtime for now
<cr1901_modern>
5:30 AM is a good time for bed
<sb0>
cr1901_modern, can you use the same coding style as elsewhere in migen? (and pep8 when it applies)
<cr1901_modern>
Do you mean solely in the Python code or the C code as well?
<GitHub76>
[pyparser] whitequark pushed 1 new commit to master: http://git.io/vJXRf
<whitequark>
sb0: is there really no pep8 reformatter?
<cr1901_modern>
Oh, there is. Just LOL Windows
<cr1901_modern>
You install the PEP checker using pip, but pip is notoriously difficult to install on Windows
<whitequark>
use a VM
<cr1901_modern>
Better yet, I should really just say screw Windows...
<sb0>
cr1901_modern, also, double quotes for strings, and spaces after #
<sb0>
and c code as well
<cr1901_modern>
C code used tabs, so I used tabs as well
<cr1901_modern>
single line for braces for functions, and on the same line as if-statements/for loops, etc. Single line if statements don't have braces
<cr1901_modern>
Do you not want me to indent conditional compilation blocks?
<whitequark>
sb0: how about just taking clang-format to the C code...
<cr1901_modern>
Fixing pointers now
<cr1901_modern>
whitequark: There's a online checker as well, I just found: http://pep8online.com
early has joined #m-labs
<whitequark>
gross
<whitequark>
a proper tool would just fix everything it doesn't like
<whitequark>
in your filesystem
<cr1901_modern>
Where's the fun in that?
<cr1901_modern>
Don't you LIKE correcting your changes incrementally and wasting time?
early has quit [Ping timeout: 248 seconds]
<cr1901_modern>
sb0: Okay, I think it should be good now. Should I rebase and send a new patch? Possibly just send a git diff as a response to my previous email?
early has joined #m-labs
fengling has quit [Quit: WeeChat 1.1.1]
<sb0>
cr1901_modern, either is fine.
early has quit [Ping timeout: 248 seconds]
early has joined #m-labs
<sb0>
rjo, are you back?
* ysionneau
is back!
<ysionneau>
hi
<ysionneau>
going through my emails, I see there are issues with flash_storage, let's try to fix that today
<sb0>
hi ysionneau
early has quit [Ping timeout: 248 seconds]
early has joined #m-labs
<cr1901_modern>
So much for sleep
<GitHub1>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vJ1fe
nengel has quit [Remote host closed the connection]
nengel has joined #m-labs
nicksydney has quit [Remote host closed the connection]
early has quit [Ping timeout: 240 seconds]
early has joined #m-labs
<mindrunner>
what is the realtion between hwflags (hw/flags.h) and Eventmanager/EventSourcePulse? Where do I define those numbers in my own Interrupts?
<sb0>
mindrunner, there isn't an automatic generation of those flags yet. i think there should be one, but I haven't found time for that yet...
<mindrunner>
ok, what do i have to do then? for example in UART code, there are two events (RX and TX). One is 0x1 and ther other one is 0x2. Where in the Misoc code is that defined. I cant find it in UART.py. The triggered events for either of tose look the same
<sb0>
0x1 is the first event registered, then 0x2, 0x4, 0x8 etc.
<mindrunner>
ah ok. so if my module only has one event, it is 0x1
early has quit [Ping timeout: 248 seconds]
early has joined #m-labs
imrehg has joined #m-labs
imrehg has quit [Quit: Leaving]
<GitHub163>
[misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/vJDUJ
<GitHub163>
misoc/master 5d5d5ed Sebastien Bourdeauducq: spiflash: fix miso bitbang with large DQ
early has quit [Ping timeout: 245 seconds]
early has joined #m-labs
bentley` has quit [Ping timeout: 250 seconds]
mumptai has quit [Quit: Verlassend]
<rjo>
sb0: yes. more or less.
<GitHub76>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vJ9BJ
<GitHub76>
misoc/master 7bdcbc9 Florent Kermarrec: litesata: use (some) settings from vivado 2015.1, try to follow all ug476 recommendations to initialize GTX (...), remove automatic reset on top....