Sunday, 2019-06-09

*** tpb has joined #yosys00:00
*** cr1901 has quit IRC00:15
*** cr1901 has joined #yosys00:16
*** emeb_mac has joined #yosys01:04
*** gsi__ has joined #yosys01:28
*** gsi_ has quit IRC01:31
*** gnufan_home has quit IRC01:59
*** Cerpin has quit IRC02:17
*** pacak has quit IRC02:52
*** diakopter has joined #yosys02:53
*** emeb has quit IRC02:53
*** PyroPeter has quit IRC03:04
*** pacak has joined #yosys03:04
*** PyroPeter has joined #yosys03:17
*** Cerpin has joined #yosys03:18
*** Cerpin has quit IRC03:37
*** Cerpin has joined #yosys03:37
*** diakopter has left #yosys03:46
*** Cerpin has quit IRC03:53
*** _whitelogger has quit IRC04:50
*** _whitelogger has joined #yosys04:52
*** gsi__ is now known as gsi_04:58
*** citypw has joined #yosys05:30
*** futarisIRCcloud has quit IRC05:36
*** _whitelogger has quit IRC06:02
*** _whitelogger has joined #yosys06:04
*** rohitksingh has joined #yosys06:29
*** rohitksingh has quit IRC07:09
*** GoldRin has quit IRC07:22
*** rohitksingh has joined #yosys07:29
*** emeb_mac has quit IRC07:30
*** rohitksingh has quit IRC07:45
*** rohitksingh has joined #yosys07:45
*** maikmerten has joined #yosys07:55
corecodedaveshah: i'm trying to add LED_DRV / RGB_DRV support for u4k08:32
corecodethe issue is that LED_DRV_CUR is a separate instance08:32
corecodeso somehow i need to tease apart which bits are for LED_DRV_CUR and which are for RGB_DRV08:33
daveshahcorecode: Is LED_DRV_CUR used for anything else?08:34
corecodealso for IR_DRV08:34
daveshahIf so you could see which bits are common in the two usages08:34
corecodebut i don't think i have that for my package08:34
corecodeneed to look again08:35
daveshahGuess you might need to use a different package for that test08:37
corecodei wonder what the point of this is08:38
corecodeit has an output signal08:38
corecodeand that signal can only be routed to either RGB_DRV or IR_DRV08:38
*** citypw has quit IRC08:38
daveshahIt almost seems like leaking their implementation detail into user designs08:39
corecodei wonder whether i can somehow force synthesis and placer to keep the LED_DRV_CUR without connecting anything to it08:45
corecodemaybe with an explicit place?08:46
daveshahYou can put a placement constraint in the pcf file but that won't stop it removing things08:51
daveshahPutting (* keep *) on it might work but I've never tried08:51
corecodeit looks like the LED_DRV_CUR is exactly the same location (modulo size) as CURREN is08:52
daveshahOh that's odd. Same z too?08:53
corecode        (25, 19, "CBIT_5")08:54
daveshahInteresting, the UltraPlus sets CBIT_5 in a tile on the other side of the device (0, 28, CBIT_5) when the RGB driver is used08:58
daveshahIs 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,1908:59
*** rohitksingh has quit IRC09:17
corecode        (0, 18, "CBIT_5")09:28
corecodeas well09:28
corecodehm nevermind09:29
*** rohitksingh has joined #yosys09:39
*** _whitelogger has quit IRC09:56
*** _whitelogger has joined #yosys09:58
*** Jybz has joined #yosys10:25
*** proteusguy has quit IRC10:56
*** futarisIRCcloud has joined #yosys10:57
*** proteusguy has joined #yosys11:08
*** _whitelogger has quit IRC12:53
*** _whitelogger has joined #yosys12:55
*** dys has quit IRC13:06
*** _whitelogger has quit IRC13:44
*** _whitelogger has joined #yosys13:46
*** futarisIRCcloud has quit IRC13:56
*** lutsabound has joined #yosys14:06
*** _whitelogger has quit IRC14:17
*** _whitelogger has joined #yosys14:19
*** dys has joined #yosys14:36
*** maikmerten has quit IRC15:20
corecodedaveshah: i forgot, how do i visualize the placer results of icestorm?15:31
corecodei want to know verify lutff is connected to which io pad15:31
daveshahcorecode: use nextpnr --gui15:31
corecodei mean the result from icecube15:35
corecodenot from nextpnr15:36
daveshahOh, it's called something like "floorplan" or "physical" view15:37
daveshahHaven't used icecube for a while though15:37
corecodeyea but somehow i can't synthesize after opening the project15:40
corecodehm, but i can't see what path it takes15:47
corecodeso how do i trace these connections?15:49
*** cr1901 has quit IRC15:54
corecodei.e. the sequence of routing and buffers15:54
*** cr1901 has joined #yosys15:54
*** citypw has joined #yosys16:01
*** cr1901 has quit IRC16:06
*** cr1901 has joined #yosys16:11
*** citypw has quit IRC16:19
*** emeb has joined #yosys16:21
daveshahcorecode: icecube doesn't any view of the routing16:33
daveshahicebox_explain and icebox_vlog will have to do...16:34
*** cr1901 has quit IRC16:38
*** cr1901 has joined #yosys16:39
*** cr1901 has quit IRC16:44
corecodeso... what to do with this silly output16:56
corecodewhich doesn't seem to be routed?16:56
corecodeit's as if there is no LEDPU output17:04
corecodeit's just a fake, not a real signal?17:04
tpbTitle: sb_rgb_drv.v · GitHub (at
tpbTitle: sb_rgb_drv.tcl · GitHub (at
corecodetcl eh?17:05
emebthe strange relationship between SB_LED_DRV_CUR and SB_RGB_DRV has always puzzled me17:06
*** cr1901 has joined #yosys17:10
corecodeseems shoehorned in17:11
corecodewhy is there this enable pin?17:12
corecodeah maybe otherwise the synthesis tool will throw it away17:12
emebmaybe for power mgmt?17:12
corecodeone is the constant current somethingsoemthing17:12
corecodethe other the specific LED drivers17:13
emebright, but the current source may pull some power and shutting it down may help reduce sleep power.17:13
corecodeand by having a virtual signal go from one to the other, the synthesizer can't optimize it away17:13
emebthe 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
corecodeyea also the vlog doesn't show anything17:19
corecodenor does the exp17:19
corecodei think it's purely virtual17:20
corecodepreviously it was part of the RGBA17:20
corecodenow it is in a separate instance17:20
emebyep - and in ultralite and ultraplus it's rolled into the other cores.17:20
emebprobably a consequence of the failed pwm core on ultra17:21
corecodei think in the ul/up they decided to not have that silly extra instance and instead use the same enable signal twice?17:23
corecodei guess we won't find out - ir400_drv periph is not mapped in icebox17:26
emebheh - not much point in pursing that then.17:27
corecodenot at the moment17:27
emebthat thing is scary anyway :)17:27
*** cr1901_modern has joined #yosys17:36
tntIt's split probably because it's shared and so that's their way to reflect it in HDL.17:40
corecodedo ul/up only have either ir or rgb?17:41
tntup only has RGB.17:41
*** cr1901 has quit IRC17:41
corecodecan somebody explain what nextpnr's ice40/ does?17:42
corecodethe disconnect all external ports17:42
corecodeis that checking whether the RGB* ports are connected elsewhere?17:42
corecodei guess it does17:42
tntThere is no real wires connection that block to the IO pins.17:43
corecodeso, it is called SB_RGB_DRV for the ultra17:43
tntNot normal routing anyway.17:43
tntSo we remove those wires in nextpnr.17:44
corecodehow do i best modify nextpnr?17:44
corecodei mean, naming wise17:44
corecodemost of the code applies as well to the ultra17:44
tntMaybe a generic is_sb_anyled_drv ?17:50
tntthat would cover sb_ir500_drv / sb_barcode_drv / sb_ir400_drv / sb_ir_drv / sb_rgba_drv / sb_rgb_drv17: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
corecodei don't feel comfortable extending this to IR17:53
corecodenot in this change17:53
tntwell you can just put all the 'non tested / supported' ones in /* */17:53
corecodei wonder what i have to do to get the rgb_drv bits into the chipdb17:54
corecodehow does create_ice_cell() get called for SB_RGBA_DRV?18:01
tntIt doesn't ?18:03
tntThe cell is already there in the .json when loading.18:03
corecodeso why is there code?18:04
tntcreate_ice_cell is called when conversing from one cell type to another. Like SB_DSP16 -> ICESTORM_DSP18:04
emeb800x600 65 color vga from a up5k with 6502 + BASIC ->
tpbTitle: Dropbox - 0609191105.jpg - Simplify your life (at
emeberr... 64 color :P18:23
tntemeb: :)18:29
emebfrankly, the composite NTSC w/ color was more challenging than VGA, even though VGA looks better.18:30
tntWell yeah, not surprising, ntsc was made for analog stuff ...18:31
tntvga even though the signal itself is analog is way closer to what digital interface video looks like.18:32
corecodeso how do i test whether a port is connected to a bel18:32
tntcorecode: huh ? What are you trying to check ?18:33
corecodewhether the LEDPU port from LED_DRV_CUR is connected to RGB_DRV18:35
tntBasically 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
corecodeand do i erase the net?18:39
tntYeah since it's not a normal net.18:41
corecodebut then if i delete it, i can't test it in the other cell18:45
tntYeah, you'd basically do the test/delete in only one of the cell.18:46
emebset a private flag "I deleted LEDPU" and test for that?18:46
corecodeah hang on18:47
corecodethe cells are sorted18:47
corecodeso one is always processed before the other18:47
corecodelexical sort?18:47
corecodei guess bellid index18:55
corecodeah no, idstring18:57
corecodei think the better choice is a flag, yes19:02
corecodewhat happens if i erase a net, but not all ports connected to it?19:05
tntwell you must not delete the port, but you need to disconnect them.19:07
tntif not ... assert / segfault / general pain and badness.19:07
corecodeError::Illegal Connection: Pin 'RGBPU' of instance 'RGB_DRV' of type 'RGB_DRV' should be  driven by 'LEDPU' pin of 'LED_DRV_CUR' type instance19:10
corecodeso that's the message icecube spits out when you wire up 019:11
corecodehowever, if you don't wire up anything (don't mention the port), you don't get an error19:11
corecodebut somehow the LED_DRV_CUR instance is being optimized away then19:11
corecode            ci->ports.erase(ctx->id("RGB0"));19:12
corecodeso what's that then?19:12
*** rohitksingh has quit IRC19:13
*** lutsabound has quit IRC19:15
*** AlexDaniel has joined #yosys19:16
*** lutsabound has joined #yosys19:25
corecodehm, do i need to make a new ipcon_u4k db?19:59
corecodeor do i dump stuff into the 5k?19:59
daveshahcorecode: what do you need to add?20:02
corecodethe RGB_DRV20:02
daveshahWhat bits does it add to that database?20:03
corecodei don't know20:03
corecodei'm struggling with icefuzz's Makefile20:03
corecodei need to dump the bits somewhere20:03
daveshahIf its just some extra config bits then it's fine just to use the 5k one20:04
corecodehm i don't know how i can get these bits extracted20:18
corecodemistakes were made20:18
corecodeah no20:19
corecodederp, of course no new bits show up, because the same bits are already used under a different name20:23
daveshahYes, will just be the same old CBIT_n20:24
daveshahWhat will be needed is the mapping in icebox specifying what the bits actually do (as part of the extra cell stuff)20:25
corecodeyea i have that20:32
*** sammylin has joined #yosys20:40
sammylinERROR: no timing info for port 'Y[4]' of cell type '$alu'20:41
sammylinI used a commandline argument of --freq 1620:41
sammylinIs there another way I should specify the timing constraints for my clock?20:42
corecodeyea it linked20:42
corecodeyosys comes tomorrow20:42
*** cr1901 has joined #yosys20:44
daveshahsammylin: there shouldn't be a '$alu' cell going into nextpnr at all20:44
daveshahIt's complaining about a lack of timing data because it doesn't know anything at all about that cell type20:45
daveshahWhat Yosys command are you running?20:45
sammylinnextpnr-ice40 --lp8k --json blinky.json --pcf blinky.pcf --asc blinky.asc --clock 1620:45
tntnot nextpnr20:46
sammylintrying to get a blinky VHDL design on the TinyFPGA20:46
daveshahI'm pretty sure this error message was changed to a better one some time ago anyway20:46
tntsammylin: how did you generate blinky.json ?20:47
sammylinwrite_json blinky.json20:47
tntAnd the rest of the yosys script ?20:47
sammylinis there a way to generate the history of yosys commands?20:47
tntwell ... you entered them didn't you ?20:48
daveshahYou should just be able to press up, it uses readline and works like a terminal20:48
daveshahBut anyway, you need to run synthesis for iCE40 in order to get something nextpnr can use20:48
sammylinverific -vhdl93 blinky.vhd20:48
daveshahYou need to run synth_ice40 to synthesise for iCE40 before writing the JSON for nextpnr20:49
sammylindoesn't that call read_verilog?20:49
sammylinafter my verific command run synth_ice40?20:49
tntthat will actually do all the mapping from the "base primitives" of yosys to actual cells that exist in the ice40 fpga.20:50
sammylinverific -vhdl93 blinky.vhd20:53
sammylinsynth_ice40 -top blinky -json blinky.json20:53
sammylinnextpnr-ice40 --lp8k --json blinky.json --pcf blinky.pcf --asc blinky.asc --clock 1620:53
*** emeb_mac has joined #yosys20:54
sammylinicepack blinky.asc blinky.bin20:54
sammylintinyprog -p blinky.bin20:54
sammylintinyprog -b20:54
tntisn't it --freq 16 ?20:54
sammylinoops, yes.  Copied the wrong command20:54
daveshahYou probably want --package passed to nextpnr too20:54
daveshahI don't think the default matches the tinyfpga20:55
tntoh good catch20:55
daveshah --package cm81 is what you want20:55
sammylinThanks for the help.  It's still not blinking :(20:59
sammylinWhat should I look into?20:59
daveshahTry a Verilog blinky first of all21:00
sammylinWill do.21:00
daveshahIf that fails its probably a bad pcf file or something21:00
sammylinThank you.21:00
daveshahIf that works then I'd use Yosys commands like show, dump, write_verilog to see how Yosys is handling the Verific output21:01
tntsammylin: can you pastebin your pcf and the vhdl ?21:04
*** sammylin has quit IRC21:07
*** emeb_mac has left #yosys21:13
*** cr1901 has quit IRC21:22
*** sammylin has joined #yosys21:46
*** gnufan_home has joined #yosys21:48
sammylinWooohoo.. blinky works21:48
sammylinProblem with PCF21:48
sammylinSo glad I got this working.  iCEcube2 kept segfaulting on me.21:51
*** sammylin has quit IRC22:03
cr1901_modern>iCEcube2 kept segfaulting on me. <-- where I have heard this before?22:11
cr1901_modernwell anything that uses inferred RAM will choke icecube at least22:12
*** gnufan_home has quit IRC22:21
*** _whitelogger has quit IRC23:02
*** _whitelogger has joined #yosys23:04
*** Jybz has quit IRC23:20
*** emeb has quit IRC23:50

Generated by 2.13.1 by Marius Gedminas - find it at!