Thursday, 2019-02-21

*** tpb has joined #yosys00:00
*** seldridge has quit IRC00:12
corecodedaveshah: i don't think i have new IP00:39
corecodeat the moment00:39
*** litghost has joined #yosys00:50
litghostBy default yosys appears to set unset BRAM init parameters to 'x'.  Is there any option or command to force unset/unused BRAM INIT values to 0?00:59
*** seldridge has joined #yosys01:04
*** q3k has quit IRC01:05
*** develonepi3 has quit IRC01:15
ZipCPUlitghost: Why not use a for loop?01:52
ZipCPUSomething like: initial for(k=0; k<RAMLEN; k=k+1) ram[k] = 0;01:53
*** citypw has quit IRC01:56
*** gsi__ has joined #yosys02:00
*** emeb has left #yosys02:00
*** emeb_mac has joined #yosys02:03
litghostWon't work, as the hardware BRAM inference (e.g. memory_bram) is the thing that is introducing the 'x'.  I am fully defined the RAM, but narrower than the underlying BRAM primitive.02:03
*** gsi_ has quit IRC02:03
*** citypw has joined #yosys03:43
*** gsi__ has quit IRC03:45
*** gsi_ has joined #yosys03:51
*** proteusguy has quit IRC03:59
*** Forty-Bot has joined #yosys04:02
ZipCPUlighost: No, that should work04:03
ZipCPUYou aren't running into the issue about not being able to use the iCE40 block RAMs for the first several clock ticks, are you?04:03
*** leviathanch has joined #yosys04:09
*** proteusguy has joined #yosys04:53
*** rohitksingh_work has joined #yosys04:57
*** pie___ has joined #yosys05:06
*** pie__ has quit IRC05:10
MoeIcenowylitghost: add a new step05:13
MoeIcenowyrefer to my code for Anlogic05:13
MoeIcenowythe Anlogic TD tool do not accept 'bx in BRAM/DRAM initialization05:13
*** rohitksingh_work has quit IRC05:26
*** rohitksingh_work has joined #yosys05:27
*** jevinskie has joined #yosys05:36
litghostZipCPU: No, this shows up in the final synthesized output.  The problem is on Xilinx BRAM hardware, which Yosys techmapping an 18-bit wide 1024 deep onto a 16-bit wide 1024 deep primative.  So the upper two bits of each depth is 'x'05:58
litghostMoelcenowy: Which step did you added?  setundef appears to be the right command, but it doesn't seem to affect parameters.  I'm working on a patch to add a -params mode, but unclear if that is the best approach.05:59
litghostMoelcenowy: Any chance you are referring to Moelcenowy?06:07
*** proteusguy has quit IRC06:11
*** _whitelogger has quit IRC06:25
*** _whitelogger has joined #yosys06:27
*** _whitelogger has quit IRC06:39
*** _whitelogger has joined #yosys06:41
*** Cerpin has quit IRC07:21
*** emeb_mac has quit IRC07:24
*** seldridge has quit IRC07:34
*** indy has quit IRC07:59
*** indy has joined #yosys08:08
*** m4ssi has joined #yosys08:32
MoeIcenowylitghost: similar08:45
MoeIcenowyit's anlogic_determine_init what I mentioned08:46
*** MoeIcenowy has quit IRC08:47
*** MoeIcenowy has joined #yosys08:48
*** citypw has quit IRC09:14
*** develonepi3 has joined #yosys11:19
*** leviathanch has quit IRC11:43
*** rohitksingh_work has quit IRC12:15
*** rohitksingh_work has joined #yosys12:17
*** leviathanch has joined #yosys13:16
*** Cerpin has joined #yosys13:25
*** rohitksingh_work has quit IRC13:28
*** rohitksingh has joined #yosys14:19
*** emeb has joined #yosys14:50
*** seldridge has joined #yosys15:24
*** danieljabailey has joined #yosys15:45
*** ylamarre has joined #yosys16:10
*** voxadam has joined #yosys16:12
sxpertlitghost: sounds like yosys uses the wrong primitive then16:34
sxpertdaveshah: if, in a particular always block, I have multiple access to the same distributed memory with the index being generated by a wire, will yosys be able to use one single memory block ?16:46
corecodewhy not16:47
sxpertjust asking if this is the right way to do it16:47
corecodeyes, usually this is how you set defaults16:48
daveshahThis should work, although a separate, explicit memory can never go wrong in any tool16:48
corecodeyou first write defaults, then you voerwrite them16:48
corecodeoverwrite* even16:48
corecodeto prevent latches16:48
sxpertdaveshah: sure, just trying to be the cleanest possible ;-)16:48
corecodethink about how to do it in hardware16:50
*** jevinskie has quit IRC16:50
sxpertwell, I have a wire that is generating the index, with a bunch of | conditions16:51
sxpertassign src1_ptr  = ( {4{copy_address}} & data_counter   | {4{xfr_data_copy}} & xfr_data_ctr  );16:53
sxpertand then16:53
sxpertxfr_data[data_counter] <= A[src1_ptr];16:53
sxpertso, depending on data_counter or xfr_data_copy which are mutually exclusive, I get one or the other16:54
sxperterh, copy_address or xfr_data_copy that is, obviously16:56
corecodewhy do you copy it 4 times?16:57
sxpertso as to generate a mask for all 4 bits of the src1_ptr value16:57
sxpertit seemed the proper thing to do16:58
corecodeso copy_address is a predicate16:58
sxpertit's a particular state in the madness16:58
corecodei've seen this in other designs, but i find it not very readable - maybe there are some asic advantages?16:58
corecodei used conditionals16:59
sxpertcorecode: yeah, but I'm going to have more than 2 at a later stage, conditionals are harder to read at that point16:59
corecodeassign src1_addr = copy_address ? data_counter : xfr_data_counter;16:59
corecodeand bitops are not?17:00
ylamarrecorecode: Though, that wouldn't mask xfr_data_counter if xfr_data_copy is zero...17:00
corecodealways @(*) case(1'b1) copy_address: src1_addr = data_counter; xfr_data_copy: scr1_addr = xfr_data_counter; default: src1_addr = 0; endcase17:01
sxpertylamarre: right17:01
corecodeylamarre: yes, it would not.  maybe necessary, maybe not17:01
ylamarreAgreed, I just wanted to explicit the fact ;)17:01
tpbTitle: forth-cpu/alu.v at master · corecode/forth-cpu · GitHub (at
corecodethis is what i did, no idea whether that's good style or not17:02
sxpertto me this reads like a series of and gates to select the right thing, then an or gate to get the state out17:03
corecodei'm not saying it is wrong17:04
ylamarrecorecode: Watch out for partability, Vivado had trouble with this kind of priority encoding... not sure when/if it was fixed...17:04
corecodei find it harder to understand17:04
sxpertit also feels like telling the compiler what to do exactly17:04
corecodesynthesis tool*17:05
sxpertwhatever ;)17:05
ylamarreIt matters :p17:05
corecodei think they usually blow it up into a big karnaugh map and then reduce it again17:05
corecodejust guessing17:05
*** m4ssi has quit IRC17:05
*** m4ssi has joined #yosys17:06
* sxpert learned digital electronics by blowing up ttl chips 25 or so years ago,,,17:06
sxpertsomehow the teachers hated me ;-)17:07
sxpertsuch as when I told the teacher "why bother with karnaugh maps, just use a memory, put all the inputs on the address bus, and voila, 8 perfectly programmed functions out17:07
sxpertlittle did I know by then... that's what PALs/GALs were made of ;-)17:08
sxpertfunny how an fpga macro cell is pretty close from a 16R4 ;-)17:11
corecodewhy funny17:12
sxpertit's the same stuff from 20+ years ago, shrunk down and copy/pasted 10k times ;)17:14
* sxpert loves delving in history to see how things advanced over time17:16
corecodedaveshah: so what now after the icecube port?17:39
mrecthis ice40up/icecube turns out to be a nightmare17:40
corecodewhat is?17:40
mrecTool unable to find location for GB17:40
mrecI2712: Tool unable to find location for GB dcfx.sfifo.mem_doread_RNI83RD_017:40
mrecwhat should that mean?17:40
mrecthe entire simulation seems to be worthless with it :-(17:41
corecodedo you have a lot of different reset and clock networks?17:48
*** leviathanch has quit IRC17:52
mrecno such problem with radiant18:18
corecodeyea icecube2 fails to place stuff for my design18:19
mrecare there any issues with icecube2 and the ice40up?18:19
corecodeso i'll try yosys18:19
mrecI'm not a fan of the ice40up ... all the other lattice parts seem to be better and have a better simulation18:28
mrecI think I'll just dump that shit ice40up evb...18:28
mrecnonsense product, they better add more memory to the other fpgas18:29
daveshahcorecode: next step if you are happy with the icestorm stuff is nextpnr support. First thing to do is check that icebox_chipdb dumps a text chipdb correctly18:29
daveshahThen it's pretty much a case of looking through nextpnr/ice40 for every up5k specific place and duplicating with necessary changes18:30
*** m4ssi has quit IRC18:43
*** maikmerten has joined #yosys18:43
mrecI wonder why the ice40up synthesis creates randomly different results... to me the lattice synthesis tools for this chip are absolute garbage18:46
mrecthat's what I'm thinking the whole day already18:47
tntheh, I love that fpga, actually pretty capable if you know how to use it. Also never had any issues with the tools really.18:49
*** rohitksingh has quit IRC18:49
mrecme neither but only with xo2, xo3, ecp518:49
mrecalso ice40hx no problem18:49
mrecbut ice40up ... everything's crazy18:49
mrecthe biggest problem is that the simulation doesn't match18:50
tntdoesn't match what ?18:50
mrecI'm sending some data to the fpga and would like to receive some data back, however I get nothing it's stuck at 0V18:52
mrecand the interesting part is after synthesis sometimes it works a little bit but most of the time it doesn't18:52
mrecas long as I won't re-run the synthesis I can keep going with the half working image18:52
mrecwhat a nonsense18:52
tntI'm pretty sure you screwed up something ...18:53
tntI never had any issue that didn't turn out to be my fault.18:53
mrecjust that I cannot figure it out for the entire day...18:54
tntnon-deterministic behavior points to timing issues often since PnR is always a random process that will always yield different result at every run.18:55
tntwhat does the design even do ?18:55
mrecit's supposed to buffer some data18:56
mrechowever I'm very far from that since I cannot even get the communication work at all18:57
tntdoes it meet timing (and is properly constrained) ... are all the IO properly using IO registers and you properly did the setup/hold time analysis with whatever they're connected to .... etc ...18:57
mrecI never had such problems with other fpgas18:57
tntwell if you haven't done what I pre-cited above, you've always done things wrong and that was just dumb luck ... all those step should be standard for any design.18:59
ZipCPUmrec: What type of communication protocol are you trying to implement?19:03
tntwhat hardware, what is it connected to, also, where is the code, ...19:04
*** seldridge has quit IRC19:13
*** seldridge has joined #yosys19:31
*** seldridge has quit IRC20:14
*** seldridge has joined #yosys20:28
*** m4ssi has joined #yosys21:00
*** maikmerten has quit IRC21:29
corecodedaveshah: what's these mystery bits?  how do i know whether i have that also on the ultra?21:52
corecode                if (ctx->args.type == ArchArgs::UP5K && x == 25 && y == 14) {21:52
corecode                    // Mystery bits not set in this one tile21:52
daveshahHave a look at the explain output on an empty design and see if all the tiles have LC_x bits set in dsp and ipconn tiles21:53
daveshahOn the UltraPlus all but one of the dsp and ipconn tiles have these bits set21:53
corecodeFor iCE40UL device, user can configure the internal pull up resistor strength of an IO to a predefined resistor value via attribute settings.21:56
corecodeUL? what about UP and LP (ultra)?21:57
corecodewhy does the tech library documentation say only on UL, but you have it for UP?21:57
daveshahI know the UltraPlus can, because icecube allows you to enable it21:58
daveshahand I've tested it21:58
corecodein the constraints editor i can set pull-up to yes21:58
corecodebut where would i set the strength21:59
daveshahBut not change the value?21:59
corecodenot in the UI21:59
corecodejust yes/no21:59
daveshahThen the Ultra almost certainly has old style pullups not the new selectable strength ones21:59
corecodeso maybe in the docs they wanted to write UP but wrote UL22:00
daveshahUltraLite has them too22:00
corecodewhat are the chances that UP and UL have it, and LP doesn't?22:00
daveshahUL came before UP, so I think it's more likely they just never updated the docs after the UP release22:00
daveshahQuite likely, as UL came after iCE5LP22:01
corecodei guess i should try changing the pcf22:01
corecodeand see what happens22:01
daveshahadd -pullup_resistor 3P3K and see if any cf_bits appear in the explain22:02
corecodeinteresting, we don't have any existing test22:03
daveshahNo, I think my testing of that was very impromptu22:05
corecodeok, doesn't seem to change anything22:06
corecodei'm surprised that icecube doesn't complain22:07
daveshahDo you also have -pullup yes?22:07
daveshahYeah, it's funny that icecube accepts it then22:08
*** m4ssi has quit IRC22:09
corecodehey, it just discarded my input22:10
corecodeand therefore the pullup22:10
corecodeso R_EN is 1 when there is no pullup?22:11
corecodeyea, doesn't look like there is any effect when i set -pullup yes -pullup_resistor 3P3K22:14
corecodeset_io pin 2 -pullup yes -pullup_resistor 3P3K22:14
daveshahcorecode: yes, REN is negative logic22:15
daveshahThis means an empty bitstream or unconfigured device has all IO pins pulled up by default22:15
corecodei'm not a fan of default pullup, but okay22:17
daveshahIt's a weak pullup, nominally 100k, FWIW22:18
daveshahProbably consumes less current than a floating IO pin22:18
corecodebut it means that you need to have some stronger pull-down to prevent positive logic from triggering22:18
corecodesomething connected22:18
corecodei had some silly effects with MCUs that would come up from reset with pull-up enabled22:19
corecodeand we got a very brief flash of bright white light from the connected LEDs :)22:19
corecodeok, no pullups as i can tell22:20
corecodehuh, the mystery bits are just set in ipcon tiles, but only 0-4 and 17-2022:24
corecodeand the DSPs don't seem to have anything set by default22:24
tpbTitle: empty.tcl · GitHub (at
corecodemodule top;endmodule22:25
daveshahIt could be that the mystery bits are only set when the DSP is used22:25
daveshahI remember on the UltraPlus I tried removing them out of curiosity and the DSPs wouldn't work22:27
corecodeah yes22:27
corecodedo i have to care about ip_dsp_lut_perm?22:28
daveshahNo, that is obviously the same looking at that output22:29
corecodewhat does that permutation do?22:30
daveshahFor both real LUTs and the fake LUTs in the mystery bits (which are always a pass through from in2), there is a permutation from LUT init bit index to LC_i bit index22:31
daveshahJust to do with how the iCE40 bitstream is laid out22:31
corecodenow, how do i know whether some ipcon tiles will maybe get these mystery bits set?22:32
corecodebecause half of the ipcon tiles don't have bits set22:32
daveshahThey might be set if you use an IP that is routed through one of those tiles22:33
daveshahYou'd have to know the IP routing first though22:33
corecodeso do i just always set the bits?22:34
daveshahAt worst, setting them unnecessarily will probably slightly increase power consumption22:35
corecodewhere do i get the delay data from?22:37
daveshahOnce nextpnr is up and running you can use this script:
tpbTitle: nextpnr/ at master · YosysHQ/nextpnr · GitHub (at
daveshahIf the basic delays that icefuzz found are the same as the up5k, then you can just use the up5k ones22:39
corecodeand clktoq i get from the datasheet?22:40
daveshahNo, clktoq you get from the timings_*.txt file22:45
daveshahFind the max IOPATH delay from posedge:clk to lcout22:46
daveshahThe HTML might be easier to work with than the raw txt, if you prefer22:47
corecodeah, they get extracted out of icecube as well?22:47
corecodebecause i couldn't run them without yosys working22:47
daveshahYosys shouldn't need any changes22:48
daveshahIf it hits any unknown cell types then you'll need to add them directly to the timing edge extracted script:
tpbTitle: icestorm/tmedges.ys at master · cliffordwolf/icestorm · GitHub (at
*** tpb has joined #yosys22:52
corecodeso i guess to build nextpnr i first need to do yosys22:56
corecodetower of yakilon22:56
daveshahFrom memory the calls made to Yosys by the timing fuzzer are just to get the edge combinations which are shown in the HTML22:57
daveshahThey aren't actually needed to build the data nextpnr needs22:58
daveshahBut you need Yosys for a useful flow so might as well build and install it now22:58
corecodeyea i need yosys to get the timing html22:59
corecodeERROR: Module `\SMCCLK' referenced in module `\top' in cell `\internalOscilator' is not part of the design.23:24
corecodewhat does it try to tell me?23:24
corecode(make timings)23:24
daveshahYou'll need to add SMCCLK and its ports to this file
tpbTitle: icestorm/tmedges.ys at master · cliffordwolf/icestorm · GitHub (at
daveshahCan you post the timing netlist verilog that has caused this error? I can't see why SMCCLK would be appearing at all23:25
corecodeyea, that's what i am wondering23:26
daveshahI've never looked into it in great detail, but I think it provides the internal configuration clock23:26
tpbTitle: aig_00.vsb · GitHub (at
daveshahCan you post a netlist for one of the smaller designs? Maybe fanout or binop23:30
daveshahThis is not something that I've seen in any other ice4023:30
tpbTitle: binop_00.vsb · GitHub (at
corecodewhat's the legalize business23:32
daveshahSo it looks like there's a D flipflop with D connected to 1 (ie a LUT init of all 1s) and clk to the SMCCLK CLK output, driving the output enable of an IO23:32
daveshahI've not seen this before, but it reeks of silicon bug specific to the Ultra23:33
daveshahProbably because IO were being enabled slightly too early during startup and glitching23:33
corecodei've seen this before in the logs23:34
corecode    Number of inserted LUTs to Legalize IOs with PIN_TYPE= 01xxxx  :123:34
corecodethis is with the latest icecube23:34
corecodemaybe an older icecube wouldn't do this?23:35
daveshahCould be23:35
corecodelet me run that for up5k23:35
daveshahI've not seen it for up5k and I was using latest icecube2 I think23:36
corecodethat is correct23:47
corecodethis is crazy!23:47
corecodei wonder what happens if you don't do that step23:48
daveshahYou found a mystery CBIT in the bitstream, right? That could be related23:48
corecodei don't see that cbit anymore23:51
corecodeit could have been the dsp error23:51
daveshahYeah, possible23:51
daveshahI doubt that the SMCCLK behaviour will need to be replicated in nextpnr initially to get something working23:52
daveshahIn the long term, it might be needed if icecube is adding it to work around a genuine issue23:52
corecodeyea i doubt it too - that's something they would have caught23:53
corecodethere is one bit set in ipcon 25 323:54
corecodelet's see what explain says23:54
daveshahGiven that every iCE40 has had slightly broken BRAM startup I wouldn't be so sure23:55
corecodebuffer slf_op_5 sp12_h_r_223:56
daveshahThat looks like the routing from the SMCCLK output23:57
daveshahIP always uses slf_op_i in ipcon tiles for outputs23:58
corecodeso now we know where the internal oscillator sits :)23:58
daveshahWell, not the user internal oscillators but the secret mystery one :D23:59
corecodeyes exactly23:59
daveshahMight as well add it to the icebox cells list anyway23:59
corecodeheh i found something new!23:59

Generated by 2.13.1 by Marius Gedminas - find it at!