| cladamw | xiangfu, the lastest boot.crc.d41c1c9.bin can't enter selection in test program. http://pastebin.com/Wd11fDdQ | 01:41 |
|---|---|---|
| cladamw | xiangfu, but I think that you're working on it. | 01:41 |
| xiangfu | cladamw, not finish yet. | 01:41 |
| xiangfu | yes. working on that. | 01:42 |
| xiangfu | you can use 'boot.bin' for test. | 01:42 |
| cladamw | xiangfu, http://milkymist.org/updates/2011-11-29/for-rc3/ so you will update here soon? | 01:43 |
| xiangfu | yes | 01:43 |
| xiangfu | I will delete the boot.crc.d41c1c9.bin now. | 01:43 |
| cladamw | okay...I/m going to use that latest 'boot.bin', tks! | 01:44 |
| cladamw | yes. the test.bin works well except crc item. :-) | 01:56 |
| xiangfu | yes. | 02:00 |
| xiangfu | there must some detail I missed. | 02:01 |
| xiangfu | I skip 72bit in linker.ld BSS section. | 02:02 |
| xiangfu | append the CRC to the end of the file. | 02:02 |
| whitequark | here is my brainfuck softcore: http://pastie.org/3013590 | 02:21 |
| whitequark | it synthesizes (to 128 slices on spartan-3e), but is untested yet | 02:21 |
| cladamw | xiangfu, sorry that I didn't test midi item. The midi item doesn't work. I guess this is caused by midi low level f/w or fpga codes changed. | 03:14 |
| xiangfu | midi item. I will check that. | 03:29 |
| whitequark | it even kind of works! http://rghost.ru/34637451.view | 03:54 |
| kristianpaul | :-) | 04:08 |
| whitequark | nah. hangs at loops :/ | 04:15 |
| wolfspraul | wpwrak: wow great, that's a relief [customs] | 04:43 |
| wolfspraul | how much did you have to pay? did the invoice help? | 04:44 |
| wolfspraul | why was it kicked out of the standard process? | 04:44 |
| wolfspraul | wpwrak: oh I got your mail about customs - great | 05:04 |
| whitequark | it works! http://rghost.ru/34642301.view | 06:01 |
| whitequark | and here is the CPU itself: http://pastie.org/3014243 | 06:02 |
| whitequark | kristianpaul: can you insult my code? :) | 06:03 |
| kristianpaul | whitequark: why i'll do such thing? | 11:17 |
| wpwrak | wolfspraul: i had to pay USD 124 in customs fees. that's a bit higher than usual - normally, it's 50% of declared value with EMS or regular mail, and a little lower with fedex. maybe they calculated the fees over value plus shipping, which would actually be the "official" formula. | 11:48 |
| wpwrak | wolfspraul: plus USD 37 for storage. | 11:48 |
| wpwrak | wolfspraul: so all more or less within the expected range. | 11:49 |
| wolfspraul | ok good | 12:34 |
| wpwrak | wolfspraul: how's .de ? busy pimping M1 already ? | 12:47 |
| lekernel | .de ? | 13:10 |
| lekernel | btw - finally (!) demoing M1 to Peter tomorrow :) | 13:10 |
| wpwrak | lekernel: (.de) wolfgang is in germany now | 13:21 |
| wpwrak | peter ... gabriel ? | 13:22 |
| Thihi | Hmm, btw. nobody answered me here the other day. Are there other variables in the flickernoise patch script language that use the video input in some way except the video_a variable? | 13:24 |
| wpwrak | hmm, seems to be the only one (haven't done much with video yet) | 13:25 |
| Thihi | Ok. | 13:26 |
| lekernel | Thihi: yes, it's the only one so far | 13:32 |
| lekernel | wolfspraul: where? let's have a beer if you're not too far from Berlin :) | 13:33 |
| roh | re | 14:52 |
| whitequark | kristianpaul: well, it was an unusual way to ask for code review. | 15:14 |
| kristianpaul | i dont feel like a persona to ask those thins, i'm prety to this, also i had to learn on the road | 15:15 |
| kristianpaul | but i will insisnt in jump directly to milkymist code hacking | 15:16 |
| whitequark | hm | 15:21 |
| whitequark | I don't have an M1 | 15:22 |
| kristianpaul | i dont meant that, milkymist code is free you dont need a M1, also very portable | 15:24 |
| kristianpaul | like the tdc-core at the cern open hardware repository, very portable implementation | 15:24 |
| whitequark | hm | 15:24 |
| whitequark | what do you think I can do now? | 15:25 |
| whitequark | i.e. what in the code needs fixing and not needs an M1 | 15:27 |
| kristianpaul | learn :) | 15:27 |
| kristianpaul | well if you really interested | 15:28 |
| whitequark | kristianpaul: that's what I'm doing now:) | 15:32 |
| kristianpaul | good | 15:33 |
| whitequark | I think the next try will be a pipelined bf CPU, just to understand the implications | 15:35 |
| whitequark | (I don't actually think I can modify something in lm32 code and make it work. it's quite complex) | 15:35 |
| kristianpaul | whitequark: Fallenou did some blog entry in his blog about the topic | 15:36 |
| kristianpaul | whitequark: check pfu core, is part of my and therotically easy to customize | 15:37 |
| lekernel | lm32 isn't complex | 15:39 |
| kristianpaul | but worth to customize? | 15:39 |
| whitequark | lekernel: it isn't. but I have 1 (one) day of fpga experience | 15:40 |
| kristianpaul | i remenber was just one or two extra isntrucionts that can be added? | 15:40 |
| whitequark | kristianpaul: can you link to his blog? I can't google it | 15:42 |
| kristianpaul | Yann Sionneau | 15:58 |
| kristianpaul | milkymist blog fpga | 15:58 |
| whitequark | ah yes, found it now | 16:00 |
| whitequark | quite interesting | 16:01 |
| lekernel | http://www.ohwr.org/projects/ohr-meta/wiki#What-others-write-about-OHR | 16:10 |
| lekernel | btw, I'll be speaking at http://www.notacon.org/ | 16:24 |
| whitequark | okay, I don't understand this | 16:30 |
| whitequark | look, I have a RAM block which is driven, as far as I understand, by a positive clock edge | 16:31 |
| whitequark | there exists a design, where three things happen simultaneously | 16:31 |
| whitequark | a) positive EN positive | 16:31 |
| whitequark | b) address change | 16:31 |
| whitequark | c) positive clk edge | 16:31 |
| whitequark | after one full clk cycle, the data appears, and looks like that it works stable | 16:32 |
| whitequark | but this is clearly a setup time violation | 16:32 |
| whitequark | isn't it? | 16:32 |
| whitequark | *a) positive EN edge | 16:32 |
| whitequark | the RAM is a standard Xilinx Spartan3E BRAM | 16:32 |
| lekernel | hm... you should read some courses on synchronous logic systems | 16:33 |
| lekernel | and use synchronous logic as much as possible, the s3e architecture is made for that | 16:33 |
| whitequark | lekernel: that design is synchronous | 16:36 |
| whitequark | still: am I wrong? | 16:36 |
| stekern | where are they happening, in the waveform in simulations? | 16:37 |
| lekernel | what is EN exactly? the block RAM CE? | 16:38 |
| lekernel | that pin is synchronous, and has setup/hold constraint wrt the clock signal | 16:38 |
| whitequark | stekern: it works both in simulation and on a real board | 16:38 |
| lekernel | (often automatically enforced/checked by the tools) | 16:38 |
| whitequark | lekernel: https://github.com/grindars/bfcore/blob/master/IRAM.v | 16:38 |
| whitequark | the BRAM is generated automagically by XST | 16:38 |
| lekernel | yes, it's block RAM CE | 16:39 |
| lekernel | so A and EN have to stay stable a fraction of a nanosecond before the clock edge, and a fraction of a nanosecond after the clock edge | 16:40 |
| lekernel | most often, the tools take care of this for you | 16:40 |
| whitequark | (waveforms: http://rghost.ru/34731201.view) | 16:40 |
| whitequark | hm | 16:40 |
| whitequark | so, the XST (or PAR?) is clever enough to insert some internal delay to comply to setup/hold time constraint? | 16:41 |
| lekernel | generally the hold time is granted, because the flip-flops actually switch a short while after the clock edge | 16:42 |
| lekernel | PAR, however, does try hard to maintain the setup time (which determines the maximum clock frequency of the circuit) | 16:43 |
| whitequark | interesting | 16:45 |
| stekern | whitequark: I thought you were asking about not seeing that fraction of a nanosecond lekernel spoke about in simulations | 16:46 |
| lekernel | simulations use delta-delays, which is something else | 16:47 |
| whitequark | stekern: that too | 16:48 |
| whitequark | I have just read about setup/hold time constraints, and I've seen how it works both in simulation and in a real device | 16:48 |
| whitequark | while, in my opinion, it should have not | 16:48 |
| lekernel | whitequark: when simulating a synchronous circuit using an event-driven simulator, you should rely on the delta-delay algorithm, not insert delays in your code | 16:49 |
| lekernel | many people do not understand delta-delays and go for the latter option (even in some organizations where you would expect to see skilled designers), and this is a typical *HDL code smell | 16:50 |
| stekern | yeah, delays in the code sucks | 16:54 |
| lekernel | well, at least those people understand synchronous circuits. I remember an epic PS/2 controller from Potsdam university... I should grab the code and post it somewhere as an example of what not to do =] | 16:55 |
| kristianpaul | yes please :) | 16:56 |
| GitHub8 | [milkymist] sbourdeauducq pushed 5 new commits to master: https://github.com/milkymist/milkymist/compare/6f50e96...14a31d4 | 17:15 |
| GitHub8 | [milkymist/master] milkymist: remove unused variables in libbase/softfloat.c - Werner Almesberger | 17:15 |
| GitHub8 | [milkymist/master] milkymist: use -Wstrict-prototypes - Werner Almesberger | 17:15 |
| GitHub8 | [milkymist/master] milkymist: try -Wmissing-prototypes - Werner Almesberger | 17:15 |
| GitHub4 | [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/ZdOP5w | 17:16 |
| GitHub4 | [flickernoise/master] parser_helper.c: use asprintf instead of DIY solution - Werner Almesberger | 17:16 |
| wpwrak | is the MIDI test cable a regular MIDI cable or does it have some special features ? | 17:18 |
| lekernel | wpwrak: why are you returning const char * in fpvm_parse? it's a dynamically allocated string ... | 17:19 |
| lekernel | regular MIDI cable | 17:19 |
| wpwrak | (const char *) because the recipient isn't supposed to change it. | 17:20 |
| lekernel | mh... if you want... but then you have to cast it when passing to free() | 17:22 |
| wpwrak | yes, i do that | 17:22 |
| lekernel | C's "const" is broken anyway... use as you would use someone else's toothbrush | 17:22 |
| lekernel | yeah, but it's more typing | 17:22 |
| wpwrak | heh :) yes, "const" is a bit quirky. and i don't like it that "free" needs casts. but it helps in all the other places where such a string may be used. | 17:23 |
| GitHub76 | [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/tYEw_g | 17:23 |
| GitHub76 | [flickernoise/master] ptest: fix memory leak - Sebastien Bourdeauducq | 17:23 |
| lekernel | another detail is it's a little confusing to name stuff in FN with a "fpvm_" prefix | 17:24 |
| wpwrak | yes ... most of that can go anyway. just a question of cleaning up a little more | 17:25 |
| wpwrak | i kept fpvm_ because some thing are from there, so i didn't have to change the callers. since then, i've eliminated most of the callers :) | 17:26 |
| wpwrak | hmm. autotest is unhappy. hates my midi :-( | 17:26 |
| wpwrak | there are a few other things, like the comments ending up in infra-fnp.h, the "_xy" variable, adding things like per_vertex to the name table. little details that slow things down. | 17:28 |
| lekernel | wpwrak: maybe the autotest doesn't support mwalle's new UART core? | 17:29 |
| lekernel | so you plan to remove parser_helper? | 17:29 |
| wpwrak | but for now my goal is functionality. then the cleanup. there are a few more things that want cleaning up anyway, like the symbol lookups | 17:29 |
| wpwrak | (parse_helper) haven't consider that yet. i think it has its uses. | 17:30 |
| lekernel | well, all it contains is fpvm_parse and fpvm_parse_free you said you would remove | 17:30 |
| wpwrak | (UART core) hmm, could be. there were a lot of interrupt changes as well, weren't there ? | 17:31 |
| lekernel | yes | 17:31 |
| wpwrak | ah, i was thinking of the things in fpvm.c | 17:32 |
| wpwrak | fpvm_parse* only need a renaming :) | 17:32 |
| wpwrak | (uart) maybe i'll leave this to you then :) you already know what to change. | 17:33 |
| lekernel | yes, i'll have a look | 17:33 |
| lekernel | you see I'm doing efforts to support Linux :) easier Linux support was the main motivation for the new UART | 17:34 |
| wpwrak | hehe, great :) | 17:35 |
| wpwrak | the usb test is funny. asks to press enter/left button on port A then on port B. but you can just do both on the same port ;-) | 17:35 |
| wpwrak | of course, there's no way to tell anyway, at that level :) | 17:36 |
| GitHub108 | [autotest-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/59j1xg | 17:45 |
| GitHub108 | [autotest-m1/master] Remove dependency on libmath - Sebastien Bourdeauducq | 17:45 |
| GitHub15 | [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/14ad8baf3a5d3a2cc01698ff3439e5e2894f2f93 | 17:47 |
| GitHub15 | [milkymist/master] Remove libmath - Sebastien Bourdeauducq | 17:47 |
| wpwrak | hehe, die libmath, die ! ;-) | 17:48 |
| wpwrak | so we just haev softfloat to produce lots of complains with -Wmissing-prototypes not | 17:50 |
| wpwrak | s/not/now/ | 17:50 |
| lekernel | and the autotest | 17:50 |
| wpwrak | yes, i've seen some function() there as well. haven't tried to crank up the warnings over there yet, though | 17:51 |
| whitequark | lekernel: I have another question then | 18:04 |
| whitequark | xilinx docs say that BRAM works on _both_ edges | 18:04 |
| whitequark | then, can I first latch in an address in a manner described above | 18:05 |
| whitequark | and then wait for 1/2 of clock cycle and disable CE? | 18:05 |
| whitequark | output buffers should still be active, and I'll be able to make a second request in a very next clock cycle | 18:05 |
| whitequark | like this: | 18:16 |
| whitequark | CLK _|>|_|>|_|>|_|>|_|> | 18:16 |
| whitequark | CE _|>>>|___|>>>|___|> | 18:16 |
| whitequark | A _X___X___X___X___X_ | 18:16 |
| whitequark | D <_1_X_2_X_3_X_4_ | 18:16 |
| whitequark | REG <_1_X_2_X_3_X_ | 18:17 |
| whitequark | oh | 18:18 |
| whitequark | CE should have been = CLK. | 18:18 |
| whitequark | and freenode ate my precious combining unicode. | 18:19 |
| whitequark | http://pastie.org/3016878 | 18:20 |
| juliusb | i'm not sure if IRC is the best medium for waveform viewing | 18:50 |
| whitequark | juliusb: well, I've been drawing these ones... for a while and didn't want to throw them out. | 18:51 |
| whitequark | otoh, they are still meaningful. | 18:51 |
| mwalle | lekernel: is autotest the production test suite? | 18:57 |
| juliusb | :) | 19:21 |
| whitequark | TI: "Your device is a product of superior design and craftsmanship and should be treated with care." | 20:03 |
| whitequark | have they ever heard of modesty? :D | 20:03 |
| whitequark | (after that, they suggest that I should "Do not attempt to open the device. | 20:04 |
| whitequark | well, it's fine, except for the fact they are describing a PCB. | 20:04 |
| whitequark | also, since when PCBs have "moving parts"?.. | 20:05 |
| wolfspraul | juliusb: why is irc not good for waveforms? I think those are awesome! whitequark - more plase :-) | 20:10 |
| whitequark | wolfspraul: I'm thinking about releasing a library for drawing (awesome) unicode waveforms | 20:11 |
| whitequark | a "library" | 20:12 |
| wolfspraul | definitely | 20:12 |
| wolfspraul | we need to get more beginners into this scene, and we know it's a worthwhile endeavor so we can build bridges wholeheartedly | 20:12 |
| wolfspraul | it's not a fad that will go away in a year or two | 20:13 |
| whitequark | what I see in Russia is a horrible, horrible lack of sensible engineers | 20:13 |
| mumptai | and drawing waveforms will help? | 20:13 |
| wolfspraul | discussing about them, definitely imho | 20:13 |
| whitequark | especially young ones (< 50 yrs.), because old-schoolers, at least here, often prefer... suboptimal methods | 20:13 |
| wolfspraul | and discussion may be eased with a drawing :-) | 20:14 |
| whitequark | so it would be very good if it actually worked. | 20:14 |
| kristianpaul | i agree with wolfspraul , the ascii waves are not bad | 20:14 |
| wolfspraul | when I saw them I was first taken aback, but that's cool. new idea! waveform ascii art in irc - cool! :-) | 20:14 |
| kristianpaul | of course the link to a vcd file download is not bad either :) | 20:15 |
| wolfspraul | how useful we find out over time | 20:15 |
| Action: whitequark goes back to writing a pipelined brainfuck cpu core with branch prediction | 20:17 | |
| wpwrak | roh: hmm, using http://projects.qi-hardware.com/index.php/p/m1/source/tree/master/cad/protocase_v7_laser.dxf, how can i tell what is engraving (text) and what is a cut through the board ? | 21:27 |
| whitequark | looking at RTL makes me feel quite stupid. | 21:45 |
| whitequark | can I assume that a trigger has an implicit delay inside, and if several ones are connected in a sequence, a clock pulse _first_ latches the state of output to the input of next one, and _then_ switches the output? | 21:46 |
| lars_ | more or less | 21:51 |
| lars_ | but it all happens at the same time. so not "first" and "then" | 21:52 |
| whitequark | well, it happens at the same time for each of the individual flip-flops, yes | 21:53 |
| whitequark | what I don't understand | 21:54 |
| whitequark | if it happens _really_ at the same time | 21:54 |
| whitequark | then you cannot build a working chain of flip-flops at all | 21:54 |
| whitequark | they all will switch simultaneously | 21:54 |
| lars_ | there is propagation delay | 21:54 |
| whitequark | that's what I have asked | 21:55 |
| whitequark | without propagation delay, synchronous circuits cannot work, can they? | 21:55 |
| lars_ | probably not | 21:57 |
| lars_ | at least not the way we expect them to work | 21:57 |
| whitequark | thanks, I understand the idea now | 21:58 |
| whitequark | looking at RTL really helps to understand how the circuit you've just designed really works | 22:01 |
| whitequark | or maybe I'm just fooled by C-look-alike-ness of verilog | 22:01 |
| lars_ | do you use a lot of blocking statements? | 22:03 |
| whitequark | lars_: none of them | 22:04 |
| kristianpaul | urghh | 22:05 |
| whitequark | kristianpaul: hm? | 22:05 |
| kristianpaul | non blocking way go, i agree with sebastien | 22:05 |
| kristianpaul | also use as much you can always statements | 22:06 |
| kristianpaul | life easier :) | 22:06 |
| whitequark | yes, I've already notices that | 22:06 |
| whitequark | *noticed | 22:06 |
| lars_ | i fully agree. i never use blocking statements | 22:06 |
| whitequark | if I put everything in one always statement, XST tends to infer some monstrosity | 22:06 |
| whitequark | and if I don't, then it's a nice clean set of primitives as they should be | 22:07 |
| lars_ | but imo non blocking is already quite close to rtl | 22:08 |
| whitequark | blocking statements look quite foreign to FPGA's for me. they hide some internal state and tend to generate suboptimal code | 22:08 |
| whitequark | lars_: maybe that's just how my brain works: if it sees C-like text, it thinks procedurally, and if a circuit, then in a proper way | 22:08 |
| whitequark | just guessing | 22:08 |
| whitequark | but the thing I'm doing now had not started to work until I stared for 30 minutes at RTL. | 22:09 |
| whitequark | the logic was completely wrong | 22:10 |
| lekernel | whitequark: no, BRAMs do not work on both edges. what they probably mean is you can select between reacting to rising or falling edges. | 23:04 |
| lekernel | but you can't do both | 23:04 |
| lekernel | if you want to have 1 request per cycle, you can pipeline them | 23:04 |
| lekernel | but keep everything synchronous... no half-cycles or things like that | 23:04 |
| whitequark | lekernel: I'm pipelining everything | 23:05 |
| whitequark | well | 23:05 |
| lekernel | FPGAs aren't made for this, and it's a source of bugs and time wastage | 23:05 |
| whitequark | and yes, everything I do is only done @(posedge clk) | 23:05 |
| whitequark | but I've thought of a "clever trick" for RAM access | 23:05 |
| whitequark | assign ram_ce = should_fetch && clk; | 23:06 |
| whitequark | damn. | 23:07 |
| whitequark | INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - | 23:07 |
| whitequark | (not related to the ram_ce) | 23:07 |
| lekernel | oh, and yes, if you try asynchronous designs, this tickles synthesizer bugs as well :-) | 23:07 |
| lekernel | clk should be connected *only* to clock ports | 23:07 |
| whitequark | lekernel: ah okay, then it is possibly related. | 23:08 |
| whitequark | hm | 23:08 |
| whitequark | maybe there is a clock gate | 23:08 |
| whitequark | primitive I mean | 23:08 |
| lekernel | wtf? | 23:09 |
| lekernel | I told you to do a synchronous design | 23:09 |
| lekernel | forget about clock gating | 23:09 |
| whitequark | ok | 23:10 |
| lekernel | the FPGA architecture is optimized for synchronous designs, and the tools expect synchronous designs | 23:10 |
| whitequark | hm | 23:11 |
| whitequark | then I don't understand how one can get one request per cycle | 23:12 |
| lekernel | by presenting a new address after each clock edge | 23:12 |
| whitequark | ahh, so it does not need CE edges | 23:12 |
| whitequark | yes indeed it does not. stupid | 23:12 |
| lekernel | and yes, this means that the data pins have the values from the previous address. that's where pipeline hazards and other niceties come from :-P | 23:13 |
| whitequark | yeah. I've read See MIPS Run several times | 23:13 |
| lekernel | CE is a synchronous pin that tells it to read the new address when it's high | 23:14 |
| whitequark | MIPS is a horribly bad processor design, but the book describes a lot of interesting things about processor internals | 23:14 |
| lekernel | its purpose is to _disable_ the RAM read for some cycles | 23:14 |
| whitequark | nah | 23:15 |
| whitequark | still "INTERNAL+ERROR" | 23:15 |
| whitequark | lekernel: can you take a look at my code? it just dies somewhere in the parser | 23:18 |
| whitequark | with a double free. | 23:18 |
| lekernel | mwalle: yes, autotest is the production test software | 23:19 |
| whitequark | okay. an undocumented xst option -use_new_parser yes fixes that. | 23:37 |
| --- Thu Dec 15 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!