| *** tpb has joined #yosys | 00:00 | |
| *** danieljabailey has quit IRC | 00:07 | |
| *** emeb_mac has joined #yosys | 00:10 | |
| *** promach_ has joined #yosys | 01:24 | |
| *** awordnot has quit IRC | 01:28 | |
| *** awordnot has joined #yosys | 01:30 | |
| *** promach_ has quit IRC | 01:48 | |
| *** gsi__ has joined #yosys | 02:20 | |
| *** promach has joined #yosys | 02:22 | |
| *** gsi_ has quit IRC | 02:22 | |
| promach | Could anyone comment on https://www.reddit.com/r/yosys/comments/apc1j3/3d_array_bitwidth_mismatch/ ? | 03:39 |
|---|---|---|
| tpb | Title: 3D array bitwidth mismatch : yosys (at www.reddit.com) | 03:39 |
| *** emeb_mac has quit IRC | 03:45 | |
| *** emeb_mac has joined #yosys | 03:50 | |
| *** dys has quit IRC | 03:51 | |
| *** emeb_mac has left #yosys | 03:56 | |
| *** danieljabailey has joined #yosys | 04:08 | |
| chaseemory | i imagine its some confusion with packed vs unpacked arrays, in your case mixing both, but the output should be 8bits no? | 04:15 |
| *** rohitksingh has joined #yosys | 04:21 | |
| *** lutsabound has quit IRC | 04:22 | |
| *** rohitksingh has quit IRC | 04:33 | |
| *** pie___ has joined #yosys | 04:34 | |
| *** pie__ has quit IRC | 04:37 | |
| *** rohitksingh_work has joined #yosys | 04:45 | |
| *** SpaceCoaster has joined #yosys | 05:09 | |
| *** proteusguy has quit IRC | 05:17 | |
| *** emeb_mac has joined #yosys | 05:28 | |
| emeb_mac | does there exist a library of stubs for the Lattice SB_* cells that can be used for linting w/ Verilator? | 05:29 |
| emeb_mac | or is there some way to blackbox those w/o a library? | 05:30 |
| promach | chaseemory : if you look at https://www.verilogpro.com/systemverilog-arrays-synthesizable/ , I am using "Unpacked Array Assignment" | 05:31 |
| tpb | Title: SystemVerilog Arrays, Flexible and Synthesizable - Verilog Pro (at www.verilogpro.com) | 05:31 |
| promach | reg [(A_WIDTH+B_WIDTH-1):0] middle_layers[(NUM_OF_INTERMEDIATE_LAYERS-1):0][0:(SMALLER_WIDTH-1)]; | 05:36 |
| promach | chaseemory | 05:36 |
| *** proteusguy has joined #yosys | 06:54 | |
| *** dys has joined #yosys | 06:56 | |
| *** jevinskie has quit IRC | 07:00 | |
| *** dys has quit IRC | 07:25 | |
| daveshah | emeb_mac: https://github.com/YosysHQ/yosys/blob/master/techlibs/ice40/cells_sim.v might do the trick | 07:55 |
| tpb | Title: yosys/cells_sim.v at master · YosysHQ/yosys · GitHub (at github.com) | 07:55 |
| promach | is it true that yosys does not support packed array yet ? logic [A-1:0][B-1:0][C-1:0] array; | 08:04 |
| *** m4ssi has joined #yosys | 08:11 | |
| *** _whitelogger has quit IRC | 08:37 | |
| *** _whitelogger has joined #yosys | 08:41 | |
| *** leviathanch has joined #yosys | 08:50 | |
| sxpert | how would I <= the same value to multiple things at the same time ? | 09:41 |
| sxpert | do I have to copy / paste the operation, or is there a nicer way to do that ? | 09:41 |
| daveshah | If the destination is an array, then use a for loop | 09:57 |
| sxpert | no, it's like I calculate some value, and needs it in 2 reg | 10:01 |
| sxpert | which are used by 2 different things | 10:01 |
| sxpert | say, the alu_dest register and the dbg_dest register | 10:02 |
| daveshah | This is a rare case where non-blocking assignments are reasonable | 10:04 |
| daveshah | e.g tmp_result = op; alu_dest <= tmp_result; dbg_dest <= tmp_result | 10:05 |
| sxpert | ok | 10:05 |
| sxpert | however verilator would somehow complain I guess | 10:05 |
| sxpert | daveshah: can tmp_result be declared locally ? | 10:06 |
| daveshah | Not in traditional Verilog, SystemVerilog probably supports something like that | 10:07 |
| sxpert | I see | 10:07 |
| daveshah | Either way it is essential that tmp_result is only accessed and written in one always block | 10:07 |
| daveshah | otherwise it might be a race condition in simulation | 10:07 |
| sxpert | I suppose reading from multiple locations would not be a biggie | 10:08 |
| daveshah | This is definitely where VHDL wins, the "variable" local to a process is much nicer | 10:08 |
| sxpert | I see | 10:08 |
| daveshah | sxpert: multiple locations in one always block is fine | 10:08 |
| sxpert | ah | 10:08 |
| daveshah | In different always blocks there are race condition issues in simulation | 10:08 |
| sxpert | I see | 10:08 |
| sxpert | unlike with <= | 10:08 |
| daveshah | Indeed | 10:09 |
| sxpert | ok | 10:09 |
| daveshah | This is one reason why = is generally discouraged | 10:09 |
| daveshah | in clocked always blocks | 10:09 |
| daveshah | Temporary results are a limited exception | 10:10 |
| sxpert | the fact that the concept of temporary results are missing from the language is an oversight IMHO | 10:10 |
| daveshah | Yes, just checked and it is fixed in SystemVerilog, a reg can be inside an always | 10:12 |
| sxpert | have a link ? | 10:12 |
| daveshah | https://stackoverflow.com/a/25859216/10520793 | 10:14 |
| tpb | Title: Can Verilog variables be given local scope to an always block? - Stack Overflow (at stackoverflow.com) | 10:14 |
| daveshah | Sorry https://stackoverflow.com/a/25873704/10520793 | 10:15 |
| daveshah | Yosys only supports this if the block is named | 10:16 |
| daveshah | ie you have :somename after begin | 10:17 |
| sxpert | I see | 10:17 |
| sxpert | come to think of it, it seems that there are a few combinations in the opcodes, so I could make a few wires ... | 10:17 |
| sxpert | and reuse them elsewhere | 10:18 |
| sxpert | should generate less logic overall, I guess | 10:18 |
| daveshah | Maybe, but many of these cases will be dealt with by opt_merge | 10:19 |
| sxpert | will make it nicer to read too ;) | 10:20 |
| *** AlexDaniel has joined #yosys | 10:33 | |
| *** tinyhippo has joined #yosys | 10:47 | |
| *** tinyhippo has left #yosys | 10:47 | |
| *** AnkurA has joined #yosys | 10:51 | |
| AnkurA | Hey all, not able to do synthesis with .plib provided by foundry | 10:51 |
| AnkurA | any idea if .plib cannot be used? | 10:51 |
| daveshah | Yosys supports Liberty libraries for ASIC synthesis, is that what a .plib is? | 10:52 |
| AnkurA | any other ways to do it if the foundry has not provided .lib liberty file? | 11:03 |
| AnkurA | .plib is some physical library file | 11:03 |
| AnkurA | excepth, various other files are provided like .db, .sef, .nldm, etc. | 11:05 |
| AnkurA | except .lib I meant | 11:05 |
| daveshah | Many of these files are proprietary | 11:10 |
| daveshah | It looks like the plib might be a heavily extended Liberty, in which case it might be possible to modify Yosys to skip over the bits it can't use | 11:11 |
| AnkurA | Found .lib in nldm folder | 11:15 |
| AnkurA | thanks. | 11:15 |
| *** AnkurA has left #yosys | 11:15 | |
| sxpert | daveshah: soon there will be an opensource library for opensource asics with opensource process, I understand | 12:25 |
| daveshah | LibreSilicon? | 12:26 |
| sxpert | yeah | 12:26 |
| sxpert | that looks pretty interesting | 12:26 |
| daveshah | other than the blockchain stuff | 12:26 |
| sxpert | what blockchain stuff ? | 12:27 |
| daveshah | > By using a blockchain solution in order to track the added value from the work of every contributor, without any human intervention required, it is ensured that everyone is being payed a fair price for the work and time she or he has invested into developing an ASIC or IP block. Manufacturing potential can be reported on a market place where customers can put up orders. The result will be something like a crypto exchange | 12:27 |
| daveshah | just without speculation, a way for people who want to buy chips and people with a basement containing a clean room to find each other. This becomes possible with our free semiconductor manufacturing process standard which allow reproducible results with varying setups. | 12:27 |
| sxpert | ah. | 12:27 |
| sxpert | not really interested by that part | 12:28 |
| sxpert | the silicon manufacturing bit is the important part here | 12:28 |
| sxpert | guess they needed "Blockchain" somewhere in the blurb to get financing | 12:28 |
| *** cr1901_modern has quit IRC | 12:38 | |
| *** rohitksingh_work has quit IRC | 12:47 | |
| corecode | lol blockchain | 12:58 |
| sxpert | it's one of those magic buzzwords to get money from know-nothing capitalists. can be considered as a nop | 13:33 |
| *** cr1901_modern has joined #yosys | 13:56 | |
| *** rohitksingh has joined #yosys | 13:59 | |
| cr1901_modern | daveshah: Do you have a moment to hear about our lord and savior blockchain? | 14:08 |
| *** jevinskie has joined #yosys | 14:13 | |
| somlo | "If you think blockchain is the solution to your problem, you don't understand blockchain. And, you don't understand the problem" | 14:18 |
| sxpert | so... | 14:52 |
| sxpert | I think I'm getting somewhere | 14:53 |
| sxpert | guess I should be splitting this ALU thing with the registers into a separate module | 14:53 |
| sxpert | will try that later | 14:54 |
| sxpert | feels like major surgery though | 14:56 |
| sxpert | daveshah: what does "Clock '$glbnet$ph1' has no interior paths" means ? | 15:15 |
| daveshah | That means there are no paths between two registers both clocked by ph1 | 15:17 |
| daveshah | Therefore a Fmax is not applicable | 15:17 |
| daveshah | however, max delays to/from other clock domains may be printed | 15:18 |
| sxpert | is that a problem ? | 15:19 |
| daveshah | Probably not | 15:20 |
| sxpert | ok | 15:21 |
| daveshah | Are you expecting all the registers clocked by ph1 to drive and be driven by registers in other domains? | 15:21 |
| sxpert | nope | 15:22 |
| sxpert | I'm actually trying to isolate things into their own domain | 15:22 |
| sxpert | one at a time | 15:22 |
| daveshah | That sounds dangerous | 15:22 |
| sxpert | hmm ? | 15:22 |
| daveshah | Good practice is to have as few clock domains as possible | 15:23 |
| daveshah | In many cases, everything except IO belongs in a single design | 15:23 |
| daveshah | *domain | 15:23 |
| sxpert | well, ph[0-3] are derived from a common clk | 15:24 |
| sxpert | with this : https://github.com/sxpert/hp-saturn/blob/master/saturn_core.v#L251 | 15:24 |
| tpb | Title: hp-saturn/saturn_core.v at master · sxpert/hp-saturn · GitHub (at github.com) | 15:24 |
| *** jevinskie has quit IRC | 15:25 | |
| daveshah | FPGA logic is not glitch free | 15:26 |
| daveshah | This could end up with double clocking issues | 15:26 |
| sxpert | ha | 15:27 |
| sxpert | how should I do that then ? ;) | 15:28 |
| daveshah | First of all you shouldn't | 15:29 |
| sxpert | well. duh | 15:30 |
| daveshah | If you really have to then a PLL is the only safe way to generate related clocks | 15:30 |
| sxpert | I see | 15:30 |
| daveshah | Registers will be better than combinational logic, but still far from ideal | 15:30 |
| sxpert | say I could use some form of counter ? | 15:30 |
| daveshah | Yes | 15:32 |
| sxpert | ok, works for me. | 15:32 |
| sxpert | will redo that part | 15:32 |
| sxpert | so, one clock, and a 2 bit counter for phase | 15:35 |
| sxpert | works for me | 15:38 |
| * ZipCPU takes a look at sxpert's saturn_core clocking logic | 15:46 | |
| ZipCPU | sxpert: +1 to everything daveshah said. Consider this post if you want further reading: http://zipcpu.com/blog/2017/06/02/generating-timing.html | 15:46 |
| tpb | Title: Controlling Timing within an FPGA (at zipcpu.com) | 15:46 |
| * sxpert obviously does all the beginner's mistakes ;-) | 15:49 | |
| sxpert | (that's part of learning, I guess) | 15:49 |
| ZipCPU | As long as its the fun part of learning, have at it! | 15:49 |
| sxpert | yeah | 15:51 |
| sxpert | having a blast | 15:51 |
| ZipCPU | You realize I'm only a couple of years ahead of you, right? ;) | 15:55 |
| sxpert | ZipCPU: so I need to pass clk and counter to the modules IIUC | 15:55 |
| sxpert | ZipCPU: good enough, I'm a couple years behind ;) | 15:55 |
| ZipCPU | I would instead pass a clock and an enable line, with four enable lines--one per phase | 15:55 |
| sxpert | ah | 15:56 |
| ZipCPU | That'll reduce the amount of logic required to use the phase | 15:56 |
| ZipCPU | ... and, if you are on an iCE40, you'll need all the reductions you can get | 15:56 |
| sxpert | so, generate those enable on neg-edge | 15:56 |
| sxpert | and use then on posedge ? | 15:57 |
| sxpert | (which allows the enable to be stable when posedge comes up | 15:58 |
| ZipCPU | No. Do everything on the positive edge | 15:58 |
| sxpert | ah | 15:58 |
| ZipCPU | Most toolchains can't handle both edges of the clock | 15:59 |
| ZipCPU | Part of the problem being that few clocks are sufficiently reliable on both edges too | 15:59 |
| sxpert | this is what I understand will happen : https://github.com/sxpert/hp-saturn/blob/master/README | 16:06 |
| tpb | Title: hp-saturn/README at master · sxpert/hp-saturn · GitHub (at github.com) | 16:06 |
| ZipCPU | Looks good | 16:06 |
| sxpert | however, on posedge, the phase will not be stable | 16:07 |
| sxpert | or is the logic happening before the clock edge ? | 16:08 |
| sxpert | ZipCPU: link above is most enlightening | 16:18 |
| ZipCPU | You mean the one I wrote? | 16:18 |
| sxpert | yeah | 16:18 |
| ZipCPU | Thanks! | 16:18 |
| sxpert | still, I'm puzzled by how this all works | 16:19 |
| ZipCPU | How so? | 16:19 |
| sxpert | all the logic described in the "always @(posedge clk)" block, is combinatorial logic and the clk controls all the touched flip-flops ? | 16:20 |
| ZipCPU | I'm not sure I follow yet | 16:20 |
| sxpert | I mean, that's how the fpga works inside ? | 16:20 |
| ZipCPU | Internal to an FPGA are LUTs, FFs, and wires to connect them all | 16:21 |
| ZipCPU | Many FPGAs group the LUTs and FFs together into logic blocks | 16:21 |
| sxpert | so what's inside the block is a bunch of luts, and the ff store whatever the luts have generated on the clk (up or down) signal | 16:22 |
| ZipCPU | The LUTs are your combinatorial logic, and are (often) immediately followed by FFs. The FF in the logic block can be bypassed, though, if you aren't interesteed in using it | 16:22 |
| ZipCPU | Yeah, something like that | 16:22 |
| sxpert | ok | 16:22 |
| ZipCPU | In addition, most FPGAs have some low-latency networks for clocks to help reduce clock skew from one part of the chip to another | 16:22 |
| ZipCPU | These low-latency networks, which are limited in number, tend to be fed to every logic block | 16:23 |
| sxpert | yeah, I had that part in the brain ;) | 16:23 |
| ZipCPU | The other part of the FF thing is that many FFs have CEs built into them | 16:23 |
| ZipCPU | Hence, your phase signals (once created) should be able to use the global routing networks, and then no additional logic at the FF | 16:23 |
| sxpert | I see | 16:23 |
| ZipCPU | Unless Yosys adds some more combinational logic, such as the FF only changes if A & B are true | 16:24 |
| sxpert | said phase signals should be "wire blah; assign blah = <something>;" ? | 16:24 |
| sxpert | the something being a function of counter | 16:25 |
| sxpert | ? | 16:25 |
| ZipCPU | Well, you could say: wire [3:0] phase_ce; assign phase_ce[0] = counter[1:0] == 2'b00; | 16:25 |
| ZipCPU | Did you see my explanation of timing in terms of stalagtites and stalagmites | 16:26 |
| ZipCPU | It was on pages 10-13 of the tutorial lesson on debouncing (lesson 7) ... see http://zipcpu.com/tutorial | 16:27 |
| tpb | Title: Verilog Beginner's Tutorial (at zipcpu.com) | 16:27 |
| ZipCPU | If you use wire [3:0] phase_ce; assign phase_ce[0] = (counter[1:0] == 2'b00); your starting your design out in timing debt, and won't be able to do as much on the clock | 16:27 |
| ZipCPU | On the other hand, if you use: reg [3:0] phase_ce; always @(posedge i_clk) phase_ce[0] <= (counter[1:0] == 2'b00); your phase will be delayed by one clock tick (probably irrelevant) but you'll have more time to get things done based upon that value within your design | 16:28 |
| sxpert | ah. I see | 16:28 |
| sxpert | as long as the thing starts with phase_0 on reset | 16:29 |
| ZipCPU | That should be easy to verify | 16:29 |
| sxpert | yeah | 16:29 |
| sxpert | another Q I had was, is a monster case statement bad for timing ? | 16:30 |
| ZipCPU | It can be | 16:30 |
| ZipCPU | It isn't necessarily so though | 16:30 |
| sxpert | any known red-flags ? | 16:31 |
| ZipCPU | You mean with the monster case statement? | 16:31 |
| sxpert | yeah | 16:31 |
| ZipCPU | Some designs/designers use them often. I don't. Here's why ... | 16:31 |
| ZipCPU | The larger the case statement is, or the nested if, whatever, the more logic is required to compute every value | 16:31 |
| ZipCPU | My own design philosophy has always been about minimizing my logic usage count--hence the ZipCPU | 16:32 |
| ZipCPU | That usually forces me to move every register's definition/assignment into its own always block | 16:32 |
| ZipCPU | Have you seen my article on minimizing logic utilization? | 16:33 |
| sxpert | yeah, but guess I'll have to read again | 16:33 |
| ZipCPU | A lot of what I do is optimizing logic for those time periods where I don't care what a particular value is | 16:34 |
| ZipCPU | Another big part of what I do is to work very hard to minimize the logic used when that logic needs to be applied to lots of values | 16:35 |
| ZipCPU | For example, if (A) WORD <= I1 + I2; else if (B) WORD <= I1 ^ I2; else if ... | 16:36 |
| ZipCPU | Sometimes you can't get around it, like when building an ALU, but sometimes you can | 16:36 |
| sxpert | well, the ALU I built works in multiple phases, minimizing the work in each phase | 16:40 |
| sxpert | ph1: get the data, ph2: do calculation, ph3: write back | 16:41 |
| ZipCPU | What if the calculation takes longer? Such as a multiply or a divide? | 16:41 |
| sxpert | ph0 being request data from memory | 16:41 |
| sxpert | there's no such instruction ;) | 16:41 |
| ZipCPU | Are you only ever using block RAM? Never any flash memory? | 16:42 |
| sxpert | not at this time | 16:42 |
| sxpert | I was thinking of plugging some form of cache though, that would stall the processor while it accesses said flash on PC changes | 16:43 |
| sxpert | as I understand, flash works in a streaming fashion, as long as you request the next value | 16:44 |
| ZipCPU | You are working on an ECP5, right? I could never get the cache to fit on an iCE40 | 16:44 |
| sxpert | yeah | 16:44 |
| sxpert | the original processor was 4Mhz... | 16:44 |
| sxpert | ZipCPU: how much cache were you trying to have ? | 16:45 |
| ZipCPU | I stripped it bare, down to two cache lines of 8 items each--still too much logic | 16:46 |
| sxpert | how big was that ice40 ? | 16:47 |
| ZipCPU | 8k | 16:47 |
| ZipCPU | hx | 16:47 |
| sxpert | hmm | 16:48 |
| *** leviathanch has quit IRC | 16:51 | |
| sxpert | so that's 8k luts ? | 16:53 |
| ZipCPU | 7680 if I recall, but roughly 8k, yes | 16:54 |
| ZipCPU | They're 4-LUTs too, as opposed to the Xilinx 8-LUTs | 16:54 |
| sxpert | not much indeed | 16:54 |
| ZipCPU | (I'm not sure how big the LUTs are on the ECP5) | 16:54 |
| sxpert | I can see how that gets filled up pretty fast | 16:55 |
| daveshah | LUT4s, but with cascade muxes to combine to build larger LUTs | 16:55 |
| daveshah | Xilinx is LUT6 btw | 16:55 |
| ZipCPU | Thanks, daveshah! | 16:55 |
| daveshah | but also has muxes to build larger LUTs like ECP5 | 16:55 |
| ZipCPU | Oohh, thanks, Looks like I mistyped that as 8-LUTs for the Xilinx chips, my bad | 16:55 |
| *** maikmerten has joined #yosys | 16:57 | |
| sxpert | ZipCPU: 1 slice is 2 LUT4 and 2 FF | 16:57 |
| ZipCPU | daveshah would know that better than I. Are you asking regarding iCE40 or ECP5? | 16:58 |
| daveshah | sxpert: yes | 16:58 |
| sxpert | reading from the datasheet | 16:58 |
| sxpert | those lut4 have carry in and out too | 16:58 |
| daveshah | Yes, there's some carry logic in there | 16:59 |
| sxpert | doesn't say how many outputs those luts have though | 17:00 |
| daveshah | one | 17:01 |
| sxpert | ok | 17:01 |
| daveshah | in carry mode it's a bit more complicated | 17:01 |
| sxpert | so that's a 1 bit adder or something | 17:01 |
| daveshah | no | 17:01 |
| daveshah | https://usercontent.irccloud-cdn.com/file/9BqG6cW6/ecp5_carry_split.png | 17:03 |
| daveshah | it can be drawn like this in most cases | 17:03 |
| daveshah | effectively the LUT2 is the bottom half of the LUT4 | 17:03 |
| daveshah | although they can have separate init values if you treat the top part as a LUT3 and tie the D input to 1 | 17:03 |
| sxpert | so that uses 2 luts ? | 17:05 |
| daveshah | no, those are both parts of the LUT4 | 17:05 |
| sxpert | ah ok | 17:06 |
| sxpert | the lut4 is thus built with 2 lut3 internally ? | 17:08 |
| daveshah | No | 17:08 |
| daveshah | It's really a LUT4 with the output from the bottom LUT2 broken out | 17:09 |
| sxpert | hmm | 17:09 |
| daveshah | but in almost all cases the remainder is used as a LUT3 | 17:09 |
| daveshah | in the carry situation | 17:09 |
| * sxpert wonders how there's 2 outputs ;-) | 17:10 | |
| daveshah | all a LUT is is a cascade of multiplexers | 17:10 |
| daveshah | selecting one of 2^K config bits | 17:10 |
| daveshah | to get the second "LUT2" output, you just need to tap off from the middle | 17:10 |
| daveshah | however, this second output is only used as part of the carry logic, it's not generally usable | 17:11 |
| sxpert | ah, I thought it was some sort of 2^K bits ram | 17:11 |
| daveshah | it is | 17:11 |
| daveshah | indeed, 4 out of the 8 LUTs in a tile are usable as ram as well as rom | 17:11 |
| sxpert | I was thinking of the config bits here | 17:12 |
| *** seldridge has joined #yosys | 17:12 | |
| sxpert | say you have a 4-16 mux selecting which of the 16 config bits come out the output | 17:13 |
| daveshah | yeah | 17:14 |
| sxpert | and then next to that, you have a ff that you can clock whatever comes out into | 17:14 |
| daveshah | yeah | 17:15 |
| daveshah | for LUTs not usable as distributed RAM, it will be probably be a simple shift register | 17:15 |
| sxpert | the part I don't get is how you get a 2nd input as the cout (the c-in is just one of the 4 input bits) | 17:15 |
| sxpert | perhaps you have a second 3-8 mux selecting one of bits [8-15] | 17:16 |
| daveshah | the mux connecting cin/cout isn't one of those muxes, that's an extra carry mux | 17:16 |
| daveshah | https://usercontent.irccloud-cdn.com/file/iTtnPsuv/LUT2_LUT4.png | 17:19 |
| daveshah | see this badly edited stolen diagram | 17:19 |
| sxpert | oh, I see... this is much more clear | 17:20 |
| sxpert | imho, would have been smarter to have the possibility of splitting into 2 lut3 | 17:20 |
| daveshah | yeah, but then you hit routing fabric constraints | 17:21 |
| sxpert | is there a doc from lattice with this sort of info ? or does this comes from somewhere else ? | 17:21 |
| daveshah | it came from careful analysis of their simulation models (see $DIAMOND/cae_library/simulation/verilog/ecp5y) | 17:22 |
| daveshah | * $DIAMOND/cae_library/simulation/verilog/ecp5u | 17:22 |
| sxpert | ah, bloody RPM ;) | 17:24 |
| sxpert | ah, and one needs an account... | 17:24 |
| daveshah | Feel free to peruse the rewritten FOSS alternatives | 17:25 |
| daveshah | https://github.com/YosysHQ/yosys/blob/master/techlibs/ecp5/cells_sim.v#L19-L49 | 17:25 |
| tpb | Title: yosys/cells_sim.v at master · YosysHQ/yosys · GitHub (at github.com) | 17:25 |
| daveshah | is the model for the CCU2C carry primitive | 17:25 |
| * sxpert bookmarks | 17:27 | |
| *** emeb has joined #yosys | 17:35 | |
| emeb | Trying to run a design thru nextpnr-ice40 and it fails with "ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc." | 17:46 |
| daveshah | emeb: could it be an inferred latch? try grepping the Yosys output for dlatch | 17:47 |
| emeb | daveshah: thx - will look. | 17:48 |
| *** oldtopman has joined #yosys | 17:58 | |
| emeb | daveshah: found a few latches inferred in yosys - easily fixed w/ fully specified case. That did not eliminate the ERROR though. | 17:59 |
| daveshah | Is it possible there are other forms of combinational loop in there? | 18:01 |
| daveshah | If you just want to get rid of the error, run nextpnr with --ignore-loops | 18:01 |
| *** m4ssi has quit IRC | 18:02 | |
| emeb | daveshah: it's possible - I'm using a 6502 IP core of unknown quality. | 18:03 |
| daveshah | In that case --ignore-loops is your best bet | 18:05 |
| emeb | Yes - thanks. that seems to let it run further, exposing some other interesting things to chase. | 18:07 |
| *** rohitksingh has quit IRC | 18:27 | |
| sxpert | ZipCPU: does this look good ? https://github.com/sxpert/hp-saturn/blob/master/saturn_core.v#L242 ? | 18:33 |
| tpb | Title: hp-saturn/saturn_core.v at master · sxpert/hp-saturn · GitHub (at github.com) | 18:33 |
| ZipCPU | sxpert: Not yet | 18:38 |
| ZipCPU | What do you intend to do on a reset? | 18:38 |
| ZipCPU | You've only covered one half of the reset case | 18:38 |
| emeb | daveshah: also - thanks for the link to the SB_ lib yesterday. just read the chl log and spotted that. | 18:46 |
| emeb | which raises another question - is yosys able to infer the SB_SPRAM256KA ? | 18:47 |
| daveshah | No, it isn't | 18:47 |
| daveshah | atm Yosys doesn't support shared read/write ports of any kind | 18:47 |
| sxpert | ZipCPU: how would I go for that reset thing ? | 18:47 |
| daveshah | this also means it can't infer Xilinx/ECP5 true dual port RAM, only pseudo dual port (1R1W) | 18:47 |
| sxpert | ZipCPU: for now I expected to use the initial block, but that may not be the best solution | 18:48 |
| ZipCPU | sxpert: You want a structure such as: initial A <= 1'b0; always @(posedge i_clk) if (i_reset) A<= 1'b0; else A <= !A; | 18:48 |
| emeb | daveshah: OK, that makes sense. I was having trouble with inference so I just instantiated. | 18:48 |
| sxpert | ZipCPU: so as to debounce the reset ? | 18:49 |
| sxpert | or to buffer it somehow ? | 18:49 |
| ZipCPU | No | 18:49 |
| emeb | daveshah: and I was able to get my whacky 6502 thing to build - found a loop, broke it, now everyone is happy. | 18:49 |
| daveshah | :) | 18:49 |
| ZipCPU | To set your values both on a reset as well as following the reset | 18:49 |
| emeb | pro-tip - yosys does check for loops and warn about them. TIL. :P | 18:50 |
| sxpert | ZipCPU: what would A be used for ? | 18:51 |
| sxpert | initial does only apply on fpga bootup... | 18:51 |
| sxpert | I see | 18:51 |
| ZipCPU | I'm using A to avoid retyping all 9 of your assignments | 18:51 |
| sxpert | yeah right | 18:51 |
| sxpert | why !A though ? | 18:53 |
| ZipCPU | To avoid saying: clk_phase <= clk_phase + 1; | 18:53 |
| sxpert | should ah | 18:53 |
| ZipCPU | I was just trying to share the form of the solution | 18:53 |
| sxpert | and reset all other signals to 0 | 18:53 |
| sxpert | I guess | 18:53 |
| ZipCPU | Well ... that's not quite a given | 18:54 |
| ZipCPU | The issue is that you want all of the en_* signals set to zero during the reset, and you then want en_bus_send set on the first clock after the reset | 18:55 |
| ZipCPU | (That was your requirement, not mine) | 18:55 |
| sxpert | ah right | 18:55 |
| sxpert | guess I can lose a step | 18:56 |
| sxpert | not a biggie | 18:56 |
| sxpert | so all to 0 would work | 18:56 |
| sxpert | ok, I have created a delayed reset enable too | 19:09 |
| sxpert | ZipCPU: yay, seems to work ;) | 19:23 |
| sxpert | now, I need to figure out the rest ;) | 19:23 |
| ZipCPU | o/ | 19:23 |
| sxpert | there, removed all the old stuff (stored in a safe place) | 19:34 |
| sxpert | ZipCPU: the "generate if(blah)" is for optional stuff that may not get compiled in ? | 19:42 |
| ZipCPU | I use it for that purpose, yes | 19:42 |
| ZipCPU | blah must be a 1'bit parameter to make it work | 19:42 |
| sxpert | ok, won't need that ;) | 19:43 |
| ZipCPU | I suppose you could make it a localparam too ... | 19:44 |
| sxpert | or some `define | 19:47 |
| ZipCPU | I've had problems using `define's over the years | 19:49 |
| ZipCPU | I've used them on many projects | 19:50 |
| sxpert | ah | 19:50 |
| ZipCPU | The result usually ends up with something that's less capable, since it's harder to handle `define's in these projects | 19:50 |
| sxpert | I see | 19:58 |
| *** dys has joined #yosys | 20:12 | |
| sxpert | ZipCPU: here's what I came with, https://github.com/sxpert/hp-saturn/blob/master/saturn-decoder.v | 20:43 |
| tpb | Title: hp-saturn/saturn-decoder.v at master · sxpert/hp-saturn · GitHub (at github.com) | 20:43 |
| ZipCPU | sxpert: What am I looking at? | 20:46 |
| sxpert | well, trying to apply whatever I learned tonight, dunno if I did well | 20:48 |
| sxpert | on i_en_dec, it receives 0, then 0, ends up setting the ins_rtnsxm reg to 1 | 20:50 |
| sxpert | one of the questions I had was respective to mucking with continue on line 59 and 78 | 20:51 |
| ZipCPU | Still not following what I'm looking at. Does it do what you want it to? | 20:53 |
| sxpert | simulation says so | 20:53 |
| sxpert | I'm just trying to ascertain that it's synthesizable | 20:53 |
| sxpert | and proper ;) | 20:56 |
| sxpert | (before I start coding the rest of the decoder in the same fashion | 20:56 |
| *** X-Scale has quit IRC | 21:08 | |
| ZipCPU | It's not synthesizable | 21:17 |
| ZipCPU | Neither $display nor $monitor can be synthesized ;) | 21:18 |
| sxpert | sure | 21:18 |
| *** X-Scale has joined #yosys | 21:19 | |
| *** dys has quit IRC | 21:24 | |
| sxpert | ok, not doing what I want, YET | 21:30 |
| ZipCPU | You know .... it's a whole lot easier to get that sort of thing working with formal methods than with simulation ... just sayin' | 21:30 |
| * sxpert wonders wth are those formal methods | 21:31 | |
| *** dys has joined #yosys | 21:33 | |
| * sxpert got it to work ! | 21:35 | |
| sxpert | \o/ | 21:35 |
| chaseemory | TIL you can concat wires with an enum in a case block | 21:48 |
| sxpert | hmm ? | 21:49 |
| chaseemory | id been curious for a while if it would work, i wrote this | 21:50 |
| chaseemory | casex( {current, send_i, hdr_ready_i, payload_axis_tready_i} ) | 21:50 |
| sxpert | yeah, seems to work | 21:50 |
| sxpert | generates some bitstring you can compare against | 21:50 |
| chaseemory | where current is an enum, and the rest are wires, and just concatted them together for each case as well | 21:50 |
| sxpert | suppose it allows for testing all cases of the enum ? | 21:51 |
| chaseemory | could even test the same cases of the enum with different combinations of the wires as well, its being used in my next state logic block | 21:54 |
| *** maikmerten has quit IRC | 22:00 | |
| sxpert | good luck with that ;) | 22:04 |
| chaseemory | hehe I like trying to new things to see how they work :D | 22:18 |
| sxpert | yeah | 22:33 |
| sxpert | sometimes, they fail spectacularly for no reason | 22:34 |
| chaseemory | dont I know it, now that Ive gotten into ASIC toolchains in school vs just FPGA ones till now, they can go belly up quick and in strange ways | 23:19 |
| *** corecode_ has joined #yosys | 23:46 | |
| *** Kamilion|ZNC has joined #yosys | 23:47 | |
| *** Thorn has quit IRC | 23:50 | |
| *** ric96 has quit IRC | 23:53 | |
| *** corecode has quit IRC | 23:53 | |
| *** bluesceada has quit IRC | 23:53 | |
| *** daveshah has quit IRC | 23:53 | |
| *** Kamilion has quit IRC | 23:53 | |
| *** sorear has quit IRC | 23:53 | |
| *** ovf has quit IRC | 23:53 | |
| *** zkms has quit IRC | 23:53 | |
| *** _florent_ has quit IRC | 23:53 | |
| *** adamgreig has quit IRC | 23:53 | |
| *** mrsteveman1 has quit IRC | 23:53 | |
| *** bluesceada has joined #yosys | 23:53 | |
| *** Kamilion|ZNC is now known as Kamilion | 23:55 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
