clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
<adamgreig> I have an ice40 hx8k design using a pll with a clock into GBIN0 (on the same cell as the X16/Y33 PLL); arachne places fine but nextpnr errors saying the PACKAGEPIN for the SB_PLL40_PAD must be GBIN5 (X16/Y0, the cell with the other PLL)
<adamgreig> I'm guessing it's picked the other PLL and then complained that the pad input is not in that cell, but I'm not really sure
<adamgreig> any ideas?
<cr1901_modern> adamgreig: You may wish to talk to tnt in ##openfpga. He's been tweaking PLL stuff lately
<adamgreig> thanks, I'll try him
emeb has quit [Quit: Leaving.]
leviathanch has joined #yosys
rohitksingh has joined #yosys
zkms has quit [Quit: WeeChat 2.2]
zkms has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
maikmerten has joined #yosys
_whitelogger has joined #yosys
dys has quit [Ping timeout: 240 seconds]
rohitksingh has joined #yosys
dys has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #yosys
dys has quit [Ping timeout: 268 seconds]
maikmerten has quit [Remote host closed the connection]
dys has joined #yosys
rohitksingh has quit [Ping timeout: 250 seconds]
dys has quit [Ping timeout: 272 seconds]
dys has joined #yosys
leviathanch has quit [Read error: Connection reset by peer]
ZipCPU has quit [Ping timeout: 260 seconds]
rohitksingh has joined #yosys
ZipCPU has joined #yosys
tnt has joined #yosys
<tnt> I'm a bit confused. I have `define MAX(_a, _b) ((_a) > (_b) ? (_a) : (_b)) and $display(" %d", `MAX(0, $clog2(1 << 17) - 18));
<tnt> and this displays -1 ... I would expect 0 (and that's what I get with iverilog)
leviathanch has joined #yosys
<ZipCPU> tnt: That might depend upon the type of _a and _b. Are they both signed, or not?
<ZipCPU> If I re-interpret -1 as an unsigned value, it will always be the maximum value
<tnt> well, one argument is 0 exactly and the other is $clog2 which I'd expect to be signed.
<ZipCPU> ... and to how many bits is the result applied?
<tnt> it's used as the width of something.
<tnt> localparam XXX = MAX(0, $clog2(1 << 17) - 18); and XXX will be -1.
<tnt> sorry, localparam integer XXX = ...
<ZipCPU> Do you have a 5-10 line example somewhere that I could test?
<tpb> Title: module test; `define MAX(_a, _b) ((_a) > (_b) ? (_a) : (_b)) localparam intege - Pastebin.com (at pastebin.com)
<ZipCPU> So is your problem iverilog or yosys?
<tnt> yosys
<tnt> I mean, MAX(0,-1) should return 0 ...
<ZipCPU> Not if there's a type conflict between signed and unsigned ... but let me test this out
<tnt> AFAIU contants like '0' or '18' should be 'integer' in verilog by default. $clog2 is also supposed to return an integer according to the spec I have. So everything in that expression is of type 'integer' which is a signed type.
<ZipCPU> I see what's going on
<ZipCPU> I'm using yosys for my test
<ZipCPU> yosys has an assertion failure reading this code ...
<ZipCPU> Verilator has a problem with this code too
<tnt> What's wrong with it ? Seemed perfectly valid to me ?
<ZipCPU> It may be that I modified it slightly to create a wire of width [X-1:0]
<ZipCPU> If 'X' is 0, the wire has zero width
<ZipCPU> Let me adjust it for a width of [X:0] ... that should help this example along
<sorear> I thought it created a little endian wire of width 2
<tnt> yeah the -1:0 thing is how I noticed th eproblem ... because yosys would throw a warning about reverse part order and truncate the signal and strip out all my logic ... and I narrowed it to that constant being miscomputed.
kraiskil__ has joined #yosys
<ZipCPU> I wonder if removing the macro would change anything
<ZipCPU> ...
<tnt> not really
<tnt> initial $display("%d", ($clog2(1 << 17) - 18) > 0 ? 1 : 0);
<ZipCPU> If not, then that eliminates one possible part of the problem. (Testing now)
<tnt> this displays 1 ... so -1 > 0
<ZipCPU> What's the type of $clog(X)? That'd be a good question ...
* ZipCPU looks up the SV spec
<tnt> The way I understand 17.11.1 of http://staff.ustc.edu.cn/~songch/download/IEEE.1364-2005.pdf it should be 'integer'
<ZipCPU> Ok, so the argument is always treated as unsigned. That doesn't tell me much of the result
<ZipCPU> Yes, integer is what I've got here too
* ZipCPU greps through yosys code to find the $clog2 implementation
<ZipCPU> Looks to be in frontends/ast/simplify.cc ...
<tnt> and is_signed is set to false.
<ZipCPU> Yosys creates an integer with it ...
<ZipCPU> Let's stuff a printf in there and see what integer comes back from $clog2 ...
<tnt> mkconst_int(uint32_t v, bool is_signed, int width)
<tnt> if you take the result of clog2 and put it in an integer, then use it ... it works.
<ZipCPU> Really? Ok ... (still digging)
<ZipCPU> What result are you using for $clog2?
<tnt> What do you mean ?
<ZipCPU> You are using 17 for the result of $clog2(1<<17), right?
<ZipCPU> (Seems obvious I know ...)
<ZipCPU> Having now instrumented simplify.cc to look at what yosys is doing internally ... I'm now more confused than I was before.
<ZipCPU> Ahh ... that's why ... it's subtracting one from the argument ... so it's working on (1<<17)-1
<ZipCPU> That still doesn't make any sense
<ZipCPU> Counting 1's bits would only work for values of the form (1<<x)-1
<tpb> Title: [Diff] diff --git a/frontends/ast/simplify.cc b/frontends/ast/simplify.cc index bb4c97 - Pastebin.com (at pastebin.com)
<tnt> this makes it works as I'd expect.
* ZipCPU searches on the definition of mkconst_int
<ZipCPU> But ... $clog2 *should* be an unsigned value
<ZipCPU> It's like ssize_t ... there's no way it can be negative
<ZipCPU> Subtracting 18 from 17u should result in -1, but in an unsigned context ... -1 is the largest possible value
<tnt> There is no way it can be negative, but it should still be a 'integer' signed type as far as verilog is concerned.
<ZipCPU> Yeah, okay ... I see that in the spec
<ZipCPU> Thanks for bringing that back to my attention
<ZipCPU> Can I convince you to create a pull request with this information in it?
<ZipCPU> ... and an issue documenting that pull request?
<tnt> Sure
<ZipCPU> I'll have a chance in a couple of days to make sure it gets the attention it needs.
<tnt> If you can comment on https://github.com/YosysHQ/yosys/issues/700 and associated PR at the same time :P
<tpb> Title: Feature request: Finer grained control on Clock Enable usage · Issue #700 · YosysHQ/yosys · GitHub (at github.com)
<ZipCPU> Is that your PR as well?
<tnt> yes
<daveshah> I understand Clifford is about to travel to the US. So there might be a little delay on this stuff right now
<ZipCPU> daveshah: what path forward do you recommend? Can you accept pull requests? This one is pretty simple
<daveshah> No, I don't have permission for that
<ZipCPU> Ok, we'll just hold on to these for Clifford then
<tnt> #700 might be a bit 'unrefined' option, but at least so far I've had a good experience with it. I think pretty much all the designed I used this with ended up smaller and faster.
<daveshah> tnt: without min_ce_use: 8 runs of picorv32 `min = 53.88 MHz, avg = 56.57125 MHz, max = 60.05 MHz`
<daveshah> with min_ce_use=4: 8 runs of picorv32 `icetime: min = 57.28 MHz, avg = 61.33375 MHz, max = 64.6 MHz`
<daveshah> with min_ce_use=8: 8 runs of picorv32 `icetime: min = 57.14 MHz, avg = 62.78874999999999 MHz, max = 67.06 MHz`
<daveshah> LGTM!
<daveshah> 11% improvement is very nice
<zkms> nice!
<tnt> daveshah: nice :)
Forty-Bot has quit []
Forty-Bot has joined #yosys
Forty-Bot has quit [Client Quit]
kraiskil__ has quit [Ping timeout: 268 seconds]
leviathanch has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 240 seconds]
AlexDaniel has joined #yosys
kraiskil__ has joined #yosys
kc5tja has joined #yosys
<kc5tja> ZipCPU: yt by any chance?
<ZipCPU> What's up?
* ZipCPU is working on another tutorial lesson
<ZipCPU> Stuck on anything?
<kc5tja> Apologies for disappearing for months; but I'm running into an issue with Verilator where it cannot find verilated.h.
<kc5tja> My goal is to write an integration test for the SIA core using Verilator.
<ZipCPU> Do you have verilated.h in your distribution?
<kc5tja> Yes.
<kc5tja> Let me be more precise.
<ZipCPU> Ok, so this is just a gcc issue. Go on.
<kc5tja> It's in the Verilator package.
<kc5tja> I'm not finding it in the obj_dir directory, though.
<ZipCPU> Oh, dear. But yet you can run it, right?
<kc5tja> I can run other Verilator tests OK.
<ZipCPU> Yes, you've been doing very nicely with it from what I saw last
<ZipCPU> Go on
<ZipCPU> Are you using the -exe flag? (I don't normally do so, but it might affect this)
<tpb> Title: Kestrel-3: Artifact Content (at chiselapp.com)
<kc5tja> That's my Makefile. It's basically where you and I left off last time.
<kc5tja> This appears to work for you, but for me, I just can't get it to locate verilated.h. Any ideas?
<ZipCPU> Yes
<ZipCPU> I've had this problem (I think) once or twice when using -exe. I don't normally use -exe, so I don't have it that often.
<ZipCPU> Does it create an obj_dir directory?
<kc5tja> It does.
<kc5tja> Actually, let me double check.
<kc5tja> Like I said, been 2 months since I last did this. ;-)
<ZipCPU> Is there a reason why your "make -j ..." command doesn't include a number of processors? (Let me check if this is even legal ...)
<kc5tja> LOL...OK, egg on my face.
<ZipCPU> Ok, -j with no argument is legal
<kc5tja> I typed "rm -rf obj_dir; make verilator_test" and it not only succeeded to compile, but now it ran.
<ZipCPU> o/
<ZipCPU> Glad I could help you!
<kc5tja> Rubber ducking for the win, I guess.
<ZipCPU> Wow, that was one of the easier questions I've managed to help some one with. Got any harder ones? (Those are more fun)
<ZipCPU> ;)
* ZipCPU needs rubber ducks from time to time too
<ZipCPU> I remember a bug I was struggling with where I was *convinced* yosys was _BROKEN_!
<qu1j0t3> heh
<ZipCPU> I had an assertion that if (A) then (B) must be true on the next clock. I could cover(A), but never cover(B)
<ZipCPU> The assertion passed, cover(B) did not
<ZipCPU> It took some time, but I finally managed to corner clifford and get him to look at my code.
<ZipCPU> He found the line that essentially said: assume(!B);, and suggested that the error message needed to be more comprehensible
<ZipCPU> Same sort of thing. I was quite frustrated with myself for not handling my own work, but ... sometimes we all need another pair of eyes.
<daveshah> I've had some fun bugs like that
<kc5tja> Now I have to make sense of the VCD output. Heh.
<ZipCPU> I just hate bringing others in to stare at my ... bad designs
<daveshah> Spent two days debugging the first stage bootloader DDR3 init of an Allwinner A64 processor
<daveshah> Turned out I'd put a 240kohm resistor instead of 240 ohm for the memory's Zq calibration resistor
<ZipCPU> Ouch!
<daveshah> It's not as bad as when my SDR project worked fine with some standalone software but failed to calibrate when part of gnuradio
<ZipCPU> Go on
<daveshah> Basically, both the AD9361 and something within gnuradio defined a function with the same name and a similar purpose, to do with the position of the first one bit in a word iirc
<daveshah> But the way the defined it differed by one
<ZipCPU> Doh! That one would've been a pain to find! I'd never look there
<daveshah> The dynamic linker chose the gnuradio one which subtetlty broke the AD9361 init code
<daveshah> I only found it by dumping the SPI data sent and received over USB to a file and comparing it in both cases
<daveshah> Eventually I found the specific command that was failing
<daveshah> And traced this back to where it was implemented
<ZipCPU> I would've groaned pretty hard on finding something like that
<ZipCPU> That would've also probably ended my work day
<kc5tja> This is one of the reasons why I'm not a terribly big fan of dynamic linking as it's implemented on Windows or Posix environments. But, I'm an old man screaming at clouds. ;)
<kc5tja> OOH, I totally forgot that your code pulses the clock and nothing happens right on an edge.
<kc5tja> That will take me some getting used to.
<ZipCPU> Trust me ... it'll save you from some other bugs ... ;)
<ZipCPU> That said, I'd love to hear an alternative
<kc5tja> I'm very used to looking at the VCDs that yosys generates where things happen on edges.
<kc5tja> (It's also how I typically did my unit tests in the past, since it was less code)
<ZipCPU> I'd love to have things happen on edges
<ZipCPU> I wish I could
<kc5tja> I'm not saying it's wrong; it's different from what I'm used to by many years. Going to take some mental adjustment on my part.
<ZipCPU> It took me some adjustment as well ... after a lot of frustrating debugging with Verilator
<kc5tja> Everything will work great until it doesn't. ;)
<ZipCPU> Yes. So IMHO, the design process is all about mitigating the pain when things don't work
srk has quit [Ping timeout: 245 seconds]
srk has joined #yosys
kraiskil__ has quit [Ping timeout: 240 seconds]
seldridge has joined #yosys
tpb has quit [Remote host closed the connection]