Martoni has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121129170341]]
lekernel has joined #milkymist
Martoni has joined #milkymist
Martoni has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121129170341]]
Martoni has joined #milkymist
Martoni has quit [Client Quit]
Martoni has joined #milkymist
mumptai has joined #milkymist
<lekernel>
wpwrak, I have forwarded your email to Adrien
<lekernel>
re. wire characterization
<lekernel>
mwalle, yup
<lekernel>
you should have come to the conference mwalle :)
<wpwrak>
lekernel: ah, thanks !
<Fallenou>
lekernel: ahah nice link, I never go to Quick btw :p
<Fallenou>
even during the star wars burgers sales ... :p
mumptai has quit [Ping timeout: 255 seconds]
<wpwrak>
Fallenou: they're very efficient in the future. crash a spacecraft ... don't bemoan the dead, have a burgers sale ! kinda like the happy face of soylent green :)
<Fallenou>
wwwwhat ?!
<Fallenou>
please send me samples of what you take :p
<atgreen>
lekernel: watching your migen talk right now - thanks for posting
<wpwrak>
Fallenou: just exploiting the creative phase between waking up and the first dose of caffeine :)
<Fallenou>
wow
xiangfu has quit [Quit: leaving]
xiangfu has joined #milkymist
<kyak>
lekernel: just watched your video for Migen, very impressive. Since you mentioned dataflow programming, have you seen HDL Coder? (http://www.mathworks.com/products/hdl-coder/)
<wpwrak>
frequency 6000000 -> new real frequency 46570.9, delay 0 operating without delay :)
<kyak>
it has nothing to do with FOSS, of course, but it's a yet another approach from higher level languages to hardware design
<wpwrak>
oops. wrong channel
<kyak>
wpwrak: chaos and confusion!
<wpwrak>
kyak: now you're getting into the spirit :)
<kyak>
we should team up :)
<wpwrak>
yeah. you take the northern hemisphere, i take the south :)
<kristianpaul>
wpwrak: where is your turbo button? :-)
<wpwrak>
kristianpaul: you mean for "world domination, FAST" ?
<lekernel>
kyak, yeah, and we should replace that
<lekernel>
s/matlab/scipy
<lekernel>
s/hdlcoder/migen
<kyak>
lekernel: what are your thoughts about replacing Simulink?
<kyak>
i mean, even System Generator from Xilinx uses it as a base
<lekernel>
same. everything mathworks should die and be replaced with python and migen.
<lekernel>
the problem with replacing simulink is all open source UI toolkits are massive piles of turd
<kyak>
that's pretty ambitious
<lekernel>
maybe e17 libraries are better, still need to look at them
<kyak>
simulink is not just an MATLAB ui
<kyak>
it's much more
<lekernel>
I know, but the annoying part will be the UI
<lekernel>
that's what people want, too
<kyak>
that's correct
<kyak>
just wondering why did you even mention LabView?
<kyak>
if everything mathworks should die, everything ni should die, too?
<lekernel>
maybe :) I'm actually less familiar with LabView
<lekernel>
but it just the first example that come to my mind when writing that slide :)
<kyak>
well, anyway, it's awesome. I know the amount of work MathWorks put into their HDL Coder, so it's amazing what you did (all alone or with just few people)
<lekernel>
well, I think Pytholite still lacks many features that HDL Coder has
<lekernel>
but someday we'll get there, hopefully
florent_ has joined #milkymist
<kristianpaul>
wpwrak: yeap ;)
<florent_>
Hi everyone
<florent_>
I'm playing a bit with the Milkymist stuff and especially Migen ans wanted to discuss with you
<florent_>
*and
<florent_>
we already echanged a little on the dev-list about embedded blocks or milkymist-migen-port
<florent_>
but unfortunately I didn't had time at the end of the year to continue working on that
<florent_>
time I have now ;)
<lekernel>
hi florent_
<florent_>
hi!
<florent_>
I have some technical question
<florent_>
but before I just want to give you a little feedback of Migen
<florent_>
I've tried Migen on a to code a small logic analyzer, it was difficult to start using it but after it was very frustrating to get back to vhdl
<florent_>
I'm planning to use it on some projects but I don't think my customers are ready to switch to it;;;
<florent_>
...
<florent_>
To learn and also to try to convince my customers I've planned some project using it
<florent_>
maybe someone here will be interested?
<florent_>
-The first one is a small port of Milkymist-ng to a De0Nano using Lm32/Asmicon/Uart/Gpios/etc...
<florent_>
-The second one is a port of Milkymist-ng to a KC705
<florent_>
for the first project I want to use Asmicon
<florent_>
I've started to implement if
<florent_>
*it
<florent_>
but the Sdram on the De0Nano is only 16 bits wide
<florent_>
and Asmicon is doing some assertions with the d_with
<florent_>
the first one is in the multiplexer
<florent_>
and the others one is in Wishbone2Asmi
<florent_>
Have you more informations about the width limitations in the Asmicon?
<florent_>
I understand the d_width limitation on the wishbone2Asmi module but not the limitation in the controller
<lekernel>
it's not d_width, it's the frequency ratio between SoC and DRAM
<florent_>
Ah ok
mumptai has joined #milkymist
<florent_>
It's was another limitation
<florent_>
in fact I'm using a Sdram, so I have only 1 phase
<lekernel>
what's the SDRAM? PC133?
<florent_>
do you think I will have so trouble with the multiplexer in this configuration?
<lekernel>
well you can run SDRAM at 133MHz and SoC at 67... then you have 2 phases
<florent_>
If I remove the assertion
<lekernel>
but if everything can meet timing at 133MHz or maybe even 100MHz it could be better
<lekernel>
with 1 phase
<lekernel>
well you have to add 1-phase support to the multiplexer :) I have not coded it
<florent_>
Ok, no problem, that just what I wanted to know about that
<lekernel>
what's the maximum frequency of your SDRAM part?
<lekernel>
if you run a 1:2 frequency ratio system then you have 32-bit data
<lekernel>
would help with wishbone
<lekernel>
there are some SDRAM parts that can do 166MHz
<florent_>
Let me check the DDR on the De0Nano
<lekernel>
it's not DDR
<florent_>
yes sorry
<florent_>
the max frequency is 143MHz
<lekernel>
ok. and what's the maximum frequency of lm32 in that fpga?
<florent_>
more than 100Mhz iirc
<lekernel>
ah. so I guess you don't want to limit it to 143/2=71.5MHz ...
<florent_>
In fact it's not so important
<florent_>
I'm making the De0Nano to:
<lekernel>
you can run with 1 phase and BL=1 (ie no bursting)
<florent_>
- learn more about Migen and the Asmicon
<lekernel>
and 16-bit data (then you need to adapt the wishbone)
<florent_>
- to prepare the KC705 port
<lekernel>
ASMI is really designed for new SDRAM :)
<florent_>
I think I will run at 1:2 frequency for a first attempt
<lekernel>
hmm, pick your poison
<lekernel>
if you use a frequency ratio system, you need to mess with the DDR registers
<lekernel>
if you don't, you can use simple I/O flip-flops, and you need to adapt multiplexer and wishbone bridge
<florent_>
I will have to check witch adaptation is the easier ;)
<lekernel>
it's also hard to tell which one would make the faster system
<florent_>
In fact I don't care about perfomance on the De0Nano
<lekernel>
modern DRAMs happily run at 800+MHz, so they're rarely the limiting factor with those frustratingly slow FPGAs
<florent_>
it's only that I don't work to start using ASMICON with the kintex7...
<florent_>
*want
<lekernel>
ah, I have some ideas for the kintex7 :)
<florent_>
ah?
<lekernel>
yeah
<lekernel>
you need to use DQS
<lekernel>
for reading
<lekernel>
the current trick with ISERDES won't work, DDR3 timing figures are just too tight
<florent_>
that's why they introduced IN_FIFO and OUT_FIFO I think
<lekernel>
so we won't use the ISERDES - just IDDR2
<lekernel>
put the data into a FIFO
<lekernel>
(a soft FIFO)
<florent_>
In a first time I was planning to use the Xilinx Phy on the KC705
<lekernel>
and read the data assuming the worst case (late) DQS arrival
<florent_>
since it's a SODIMM , I have to do read and write leveling
<lekernel>
now there's a catch - as you know DQS stops when there is no more data to transfer, so there will be some data stuck in the registers
<lekernel>
the idea is to make the controller insert a dummy data read (just repeat the last read command, which will always be a page hit) to make the DDR3 wiggle its DQS pins
<lekernel>
every time there is a "bubble" in the flow of read requests
<lekernel>
I would advise against using IN_FIFO and OUT_FIFO, they're very badly documented
<lekernel>
and quite a big mess...
<lekernel>
I think the "dummy read" solution + IDDR + soft FIFO is simpler and more elegant
<florent_>
I totally agree with you but using the Xilinx phy can be a first step
<florent_>
ASMICON+ Xilinx Phy
<lekernel>
I think you'll spend more time debugging it than implementing the soft-FIFO solution :)
<florent_>
and after ASMICON + custom phy
<lekernel>
oh and btw - some PHYs have unpredictable read latency
<florent_>
and I'm used to the Xilinx Phy
<lekernel>
which adds to the mess of DRAM scheduling, and the ASMICON design doesn't support it
<florent_>
hmm yes
<lekernel>
my solution has a fixed read latency
<florent_>
that's was another question I have about ASMICON
<florent_>
I see read_time and write_time parameters, does the ASMICON needs to be aware of phy latency?
<lekernel>
yes, of course
<florent_>
Ok so I first have to check if Xilinx Phy latency is predictable...
<lekernel>
do you have a URL to that Xilinx PHY? last time I checked they didn't publish it
<lekernel>
is it that horrendous design generated by a horrible java application?
<florent_>
yes it's the MIG
<lekernel>
last time I ran it you couldn't generate the PHY aline
<lekernel>
alone
<lekernel>
you had to extract it from the generated VHDL mess
<florent_>
In fact the MIG is a full controller : controller + phy
<lekernel>
yes
<florent_>
I've worked on a project with a custom controller + only the xilinx phy
<florent_>
There was enough documentation for that
<florent_>
only lots of parameters to support!
<florent_>
The phy use IN_FIFO/OUT_FIFO/PHY_CONTROL hard blocks
<lekernel>
yeah I had a look at that source
<lekernel>
for kintex 7 and ddr3
<lekernel>
and I don't like it
<florent_>
But those are not documented or supported
atgreen_ has joined #milkymist
<florent_>
And the Phy used lots of resources
<lekernel>
even with the hard blocks? hm
<lekernel>
yeah I remember there was some large FSMs in there
<lekernel>
haven't tried synthesizing it...
atgreen has quit [Ping timeout: 276 seconds]
<lekernel>
IDDR + soft-FIFO scores one more point I guess
<florent_>
In fact the Phy does everythin : DDR configuration / and Read/Write Leveling
<florent_>
Read and write leveling take at least 1000 Luts each
<lekernel>
read leveling is solved in a more simple way by using DQS as clock and assuming the worst case DQS arrival for data recapture using the system clock
<florent_>
With support read and write leveling on milkymist it's maybe better to implement a software solution
<lekernel>
write leveling can be solved by having independent DDR3 chips instead of a DIMM
<florent_>
Ah ok, i didn't understand that
<lekernel>
if you only use one DDR3 chip on the DIMM you can skip write leveling
<lekernel>
or rather implement a much simpler version of it
<lekernel>
also this sort of things should be done by some BIOS running on a softcore CPU, not a FSM anyway
<florent_>
I've read some time ago that you were planning a M^3
<florent_>
is it still planned?
<lekernel>
yeah, but I need a clearer marketing case for it
<florent_>
Ah Ok
<florent_>
And wouldn't it be more easier to have a board with all the FPGA/DDR/Flash and another mezzanine with the functionnalites?
<lekernel>
I'll start with a simpler M1-based video mixer, too
<florent_>
because I would be interested by a such board!
<lekernel>
I don't know. if you want to ship end user products eventually, this adds to the complexity of the assembly process and the mechanical design.
<lekernel>
also M3 would have high speed signals like HDMI, Displayport or Thunderbolt *g*
<florent_>
yes of course but you can attract all the arduino community with such a board
<lekernel>
and I can tell you they're trying hard...
<florent_>
yes but the problem it's very difficult to learn fpga
<lekernel>
and it's expensive blah blah blah
<lekernel>
bottom line: you can't :)
<florent_>
don't know... maybe migen can help
<lekernel>
I think Arduino fans are simply the wrong target
<lekernel>
besides, I love technology, and making simple boards bores me.
<florent_>
yes I can understand
<florent_>
I have to go
<florent_>
thanks for the discussion and advices
<lekernel>
bye, thanks for coming bye!
<lekernel>
keep us posted about your DRAM adventures
<lekernel>
and good luck!
<florent_>
of course, I hope I won't have to ask you too much boring questions ;)
<florent_>
bye
<lekernel>
questions about DRAM are rarely boring
<lekernel>
and we need good ASMI documentation/knowledge base anyway
<lekernel>
so please ask them on a logged channel or list
<florent_>
ok I'll do that
lekernel has left #milkymist ["Leaving"]
lekernel has joined #milkymist
mumptai has quit [Ping timeout: 272 seconds]
Martoni has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121129170341]]
jimmythehorn has joined #milkymist
florent_ has quit [Quit: Page closed]
atgreen_ has quit [Ping timeout: 272 seconds]
atgreen_ has joined #milkymist
kilae has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]]
atgreen_ has quit [Ping timeout: 260 seconds]
green_ has joined #milkymist
<Fallenou>
lekernel: for the workshop, networkx v1.1 is up to date enough ? (package from debian squeeze)
<lekernel>
I think so
<lekernel>
but I don't really know. try running mm soc build.py and see if it screams
<Fallenou>
build.py says "ImportError: No module named netowrkx"
<Fallenou>
oh ok I have the networkx module for python 2.6 not for python3
Alarm has joined #milkymist
<Fallenou>
I used easy_install3 to install networkx 1.7 (as a .egg file) it ave me a bunch of syntax error but now I can import networkx in python3
<Fallenou>
weird that the install throws so much errors
<Fallenou>
ok good make all works fine
<Fallenou>
mwalle: are you here ?
<Fallenou>
I clonsed your github milkymist repository, checked out the "mmu" branch, then I went to cores/lm32/test and did "make" and then vvp tb_lm32 +prog=qemu_testcases/test_mmu.vh
<Fallenou>
it does not seem to ever $finish
<Fallenou>
am I doing it wrong ?
kyak has quit []
<Fallenou>
it seems pmem_adr takes values 0, 0001, 0002, 0003 and then 0000 and it stays 0000