| *** tpb has joined #yosys | 00:00 | |
| corecode | daveshah: i don't seem to find a way to specify a global buffer network | 00:07 |
|---|---|---|
| corecode | only promote/demote | 00:07 |
| daveshah | Use a manually placed SB_GB | 00:09 |
| corecode | yea, doing that now | 00:09 |
| corecode | well, 8 | 00:09 |
| corecode | otherwise it keeps placing it in the same location | 00:10 |
| daveshah | I'm pretty sure you can override this in floorplan view or the PCF file | 00:12 |
| *** Thorn has quit IRC | 00:12 | |
| daveshah | Something like set_location name x y z | 00:12 |
| corecode | well, i'm trying to figure out the gb locations | 00:13 |
| corecode | but this seems to have worked | 00:13 |
| daveshah | You can see them in floorplan view | 00:13 |
| daveshah | At some point you'll probably need to create them one by one to find out which network each fabout drives | 00:14 |
| corecode | i just created 8 inputs, 8 SB_GB, 8 outputs | 00:14 |
| corecode | aaah | 00:14 |
| corecode | hm, how would i know? | 00:15 |
| daveshah | By creating them one by one manually placed at each location | 00:15 |
| corecode | if i cannot constrain it to a network, i constrain it to a location | 00:16 |
| corecode | and then it has to be that network | 00:16 |
| daveshah | And seeing which glb_netwk appears in the icebox_explain output | 00:16 |
| corecode | doesn't explain use the data that i'm trying to fill in? | 00:16 |
| daveshah | Not this data | 00:16 |
| daveshah | icebox_vlog does | 00:17 |
| daveshah | icebox_explain is lower level, all it needs is the list of tiles and the actual bitstream bit mapping | 00:17 |
| corecode | ah no | 00:18 |
| corecode | i can see both | 00:18 |
| corecode | the explain shows me the network number | 00:18 |
| daveshah | Yeah | 00:18 |
| corecode | and given the output, i know what input clock it was | 00:18 |
| daveshah | Yeah, that works | 00:19 |
| corecode | does the order matter in gbufin_db? | 00:25 |
| daveshah | No, but it does for padin_db | 00:26 |
| corecode | ok | 00:26 |
| corecode | what about the location within the tile? the 0 1, does that not matter for the gbufin? | 00:27 |
| daveshah | No, it doesn't | 00:28 |
| corecode | ok | 00:28 |
| daveshah | I think it is always 2, but that isn't used anywhere | 00:28 |
| corecode | the psb shows | 00:29 |
| corecode | set_io gbufin_3 6 0 1 # ICE_GB | 00:29 |
| corecode | not always 1 though | 00:29 |
| daveshah | Yeah, that's fine | 00:30 |
| corecode | for my fake padin, does it matter there? | 00:30 |
| daveshah | No, it doesn't | 00:31 |
| *** pie_ has joined #yosys | 00:32 | |
| corecode | hm, vlog fails with nonexistant data | 00:47 |
| corecode | something in get_pll_bits | 00:47 |
| corecode | aha | 00:50 |
| *** emeb_mac has joined #yosys | 00:57 | |
| *** cr1901_modern has quit IRC | 00:59 | |
| corecode | daveshah: what do you mean by "So a tiny bit of semi-manual work is needed #first to discover this (basically run this script with show_all_bits=True #and look for the stuck bit" | 01:01 |
| corecode | run it completely? | 01:01 |
| corecode | i guess i'll see | 01:01 |
| * corecode waits for fuzzing to end | 01:01 | |
| *** emeb has quit IRC | 01:02 | |
| *** cr1901_modern has joined #yosys | 01:23 | |
| *** cr1901_modern has quit IRC | 01:48 | |
| *** jevinskie has joined #yosys | 01:55 | |
| *** gsi_ has joined #yosys | 02:04 | |
| *** gsi__ has quit IRC | 02:07 | |
| *** gsi_ has quit IRC | 02:20 | |
| *** cr1901_modern has joined #yosys | 02:45 | |
| *** seldridge has quit IRC | 03:15 | |
| *** citypw has joined #yosys | 04:04 | |
| *** citypw has quit IRC | 04:05 | |
| *** rohitksingh_work has joined #yosys | 04:07 | |
| *** citypw has joined #yosys | 04:12 | |
| *** pie__ has joined #yosys | 04:13 | |
| *** pie_ has quit IRC | 04:15 | |
| *** gsi_ has joined #yosys | 04:36 | |
| *** leviathanch has joined #yosys | 04:41 | |
| *** proteusguy has joined #yosys | 05:50 | |
| *** chaseemory has quit IRC | 06:07 | |
| *** awordnot has quit IRC | 06:32 | |
| *** awordnot has joined #yosys | 06:35 | |
| *** emeb_mac has quit IRC | 07:14 | |
| *** dys has quit IRC | 07:43 | |
| *** cr1901_modern has quit IRC | 07:55 | |
| *** cr1901_modern has joined #yosys | 07:56 | |
| *** jevinskie has quit IRC | 08:22 | |
| *** s_frit has joined #yosys | 08:25 | |
| *** m4ssi has joined #yosys | 08:40 | |
| *** pie_ has joined #yosys | 08:57 | |
| *** pie__ has quit IRC | 08:59 | |
| *** m_t has joined #yosys | 09:07 | |
| *** danieljabailey has quit IRC | 09:37 | |
| *** Thorn has joined #yosys | 10:00 | |
| *** leviathanch has quit IRC | 10:02 | |
| *** citypw has quit IRC | 10:21 | |
| *** Thorn has quit IRC | 10:26 | |
| *** flaviusb has joined #yosys | 10:33 | |
| corecode | gotta figure out where all these PLL ports come from | 11:30 |
| daveshah | corecode: icebox_vlog will tell you that | 12:26 |
| daveshah | Just connect each port to a pin and see where the routing for that pin ends up | 12:26 |
| corecode | yea, icebox_vlog still crashes based on missing data :) | 12:26 |
| corecode | but getting there | 12:27 |
| corecode | need to input the iolatch data | 12:27 |
| daveshah | sure, just fill in any old stuff to get icebox_vlog working, even comment it out | 12:32 |
| daveshah | There should be a script for the iolatch data | 12:32 |
| *** Thorn has joined #yosys | 12:35 | |
| *** rohitksingh_work has quit IRC | 12:55 | |
| *** m_t has quit IRC | 13:11 | |
| *** AlexDaniel has quit IRC | 13:21 | |
| *** jevinskie has joined #yosys | 13:47 | |
| *** tlwoerner has quit IRC | 13:51 | |
| *** rohitksingh has joined #yosys | 13:52 | |
| *** danieljabailey has joined #yosys | 14:01 | |
| *** somlo has quit IRC | 14:42 | |
| *** tlwoerner has joined #yosys | 14:42 | |
| *** leviathanch has joined #yosys | 14:47 | |
| *** develonepi3 has quit IRC | 15:10 | |
| *** jevinskie has quit IRC | 15:34 | |
| *** rohitksingh has quit IRC | 15:39 | |
| *** citypw has joined #yosys | 15:44 | |
| *** seldridge has joined #yosys | 15:46 | |
| *** develonepi3 has joined #yosys | 15:49 | |
| sxpert | ZipCPU: have some time for constructive criticism ? https://github.com/sxpert/hp-saturn/blob/master/saturn_bus_ctrl.v | 16:00 |
| tpb | Title: hp-saturn/saturn_bus_ctrl.v at master · sxpert/hp-saturn · GitHub (at github.com) | 16:00 |
| corecode | why [0:0]? | 16:01 |
| sxpert | because I get complaints about dimentions not set | 16:02 |
| corecode | wat | 16:02 |
| corecode | so what are you working on? | 16:03 |
| sxpert | https://en.wikipedia.org/wiki/Saturn | 16:03 |
| tpb | Title: Saturn - Wikipedia (at en.wikipedia.org) | 16:03 |
| sxpert | this | 16:03 |
| sxpert | ah, hmm, bad link ;) | 16:03 |
| corecode | -_- | 16:04 |
| sxpert | https://en.wikipedia.org/wiki/HP_Saturn | 16:04 |
| tpb | Title: HP Saturn - Wikipedia (at en.wikipedia.org) | 16:04 |
| sxpert | this | 16:04 |
| ZipCPU | sxpert: You are missing the `default_nettype none instruction at the top ;) | 16:04 |
| sxpert | ah | 16:05 |
| ZipCPU | You have several unused signals: i_en_bus_recv, i_en_bus_ecmd, i_alu_pc, i_read_pc, i_cmd_dp_read ... | 16:05 |
| ZipCPU | Oh, and almost forgot i_en_bus_send | 16:06 |
| * ZipCPU is running a verilator -Wall check | 16:06 | |
| sxpert | those are goners | 16:06 |
| corecode | is that the original bus? | 16:06 |
| sxpert | corecode: yes | 16:06 |
| *** rohitksingh has joined #yosys | 16:07 | |
| sxpert | theoretically the 4 datalines are bi-directionnal, but that may be impossible depending on the fpga | 16:07 |
| ZipCPU | You can turn the "noise" off by wrapping their definitions with "// verilator lint_off UNUSED" and "// verilator lint_on UNUSED". Alternatively, you can create one big unused chunk at the bottom with, "wire [N-1:0] unused; assign unused = { your_uused_wires };" and then wrap it with the Verilator lint statements | 16:07 |
| ZipCPU | (Replace N with the number of wires that are unused) | 16:08 |
| sxpert | no no, I ough to remove those unused signals, just didn't get to that yet | 16:08 |
| ZipCPU | That works too | 16:09 |
| sxpert | been furioulsy rewriting that thing 3 times or so ;) | 16:09 |
| ZipCPU | Still needs formal properties | 16:09 |
| corecode | good | 16:09 |
| sxpert | ZipCPU: well have to understand how that works first | 16:10 |
| corecode | yea me too | 16:10 |
| *** somlo has joined #yosys | 16:40 | |
| *** citypw has quit IRC | 17:24 | |
| corecode | daveshah: so what now? | 17:28 |
| corecode | i think i'm almost done | 17:28 |
| corecode | just need to do some pll port testing | 17:28 |
| daveshah | Next step is to make sure that icebox_chipdb generates the text database for arachne/nextpnr | 17:28 |
| *** m4ssi has quit IRC | 17:33 | |
| corecode | now i just need to see what signal is actually routed to the respective fabout locations | 17:37 |
| corecode | for the pll ports | 17:38 |
| *** emeb has joined #yosys | 17:43 | |
| corecode | how do i best trace the routing? | 17:46 |
| emeb | traceroute! | 17:50 |
| daveshah | corecode: just create a design with all the PLL pins connected to top IOs and run with icebox_vlog | 17:53 |
| daveshah | passing the PCF to icebox_vlog so it picks up port names too | 17:53 |
| *** leviathanch has quit IRC | 17:54 | |
| *** rohitksingh has quit IRC | 19:12 | |
| *** dys has joined #yosys | 19:18 | |
| *** vzcx has joined #yosys | 19:37 | |
| vzcx | has anyone had success using yosys/icestorm on openbsd? | 19:37 |
| ZipCPU | Are you struggling with anything in particular? | 19:38 |
| vzcx | i'm having trouble flashing my hx8k... seems to raise an error in libusb | 19:38 |
| vzcx | when using iceprog | 19:38 |
| ZipCPU | Does it build without problems? | 19:39 |
| vzcx | the iceprog tool? yes. | 19:41 |
| ZipCPU | What error do you get? | 19:42 |
| vzcx | usb_bulk_write failed | 19:42 |
| vzcx | this happens at the first call to send_byte, at the line commented "enable clock divide by 5" | 19:43 |
| * ZipCPU doesn't have openbsd, and is struggling to know what to ask next | 19:45 | |
| * vzcx knows disappointingly little about ftdi, hardware generally, and what's supposed to be happening here | 19:46 | |
| *** dys has quit IRC | 19:47 | |
| vzcx | i appreciate the effort at least! zipcpu is very cool and having it as an example is really accelerating my practical knowledge of comp arch and verilog | 19:49 |
| ZipCPU | Thanks! | 19:50 |
| ZipCPU | My own knowledge of FTDI+USB is really slim as well | 19:50 |
| *** dys has joined #yosys | 20:01 | |
| *** seldridge has quit IRC | 20:07 | |
| *** seldridge has joined #yosys | 20:14 | |
| corecode | daveshah: how do i find where PLLOUT_B is located at? | 20:32 |
| corecode | i guess it is PLLOUTCORE[1] | 20:32 |
| daveshah | It's PLLOUTCOREB/PLLOUTGLOBALB | 20:32 |
| corecode | but i'm looking at a vlog output, and i can't identify the location | 20:32 |
| daveshah | it will appear as an "input pin" | 20:32 |
| corecode | there is a whole lot of routing | 20:33 |
| daveshah | you should see a D_IN_0 in there? | 20:33 |
| corecode | aaaah | 20:33 |
| corecode | thanks | 20:33 |
| corecode | but where do i find the , 0 or , 1 | 20:33 |
| corecode | // (13, 21, 'io_0/D_IN_0') | 20:33 |
| daveshah | 0 | 20:33 |
| corecode | from the io_0? | 20:34 |
| daveshah | yeah | 20:34 |
| corecode | aha! | 20:34 |
| daveshah | the PLLs are in the input path | 20:34 |
| corecode | sorting the routing information by coordinate is not as useful as sorting it by connection | 20:34 |
| corecode | ok | 20:35 |
| corecode | should i run a connectivity test? | 20:35 |
| daveshah | yes, that would be a good idea | 20:36 |
| corecode | it took very long last time, and then i aborted | 20:36 |
| corecode | you had some feedback on not using the 8k ram db or something like it | 20:37 |
| daveshah | yeah, you should be using the 8k ram db not the 1k ram db | 20:37 |
| corecode | i thought i was | 20:38 |
| corecode | elif self.device == "5k" or self.device == "u4k": | 20:38 |
| corecode | add_seed_segments(idx, tile, rambtile_8k_db) | 20:38 |
| corecode | 20:38 | |
| corecode | that? | 20:38 |
| daveshah | that looks good | 20:38 |
| corecode | then it must have been something else | 20:38 |
| daveshah | the problem was in the icefuzz makefile I think | 20:38 |
| corecode | aha! | 20:38 |
| corecode | i guess that makefile needs some work | 20:41 |
| corecode | do i need to build my own u4k bitdata_dsp? | 20:42 |
| daveshah | Have you seen any changes to the dsp bitdata? | 20:43 |
| corecode | this one special dsp bit that lives elsewhere doesn't exist for me | 20:43 |
| corecode | or rather, is uniform like the other dsps | 20:43 |
| corecode | i don't think i quite understand this bitdata thing | 20:44 |
| daveshah | The lack of a special bit doesn't matter, that's all dealt with in icebox | 20:45 |
| daveshah | the bitdata contains the routing bits, and low-level names of config bits | 20:45 |
| daveshah | higher-level mapping is done in icebox | 20:45 |
| *** SpaceCoaster has quit IRC | 20:53 | |
| *** SpaceCoaster has joined #yosys | 20:55 | |
| *** seldridge has quit IRC | 21:42 | |
| sxpert | corecode: you guys are hacking at yet another ice40 ? | 21:43 |
| sxpert | crap, more work: DEC_INIT 2: nibble 9 not handled | 21:44 |
| *** dys has quit IRC | 21:57 | |
| *** dys has joined #yosys | 22:05 | |
| corecode | what's that error message? | 22:30 |
| corecode | yea, ice5lp, aka ice40 ultra | 22:31 |
| *** vzcx has quit IRC | 23:05 | |
| corecode | Module SB_RGB_IP is not a valid primitive. Please check | 23:14 |
| corecode | wut | 23:14 |
| emeb | corecode: glad to hear you're doing ultra! | 23:15 |
| emeb | I've got a large stash of ice5lp4k sg48 parts leftover from a while ago. | 23:16 |
| emeb | (and I know someone who has a whole reel of them that he's probably never going to use) | 23:17 |
| corecode | i'll take them :) | 23:17 |
| daveshah | corecode: oh lmao | 23:17 |
| daveshah | I remember reading about this | 23:18 |
| daveshah | the hard SB_LEDD_IP primitive in the ice40 ultra is broken | 23:18 |
| daveshah | SB_RGB_IP isn't a primitive at all, just soft logic | 23:18 |
| emeb | I thought that was just the PWM stuff that was borken | 23:19 |
| emeb | but the actual high current drivers work OK | 23:19 |
| daveshah | yeah, that is SB_LEDD_IP/SB_RGB_IP | 23:19 |
| daveshah | the drivers are indeed fine | 23:19 |
| daveshah | afaik | 23:19 |
| emeb | yeah - I've run into that too. | 23:19 |
| corecode | ah what | 23:19 |
| corecode | so do i skip that? | 23:20 |
| emeb | probably best | 23:20 |
| emeb | unless you want to make a synthesizable soft core for it :) | 23:21 |
| corecode | so what is broken? | 23:23 |
| corecode | i can't find documentation on the SB_LEDD_IP | 23:24 |
| daveshah | no, because it is broken | 23:25 |
| corecode | broken how? | 23:28 |
| corecode | it was supposed to do some driving? | 23:28 |
| corecode | or is that the pwm ramp generator | 23:28 |
| daveshah | it's a pwm generator core (for things like fading/ breathing effects), it doesn't do the actual high current stuff | 23:28 |
| corecode | okay | 23:30 |
| emeb | corecode: you in the US? | 23:30 |
| corecode | emeb: no | 23:30 |
| corecode | ok the icefuzz makefile runs | 23:30 |
| daveshah | do you see any changes to icebox/iceboxdb.py once it has finished running? | 23:31 |
| corecode | no | 23:32 |
| daveshah | good, that means low level bits are the same | 23:32 |
| corecode | well, over all, yes | 23:32 |
| corecode | so now i can run the | 23:32 |
| corecode | meh | 23:32 |
| corecode | https://github.com/cliffordwolf/icestorm/compare/master...corecode:u4k?expand=1 | 23:32 |
| tpb | Title: Comparing cliffordwolf:master...corecode:u4k · cliffordwolf/icestorm · GitHub (at github.com) | 23:32 |
| corecode | there are some changes, but they seem unrelated? | 23:32 |
| corecode | i don't know where these come from | 23:32 |
| daveshah | those are because of the ram database issue | 23:33 |
| daveshah | effectively you've put the 8k/u4k/all newer ice40 ram bits into the 1k db | 23:33 |
| corecode | why doesn't it get fixed? | 23:33 |
| corecode | ah, i need to run the generation for the 1k again | 23:33 |
| daveshah | no, the database is accumulative | 23:34 |
| corecode | or rather, i revert to the original state, and then run for the u4k | 23:34 |
| daveshah | you'll need to checkout iceboxdb.py from master and run again | 23:34 |
| daveshah | yup | 23:34 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!