| *** tpb has joined #yosys | 00:00 | |
| *** cr1901 has quit IRC | 00:15 | |
| *** cr1901 has joined #yosys | 00:16 | |
| *** emeb_mac has joined #yosys | 01:04 | |
| *** gsi__ has joined #yosys | 01:28 | |
| *** gsi_ has quit IRC | 01:31 | |
| *** gnufan_home has quit IRC | 01:59 | |
| *** Cerpin has quit IRC | 02:17 | |
| *** pacak has quit IRC | 02:52 | |
| *** diakopter has joined #yosys | 02:53 | |
| *** emeb has quit IRC | 02:53 | |
| *** PyroPeter has quit IRC | 03:04 | |
| *** pacak has joined #yosys | 03:04 | |
| *** PyroPeter has joined #yosys | 03:17 | |
| *** Cerpin has joined #yosys | 03:18 | |
| *** Cerpin has quit IRC | 03:37 | |
| *** Cerpin has joined #yosys | 03:37 | |
| *** diakopter has left #yosys | 03:46 | |
| *** Cerpin has quit IRC | 03:53 | |
| *** _whitelogger has quit IRC | 04:50 | |
| *** _whitelogger has joined #yosys | 04:52 | |
| *** gsi__ is now known as gsi_ | 04:58 | |
| *** citypw has joined #yosys | 05:30 | |
| *** futarisIRCcloud has quit IRC | 05:36 | |
| *** _whitelogger has quit IRC | 06:02 | |
| *** _whitelogger has joined #yosys | 06:04 | |
| *** rohitksingh has joined #yosys | 06:29 | |
| *** rohitksingh has quit IRC | 07:09 | |
| *** GoldRin has quit IRC | 07:22 | |
| *** rohitksingh has joined #yosys | 07:29 | |
| *** emeb_mac has quit IRC | 07:30 | |
| *** rohitksingh has quit IRC | 07:45 | |
| *** rohitksingh has joined #yosys | 07:45 | |
| *** maikmerten has joined #yosys | 07:55 | |
| corecode | daveshah: i'm trying to add LED_DRV / RGB_DRV support for u4k | 08:32 |
|---|---|---|
| corecode | the issue is that LED_DRV_CUR is a separate instance | 08:32 |
| corecode | so somehow i need to tease apart which bits are for LED_DRV_CUR and which are for RGB_DRV | 08:33 |
| daveshah | corecode: Is LED_DRV_CUR used for anything else? | 08:34 |
| corecode | also for IR_DRV | 08:34 |
| daveshah | If so you could see which bits are common in the two usages | 08:34 |
| corecode | yea | 08:34 |
| corecode | but i don't think i have that for my package | 08:34 |
| corecode | need to look again | 08:35 |
| daveshah | Guess you might need to use a different package for that test | 08:37 |
| corecode | i wonder what the point of this is | 08:38 |
| corecode | it has an output signal | 08:38 |
| corecode | and that signal can only be routed to either RGB_DRV or IR_DRV | 08:38 |
| *** citypw has quit IRC | 08:38 | |
| daveshah | It almost seems like leaking their implementation detail into user designs | 08:39 |
| corecode | yes | 08:45 |
| corecode | i wonder whether i can somehow force synthesis and placer to keep the LED_DRV_CUR without connecting anything to it | 08:45 |
| corecode | maybe with an explicit place? | 08:46 |
| daveshah | You can put a placement constraint in the pcf file but that won't stop it removing things | 08:51 |
| daveshah | Putting (* keep *) on it might work but I've never tried | 08:51 |
| corecode | it looks like the LED_DRV_CUR is exactly the same location (modulo size) as CURREN is | 08:52 |
| daveshah | Oh that's odd. Same z too? | 08:53 |
| corecode | (25, 19, "CBIT_5") | 08:54 |
| daveshah | Interesting, the UltraPlus sets CBIT_5 in a tile on the other side of the device (0, 28, CBIT_5) when the RGB driver is used | 08:58 |
| daveshah | Is there a CURREN signal anywhere (either on the LED_DRV_CUR or the RGB itself)? On the UltraPlus it routes into tile 25,29 which is equivalent to Ultra tile 25,19 | 08:59 |
| *** rohitksingh has quit IRC | 09:17 | |
| corecode | (0, 18, "CBIT_5") | 09:28 |
| corecode | as well | 09:28 |
| corecode | hm nevermind | 09:29 |
| *** rohitksingh has joined #yosys | 09:39 | |
| *** _whitelogger has quit IRC | 09:56 | |
| *** _whitelogger has joined #yosys | 09:58 | |
| *** Jybz has joined #yosys | 10:25 | |
| *** proteusguy has quit IRC | 10:56 | |
| *** futarisIRCcloud has joined #yosys | 10:57 | |
| *** proteusguy has joined #yosys | 11:08 | |
| *** _whitelogger has quit IRC | 12:53 | |
| *** _whitelogger has joined #yosys | 12:55 | |
| *** dys has quit IRC | 13:06 | |
| *** _whitelogger has quit IRC | 13:44 | |
| *** _whitelogger has joined #yosys | 13:46 | |
| *** futarisIRCcloud has quit IRC | 13:56 | |
| *** lutsabound has joined #yosys | 14:06 | |
| *** _whitelogger has quit IRC | 14:17 | |
| *** _whitelogger has joined #yosys | 14:19 | |
| *** dys has joined #yosys | 14:36 | |
| *** maikmerten has quit IRC | 15:20 | |
| corecode | daveshah: i forgot, how do i visualize the placer results of icestorm? | 15:31 |
| corecode | i want to know verify lutff is connected to which io pad | 15:31 |
| daveshah | corecode: use nextpnr --gui | 15:31 |
| corecode | uhm | 15:35 |
| corecode | i mean the result from icecube | 15:35 |
| corecode | not from nextpnr | 15:36 |
| daveshah | Oh, it's called something like "floorplan" or "physical" view | 15:37 |
| daveshah | Haven't used icecube for a while though | 15:37 |
| corecode | yea but somehow i can't synthesize after opening the project | 15:40 |
| corecode | odd | 15:40 |
| corecode | hm, but i can't see what path it takes | 15:47 |
| corecode | mh | 15:47 |
| corecode | so how do i trace these connections? | 15:49 |
| *** cr1901 has quit IRC | 15:54 | |
| corecode | i.e. the sequence of routing and buffers | 15:54 |
| *** cr1901 has joined #yosys | 15:54 | |
| *** citypw has joined #yosys | 16:01 | |
| *** cr1901 has quit IRC | 16:06 | |
| *** cr1901 has joined #yosys | 16:11 | |
| *** citypw has quit IRC | 16:19 | |
| *** emeb has joined #yosys | 16:21 | |
| daveshah | corecode: icecube doesn't any view of the routing | 16:33 |
| daveshah | icebox_explain and icebox_vlog will have to do... | 16:34 |
| *** cr1901 has quit IRC | 16:38 | |
| *** cr1901 has joined #yosys | 16:39 | |
| *** cr1901 has quit IRC | 16:44 | |
| corecode | so... what to do with this silly output | 16:56 |
| corecode | which doesn't seem to be routed? | 16:56 |
| corecode | it's as if there is no LEDPU output | 17:04 |
| corecode | it's just a fake, not a real signal? | 17:04 |
| corecode | https://gist.github.com/corecode/4b6d47e26830fcb2f3a5ff3542189647 | 17:05 |
| tpb | Title: sb_rgb_drv.v · GitHub (at gist.github.com) | 17:05 |
| corecode | https://gist.github.com/corecode/5a95c1ffef6c22b1063af5b2e056df2e | 17:05 |
| tpb | Title: sb_rgb_drv.tcl · GitHub (at gist.github.com) | 17:05 |
| corecode | tcl eh? | 17:05 |
| emeb | the strange relationship between SB_LED_DRV_CUR and SB_RGB_DRV has always puzzled me | 17:06 |
| *** cr1901 has joined #yosys | 17:10 | |
| corecode | yea | 17:11 |
| corecode | seems shoehorned in | 17:11 |
| corecode | why is there this enable pin? | 17:12 |
| corecode | ah maybe otherwise the synthesis tool will throw it away | 17:12 |
| emeb | maybe for power mgmt? | 17:12 |
| corecode | one is the constant current somethingsoemthing | 17:12 |
| corecode | the other the specific LED drivers | 17:13 |
| emeb | right, but the current source may pull some power and shutting it down may help reduce sleep power. | 17:13 |
| corecode | and by having a virtual signal go from one to the other, the synthesizer can't optimize it away | 17:13 |
| corecode | yes | 17:13 |
| emeb | the Ultra data sheet and appnotes don't provide any detail on this - just say that it supplies a 40uA reference and takes 100us to stabilize after EN is asserted. | 17:19 |
| corecode | yea also the vlog doesn't show anything | 17:19 |
| corecode | nor does the exp | 17:19 |
| corecode | i think it's purely virtual | 17:20 |
| corecode | previously it was part of the RGBA | 17:20 |
| corecode | now it is in a separate instance | 17:20 |
| emeb | yep - and in ultralite and ultraplus it's rolled into the other cores. | 17:20 |
| emeb | probably a consequence of the failed pwm core on ultra | 17:21 |
| corecode | hmm | 17:23 |
| corecode | i think in the ul/up they decided to not have that silly extra instance and instead use the same enable signal twice? | 17:23 |
| corecode | hm | 17:23 |
| corecode | i guess we won't find out - ir400_drv periph is not mapped in icebox | 17:26 |
| emeb | heh - not much point in pursing that then. | 17:27 |
| corecode | not at the moment | 17:27 |
| emeb | that thing is scary anyway :) | 17:27 |
| emeb | YOU CAN'T HANDLE THE CURRENT!!! | 17:27 |
| *** cr1901_modern has joined #yosys | 17:36 | |
| tnt | It's split probably because it's shared and so that's their way to reflect it in HDL. | 17:40 |
| corecode | yes | 17:41 |
| corecode | do ul/up only have either ir or rgb? | 17:41 |
| tnt | up only has RGB. | 17:41 |
| *** cr1901 has quit IRC | 17:41 | |
| corecode | can somebody explain what nextpnr's ice40/pack.cc:1116 does? | 17:42 |
| corecode | the disconnect all external ports | 17:42 |
| corecode | is that checking whether the RGB* ports are connected elsewhere? | 17:42 |
| corecode | i guess it does | 17:42 |
| tnt | There is no real wires connection that block to the IO pins. | 17:43 |
| corecode | so, it is called SB_RGB_DRV for the ultra | 17:43 |
| tnt | Not normal routing anyway. | 17:43 |
| tnt | So we remove those wires in nextpnr. | 17:44 |
| corecode | how do i best modify nextpnr? | 17:44 |
| corecode | i mean, naming wise | 17:44 |
| corecode | most of the code applies as well to the ultra | 17:44 |
| tnt | Maybe a generic is_sb_anyled_drv ? | 17:50 |
| tnt | that would cover sb_ir500_drv / sb_barcode_drv / sb_ir400_drv / sb_ir_drv / sb_rgba_drv / sb_rgb_drv | 17:52 |
| tnt | (I think I didn't forget any ...) Then a std::map of the cell name -> an array of the 'special output pins names'. | 17:52 |
| corecode | i don't feel comfortable extending this to IR | 17:53 |
| corecode | not in this change | 17:53 |
| tnt | well you can just put all the 'non tested / supported' ones in /* */ | 17:53 |
| corecode | i wonder what i have to do to get the rgb_drv bits into the chipdb | 17:54 |
| corecode | how does create_ice_cell() get called for SB_RGBA_DRV? | 18:01 |
| tnt | It doesn't ? | 18:03 |
| tnt | The cell is already there in the .json when loading. | 18:03 |
| corecode | so why is there code? | 18:04 |
| tnt | create_ice_cell is called when conversing from one cell type to another. Like SB_DSP16 -> ICESTORM_DSP | 18:04 |
| emeb | 800x600 65 color vga from a up5k with 6502 + BASIC -> https://www.dropbox.com/s/xea4z9gbwsupp7k/0609191105.jpg?dl=0 | 18:23 |
| tpb | Title: Dropbox - 0609191105.jpg - Simplify your life (at www.dropbox.com) | 18:23 |
| emeb | err... 64 color :P | 18:23 |
| tnt | emeb: :) | 18:29 |
| emeb | frankly, the composite NTSC w/ color was more challenging than VGA, even though VGA looks better. | 18:30 |
| tnt | Well yeah, not surprising, ntsc was made for analog stuff ... | 18:31 |
| tnt | vga even though the signal itself is analog is way closer to what digital interface video looks like. | 18:32 |
| corecode | so how do i test whether a port is connected to a bel | 18:32 |
| tnt | corecode: huh ? What are you trying to check ? | 18:33 |
| corecode | whether the LEDPU port from LED_DRV_CUR is connected to RGB_DRV | 18:35 |
| tnt | Basically you need to take both cells, then from the cell you get the port, from the port you can find the net and then on the net you can check if the driver is the LED_DRV_CUR and is net.users.size == 1 and if that user is indeed a RGB_DRV. | 18:37 |
| corecode | and do i erase the net? | 18:39 |
| tnt | Yeah since it's not a normal net. | 18:41 |
| corecode | but then if i delete it, i can't test it in the other cell | 18:45 |
| corecode | hmm | 18:45 |
| tnt | Yeah, you'd basically do the test/delete in only one of the cell. | 18:46 |
| emeb | set a private flag "I deleted LEDPU" and test for that? | 18:46 |
| corecode | ah hang on | 18:47 |
| corecode | the cells are sorted | 18:47 |
| corecode | so one is always processed before the other | 18:47 |
| corecode | lexical sort? | 18:47 |
| corecode | i guess bellid index | 18:55 |
| corecode | ah no, idstring | 18:57 |
| corecode | i think the better choice is a flag, yes | 19:02 |
| corecode | what happens if i erase a net, but not all ports connected to it? | 19:05 |
| tnt | well you must not delete the port, but you need to disconnect them. | 19:07 |
| tnt | if not ... assert / segfault / general pain and badness. | 19:07 |
| corecode | Error::Illegal Connection: Pin 'RGBPU' of instance 'RGB_DRV' of type 'RGB_DRV' should be driven by 'LEDPU' pin of 'LED_DRV_CUR' type instance | 19:10 |
| corecode | so that's the message icecube spits out when you wire up 0 | 19:11 |
| corecode | however, if you don't wire up anything (don't mention the port), you don't get an error | 19:11 |
| corecode | but somehow the LED_DRV_CUR instance is being optimized away then | 19:11 |
| corecode | ci->ports.erase(ctx->id("RGB0")); | 19:12 |
| corecode | 19:12 | |
| corecode | so what's that then? | 19:12 |
| *** rohitksingh has quit IRC | 19:13 | |
| *** lutsabound has quit IRC | 19:15 | |
| *** AlexDaniel has joined #yosys | 19:16 | |
| *** lutsabound has joined #yosys | 19:25 | |
| corecode | hm, do i need to make a new ipcon_u4k db? | 19:59 |
| corecode | or do i dump stuff into the 5k? | 19:59 |
| daveshah | corecode: what do you need to add? | 20:02 |
| corecode | the RGB_DRV | 20:02 |
| daveshah | What bits does it add to that database? | 20:03 |
| corecode | i don't know | 20:03 |
| corecode | i'm struggling with icefuzz's Makefile | 20:03 |
| corecode | i need to dump the bits somewhere | 20:03 |
| daveshah | If its just some extra config bits then it's fine just to use the 5k one | 20:04 |
| corecode | ok | 20:05 |
| corecode | hm i don't know how i can get these bits extracted | 20:18 |
| corecode | oooh | 20:18 |
| corecode | mistakes were made | 20:18 |
| corecode | ah no | 20:19 |
| corecode | derp, of course no new bits show up, because the same bits are already used under a different name | 20:23 |
| daveshah | Yes, will just be the same old CBIT_n | 20:24 |
| daveshah | What will be needed is the mapping in icebox specifying what the bits actually do (as part of the extra cell stuff) | 20:25 |
| corecode | yea i have that | 20:32 |
| *** sammylin has joined #yosys | 20:40 | |
| sammylin | ERROR: no timing info for port 'Y[4]' of cell type '$alu' | 20:41 |
| sammylin | I used a commandline argument of --freq 16 | 20:41 |
| sammylin | Is there another way I should specify the timing constraints for my clock? | 20:42 |
| corecode | yea it linked | 20:42 |
| corecode | yosys comes tomorrow | 20:42 |
| *** cr1901 has joined #yosys | 20:44 | |
| daveshah | sammylin: there shouldn't be a '$alu' cell going into nextpnr at all | 20:44 |
| daveshah | It's complaining about a lack of timing data because it doesn't know anything at all about that cell type | 20:45 |
| daveshah | What Yosys command are you running? | 20:45 |
| sammylin | nextpnr-ice40 --lp8k --json blinky.json --pcf blinky.pcf --asc blinky.asc --clock 16 | 20:45 |
| tnt | yosys | 20:45 |
| tnt | not nextpnr | 20:46 |
| sammylin | trying to get a blinky VHDL design on the TinyFPGA | 20:46 |
| daveshah | I'm pretty sure this error message was changed to a better one some time ago anyway | 20:46 |
| tnt | sammylin: how did you generate blinky.json ? | 20:47 |
| sammylin | write_json blinky.json | 20:47 |
| tnt | And the rest of the yosys script ? | 20:47 |
| sammylin | is there a way to generate the history of yosys commands? | 20:47 |
| tnt | well ... you entered them didn't you ? | 20:48 |
| daveshah | You should just be able to press up, it uses readline and works like a terminal | 20:48 |
| daveshah | But anyway, you need to run synthesis for iCE40 in order to get something nextpnr can use | 20:48 |
| sammylin | verific -vhdl93 blinky.vhd | 20:48 |
| sammylin | flatten | 20:49 |
| daveshah | You need to run synth_ice40 to synthesise for iCE40 before writing the JSON for nextpnr | 20:49 |
| sammylin | doesn't that call read_verilog? | 20:49 |
| sammylin | after my verific command run synth_ice40? | 20:49 |
| tnt | yes | 20:50 |
| tnt | that will actually do all the mapping from the "base primitives" of yosys to actual cells that exist in the ice40 fpga. | 20:50 |
| sammylin | verific -vhdl93 blinky.vhd | 20:53 |
| sammylin | synth_ice40 -top blinky -json blinky.json | 20:53 |
| sammylin | nextpnr-ice40 --lp8k --json blinky.json --pcf blinky.pcf --asc blinky.asc --clock 16 | 20:53 |
| *** emeb_mac has joined #yosys | 20:54 | |
| sammylin | icepack blinky.asc blinky.bin | 20:54 |
| sammylin | tinyprog -p blinky.bin | 20:54 |
| sammylin | tinyprog -b | 20:54 |
| tnt | isn't it --freq 16 ? | 20:54 |
| daveshah | Yes | 20:54 |
| sammylin | oops, yes. Copied the wrong command | 20:54 |
| daveshah | You probably want --package passed to nextpnr too | 20:54 |
| daveshah | I don't think the default matches the tinyfpga | 20:55 |
| tnt | oh good catch | 20:55 |
| daveshah | --package cm81 is what you want | 20:55 |
| sammylin | Thanks for the help. It's still not blinking :( | 20:59 |
| sammylin | What should I look into? | 20:59 |
| daveshah | Try a Verilog blinky first of all | 21:00 |
| sammylin | Will do. | 21:00 |
| daveshah | If that fails its probably a bad pcf file or something | 21:00 |
| sammylin | Thank you. | 21:00 |
| daveshah | If that works then I'd use Yosys commands like show, dump, write_verilog to see how Yosys is handling the Verific output | 21:01 |
| tnt | sammylin: can you pastebin your pcf and the vhdl ? | 21:04 |
| *** sammylin has quit IRC | 21:07 | |
| *** emeb_mac has left #yosys | 21:13 | |
| *** cr1901 has quit IRC | 21:22 | |
| *** sammylin has joined #yosys | 21:46 | |
| *** gnufan_home has joined #yosys | 21:48 | |
| sammylin | Wooohoo.. blinky works | 21:48 |
| sammylin | Problem with PCF | 21:48 |
| sammylin | So glad I got this working. iCEcube2 kept segfaulting on me. | 21:51 |
| *** sammylin has quit IRC | 22:03 | |
| cr1901_modern | >iCEcube2 kept segfaulting on me. <-- where I have heard this before? | 22:11 |
| cr1901_modern | well anything that uses inferred RAM will choke icecube at least | 22:12 |
| *** gnufan_home has quit IRC | 22:21 | |
| *** _whitelogger has quit IRC | 23:02 | |
| *** _whitelogger has joined #yosys | 23:04 | |
| *** Jybz has quit IRC | 23:20 | |
| *** emeb has quit IRC | 23:50 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
