| --- Log opened Tue Oct 22 00:00:50 2013 | ||
| poke53281 | Good morning stekern. It's time to wake up ;) | 02:14 |
|---|---|---|
| stekern | poke53281: morning | 02:31 |
| hansfbaier | stekern: Do you have an idea of how to debug i2c further? The I2c on the bottom header sends nothing out, sda and scl just seem tied high. Because I thought the new linux driver was possibly broken, I ported a bare metal driver I used on the ZPU but with the same core. Same result: No output. I triple checked the pinmap, I looked at the top level several times, I diffed with orpsocv2, no result. I'm kind of out of ideas now.... | 08:08 |
| hansfbaier | stekern: i2c0 can see the EEPROM, but not the accel. I noticed the fitter just ignored it when tying the pin to VCC via tcl. I added then an output to _top tied to one. That worked well, but still no accel. Any ideas of how to further proceed? Signal Tap? | 08:09 |
| hansfbaier | juliusb: ^ This is about de0_nano on orpsocv3, I ported over the spi and parts of i2c | 08:10 |
| olofk_ | So when I finally learned the IP of my server, there is a power failure | 08:14 |
| olofk_ | hansfbaier: Could it be that those pins are reserved for something else? Did you try to move them somewhere else? | 08:15 |
| olofk_ | Have you checked with a simulator that the wishbone accesses reaches the core? | 08:16 |
| hansfbaier | olofk: good ideas, will try. | 08:17 |
| olofk_ | Did you use orpsocv3 EE? The free version is limited to one i2c core | 08:17 |
| hansfbaier | olofk: Which simulator would be best for that purpose? | 08:17 |
| hansfbaier | olofk: lol | 08:17 |
| olofk_ | hansfbaier: I would try modelsim. Icarus might work, but that requires that you are not using any altera-specific primitives in the design | 08:18 |
| hansfbaier | olofk: never touched modelsim. How about verilator? | 08:18 |
| hansfbaier | olofk: Oh you mean with orpsocv3... | 08:19 |
| olofk_ | verilator also requires you to not have any altera-specific primitives, and you need to create C++ test bench top level | 08:19 |
| hansfbaier | ./orpsoc sim de0_nano? | 08:19 |
| olofk_ | That should launch a simulation with the default simulator (given that someone has been kind enough to actually write a testbench) | 08:20 |
| hansfbaier | error: Unable to find the root module "orpsoc_tb" in the Verilog source. | 08:20 |
| hansfbaier | nope | 08:20 |
| olofk_ | Ahh.. sorry. That's an orpsoc issue. Use "orpsoc sim --force de0_nano" to clean out the build dir | 08:21 |
| olofk_ | It's a feature/bug | 08:21 |
| olofk_ | And you probably want to preload an elf file to the RAM as well | 08:21 |
| olofk_ | add --or1k-elf-load=/path/to/file.elf | 08:22 |
| olofk_ | Add --vcd if you want VCD logging, and add --timeout=<integer value> if you want the test case to abort after a certain time | 08:22 |
| hansfbaier | http://pastie.org/8420697 | 08:23 |
| olofk_ | Try to remove altera_virtual_jtag.v from de0_nano.core | 08:24 |
| olofk_ | hmm.. is there a bench/orpsoc_tb.v in your de0_nano system? | 08:25 |
| hansfbaier | olofk_: $ ls systems/de0_nano/bench/orpsoc_tb.v | 08:27 |
| hansfbaier | systems/de0_nano/bench/orpsoc_tb.v | 08:27 |
| olofk_ | That's odd | 08:27 |
| olofk_ | Did orpsoc copy the file into build/de0_nano/src/de0_nano/bench as well? | 08:28 |
| olofk_ | (not sure about the path) | 08:28 |
| hansfbaier | olofk_: I saw that modelsim is somehow integrated with orpsocv3, does it work yet? | 08:29 |
| hansfbaier | else could you recommend a good tutorial/doc of how to use modelsim? It's far from intuitive (compared to isim) | 08:29 |
| _franck_ | it does | 08:30 |
| olofk_ | hansfbaier: orpsoc sim --force --simulator=modelsim de0_nano --or1k-elf-load=.... | 08:30 |
| olofk_ | I think it requires you to set up some environment variable, but I think orpsoc will tell you that if you try to run it | 08:31 |
| hansfbaier | de0_nano has only: http://pastie.org/8420697 | 08:31 |
| hansfbaier | sorry, wrong paste | 08:31 |
| hansfbaier | simulators =icarus | 08:32 |
| hansfbaier | do I need to change it first to modelsim? the above just got me the same error as before... | 08:32 |
| stekern | hansfbaier, juliusb: I'm a bit confused, juliusb's "fancy accelerometer stuff" use spi it seems: https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/boards/altera/de0_nano/sw/tests/simple_spi/board/simple_spi-adxl345.c | 08:32 |
| _franck_ | hansfbaier: could you try with de1 ? | 08:32 |
| hansfbaier | _franck_: sim? | 08:32 |
| stekern | but you are speaking about i2c hansfbaier | 08:33 |
| _franck_ | yes | 08:33 |
| hansfbaier | stekern: Yes, SPI | 08:33 |
| olofk_ | hansfbaier: It's not very important what's in the simulators tag in the .core file yet. The only thing it is used for ATM is that orpsoc defaults to the first specified in the list | 08:33 |
| hansfbaier | if G5 is pulled high, it's supposed to operate as I2C | 08:33 |
| olofk_ | But you override that with --simulator= | 08:33 |
| stekern | ok, so noone have ever actually got that working | 08:34 |
| olofk_ | Got what working? | 08:34 |
| stekern | accelerometer over i2c | 08:35 |
| olofk_ | Didn't juliusb demo that at oshug? | 08:35 |
| hansfbaier | olofk: http://pastie.org/8420713 | 08:35 |
| olofk_ | hansfbaier: Ahh.. ok | 08:36 |
| stekern | olofk_: he demoed it at chiphack, in SPI mode | 08:36 |
| olofk_ | stekern: I see. | 08:36 |
| olofk_ | hansfbaier: Ok. I think I understand now | 08:36 |
| olofk_ | What modelsim version are you running? The Altera-provided one? | 08:37 |
| hansfbaier | olofk_ Yes Altera edition, the freebie | 08:38 |
| _franck_ | hansfbaier: https://github.com/openrisc/orpsoc-cores/blob/master/systems/de1/de1.core | 08:38 |
| _franck_ | look at the bottom of the file | 08:38 |
| hansfbaier | _franck_: sim it? | 08:38 |
| hansfbaier | ah thanks | 08:38 |
| olofk_ | It seems that de0_nano uses several altera primitives. There might have been errors from icarus that we didn't see, because they are currently only written to a log file | 08:39 |
| olofk_ | That's probably why it failed without any apparent reason | 08:39 |
| olofk_ | modelsim should work with the modelsim options from _franck_'s de1 port | 08:39 |
| stekern | hansfbaier: what do you mean with "sda and scl on the bottom doesn't send anything out"? | 08:40 |
| hansfbaier | _franck_: http://pastie.org/8420720 | 08:40 |
| stekern | how can the eeprom work then? | 08:40 |
| hansfbaier | stekern: bottom header | 08:40 |
| _franck_ | altera primitives have ifndef SIM. However, -DSIM is not present in de0_nano.core | 08:40 |
| stekern | hansfbaier: yes, where is the EEPROM connected? | 08:40 |
| olofk_ | Hmm.. should it be --sim=modelsim ? Can't remember | 08:40 |
| stekern | hansfbaier: isn't it connected to the same sda scl? | 08:41 |
| stekern | if not, that's most likely not going to work | 08:41 |
| hansfbaier | _franck_ : I have an issue with or1k-newlib: When I set breakpoints they never break, and when I run over one and break with SIGINT, then it's always in _board_exit | 08:41 |
| _franck_ | never used that option :) I just change simulator in de1.core.... | 08:41 |
| hansfbaier | stekern: No, I have two i2c controllers, one for internal, one for external | 08:41 |
| stekern | ah, ok | 08:42 |
| stekern | so i2c1 is connected to accel? | 08:42 |
| hansfbaier | stekern: the internal i2c0 can see the eeprom, but not the accel, the external does nothing whatsoever, and this really drives me nuts. I already spent hours and hours on it. | 08:42 |
| hansfbaier | stekern: no, i2c0 | 08:42 |
| hansfbaier | stekern: maybe if you might look into the _top file you see something, I'm stricken with blindness ATM.... | 08:43 |
| stekern | so the accel and the eeprom shares the same sda and scl? | 08:43 |
| hansfbaier | stekern: Yes, do I need a pullup on the pin in the TCL? | 08:43 |
| hansfbaier | stekern: Or external pullups on the header? | 08:43 |
| hansfbaier | or declare them in the tcl? | 08:43 |
| _franck_ | hansfbaier: no idea. I didn't test debug thing with newlib programs. Just worked on assembly programs and barebox | 08:44 |
| hansfbaier | but orpscov2 didn't have them either and i2c worked well with my ep4ce10 | 08:44 |
| _franck_ | hansfbaier: does debug works for you with a simple asm led blinker ? | 08:44 |
| hansfbaier | _franck_: No with nothing | 08:44 |
| stekern | it probably doesn't hurt, but I doubt that is what is wrong | 08:44 |
| hansfbaier | _franck_: errr, with nothing that is written in C | 08:44 |
| _franck_ | that should break whatever is the binary... | 08:45 |
| hansfbaier | stekern: My logic analyzer indicated they are pulled high anyway, but not the tiniest trace of a signal there... I'm just puzzled. I looked at the _top.v and .tcl over and over, and they seem all right. I diffed with the old sources, only whitespace and comments. | 08:45 |
| hansfbaier | _franck_: you mean disassemble and then stepi? | 08:46 |
| hansfbaier | stekern: Could you take a look at the tcl and _top in my repo? Maybe you can see something I'm blind to? | 08:46 |
| stekern | old sources for what? there was no I2C1 in orpsocv1 | 08:47 |
| stekern | err orpsocv2 | 08:47 |
| hansfbaier | orpsocv2 they worked for me on my ep4ce10 | 08:47 |
| hansfbaier | git://openrisc.net/stefan/orpsoc | 08:48 |
| _franck_ | hansfbaier: you can do that. Or you can disassemble and then set the breakpoint to a known address | 08:48 |
| hansfbaier | _franck_: let's see | 08:49 |
| stekern | hansfbaier: they? there are only pinmaps for I2C0 in de0_nano, no? | 08:49 |
| hansfbaier | stekern: I used the de0_nano as a basis for my ep4c10 board | 08:50 |
| hansfbaier | stekern: no the de0_nano has full I2C support, I just had to set the right `defines | 08:50 |
| hansfbaier | is git://openrisc.net/stefan/orpsoc orpsoc v1? | 08:51 |
| stekern | no, v1 was a typo | 08:51 |
| stekern | you just had to set the right defines...and do the pinmap | 08:51 |
| stekern | there's no pinmap for I2C1 in de0_nano... | 08:52 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/syn/quartus/tcl | 08:52 |
| hansfbaier | stekern: No, assembler breakpoints don't work as well, I just goes to nowhere then (0x0000004) | 08:56 |
| _franck_ | hansfbaier: ok, weird. I may have a look some day. | 08:57 |
| hansfbaier | stekern: No i2c1 is in my orpsoc-cores//de0_nano | 08:57 |
| hansfbaier | stekern: I only used one i2c in my ep4ce10 | 08:58 |
| hansfbaier | stekern: I mean https://github.com/hansfbaier/orpsoc-cores/blob/master/systems/de0_nano/rtl/verilog/orpsoc_top.v | 09:00 |
| hansfbaier | and https://github.com/hansfbaier/orpsoc-cores/blob/master/systems/de0_nano/data/pinmap.tcl | 09:00 |
| stekern | yes, but you said "I copied from the old sources" and I asked "what old sources" and then you said "orpsocv2" | 09:01 |
| hansfbaier | stekern: Yes, that's where I got the patches from | 09:02 |
| hansfbaier | stekern: and the toplevel | 09:02 |
| hansfbaier | stekern: and pinmap | 09:02 |
| hansfbaier | stekern: i2c1 I did search/replace | 09:02 |
| stekern | ... for i2c0, which "works" (at least as much as in orpsocv2) | 09:03 |
| hansfbaier | _franck_: wait a minute, wrong start point, have to set manually | 09:04 |
| _franck_ | yes, j *0x100 | 09:05 |
| hansfbaier | _franck_: Same result, it works, then I break manually set a breakpoint, then goes to outer space | 09:07 |
| hansfbaier | 0x00000e04 | 09:08 |
| hansfbaier | program ends at 0x000001c0: | 09:08 |
| hansfbaier | stekern: I2c0 can see the eeprom but not the accel | 09:08 |
| _franck_ | hansfbaier: ok, are you using mor1kx ? | 09:09 |
| hansfbaier | _franck_: yes | 09:09 |
| hansfbaier | _franck_: default in orpsocv3 | 09:09 |
| hansfbaier | _franck_: mor1kx has no debug support yet? | 09:09 |
| hansfbaier | aah that explains something | 09:09 |
| stekern | hansfbaier: yes, but I don't think it works any better in orpsocv2 | 09:09 |
| stekern | hansfbaier: mor1kx have debug support | 09:10 |
| hansfbaier | stekern: In orpsocv2 it could see my RTC module which I had on i2c0 (no thers) | 09:10 |
| hansfbaier | others | 09:10 |
| hansfbaier | stekern: Did you have a look at the two links? | 09:11 |
| stekern | yes, but I couldn't see anything special | 09:11 |
| stekern | at least not to why i2c1 doesn't work | 09:11 |
| stekern | hansfbaier: what address did you use when you tried to access the accel? | 09:12 |
| hansfbaier | stekern: I scanned the whole bus, none... | 09:13 |
| hansfbaier | only 0x50 alive | 09:13 |
| hansfbaier | with i2cdetect -y 0 | 09:13 |
| hansfbaier | stekern: In the dts I use 0x1d | 09:14 |
| hansfbaier | stekern: as in yours | 09:14 |
| stekern | yes, but that doesn't work on orpsocv2 anyways | 09:14 |
| stekern | although, 0x1d should be correct | 09:15 |
| stekern | what bus speed are you using? | 09:16 |
| hansfbaier | stekern: last used was clock-frequency = <50000000>; which should correspond to 500kHz | 09:18 |
| hansfbaier | stekern: I tried lowering to 20000000 but no effect | 09:18 |
| stekern | 500 kHz would be too high, the datasheet says: r. It supports standard (100 kHz) and fast (400 kHz)data transfer modes if the timing parameters given... | 09:20 |
| hansfbaier | stekern: Ahh, I should looked there more.... | 09:20 |
| hansfbaier | I'll try clock-frequency = <10000000>; which then would correspond to 100kHz | 09:21 |
| hansfbaier | stekern: Here is my dts now: http://pastie.org/8420809 | 09:23 |
| hansfbaier | adxl34x 0-001d: Failed to probe ADXL34x accelerometer | 09:24 |
| stekern | i haven't looked how the clock-frequency relates to the bus-speed in the i2c driver, but I trust that you've done the math right there ;) | 09:25 |
| stekern | seems like the example design referenced in de0 nano user manual use spi to access the accel too... | 09:26 |
| hansfbaier | stekern: Yes, it's precisely implemented like the formula in the data sheet. system clock corresponds to 500kHz | 09:26 |
| hansfbaier | stekern: Hey wait a minute... | 09:27 |
| * stekern waits a minute | 09:28 | |
| hansfbaier | prescale = (i2c->clock_khz / (5*100)) - 1; | 09:28 |
| hansfbaier | almost exactly a minute :) | 09:28 |
| stekern | ;) | 09:28 |
| hansfbaier | stekern: the denominator is the wanted bus freq in KHz | 09:29 |
| hansfbaier | BTW: http://pastie.org/8420817 | 09:29 |
| stekern | umm, wait a minute | 09:31 |
| stekern | where does that i2c->clock_khz come from? | 09:32 |
| hansfbaier | stekern: clock-frequency /1000 | 09:32 |
| stekern | so if you decrease clock-frequency, you'll increase the bus-speed | 09:33 |
| stekern | so the first was correct | 09:33 |
| stekern | the bus-speed is "hardcoded" to 100kHz | 09:33 |
| hansfbaier | stekern: Yes, that dawned on me too right now, it should have been 50MHz * 5 | 09:33 |
| hansfbaier | = 250MHz | 09:33 |
| hansfbaier | stekern: Ah, yes, 100k that's correct | 09:35 |
| stekern | if you want to try with yet-another-i2c-driver: https://github.com/skristiansson/sublime/blob/master/sw/drivers/opencores_i2c.c | 09:35 |
| stekern | but I doubt that the driver is the problem... | 09:36 |
| hansfbaier | stekern: Is this baremetal? | 09:37 |
| hansfbaier | stekern: But what about printf in there? | 09:37 |
| stekern | yes, baremetal | 09:39 |
| stekern | or1k-elf newlib/libgloss baremetal | 09:39 |
| stekern | I'm going to change the printf's to some macro later ;) | 09:40 |
| hansfbaier | stekern: How do you use the ssm2603? Got a breakout board? I saw i looks like a BGA | 09:40 |
| hansfbaier | stekern: Where do the printf's go, serial? | 09:40 |
| stekern | the ssm2603 is nicely soldered onto your sockit ;) | 09:40 |
| hansfbaier | stekern: Aaaahhh | 09:41 |
| stekern | serial, yes | 09:41 |
| stekern | hansfbaier: did your i2c patches change polarity of arst_rst? | 09:42 |
| hansfbaier | can't remember | 09:43 |
| stekern | if not, this is not right: https://github.com/hansfbaier/orpsoc-cores/blob/master/systems/de0_nano/rtl/verilog/orpsoc_top.v#L655 | 09:45 |
| hansfbaier | stekern: great, that would explain something | 09:45 |
| hansfbaier | stekern: Why the bus is dead on the external one, should that be negated? | 09:45 |
| * hansfbaier is talking nonsense | 09:48 | |
| hansfbaier | scrap the statement before | 09:48 |
| hansfbaier | Ah, yes, parameter ARST_LEVEL should be 0, shouldn't it? | 09:51 |
| hansfbaier | errr no | 09:51 |
| stekern | it depends what you want ;) | 09:51 |
| stekern | I would remove the wb_rst from it and set arst_i to the value where it is not reset | 09:52 |
| hansfbaier | stekern: Mine is identical to orpsocv2 | 09:52 |
| stekern | if you leave ARST_LEVEL to 0, then set arst_i to 1 | 09:53 |
| _franck_ | hansfbaier: at least, breakpoint are working on a simulated system using uart-simple.elf which is using newlib stuff | 09:53 |
| _franck_ | http://pastie.org/8420861 | 09:54 |
| stekern | hansfbaier: perhaps, but I think orpsocv2 is doing it "wrong" by connecting wb_rst to arst_i | 09:54 |
| hansfbaier | _franck_: I use de0_nano | 09:54 |
| hansfbaier | stekern: so tie arst_i to 0? | 09:54 |
| stekern | and orpsocv2 sets ARST_LEVEL to something different than what it is in i2c_master svn | 09:55 |
| stekern | by changing it inside the core, instead of feeding the parameter from the module instantiation | 09:55 |
| hansfbaier | stekern: Yes, but it's the same as in my repo | 09:55 |
| stekern | ok, that's what I wondered | 09:56 |
| hansfbaier | stekern: Or maybe I fried parts of my nano.... Should try the official accel example | 09:58 |
| stekern | which "official"? | 09:58 |
| hansfbaier | altera | 09:58 |
| stekern | all the ones I have seen use SPI | 09:58 |
| hansfbaier | stekern: ah | 09:59 |
| * hansfbaier is getting tired..... | 09:59 | |
| hansfbaier | very hot here | 09:59 |
| stekern | I will happily swap some of the cold here with you | 09:59 |
| hansfbaier | stekern: The brain works better in the cold, just like any CPU/GPU | 10:01 |
| hansfbaier | 31.5C her | 10:01 |
| hansfbaier | e | 10:01 |
| Powermaniac | hansfbaier: That is very interesting you say that, explains somethings about how I am when it is cold here... | 10:02 |
| hansfbaier | Powermaniac: Thinking and remembering is a lot harder when it's hot. | 10:04 |
| stekern | to heck with brains, I'll swap anyway! | 10:04 |
| Powermaniac | Haha | 10:05 |
| hansfbaier | stekern: Funny if I set clock-frequency= 100MHz, the system hangs on startup | 10:08 |
| hansfbaier | stekern: I'd be glad to swap some of the cold too :) | 10:14 |
| hansfbaier | stekern: The EEPROM shows up, but does not work: | 10:16 |
| hansfbaier | # i2cget -y 0 0x50 1 | 10:16 |
| hansfbaier | Error: Read failed | 10:16 |
| hansfbaier | (I disabled the AT24 driver in the dts first) | 10:16 |
| hansfbaier | mor1kx-problem?!?! | 10:17 |
| hansfbaier | I had caches all disabled on my ep4ce10 | 10:17 |
| hansfbaier | anyway, enough for today..... | 10:18 |
| hansfbaier | need some diversion... | 10:18 |
| stekern | dunno, I can read and write over i2c fine with mor1kx with caches enabled to the ssm2603 at least | 10:19 |
| olofk_ | I'm going crazy over the stupid fucking undocumented piece of shit Xilinx tools | 10:21 |
| hansfbaier | olofk_: Why bother using Xilinx? | 10:22 |
| olofk_ | hansfbaier: I swing both ways | 10:22 |
| olofk_ | Finally! | 10:23 |
| hansfbaier | olofk_: I have a spartan XC3S500E here, with cable. I started on it. But switched to Altera soon. One plus has Xilinx, ISE is more intuitive to use. It's dirt simple to fire up a simulation of a tb in iSim. On Altera, you've got to take a seminar or so. | 10:25 |
| olofk_ | After descending into the darker parts of internet, I found out that Xilinx tcl engine uses | as path separator | 10:26 |
| olofk_ | hansfbaier: Isim is the worst piece of crap I have ever used | 10:26 |
| hansfbaier | olofk: I didn't do much with it, but i found it pretty simple to use | 10:27 |
| olofk_ | Doesn't support VPI, and the crippled version they give away with webpack is so incredible slow that it took me a while to find out it was actually running a simulator | 10:27 |
| olofk_ | s/simulator/simulation | 10:27 |
| hansfbaier | olofk: It was fine fora 64 cells CPLD though ;) | 10:27 |
| olofk_ | I had support for it in my first version of orpsocv3, but there is no fucking way I'll rewrite the code for that again | 10:27 |
| olofk_ | :) | 10:27 |
| hansfbaier | anyway, got to get some rest before the kids wake up... | 10:28 |
| hansfbaier | bye | 10:28 |
| hansfbaier | thanks a lot | 10:28 |
| nvmind | hello all | 10:29 |
| nvmind | what is the status of mor1kx? | 10:30 |
| nvmind | is it already usable? | 10:30 |
| stekern | yes | 10:30 |
| nvmind | I was wondering if it is smaller/faster than or1200 | 10:31 |
| stekern | yes | 10:31 |
| nvmind | both? | 10:31 |
| nvmind | :) | 10:31 |
| stekern | yes | 10:32 |
| stekern | ;) | 10:32 |
| nvmind | are you working on it? | 10:32 |
| stekern | yes | 10:32 |
| * nvmind is thinking to another yes/no question. | 10:33 | |
| stekern | my up-arrow and enter button is experiencing some serious wear-out here ;) | 10:33 |
| nvmind | can I use adv_debug_sys with it? | 10:34 |
| nvmind | :) | 10:34 |
| stekern | up-up enter | 10:34 |
| nvmind | yes :) | 10:34 |
| nvmind | I am considering to replace or1200 | 10:35 |
| nvmind | for two main reason | 10:35 |
| nvmind | 1) it is area hungry ;) | 10:36 |
| stekern | so, with all the whistle and bells, it might be about the same size as or1200, but with the same setup as a fullblown or1200 without FPU, it should be at least a bit smaller | 10:36 |
| stekern | that's the cappuccino, that goes for maximum performance | 10:37 |
| nvmind | 10) I can't make it go faster than 60Mhz on a de1 and the critical path is inside the cpu | 10:37 |
| stekern | then there's the smaller guys, (pronto)espresso, they should be a lot smaller, but lacks cache and mmu | 10:37 |
| stekern | I've got it running at ~90 MHz on orpsocv2 de0_nano | 10:39 |
| nvmind | I don't need cache and mmu at the moment | 10:39 |
| nvmind | and I like the deeper pipeline | 10:39 |
| stekern | with mmu's disabled (there's a critical path through those) | 10:39 |
| stekern | and 75MHz with mmus enabled | 10:39 |
| nvmind | is it designed for ASIC or only for FPGA? | 10:40 |
| stekern | but it's really at IPC where mor1kx cappuccino runs circles around or1200 | 10:40 |
| stekern | especially if mmus are enabled | 10:41 |
| stekern | it's designed to fit both, juliusb have synthesized the espressos with asic tools | 10:42 |
| nvmind | well I am asking this because in or1200 I have found things that were described in a more ASIC oriented way ;) | 10:44 |
| nvmind | and there was also something that was stopping the retiming algorithm of quartus | 10:44 |
| olofk_ | stekern: I'm not sure anyone running around in circles at International Paralympic Committee? | 10:45 |
| stekern | haha | 10:45 |
| nvmind | ahuahua | 10:45 |
| stekern | it's para lympics anyway | 10:45 |
| olofk_ | :) | 10:46 |
| rokka | did someone say something to me.. my buffer is too small :l? | 10:53 |
| olofk_ | rokka: Yes, I did | 10:53 |
| olofk_ | But I forgot the questions | 10:53 |
| olofk_ | oh.. right. Now I remember | 10:53 |
| olofk_ | You asked where to add the statements to the TCL file, right? | 10:54 |
| rokka | yes | 10:54 |
| rokka | where is the tcl file | 10:54 |
| olofk_ | Which build system are you using? orpsocv2, orpsocv3 or something else? | 10:54 |
| rokka | i have custom project in quartus | 10:54 |
| olofk_ | hmm.. you should be able to set it somewhere in the menus, but IIRC it was almost impossible to find | 10:55 |
| olofk_ | Try to add it directly in your quartus project file | 10:55 |
| olofk_ | I think that's the qpf file | 10:55 |
| rokka | can you tell the line too.. :D its also lost in buffer | 10:56 |
| rokka | should really set bigger buffer to irssi | 10:56 |
| olofk_ | set_global_assignment -name GENERATE_SVF_FILE ON | 10:56 |
| * olofk_ too | 10:56 | |
| olofk_ | I'm really not sure here, but I think that you can add TCL commands directly to the qpf file | 10:57 |
| rokka | i can try | 10:57 |
| olofk_ | Or maybe you can put it in a new tcl file and somehow tell quartus to include that file | 10:57 |
| rokka | btw. when i run "jtag file.jtag" its only active until i reboot | 10:58 |
| rokka | how can i set it in spi-flash to automatically run | 10:59 |
| rokka | after power up | 10:59 |
| olofk_ | Hmm.. LoneTech is the guy to ask for this | 10:59 |
| olofk_ | It was an ordb2a you were using, right? | 10:59 |
| rokka | yes this http://opencores.org/shop,item,11 | 11:00 |
| olofk_ | are you using quartus_sh or the GUI when you build the project? | 11:00 |
| rokka | gui | 11:00 |
| olofk_ | ah ok. Never really used the GUI, so I don't know how to add extra TCL files | 11:00 |
| rokka | is it easy to build from shell? i am using windows | 11:01 |
| olofk_ | Haven't tried in windows | 11:04 |
| olofk_ | But if you are using the GUI, it might be easiest to just look for that option in the menus. I haven't got a clue where to find it, but I know it should be there somewhere | 11:04 |
| stekern | you can add it manually to the .qsf | 11:05 |
| stekern | but I think it's best to first quit quartus before editing that file manually | 11:05 |
| olofk_ | aha.. it's the qsf. Haven't learned all the Altera format extensions yet | 11:05 |
| olofk_ | stekern: Is that a TCL file? | 11:05 |
| stekern | because otherwise quartus might overwrite what you changed | 11:06 |
| rokka | yes.. adding to .qsf did work.. .qpf did not :) | 11:06 |
| stekern | olofk_: tclish | 11:07 |
| rokka | thanks to both of you :) | 11:07 |
| stekern | i don't now if you can have anything else than pure set_xxxxx in it | 11:07 |
| rokka | so writing to spi flash requires that something special is running on the fpga? | 11:08 |
| rokka | can someone tell how LGPL work with FPGA | 11:09 |
| rokka | i have many questions x) | 11:09 |
| olofk_ | rokka: It's not completely clear how LGPL works, but everyone I have been talking to that has released HDL code under LGPL _wants_ it to be interpreted as "Use this core in any project. You don't have to release any other source code, but if you make changes to this core, we want to see what you did" | 11:11 |
| rokka | de facto | 11:15 |
| _franck_ | rokka: "Device and Pin Options" --> Programming Files --> then check (.svf) | 11:16 |
| rokka | so nobody is suing somebody to release .vhdl or .v files if using their lgpl core | 11:17 |
| stekern | _franck_, the GUI master ;) | 11:17 |
| _franck_ | :) | 11:17 |
| rokka | _franck_: ah.. thanks :) | 11:18 |
| olofk_ | I told you it was impossible to find :) | 11:18 |
| * stekern hates checkboxes | 11:18 | |
| olofk_ | rokka: No, that has not happened, and I find it hard to believe that anyone would sue | 11:18 |
| _franck_ | come one, GUI is not that bad | 11:18 |
| olofk_ | _franck_: I actually use GUI sometimes too. gtk-emacs for example | 11:19 |
| olofk_ | and xterm | 11:19 |
| stekern | me too, gtkwave | 11:19 |
| stekern | and gitk | 11:19 |
| olofk_ | oh.. and I'm using IRC through a browser right now :( | 11:19 |
| olofk_ | in windows :( :( | 11:20 |
| olofk_ | at work :( :( :( | 11:20 |
| stekern | and wireshark | 11:20 |
| stekern | I actually use the quartus gui sometimes too | 11:21 |
| stekern | because there are projects setup by others without makefiles | 11:21 |
| olofk_ | And FastTracker II :) | 11:21 |
| stekern | ...or orpsocs | 11:21 |
| stekern | yes, fasttracker II | 11:21 |
| rokka | my project is ecu for gasoline engines with fpga :D and i use orsoc board as hw | 11:21 |
| stekern | it was a while ago though | 11:22 |
| stekern | I think I used that in 2004 last | 11:22 |
| stekern | I spent the last week at university crashing at a friends couch and he lent me a PC with dos only installed | 11:23 |
| rokka | do you know any general purpose fpga irc channels | 11:23 |
| _franck_ | #fpga I guess :) | 11:24 |
| rokka | not on freenode? | 11:25 |
| stekern | this was the result: http://oompa.chokladfabriken.org/whizkid/whizkid_-_chipsmoddadstek.mp3 | 11:25 |
| _franck_ | it's ##fpga | 11:26 |
| stekern | what's up with the double #? | 11:27 |
| stekern | twice as trendy with extra hashtags.. | 11:28 |
| rokka | :D ok thanks | 11:28 |
| olofk_ | It's more secure if you double hash it ;) | 11:29 |
| stekern | but I actually used scream tracker more when I took my first tracker steps | 11:31 |
| rokka | do you have any interesting projects that use openrisc ?:) | 11:37 |
| stekern | I'm finally working on a synth that uses openrisc as a 'controller' | 11:40 |
| stekern | that's interesting to me at least ;) | 11:40 |
| rokka | cool | 11:40 |
| rokka | musical project | 11:41 |
| rokka | what does it control? | 11:42 |
| rokka | software -> os -> openrisc -> custom cores? | 11:43 |
| olofk_ | I'm working on an OpenRISC powered selective Death Ray that only kills children, women, puppies and kittens | 11:44 |
| stekern | not sockittens I hope? | 11:44 |
| rokka | :D | 11:44 |
| olofk_ | stekern: The only way to protect yourself is to lock it into your garage | 11:45 |
| stekern | rokka: the synth core itself has a wb interface, so the openrisc core runs everything that doesn't need to be 'hw accelerated' | 11:45 |
| stekern | ... or that's the plan, it's not finished | 11:45 |
| stekern | olofk_: ok, but it's in my 'mancave' in the basement, does that count? | 11:46 |
| stekern | I don't know if I'm allowed to call it a 'mancave' though, since it's extensively used to watch my little pony... | 11:48 |
| rokka | :D | 11:48 |
| rokka | stekern: had to google the wb.. :) | 11:49 |
| rah | http://myrtle.settrans.net/~rah/about.txt | 11:50 |
| rah | ^^ I'd be very interested in any feedback on this document | 11:50 |
| stekern | http://memerial.net/5804-welcome-to-virginity-guide <- me | 11:50 |
| stekern | rokka: heh, sorry, wishbone | 11:51 |
| rah | particularly about the section on chip manufacturing and FPGAs but obviously any other feedback is welcome | 11:51 |
| rokka | stekern: yesh.. i found it :) | 11:51 |
| rokka | stekern, lol :D | 11:53 |
| stekern | rah: I'm not saying you are wrong, but what differs from a (complex) free PCB design and a free chip design, apart from the price to manufacture | 11:54 |
| stekern | theoretically | 11:54 |
| stekern | in terms of freedom, I mean | 11:54 |
| rah | stekern: speaking only of ASICs, price is the only issue | 11:54 |
| rah | stekern: the price of manufacturing ASICs is prohibitively expensive | 11:55 |
| stekern | but the freedom of the actual design doesn't differ | 11:55 |
| stekern | just some food for though | 11:55 |
| stekern | t | 11:55 |
| rah | I see | 11:56 |
| rah | well, yes, of course there's no difference in the freedom of the design | 11:56 |
| rah | the difference is in the freedom of the computer user | 11:56 |
| rah | you can't be a computer user of a free design that can't be manufactured | 11:57 |
| stekern | there's of course a practical difference, the average hacker can't take the chip design and send it to an ASIC manufacturer, since he probably doesn't have the funds for it, but he can send a PCB design to some PCB manufacturer | 11:58 |
| rah | yes that's the point | 11:58 |
| stekern | you can run it on FPGAs though | 11:58 |
| rah | right, but they're all proprietary | 11:58 |
| rah | I can run an OpenRISC core on a machine that I don't have the design to and which I have to use proprietary Win32 software to program :-) | 11:59 |
| rokka | you just need energy-matter converter from star trek | 11:59 |
| rah | rokka: damn, why didn't I think of that? :-) | 11:59 |
| stekern | you don't need windows programs | 12:00 |
| rah | I thought I needed Win32 software to generate images which can then be flashed using Linux software? | 12:00 |
| stekern | but the PCB manufacture is (most likely) done in china somewhere, where you don't have any insight in their manufacturer process neither | 12:00 |
| rokka | fpga tools exist to linux too | 12:00 |
| stekern | rah: no, you can use the software under linux | 12:01 |
| stekern | it's just that the software isn't free/opensource | 12:01 |
| rah | stekern: but is it Win32 software running under Wine? | 12:01 |
| rokka | native | 12:01 |
| stekern | rah: no, native linux | 12:01 |
| rah | hmm ok | 12:01 |
| rah | that's good to hear | 12:01 |
| rah | stekern: I'm a little concerned that you came back with objections that I thought I had covered in the text | 12:02 |
| rah | stekern: for example, the text says "It is also impractical for enthusiasts to produce free hardware chips because of the enormous costs of manufacturing silicon designs." | 12:03 |
| rah | stekern: and later "While it is not yet practical to create free chips, it is possible to create free motherboards." | 12:03 |
| rah | stekern: is this because the text isn't clear enough? | 12:03 |
| stekern | rah: as I said, I think your main point is valid, there's a practical price point | 12:03 |
| stekern | it was the latter that I reacted on, the use of the word "free", why is the motherboard more free than the chip? | 12:04 |
| rokka | projects like kickstarter coult make it possible to collect enough funds for making asics | 12:05 |
| rokka | could.. :D | 12:05 |
| stekern | I think the free designs are more interesting than what they go into, that's my only point | 12:06 |
| rah | stekern: I see | 12:22 |
| olofk_ | I'm not sure that openrisc.net should be listed as the source for OpenRISC. That's mainly the linux port that is hosted there | 12:22 |
| rah | ah ok | 12:23 |
| rah | I had listed opencores and openrisc on the same line with a url of opencores.org | 12:23 |
| rah | what *should* the url be for openrisc? | 12:23 |
| stekern | the frontpage for the project is opencores.org/or1k | 12:24 |
| rah | ok I'll use that thanks | 12:27 |
| olofk_ | rah: I liked that you have a section that explains "The Internet". I have always wondered what that was ;) | 12:28 |
| stekern | because what is the freedom in "free chip"? the freedom only exists when you can change it, when it's taped out on an ASIC, it's kind of per definition not a "free chip" | 12:28 |
| stekern | the design behind it is | 12:28 |
| rah | olofk_: I'm glad I could help ;-) | 12:29 |
| rah | stekern: yes, the issues of freedom in the hardware arena are much more complex than in software | 12:29 |
| stekern | rah: I agree, and the same logic can be applied to PCBs | 12:30 |
| olofk_ | stekern: To be honest, it's basically the same thing with a PCB or a software binary | 12:30 |
| rah | stekern: I'm focussing on "free hardware", meaning actual objects whose *design* is free | 12:30 |
| stekern | that's why I'm mostly interested in open source/free hardware *designs* | 12:30 |
| rah | stekern: right, so a free computer would mean a computer consisting of PCBs whose designs are available, populated by chips whose designs are available and electrically connected using resistors and capacitors whose designs are available | 12:31 |
| rah | s/available/freely licensed/ | 12:31 |
| olofk_ | I'm more into creative design | 12:31 |
| _franck_ | rah: that will never happen | 12:31 |
| rah | _franck_: you can't know that | 12:31 |
| olofk_ | I find it unbelievable that today's computers has come from evolution. There must be a higher power that designed them | 12:32 |
| olofk_ | oh..I mean intelligent design | 12:32 |
| _franck_ | you'll always have an IC that is not open source unless you want to make 10 ASIC for your computer | 12:33 |
| rah | _franck_: I want 1000s of ASIC designs | 12:33 |
| rah | for 1000s of different kinds of chips | 12:33 |
| _franck_ | ok great :) | 12:33 |
| _franck_ | but you can prototype digital chips with FPGA but what about analog ? Let's say a gigabit PHY ? | 12:35 |
| _franck_ | there will be no fun, so no contributors | 12:35 |
| rah | maybe "fun" isn't the only motivation | 12:35 |
| rah | maybe some people would find it fun | 12:35 |
| rah | but at the most basic, if it's possible to create a PHY design that is proprietary and restricted, it's possible to create a PHY design that is free | 12:36 |
| _franck_ | of course it's possible... | 12:37 |
| _franck_ | you could buid a free space ship as well ;) | 12:38 |
| rah | hell yes | 12:38 |
| rah | free hardware space ship | 12:38 |
| rah | we'll do that after we've made our free desktop computer :-) | 12:38 |
| rah | not much difference.. ;-) | 12:38 |
| rah | _franck_: I'm not a fool, I understand that these goals involve subverting the modus operandi of an entire industry that requires vast resources for R&D | 12:46 |
| rah | _franck_: but that doesn't mean that working towards the goal, and helping where possible, isn't of value | 12:46 |
| stekern | i completely agree with that | 13:06 |
| stekern | but, the r&d costs aren't really the issue, it's the manufacture cost | 13:06 |
| stekern | and I agree, what people find fun is highly individual, I bet there are people that enjoy designing phys | 13:08 |
| _franck_ | of course designing phys can be fun. However, if you know you'll never get your design into a chip that might be frustrating | 13:17 |
| rah | there's no way to know whether your design will or won't get into a chip | 13:19 |
| rah | community-developed IC designs have already been manufactured into ASICs | 13:20 |
| rah | an or1k core is included in the Allwinner A31 | 13:20 |
| rah | who's to say that if someone decided to create a PHY design, some other chip startup won't make use of their design | 13:21 |
| rah | s/a PHY design/a free PHY design/ | 13:21 |
| stekern | yeah, and I think that's the most likely way to get "free chips" | 13:25 |
| rah | I agree | 13:26 |
| rah | at least for the foreseeable future | 13:26 |
| stekern | do good designs that people with the funds want to use | 13:26 |
| rah | right | 13:27 |
| _franck_ | well, I don't know how analog ASICs are prototyped but I don't think you go straight from simu to manufacturing | 13:29 |
| stekern | the analog asic I did back in the university went straight from simu to chip | 13:41 |
| stekern | but that was pretty simple, just a bipolar transistor | 13:41 |
| rah | stekern: your university had the facility to manufacture ASICs? | 13:42 |
| stekern | they had/have a cleanroom, yes | 13:43 |
| rah | O_o | 13:44 |
| rah | cool | 13:45 |
| rah | suddenly freely licensed, well developed analog designs don't seem so difficult | 13:45 |
| stekern | http://oompa.chokladfabriken.org/foton/Rrfoto/dscf0076.jpg | 13:50 |
| stekern | ovens | 13:50 |
| stekern | http://oompa.chokladfabriken.org/foton/Rrfoto/dscf0093.jpg | 13:51 |
| stekern | yours truly: http://oompa.chokladfabriken.org/foton/Rrfoto/dscf0092.jpg | 13:52 |
| rah | geek! :-) | 13:52 |
| rah | that's cool | 13:53 |
| rah | I suppose though that if you're going to do fundamental research into IC science, you would need to be able to create your own ICs | 13:53 |
| _franck_ | stekern: you had glasses at that time ? | 13:54 |
| stekern | that's eleven years ago, I look much cooler now, I promise! | 13:54 |
| stekern | especially without that suite... | 13:54 |
| stekern | _franck_: I still wear glasses, when I don't use contact lenses | 13:54 |
| rah | heh | 13:54 |
| stekern | _franck_: http://opencores.org/or1k/File:IMG_1009.JPG | 13:57 |
| _franck_ | I didn't pay attention to that :) I used to wear glasses before I had an eye surgery | 13:59 |
| stekern | I should do that too... | 14:11 |
| stekern | just have to find the time, money and courage | 14:11 |
| * rah eyes the careers page of the Embecosm website | 14:33 | |
| * rah ponders | 14:33 | |
| nvmind | when mor1k jumps to 0x700 is a tbl miss right? | 17:06 |
| nvmind | mmm it seems that it tries to fetch 0x700 after a branch exception. | 17:10 |
| poke53281 | 0x700 is an illegal instruction | 17:12 |
| poke53281 | 0x900 is an data TLB miss and 0xA00 is an instruction TLB miss | 17:13 |
| nvmind | it seems that this is the instruction causing the fault -> l.movhi r1, RAM_LOAD_BASE | 17:14 |
| nvmind | that the assembler translate as: | 17:15 |
| poke53281 | But this is a very often used valid instruction. | 17:15 |
| nvmind | 32'h6469722b | 17:16 |
| nvmind | :) | 17:16 |
| nvmind | well I now :) | 17:16 |
| nvmind | this is part of a rom that normally boots with or1200 | 17:16 |
| nvmind | mmm | 17:19 |
| nvmind | has mor1kx a differnt instruction encoding from or1200?? | 17:20 |
| poke53281 | I don't know. I can tell you everything aboult emulation OpenRISC, but nothing about real hardware. | 17:21 |
| stekern | nvmind: no, it has the the same instruction encoding | 17:23 |
| nvmind | well... what the hell I did wrong :) | 17:24 |
| stekern | hmm, rom you say... that shouldn't be much room for error from that | 17:29 |
| stekern | s/that/there | 17:30 |
| stekern | where does the branch go? | 17:30 |
| stekern | or are you just calling the exception a "branch exception"? | 17:31 |
| stekern | is this in simulation? can you provide a vcd? | 17:31 |
| nvmind | stekern: yes I can provide a vcd | 17:34 |
| nvmind | stekern: ctrl_branch_exception_o becomes 1 and then mor1k starts fetching at 0x700 | 17:37 |
| nvmind | stekern: but the first two instruction of the rom are l.movhi r0, 0 | 17:38 |
| nvmind | l.movhi r1, RAM_LOAD_BASE | 17:38 |
| nvmind | 17:38 | |
| nvmind | then that signal becomes 1. | 17:38 |
| stekern | ok, I'd be interested in seeing the vcd | 17:43 |
| nvmind | it's 3Mb | 17:43 |
| nvmind | I can send it by email | 17:44 |
| stekern | sure, stefan.kristiansson@saunalahti.fi | 17:44 |
| stekern | dropbox usually works well otherwise | 17:44 |
| nvmind | I don't have a dropbox account | 17:45 |
| stekern | but e-mail is fine by me | 17:45 |
| nvmind | stekern: sent, but I noticed that the signal is ctrl_except_illegal | 17:52 |
| nvmind | maybe I followed the wrong line | 17:53 |
| nvmind | sorry | 17:53 |
| stekern | oh, that's of less importance | 18:04 |
| stekern | it will cause the ctrl_branch_exception_o to assert | 18:04 |
| stekern | mail safely arrived | 18:07 |
| stekern | nvmind: umm, do you have a disasm of your program? | 18:13 |
| stekern | the ROM I mean | 18:13 |
| stekern | l.movhi r0, 0 should be 0x18000000 | 18:15 |
| stekern | not 0x2b696e63 | 18:15 |
| stekern | at what address should the ROM start at? is 0x9f000000 correct? | 18:15 |
| nvmind | stekern: correct | 18:24 |
| nvmind | stekern: It is an assembly program that gets converted in a rom | 18:25 |
| nvmind | stekern: I think the ball is in my court... | 18:30 |
| nvmind | stekern: solved. Sorry I did a stupid thing with my build system and that broke the generation of the rom. | 18:49 |
| stekern | ah, good that it got sorted out ;) | 18:54 |
| --- Log closed Wed Oct 23 00:00:52 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
