| *** tpb has joined #yosys | 00:00 | |
| *** seldridge has quit IRC | 00:12 | |
| corecode | daveshah: i don't think i have new IP | 00:39 |
|---|---|---|
| corecode | at the moment | 00:39 |
| *** litghost has joined #yosys | 00:50 | |
| litghost | By 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 #yosys | 01:04 | |
| *** q3k has quit IRC | 01:05 | |
| *** develonepi3 has quit IRC | 01:15 | |
| ZipCPU | litghost: Why not use a for loop? | 01:52 |
| ZipCPU | Something like: initial for(k=0; k<RAMLEN; k=k+1) ram[k] = 0; | 01:53 |
| *** citypw has quit IRC | 01:56 | |
| *** gsi__ has joined #yosys | 02:00 | |
| *** emeb has left #yosys | 02:00 | |
| *** emeb_mac has joined #yosys | 02:03 | |
| litghost | Won'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 IRC | 02:03 | |
| *** citypw has joined #yosys | 03:43 | |
| *** gsi__ has quit IRC | 03:45 | |
| *** gsi_ has joined #yosys | 03:51 | |
| *** proteusguy has quit IRC | 03:59 | |
| *** Forty-Bot has joined #yosys | 04:02 | |
| ZipCPU | lighost: No, that should work | 04:03 |
| ZipCPU | You 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 #yosys | 04:09 | |
| *** proteusguy has joined #yosys | 04:53 | |
| *** rohitksingh_work has joined #yosys | 04:57 | |
| *** pie___ has joined #yosys | 05:06 | |
| *** pie__ has quit IRC | 05:10 | |
| MoeIcenowy | litghost: add a new step | 05:13 |
| MoeIcenowy | refer to my code for Anlogic | 05:13 |
| MoeIcenowy | the Anlogic TD tool do not accept 'bx in BRAM/DRAM initialization | 05:13 |
| *** rohitksingh_work has quit IRC | 05:26 | |
| *** rohitksingh_work has joined #yosys | 05:27 | |
| *** jevinskie has joined #yosys | 05:36 | |
| litghost | ZipCPU: 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 |
| litghost | Moelcenowy: 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 |
| litghost | Moelcenowy: Any chance you are referring to Moelcenowy? | 06:07 |
| litghost | anlogic_determine_init? | 06:07 |
| *** proteusguy has quit IRC | 06:11 | |
| *** _whitelogger has quit IRC | 06:25 | |
| *** _whitelogger has joined #yosys | 06:27 | |
| *** _whitelogger has quit IRC | 06:39 | |
| *** _whitelogger has joined #yosys | 06:41 | |
| *** Cerpin has quit IRC | 07:21 | |
| *** emeb_mac has quit IRC | 07:24 | |
| *** seldridge has quit IRC | 07:34 | |
| *** indy has quit IRC | 07:59 | |
| *** indy has joined #yosys | 08:08 | |
| *** m4ssi has joined #yosys | 08:32 | |
| MoeIcenowy | litghost: similar | 08:45 |
| MoeIcenowy | it's anlogic_determine_init what I mentioned | 08:46 |
| *** MoeIcenowy has quit IRC | 08:47 | |
| *** MoeIcenowy has joined #yosys | 08:48 | |
| *** citypw has quit IRC | 09:14 | |
| *** develonepi3 has joined #yosys | 11:19 | |
| *** leviathanch has quit IRC | 11:43 | |
| *** rohitksingh_work has quit IRC | 12:15 | |
| *** rohitksingh_work has joined #yosys | 12:17 | |
| *** leviathanch has joined #yosys | 13:16 | |
| *** Cerpin has joined #yosys | 13:25 | |
| *** rohitksingh_work has quit IRC | 13:28 | |
| *** rohitksingh has joined #yosys | 14:19 | |
| *** emeb has joined #yosys | 14:50 | |
| *** seldridge has joined #yosys | 15:24 | |
| *** danieljabailey has joined #yosys | 15:45 | |
| *** ylamarre has joined #yosys | 16:10 | |
| *** voxadam has joined #yosys | 16:12 | |
| sxpert | litghost: sounds like yosys uses the wrong primitive then | 16:34 |
| sxpert | daveshah: 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 |
| corecode | why not | 16:47 |
| sxpert | just asking if this is the right way to do it | 16:47 |
| corecode | yes, usually this is how you set defaults | 16:48 |
| daveshah | This should work, although a separate, explicit memory can never go wrong in any tool | 16:48 |
| corecode | you first write defaults, then you voerwrite them | 16:48 |
| corecode | rewrite* | 16:48 |
| corecode | overwrite* even | 16:48 |
| corecode | to prevent latches | 16:48 |
| sxpert | daveshah: sure, just trying to be the cleanest possible ;-) | 16:48 |
| corecode | think about how to do it in hardware | 16:50 |
| *** jevinskie has quit IRC | 16:50 | |
| sxpert | well, I have a wire that is generating the index, with a bunch of | conditions | 16:51 |
| sxpert | assign src1_ptr = ( {4{copy_address}} & data_counter | {4{xfr_data_copy}} & xfr_data_ctr ); | 16:53 |
| sxpert | and then | 16:53 |
| sxpert | xfr_data[data_counter] <= A[src1_ptr]; | 16:53 |
| sxpert | so, depending on data_counter or xfr_data_copy which are mutually exclusive, I get one or the other | 16:54 |
| sxpert | erh, copy_address or xfr_data_copy that is, obviously | 16:56 |
| corecode | why do you copy it 4 times? | 16:57 |
| sxpert | so as to generate a mask for all 4 bits of the src1_ptr value | 16:57 |
| corecode | aha | 16:58 |
| sxpert | it seemed the proper thing to do | 16:58 |
| corecode | so copy_address is a predicate | 16:58 |
| sxpert | yeah | 16:58 |
| corecode | aha | 16:58 |
| sxpert | it's a particular state in the madness | 16:58 |
| corecode | i've seen this in other designs, but i find it not very readable - maybe there are some asic advantages? | 16:58 |
| corecode | i used conditionals | 16:59 |
| sxpert | corecode: yeah, but I'm going to have more than 2 at a later stage, conditionals are harder to read at that point | 16:59 |
| corecode | assign src1_addr = copy_address ? data_counter : xfr_data_counter; | 16:59 |
| corecode | and bitops are not? | 17:00 |
| sxpert | dunno | 17:00 |
| ylamarre | corecode: Though, that wouldn't mask xfr_data_counter if xfr_data_copy is zero... | 17:00 |
| corecode | always @(*) case(1'b1) copy_address: src1_addr = data_counter; xfr_data_copy: scr1_addr = xfr_data_counter; default: src1_addr = 0; endcase | 17:01 |
| sxpert | ylamarre: right | 17:01 |
| corecode | ylamarre: yes, it would not. maybe necessary, maybe not | 17:01 |
| ylamarre | Agreed, I just wanted to explicit the fact ;) | 17:01 |
| corecode | https://github.com/corecode/forth-cpu/blob/master/rtl/alu.v | 17:02 |
| tpb | Title: forth-cpu/alu.v at master · corecode/forth-cpu · GitHub (at github.com) | 17:02 |
| corecode | this is what i did, no idea whether that's good style or not | 17:02 |
| sxpert | to me this reads like a series of and gates to select the right thing, then an or gate to get the state out | 17:03 |
| corecode | yes | 17:04 |
| corecode | i'm not saying it is wrong | 17:04 |
| ylamarre | corecode: Watch out for partability, Vivado had trouble with this kind of priority encoding... not sure when/if it was fixed... | 17:04 |
| corecode | i find it harder to understand | 17:04 |
| sxpert | it also feels like telling the compiler what to do exactly | 17:04 |
| corecode | synthesis tool* | 17:05 |
| sxpert | whatever ;) | 17:05 |
| corecode | difference | 17:05 |
| ylamarre | It matters :p | 17:05 |
| corecode | i think they usually blow it up into a big karnaugh map and then reduce it again | 17:05 |
| corecode | just guessing | 17:05 |
| *** m4ssi has quit IRC | 17:05 | |
| *** m4ssi has joined #yosys | 17:06 | |
| * sxpert learned digital electronics by blowing up ttl chips 25 or so years ago,,, | 17:06 | |
| sxpert | somehow the teachers hated me ;-) | 17:07 |
| sxpert | such 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 out | 17:07 |
| sxpert | little did I know by then... that's what PALs/GALs were made of ;-) | 17:08 |
| sxpert | funny how an fpga macro cell is pretty close from a 16R4 ;-) | 17:11 |
| corecode | why funny | 17:12 |
| sxpert | well... | 17:14 |
| sxpert | it'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 time | 17:16 | |
| corecode | daveshah: so what now after the icecube port? | 17:39 |
| mrec | this ice40up/icecube turns out to be a nightmare | 17:40 |
| corecode | what is? | 17:40 |
| mrec | Tool unable to find location for GB | 17:40 |
| mrec | I2712: Tool unable to find location for GB dcfx.sfifo.mem_doread_RNI83RD_0 | 17:40 |
| mrec | what should that mean? | 17:40 |
| mrec | the entire simulation seems to be worthless with it :-( | 17:41 |
| corecode | do you have a lot of different reset and clock networks? | 17:48 |
| *** leviathanch has quit IRC | 17:52 | |
| mrec | no | 18:01 |
| mrec | hmm | 18:18 |
| mrec | no such problem with radiant | 18:18 |
| corecode | yea icecube2 fails to place stuff for my design | 18:19 |
| mrec | are there any issues with icecube2 and the ice40up? | 18:19 |
| corecode | so i'll try yosys | 18:19 |
| mrec | I'm not a fan of the ice40up ... all the other lattice parts seem to be better and have a better simulation | 18:28 |
| mrec | I think I'll just dump that shit ice40up evb... | 18:28 |
| mrec | nonsense product, they better add more memory to the other fpgas | 18:29 |
| daveshah | corecode: 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 correctly | 18:29 |
| daveshah | Then it's pretty much a case of looking through nextpnr/ice40 for every up5k specific place and duplicating with necessary changes | 18:30 |
| *** m4ssi has quit IRC | 18:43 | |
| *** maikmerten has joined #yosys | 18:43 | |
| mrec | I wonder why the ice40up synthesis creates randomly different results... to me the lattice synthesis tools for this chip are absolute garbage | 18:46 |
| tnt | ? | 18:47 |
| mrec | that's what I'm thinking the whole day already | 18:47 |
| mrec | entire/ | 18:47 |
| tnt | heh, 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 IRC | 18:49 | |
| mrec | me neither but only with xo2, xo3, ecp5 | 18:49 |
| mrec | also ice40hx no problem | 18:49 |
| mrec | but ice40up ... everything's crazy | 18:49 |
| mrec | the biggest problem is that the simulation doesn't match | 18:50 |
| tnt | doesn't match what ? | 18:50 |
| mrec | I'm sending some data to the fpga and would like to receive some data back, however I get nothing it's stuck at 0V | 18:52 |
| mrec | and the interesting part is after synthesis sometimes it works a little bit but most of the time it doesn't | 18:52 |
| mrec | as long as I won't re-run the synthesis I can keep going with the half working image | 18:52 |
| mrec | what a nonsense | 18:52 |
| tnt | I'm pretty sure you screwed up something ... | 18:53 |
| tnt | I never had any issue that didn't turn out to be my fault. | 18:53 |
| mrec | just that I cannot figure it out for the entire day... | 18:54 |
| tnt | non-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 |
| tnt | what does the design even do ? | 18:55 |
| mrec | it's supposed to buffer some data | 18:56 |
| mrec | however I'm very far from that since I cannot even get the communication work at all | 18:57 |
| tnt | does 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 |
| mrec | I never had such problems with other fpgas | 18:57 |
| tnt | well 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 |
| ZipCPU | mrec: What type of communication protocol are you trying to implement? | 19:03 |
| tnt | what hardware, what is it connected to, also, where is the code, ... | 19:04 |
| *** seldridge has quit IRC | 19:13 | |
| *** seldridge has joined #yosys | 19:31 | |
| *** seldridge has quit IRC | 20:14 | |
| *** seldridge has joined #yosys | 20:28 | |
| *** m4ssi has joined #yosys | 21:00 | |
| *** maikmerten has quit IRC | 21:29 | |
| corecode | daveshah: 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 tile | 21:52 |
| corecode | 21:52 | |
| daveshah | Have 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 tiles | 21:53 |
| corecode | ok | 21:53 |
| corecode | thanks | 21:53 |
| daveshah | On the UltraPlus all but one of the dsp and ipconn tiles have these bits set | 21:53 |
| corecode | hm | 21:56 |
| corecode | For iCE40UL device, user can configure the internal pull up resistor strength of an IO to a predefined resistor value via attribute settings. | 21:56 |
| corecode | UL? what about UP and LP (ultra)? | 21:57 |
| corecode | why does the tech library documentation say only on UL, but you have it for UP? | 21:57 |
| daveshah | I know the UltraPlus can, because icecube allows you to enable it | 21:58 |
| daveshah | and I've tested it | 21:58 |
| corecode | in the constraints editor i can set pull-up to yes | 21:58 |
| corecode | but where would i set the strength | 21:59 |
| daveshah | But not change the value? | 21:59 |
| corecode | not in the UI | 21:59 |
| corecode | just yes/no | 21:59 |
| daveshah | Then the Ultra almost certainly has old style pullups not the new selectable strength ones | 21:59 |
| corecode | okay | 21:59 |
| corecode | so maybe in the docs they wanted to write UP but wrote UL | 22:00 |
| daveshah | UltraLite has them too | 22:00 |
| corecode | what are the chances that UP and UL have it, and LP doesn't? | 22:00 |
| daveshah | UL came before UP, so I think it's more likely they just never updated the docs after the UP release | 22:00 |
| daveshah | Quite likely, as UL came after iCE5LP | 22:01 |
| corecode | hm | 22:01 |
| corecode | i guess i should try changing the pcf | 22:01 |
| corecode | and see what happens | 22:01 |
| daveshah | Yeah | 22:01 |
| daveshah | add -pullup_resistor 3P3K and see if any cf_bits appear in the explain | 22:02 |
| corecode | interesting, we don't have any existing test | 22:03 |
| daveshah | No, I think my testing of that was very impromptu | 22:05 |
| corecode | ok, doesn't seem to change anything | 22:06 |
| corecode | i'm surprised that icecube doesn't complain | 22:07 |
| daveshah | Do you also have -pullup yes? | 22:07 |
| corecode | duh | 22:07 |
| daveshah | Yeah, it's funny that icecube accepts it then | 22:08 |
| *** m4ssi has quit IRC | 22:09 | |
| corecode | hey, it just discarded my input | 22:10 |
| corecode | and therefore the pullup | 22:10 |
| corecode | so R_EN is 1 when there is no pullup? | 22:11 |
| corecode | yea, doesn't look like there is any effect when i set -pullup yes -pullup_resistor 3P3K | 22:14 |
| corecode | set_io pin 2 -pullup yes -pullup_resistor 3P3K | 22:14 |
| daveshah | corecode: yes, REN is negative logic | 22:15 |
| daveshah | This means an empty bitstream or unconfigured device has all IO pins pulled up by default | 22:15 |
| corecode | i'm not a fan of default pullup, but okay | 22:17 |
| daveshah | It's a weak pullup, nominally 100k, FWIW | 22:18 |
| corecode | yea | 22:18 |
| daveshah | Probably consumes less current than a floating IO pin | 22:18 |
| corecode | but it means that you need to have some stronger pull-down to prevent positive logic from triggering | 22:18 |
| corecode | something connected | 22:18 |
| corecode | i had some silly effects with MCUs that would come up from reset with pull-up enabled | 22:19 |
| corecode | and we got a very brief flash of bright white light from the connected LEDs :) | 22:19 |
| corecode | ok, no pullups as i can tell | 22:20 |
| corecode | huh, the mystery bits are just set in ipcon tiles, but only 0-4 and 17-20 | 22:24 |
| corecode | and the DSPs don't seem to have anything set by default | 22:24 |
| daveshah | Interesting | 22:25 |
| corecode | https://gist.github.com/096eed842aff6ef3ca90644133ee0753 | 22:25 |
| tpb | Title: empty.tcl · GitHub (at gist.github.com) | 22:25 |
| corecode | module top;endmodule | 22:25 |
| daveshah | It could be that the mystery bits are only set when the DSP is used | 22:25 |
| corecode | yes | 22:26 |
| daveshah | I remember on the UltraPlus I tried removing them out of curiosity and the DSPs wouldn't work | 22:27 |
| corecode | ah yes | 22:27 |
| corecode | hehe | 22:27 |
| corecode | do i have to care about ip_dsp_lut_perm? | 22:28 |
| daveshah | No, that is obviously the same looking at that output | 22:29 |
| corecode | what does that permutation do? | 22:30 |
| daveshah | For 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 index | 22:31 |
| daveshah | Just to do with how the iCE40 bitstream is laid out | 22:31 |
| corecode | aha | 22:31 |
| corecode | now, how do i know whether some ipcon tiles will maybe get these mystery bits set? | 22:32 |
| corecode | because half of the ipcon tiles don't have bits set | 22:32 |
| daveshah | They might be set if you use an IP that is routed through one of those tiles | 22:33 |
| daveshah | You'd have to know the IP routing first though | 22:33 |
| corecode | so do i just always set the bits? | 22:34 |
| daveshah | At worst, setting them unnecessarily will probably slightly increase power consumption | 22:35 |
| corecode | ok | 22:36 |
| corecode | where do i get the delay data from? | 22:37 |
| daveshah | Once nextpnr is up and running you can use this script: https://github.com/YosysHQ/nextpnr/blob/master/ice40/tmfuzz.py | 22:39 |
| tpb | Title: nextpnr/tmfuzz.py at master · YosysHQ/nextpnr · GitHub (at github.com) | 22:39 |
| daveshah | If the basic delays that icefuzz found are the same as the up5k, then you can just use the up5k ones | 22:39 |
| corecode | and clktoq i get from the datasheet? | 22:40 |
| daveshah | No, clktoq you get from the timings_*.txt file | 22:45 |
| daveshah | Find the max IOPATH delay from posedge:clk to lcout | 22:46 |
| daveshah | The HTML might be easier to work with than the raw txt, if you prefer | 22:47 |
| corecode | ah, they get extracted out of icecube as well? | 22:47 |
| corecode | because i couldn't run them without yosys working | 22:47 |
| daveshah | Yeah | 22:47 |
| daveshah | Yosys shouldn't need any changes | 22:48 |
| daveshah | If it hits any unknown cell types then you'll need to add them directly to the timing edge extracted script: https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/tmedges.ys | 22:49 |
| tpb | Title: icestorm/tmedges.ys at master · cliffordwolf/icestorm · GitHub (at github.com) | 22:49 |
| *** tpb has joined #yosys | 22:52 | |
| corecode | so i guess to build nextpnr i first need to do yosys | 22:56 |
| corecode | tower of yakilon | 22:56 |
| daveshah | From memory the calls made to Yosys by the timing fuzzer are just to get the edge combinations which are shown in the HTML | 22:57 |
| daveshah | They aren't actually needed to build the data nextpnr needs | 22:58 |
| daveshah | But you need Yosys for a useful flow so might as well build and install it now | 22:58 |
| corecode | yea i need yosys to get the timing html | 22:59 |
| corecode | ERROR: Module `\SMCCLK' referenced in module `\top' in cell `\internalOscilator' is not part of the design. | 23:24 |
| corecode | what does it try to tell me? | 23:24 |
| corecode | (make timings) | 23:24 |
| daveshah | You'll need to add SMCCLK and its ports to this file https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/tmedges.ys | 23:25 |
| tpb | Title: icestorm/tmedges.ys at master · cliffordwolf/icestorm · GitHub (at github.com) | 23:25 |
| daveshah | Can you post the timing netlist verilog that has caused this error? I can't see why SMCCLK would be appearing at all | 23:25 |
| corecode | yea, that's what i am wondering | 23:26 |
| daveshah | I've never looked into it in great detail, but I think it provides the internal configuration clock | 23:26 |
| corecode | https://gist.github.com/9692d4c7315de1a6f2b7380bda1a0a30 | 23:26 |
| tpb | Title: aig_00.vsb · GitHub (at gist.github.com) | 23:26 |
| daveshah | Can you post a netlist for one of the smaller designs? Maybe fanout or binop | 23:30 |
| daveshah | This is not something that I've seen in any other ice40 | 23:30 |
| corecode | https://gist.github.com/669fdcb31090543b35fc4cc90ba27880 | 23:31 |
| tpb | Title: binop_00.vsb · GitHub (at gist.github.com) | 23:31 |
| corecode | sure | 23:31 |
| corecode | what's the legalize business | 23:32 |
| daveshah | So 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 IO | 23:32 |
| daveshah | I've not seen this before, but it reeks of silicon bug specific to the Ultra | 23:33 |
| corecode | aha! | 23:33 |
| daveshah | Probably because IO were being enabled slightly too early during startup and glitching | 23:33 |
| corecode | i've seen this before in the logs | 23:34 |
| daveshah | Interesting | 23:34 |
| corecode | Number of inserted LUTs to Legalize IOs with PIN_TYPE= 01xxxx :1 | 23:34 |
| corecode | this is with the latest icecube | 23:34 |
| corecode | maybe an older icecube wouldn't do this? | 23:35 |
| daveshah | Could be | 23:35 |
| corecode | let me run that for up5k | 23:35 |
| daveshah | I've not seen it for up5k and I was using latest icecube2 I think | 23:36 |
| corecode | that is correct | 23:47 |
| corecode | this is crazy! | 23:47 |
| corecode | i wonder what happens if you don't do that step | 23:48 |
| daveshah | You found a mystery CBIT in the bitstream, right? That could be related | 23:48 |
| corecode | i don't see that cbit anymore | 23:51 |
| corecode | it could have been the dsp error | 23:51 |
| daveshah | Yeah, possible | 23:51 |
| daveshah | I doubt that the SMCCLK behaviour will need to be replicated in nextpnr initially to get something working | 23:52 |
| daveshah | In the long term, it might be needed if icecube is adding it to work around a genuine issue | 23:52 |
| corecode | yea i doubt it too - that's something they would have caught | 23:53 |
| corecode | there is one bit set in ipcon 25 3 | 23:54 |
| corecode | let's see what explain says | 23:54 |
| daveshah | Given that every iCE40 has had slightly broken BRAM startup I wouldn't be so sure | 23:55 |
| corecode | buffer slf_op_5 sp12_h_r_2 | 23:56 |
| daveshah | That looks like the routing from the SMCCLK output | 23:57 |
| corecode | yes | 23:58 |
| daveshah | IP always uses slf_op_i in ipcon tiles for outputs | 23:58 |
| corecode | yep | 23:58 |
| corecode | so now we know where the internal oscillator sits :) | 23:58 |
| daveshah | Well, not the user internal oscillators but the secret mystery one :D | 23:59 |
| corecode | yes exactly | 23:59 |
| daveshah | Might as well add it to the icebox cells list anyway | 23:59 |
| corecode | heh i found something new! | 23:59 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!