Friday, 2019-02-22

*** tpb has joined #yosys00:00
daveshahI wonder if the UltraPlus has a SMCCLK primitive too00:00
corecodeis it (25, 3, 0) or (25, 3, 1)?00:01
daveshahz doesn't matter for functional purposes so long as its unique within a tile00:02
daveshahIf it appears in icecube floorplan view, use the coordinates that gives00:02
daveshahOtherwise, the first free z index in 25, 300:02
corecodeit just says IpConn tile00:02
daveshahDoesn'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 device00:03
corecodeso how do i test whether this is recorded right in icebox00:04
daveshahThere isn't really a way for these primitives00:04
daveshahNeed to get round to proper extra cell support in icebox_vlog at some point00:05
corecodeman i need to disable my clean up trailing space on save00:07
corecodeit adds so much churn that i have to remove00:07
corecodeso now i need to modify yosys00:10
corecodeah no, it's in icefuzz still00:11
daveshahEventually you'll want to add blackboxes for these new cell types to
tpbTitle: yosys/cells_sim.v at master · YosysHQ/yosys · GitHub (at
daveshahBut no urgency00:12
*** seldridge has quit IRC00:27
*** emeb has left #yosys00:32
*** emeb_mac has joined #yosys00:49
corecodemeh, now i'm fighting with cmake00:59
corecodeexisting bug01:00
emeb_maccorecode: how goes the LP4k work?01:11
corecodein nextpnr now01:15
corecodehm what's this pi_eb_bank that i can't find in glbinfo now?01:16
*** seldridge has joined #yosys01:16
corecodei need to make up padin bits01:18
*** leviathanch has joined #yosys01:22
*** gsi__ has joined #yosys01:58
*** gsi_ has quit IRC02:01
corecodedaveshah: yea i don't know where i get the io_clktoq from02:26
corecodeor the model params02:29
*** AlexDaniel has quit IRC02:35
*** citypw has joined #yosys04:10
*** rohitksingh_work has joined #yosys04:12
*** pie__ has joined #yosys05:05
mrecI'm doing some serial communication however the results differ from synthesis to synthesis and that's not only confusing but wrong05:06
mrecI guess there's some bug in the synthesis tool itself otherwise the result wouldn't be random05:06
mrecand I highly doubt that this has anything to do with setup/hold/propagation delays05:07
mrecrandom 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 way05:08
*** pie___ has quit IRC05:09
mrecI'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 all05:09
mrecI never had such a basic issue with any other lattice part so I guess the ice40up5k is shit05:11
mreclooking at the rtl ... it's even synthesising things which it should cut out ... no no this thing is so wrong05:13
mrecit feels like when counting from 1 to 10 things break at 105:20
mrecwhat 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 working05:25
mreciter++ of course05:25
mrecwhatever it's so basic that it is impossible to fail normally05:25
*** proteusguy has joined #yosys05:40
emeb_maciin 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
MoeIcenowymrec: try Lattice Radient or iCEcube2?06:31
MoeIcenowyif it works with them, but not with Yosys/NextPnR/Icestorm06:31
MoeIcenowyit's a severe bug06:31
*** seldridge has quit IRC07:05
*** proteusguy has quit IRC07:13
*** emeb_mac has quit IRC07:28
*** proteusguy has joined #yosys07:46
*** m4ssi has joined #yosys08:12
daveshahcorecode: have you got timing html file?08:28
*** proteusguy has quit IRC08:42
*** rohitksingh_work has quit IRC08:59
*** rohitksingh_work has joined #yosys08:59
*** rohitksingh_work has quit IRC09:37
*** citypw has quit IRC10:09
*** indy has quit IRC10:35
corecodedaveshah: i only see propagation delays and timing checks10:53
*** danieljabailey has quit IRC10:55
tntmrec: just pastebin the exact code you're trying to run ...10:55
daveshahcorecode: what you want is the propogation delay from posedge:clk to lcout11:12
daveshahin LogicCell4011:12
corecodeooh, i thought it is for SB_IO12:21
corecode1050, it says12:22
corecodesomehow i have all propagation delays twice12:25
daveshahCan you post the file? From memory if isn't creating the project correctly then icecube can produce funny timings12:26
corecodewill the txt file suffice?12:26
tpbTitle: timings_u4k.txt · GitHub (at
tpbTitle: timings_up5k.txt · GitHub (at
corecodeto compare12:27
daveshahI think this is a project problem, usually suspiciously round timings are a sign of this12:27
corecodeso what can i do?12:28
daveshahMake sure these lines: are creating a project file set up the same way as one from the icecube gui12:28
tpbTitle: icestorm/ at master · cliffordwolf/icestorm · GitHub (at
daveshahYou'll also need to clear the timing file after making the fix12:29
corecodedo i need to run any other tests again after fixing this?12:37
daveshahNo, just the main icefuzz12:37
daveshahIt only affects timing, nothing bitstream wise12:37
corecodedo i have to clear the runs?12:38
corecodethe work_*12:38
corecodedaveshah: i can't find the timings in nextpnr in the 5k file12:52
daveshahcorecode: wait, is this the IO timing?13:10
daveshahthen it should be PRE_IO, sorry13:10
corecodethere are two places with timing13:15
corecodeSB_IO, and the lut model13:15
*** rohitksingh has joined #yosys13:17
daveshahlut model?13:17
daveshahyou mean
*** voxadam has quit IRC14:14
*** voxadam has joined #yosys14:15
*** m4ssi has quit IRC14:19
*** m4ssi has joined #yosys14:20
*** rohitksingh has quit IRC14:24
*** rohitksingh has joined #yosys14:26
*** emeb has joined #yosys14:33
*** rohitksingh has quit IRC14:35
*** danieljabailey has joined #yosys14:56
*** citypw has joined #yosys15:29
corecodenow i need to test a simple design15:34
* corecode goes on to learn how to use yosys and nextpnr15:34
corecodedaveshah: i'm getting15:52
corecodeERROR: Unable to place cell 'hfosc_OSC' of type 'ICESTORM_HFOSC'15:52
corecodebut i can't find a place in nextpnr where i forgot to add it15:53
corecodeit's in the chipdb15:55
tntcorecode: do you have your chipdb somewhere ?15:57
tpbTitle: iCE40 Ultra = iCE5LP = u4k port by corecode · Pull Request #202 · cliffordwolf/icestorm · GitHub (at
daveshahcorecode: fyi, we don't check in the chipdb-*.txt files16:02
corecodethat explains why git grep didn't find it16:02
daveshahHFOSC in there looks fine16:03
tntyeah. You did rebuild nextpnr right ?16:03
daveshahIf you look at that tile under "Bels" in the GUI sidebar opened for u4k, do you see it?16:03
corecodeX0/Y21/hfosc_1, type ICESTORM_HFOSC16:07
daveshahlooks good16:07
corecodethere is no cell drawn tho16:09
corecodein the ui16:09
daveshahno, that's fine16:09
daveshahcan you try setting z to zero?16:10
corecode"yea, but..."16:10
corecodewhat about the 5k16:10
corecodethe error comes from cell_place_unique16:11
daveshahI think the importer needs z to be contiguous from zero in a tile16:12
corecodeand either it's not in ctx->getBels, or its type isn't right, or it is locked16:12
corecodefeels more like we should change the importer...16:13
tntthe importer ? you mean ?16:14
corecodewell, whatever you call the importer16:15
corecodei guess the problem is that i don't have the i2c cell in icepack yet16:15
daveshahalthough I can't see why they would be a problem either16:16
daveshahultraplus seems to have some non-contiguous zs already in fact16:17
daveshahnever mind that idea16:17
tntif it shows in the gui, it should be in the blob right ?16:17
corecodeyea, it's not in getBels()16:34
corecodeLFOSC isn't there either16:35
corecodeor SMCCLK16:35
corecodeonly warmboot is16:35
corecodefeels like the wrong chip type16:36
corecodei guess the json file doesn't contain the target16:36
corecodeand i need to pass it in the command line16:37
corecodewell, there is the nice .proj file16:38
corecodei thought it would be picked up16:38
corecodebut evidently not?16:39
daveshahNo, the JSON is device independent16:39
daveshahIt is mapped to a family (ie iCE40) rather than specific device16:39
daveshahA proj file should contain the device type though16:39
MoeIcenowyjson by yosys?16:40
MoeIcenowyBTW is the standard of the json output by yosys available?16:40
MoeIcenowyor is it used by any other EDA tool?16:40
MoeIcenowy(except Yosys/NextPnR16:40
daveshahThere is
tpbTitle: Yosys Open SYnthesis Suite :: Command Reference :: write_json (at
MoeIcenowyBTW the EDIF output of Yosys is not usable in iCEcube2 (16:41
daveshahI know16:41
daveshahEDIF isn't really a standard16:41
MoeIcenowyand the VQM output of Yosys is not usable in Quartus Prime16:41
daveshahYosys outputs the Xilinx flavour, more or less16:41
MoeIcenowy(seems mainly about altsyncram16:42
daveshahI don't think that should be too hard to fix16:42
MoeIcenowybut it seems strange16:42
tnt  is a serious limitation of that json fmt for the moment :/16:43
tpbTitle: Port defined like d[9:2] is not indexed correctly when used in pcf file · Issue #206 · YosysHQ/nextpnr · GitHub (at
corecodeso what is this .proj file for?16:43
MoeIcenowydaveshah: is commercial synthesis tool all customized for a certain PnR toolchain?16:44
daveshahcorecode: the .proj file is mostly for projects created in the GUI16:44
MoeIcenowye.g. Synplify Pro16:44
daveshahMoeIcenowy: I think Lattice have some custom shims for compatability16:45
daveshahtnt: I keep pestering clifford to fix the Yosys side :P16:45
corecodei guess you'd have to output vector position as a second array16:46
daveshahI think we will still only ever consider contiguous vectos16:46
daveshahso probably just a start and end index16:46
corecodeis there ways to have non-contiguous vectors?16:47
daveshahNot in any HDL I know16:47
daveshahI don't even think Yosys supports them internally16:47
MoeIcenowywhy don't you define two vectos16:47
MoeIcenowyvectors *16:47
corecodei wonder, can i put a normal IO on an OD pad?16:49
daveshahYes, but it works as an open drain IO16:49
corecodethat's good enough16:49
daveshahno pullup either16:49
corecodei made a design error16:49
corecodehad to flip my LEDs around :)16:50
corecodeofc i didn't read the docs thoroughly enough16:50
daveshahdidn't realise they were sinks?16:50
corecodei thought they were sources16:51
daveshahadvantage of sinks is that your LED supply can be 5V16:51
corecodeso these pads can tolerate 5V?16:52
corecodeor are you safe due to Vf16:52
corecodehm, why does nextpnr use a SB_GB for the HFOSC16:56
corecodeterminate 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                    int8_t &cbit =[i].row).at(swi.cbits[i].col);17:01
corecodethat line17:01
tntdaveshah: you can only use 5V if the min Vf is large enough AFAIK.17:03
daveshahcorecode: nextpnr always uses a SB_GB for global signals17:05
daveshahyou can tell it not to for testing with "(* ROUTE_THROUGH_FABRIC=1 *)17:06
daveshahon the HFOSC17:06
tntyour chipdb for HFOSC has a port named 'CLKLF_FABRIC 0 18 slf_op_7'  that seems suspicious.17:08
corecodedoesn't the HFOSC directly go to the global network?17:08
daveshahwell, through a padin17:08
daveshahthe SB_GB is used to enable that, and also prevent anything else using that global buffer site17:08
tntcorecode: SB_GB kind of represents the 'global network'.17:08
corecodein the HFOSC tile17:08
corecodeso SB_GB can be used for both fabric signals and for signals that can be connected directly to the glb17:10
daveshahin nextpnr, this is how we represent this17:10
MoeIcenowydaveshah: I dug into the issue, and found that when dealing with VQM, the width of some intput/output of altsyncram depends on its parameters17:11
MoeIcenowyhowever yosys seems to have no support of this17:12
MoeIcenowy(Quartus uses its proprietary format to define altsyncram17:12
daveshahYosys supports this for normal cells17:13
daveshahI don't know how it works for blackbox cells17:13
MoeIcenowyhow to use it?17:13
MoeIcenowyoh sorry I found me wrong17:14
MoeIcenowythe uppercase and lowercase naming of the parameters are the same within Quartus when parsing VQM17:14
MoeIcenowybut is different on Yosys17:14
corecodeso why are there only 18 cbits, and it is trying to access bit 2117:14
MoeIcenowyI just wrongly used lowercase in parameter def and lowercase in portdef17:15
corecodehm, it's trying to set a config bit in ipconn cell 0/1917:16
*** m4ssi has quit IRC17:17
tpbTitle: iCE40 Ultra = iCE5LP = u4k port by corecode · Pull Request #202 · cliffordwolf/icestorm · GitHub (at
daveshahthis doesn't look right17:17
daveshahUltra doesn't have IO tiles at the side17:17
* corecode makes up a song about rebuilding chipdbs17:19
daveshahwe should add music like those old keygens17:19
ZipCPUdaveshah: Who's building that HugeFPGA?17:20
ZipCPUIs that just the tinyFPGA EX renamed?17:21
daveshahyes, it was a bad combination of inspect element and gimp :P17:22
ZipCPUSo ... there's really nothing there then?  Got it.17:23
MoeIcenowyI got manually defined altsyncram work now17:24
MoeIcenowybut inferred ones still not work17:25
daveshahI don't think Intel RAM inference really works yet17:25
daveshahZipCPU might know more?17:25
ZipCPUWhat device are we discussing?  Altera?17:26
MoeIcenowyZipCPU: yes17:26
ZipCPUI've been building a design with inferred RAM within it ... is that not working for you?  Which device?17:26
MoeIcenowyZipCPU: do you use Yosys to synth and Quartus to PnR?17:27
ZipCPUI have used Yosys to synth, but I'll admit my path stopped there17:27
ZipCPUMy design needs DDR I/O elements, as well as the PLL, and I'm not (yet) certain how to properly synthesize those for Quartus PnR17:28
MoeIcenowyThe inferred thing seems well, but it just doesn't work ;-)17:28
ZipCPUHow so?17:28
tntcorecode: 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
MoeIcenowyQuartus has strict check on altsyncram parameters and ports17:29
*** proteusguy has joined #yosys17:37
MoeIcenowyand VQM is not Verilog -- it has a more narrow grammar17:38
corecodehm, unable to find config bit IpConfig.CBIT_317:44
corecodeIpConfig.CBIT_3 B2[7]17:46
corecodeit's in the chipdb tho\17:46
corecodehm no, i think this is a different CBIT_317:48
corecodeno, it's the hfosc, pretty sure17:50
daveshahcorecode: are you sure that location is an ipcon tile?17:55
daveshahand that is going into the database correct17:55
corecodeit's a dsp tile17:55
corecodebut replaces the name with IpConfig.17:55
daveshahIs it a dsp3 tile?17:56
daveshahLooks like only CBIT_0 is present in the config bit database for that17:57
MoeIcenowyoops nowadays quartus itself doesn't generate VQM file17:57
MoeIcenowyonly other 3rdparty synthesis tool will generate17:57
MoeIcenowyI think some weird FPGA vendor has no their own synthesis tool17:58
daveshahBecause the fuzzer didn't build any designs to create them17:58
MoeIcenowyand uses VQM from Quartus17:58
daveshahAs the CBITs are always in the same place across all the DSP/IpCon tiles17:58
corecodebut why17:58
daveshahyou can just use something like this to add it:17:58
tpbTitle: icestorm/ at master · cliffordwolf/icestorm · GitHub (at
daveshahcorecode: did you have the oscillator covering all divider values in
corecodeha, no17:59
MoeIcenowydaveshah: BTW how difficult is it to reuse prjtrellis workflow on other Lattice chips?17:59
MoeIcenowye.g. ECP317:59
*** pointfree has quit IRC17:59
corecodebut i set both bits17:59
MoeIcenowysome low end ECP3 chips are quite cheap17:59
daveshahMoeIcenowy: workflow should mostly be the same17:59
daveshahMoeIcenowy: some changes to nextpnr might be needed because of slightly different slice, etc17:59
daveshahalso, different fuzzers for that17:59
*** pointfree has joined #yosys18:00
daveshahcorecode: anyway, just adding them manually in like that snippet above is fine18:00
corecodenono, i do18:00
daveshahcould it be that the fuzz data wasn't being processed correctly18:00
corecodedefinitely got fuzzed18:01
daveshahdid it end up in
corecodeaha, i'm using the 5k db18:02
corecodefor the dsp18:02
corecodei'm confused now - how would this work on 5k?18:02
daveshahThe 5k doesn't use those configuration bits18:03
daveshahit has the osc bits in an ipcon tile18:03
daveshahbut it's fine to share the databases18:03
corecodethat location is an ipcon tile18:03
corecodeso you suggest rather than modifying the chipdb file, just hardcode it?18:05
daveshah0 16 looks like a dsp3 tile to me18:05
corecodeyes it is18:05
daveshahyeah, the same way I did for dsp1 CBIT_518:05
corecodeyou mean also on the 5k?18:05
tpbTitle: icestorm/ at master · cliffordwolf/icestorm · GitHub (at
daveshahjust get the locations of the cbits from the other tiles18:06
daveshahyeah, doing it for both 5k and u4k is fine18:06
daveshahfwiw maybe those bits have some hidden function on the 5k too :P18:06
corecodeoh, just for something else?18:07
daveshahwell, who knows...18:07
corecodebecause it seems the bit location is the same, just that there is a different tile at that point?18:07
corecode<chipdb song>18:13
*** danieljabailey has quit IRC18:35
*** xdeller__ has quit IRC18:42
*** xdeller__ has joined #yosys18:42
*** seldridge has joined #yosys18:43
*** seldridge has joined #yosys18:43
corecodemeh, now i need to figure out whether there is a TRIM_EN bit18:50
corecodeor i remove it from the u4k for now18:50
corecodehm, i need an ieren info block for the OD pins19:07
corecodesomehow my chipdb doesn't have that19:08
*** leviathanch has quit IRC19:08
*** xerpi has joined #yosys19:08
*** xerpi has quit IRC19:29
*** xerpi has joined #yosys19:29
corecodehm, how can i get icecube to use a SB_IO_OD for output19:34
daveshahtweak the pin_type and make sure that D_OUT_0 is connected19:37
corecodeoh use a SB_IO explicitly?19:39
daveshahwell a SB_IO_OD19:39
corecodei'm looking at the ioctrl script, and i don't see how you got the ieren from that19:40
corecodebecause the script is skipping the OD pins19:40
daveshahI think I just assumed the same pattern (mirrored Z) and it worked19:40
daveshahmight have checked with explain manually19:40
tpbTitle: icestorm/sb_io_od.v at master · cliffordwolf/icestorm · GitHub (at
corecodei wonder why they did that19:41
daveshahThe ierens are strange19:50
daveshahat least they are consistently swapped on the ultra/up19:50
daveshahon the hx8k they are sometimes swapped and sometimes aren't19:50
daveshahon the hx1k they are all nice and correct19:50
corecodeGot .ipcon_tile statement for dsp0 tile 0 5.20:01
corecodeman my chipdb sucks20:01
corecodewhy doesn't it call it dsp_tile20:06
corecodebut it has a dsp bel on there20:07
*** xerpi has quit IRC20:11
*** xerpi has joined #yosys20:12
* corecode fixes icebox20:19
*** xerpi has quit IRC20:22
*** xerpi has joined #yosys20:23
*** xerpi_ has joined #yosys20:40
*** xerpi has quit IRC20:42
corecode\o/ blinky simulates21:09
*** noname_Matt has joined #yosys21:31
*** voxadam_ has joined #yosys21:39
*** voxadam has quit IRC21:40
*** xerpi_ has quit IRC21:43
tpbTitle: ice40: support u4k by corecode · Pull Request #241 · YosysHQ/nextpnr · GitHub (at
daveshahI'll take a look21:46
corecodethank you21:46
*** noname_Matt has quit IRC21:52
tntWhat's SMCCLK btw ?21:59
*** noname_Matt has joined #yosys22:04
daveshahtnt: my limited understanding is SMCCLK exposes the internal configuration clock22:05
daveshahI don't exactly know how it behaves after startup22:05
daveshahBut on the iCE40 Ultra iCEcube uses it to clock a register (with D input at 1'b1) driving output enables22:06
noname_MattHas anyone tried writing a partial bitstream to an ice40 device without restarting it? (a warm boot perhaps?)22:06
noname_MattI'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 operation22:07
daveshahAs far as I know, any reconfiguration will lose CRAM and register values22:08
daveshahI don't even know a way to keep the config port open while the design is running22:08
daveshahOTOH, preserving BRAM across reconfig is supported22:08
corecodewow hot hardware update22:13
corecodeand reload state from bram22:13
noname_Mattcorecode: Can you elaborate a bit? I did see some info on enabling/disabling warm/cold rebooting, but nothing on what a 'hot' update would entail22:54
corecodei'm just extrapolating from the information22:54
noname_MattI'm guessing this would reconfigure the device and clear all registers, but you're suggesting to recover from bram?22:54
daveshahSo BRAM will be kept if the bitstream doesn't initialise it22:55
corecodedump all state into a bram via some shift register or mux, then in the new design reverse direction22:55
noname_MattI see.22:55
daveshahatm the tools always include bram init in the bitstream, but that would be easy enough to change22:55
corecodei don't think an fpga is really made for that22:55
corecodei mean, can you load the DFF optionally from a different signal?22:56
noname_MattStill requires explicit start/stop, but saves having to do a full reboot of the core.22:56
noname_Mattwell, I think the FPGA is definitely not made for this, but then again it definitely wan't made to work with icestorm22:57
noname_Mattdaveshah: 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 contents22:58
noname_Mattand see if it can be skipped over, maybe22:58
daveshahI have attempted to readout CRAM after asserting CDONE and not got anything useful22:59
noname_Mattlike, 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 engineering22:59
daveshahSorry, I mean creset23:00
daveshahIt seems to wipe CRAM23:00
noname_MattAll I have to go on so far is
tpbTitle: Project IceStorm Bitstream File Format Documentation (at
noname_Mattso I don't know what you're talking about :(23:01
daveshahcreset is a pin23:01
corecodeconfig pins23:01
daveshahYou assert it to reset the device, and you have to assert it to re enable the SPI programming interface23:02
daveshahAs soon as you assert it, CRAM is wiped23:02
noname_Mattis there somewhere I can read about the programming procedure?23:02
corecodeand i guess clocks stop running23:02
corecodeyes, there is an app note23:02
noname_Mattwhen does the SPI interface become disabled?23:02
corecodei think CDONE goes high at some point23:03
corecodeand that's it23:03
noname_MattI 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_Mattis the app note on lattice's site somewhere?23:04
corecodei'd home not23:04
daveshahSPI is disabled once you send opcode 0 payload 6 to wakeup and start running the bitstream23:05
daveshahIt's possible there's a different command to run the design without disabling SPI23:05
corecodeah so far i've just pushed out the bin23:05
daveshahIt's also unlikely given the structure of the device23:05
daveshahYeah, effectively the bin is a series of commands23:05
noname_Mattmight be fun to fuzz it and look for undocumented commands, but it sounds like you might be correct23:06
noname_Mattwhat dos warm boot in opcode 9 refer to?23:06
daveshahIt enables use of the SB_WARMBOOT primitive23:07
corecodebut warmboot is spi master23:08
daveshahExactly the same commands are read off SPI flash in that mode23:08
daveshahJust the iCE40 is driving the clock and sends a read command first23:08
noname_Mattand I assume it will read the same opcodes and look for the same sort of termination?23:09
corecodeso, do i try to upload a blinky design to my board23:09
*** m4ssi has joined #yosys23:10
daveshahnoname_Matt: the termination is the wakeup command again23:10
corecodewell, opcode 0/623:10
noname_Mattwhat if you send it a reboot instead? how does SB_WARMBOOT fit into it?23:11
noname_Mattreboot: 0/823:11
daveshahReboot just resets things23:11
daveshahWARMBOOT basically indexes into a jump table that points to the image, iirc23:12
noname_Mattreboot just starts everything over again?23:12
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
daveshahYes, warmboot also performs a reset of all but BRAM23:16
daveshahYes, warmboot will index into a jump table of 4 opcodes that point to the real images23:17
noname_Mattthat is, opcode 4/* not literally a table four entries long?23:19
noname_MattI presume such a table is located at a certain spot and is indexed on some condition?23:20
daveshahI think each "warmboot applet" is 32 bytes in total23:21
daveshahWith a 4 command to set the jump address and a reboot command which jumps to that address23:22
daveshahThe warmboot primitive selects one of those applets23:22
noname_Mattwhen you say warmboot primitive, is this a series of opcodes, or a hardwired procedure?23:40
noname_Mattcontrolled by opcode 9/*?23:40
noname_MattA signal on the chip?23:42
noname_Mattand this starts the procedure to select and load a bitstream?23:43
corecodei think you apply signals that select the bitstream23:43
noname_Mattok. that makes sense23:44
noname_Mattthank you. I have a much better idea how all this work now.23:44

Generated by 2.13.1 by Marius Gedminas - find it at!