| *** tpb has joined #yosys | 00:00 | |
| *** emeb_mac has joined #yosys | 00:49 | |
| *** proteusguy has quit IRC | 01:05 | |
| *** promach_ has joined #yosys | 01:15 | |
| promach_ | corecode : spidergon routing algorithm will give deadlock, that is one bad thing about spidergon | 01:16 |
|---|---|---|
| *** proteusguy has joined #yosys | 01:17 | |
| promach_ | corecode : I mean for spidergon with all master nodes | 01:29 |
| promach_ | https://en.wikipedia.org/wiki/Turn_restriction_routing#Logic_behind_turn_restriction_routing won't be able to help in this case | 01:29 |
| tpb | Title: Turn restriction routing - Wikipedia (at en.wikipedia.org) | 01:29 |
| corecode | can you explain how it can deadlock? | 01:31 |
| *** leviathanch has joined #yosys | 01:38 | |
| emeb_mac | hah, fun - got a simple little 6502-based system running in u4k (my breakout) and hx1k (icestick). fun part was setting up the makefile to include building the ROM contents from 6502 assembly code. | 01:38 |
| *** gsi_ has joined #yosys | 01:40 | |
| *** gsi__ has quit IRC | 01:43 | |
| promach_ | corecode : spidergon with all master nodes will have the possibility of cyclic packet transaction | 01:46 |
| promach_ | cyclic packet flow will lead to deadlock | 01:46 |
| promach_ | this is all the fault with spidergon deterministic routing algorithm | 01:46 |
| promach_ | corecode | 01:46 |
| emeb_mac | general question: when building a design in yosys/nextpnr, is there a way to just change the EBR contents w/o rebuilding everything from scratch? | 02:06 |
| *** proteusguy has quit IRC | 04:21 | |
| *** shuggsy has joined #yosys | 04:48 | |
| *** shuggsy has quit IRC | 04:49 | |
| *** shuggsy has joined #yosys | 04:49 | |
| *** shuggsy has quit IRC | 04:53 | |
| *** shuggsy has joined #yosys | 04:53 | |
| *** pie__ has joined #yosys | 04:55 | |
| *** shuggsy has quit IRC | 04:55 | |
| *** shuggsy has joined #yosys | 04:56 | |
| *** AlexDaniel has quit IRC | 04:57 | |
| *** pie___ has quit IRC | 04:59 | |
| *** rohitksingh has joined #yosys | 05:44 | |
| *** _whitelogger has quit IRC | 06:01 | |
| *** _whitelogger has joined #yosys | 06:03 | |
| *** _whitelogger has quit IRC | 06:19 | |
| *** _whitelogger has joined #yosys | 06:21 | |
| *** leviathanch has quit IRC | 06:35 | |
| *** rohitksingh has quit IRC | 07:12 | |
| *** emeb_mac has quit IRC | 07:13 | |
| *** proteusguy has joined #yosys | 07:15 | |
| *** proteusguy has quit IRC | 08:20 | |
| *** proteusguy has joined #yosys | 08:37 | |
| *** leviathanch has joined #yosys | 08:45 | |
| corecode | promach_: why deadlock? | 09:07 |
| promach_ | corecore : because packet went into cyclic path | 09:07 |
| corecode | a single packet? | 09:07 |
| daveshah | emeb_mac: there is icebram | 09:07 |
| daveshah | It should work with vendor tools too | 09:08 |
| promach_ | corecode : no, all nodes issue packet to the next neighbouring node | 09:08 |
| promach_ | do you get it ? | 09:08 |
| corecode | why is that a deadlock | 09:08 |
| promach_ | corecode : because deadlock is something that locks everything down | 09:08 |
| promach_ | imagine all nodes send at the same time instant | 09:09 |
| promach_ | corecode | 09:09 |
| promach_ | with turn-restricion, then deadlock will not happen | 09:09 |
| promach_ | corecode : but spidergon is using shortest path routing algorithm which does not consider the deadlock problem | 09:10 |
| corecode | can you explain the deadlock | 09:10 |
| corecode | you're saying that it leads to deadlock, but i don't see how | 09:10 |
| tnt | I think figuring out why 'xxx is "unused"' is where I spend most of my time when synthesizing stuff for the first time. | 09:11 |
| corecode | so we start out by having all nodes send a packet to their neighbor | 09:11 |
| promach_ | corecode : es | 09:11 |
| promach_ | yes | 09:11 |
| promach_ | let say in a restaurant, we have a cicle of tables | 09:12 |
| corecode | nono | 09:12 |
| promach_ | and we have 8 tables | 09:12 |
| corecode | no analogy | 09:12 |
| promach_ | we have 8 couples | 09:12 |
| corecode | i can't work with analogies | 09:12 |
| corecode | my brain can't translate | 09:12 |
| promach_ | all of them are sitting in the table | 09:12 |
| promach_ | all nodes are chained in a cicular manner | 09:12 |
| corecode | yes | 09:12 |
| promach_ | node 0 sends packet to node 1 | 09:13 |
| corecode | yes | 09:13 |
| promach_ | node 1 sends packet to node 2 | 09:13 |
| corecode | yes | 09:13 |
| promach_ | node 2 sends packet to node 3 | 09:13 |
| promach_ | node 3 sends packet to node 4 | 09:13 |
| promach_ | node 4 sends packet to node 5 | 09:13 |
| promach_ | node 5 sends packet to node 6 | 09:13 |
| promach_ | node 6 sends packet to node 7 | 09:13 |
| corecode | yes | 09:13 |
| promach_ | node 7 sends packet to node 0 | 09:13 |
| corecode | yes | 09:13 |
| promach_ | now do you see deadlock | 09:14 |
| corecode | no | 09:14 |
| promach_ | moving packet across from one node to the another node requires time latency | 09:14 |
| corecode | yes | 09:14 |
| promach_ | this is physical world, remember | 09:14 |
| promach_ | I mean hardware | 09:14 |
| promach_ | wiring time | 09:14 |
| corecode | so it takes, say, 32 clock cycles to transmit a packet | 09:14 |
| promach_ | let say each packet transfer requires 1 clock cycle | 09:15 |
| promach_ | node 0 cannot send packet to node 1 if node 1 does not have buffer space | 09:15 |
| corecode | okay | 09:15 |
| corecode | why doesn't it have the buffer space? | 09:15 |
| promach_ | node 1 cannot send packet to node 2 if node 2 does not have buffer space | 09:15 |
| promach_ | because it is occupied | 09:16 |
| promach_ | does not have enough buffer space | 09:16 |
| corecode | how is it occupied | 09:16 |
| promach_ | this has to do with all the packet routing | 09:16 |
| corecode | okay | 09:17 |
| corecode | please explain | 09:17 |
| promach_ | all nodes are initially full | 09:17 |
| corecode | why? | 09:17 |
| promach_ | because it is full | 09:17 |
| corecode | what's in there | 09:17 |
| promach_ | filled from packets routed during previous timestep | 09:17 |
| corecode | okay | 09:17 |
| promach_ | do you get the meaning of deadlock now ? | 09:18 |
| corecode | no | 09:18 |
| promach_ | https://en.wikipedia.org/wiki/Turn_restriction_routing | 09:18 |
| tpb | Title: Turn restriction routing - Wikipedia (at en.wikipedia.org) | 09:18 |
| corecode | it seems you're assuming that there is only one buffer for input and output | 09:18 |
| promach_ | https://en.wikipedia.org/wiki/Deadlock | 09:19 |
| tpb | Title: Deadlock - Wikipedia (at en.wikipedia.org) | 09:19 |
| corecode | i know what a deadlock is | 09:19 |
| promach_ | assume ? | 09:19 |
| corecode | is this a question? | 09:20 |
| promach_ | are you telling me that virtual channels will solve the deadlock issue ? | 09:20 |
| corecode | no | 09:20 |
| promach_ | even in spidergon ? | 09:20 |
| corecode | no | 09:20 |
| corecode | you're not being rigorous | 09:20 |
| promach_ | huh ? | 09:20 |
| corecode | you say "this is a deadlock", but you don't define any algorithm | 09:21 |
| promach_ | see https://www.reddit.com/r/algorithms/comments/au94ak/spidergon_networksonchips/eho9uf1/ | 09:21 |
| tpb | Title: Spidergon Networks-on-Chips : algorithms (at www.reddit.com) | 09:21 |
| promach_ | corecode | 09:21 |
| corecode | do you actually look for feedback on what you're saying? | 09:22 |
| corecode | or do you just want to be confirmed? | 09:22 |
| promach_ | no, I am trying to find out ways to tackle deadlock problem in Spidergon | 09:22 |
| corecode | then write an algorithm that will deadlock | 09:23 |
| corecode | and then think about how to avoid it | 09:23 |
| promach_ | already did | 09:23 |
| promach_ | I mean the thinking part, not yet | 09:23 |
| corecode | any cylic graph will have the problem you're describing | 09:23 |
| promach_ | yup | 09:23 |
| corecode | so it's silly to say "oh no" | 09:24 |
| promach_ | wait, probably virtual channels will help | 09:24 |
| *** rohitksingh has joined #yosys | 09:24 | |
| corecode | why | 09:24 |
| corecode | i think you're reading a lot and not doing a lot | 09:24 |
| promach_ | no, reading helps | 09:24 |
| corecode | thinking helps even more | 09:25 |
| corecode | if you can process your incoming data in one clock cycle, would you get a deadlock? | 09:25 |
| promach_ | otherwise the code won't be correct | 09:25 |
| corecode | code is never correct | 09:25 |
| corecode | but it can approach correct | 09:25 |
| corecode | it's an iterative process | 09:25 |
| corecode | so it can't be a routing deadlock; if our processing in the node was just "receive packet and drop", it would work without problems | 09:26 |
| corecode | so it has to be a processing issue | 09:26 |
| promach_ | what processing were you referring ? | 09:27 |
| corecode | in the node | 09:27 |
| promach_ | true, each node is a verilog module | 09:27 |
| promach_ | and each verilog module has different latency | 09:27 |
| corecode | if each node will just discard the incoming packet, it won't deadlock | 09:27 |
| promach_ | true | 09:28 |
| corecode | so it is not a problem of the network | 09:28 |
| promach_ | but we have tackle this problem through network concepts | 09:28 |
| corecode | no | 09:28 |
| promach_ | using virtual channels will solve the deadlock issue | 09:28 |
| corecode | okay | 09:28 |
| corecode | i'm done with you | 09:28 |
| promach_ | but I am not sure | 09:29 |
| corecode | i think you're a robot | 09:29 |
| corecode | off in ignore you go | 09:29 |
| *** proteusguy has quit IRC | 09:42 | |
| sorear | harsh | 09:42 |
| corecode | sorear: me? | 09:45 |
| sorear | yes | 09:45 |
| corecode | why | 09:47 |
| *** maikmerten has joined #yosys | 10:00 | |
| *** proteusguy has joined #yosys | 10:12 | |
| *** rohitksingh has quit IRC | 10:17 | |
| keesj | daveshah: great work on ECP5 DDR3! https://twitter.com/fpga_dave/status/1101925224344367105 | 11:00 |
| corecode | oh i should get into the ecp5 | 11:06 |
| daveshah | thanks keesj!# | 11:12 |
| corecode | yeah, cool | 11:14 |
| corecode | oh no, the q&a of your fodem talk was cut short | 11:16 |
| *** proteusguy has quit IRC | 11:16 | |
| corecode | daveshah: is there a list of what dies exist for the ecp5? | 11:31 |
| daveshah | It's 25k, 45k, and 85k | 11:31 |
| daveshah | the 12k is a rebadged 25k | 11:31 |
| corecode | do they all have serdes? | 11:31 |
| daveshah | Probably, but it's the most likely thing to have yield issues | 11:32 |
| corecode | aha | 11:32 |
| daveshah | so I wouldn't bank on it being in-spec on non-serdes parts | 11:32 |
| corecode | i see | 11:32 |
| corecode | but good enough to play with | 11:32 |
| daveshah | haven't ever tried it | 11:32 |
| corecode | ok | 11:33 |
| daveshah | don't have any boards around with a non-serdes ecp5 that exposes the necessary pins | 11:33 |
| corecode | ah | 11:33 |
| corecode | because the UM (serdes) parts seem to be 3x the price | 11:33 |
| tnt | What I'm wondering is if the 5g part could run at 6.144G ... | 11:38 |
| corecode | where is that rate used? | 11:39 |
| daveshah | Given that the 5G parts are already 'over-volted' my suspicion is they are quite marginal | 11:39 |
| daveshah | wouldn't be too surprised if some could run at 6.144G though | 11:40 |
| tnt | corecode: with 2x6.144G you can get a 10G ethernet lane. | 11:40 |
| corecode | ah, the 256-CABGA is 0.8mm pitch | 11:40 |
| corecode | that's at least possible in fairly low price process | 11:41 |
| somlo | daveshah: also want to say congrats (and thanks) for the ecp5 ddr3 thing! | 12:21 |
| somlo | is it in litex proper, or in a fork or PR? | 12:22 |
| daveshah | The DDR3 stuff is now upstream | 12:23 |
| daveshah | The SoC with Ethernet is here: https://github.com/enjoy-digital/versa_ecp5 | 12:23 |
| tpb | Title: GitHub - enjoy-digital/versa_ecp5: Versa ECP5 SoC based on LiteX (at github.com) | 12:23 |
| somlo | so litedram proper and versa_ecp5, then -- cool! | 12:23 |
| somlo | I need a starting point to rip out just the dram controller and the C program used to initialize it, so I can graft it onto the rocket chip based SoC :) | 12:24 |
| *** Laksen has joined #yosys | 12:26 | |
| somlo | so Lattice have decided to send me a proper 5g versa board, and they're letting me keep the franken-version with a non-5g FPGA -- might be worth something as a weird collectible one day in the future (or not) :) | 12:31 |
| *** flaviusb has quit IRC | 12:42 | |
| *** rohitksingh has joined #yosys | 12:44 | |
| *** flaviusb has joined #yosys | 12:44 | |
| *** rohitksingh has quit IRC | 13:05 | |
| *** rohitksingh has joined #yosys | 13:21 | |
| *** rohitksingh has quit IRC | 13:35 | |
| *** rohitksingh has joined #yosys | 14:01 | |
| *** lutsabound has joined #yosys | 14:29 | |
| *** rohitksingh has quit IRC | 14:29 | |
| MoeIcenowy | somlo: board with wrong chip? | 15:28 |
| MoeIcenowy | collectible ;-) | 15:28 |
| *** svenn2 has joined #yosys | 15:32 | |
| *** svenn has quit IRC | 15:32 | |
| *** maikmerten has quit IRC | 15:37 | |
| *** emeb_mac has joined #yosys | 15:48 | |
| *** leviathanch has quit IRC | 17:40 | |
| *** knielsen has quit IRC | 18:15 | |
| *** knielsen has joined #yosys | 18:23 | |
| *** rohitksingh has joined #yosys | 18:34 | |
| *** promach_ has quit IRC | 18:46 | |
| *** rohitksingh has quit IRC | 18:49 | |
| MoeIcenowy | daveshah: btw is DFF initialization implemented in ECP5 Yosys? | 19:13 |
| daveshah | MoeIcenowy: yes, it is now | 19:13 |
| daveshah | https://github.com/YosysHQ/yosys/blob/master/techlibs/ecp5/ecp5_ffinit.cc | 19:13 |
| tpb | Title: yosys/ecp5_ffinit.cc at master · YosysHQ/yosys · GitHub (at github.com) | 19:13 |
| MoeIcenowy | daveshah: in fact I think I have done the same thing for Anlogic | 19:14 |
| MoeIcenowy | via "dffinit -strinit SET RESET -ff AL_MAP_SEQ q REGSET -noreinit" | 19:14 |
| MoeIcenowy | do you think this scheme familiar? ;-) | 19:15 |
| daveshah | yeah, this pass also has to deal with conflicts between sync set/reset and initialisation (by blowing the sync set/reset back to logic in a conflict) | 19:16 |
| MoeIcenowy | oh maybe I should drop my code and port ecp5_ffinit to anlogic | 19:17 |
| *** develonepi3 has quit IRC | 21:08 | |
| emeb_mac | stupid 6502 + UART running on an icestick. just because -> https://github.com/emeb/icestick_6502.git | 21:55 |
| tpb | Title: GitHub - emeb/icestick_6502: A small 6502 system build on a Lattice Icestick FPGA development board (at github.com) | 21:55 |
| cr1901_modern | ahhh you used Arlet's core nice | 21:56 |
| tnt | emeb_mac: now you need to pport basic to it :) | 21:56 |
| cr1901_modern | oh cool, you made an acia too | 21:58 |
| cr1901_modern | next is via and pia ports :P? | 21:58 |
| emeb_mac | tnt: rofl | 21:58 |
| emeb_mac | tnt: I actually have BASIC running on the one I did for up5k | 21:59 |
| emeb_mac | but it's too big to fit into the BRAM on the hx1k | 21:59 |
| tnt | oh you have a up5k version somewhere ? | 21:59 |
| daveshah | Run on SPI flash? | 21:59 |
| emeb_mac | tnt: yeah - haven't published it though - not quite done yet | 21:59 |
| daveshah | Or implement virtual memory and load pages from the UART :P | 21:59 |
| emeb_mac | daveshah: heh | 22:00 |
| emeb_mac | cr1901_modern: the acia is just a wrapper around a simple UART core I found on github | 22:00 |
| emeb_mac | cr1901_modern: and on closer inspection that UART has some issues. But it's good enough for a demo. :) | 22:01 |
| cr1901_modern | ahhh | 22:01 |
| cr1901_modern | and 65816 has virtual memory support; I don't think 6502 does | 22:01 |
| emeb_mac | cr1901_modern: no - it's just straight 64k w/o banks, mmu, etc | 22:01 |
| cr1901_modern | there's an old 74xx chip that is called an "MMU", but it's more accurately called a bank switcher | 22:02 |
| sorear | 65816 has bank registers but no protection/remapping? | 22:23 |
| cr1901_modern | 65816 has an abort pin that restarts the current insn | 22:24 |
| cr1901_modern | this means in principle you can add memory protection/remapping | 22:24 |
| cr1901_modern | But I've seen the abort pin used exactly once | 22:26 |
| cr1901_modern | in someone's custom computer | 22:26 |
| cr1901_modern | (Back in 2015 I asked for the source code- it was made using one of Lattice's GUIs a la icestuido | 22:26 |
| cr1901_modern | I still have it somewhere, but never got around to studying it | 22:27 |
| cr1901_modern | sorear: https://www.pc65816.de/en/html/asicmmu.html | 22:35 |
| tpb | Title: ASICMMU (at www.pc65816.de) | 22:35 |
| cr1901_modern | Note that adapting this to modern FPGAs... well, it stinks. 65816 is a 5V CMOS CPU, so TTL levels don't work for it and associated peripherals | 22:44 |
| cr1901_modern | on the other end of the MMU you'll need level shifters for 5V CMOS peripherals that natively speak to 65816 | 22:44 |
| emeb_mac | I've been lurking over on that Commander 16 project on FB where they're trying to design a 65816 retrocomputer. | 22:46 |
| emeb_mac | it's kind of hilarious/sad all the conflict they're having over the use of FPGAs | 22:47 |
| sorear | cute | 22:47 |
| cr1901_modern | well, maybe you don't need all that much converted back to 5V on the I/O side of the MMU... a greenpak powered at 5V could do dual addr decoding and level shifting | 22:49 |
| tnt | emeb_mac: is that the 8bit guy project ? | 22:54 |
| cr1901_modern | He rubs me the wrong way | 22:54 |
| cr1901_modern | but I could just be jealous of his success | 22:54 |
| cr1901_modern | (and there are some... flaws w/ his "how 8-bit graphics work" that my NES hacker friends like to point out :P) | 22:55 |
| cr1901_modern | "how 8-bit graphics work" video* | 22:55 |
| tnt | oh yeah, it's not always the most technically accurate. For that gotta watch the 'ultimate talks' series from ccc :p | 22:56 |
| tnt | we need a 'ultimate ice40 talk' with all the tech details of all the blocks the routing and all that stuff :) | 22:57 |
| emeb_mac | tnt: yes | 22:57 |
| emeb_mac | it's a neat idea, but their self-imposed limits seem kind of shortsighted, and I suspect they'll have a hard time hitting that $50 price point goal without losing their shirts. | 22:59 |
| tnt | I didn't read anything on the fb group, but esden and I actually sent him a proposal for an ice40 gpu (and matching hdmi driver and bus interface), but he turned it down, so didn't really follow after that. | 23:01 |
| cr1901_modern | c256 foenix looks interesting | 23:02 |
| cr1901_modern | it's sorta what I would do if I were making my own 65816 computer | 23:02 |
| cr1901_modern | I would use FPGAs for: address decoding, MMU, i2c bus, uart, and spi bus. The UART is because the current ACIA silicon by WDC is very broken | 23:03 |
| esden | I had a few back and forth with him when he turned us down. Regarding pricing. He insisted it was fine to use the xilinx chip for video, because someoen told him he will be able to source the chips for $5. I ended up wishing him good luck, and if he is interested he knows how to reach us. :) | 23:03 |
| esden | And honestly. I am even more curious if he will be able to source the 65C2xxx chip for a reasonable price. Without good chip distributor contacts and large production quantities, these things are not that simple to get. | 23:05 |
| cr1901_modern | 65c2xx is the microcontroller variant IIRC | 23:06 |
| cr1901_modern | it's an interesting beast | 23:06 |
| esden | I don't doubt it is interesting. ;) | 23:07 |
| cr1901_modern | esden: I like WDC a lot- they are receptive to hobbyists inquiries. But it's quite a mystery to me where their actual business comes from. | 23:07 |
| cr1901_modern | b/c it ain't from Joe nobody like me | 23:07 |
| daveshah | Plenty of still built old designs I'm sure | 23:08 |
| daveshah | Particularly applications which are certified and expensive to change | 23:08 |
| cr1901_modern | (the VP of Business and Development David Cramer helped me out personally over email when I had trouble buying some 65816s a few years ago from a vendor.) | 23:08 |
| cr1901_modern | WDC is fabless; they used Sanyo up until I want to say 2015; now they use TSMC | 23:10 |
| esden | Yeah the amount of old chips in industrial applications is astonishing. I bet in certified systems there is even more of that. | 23:11 |
| cr1901_modern | (Tbh, I thought for the longest time Sanyo was a kitchen appliance manufacturer) | 23:11 |
| emeb_mac | WDC is about 5 miles from where I live. | 23:12 |
| cr1901_modern | Oh that's cool | 23:12 |
| cr1901_modern | >In 2010, Sanyo sold its semiconductor operations to ON Semiconductor. [16] Oops | 23:12 |
| sorear | Are they still using the old masks for anything or is the Verilog version the only one now | 23:13 |
| emeb_mac | but I agree with esden that they'll have trouble with pricing, not just on the CPU & FPGA too. | 23:13 |
| *** Laksen has quit IRC | 23:14 | |
| sorear | My general philosophy on this sort of system stuff is you want to balance complexity between components, and using a ca. 10 kGE core like 65816 with >>1Mbit of memory is unbalanced and silly | 23:15 |
| emeb_mac | heh - the village idiot driving a lamborghini :) | 23:17 |
| esden | I also heard him say, "I am not concerned about the hardware that much, software is much more important at the moment." although I partly agree. He did mention the aggressive $60 retail target, and I think they are being overly optimistic. To emeb_mac's point, even if the main components seem to be "gettable" in the right price bracket, there is a lot of supporting components that will add up. | 23:17 |
| cr1901_modern | sorear: I dunno... in principle 65816 could run a full fledged *nix if you actually gave it a full 16MB of RAM. The main problem is that functions have to be limited to 64kB boundaries (or a linker relaxation pass would have to break a function that straddled the boundary into two chunks). | 23:18 |
| sorear | who are we talking about? | 23:18 |
| cr1901_modern | I think that would be cool | 23:18 |
| cr1901_modern | sorear: 8-bit guy | 23:18 |
| sorear | i,i Sanrio semiconductors | 23:18 |
| cr1901_modern | ._. | 23:19 |
| emeb_mac | Those Spartan 6 LX9 chips are listed @ ~$18 / qty180. You might be able to get them cheaper if you cozy up to the Xilinx reps and get the "friend & family" pricing. This project *might* be high enough profile that they'd buy in. Might. | 23:20 |
| daveshah | Unlikely, with my experience of Xilinx reps in the UK a few years ago at least | 23:22 |
| *** loxodes has joined #yosys | 23:22 | |
| daveshah | The best price we got was higher per unit than digikey | 23:22 |
| daveshah | In qty 1000 | 23:22 |
| emeb_mac | A guy I know managed to talk Xilinx down to about $10 for an SDR project he was going to do, but there were a lot of strings attached. | 23:23 |
| emeb_mac | (on the S6 LX9) | 23:23 |
| daveshah | I suspect in this case they are relying on cheapo "secondary" distributors | 23:24 |
| daveshah | Not a risk I'd take for something like this, but each to their own | 23:24 |
| emeb_mac | ever popular Chinese gray market | 23:24 |
| emeb_mac | ice40 HX would definitely be a better bet for something that doesn't need lots of DSP cores. | 23:25 |
| esden | Yeah, I can confirm that it really depends on how cozy you are with the "right people" from the chip vendor. And developing those relationships takes a lot of time, even if you have a "high profile" project. But who knows he might know someone, he does have a lot of tech people watching his channel. | 23:26 |
| cr1901_modern | I really can't watch many retro channels on YT. I just get sad that I either A. missed my chance to get a piece of the retro pie, and/or B. don't have the right personality to have pulled off being a popular retro enthusiast lol | 23:28 |
| cr1901_modern | That market is very well saturated now | 23:28 |
| esden | I try to tell myself that I do not have space or time for it anyways. So I enjoy the fruits of the other people’s labor here. I have enough things to play with... ;) but sometimes I have similar feelings cr1901_modern | 23:32 |
| cr1901_modern | esden: The first step towards fixing a problem is admitting it exists. Well, I'm not really about the fix these jealous feelings tho LOL | 23:34 |
| cr1901_modern | If someone wants to dunk on 8-bit guy, and I know their credentials, I'm prob gonna listen. And wish it was me doing said videos and sipho- err making money off ppl's nostalgia instead | 23:35 |
| cr1901_modern | I mean shit, of course I'd love to be able to talk about/make hardware for obsolete machines and not have to worry about other work XD | 23:36 |
| daveshah | Get a job in the railway industry then :P | 23:36 |
| daveshah | Or military or marine | 23:37 |
| esden | Or aircraft... | 23:37 |
| cr1901_modern | Hmmm, well I do like trains (although foamers ensure I'll never talk about that out loud) | 23:37 |
| esden | My PnP is the biggest retro project that I have... and I would prefer if it was not retro to be fair... on the other hand it is probably easier to maintain without a support contract. ;D | 23:38 |
| cr1901_modern | PnP? | 23:38 |
| esden | Pick and Place machine | 23:38 |
| cr1901_modern | You're making an ISA Plug-n-Pray FPGA core? | 23:38 |
| cr1901_modern | ahhhh | 23:38 |
| cr1901_modern | yea I don't have the spare money for that | 23:38 |
| esden | well... it is not a toy in my case. I wish it was just that. | 23:38 |
| esden | Ahh the utopia where one can just work on interesting shit without worrying about materialism. :/ | 23:40 |
| cr1901_modern | Hmmm fair point. I wasn't thinking of using it as a toy, but to make prototyping during contracts easier | 23:42 |
| cr1901_modern | since I'm not a wonderful manual pick-n-place machine | 23:43 |
| *** chaseemory has joined #yosys | 23:48 | |
| cr1901_modern | esden: Was the 3-bit HDMI icebreaker PMOD meant to be a prototype? | 23:55 |
| cr1901_modern | contrast to the 16-pin PMOD | 23:55 |
| cr1901_modern | or was there supposed to be an 8-pin 3-bit and 16-pin "whatever"-bit verson? | 23:55 |
| esden | For less boards than 10 it is usually faster to place by hand than setup a PnP. | 23:57 |
| esden | The 3bit one was a prototype based on Kevin's design. The 4bit version is the successor to it, based on tnt's suggestion. This is what I will be making and selling in the store. The 12bit version is part of the crowd funding campaign, and this is what "people" will be getting. | 23:58 |
| cr1901_modern | ahhh | 23:59 |
| cr1901_modern | (who is Kevin, btw?) | 23:59 |
| cr1901_modern | anyways I have the 3-bit version which is fine for my needs. Making the 4-bit at home might be fun | 23:59 |
| esden | There is a new version of the 4 and 12 bit coming, with more jumpers, again a good suggestion from tnt. ;) | 23:59 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!