#milkymist IRC log for Monday, 2013-05-20

azonenbergi've been using libftd2xx07:59
azonenbergmy library could be easily ported to use libftdi, in fact i was doing that in the past07:59
azonenbergbut bugs forced me t oleave07:59
Fallenoumilkymist-ng on nexys3: round #2!08:13
Fallenouhi :)08:13
Fallenoulekernel: is it normal that libcompiler-rt folder only contains a Makefile?08:29
lekernelyes, see the readme08:29
Fallenouminisoc is complaining because it does not know how to make it08:29
Fallenouoh god08:29
Fallenousorry about that08:30
Fallenoulm32--netbsd-ld: bios.elf section `.rodata' will not fit in region `rom'08:46
Fallenoulm32--netbsd-ld: region `rom' overflowed by 2452 bytes08:46
FallenouI don't know if I can increase the rom size ... let's see08:47
lekernelwhy is your compiler producing a larger binary than mine?08:50
lekernelI have lm32-elf-gcc (GCC) 4.5.408:50
lekerneland the binary uses 14/16k08:51
Fallenouhum let me try with another toolchain08:51
Fallenouwas using the netbsd one08:51
lekernelotoh you may want to netboot netbsd, which could need a bigger bios08:52
Fallenouyes :/08:52
Fallenouwith my rtems toolchain it's even worse, 2540 bytes of overflow08:53
lekerneljust increase the rom size - it should work08:53
Fallenoulet's put 32k08:53
Fallenouok, bios is fine now08:56
Fallenoulekernel: awesome, it works08:58
FallenouI have the BIOS prompt using minisoc on the Nexys308:58
lekernelgood :)08:58
FallenouI wonder what I did wrong on my side...08:58
lekernelanyone going to http://lvee.org/ ?09:26
lekerneland http://conference.vde.com/emlc2013/Pages/EMLC2013.aspx just before09:27
Fallenoulekernel: 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 primitive10:08
Fallenouwith the SRLE16 code snippet, it works now :)10:08
lekernelwould be interesting to rewrite LM32 with FHDL, that would solve little problems like resets and the slightly messy include file10:19
lekernelthe latter could become a real problem in a multicore system10:20
lekernelalso, when we have direct FHDL to netlist, we could synthesize MM SoC :)10:20
Fallenouthat would be pretty cool :!)10:29
wpwrakspeaking of which, aren't there already open source tools that do a verilog to netlist conversion ?10:30
wpwrakthat way, you could take migen output, mix in the "native" blocks, and process that10:31
lekernelno, there aren't10:31
lekernelbeen thinking about your "mixed language" thing wpwrak and I start to like it...10:43
wpwrakgood :)10:44
wpwraklook at all the different worlds, take the best from all of them10:44
lekernelalso, you can use that as an output language to check what metaprogramming did10:44
lekernelie output the same language but without any python bits10:45
wpwrakyup, regression tests are important for this sort of project10:45
lekernelcan be a nicer debugging aid than opening the generated verilog10:45
lekerneland death to verilog anyway :)10:46
wpwrakwell, you could still use the basic bits of verilog. they're not so bad10:47
lekernelyeah, but kill the event-driven model10:48
wpwrakexpression syntax, most of the syntactical structure, e.g., all that's fairly clean and intuitive. they veer off into silliness with their macro capabilities, though10:48
lekernelI'd say 90% of ASIC engineers don't understand it anyway, as illustrated by the prevalence of " <= #1 " assignments in synchronous blocks10:49
wpwrakwell, if that's what you really need ... :)10:50
lekernelsometimes, there are still some silly and complicated to fix comb loops in the migen output as well10:50
lekerneleg http://lists.milkymist.org/pipermail/devel-milkymist.org/2012-November/003190.html10:51
wpwrakso icarus doesn't always solve the halting problem. well, what's new ? :)10:54
larscwell it's not the halting problem10:56
larscit's just a simple bug10:57
wpwrakyeah. a very special case of not solving the halting problem :)11:00
lekernelthe funny thing is all simulators do a different thing11:01
wpwrakbut does icarus advance the time ? or does it stay at t = 0 ?11:02
larscit shouldn't11:02
larscshould all be in the same delta cycle11:03
larscbut on the other hand verilog doesn't know about delta cycles11:04
lekernelit'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.11:11
lekerneland the event driven model does not know anything about synchronous hardware, which is wrong11:11
wpwrakso you basically want to reduce it to either "assign" or "always @(...edge ...)", no other forms of always11:12
larsceven with the event driven model loops settle in short time, zero time to be exact.11:15
larscproblem is when they don't settle, but they won't settle in hw either in that case11:15
lekernelI mean time in delta-cycles11:18
lekerneland yes11:18
lekernelbut for some verilog simulators, loops that settle in hw don't settle in simulation11:18
lekernelincluding some big expensive simulators11:19
wpwrakcan an always also execute then a signal it assigned to but doesn't change ?11:19
wpwrake.g., always @(x) y <= y+111:20
wpwrakand somewhere else x = 1; x = 1; x = 1;11:20
larscthat's undefined11:20
wpwrakif the answer is "yes", the endless loop would be more or less valid11:20
wpwrakhah ! :)11:20
larscI think11:20
wpwrakthere we go11:20
larscyou just shouldn't do this kind of thing11:21
wpwrakof course, that makes @(*) rather dubious11:21
wpwrakin a way, always @(*) makes assign somewhat redundant, doesn't it ?11:22
larscin what way?11:22
wpwrakin the sense that assign could just be expressed as always @(*), couldn't it ?11:24
larsckind of11:27
larscyou can do more in a process though11:28
larscand an assign is more like aliasing the signal11:29
wpwrakyou 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 ?11:30
wpwraki could imagine an event counter, but then that's probably undefined (see the example above)11:30
larscyou can for example use a case statement11:35
wpwrakcouldn't you express this in an "assign" as well ?11:36
larscbut not as nicely11:37
wpwraki'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.11:57
larscwell assign foo <= bar; is easier than always @(*) begin foo <= bar; end12:03
larscand there is a a subtile difference12:04
wpwrakyou could just group several assignments in one block, like migen does12:05
larscwhy would you?12:06
wpwrakto avoid the extra construct. keep the language simple12:07
larscassign assigns a signal to a signal and <= assigns a value to a signal12:07
wpwrakthat's an implementation detail :)12:08
wpwrakalso blocking vs. non-blocking seems a bit unnatural12:09
wpwrakif you assume that you have a synchronous design anyway, i don't think you need both12:09
larscyea, that's what they messed up in verilog12:09
larscthey only had blocking in the beginning12:10
wpwrakthat's what i'd do, too12:10
larscblocking is horrible12:10
wpwraki'd put my faith in data flow analysis12:10
wpwrakthat is, the semantics would be those of blocking. nice and easy. the implementation could be something very different.12:11
larscthe problem with blocking is that is not deterministic12:11
lekernelit is deterministic if the only thing you do with the value is read it in a non-blocking assignment somewhere down the same always block12:12
wpwrakhow about making blocks (semantically) atomic ?12:14
lekernelhow about not having blocks?12:14
wpwrakhow do have different clocks without blocks ?12:15
lekernelthe only reason you may want blocks is for variables/blocking assignments12:15
wpwrakalso migen has them. all sorts of sync plus one comb12:15
lekerneland clocks ofc12:15
larscwell, you want blocks to structure things12:16
wpwrakwell, perhaps one could do it like this: use blocks strictly for scoping and compound statements, like in c12:16
lekernelno, python provides better ways to structure things12:16
larscbut we are not talking about python now, are we?12:17
wpwrak[...] ... naw, that thouht i was developing doesn't go anywhere nice12:18
wpwraklekernel: python still has blocks :)12:18
wpwraki'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 code12:20
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/WEx8x7C914:44
Alarm__wpwrak: why ?14:44
Alarm__wpwrak:  ?15:32
wpwraklooks as if it should work. does anything happen instead ? error or such ? the controller numbers ( (1, 1), (1, 2), (1, 3) ) are correct ?15:49
wpwraki don't know about DMX, though. do if it's a problem on the DMX side, i wouldn't know what it means.15:49
Alarm__wpwrak: f I put DMX2 = 1.0 then the red lights.16:26
Alarm__wpwrak: if I put DMX2 = 1.0 then the red lights.16:26
wpwrakmaybe try avoid binding the control directly to an output variable. i.e., instead of  dmx2 = range(fader1);  do  tmp = range(fader1); dmx2 = tmp16:30
wpwrakas far a i remember both should work, but maybe there's an issue16:30
wpwrakyou could also test your fader selection. i.e., make sure you got the numbers right. if you got them wrong, simply nothing happens16:31
Alarm__wpwrak: in last line, I put: DMX2 = tmp, I get the following error: "Value must be a near constant EOF"16:48
wpwrakyou need to set tmp first :)16:51
wpwraktmp = range(fader1); dmx2 = tmp16:52
Alarm__wpwrak: http://pastebin.com/7eZB2DJA17:06
Alarm__  wpwrak :with the line "DMX2 = tmp;" I get an error. If I remove it, I have no error17:08
wpwraklekernel: your 1 minute run was probably the equivalent of compiling 'int main(void) { return 0; }' ;-)17:08
lekernelno, the output looked serious17:09
wpwraklekernel: did you have a partial/unsuccessful run before ? maybe they got better at incremental builds17:09
lekernelno, I didn't17:10
wpwrakah, you're in the initialization. you need to add per_vertext: before the assignments17:12
wpwrakthat was for Alarm__17:12
wpwraklekernel: hmm, mysterious. unless they run time actually depends on how much of the fpga is not used, that doesn't quite make sense17:13
wpwrakAlarm__: well, before the assignments to tmp and to dmx217:15
lekernelwell for now I'll have more than enough trouble getting the s6 mixxeo out17:15
lekernelvivado etc. I will look later17:15
wpwrakAlarm__: err, the one to dmx2 only. the other one is good.17:15
Fallenou19:12 < wpwrak> ah, you're in the initialization. you need to add per_vertext: before the assignments < or per_frame: ?18:24
wpwrakargh. yes, per_frame18:25
wpwrakthat stuff is totally swapped out18:25
_florent_I'm trying to adapt the DDR controller to Kintex7 on the KC705.19:11
_florent_I'm only doing an adaptation of the milkymist-ng S6ddrphy to use the Kintex7 blocks (oserdese2, iserdeses2, ...)19:12
_florent_read & write leveling is not implemented for now, but it should work without at low frequency (200 MHz ie DDR400).19:12
_florent_ for now I'm able to initialize the DDR in simulation and commands are sent correctly to the memory.19:12
_florent_I have a little question on one point, my configuration is:19:13
_florent_Burst Length = 819:13
_florent_Nb Phases = 2 (still half rate controller)19:13
_florent_DFI data width = 128 (64 bits DDR3)19:13
_florent_ie to generate a complete DDR burst, I have to assert dfi_wrdata_en for 2 consecutive cycles (256 bits per cycle).19:13
_florent_I have done some adaptation on the asmicon to use correct values for burst length and asmiport data width (512)19:14
_florent_but it seems the asmicon is still asserting dfi_wedata_en for only 1 cycle.19:14
_florent_I haven't look at the asmicon code yet on this point19:14
_florent_lekernel : do you remember if this behaviour is implemented?19:14
_florent_It seems it's not implemented in the code, I'll try to add it20:07
sb0_florent_, ASMI doesn't support bursts. use BL=4 instead.20:48
sb0ah but that's not possible with ddr3.. hmm20:49
_florent_I'm looking at the multiplexer20:49
_florent_it seems possible to add support for that here20:50
sb0I guess that with the clock frequencies of DDR3 compared to the slowness of FPGAs, you need a 1/4 rate controller eventually20:50
_florent_I'll try to do it20:51
_florent_for now it's really a simple port of your phy20:51
_florent_It won't probably work with frequency > 200 MHz since write and read leveling won't be implemented20:52
sb0yeh, you can try hacking something together first... but I don't think it makes much sense to support bursts permanently in ASMI20:52
sb0you'd be better off with DDR2 in this case, which has lower CAS latency20:52
_florent_probably but I'm not able to change the ddr on the board20:54
sb0how about doing it right, with 1:4 (cmd) / 1:8 (data) serialization, and read/write leveling?20:55
sb0note that read leveling is just using DQS ...20:56
sb0and if you have only one chip, or individual chips, you don't need WL20:57
_florent_it seems ddr3 has a burst chop mode20:58
_florent_a kind of BL4 support20:58
sb0it won't help20:58
sb0the peak data rate is the same20:59
sb0all it does is use the first 4 bit times only20:59
_florent_ok but at least it will be functionnal but I agree very slow...20:59
sb0you have the exact same IO timing constraints in BL8 and burst chop 421:00
sb0so just use BL8 in this case ;) you've done the hard part, don't waste half the bandwidth for nothing21:00
sb0the only advantage of chopped burst is reduced delays for some read-to-write, write-to-read and write-to-precharge transitions21:02
sb0it's very minor and I think a good strategy is just to ignore it, DDR3 is messy enough like that21:02
_florent_ok and do you know if in burst chop mode, you have to generate dqs for the last 4 burst?21:04
sb0I don't think so, since burst chop reduces the bus turnaround timing spec. that's incompatible with the transmitting end still driving DQS.21:05
sb0but check the datasheet21:06
_florent_ok but anyway, it will probably be easier to hack the controller21:07
sb0is it a DIMM with that horrid flyby routing topology?21:07
sb0or just one chip?21:07
_florent_a dimm21:07
_florent_with 8 chips21:07
sb0and you need all of them?21:07
_florent_maybe not21:08
sb0well, on the other hand, xilinx claims they have fixed the supershitty IODELAY in 7 series21:09
sb0if that claim is true, implementing write leveling might not be too hard21:09
_florent_but it will be very slow with only a 8 bit DDR...21:09
sb0especially since you can do it from LM32, with nice debug output21:10
_florent_one thing that is very frustrating is that the equivalent of oserdes2 and iserdes2 (oserdese2 and iserdese2) are now secure ip21:10
_florent_so it's not possible to simulate with icarus21:11
sb0it is. modelsim passes the cleartext to memcpy() when you load secureip.21:12
_florent_ah interesting21:12
--- Tue May 21 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!