lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs :: Mixxeo preorder lists.milkymist.org/pipermail/devel-milkymist.org/2013-May/003344.html
wpwrak has quit [Read error: Connection reset by peer]
mumptai has quit [Quit: Verlassend]
antgreen has quit [Ping timeout: 256 seconds]
wpwrak has joined #milkymist
antgreen has joined #milkymist
<azonenberg> i've been using libftd2xx
<azonenberg> my library could be easily ported to use libftdi, in fact i was doing that in the past
<azonenberg> but bugs forced me t oleave
<Fallenou> milkymist-ng on nexys3: round #2!
<Fallenou> hi :)
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
lekernel has joined #milkymist
<Fallenou> hi!
<lekernel> hi
<Fallenou> lekernel: is it normal that libcompiler-rt folder only contains a Makefile?
<lekernel> yes, see the readme
<Fallenou> minisoc is complaining because it does not know how to make it
<Fallenou> oh god
<Fallenou> sorry about that
bhamilton has joined #milkymist
<Fallenou> lm32--netbsd-ld: bios.elf section `.rodata' will not fit in region `rom'
<Fallenou> lm32--netbsd-ld: region `rom' overflowed by 2452 bytes
<Fallenou> aouch
<Fallenou> I don't know if I can increase the rom size ... let's see
<lekernel> why is your compiler producing a larger binary than mine?
<lekernel> I have lm32-elf-gcc (GCC) 4.5.4
<lekernel> and the binary uses 14/16k
<Fallenou> hum let me try with another toolchain
<Fallenou> was using the netbsd one
<lekernel> otoh you may want to netboot netbsd, which could need a bigger bios
<Fallenou> yes :/
<Fallenou> with my rtems toolchain it's even worse, 2540 bytes of overflow
<lekernel> just increase the rom size - it should work
<Fallenou> let's put 32k
<Fallenou> ok, bios is fine now
<Fallenou> lekernel: awesome, it works
<Fallenou> I have the BIOS prompt using minisoc on the Nexys3
<lekernel> good :)
<Fallenou> I wonder what I did wrong on my side...
bhamilton has quit [Ping timeout: 256 seconds]
<lekernel> anyone going to http://lvee.org/ ?
bhamilton has joined #milkymist
lekernel has quit [Ping timeout: 256 seconds]
bhamilton has quit [Ping timeout: 252 seconds]
lekernel has joined #milkymist
_florent_ has joined #milkymist
<Fallenou> lekernel: my previous attempts (before you sent me minisoc) were failing because I was not setting a reset signal to the "cd_sys" clock domain, I was not using any SRLE16 primitive
<Fallenou> with the SRLE16 code snippet, it works now :)
<lekernel> yeah
<lekernel> would be interesting to rewrite LM32 with FHDL, that would solve little problems like resets and the slightly messy include file
<lekernel> the latter could become a real problem in a multicore system
<lekernel> also, when we have direct FHDL to netlist, we could synthesize MM SoC :)
azonenberg has quit [Read error: Operation timed out]
<Fallenou> that would be pretty cool :!)
<wpwrak> speaking of which, aren't there already open source tools that do a verilog to netlist conversion ?
<wpwrak> that way, you could take migen output, mix in the "native" blocks, and process that
<lekernel> no, there aren't
<lekernel> been thinking about your "mixed language" thing wpwrak and I start to like it...
<wpwrak> good :)
<wpwrak> look at all the different worlds, take the best from all of them
<lekernel> also, you can use that as an output language to check what metaprogramming did
<lekernel> ie output the same language but without any python bits
<wpwrak> yup, regression tests are important for this sort of project
<lekernel> can be a nicer debugging aid than opening the generated verilog
<lekernel> and death to verilog anyway :)
<wpwrak> well, you could still use the basic bits of verilog. they're not so bad
<lekernel> yeah, but kill the event-driven model
<wpwrak> expression syntax, most of the syntactical structure, e.g., all that's fairly clean and intuitive. they veer off into silliness with their macro capabilities, though
<lekernel> I'd say 90% of ASIC engineers don't understand it anyway, as illustrated by the prevalence of " <= #1 " assignments in synchronous blocks
<wpwrak> well, if that's what you really need ... :)
<lekernel> sometimes, there are still some silly and complicated to fix comb loops in the migen output as well
<wpwrak> so icarus doesn't always solve the halting problem. well, what's new ? :)
<larsc> well it's not the halting problem
<larsc> it's just a simple bug
<wpwrak> yeah. a very special case of not solving the halting problem :)
<lekernel> the funny thing is all simulators do a different thing
<wpwrak> but does icarus advance the time ? or does it stay at t = 0 ?
<larsc> it shouldn't
<larsc> should all be in the same delta cycle
<larsc> but on the other hand verilog doesn't know about delta cycles
<lekernel> it's the halting problem in general, yes. but remember you are designing synchronous hardware, so your comb loops are supposed to settle in a short time.
<lekernel> and the event driven model does not know anything about synchronous hardware, which is wrong
<wpwrak> so you basically want to reduce it to either "assign" or "always @(...edge ...)", no other forms of always
<larsc> even with the event driven model loops settle in short time, zero time to be exact.
<larsc> problem is when they don't settle, but they won't settle in hw either in that case
<lekernel> I mean time in delta-cycles
<lekernel> and yes
<lekernel> but for some verilog simulators, loops that settle in hw don't settle in simulation
<lekernel> including some big expensive simulators
<larsc> interresting
<wpwrak> can an always also execute then a signal it assigned to but doesn't change ?
<wpwrak> e.g., always @(x) y <= y+1
<wpwrak> and somewhere else x = 1; x = 1; x = 1;
<larsc> that's undefined
<wpwrak> if the answer is "yes", the endless loop would be more or less valid
<wpwrak> hah ! :)
<larsc> I think
<wpwrak> there we go
<larsc> you just shouldn't do this kind of thing
<wpwrak> of course, that makes @(*) rather dubious
<wpwrak> in a way, always @(*) makes assign somewhat redundant, doesn't it ?
<larsc> in what way?
<wpwrak> in the sense that assign could just be expressed as always @(*), couldn't it ?
Hawk777 has quit [Read error: Operation timed out]
Hawk777 has joined #milkymist
<larsc> kind of
<larsc> you can do more in a process though
<larsc> and an assign is more like aliasing the signal
<wpwrak> you mean you have more means to express your operation ? or do you mean you can do operations (without entering undefined territory) an assign can't do ?
<wpwrak> i could imagine an event counter, but then that's probably undefined (see the example above)
<larsc> you can for example use a case statement
<wpwrak> couldn't you express this in an "assign" as well ?
<larsc> yes
<larsc> but not as nicely
<wpwrak> i'm looking at it from a simplification point of view: if always @(*) can replace assign and is more comfortable, then you probably shouldn't have assign.
<larsc> well assign foo <= bar; is easier than always @(*) begin foo <= bar; end
<larsc> and there is a a subtile difference
<wpwrak> you could just group several assignments in one block, like migen does
<larsc> why would you?
<wpwrak> to avoid the extra construct. keep the language simple
<larsc> assign assigns a signal to a signal and <= assigns a value to a signal
<wpwrak> that's an implementation detail :)
<wpwrak> also blocking vs. non-blocking seems a bit unnatural
<wpwrak> if you assume that you have a synchronous design anyway, i don't think you need both
<larsc> yea, that's what they messed up in verilog
<larsc> they only had blocking in the beginning
<wpwrak> that's what i'd do, too
<larsc> no
<larsc> blocking is horrible
<wpwrak> i'd put my faith in data flow analysis
<wpwrak> that is, the semantics would be those of blocking. nice and easy. the implementation could be something very different.
<larsc> the problem with blocking is that is not deterministic
<lekernel> it is deterministic if the only thing you do with the value is read it in a non-blocking assignment somewhere down the same always block
<wpwrak> how about making blocks (semantically) atomic ?
<lekernel> how about not having blocks?
<wpwrak> how do have different clocks without blocks ?
<lekernel> the only reason you may want blocks is for variables/blocking assignments
<wpwrak> also migen has them. all sorts of sync plus one comb
<lekernel> and clocks ofc
<larsc> well, you want blocks to structure things
<wpwrak> well, perhaps one could do it like this: use blocks strictly for scoping and compound statements, like in c
<lekernel> no, python provides better ways to structure things
<larsc> but we are not talking about python now, are we?
<wpwrak> [...] ... naw, that thouht i was developing doesn't go anywhere nice
<wpwrak> lekernel: python still has blocks :)
<wpwrak> i'm not a great fan of python's indentation syntax. it looks nice enough in most cases, but it gets in the way when debugging code
bhamilton has joined #milkymist
bhamilton has quit [Quit: Leaving.]
kilae has joined #milkymist
bhamilton has joined #milkymist
playthatbeat has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]
playthatbeat has joined #milkymist
playthatbeat has quit [Client Quit]
playthatbeat has joined #milkymist
playthatbeat has quit [Client Quit]
playthatbeat has joined #milkymist
<Alarm__> wpwrak: I try to write a patch Flickernoise to drive a projector DMX address 1 with a midi console. It works with DMX table but not with the console: http://pastebin.com/WEx8x7C9
<Alarm__> wpwrak: why ?
<Alarm__> wpwrak: ?
<wpwrak> looks as if it should work. does anything happen instead ? error or such ? the controller numbers ( (1, 1), (1, 2), (1, 3) ) are correct ?
<wpwrak> i don't know about DMX, though. do if it's a problem on the DMX side, i wouldn't know what it means.
<Alarm__> wpwrak: f I put DMX2 = 1.0 then the red lights.
<Alarm__> wpwrak: if I put DMX2 = 1.0 then the red lights.
<wpwrak> maybe try avoid binding the control directly to an output variable. i.e., instead of dmx2 = range(fader1); do tmp = range(fader1); dmx2 = tmp
<wpwrak> as far a i remember both should work, but maybe there's an issue
<wpwrak> you could also test your fader selection. i.e., make sure you got the numbers right. if you got them wrong, simply nothing happens
azonenberg has joined #milkymist
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
<Alarm__> wpwrak: in last line, I put: DMX2 = tmp, I get the following error: "Value must be a near constant EOF"
<wpwrak> you need to set tmp first :)
<wpwrak> tmp = range(fader1); dmx2 = tmp
bhamilton has quit [Quit: Leaving.]
bhamilton has joined #milkymist
antgreen has quit [Quit: Leaving]
bhamilton has left #milkymist [#milkymist]
<Alarm__> wpwrak :with the line "DMX2 = tmp;" I get an error. If I remove it, I have no error
<wpwrak> lekernel: your 1 minute run was probably the equivalent of compiling 'int main(void) { return 0; }' ;-)
<lekernel> no, the output looked serious
<wpwrak> lekernel: did you have a partial/unsuccessful run before ? maybe they got better at incremental builds
<lekernel> no, I didn't
<wpwrak> ah, you're in the initialization. you need to add per_vertext: before the assignments
<wpwrak> that was for Alarm__
<wpwrak> lekernel: hmm, mysterious. unless they run time actually depends on how much of the fpga is not used, that doesn't quite make sense
<lekernel> dunno
<wpwrak> Alarm__: well, before the assignments to tmp and to dmx2
<lekernel> well for now I'll have more than enough trouble getting the s6 mixxeo out
<lekernel> vivado etc. I will look later
<wpwrak> Alarm__: err, the one to dmx2 only. the other one is good.
azonenberg has quit [Read error: Connection reset by peer]
jevin has quit [Quit: Textual IRC Client: www.textualapp.com]
jevin has joined #milkymist
azonenberg has joined #milkymist
<Fallenou> 19:12 < wpwrak> ah, you're in the initialization. you need to add per_vertext: before the assignments < or per_frame: ?
<wpwrak> argh. yes, per_frame
<wpwrak> that stuff is totally swapped out
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
mumptai has joined #milkymist
<_florent_> hi
<_florent_> I'm trying to adapt the DDR controller to Kintex7 on the KC705.
<_florent_> I'm only doing an adaptation of the milkymist-ng S6ddrphy to use the Kintex7 blocks (oserdese2, iserdeses2, ...)
<_florent_> read & write leveling is not implemented for now, but it should work without at low frequency (200 MHz ie DDR400).
<_florent_> for now I'm able to initialize the DDR in simulation and commands are sent correctly to the memory.
<_florent_> I have a little question on one point, my configuration is:
<_florent_> Burst Length = 8
<_florent_> Nb Phases = 2 (still half rate controller)
<_florent_> DFI data width = 128 (64 bits DDR3)
<_florent_> ie to generate a complete DDR burst, I have to assert dfi_wrdata_en for 2 consecutive cycles (256 bits per cycle).
<_florent_> I have done some adaptation on the asmicon to use correct values for burst length and asmiport data width (512)
<_florent_> but it seems the asmicon is still asserting dfi_wedata_en for only 1 cycle.
<_florent_> I haven't look at the asmicon code yet on this point
<_florent_> lekernel : do you remember if this behaviour is implemented?
<_florent_> It seems it's not implemented in the code, I'll try to add it
sb0 has joined #milkymist
<sb0> _florent_, ASMI doesn't support bursts. use BL=4 instead.
<sb0> ah but that's not possible with ddr3.. hmm
<_florent_> I'm looking at the multiplexer
<_florent_> it seems possible to add support for that here
<sb0> I guess that with the clock frequencies of DDR3 compared to the slowness of FPGAs, you need a 1/4 rate controller eventually
<_florent_> I'll try to do it
<_florent_> for now it's really a simple port of your phy
<_florent_> It won't probably work with frequency > 200 MHz since write and read leveling won't be implemented
<sb0> yeh, you can try hacking something together first... but I don't think it makes much sense to support bursts permanently in ASMI
<sb0> you'd be better off with DDR2 in this case, which has lower CAS latency
<_florent_> probably but I'm not able to change the ddr on the board
<_florent_> :(
<sb0> how about doing it right, with 1:4 (cmd) / 1:8 (data) serialization, and read/write leveling?
Alarm__ has quit [Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949]]
<sb0> note that read leveling is just using DQS ...
<sb0> and if you have only one chip, or individual chips, you don't need WL
<_florent_> it seems ddr3 has a burst chop mode
<_florent_> a kind of BL4 support
<sb0> it won't help
<sb0> the peak data rate is the same
<sb0> all it does is use the first 4 bit times only
<_florent_> ok but at least it will be functionnal but I agree very slow...
<sb0> you have the exact same IO timing constraints in BL8 and burst chop 4
<sb0> so just use BL8 in this case ;) you've done the hard part, don't waste half the bandwidth for nothing
<sb0> the only advantage of chopped burst is reduced delays for some read-to-write, write-to-read and write-to-precharge transitions
<sb0> it's very minor and I think a good strategy is just to ignore it, DDR3 is messy enough like that
<_florent_> ok and do you know if in burst chop mode, you have to generate dqs for the last 4 burst?
<sb0> I don't think so, since burst chop reduces the bus turnaround timing spec. that's incompatible with the transmitting end still driving DQS.
<sb0> but check the datasheet
<_florent_> ok but anyway, it will probably be easier to hack the controller
<sb0> is it a DIMM with that horrid flyby routing topology?
<sb0> or just one chip?
<_florent_> a dimm
<_florent_> with 8 chips
<sb0> and you need all of them?
<_florent_> maybe not
<sb0> well, on the other hand, xilinx claims they have fixed the supershitty IODELAY in 7 series
<sb0> if that claim is true, implementing write leveling might not be too hard
<_florent_> but it will be very slow with only a 8 bit DDR...
<sb0> especially since you can do it from LM32, with nice debug output
<_florent_> one thing that is very frustrating is that the equivalent of oserdes2 and iserdes2 (oserdese2 and iserdese2) are now secure ip
<_florent_> so it's not possible to simulate with icarus
<sb0> it is. modelsim passes the cleartext to memcpy() when you load secureip.
<_florent_> ah interesting
_florent_ has quit [Quit: Page closed]
sb0 has quit [Quit: Leaving]
lekernel has quit [Quit: Leaving]
mumptai has quit [Quit: Verlassend]