| --- Log opened Thu Jul 28 00:00:59 2016 | ||
| stekern | olofk: the musl branch has some musl specific patches applied | 00:55 |
|---|---|---|
| olofk | stekern: Do you remember what kind of patches? Should those be enabled for the other toolchains as well? | 01:19 |
| olofk | Oh no! Octopussy is falling down a canyon when I try to reach the openrisc repos! | 01:20 |
| olofk | I knew that we should have mirrored everything to opencores :) | 01:22 |
| stekern | it does the same when I try to log in | 01:22 |
| stekern | https://github.com/openrisc/or1k-gcc/commit/3665cefa2c4256782ac9456bee6f8330f690519e | 01:23 |
| stekern | https://github.com/openrisc/or1k-gcc/commit/dfad8a2635433704c74c70db28c3559867c2e362 | 01:23 |
| olofk | Got seriously impressed by this little thing https://www.kickstarter.com/projects/onion/omega2-5-iot-computer-with-wi-fi-powered-by-linux | 01:40 |
| olofk | stekern: Hmm.. shouldn't those really be upstreamed? | 01:42 |
| olofk | At least the first one | 01:42 |
| stekern | olofk: they might be (or part of them) already, haven't kept track lately | 01:43 |
| wallento | If they were upstream, that patch would be empty, or not? | 01:45 |
| stekern | yes, but that branch is from march | 02:06 |
| stekern | https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=8827dc830d374c2512be5713d6dd143913f53c7d;hb=5312a3afadcb738fc64e8b3927b7144462c23cb3#l585 | 02:06 |
| stekern | olofk: (omega2) yes, that looks pretty cool | 03:45 |
| stekern | especially at that price point | 03:45 |
| ssvb | does something like this look like a good FPGA board for trying to synthesize OpenRISC in a 'microcontroller' configuration? www.aliexpress.com/item/EP4CE10-altera-fpga-board-fpga-development-board-fpga-altera-board-fpga-development-board/32637947021.html | 11:41 |
| kc5tja | Cannot view link; it asks for username and password instead. | 13:24 |
| ssvb | hmm, does it? there is a 'http://' prefix missing, but other than this everything should be fine | 13:32 |
| ssvb | but anyway, it's an Altera Cyclone IV FPGA (10K LE) soldered on a board, which only has a few LEDs/buttons and exposes all pins on the expansion headers | 13:34 |
| kc5tja | Yeah, it redirects for me, with or without http:// or https://. I think AliExpress is busted. :/ | 13:35 |
| ssvb | is it realistic to combine an OpenRISC core with just UART peripheral and nothing else, put some code in ROM and use a bit of SRAM for data? | 13:37 |
| kc5tja | That's the simplest possible computer configuration, I'd say. I would be very surprised if that combination did not fit on a 10K LE device. | 13:38 |
| kc5tja | I imagine the availability of block RAMs on the FPGA will be your limiting factor, and not so much the logic element count. | 13:38 |
| kc5tja | Disclaimer: I don't know much about OpenRISC, but I'm guessing based on my experience with RISC-V cores. I doubt they differ that much in implementation complexity. | 13:39 |
| ssvb | here is a basic summary information about this FPGA chip - https://www.arrow.com/en/products/ep4ce10e22c8n/altera (hopefully it is accessible) | 13:41 |
| ssvb | it is supposed to have 414 Kbits of embedded memory | 13:43 |
| ssvb | what would be the recommended lowest cost FPGA board in general? | 13:44 |
| kc5tja | That's close to 51KB of memory, so assuming 16KB will be used by the register file, that gives you 16KB to use to emulate ROM, 16KB for RAM, and apporximately 4KB left over if you need it. | 13:47 |
| kc5tja | However, I haven't found out how Altera's chips organize block RAMs. I'm going on the assumption that each block RAM macro instantiates 16Kb (bits) of memory, and you'll need multiple of those to implement a 32-bit register file. | 13:47 |
| kc5tja | I don't know what the lowest cost board is. I'd wager somewhere in the vicinity of $30 is pretty good; I think that's close to the cheapest I've personally seen. | 13:48 |
| ssvb | would such amount of memory be enough to run CoreMark? :) | 13:49 |
| kc5tja | These are typically just break-out boards though. No built-in RAM or ROM, no video, PS/2, or other ports. But they do have power supply and programming facilities. | 13:49 |
| kc5tja | I don't know anything about CoreMark, sorry. | 13:50 |
| ssvb | yes, it's exactly one of such boards that is sold on aliexpress | 13:50 |
| ssvb | how does one usually benchmark the soft CPU cores? | 13:50 |
| kc5tja | Personally, I don't bother. | 13:51 |
| kc5tja | Porting a benchmark has typically required floating point support, and I have no interest in supporting floating point. | 13:51 |
| kc5tja | It also typically requires an operating system, which is something I've never succeeded in completing. | 13:51 |
| kc5tja | Even Oberon System, arguably one of the simplest OSes in existence, has so far stumped me. | 13:52 |
| kc5tja | (though, at least I know what needs to be done; it's just the amount of work involved is not enticing to me.) | 13:52 |
| ssvb | I'm currently trying to compile and run CoreMark on the OpenRISC core in Allwinner H3 | 13:53 |
| ssvb | it does not need any special OS and only needs some sort of a timer and printf implementation, which can use UART for output | 13:54 |
| kc5tja | Doesn't that have an ARM core? | 13:54 |
| ssvb | but it does not seem to work correctly fore me yet | 13:54 |
| kc5tja | I just looked, and CoreMark needs me to create an account with them just to download the sources. That's another reason why I don't care about benchmarks. | 13:55 |
| ssvb | yes, the primary CPU in Allwinner H3 is a quad-core ARM, but it also has a supplementary OpenRISC core | 13:56 |
| kc5tja | It's like, "You need to register with the EU to measure length in meters." | 13:56 |
| kc5tja | Oooh, I didn't know about that. That's pretty neat. | 13:56 |
| ssvb | well, I don't see a big problem with just creating an account for CoreMark and supplying them with my e-mail | 13:57 |
| ssvb | one does not need to pay anything | 13:57 |
| kc5tja | That's good. | 13:57 |
| kc5tja | Does it need floating point support though? | 13:58 |
| kc5tja | (or, at least, can floating point benchmarks be skipped if we want?) | 13:58 |
| kc5tja | Meeting. brb | 13:59 |
| ZipCPU|Laptop | kc5tja: ssvb: I've been using Dhrystone as a benchmark. It's not perfect, but it's drawbacks are all well known. | 14:05 |
| ZipCPU|Laptop | You may also find the "Inventory of soft processor cores" on OpenCores to be valuable. The author tries very hard to evaluate multiple | 14:07 |
| ZipCPU|Laptop | cores against a series of benchmarks--not necessarily performance per se, but benchmarks nonetheless. | 14:08 |
| ssvb | ZipCPU: CoreMark claims to be better than Dhrystone according to its FAQ - http://www.eembc.org/coremark/faq.php | 14:22 |
| ZipCPU|Laptop | That shouldn't be too hard. | 14:22 |
| ssvb | it also offers some kind of correctness validation, which currently fails for me on Allwinner H3 | 14:23 |
| ZipCPU|Laptop | Although, I would agree with kc5tja about not wanting to register in order to measure length in meters. | 14:23 |
| ssvb | that's why I wondered if it was my mistake when porting CoreMark, a toolchain problem or there might be something wrong in the processor | 14:24 |
| ZipCPU|Laptop | I once broke Dhrystone. Ever since then, my CPU hasn't done as well ... :rofl: | 14:25 |
| ssvb | as a toolchain test, I tried to use the pixman test suite because it had a history of exposing compiler bugs on various platforms | 14:25 |
| ZipCPU|Laptop | I may need to look that one up. Will I need to register for that one as well? | 14:26 |
| ssvb | nope, pixman is just an open source project I have been contributing to :) | 14:27 |
| ssvb | it is even not a benchmark | 14:27 |
| ZipCPU|Laptop | Is it just a good compiler testing test-suite? | 14:27 |
| ssvb | it did detect some compiler bugs in the past, but its primary purpose is just testing correctness of the pixman library | 14:29 |
| ssvb | well, and it needs Linux, that's why it is only usable with a musl based toolchain | 14:30 |
| kc5tja | Huh, ao68000 uses <5000 LUTs. That's pretty impressive. | 14:31 |
| ssvb | so far the correctness of code generation in the OpenRISC toolchain seems to be kinda OK, but qemu and jor1k are not perfect and we discussed it with olofk and poke53281 the other day | 14:31 |
| kc5tja | ZipCPU|Laptop: re: breaking Dhrystone -- hehehe. | 14:33 |
| ZipCPU|Laptop | Yup. | 14:33 |
| kc5tja | I tend to estimate performance of a processor based on how quickly it can move data from input to output. | 14:33 |
| kc5tja | For example, the reason I settled on a 6 MIPS minimum performance figure for the Kestrel-3's CPU is: | 14:33 |
| kc5tja | (deep breath) | 14:33 |
| ssvb | heh, I only wanted to run CoreMark on the OpenRISC core in Allwinner H3 and publish some results, but looks like I may be dragged in a bunch of other activities involving qemu and other things... :) | 14:34 |
| kc5tja | 1. The Commodore 64 takes about 1 second to fill a 320x200 bitmapped, monochrome image. This is at a clock speed of 1MHz, average 4 clocks per instruction. (Some instructions take 2, 3, or 5; when I averaged the loop, it came to 4 CPI average). | 14:34 |
| kc5tja | 2. A 640x480 screen is about 5x as much data as a 320x200 screen. | 14:35 |
| kc5tja | 3. Therefore, I want something around 5 MIPS minimum. But since 5 is not a nice, power-of-two divisor of 25MHz used for VGA dot-clock, 6 MIPS (25 divided by 4, a power of 2) it was. | 14:36 |
| ZipCPU|Laptop | kc5tja: Say when you're done ... I've got a question ... | 14:36 |
| kc5tja | The idea being, if I used byte-stores to fill a bitmapped screen, it should take about the same amount of time as a Commodore 64 to do the same with its screen. | 14:36 |
| kc5tja | Done. | 14:36 |
| ZipCPU|Laptop | Thanks! When you say "fill a ... image", how much CPU power is getting applied to each pixel? | 14:37 |
| kc5tja | LDA #$00 // loop: STA (ptr),Y // INX // BNE loop // INC ptr+1 // BNE loop <-- thats the reference loop. | 14:38 |
| kc5tja | That simple loop will take about one second to fill 8KB of memory at 1MHz. | 14:38 |
| ZipCPU|Laptop | So ... we're measuring the cost of filling the screen with a constant color? | 14:38 |
| kc5tja | You can unroll the loop for (MUCH!) faster performance, but that's my reference. | 14:39 |
| kc5tja | Correct. | 14:39 |
| kc5tja | Copying from one frame buffer to another would be the next least expensive operation, but I chose this because it was easy to quantify and I can measure everything else relative to this. | 14:39 |
| ZipCPU|Laptop | Gosh ... my DMA routine can do that in roughly two clocks per pixel at 80MHz. Why only 6 MIPS? Why only one screen per second? | 14:40 |
| kc5tja | RAM takes 70ns to access, so the bus is limited to 14 mega-transfers per second (MT/s). | 14:40 |
| kc5tja | The next closest VGA timing is 12.5 MT/s. | 14:41 |
| kc5tja | It's 16-bits wide, which allows me 25MB/s, allowing for a 640x480 256-color display. | 14:41 |
| kc5tja | However, b/c the bus is 16-bits wide, I need two clock cycles to fetch a 32-bit instruction. | 14:41 |
| kc5tja | Thus, 6 MIPS. | 14:41 |
| kc5tja | 6.25 technically. | 14:41 |
| kc5tja | The CPU core is clocked at 25MHz, which means each instruction takes four clock cycles minimum. | 14:41 |
| kc5tja | (and in fact, all the instructions that really matter are 4 cycles long) | 14:42 |
| kc5tja | Loads and stores take 6 (byte and halfword), 8 (word), and 14 (double-word) cycles respectively. | 14:42 |
| kc5tja | ...correction. "I need two clock cycles" --> "I need two memory cycles". | 14:43 |
| kc5tja | So, 2 clock cycles per memory cycle, 2 memory cycles per 32-bit fetch. | 14:44 |
| ZipCPU|Laptop | So, here may be one difference ... all of the RAM controllers I've written allow pipelined accesses. In one SDRAM controller, I support one 32-bit transfer every 25ns. Without the pipelined mode, it may take as long as 150ns. | 14:44 |
| ZipCPU|Laptop | Put together, the cost is 125+25N ns, where N is the number of 32-bit words that are pipelined together. | 14:45 |
| kc5tja | Yes, but you also need a cache to use it at those rates. I have a deadline of this november for hardware I want to demo. I'm late as it is getting a CPU written. A cache controller will take me another 6 months to a year at least. | 14:45 |
| ZipCPU|Laptop | No. Those are not cached rates. | 14:45 |
| ZipCPU|Laptop | The rates are the same regardless of whether or not the cache is in use. | 14:46 |
| kc5tja | That's the rate that the RAM delivers data. But the CPU doesn't incur a 150-cycle overhead on every memory hit. You're using a cache of some kind somewhere. | 14:46 |
| kc5tja | 150-ns rather. | 14:47 |
| kc5tja | But, even here, 150ns for a single-beat transfer is 2x slower than 70ns for asynchronous RAM. | 14:47 |
| ZipCPU|Laptop | No, the 150 cycle hit is not a cache hit. First, the clock is at 12.5ns, so we're talking 12 clocks to get to a data word. Many of those clocks are consumed by the SDRAM, although some are consumed with just getting to the bus from the CPU. | 14:47 |
| kc5tja | That's why SDRAM only pays out when you use it in conjunction with a cache, to amortize the 150ns hit. | 14:47 |
| ZipCPU|Laptop | Yeah ... I just haven't built the data cache controller yet. What was it you were saying about trying to get things done quickly? | 14:48 |
| ZipCPU|Laptop | (Correction to the above: it wasn't a 150 cycle hit, but a 150ns hit. That's 12 cycles at an 80MHz clock.) | 14:49 |
| kc5tja | ;) | 14:54 |
| kc5tja | Grabbing lunch. Back in a few. | 14:55 |
| olofk | ssvb: I would generally recommend de0 nano as a cheap board for OpenRISC development. It's very well supported by the community at has enough power to run Linux without problems | 15:04 |
| olofk | ssvb: But you're correct in that you only need the CPU+UART+a small on-chip memory | 15:04 |
| ZipCPU|Laptop | When does a "disk drive" become required? | 15:05 |
| olofk | To make things a bit more convenient, I would throw in a JTAG connection too, to easily debug and upload programs | 15:05 |
| ZipCPU|Laptop | I would've thought most modern computers require a "disk drive" to boot up. | 15:05 |
| ZipCPU|Laptop | (Not that the ZipCPU does --- I'm only now starting to think of how to deal with it ...) | 15:06 |
| olofk | ZipCPU|Laptop: The common thing for embedded systems is to put u-boot in a small SPI Flash or similar. That will take care of initializing the rest of the system from a disk | 15:08 |
| ZipCPU|Laptop | But what about persistent state? That can be hard when you don't control the power ... | 15:08 |
| olofk | And you have an on-chip bootloader that loads u-boot from flash first | 15:08 |
| olofk | Why on't you control the power? | 15:09 |
| ZipCPU|Laptop | The CPU/software doesn't control power. The user/operator always controls the plug. | 15:09 |
| olofk | Same as with your desktop computer | 15:09 |
| ZipCPU|Laptop | I suppose. But ... often people think they can unplug embedded systems with impunity. Consider thumb drives as an example. | 15:10 |
| ZipCPU|Laptop | You wouldn't believe what that does to the drive if you can't control when the power suddenly gets pulled. What if you are in the middle of a write? | 15:11 |
| olofk | Sure, but that's the job of the os and filesystem to handle that as graceful as it can | 15:12 |
| ZipCPU|Laptop | Maybe I've just been soured over the years. ;) | 15:15 |
| kc5tja | back | 15:18 |
| kc5tja | A disk drive typically becomes required when you want to save data for later use, and/or when you grow tired of typing the same program in over and over again. ;) | 15:20 |
| kc5tja | Re: thumbdrives -- the fault here is the filesystem, not the device itself. AmigaOS, for example, made sure to flush its dirty filesystem buffers every five seconds. This was the only reasonable way to support floppy disks (which can be removed at any time by the user) in a multitasking environment. | 15:22 |
| kc5tja | Filesystem data structures were surprisingly robust against accidental corruption (well, for the time; later on, more advanced filesystems came along that were much better). | 15:22 |
| ZipCPU|Laptop | Not really. Imagine you were writing 16MB of data to the thumbdrive. The write is ongoing when the power is pulled .... | 15:22 |
| kc5tja | If you write your on-disk structures from bottom up, meaning data sectors are written first, THEN pointers to those data sectors, THEN pointers to those, THEN directory entries, etc., eventually, the root of the tree is updated, and that's a single write update. | 15:23 |
| kc5tja | If power is lost prior to that root update, no harm done; the filesystem is still in a consistent state b/c the old metadata is still intact. | 15:24 |
| kc5tja | That's what I mean by filesystem design. | 15:24 |
| kc5tja | You're assuming ext2,3,4fs or NTFS or some such, none of which were designed with removable media in mind. | 15:24 |
| ZipCPU|Laptop | It's not quite so simple with flash memory. You might read the flash successfully once, CRC matches and all, but then come back to find it isn't well any more. | 15:24 |
| kc5tja | Why? | 15:25 |
| kc5tja | If the flash device performs proper write-balancing, you ought not see a fault for a very long time. | 15:25 |
| ZipCPU|Laptop | Because the bits aren't ... fully programmed. They lie somewhere between one and zero. | 15:25 |
| kc5tja | But, again, that would only apply to those sectors written. That wouldn't apply to untouched sectors. | 15:26 |
| ZipCPU|Laptop | The problem is, do you consider the sector valid or not? If you read it and the CRC passes, you might consider it valid and go on. | 15:26 |
| ZipCPU|Laptop | If you come back and the CRC isn't valid, you've already (re)created your journaled file system based upon it being valid ... | 15:26 |
| ZipCPU|Laptop | And now your filesystem is inconsistent. | 15:27 |
| kc5tja | If and only if your filesystem metadata points at the inconsistently written data. | 15:27 |
| kc5tja | And the only way that can happen is if you write metadata ahead of actual data. | 15:27 |
| kc5tja | Which is exactly what I said not to do on removable media. :) | 15:27 |
| ZipCPU|Laptop | Here's a good link: www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits | 15:34 |
| kc5tja | Yep, and I agree with all of it. | 15:39 |
| ZipCPU|Laptop | Then at least you know what I'm talking about. | 15:39 |
| kc5tja | Yes. | 15:39 |
| ZipCPU|Laptop | In the end, I came up with a partial solution--but by then the money had run out. | 15:40 |
| ZipCPU|Laptop | My solution was to run Linux (which we were running) from a read only flash drive, rather than a read-write flash drive. | 15:40 |
| kc5tja | Kestrel-3 will use a well-ordered filesystem for removable media, periodic dirty buffer flushes, and all the other techniques that AmigaOS used. | 15:40 |
| kc5tja | Also, I'll be using skiplists to implement the filesystem with, because B-trees are just stupidly hard to get right, especially when deleting nodes. Bleh! | 15:42 |
| ZipCPU|Laptop | Gosh ... the instructor never had a problem getting them right on the blackboard ... ;) | 15:43 |
| kc5tja | Unfortunately, I'm a 5-time college dropout; never got that far in my classes, and all the books I can find on the matter explicitly leaves deletion as an "exercise to the reader." | 15:43 |
| kc5tja | So, I'm utterly done with that crap. ;) I've now entered the 2nd half of my lifespan, and I don't want to take any more time. | 15:44 |
| ZipCPU|Laptop | That's fascinating! I think the last time I worked on one, I got halfway done and then gave it to someone else to complete. (We'll call this someone else a "student" ... ;) | 15:45 |
| olofk | Yeah! Skiplists :) I have a soft spot for those | 15:49 |
| kc5tja | Me too, because a simpleton like me can understand them. :-D | 15:55 |
| kc5tja | Nothing pleases me more than exploiting sheer simplicity and achieving "close enough" results comparable to some more sophisticated algorithm. | 15:55 |
| kc5tja | I like B-trees, to be sure. But, not enough to implement one by myself. ;P | 15:56 |
| ZipCPU|Laptop | Wouldn't they just be something that you implement once and then use many times over? | 15:56 |
| kc5tja | Maybe for in-RAM purposes yes, but not for on-disk. | 16:06 |
| olofk | I remember Reiser used something called Dancing trees, that no one had been able to implement before him | 16:18 |
| olofk | Turns out that wasn't what he eventually became most famous for | 16:18 |
| kc5tja | Fame and fortune can ruin a man. ;) | 16:21 |
| kc5tja | Just ask anyone on VH-1. | 16:21 |
| olofk | kc5tja: Probably won't have time to meet up during my trip to your side of the pond. I will just fly in and out during the weekend | 16:26 |
| olofk | Unless you happen to be in Mountan View of course | 16:27 |
| olofk | poke53281: Do you know anything about raw memory accesses from Linux with RISC-V? According to eliask there isn't a /dev/mem in there | 17:19 |
| olofk | Maybe eliask can explain better than I can :) | 17:19 |
| olofk | I'm asking since I remember that you were dealing with related things during your port of jor1k to risc-v | 17:20 |
| ssvb | olofk: de0 nano costs 86,77€ at mouser (with free delivery), but it only has 32MB of RAM and provides no Ethernet or SD card slot | 17:41 |
| ssvb | it does not look very useful as a Linux computer, and I suspect that jor1k even works faster | 17:42 |
| ZipCPU|Laptop | That's $86.25 from digikey, for those who are interested in $ not Euro's. | 17:43 |
| olofk | ssvb: All very true. I thought you were just looking for a cheap dev board with good existing OpenRISC support | 17:43 |
| ssvb | ZipCPU: well, electronics is generally more expensive in Europe | 17:44 |
| olofk | Both wallento and andrzejr have been doing OpenRISC stuff with the Nexys boards. A bit more expensive, but got a lot more interesting connectivity | 17:45 |
| olofk | And then we got the Arty that mithro and _florent_ got a Migen-based OpenRISC system running on | 17:45 |
| olofk | I should probably get some newer FPGA boards too if it wasn't for the fact that I already have more boards than time :/ | 17:46 |
| olofk | Think I got nine different boards now | 17:47 |
| ssvb | what do you think about http://www.alterawiki.com/wiki/BeMicro_CV_A9 which is available at https://www.arrow.com/en/products/bemicrocva9/arrow-development-tools for just $149.00? | 17:47 |
| ZipCPU|Laptop | And if you just want a SoC (no Linux support), the ZipCPU runs on the XuLA2-LX9, XuLA2-LX25, Cmod-S6, and (soon to be) the Arty boards. ;) | 17:47 |
| ssvb | I did some "window shopping" and it looks like the best bang for the buck | 17:47 |
| kc5tja | olofk: I live in San Lorenzo, which is about an hour away. | 17:50 |
| kc5tja | olofk: If I have enough of an advanced notice, I can be in Mountain View whenever. | 17:50 |
| ZipCPU|Laptop | The Bemicrocva9 boasts of having a 24MHz CPU--what CPU does it have? | 17:50 |
| olofk | ZipCPU|Laptop: I would presume a Nios | 17:50 |
| olofk | ZipCPU|Laptop: But the 24 MHz was just for the oscillator, right? You can probably run the CPU faster | 17:51 |
| ZipCPU|Laptop | It just doesn't make sense: are you selling an FPGA that can run Nios, or Nios plus an FPGA? | 17:51 |
| olofk | Well, they are often heavily promoting Nios/Microblaze when they sell Altera/Xilinx boards | 17:52 |
| ssvb | ZipCPU: hmm, maybe that's the trick that they do to ensure that it can't compete with more expensive boards? | 17:53 |
| olofk | ssvb: The bemicro CV looks good. I know that the earlier Bemicro models were good value for the money. There are probably similiar options in that price range too | 17:53 |
| ZipCPU|Laptop | Gosh, you could run a ZipCPU at 80MHz on a XuLA2-LX25 for $120 and get more bang for your buck: more RAM, more flash, faster CPU, *and* a micro SD card and still more logic to go. | 17:54 |
| olofk | More RAM? | 17:54 |
| ZipCPU|Laptop | (The XuLA2-LX25 is based around a Spartan-6, LX25). | 17:54 |
| ZipCPU|Laptop | Let me check on that RAM number ... | 17:54 |
| olofk | And they both got SD sockets | 17:55 |
| ZipCPU|Laptop | Okay, 32MB isn't more it's half as much. My bad. | 17:55 |
| ZipCPU|Laptop | Okay, I see it now. You got me twice. ;) | 17:55 |
| olofk | Not sure if the LX25 is any faster than a Cyclone V either :) | 17:55 |
| ZipCPU|Laptop | 24MHz vs 80MHz? | 17:56 |
| olofk | 24 MHz looks just like it's the oscillator frequency | 17:56 |
| ZipCPU|Laptop | 1MByte flash vs 1kbit EEPROM | 17:56 |
| olofk | Bemicro CV got 256Mb (=32MB) Flash | 17:57 |
| ZipCPU|Laptop | Is that what EPCQ means? | 17:57 |
| olofk | and a Gigabit ethernet phy | 17:57 |
| olofk | At least that is what I assumed EPCQ is, but you're right, there's nothing to support my claim | 17:58 |
| ZipCPU|Laptop | Well ... the ethernet phy really depends upon what you wish to do. | 17:58 |
| olofk | Ah ok. EPCQ is a quad SPI flash | 17:58 |
| olofk | Sure. I just haven't found anything better with the Xula2 yet, except for the price, and if potentially the lx25 is faster/bigger than the Cyclone % | 18:00 |
| olofk | 5 | 18:00 |
| ZipCPU|Laptop | olofk: Have you been using the XuLA2? | 18:00 |
| olofk | kc5tja: I don't know what my days will look like during my stay, but we can keep in touch and see if the stars align | 18:00 |
| olofk | ZipCPU|Laptop: No, but I have some other Spartan6-based boards | 18:01 |
| kc5tja | olofk: Best way to reach me will be through e-mail. | 18:01 |
| olofk | I think we run OpenRISC normally at 50MHz on the Atlys (lx45), but maybe stekern got it running a bit faster | 18:02 |
| olofk | kc5tja: Sure. My people will contact your people | 18:02 |
| kc5tja | I have people? SWEET! I feel important now! ;D | 18:03 |
| ZipCPU|Laptop | ssvb: olofk: How about the cmod-A7 from Digilent? It's got a hefty FPGA on it, lot's of room, I can run my CPU at 100MHz ... although it only has 1/2MB RAM, and 4MB SPI flash and no ethernet. Still, if you're looking for the cheap end of the market, that's respectable at $75. | 18:05 |
| ZipCPU|Laptop | Still, though, without the micro SD ... | 18:08 |
| ssvb | ZipCPU: as for the micro SD slot, there are cheap breakout boards which provide it | 18:11 |
| ZipCPU|Laptop | Yeah --- I just bought one. | 18:11 |
| ssvb | but yes, a built-in SD card slot is more convenient | 18:12 |
| olofk | ZipCPU|Laptop: Yes, as you said before, it all depends on the use case. In this case, I think ssvb should go for the bemicro CV or an Arty if ethernet was preferred | 18:13 |
| olofk | Arty is $99, right? | 18:13 |
| ZipCPU|Laptop | Yes. Just bought one. | 18:13 |
| olofk | :) | 18:14 |
| ZipCPU|Laptop | I'm still working on the memory, although I think I've got the flash going. | 18:14 |
| ssvb | anyway, I actually have no experience with FPGA and just bought https://www.olimex.com/Products/FPGA/iCE40/iCE40HX1K-EVB/open-source-hardware a few days ago for the purpose of learning Verilog :) | 18:15 |
| olofk | ssvb: Yeah, the ice40 devices are really cool now when we got project Icestorm | 18:15 |
| ZipCPU|Laptop | Sounds like fun! I just bought my own first board just over a year ago. | 18:16 |
| olofk | I got an icoboard at home. It sits on top of the Raspberry Pi GPIO pins | 18:16 |
| ssvb | also I have ordered this Chinese FPGA board from AliExpress with Cyclone IV and 10K LE for another 20€ and hopefully I will receive it in a month or two | 18:17 |
| olofk | picorv32 runs fine on the icoboard, but I haven't finished porting an openRISC SoC to it yet | 18:17 |
| ssvb | icoboard looks nice, but is a bit expensive | 18:17 |
| olofk | Got mine for free in order to add a FuseSoC backend for Icestorm :) | 18:18 |
| olofk | If any of you are a student, make sure to register for the LibreCores design contest. We are giving away dev boards to the best contestants | 18:19 |
| ZipCPU|Laptop | Once you get a Ph.D., it's hard to justify calling yourself a student again. Not that I wouldn't enjoy a fun design contest ... | 18:20 |
| olofk | There is also a special category for the best design running on an ice40 using the open source toolchain | 18:20 |
| olofk | ZipCPU|Laptop: Yeah. I would have liked to participate as well :) | 18:21 |
| olofk | Maybe I should go for a Ph.D. and sign up | 18:21 |
| ZipCPU|Laptop | Be prepared to kiss 5+ years of your life good bye ... | 18:22 |
| ZipCPU|Laptop | ... and don't forget to become a regular reader of phdcomics.com. | 18:22 |
| olofk | ZipCPU|Laptop: Yeah, I don't think I'll go back to academia any time soon | 18:23 |
| ZipCPU|Laptop | You might just wish to start reading from phdcomics.com anyway ... ;) | 18:23 |
| olofk | I just did :) | 18:25 |
| ZipCPU|Laptop | I've got _years_ of back issues ;) | 18:25 |
| olofk | I saw that it started in 1997 | 18:26 |
| kc5tja | When I was younger, I wanted to be a physicist, either semiconductor or astro. | 18:26 |
| olofk | I just wanted to be a rock star | 18:27 |
| kc5tja | I loved being in the academic environment. | 18:27 |
| kc5tja | Then the real world interfered, prevented me from focusing, almost bankrupting my parents through fraudulent practices in the university, etc. | 18:28 |
| kc5tja | Hence why I'm a 5-time college drop-out. | 18:28 |
| kc5tja | Not for lack of trying, that's for sure. :( | 18:28 |
| ZipCPU|Laptop | Yeah ... funds can get difficult if you are struggling for focus. | 18:28 |
| olofk | I dropped out three times before I got my MSc | 18:29 |
| olofk | Really really happy that getting funding never was part of the equation as education here is free | 18:30 |
| kc5tja | My goal in life is to amass enough wealth to afford to contribute to a university financially thorugh a donation of some kind. Something that contributes to fundamental research (which doesn't get enough funding or attention these days). | 18:30 |
| olofk | Oh well. Time to sleep now | 18:30 |
| ZipCPU|Laptop | olofk: 'till tomorrow. kc5tja: I could tell you stories of research getting messed up, mostly agriculture related though. | 18:31 |
| ZipCPU|Laptop | In many ways, research these days tends to be focused on who's bringing in the funds, not on where the real holes lie. | 18:34 |
| kc5tja | Exactly. | 18:36 |
| kc5tja | back | 21:57 |
| mithro | olofk: ping? | 23:19 |
| --- Log closed Fri Jul 29 00:00:00 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!