| *** tpb has joined #yosys | 00:00 | |
| daveshah | I wonder if the UltraPlus has a SMCCLK primitive too | 00:00 |
|---|---|---|
| corecode | is it (25, 3, 0) or (25, 3, 1)? | 00:01 |
| daveshah | z doesn't matter for functional purposes so long as its unique within a tile | 00:02 |
| daveshah | If it appears in icecube floorplan view, use the coordinates that gives | 00:02 |
| daveshah | Otherwise, the first free z index in 25, 3 | 00:02 |
| corecode | it just says IpConn tile | 00:02 |
| daveshah | Doesn't matter then - the only other place z is used is constraints, but that's kind of irrelevant for a cell that is one per device | 00:03 |
| corecode | ok | 00:03 |
| corecode | so how do i test whether this is recorded right in icebox | 00:04 |
| daveshah | There isn't really a way for these primitives | 00:04 |
| daveshah | Need to get round to proper extra cell support in icebox_vlog at some point | 00:05 |
| corecode | okay | 00:06 |
| corecode | man i need to disable my clean up trailing space on save | 00:07 |
| corecode | it adds so much churn that i have to remove | 00:07 |
| corecode | ok | 00:10 |
| corecode | so now i need to modify yosys | 00:10 |
| corecode | ah no, it's in icefuzz still | 00:11 |
| corecode | nice | 00:12 |
| daveshah | Eventually you'll want to add blackboxes for these new cell types to https://github.com/YosysHQ/yosys/blob/master/techlibs/ice40/cells_sim.v | 00:12 |
| tpb | Title: yosys/cells_sim.v at master · YosysHQ/yosys · GitHub (at github.com) | 00:12 |
| daveshah | But no urgency | 00:12 |
| *** seldridge has quit IRC | 00:27 | |
| *** emeb has left #yosys | 00:32 | |
| *** emeb_mac has joined #yosys | 00:49 | |
| corecode | meh, now i'm fighting with cmake | 00:59 |
| corecode | aha! | 01:00 |
| corecode | existing bug | 01:00 |
| emeb_mac | corecode: how goes the LP4k work? | 01:11 |
| corecode | in nextpnr now | 01:15 |
| corecode | hm what's this pi_eb_bank that i can't find in glbinfo now? | 01:16 |
| *** seldridge has joined #yosys | 01:16 | |
| corecode | aha | 01:18 |
| corecode | i need to make up padin bits | 01:18 |
| *** leviathanch has joined #yosys | 01:22 | |
| *** gsi__ has joined #yosys | 01:58 | |
| *** gsi_ has quit IRC | 02:01 | |
| corecode | okay | 02:14 |
| corecode | daveshah: yea i don't know where i get the io_clktoq from | 02:26 |
| corecode | or the model params | 02:29 |
| *** AlexDaniel has quit IRC | 02:35 | |
| *** citypw has joined #yosys | 04:10 | |
| *** rohitksingh_work has joined #yosys | 04:12 | |
| *** pie__ has joined #yosys | 05:05 | |
| mrec | I'm doing some serial communication however the results differ from synthesis to synthesis and that's not only confusing but wrong | 05:06 |
| mrec | I guess there's some bug in the synthesis tool itself otherwise the result wouldn't be random | 05:06 |
| mrec | and I highly doubt that this has anything to do with setup/hold/propagation delays | 05:07 |
| mrec | random in terms of .. it's stable for the image (even if I reload it) but if I do the synthesis again the result might be unexpected in another way | 05:08 |
| *** pie___ has quit IRC | 05:09 | |
| mrec | I'm transferring some frames, the first value of the frame should be static, one line is used for synchronisation how comes that the static value is different from time to time if it is there at all | 05:09 |
| mrec | I never had such a basic issue with any other lattice part so I guess the ice40up5k is shit | 05:11 |
| mrec | looking at the rtl ... it's even synthesising things which it should cut out ... no no this thing is so wrong | 05:13 |
| mrec | it feels like when counting from 1 to 10 things break at 1 | 05:20 |
| mrec | what a damn shit part ... it's like if rising_edge(shitclock) then if iter=2 then output<='1' else output <='0' end if; end if; is not working | 05:25 |
| mrec | iter++ of course | 05:25 |
| mrec | whatever it's so basic that it is impossible to fail normally | 05:25 |
| *** proteusguy has joined #yosys | 05:40 | |
| emeb_mac | iin my experience when the synthesized design isn't doing what I expect it's usually down to me not having fully understood something. | 05:50 |
| MoeIcenowy | mrec: try Lattice Radient or iCEcube2? | 06:31 |
| MoeIcenowy | if it works with them, but not with Yosys/NextPnR/Icestorm | 06:31 |
| MoeIcenowy | it's a severe bug | 06:31 |
| *** seldridge has quit IRC | 07:05 | |
| *** proteusguy has quit IRC | 07:13 | |
| *** emeb_mac has quit IRC | 07:28 | |
| *** proteusguy has joined #yosys | 07:46 | |
| *** m4ssi has joined #yosys | 08:12 | |
| daveshah | corecode: have you got timing html file? | 08:28 |
| *** proteusguy has quit IRC | 08:42 | |
| *** rohitksingh_work has quit IRC | 08:59 | |
| *** rohitksingh_work has joined #yosys | 08:59 | |
| *** rohitksingh_work has quit IRC | 09:37 | |
| *** citypw has quit IRC | 10:09 | |
| corecode | yes | 10:31 |
| *** indy has quit IRC | 10:35 | |
| corecode | daveshah: i only see propagation delays and timing checks | 10:53 |
| *** danieljabailey has quit IRC | 10:55 | |
| tnt | mrec: just pastebin the exact code you're trying to run ... | 10:55 |
| daveshah | corecode: what you want is the propogation delay from posedge:clk to lcout | 11:12 |
| daveshah | in LogicCell40 | 11:12 |
| corecode | ooh, i thought it is for SB_IO | 12:21 |
| corecode | 1050, it says | 12:22 |
| corecode | somehow i have all propagation delays twice | 12:25 |
| corecode | odd | 12:25 |
| daveshah | Can you post the file? From memory if icecube.sh isn't creating the project correctly then icecube can produce funny timings | 12:26 |
| corecode | sure | 12:26 |
| corecode | will the txt file suffice? | 12:26 |
| corecode | https://gist.github.com/9a4d54c71b0a8b76a97ace0db40ecc13 | 12:26 |
| tpb | Title: timings_u4k.txt · GitHub (at gist.github.com) | 12:26 |
| corecode | https://gist.github.com/65ca9a2e2bab676cc78de31e5b9d50d6 | 12:27 |
| tpb | Title: timings_up5k.txt · GitHub (at gist.github.com) | 12:27 |
| corecode | to compare | 12:27 |
| daveshah | I think this is a project problem, usually suspiciously round timings are a sign of this | 12:27 |
| corecode | :) | 12:28 |
| corecode | so what can i do? | 12:28 |
| daveshah | Make sure these lines: https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/icecube.sh#L442-L443 are creating a project file set up the same way as one from the icecube gui | 12:28 |
| tpb | Title: icestorm/icecube.sh at master · cliffordwolf/icestorm · GitHub (at github.com) | 12:28 |
| corecode | aaah | 12:28 |
| daveshah | You'll also need to clear the timing file after making the fix | 12:29 |
| corecode | do i need to run any other tests again after fixing this? | 12:37 |
| daveshah | No, just the main icefuzz | 12:37 |
| daveshah | It only affects timing, nothing bitstream wise | 12:37 |
| corecode | do i have to clear the runs? | 12:38 |
| corecode | the work_* | 12:38 |
| daveshah | yes | 12:38 |
| corecode | aha | 12:38 |
| corecode | oka | 12:38 |
| corecode | daveshah: i can't find the timings in nextpnr in the 5k file | 12:52 |
| daveshah | corecode: wait, is this the IO timing? | 13:10 |
| daveshah | then it should be PRE_IO, sorry | 13:10 |
| corecode | there are two places with timing | 13:15 |
| corecode | SB_IO, and the lut model | 13:15 |
| *** rohitksingh has joined #yosys | 13:17 | |
| daveshah | lut model? | 13:17 |
| daveshah | you mean delay.cc? | 13:17 |
| *** voxadam has quit IRC | 14:14 | |
| *** voxadam has joined #yosys | 14:15 | |
| *** m4ssi has quit IRC | 14:19 | |
| *** m4ssi has joined #yosys | 14:20 | |
| *** rohitksingh has quit IRC | 14:24 | |
| *** rohitksingh has joined #yosys | 14:26 | |
| *** emeb has joined #yosys | 14:33 | |
| *** rohitksingh has quit IRC | 14:35 | |
| *** danieljabailey has joined #yosys | 14:56 | |
| corecode | yes | 15:07 |
| *** citypw has joined #yosys | 15:29 | |
| corecode | okay | 15:34 |
| corecode | now i need to test a simple design | 15:34 |
| * corecode goes on to learn how to use yosys and nextpnr | 15:34 | |
| corecode | daveshah: i'm getting | 15:52 |
| corecode | ERROR: Unable to place cell 'hfosc_OSC' of type 'ICESTORM_HFOSC' | 15:52 |
| corecode | 15:52 | |
| corecode | but i can't find a place in nextpnr where i forgot to add it | 15:53 |
| corecode | it's in the chipdb | 15:55 |
| tnt | corecode: do you have your chipdb somewhere ? | 15:57 |
| corecode | https://github.com/cliffordwolf/icestorm/pull/202/files#diff-01d30693ba825e93970aa144628a817d | 16:01 |
| tpb | Title: iCE40 Ultra = iCE5LP = u4k port by corecode · Pull Request #202 · cliffordwolf/icestorm · GitHub (at github.com) | 16:01 |
| corecode | https://raw.githubusercontent.com/cliffordwolf/icestorm/c3f9d29a679e1a7bb01562f25661de7414139608/icebox/chipdb-u4k.txt | 16:01 |
| corecode | better | 16:01 |
| daveshah | corecode: fyi, we don't check in the chipdb-*.txt files | 16:02 |
| corecode | oh | 16:02 |
| corecode | that explains why git grep didn't find it | 16:02 |
| daveshah | HFOSC in there looks fine | 16:03 |
| tnt | yeah. You did rebuild nextpnr right ? | 16:03 |
| daveshah | If you look at that tile under "Bels" in the GUI sidebar opened for u4k, do you see it? | 16:03 |
| corecode | yes | 16:07 |
| corecode | X0/Y21/hfosc_1, type ICESTORM_HFOSC | 16:07 |
| daveshah | looks good | 16:07 |
| corecode | there is no cell drawn tho | 16:09 |
| corecode | in the ui | 16:09 |
| daveshah | no, that's fine | 16:09 |
| corecode | ok | 16:10 |
| daveshah | can you try setting z to zero? | 16:10 |
| corecode | "yea, but..." | 16:10 |
| corecode | what about the 5k | 16:10 |
| corecode | hm | 16:10 |
| corecode | the error comes from cell_place_unique | 16:11 |
| daveshah | I think the importer needs z to be contiguous from zero in a tile | 16:12 |
| corecode | and either it's not in ctx->getBels, or its type isn't right, or it is locked | 16:12 |
| corecode | aha | 16:12 |
| corecode | aaaah | 16:12 |
| corecode | feels more like we should change the importer... | 16:13 |
| tnt | the importer ? you mean chipdb.py ? | 16:14 |
| corecode | well, whatever you call the importer | 16:15 |
| corecode | i guess the problem is that i don't have the i2c cell in icepack yet | 16:15 |
| daveshah | although I can't see why they would be a problem either | 16:16 |
| daveshah | ultraplus seems to have some non-contiguous zs already in fact | 16:17 |
| daveshah | never mind that idea | 16:17 |
| tnt | if it shows in the gui, it should be in the blob right ? | 16:17 |
| daveshah | yup | 16:17 |
| corecode | yea, it's not in getBels() | 16:34 |
| corecode | LFOSC isn't there either | 16:35 |
| corecode | or SMCCLK | 16:35 |
| corecode | only warmboot is | 16:35 |
| corecode | feels like the wrong chip type | 16:36 |
| corecode | i guess the json file doesn't contain the target | 16:36 |
| corecode | and i need to pass it in the command line | 16:37 |
| corecode | derp | 16:37 |
| daveshah | Yeah | 16:37 |
| tnt | lol | 16:37 |
| corecode | well, there is the nice .proj file | 16:38 |
| corecode | i thought it would be picked up | 16:38 |
| corecode | but evidently not? | 16:39 |
| daveshah | No, the JSON is device independent | 16:39 |
| daveshah | It is mapped to a family (ie iCE40) rather than specific device | 16:39 |
| daveshah | A proj file should contain the device type though | 16:39 |
| MoeIcenowy | json by yosys? | 16:40 |
| daveshah | Yeah | 16:40 |
| MoeIcenowy | BTW is the standard of the json output by yosys available? | 16:40 |
| MoeIcenowy | or is it used by any other EDA tool? | 16:40 |
| MoeIcenowy | (except Yosys/NextPnR | 16:40 |
| daveshah | There is http://www.clifford.at/yosys/cmd_write_json.html | 16:40 |
| tpb | Title: Yosys Open SYnthesis Suite :: Command Reference :: write_json (at www.clifford.at) | 16:40 |
| MoeIcenowy | BTW the EDIF output of Yosys is not usable in iCEcube2 ( | 16:41 |
| daveshah | I know | 16:41 |
| daveshah | EDIF isn't really a standard | 16:41 |
| MoeIcenowy | and the VQM output of Yosys is not usable in Quartus Prime | 16:41 |
| daveshah | Yosys outputs the Xilinx flavour, more or less | 16:41 |
| MoeIcenowy | (seems mainly about altsyncram | 16:42 |
| daveshah | I don't think that should be too hard to fix | 16:42 |
| MoeIcenowy | but it seems strange | 16:42 |
| tnt | https://github.com/YosysHQ/nextpnr/issues/206 is a serious limitation of that json fmt for the moment :/ | 16:43 |
| tpb | Title: Port defined like d[9:2] is not indexed correctly when used in pcf file · Issue #206 · YosysHQ/nextpnr · GitHub (at github.com) | 16:43 |
| corecode | so what is this .proj file for? | 16:43 |
| MoeIcenowy | daveshah: is commercial synthesis tool all customized for a certain PnR toolchain? | 16:44 |
| daveshah | corecode: the .proj file is mostly for projects created in the GUI | 16:44 |
| MoeIcenowy | e.g. Synplify Pro | 16:44 |
| daveshah | MoeIcenowy: I think Lattice have some custom shims for compatability | 16:45 |
| daveshah | tnt: I keep pestering clifford to fix the Yosys side :P | 16:45 |
| corecode | i guess you'd have to output vector position as a second array | 16:46 |
| daveshah | I think we will still only ever consider contiguous vectos | 16:46 |
| daveshah | *vectors | 16:46 |
| daveshah | so probably just a start and end index | 16:46 |
| corecode | is there ways to have non-contiguous vectors? | 16:47 |
| daveshah | Not in any HDL I know | 16:47 |
| corecode | okay | 16:47 |
| daveshah | I don't even think Yosys supports them internally | 16:47 |
| MoeIcenowy | why don't you define two vectos | 16:47 |
| MoeIcenowy | vectors * | 16:47 |
| corecode | okay | 16:49 |
| corecode | i wonder, can i put a normal IO on an OD pad? | 16:49 |
| daveshah | Yes, but it works as an open drain IO | 16:49 |
| corecode | that's good enough | 16:49 |
| daveshah | no pullup either | 16:49 |
| corecode | i made a design error | 16:49 |
| corecode | had to flip my LEDs around :) | 16:50 |
| daveshah | :) | 16:50 |
| corecode | ofc i didn't read the docs thoroughly enough | 16:50 |
| daveshah | didn't realise they were sinks? | 16:50 |
| corecode | yea | 16:50 |
| corecode | i thought they were sources | 16:51 |
| daveshah | advantage of sinks is that your LED supply can be 5V | 16:51 |
| corecode | so these pads can tolerate 5V? | 16:52 |
| corecode | or are you safe due to Vf | 16:52 |
| corecode | hm, why does nextpnr use a SB_GB for the HFOSC | 16:56 |
| corecode | terminate called after throwing an instance of 'std::out_of_range' | 16:58 |
| corecode | what(): vector::_M_range_check: __n (which is 21) >= this->size() (which is 18) | 16:58 |
| corecode | oO | 16:58 |
| corecode | int8_t &cbit = config.at(swi.y).at(swi.x).at(swi.cbits[i].row).at(swi.cbits[i].col); | 17:01 |
| corecode | 17:01 | |
| corecode | that line | 17:01 |
| tnt | daveshah: you can only use 5V if the min Vf is large enough AFAIK. | 17:03 |
| daveshah | corecode: nextpnr always uses a SB_GB for global signals | 17:05 |
| daveshah | you can tell it not to for testing with "(* ROUTE_THROUGH_FABRIC=1 *) | 17:06 |
| daveshah | on the HFOSC | 17:06 |
| tnt | your chipdb for HFOSC has a port named 'CLKLF_FABRIC 0 18 slf_op_7' that seems suspicious. | 17:08 |
| corecode | doesn't the HFOSC directly go to the global network? | 17:08 |
| daveshah | well, through a padin | 17:08 |
| daveshah | the SB_GB is used to enable that, and also prevent anything else using that global buffer site | 17:08 |
| tnt | corecode: SB_GB kind of represents the 'global network'. | 17:08 |
| corecode | in the HFOSC tile | 17:08 |
| corecode | okay | 17:09 |
| corecode | so SB_GB can be used for both fabric signals and for signals that can be connected directly to the glb | 17:10 |
| daveshah | in nextpnr, this is how we represent this | 17:10 |
| MoeIcenowy | daveshah: I dug into the issue, and found that when dealing with VQM, the width of some intput/output of altsyncram depends on its parameters | 17:11 |
| MoeIcenowy | however yosys seems to have no support of this | 17:12 |
| MoeIcenowy | (Quartus uses its proprietary format to define altsyncram | 17:12 |
| daveshah | Yosys supports this for normal cells | 17:13 |
| daveshah | I don't know how it works for blackbox cells | 17:13 |
| MoeIcenowy | how to use it? | 17:13 |
| MoeIcenowy | oh sorry I found me wrong | 17:14 |
| MoeIcenowy | the uppercase and lowercase naming of the parameters are the same within Quartus when parsing VQM | 17:14 |
| MoeIcenowy | but is different on Yosys | 17:14 |
| corecode | so why are there only 18 cbits, and it is trying to access bit 21 | 17:14 |
| MoeIcenowy | I just wrongly used lowercase in parameter def and lowercase in portdef | 17:15 |
| corecode | hm, it's trying to set a config bit in ipconn cell 0/19 | 17:16 |
| *** m4ssi has quit IRC | 17:17 | |
| daveshah | corecode: https://github.com/cliffordwolf/icestorm/pull/202/files#diff-f865bb682df7b52897af27ef3a8bc5f1R126 | 17:17 |
| tpb | Title: iCE40 Ultra = iCE5LP = u4k port by corecode · Pull Request #202 · cliffordwolf/icestorm · GitHub (at github.com) | 17:17 |
| daveshah | this doesn't look right | 17:17 |
| daveshah | Ultra doesn't have IO tiles at the side | 17:17 |
| corecode | duh! | 17:17 |
| * corecode makes up a song about rebuilding chipdbs | 17:19 | |
| daveshah | :D | 17:19 |
| daveshah | we should add music like those old keygens | 17:19 |
| ZipCPU | daveshah: Who's building that HugeFPGA? | 17:20 |
| daveshah | :D | 17:20 |
| ZipCPU | Is that just the tinyFPGA EX renamed? | 17:21 |
| daveshah | yes, it was a bad combination of inspect element and gimp :P | 17:22 |
| ZipCPU | So ... there's really nothing there then? Got it. | 17:23 |
| MoeIcenowy | I got manually defined altsyncram work now | 17:24 |
| MoeIcenowy | but inferred ones still not work | 17:25 |
| daveshah | I don't think Intel RAM inference really works yet | 17:25 |
| daveshah | ZipCPU might know more? | 17:25 |
| ZipCPU | What device are we discussing? Altera? | 17:26 |
| MoeIcenowy | ZipCPU: yes | 17:26 |
| ZipCPU | I've been building a design with inferred RAM within it ... is that not working for you? Which device? | 17:26 |
| MoeIcenowy | ZipCPU: do you use Yosys to synth and Quartus to PnR? | 17:27 |
| ZipCPU | I have used Yosys to synth, but I'll admit my path stopped there | 17:27 |
| ZipCPU | My design needs DDR I/O elements, as well as the PLL, and I'm not (yet) certain how to properly synthesize those for Quartus PnR | 17:28 |
| MoeIcenowy | The inferred thing seems well, but it just doesn't work ;-) | 17:28 |
| ZipCPU | How so? | 17:28 |
| tnt | corecode: inside the FGPA the actual SB_GB circuit is probably not used, but 'virtually' instanciating a locked SB_GB for cores that drive the global network is how it's done in next pnr. This made it easier to support and also 'lock-out' that particular SB_GB from being used (since it would drive the same global network ...). | 17:29 |
| MoeIcenowy | Quartus has strict check on altsyncram parameters and ports | 17:29 |
| *** proteusguy has joined #yosys | 17:37 | |
| MoeIcenowy | and VQM is not Verilog -- it has a more narrow grammar | 17:38 |
| corecode | hm, unable to find config bit IpConfig.CBIT_3 | 17:44 |
| corecode | CLKHF_DIV_0 | 17:45 |
| corecode | IpConfig.CBIT_3 B2[7] | 17:46 |
| corecode | 17:46 | |
| corecode | it's in the chipdb tho\ | 17:46 |
| corecode | hm no, i think this is a different CBIT_3 | 17:48 |
| corecode | no, it's the hfosc, pretty sure | 17:50 |
| daveshah | corecode: are you sure that location is an ipcon tile? | 17:55 |
| daveshah | and that is going into the database correct | 17:55 |
| daveshah | *correctly | 17:55 |
| corecode | it's a dsp tile | 17:55 |
| corecode | but bitstream.cc replaces the name with IpConfig. | 17:55 |
| daveshah | Is it a dsp3 tile? | 17:56 |
| daveshah | Looks like only CBIT_0 is present in the config bit database for that | 17:57 |
| MoeIcenowy | oops nowadays quartus itself doesn't generate VQM file | 17:57 |
| MoeIcenowy | only other 3rdparty synthesis tool will generate | 17:57 |
| corecode | huh | 17:57 |
| corecode | why | 17:57 |
| MoeIcenowy | I think some weird FPGA vendor has no their own synthesis tool | 17:58 |
| daveshah | Because the fuzzer didn't build any designs to create them | 17:58 |
| corecode | hmm | 17:58 |
| MoeIcenowy | and uses VQM from Quartus | 17:58 |
| daveshah | As the CBITs are always in the same place across all the DSP/IpCon tiles | 17:58 |
| corecode | but why | 17:58 |
| daveshah | you can just use something like this to add it: | 17:58 |
| daveshah | https://github.com/cliffordwolf/icestorm/blob/master/icebox/icebox.py#L5544 | 17:58 |
| tpb | Title: icestorm/icebox.py at master · cliffordwolf/icestorm · GitHub (at github.com) | 17:58 |
| daveshah | corecode: did you have the oscillator covering all divider values in make_uip.py? | 17:58 |
| corecode | ha, no | 17:59 |
| MoeIcenowy | daveshah: BTW how difficult is it to reuse prjtrellis workflow on other Lattice chips? | 17:59 |
| MoeIcenowy | e.g. ECP3 | 17:59 |
| *** pointfree has quit IRC | 17:59 | |
| corecode | but i set both bits | 17:59 |
| MoeIcenowy | some low end ECP3 chips are quite cheap | 17:59 |
| daveshah | MoeIcenowy: workflow should mostly be the same | 17:59 |
| daveshah | MoeIcenowy: some changes to nextpnr might be needed because of slightly different slice, etc | 17:59 |
| daveshah | also, different fuzzers for that | 17:59 |
| *** pointfree has joined #yosys | 18:00 | |
| corecode | wait | 18:00 |
| daveshah | corecode: anyway, just adding them manually in icebox.py like that snippet above is fine | 18:00 |
| corecode | nono, i do | 18:00 |
| daveshah | could it be that the fuzz data wasn't being processed correctly | 18:00 |
| corecode | definitely got fuzzed | 18:01 |
| daveshah | did it end up in iceboxdb.py? | 18:01 |
| corecode | no | 18:01 |
| corecode | aha, i'm using the 5k db | 18:02 |
| corecode | for the dsp | 18:02 |
| corecode | i'm confused now - how would this work on 5k? | 18:02 |
| daveshah | The 5k doesn't use those configuration bits | 18:03 |
| daveshah | it has the osc bits in an ipcon tile | 18:03 |
| daveshah | but it's fine to share the databases | 18:03 |
| corecode | oh! | 18:03 |
| corecode | that location is an ipcon tile | 18:03 |
| corecode | so you suggest rather than modifying the chipdb file, just hardcode it? | 18:05 |
| daveshah | 0 16 looks like a dsp3 tile to me | 18:05 |
| corecode | yes it is | 18:05 |
| daveshah | yeah, the same way I did for dsp1 CBIT_5 | 18:05 |
| daveshah | https://github.com/cliffordwolf/icestorm/blob/master/icebox/icebox.py#L5544 | 18:05 |
| corecode | you mean also on the 5k? | 18:05 |
| tpb | Title: icestorm/icebox.py at master · cliffordwolf/icestorm · GitHub (at github.com) | 18:05 |
| daveshah | just get the locations of the cbits from the other tiles | 18:06 |
| daveshah | yeah, doing it for both 5k and u4k is fine | 18:06 |
| daveshah | fwiw maybe those bits have some hidden function on the 5k too :P | 18:06 |
| corecode | oh, just for something else? | 18:07 |
| daveshah | well, who knows... | 18:07 |
| corecode | because it seems the bit location is the same, just that there is a different tile at that point? | 18:07 |
| daveshah | yeah | 18:07 |
| corecode | <chipdb song> | 18:13 |
| *** danieljabailey has quit IRC | 18:35 | |
| *** xdeller__ has quit IRC | 18:42 | |
| *** xdeller__ has joined #yosys | 18:42 | |
| *** seldridge has joined #yosys | 18:43 | |
| *** seldridge has joined #yosys | 18:43 | |
| corecode | meh, now i need to figure out whether there is a TRIM_EN bit | 18:50 |
| corecode | or i remove it from the u4k for now | 18:50 |
| corecode | hm, i need an ieren info block for the OD pins | 19:07 |
| corecode | somehow my chipdb doesn't have that | 19:08 |
| *** leviathanch has quit IRC | 19:08 | |
| *** xerpi has joined #yosys | 19:08 | |
| *** xerpi has quit IRC | 19:29 | |
| *** xerpi has joined #yosys | 19:29 | |
| corecode | hm, how can i get icecube to use a SB_IO_OD for output | 19:34 |
| daveshah | tweak the pin_type and make sure that D_OUT_0 is connected | 19:37 |
| corecode | oh use a SB_IO explicitly? | 19:39 |
| corecode | hm | 19:39 |
| daveshah | well a SB_IO_OD | 19:39 |
| corecode | i'm looking at the ioctrl script, and i don't see how you got the ieren from that | 19:40 |
| corecode | because the script is skipping the OD pins | 19:40 |
| daveshah | I think I just assumed the same pattern (mirrored Z) and it worked | 19:40 |
| corecode | haha | 19:40 |
| daveshah | might have checked with explain manually | 19:40 |
| daveshah | https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/tests/sb_io_od.v | 19:41 |
| tpb | Title: icestorm/sb_io_od.v at master · cliffordwolf/icestorm · GitHub (at github.com) | 19:41 |
| corecode | i wonder why they did that | 19:41 |
| daveshah | The ierens are strange | 19:50 |
| daveshah | at least they are consistently swapped on the ultra/up | 19:50 |
| daveshah | on the hx8k they are sometimes swapped and sometimes aren't | 19:50 |
| daveshah | on the hx1k they are all nice and correct | 19:50 |
| corecode | hm | 20:01 |
| corecode | Got .ipcon_tile statement for dsp0 tile 0 5. | 20:01 |
| corecode | man my chipdb sucks | 20:01 |
| corecode | why doesn't it call it dsp_tile | 20:06 |
| corecode | but it has a dsp bel on there | 20:07 |
| *** xerpi has quit IRC | 20:11 | |
| *** xerpi has joined #yosys | 20:12 | |
| * corecode fixes icebox | 20:19 | |
| *** xerpi has quit IRC | 20:22 | |
| *** xerpi has joined #yosys | 20:23 | |
| corecode | aha | 20:30 |
| *** xerpi_ has joined #yosys | 20:40 | |
| *** xerpi has quit IRC | 20:42 | |
| corecode | \o/ blinky simulates | 21:09 |
| daveshah | :) | 21:21 |
| *** noname_Matt has joined #yosys | 21:31 | |
| *** voxadam_ has joined #yosys | 21:39 | |
| *** voxadam has quit IRC | 21:40 | |
| corecode | finally | 21:40 |
| *** xerpi_ has quit IRC | 21:43 | |
| corecode | https://github.com/YosysHQ/nextpnr/pull/241 | 21:46 |
| tpb | Title: ice40: support u4k by corecode · Pull Request #241 · YosysHQ/nextpnr · GitHub (at github.com) | 21:46 |
| daveshah | Awesome | 21:46 |
| daveshah | I'll take a look | 21:46 |
| corecode | thank you | 21:46 |
| *** noname_Matt has quit IRC | 21:52 | |
| tnt | What's SMCCLK btw ? | 21:59 |
| *** noname_Matt has joined #yosys | 22:04 | |
| daveshah | tnt: my limited understanding is SMCCLK exposes the internal configuration clock | 22:05 |
| daveshah | I don't exactly know how it behaves after startup | 22:05 |
| daveshah | But on the iCE40 Ultra iCEcube uses it to clock a register (with D input at 1'b1) driving output enables | 22:06 |
| noname_Matt | Has anyone tried writing a partial bitstream to an ice40 device without restarting it? (a warm boot perhaps?) | 22:06 |
| noname_Matt | I'm interested to know if it would be possible to lay things out such that the devices attached to a buss in an SoC could be swapped during operation | 22:07 |
| daveshah | As far as I know, any reconfiguration will lose CRAM and register values | 22:08 |
| daveshah | I don't even know a way to keep the config port open while the design is running | 22:08 |
| daveshah | OTOH, preserving BRAM across reconfig is supported | 22:08 |
| corecode | wow hot hardware update | 22:13 |
| corecode | and reload state from bram | 22:13 |
| noname_Matt | corecode: Can you elaborate a bit? I did see some info on enabling/disabling warm/cold rebooting, but nothing on what a 'hot' update would entail | 22:54 |
| corecode | i'm just extrapolating from the information | 22:54 |
| noname_Matt | I'm guessing this would reconfigure the device and clear all registers, but you're suggesting to recover from bram? | 22:54 |
| daveshah | So BRAM will be kept if the bitstream doesn't initialise it | 22:55 |
| corecode | dump all state into a bram via some shift register or mux, then in the new design reverse direction | 22:55 |
| noname_Matt | I see. | 22:55 |
| daveshah | atm the tools always include bram init in the bitstream, but that would be easy enough to change | 22:55 |
| corecode | i don't think an fpga is really made for that | 22:55 |
| corecode | i mean, can you load the DFF optionally from a different signal? | 22:56 |
| noname_Matt | Still requires explicit start/stop, but saves having to do a full reboot of the core. | 22:56 |
| noname_Matt | well, I think the FPGA is definitely not made for this, but then again it definitely wan't made to work with icestorm | 22:57 |
| noname_Matt | daveshah: what might be fun is to configure a simple logic circuit that responds to outside signaling, and measure at what point you lose CRAM/register contents | 22:58 |
| noname_Matt | and see if it can be skipped over, maybe | 22:58 |
| daveshah | I have attempted to readout CRAM after asserting CDONE and not got anything useful | 22:59 |
| noname_Matt | like, maybe it's only wiped if you're writing to the same block? I'm not aware of any trials and I'd be interested to know if anyone tried this during initial reverse engineering | 22:59 |
| noname_Matt | cdone? | 23:00 |
| daveshah | Sorry, I mean creset | 23:00 |
| daveshah | It seems to wipe CRAM | 23:00 |
| noname_Matt | All I have to go on so far is http://www.clifford.at/icestorm/format.html | 23:00 |
| tpb | Title: Project IceStorm Bitstream File Format Documentation (at www.clifford.at) | 23:00 |
| noname_Matt | so I don't know what you're talking about :( | 23:01 |
| daveshah | creset is a pin | 23:01 |
| corecode | config pins | 23:01 |
| daveshah | You assert it to reset the device, and you have to assert it to re enable the SPI programming interface | 23:02 |
| daveshah | As soon as you assert it, CRAM is wiped | 23:02 |
| noname_Matt | is there somewhere I can read about the programming procedure? | 23:02 |
| corecode | and i guess clocks stop running | 23:02 |
| corecode | yes, there is an app note | 23:02 |
| noname_Matt | when does the SPI interface become disabled? | 23:02 |
| corecode | i think CDONE goes high at some point | 23:03 |
| corecode | and that's it | 23:03 |
| noname_Matt | I ask because I guess the next logical question is if it's possible to get into an inbetween state where running and programming are both possible. | 23:04 |
| noname_Matt | is the app note on lattice's site somewhere? | 23:04 |
| corecode | i'd home not | 23:04 |
| corecode | yea | 23:04 |
| corecode | hope* | 23:04 |
| daveshah | SPI is disabled once you send opcode 0 payload 6 to wakeup and start running the bitstream | 23:05 |
| daveshah | It's possible there's a different command to run the design without disabling SPI | 23:05 |
| corecode | ah so far i've just pushed out the bin | 23:05 |
| daveshah | It's also unlikely given the structure of the device | 23:05 |
| daveshah | Yeah, effectively the bin is a series of commands | 23:05 |
| noname_Matt | might be fun to fuzz it and look for undocumented commands, but it sounds like you might be correct | 23:06 |
| noname_Matt | what dos warm boot in opcode 9 refer to? | 23:06 |
| noname_Matt | does* | 23:07 |
| daveshah | It enables use of the SB_WARMBOOT primitive | 23:07 |
| corecode | but warmboot is spi master | 23:08 |
| daveshah | Yeah | 23:08 |
| daveshah | Exactly the same commands are read off SPI flash in that mode | 23:08 |
| daveshah | Just the iCE40 is driving the clock and sends a read command first | 23:08 |
| noname_Matt | cool | 23:08 |
| noname_Matt | and I assume it will read the same opcodes and look for the same sort of termination? | 23:09 |
| corecode | so, do i try to upload a blinky design to my board | 23:09 |
| *** m4ssi has joined #yosys | 23:10 | |
| daveshah | noname_Matt: the termination is the wakeup command again | 23:10 |
| corecode | well, opcode 0/6 | 23:10 |
| noname_Matt | what if you send it a reboot instead? how does SB_WARMBOOT fit into it? | 23:11 |
| noname_Matt | reboot: 0/8 | 23:11 |
| daveshah | Reboot just resets things | 23:11 |
| daveshah | WARMBOOT basically indexes into a jump table that points to the image, iirc | 23:12 |
| noname_Matt | reboot just starts everything over again? | 23:12 |
| daveshah | Yeah | 23:13 |
| noname_Matt | so warmboot allows you to select a starting point to read opcode from one of several locations, but requires the same resetting? is it related to is 4/*? | 23:15 |
| daveshah | Yes, warmboot also performs a reset of all but BRAM | 23:16 |
| daveshah | Yes, warmboot will index into a jump table of 4 opcodes that point to the real images | 23:17 |
| noname_Matt | that is, opcode 4/* not literally a table four entries long? | 23:19 |
| noname_Matt | I presume such a table is located at a certain spot and is indexed on some condition? | 23:20 |
| daveshah | I think each "warmboot applet" is 32 bytes in total | 23:21 |
| daveshah | With a 4 command to set the jump address and a reboot command which jumps to that address | 23:22 |
| daveshah | The warmboot primitive selects one of those applets | 23:22 |
| noname_Matt | hrm. | 23:29 |
| noname_Matt | when you say warmboot primitive, is this a series of opcodes, or a hardwired procedure? | 23:40 |
| noname_Matt | controlled by opcode 9/*? | 23:40 |
| corecode | SB_WARMBOOT | 23:41 |
| noname_Matt | A signal on the chip? | 23:42 |
| corecode | yes | 23:42 |
| noname_Matt | and this starts the procedure to select and load a bitstream? | 23:43 |
| corecode | i think you apply signals that select the bitstream | 23:43 |
| noname_Matt | ok. that makes sense | 23:44 |
| noname_Matt | thank you. I have a much better idea how all this work now. | 23:44 |
| noname_Matt | works* | 23:44 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!