| *** tpb has joined #yosys | 00:00 | |
| *** emeb has quit IRC | 00:54 | |
| *** gsi__ has joined #yosys | 01:44 | |
| *** gsi_ has quit IRC | 01:47 | |
| *** ZipCPU has quit IRC | 01:49 | |
| *** promach has quit IRC | 02:32 | |
| *** promach has joined #yosys | 03:04 | |
| *** leviathanch has joined #yosys | 03:22 | |
| *** lutsabound has joined #yosys | 03:25 | |
| *** citypw has joined #yosys | 03:29 | |
| *** ZipCPU has joined #yosys | 03:50 | |
| *** emeb has joined #yosys | 04:30 | |
| *** rohitksingh_work has joined #yosys | 04:46 | |
| *** rohitksingh has joined #yosys | 04:47 | |
| *** pie__ has joined #yosys | 04:57 | |
| *** pie___ has quit IRC | 05:01 | |
| *** gsi__ is now known as gsi_ | 05:44 | |
| *** lutsabound has quit IRC | 05:54 | |
| *** kraiskil has joined #yosys | 07:32 | |
| *** _whitelogger has quit IRC | 07:58 | |
| *** leviathanch has quit IRC | 07:58 | |
| *** m4ssi has joined #yosys | 08:01 | |
| *** _whitelogger has joined #yosys | 08:33 | |
| *** rohitksingh has quit IRC | 08:46 | |
| *** rohitksingh_work has quit IRC | 08:52 | |
| promach | corecode : the problem with NoC compared to regular bus is that we might have some problem determining the starting packets nodes as well as finishing packets nodes | 09:06 |
|---|---|---|
| promach | in other words, for a task to be loaded into the computation units within the NoC, it is a bit difficult to determine the start nodes and finish nodes | 09:07 |
| promach | so, it is more about finding out where the data entrance and exit points | 09:08 |
| promach | corecode : have you done some coding on NoC previously ? | 09:37 |
| *** rohitksingh has joined #yosys | 09:40 | |
| promach | it is really a headache to do the mapping of computation task to the computation units within a NoC | 09:54 |
| promach | I mean without the help of gcc compiler | 10:01 |
| *** citypw has quit IRC | 10:11 | |
| *** rohitksingh has quit IRC | 10:11 | |
| *** rohitksingh has joined #yosys | 10:26 | |
| *** rohitksingh has quit IRC | 10:55 | |
| *** citypw has joined #yosys | 11:35 | |
| *** leviathanch has joined #yosys | 12:04 | |
| corecode | hi promach | 12:10 |
| corecode | why is it hard? | 12:11 |
| corecode | what computation do you want to do? | 12:11 |
| *** cr1901_modern has quit IRC | 12:27 | |
| *** cr1901_modern has joined #yosys | 12:28 | |
| * sxpert is having fun with logisim-evolution | 12:34 | |
| sxpert | finds it more intuitive than bare verilog | 12:35 |
| corecode | why intuitive? | 12:37 |
| *** kraiskil has quit IRC | 12:37 | |
| *** maikmerten has joined #yosys | 12:45 | |
| *** kraiskil has joined #yosys | 13:04 | |
| *** rohitksingh has joined #yosys | 13:06 | |
| *** kraiskil has quit IRC | 13:14 | |
| *** kraiskil has joined #yosys | 13:27 | |
| *** maikmerten has quit IRC | 13:31 | |
| *** promach_ has joined #yosys | 13:33 | |
| promach_ | corecode : see figure 2 of http://sci-hub.tw/https://dl.acm.org/citation.cfm?id=2423179 | 13:33 |
| tpb | Title: Sci-Hub: устраняя преграды на пути распространения знаний (at sci-hub.tw) | 13:33 |
| corecode | this is all academic research wank | 13:35 |
| promach_ | ??? | 13:35 |
| corecode | you need to use more words | 13:35 |
| promach_ | I am trying to map some different computation DFGs to NoC | 13:36 |
| promach_ | remember I have few DFGs to work with | 13:36 |
| corecode | i don't remember | 13:36 |
| corecode | because i never was shown | 13:36 |
| promach_ | corecode : so basically, I have few computation maths equations to be calculated using multiple processing units within the NoC | 13:37 |
| promach_ | DFG means data flow graph | 13:37 |
| promach_ | something that is formed from maths expressions, do you get it ? | 13:37 |
| corecode | yes, i know what a dfg is | 13:38 |
| promach_ | like how the data from intermediate operations are led to the next operation | 13:38 |
| promach_ | and how the final result is obtaied after multiple path traversal | 13:38 |
| promach_ | now, I have some DFGs | 13:38 |
| promach_ | corecode | 13:38 |
| promach_ | and to be mapped onto the processing units within the NoC | 13:39 |
| MoeIcenowy | daveshah: could I ignore RGB driver and assign general SB_IO to RGB pins of UP5K? | 13:40 |
| daveshah | Yes | 13:40 |
| MoeIcenowy | ok good | 13:40 |
| daveshah | but they are always open drain | 13:40 |
| daveshah | no pullup either | 13:40 |
| MoeIcenowy | daveshah: no problem, I connected them to the negative side of LED | 13:40 |
| MoeIcenowy | (but I didn't connect resistors... | 13:41 |
| MoeIcenowy | (refered the design of UPduino | 13:41 |
| promach_ | corecode : do you now understand what I am trying to do with the DFG ? | 13:45 |
| corecode | but what do you want to do concretely | 13:46 |
| *** leviathanch has quit IRC | 13:52 | |
| *** leviathanch has joined #yosys | 13:52 | |
| *** leptonix has joined #yosys | 14:12 | |
| *** qu1j0t3 has quit IRC | 14:26 | |
| promach_ | corecode: mapping DFG to NoC | 14:32 |
| *** qu1j0t3 has joined #yosys | 14:37 | |
| *** kraiskil has quit IRC | 14:38 | |
| *** lutsabound has joined #yosys | 15:02 | |
| MoeIcenowy | oh I changed my design to use PLL out as clock | 15:06 |
| MoeIcenowy | and then the full design got optimized out by Yosys | 15:07 |
| MoeIcenowy | oh dropped the judge of locked at internal reset generation | 15:07 |
| MoeIcenowy | sorry for false positive | 15:07 |
| MoeIcenowy | I used wrong name for locked signal when defining SB_PLL40_CORE | 15:08 |
| MoeIcenowy | daveshah: what's corresponding timing config in iCECube2 is used for icetime? | 15:21 |
| MoeIcenowy | worst? | 15:21 |
| daveshah | yeah | 15:21 |
| MoeIcenowy | and when running icetime with a design that uses all clocks derived from PLL | 15:22 |
| MoeIcenowy | will icetime output the freq requirment of PLL out or PLL in? | 15:22 |
| MoeIcenowy | (I assume PLL out | 15:22 |
| daveshah | neither, icetime supports a single constraint on all clocks | 15:23 |
| daveshah | passed by command line | 15:23 |
| MoeIcenowy | oh so in my situation it's PLL out? | 15:23 |
| daveshah | yeah | 15:23 |
| MoeIcenowy | (because in all alwayses pllout is used | 15:23 |
| corecode | promach_: which DFG | 15:24 |
| MoeIcenowy | daveshah: for UP5K, is icetime using commercial temperature range or industrial? | 15:25 |
| daveshah | commercial | 15:26 |
| daveshah | https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/icecube.sh#L472 | 15:26 |
| tpb | Title: icestorm/icecube.sh at master · cliffordwolf/icestorm · GitHub (at github.com) | 15:26 |
| daveshah | 85 degrees, 1.14V, worst | 15:26 |
| daveshah | same as icecube defaults afaik | 15:26 |
| MoeIcenowy | I'm now thinking soldering a 50MHz osc on an iCE40UP5K board may be too high? | 15:27 |
| MoeIcenowy | on my design with Altera Cyclone IV and Anlogic Eagle-4 (both uses proprietary toolchian) that can reach 100MHz+ | 15:28 |
| daveshah | Can always divide it down | 15:28 |
| MoeIcenowy | iCE40UP5K gets only 40Mhz+ | 15:28 |
| *** ZipCPU has quit IRC | 15:28 | |
| daveshah | 50MHz is towards the upper limit of what the up5k can do | 15:28 |
| MoeIcenowy | oh | 15:29 |
| MoeIcenowy | I start to doubt whether iCECube2 or Radient can do 50MHz+ | 15:29 |
| tnt | Well ... depends what you're trying to do ... but icecube2 can definitely do stuff that runs above 50M. | 15:37 |
| tnt | But if you're trying to make a 20 layer combinatorial logic block, that's clearly not going to fly ... | 15:37 |
| MoeIcenowy | oh icecube2 refused my design with icestorm | 15:40 |
| MoeIcenowy | just error with no message when "Import P&R Input Files" | 15:40 |
| tnt | yeah you can't mix toolchains. | 15:40 |
| tnt | in/out are not compatible. | 15:40 |
| MoeIcenowy | tnt: I used no SB_ cells for IO | 15:41 |
| MoeIcenowy | I only used SB_RGBA_DRV and SB_PLL40_CORE | 15:41 |
| tnt | I meant you can't feed a yosys output into icecube. | 15:41 |
| MoeIcenowy | I didn't feed the yosys output | 15:42 |
| MoeIcenowy | I feed v's to Synplify | 15:42 |
| MoeIcenowy | Synplify succeed | 15:42 |
| tnt | Oh ok, sorry I misunderstood. | 15:43 |
| tnt | Can you paste your code ? | 15:44 |
| MoeIcenowy | https://github.com/Icenowy/bfcpu | 15:44 |
| tpb | Title: GitHub - Icenowy/bfcpu: A simple CPU that runs Br**nf*ck code. (at github.com) | 15:44 |
| MoeIcenowy | iCECube2 proj not included | 15:44 |
| MoeIcenowy | just add verilog sources specified in Makefile_icecream_v1 and icecream_v1.pcf to proj | 15:44 |
| promach_ | corecode : https://paste.ubuntu.com/p/phVpwfrrtF/ is one example | 15:45 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 15:45 |
| promach_ | this is sort of manipulating how the final result is obtained | 15:46 |
| promach_ | corecode : from the c code, get a DFG (this is usually done by compiler tool, not human) | 15:46 |
| promach_ | and the DFG is optimized by human for hardware | 15:47 |
| *** emeb_mac has joined #yosys | 15:47 | |
| corecode | okay | 15:49 |
| corecode | well, good luck | 15:49 |
| tnt | MoeIcenowy: Import "P&R" file works fine here. | 15:50 |
| tnt | Placed and routed as well. | 15:51 |
| daveshah | fyi, just tried your design and noticed the critical path is posedge->negedge which icetime doesn't handle correctly | 15:52 |
| daveshah | nextpnr does, and gives 25MHz Fmax | 15:52 |
| MoeIcenowy | nextpnr can deliver timing info? | 15:55 |
| MoeIcenowy | tnt: maybe my iCECube2 is cursed? | 15:55 |
| daveshah | yeah, it has much better timing analysis than icetime | 15:55 |
| daveshah | also supports multiple clocks unlike icetime | 15:55 |
| MoeIcenowy | I used 2017.08 | 15:55 |
| tnt | Me too | 15:55 |
| tnt | you might want to retry to create a project from scratch. I kno corecode (IIRC) also has issue witha corrupted project file / env throwing stuff off. | 15:56 |
| MoeIcenowy | I just created it... | 15:56 |
| tnt | oh. | 15:56 |
| corecode | yep, i don't know what i did, but it failed to place | 15:56 |
| *** shuggsy has joined #yosys | 15:57 | |
| MoeIcenowy | I will try Radiant then | 15:57 |
| MoeIcenowy | tnt: did you import the PCF? | 15:57 |
| tnt | I did | 15:57 |
| tnt | Radiant is annoying because they changes the primitives, so you can't have same code with instanciated primites that works in icecube and in radiant. | 15:57 |
| MoeIcenowy | "/home/icenowy/git-repos/bfcpu/i_mem_icecream_v1.v":16:1:16:9|Cannot find data file instructions_icecream_v1.hex for task $readmemh | 15:59 |
| MoeIcenowy | WTF? Synplify Pro cannot find the hex file in the same directory with source file? | 15:59 |
| MoeIcenowy | CURSED. | 15:59 |
| MoeIcenowy | tnt: where's the Radient primitives library? | 16:01 |
| MoeIcenowy | BTW I recreated a proj, and still failed to PnR | 16:01 |
| corecode | no, it cannot | 16:01 |
| corecode | the synplify project is elsewhere | 16:01 |
| MoeIcenowy | maybe it's now the time for `rm -rf ~/fpga/lattice/iCEcube2.2017.08/`? | 16:01 |
| MoeIcenowy | remembered when attending our "Laboratory of Computer Organization" lesson, the teacher warned us that under Vivado only absolute path will work for $readmemh | 16:05 |
| tnt | Well to be fair yosys also looks for file in cwd and not in the same directory as the source file. I wish verilog had the same as C for include where using "" searches the same dir as the source. | 16:13 |
| daveshah | heh, looks like we actually beat icecube in this case | 16:14 |
| daveshah | icecube is reporting 22-24MHz across runs, nextpnr with the new criticality driven placer is getting 25-27MHz | 16:14 |
| tnt | daveshah: ? I get 36.98 MHz with icecube | 16:14 |
| daveshah | is it picking up the hex file? | 16:15 |
| tnt | Oh ... | 16:15 |
| daveshah | I was getting around that when it wasn't processing the readmemh and optimised half the core away | 16:15 |
| MoeIcenowy | seems that if hex is not picked | 16:15 |
| MoeIcenowy | the whole i_mem is optimized out | 16:15 |
| MoeIcenowy | too clever | 16:15 |
| daveshah | synthesis tools are too clever until they aren't clever enough :P | 16:16 |
| MoeIcenowy | daveshah: it's still not clever enough to optimize the whole core ;-) | 16:16 |
| MoeIcenowy | optimize it to fixed 000 output ;-) | 16:16 |
| daveshah | at some point you hit the halting problem | 16:16 |
| MoeIcenowy | daveshah: BTW how to let nextpnr generate timing report? | 16:17 |
| daveshah | it does it automatically | 16:17 |
| daveshah | just look towards the end of the output | 16:17 |
| daveshah | unless you run with -q, then it will only print failures | 16:17 |
| MoeIcenowy | daveshah: by proving it's not a turing machine halting problem can be solved | 16:17 |
| daveshah | yes, this is true | 16:18 |
| tnt | daveshah: indeed, now I get 23.5M | 16:19 |
| MoeIcenowy | I think maybe if we try to inject not-so-optimized yosys result to iCECube2 PnR | 16:20 |
| MoeIcenowy | it will be lower freq | 16:20 |
| MoeIcenowy | ;-) | 16:20 |
| daveshah | yeah, Yosys does struggle a bit with some optimisations atm | 16:21 |
| tnt | Is there a way to feed synopsys output to nextpnr ? | 16:21 |
| daveshah | hmm | 16:22 |
| daveshah | not sure if it can export anything other than an edif | 16:22 |
| MoeIcenowy | daveshah: it says to export VQM | 16:22 |
| daveshah | that might work | 16:22 |
| MoeIcenowy | but I don't know whether Lattice ver of Synplify supports it | 16:22 |
| MoeIcenowy | oh maybe it's now the time for me to rebuilt nextpnr | 16:23 |
| MoeIcenowy | my nextpnr version here only produces 22MHz | 16:23 |
| *** emeb_mac has quit IRC | 16:23 | |
| MoeIcenowy | and fails timing check | 16:23 |
| daveshah | I'm on my working branch which is this PR: https://github.com/YosysHQ/nextpnr/pull/219 | 16:24 |
| tpb | Title: HeAP-based analytical placer by daveshah1 · Pull Request #219 · YosysHQ/nextpnr · GitHub (at github.com) | 16:24 |
| daveshah | this both improves the current placer1 and adds a new placer | 16:24 |
| daveshah | I was actually using the improved placer1 to get the 27MHz result | 16:24 |
| daveshah | hoping this gets approved and merged this week | 16:24 |
| MoeIcenowy | so a rebuild is really useful? | 16:25 |
| daveshah | I don't think rebuilding master will make much difference | 16:25 |
| MoeIcenowy | BTW does rebuilding master require rebuild icestorm? | 16:25 |
| daveshah | yes, because the u4k device was added | 16:25 |
| MoeIcenowy | daveshah: how does --opt-timing work? | 16:27 |
| daveshah | that runs an extra post-placement pass that can improve timing a bit (at the expense of runtime, and not always improving) | 16:27 |
| daveshah | master with opt-timing gets me 27.9Mhz | 16:28 |
| MoeIcenowy | hears so good | 16:28 |
| MoeIcenowy | so maybe master will help | 16:28 |
| MoeIcenowy | currently mine is 19cffde | 16:29 |
| tnt | daveshah: synopsis can actually write out a mapped verilog netlist. | 16:29 |
| *** emeb has quit IRC | 16:29 | |
| MoeIcenowy | tnt: it's VQM | 16:29 |
| MoeIcenowy | oh that reminds me of the VQM generated by Yosys not recognized by Quartus Prime 18.1 | 16:30 |
| daveshah | yeah, just found it | 16:30 |
| MoeIcenowy | VQM seems to be a quite strict Verilog subset | 16:30 |
| MoeIcenowy | BTW something interesting: AGM Supra, which uses Quartus II defaultly as its synthesis suite, can read Yosys VQM (because Yosys is also its choice) | 16:31 |
| daveshah | Looks like it needs a definition of SB_RAM512x8NR | 16:32 |
| daveshah | then Yosys should handle it | 16:32 |
| tnt | For some IPs the config seem to be attributes rather than params, that ight be anissue. | 16:32 |
| MoeIcenowy | now I start to believe iCE40 has really bad timing | 16:34 |
| tnt | The UP5K is optimized for ultra low power, not for speed. | 16:39 |
| daveshah | so looks like nextpnr gets 22MHz on the synplify netlist | 16:39 |
| MoeIcenowy | tnt: HX is for speed? | 16:39 |
| tnt | MoeIcenowy: yes. | 16:39 |
| MoeIcenowy | daveshah: the same branch with Yosys netlist? | 16:39 |
| tnt | although ... it's still a 'low power class' so don't go expects Xilinx 7 series level of perf. | 16:39 |
| daveshah | MoeIcenowy: 27MHz | 16:40 |
| tnt | daveshah: interesting. | 16:40 |
| *** rohitksingh has quit IRC | 16:40 | |
| MoeIcenowy | really interesting | 16:40 |
| MoeIcenowy | how about LC usage? | 16:40 |
| MoeIcenowy | BTW is there anyone crazy enough to attach a SDRAM to iCE40UP? | 16:41 |
| daveshah | Synplify wins, about 455 LCs compared to 503 | 16:41 |
| MoeIcenowy | tnt: I used to expect Cyclone IV E level of perf | 16:41 |
| tnt | I have 0 experience with altera so ... can't comment. | 16:42 |
| MoeIcenowy | my main experience is with altera | 16:42 |
| MoeIcenowy | then anlogic | 16:42 |
| MoeIcenowy | then xilinx | 16:42 |
| MoeIcenowy | silliconblue just started | 16:43 |
| MoeIcenowy | and never any experience with genuine lattice | 16:43 |
| MoeIcenowy | daveshah: I remember synplify always win on space to yosys | 16:44 |
| MoeIcenowy | it might be useful if you want to use LP384 ;-) | 16:45 |
| daveshah | yeah, seems to win on space but not timing (tried setting a timing constraint but didn't seem to change things) | 16:45 |
| MoeIcenowy | BTW for FPGA REing I now think the infomation given by vendor toolchain is very necessary ;-) | 16:46 |
| *** qu1j0t3 has left #yosys | 16:46 | |
| MoeIcenowy | I abandoned to RE AGM AG1280 because it can give out no useful info except a JTAG sequence used to burn the FPGA | 16:47 |
| MoeIcenowy | Lattice and SiliconBlue toolchain seem to deliver many useful internal info | 16:48 |
| *** rohitksingh has joined #yosys | 17:02 | |
| corecode | you mean it doesn't produce a binary? | 17:05 |
| MoeIcenowy | corecode: it do produce, but a binary cannot be burned at all | 17:06 |
| MoeIcenowy | to burn the bitstream into SRAM the JTAG sequence is needed | 17:06 |
| MoeIcenowy | and binary cannot be furtherly converted | 17:06 |
| MoeIcenowy | the only chance of generating JTAG sequence is when PnR | 17:06 |
| corecode | so what is the holdup for RE? | 17:07 |
| MoeIcenowy | you cannot even judge whether the binary file is meaningful | 17:09 |
| MoeIcenowy | I remember at least one generation function of AGM Supra generates useless output, that is what the FAE says | 17:09 |
| corecode | you mean whether the vendor tool produced a correct bitstream? | 17:09 |
| MoeIcenowy | yes | 17:10 |
| corecode | well that is a requirement of course | 17:10 |
| corecode | or you would have to verify the behavior from the outside | 17:10 |
| MoeIcenowy | but the bitstream file is not used in any process at all | 17:10 |
| MoeIcenowy | only the programming command file is useful | 17:11 |
| corecode | jtag command sequence is the equivalent to a bitstream | 17:11 |
| MoeIcenowy | yes | 17:11 |
| MoeIcenowy | but I think extract info from it will be weird | 17:11 |
| corecode | not different from a bitstream | 17:11 |
| *** lutsabound has quit IRC | 17:12 | |
| *** maikmerten has joined #yosys | 17:17 | |
| *** promach_ has quit IRC | 17:22 | |
| MoeIcenowy | oh for the previous PnR failure on iCEcube2 | 17:30 |
| MoeIcenowy | I just checked my dmesg | 17:30 |
| tnt | OOM ? | 17:31 |
| MoeIcenowy | it says "edifparser[15356]: segfault at 0 ip 00000000f7e9d5e2 sp 00000000ff905838 error 4 in liboaCommon.so[f7e92000+11000]" | 17:31 |
| MoeIcenowy | just segfault | 17:31 |
| MoeIcenowy | no OOM | 17:31 |
| tnt | ah well. | 17:31 |
| MoeIcenowy | not only edifparser can fail on Yosys EDIF, but it can also fail on Synplify Pro EDIF | 17:32 |
| MoeIcenowy | hahahaha | 17:32 |
| MoeIcenowy | nextpnr perfectly outperform iCEcube2 here by no segfault | 17:33 |
| MoeIcenowy | ;-) | 17:33 |
| *** m4ssi has quit IRC | 17:34 | |
| *** svenn has quit IRC | 18:04 | |
| *** svenn has joined #yosys | 18:04 | |
| *** rohitksingh has quit IRC | 19:15 | |
| *** fseidel has joined #yosys | 19:21 | |
| *** voxadam_ is now known as voxadam | 19:22 | |
| *** eigenzer_ has joined #yosys | 19:26 | |
| *** leviathanch has quit IRC | 19:27 | |
| *** eigenzer_ has quit IRC | 20:04 | |
| *** emeb_mac has joined #yosys | 20:37 | |
| *** shuggsy has quit IRC | 20:42 | |
| *** emeb_mac has quit IRC | 21:18 | |
| *** m4ssi has joined #yosys | 21:20 | |
| *** maikmerten has quit IRC | 21:21 | |
| *** ddrown_ has joined #yosys | 22:51 | |
| *** zkms_ has joined #yosys | 22:54 | |
| *** _whitelogger has quit IRC | 23:00 | |
| *** zkms has quit IRC | 23:00 | |
| *** litghost has quit IRC | 23:00 | |
| *** ddrown has quit IRC | 23:00 | |
| *** thoughtpolice has quit IRC | 23:00 | |
| *** thoughtpolice has joined #yosys | 23:05 | |
| *** m4ssi has quit IRC | 23:09 | |
| *** m4ssi has joined #yosys | 23:19 | |
| *** massi_ has joined #yosys | 23:21 | |
| *** m4ssi has quit IRC | 23:24 | |
| *** shuggsy has joined #yosys | 23:41 | |
| *** shuggsy has quit IRC | 23:42 | |
| *** _whitelogger has joined #yosys | 23:49 | |
| *** proteusguy has quit IRC | 23:54 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!