danieljabailey has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
wavedrom has quit [Ping timeout: 244 seconds]
develonepi3 has joined #yosys
emeb has left #yosys [#yosys]
xerpi has quit [Remote host closed the connection]
pie__ has quit [Ping timeout: 252 seconds]
emeb_mac has joined #yosys
pie_ has joined #yosys
citypw has joined #yosys
danieljabailey has joined #yosys
lutsabound has quit [Quit: Connection closed for inactivity]
TD-Linux has quit [Ping timeout: 250 seconds]
TD-Linux has joined #yosys
pie__ has joined #yosys
pie_ has quit [Remote host closed the connection]
rohitksingh_work has joined #yosys
leviathanch has joined #yosys
emeb_mac has quit [Quit: Leaving.]
kc5tja has quit [Ping timeout: 250 seconds]
kraiskil_ has joined #yosys
wavedrom has joined #yosys
wavedrom has quit [Ping timeout: 250 seconds]
pie__ has quit [Remote host closed the connection]
pie__ has joined #yosys
dys has quit [Ping timeout: 272 seconds]
m4ssi has joined #yosys
xerpi has joined #yosys
sigwinch_ has joined #yosys
<sigwinch_>
Good morning, #yosys!
<daveshah>
Morning sigwinch_!
<sigwinch_>
I was asking myself how to properly have a counter have the correct width, based on the number of cycles I want to count, and especially to get rid of a warning when I compare against "number of cycles minus one". Here's what I came up with, and I wanted to ask if that's the proper way or hopelessly ugly:
<daveshah>
So personally I'd never worry about such a warning
<daveshah>
I think an alternative way might be to do (NCYCLES-1)[CYCLE_CTR_BITS-1:0]
<sigwinch_>
Ah, good idea, never thought of that (bit-indexing a integer literal).
<swetland>
I believe you need $clog2(N+1) if N could be an exact power of two
<swetland>
daveshah: I like the warning in general as it catches assignments of mismatch net-sizes to each other, but it does get entertaining when params/constants are involved
<swetland>
as I am reminded elsewhere, don't need the +1 on the clog2 if N-1 is the max value in use
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
citypw has quit [Ping timeout: 258 seconds]
<sigwinch_>
daveshah: verilator doesn't like (123)[NBITS-1:0] ...
leviathanch has quit [Remote host closed the connection]
<sigwinch_>
...and yosys doesn't like typedefs ;-).
<swetland>
try this in verilator:
<swetland>
localparam NCYCLES_1 = NCYCLES - 1;
<swetland>
NCYCLES_1[CYCLE_CTR_BITS-1:0]
<swetland>
it seems to be willing to slice a param but not an arbitrary expression
<sigwinch_>
:-) Very good. Seems to make both yosys, iverilog and verilator happy! Thanks!
kraiskil_ has quit [Ping timeout: 244 seconds]
<swetland>
this has been the adventure of verilog/systemverilog for me -- finding the union of features/syntax/dialect that all the tools I want/need to use can understand
<tpb>
Title: [VeriLog] verilog counter with dynamic width, 0..(N-1), no warn - Pastebin.com (at pastebin.com)
<swetland>
so there's a neat trick for this that someone pointed out to me recently -- if you load the counter to max and then detect the underflow (making the counter one bit wider than you need to be), you don't need an n-bit-wide comparator to detect the trigger/reload -- you just trigger on underflow
<tnt>
sigwinch_: in general if you don't need the value, make counter 1 bit wider, init to xxx-2, doing a decrement and look for the msb going high. Avoids the need for a comparator.
<tnt>
Arf ... was too slow to type :
<sigwinch_>
That's a very useful remark, thanks tnt!
xerpi has quit [Remote host closed the connection]
xerpi has joined #yosys
<sigwinch_>
(and of course swetland ;-) ...)
daniel_ has joined #yosys
<swetland>
tnt's explanation was much more succinct -- worth the wait ^^
<shapr>
hi FL4SHK ! How'd you end up in this nifty community?
<ZipCPU>
It's fast, and it's got plenty of room for logic
<FL4SHK>
shapr: ZipCPU's influence
* ZipCPU
grins broadly
<shapr>
good reason!
<shapr>
FL4SHK: do you do FPGA stuff for money?
<FL4SHK>
I just got my first out-of-college job that I think will be involving that
<shapr>
oh cool! So you just finished your Master's? or you went on to get a doctorate?
<FL4SHK>
just finished my MS
<shapr>
nice!
* ZipCPU
showed FL4SHK how to use formal verification methods on his college project. He told ZipCPU it'd never have worked without the formal methods.
<shapr>
I'd like to go back and get a master's but it did take me twenty four years from start to finish for my bachelor's
<FL4SHK>
oh
<shapr>
mind you, I really *enjoy* taking college classes
<FL4SHK>
some of mine I actually did really enjoy taking haha
<shapr>
I love learning far more than I care about grades
<shapr>
my GPA was never impressive, but when I learn something it sticks in my head forever
<shapr>
that's all I care about
* shapr
swears at pagerduty
<ZipCPU>
shapr: If you want to configure a PLL, you'll need both icepll as well as the iCE40 documentation for their PLLs
<shapr>
for learning by others, why not just use stock BeagleWire 100MHz and modify the synthesizer to handle that?
<shapr>
also, verilog still makes me angry that I can't parameterize clocks
<ZipCPU>
You could
<ZipCPU>
It's not a bad idea
<ZipCPU>
Only problem with 100MHz is ... what happens if you can't get your logic running that fast?
<ZipCPU>
Jan Gray suggests, for high speed clocking, pick a clock rate and stick with it--so you might be good
<ZipCPU>
My problem is that I started with the ZipCPU at 100MHz on an Artix-7 device ... and so all my logic references are with respect to that experience.
wavedrom has joined #yosys
<ZipCPU>
shapr: What kind of speakers do you expect to be using? As in, what interface will they be expecting? I2S? PWM?
<shapr>
I have the i2s pmod from digilent that the original author used
tmeissner has joined #yosys
<ZipCPU>
What clock speed did he use for it? 1MHz?? That would seem rather odd.
<shapr>
i2s is a digital protocol
<tmeissner>
Does anyone tried to build SymbiYosys from source?
<shapr>
ZipCPU: pagerduty is being needy, I'll return sometime :-/
<tmeissner>
I cannot build Avy, I get compilation error
<ZipCPU>
tmeissner: I do it all the time
<ZipCPU>
shapr: ;)
<tmeissner>
I assume that the error results from implicit conversions which are now illegal with the latest C++ standard
<ZipCPU>
What machine are you building on? Ubuntu?
<tmeissner>
debian
<tmeissner>
error: narrowing conversion of '2500023266u' from 'unsigned int' to 'int' inside { } [-Wnarrowing]
<ZipCPU>
Let me check if I can build it (Ubuntu 16.04) ... it's been a while since I have
<tmeissner>
I get a lot of these during compile
<ZipCPU>
Those are probably not an issue
<tmeissner>
Not all, some are warnings, but these are errors and result in compilation abort
<ZipCPU>
What compiler are you using?
<ddrown>
is that gcc 8.x?
<ZipCPU>
As in ... what version of which compiler?
* ZipCPU
is still using GCC 5.4
<tmeissner>
I don't know exactly, I used the apt-get line from the symbiyosys doc
<tmeissner>
I look after the version, please wait
<ZipCPU>
Try typing "gcc -v"
<ZipCPU>
It should show up on the last line of that output
<tmeissner>
gcc version 6.3.0 20170516
* ZipCPU
just upgraded his avy, is about to start building ...
* shapr
grumbles
<shapr>
ok so
<shapr>
ahem
<shapr>
ZipCPU: so I could just divide the clock division counts by five and it'll most likely all work?
<ZipCPU>
Generally, you should use a PLL if at all possible for any clock adjustments
<shapr>
what does that mean?
<ZipCPU>
Most FPGA devices have a series of special PLL hardware blocks within them
<shapr>
is the external clock of the BeagleWire not a PLL?
<ZipCPU>
No, that's a clock
<ZipCPU>
Imagine that to be an incoming square wave toggling at 100MHz
<shapr>
FL4SHK: if you ever want advice on writing Python or Haskell code, I can help :-)
<shapr>
sure, ok
<ZipCPU>
Your goal is to get some other rate ... 20MHz you said
<FL4SHK>
shapr: well tbh I've been programming for much longer than I've been writing HDL codehaha
<shapr>
yeah, different speeds for different things, yeah
<FL4SHK>
Haskell is kind of foreign to me though
<shapr>
FL4SHK: I can help!
<FL4SHK>
I've used Python enough times to be dangerous with it
<shapr>
if you want, not gonna be pushy
<ZipCPU>
While it is possible to do something like: always @(posedge i_100mhz_clk) o_20mhz_clk <= ... something appropriate ...
<ZipCPU>
You are likely to have all kinds of problems doing so
<FL4SHK>
ZipCPU: isn't the "correct" answer to use a counter instead
<shapr>
oh, I thought that was how clock dividers work
<ZipCPU>
Adjusting the clock speed with a PLL is recommended
<FL4SHK>
that much I know you're not supposed to do
<ZipCPU>
shapr: That should work nicely for creating outgoing clocks
<ZipCPU>
I was discussing internal clocks, such as you might use in the @(posedge CLOCK) section of your code
<ZipCPU>
The other stuff ... have at it
<ZipCPU>
;)
<shapr>
there's a difference?
<ZipCPU>
Yes
<shapr>
I thought the external clock was the same as a PLL
<shapr>
in that they're both clock signal sources
<FL4SHK>
you definitely don't want to do @(posedge counter)
<FL4SHK>
in... synthesizeable code
<ZipCPU>
If you use an always @(posedge something) ... use either an externally supplied clock or the output of a PLL (both will work)
<FL4SHK>
^
<FL4SHK>
if you want a "clock divider" without using a PLL I'm pretty sure you can do if (counter[...])
* ZipCPU
considers sitting back and watching his apprentice teach the lesson ;)
<shapr>
FL4SHK: I've been using Python since 1996, but professionally only since 2000
<shapr>
dunno if I'm an expert, but I know more than most
<shapr>
FL4SHK: ok so... what's the difference between a PLL and an external clock?
<shapr>
is the difference that I can change a PLL?
<shapr>
is there any functional difference?
<FL4SHK>
PLLs need an external clock
<shapr>
oh they do?
<FL4SHK>
in terms of your FPGA code it probably doesn't matter which one you use?
<FL4SHK>
yeah
<FL4SHK>
PLLs are like magic to me
<FL4SHK>
but I have used them
<shapr>
so, a PLL on an FPGA needs an external clock to feed it, but then you can change the default clock speed of your entire .. something?
<ZipCPU>
FL4SHK: You didn't read my article on PLL's? ;)
<ZipCPU>
shapr: Yes.
<FL4SHK>
It'd be neat if I could just make a PLL out of logic but
<ZipCPU>
FL4SHK: You can ....
<FL4SHK>
Isn't that a bad idea
<FL4SHK>
I thought it was a bad idea lol
<shapr>
is it?
<FL4SHK>
Maybe I'm wrong
<ZipCPU>
In general, it is ... but some of the Xilinx hardware has some really curious and useful capabilities ... but we are getting off topic
<ZipCPU>
shapr: The basic idea is ... external clock -> (FPGA Boundary) -> PLL -> Clock at whatever rate you'd like (within reason)
<shapr>
ok, so a PLL can modify an incoming external clock
<ZipCPU>
Yes
<shapr>
but you don't get many PLLs?
<ZipCPU>
It can cause it to change phase and frequency. Some PLL's can also output multiple clocks with known relationships to each other
<shapr>
otherwise I could use them to do clock division for me?
<ZipCPU>
No, you don't get many at all.
<ZipCPU>
You don't want to use a PLL to create your I2S clocks
<shapr>
how is a PLL different from a counter that does clock division?
<shapr>
why not?
<shapr>
ZipCPU: I swear I need to send you more money
<ZipCPU>
Why? Because going through the PLL introduces some amount of ns delay
* ZipCPU
does not object
* shapr
fires up patreon
<ZipCPU>
If you are going to send data out of an FPGA, you really want to make certain all of that data transitions on the same clock interval--so it all has the same timing relationships within it
<ZipCPU>
A PLL will give you the right frequency, but will also change phase--usually undesirably--so that you nolonger maintain a known phase relationship with the incoming clock
<somlo>
ZipCPU, shapr: isn't the problem with wiring up your own custom PLLs that now your clock signal would be output over "data" wires rather than dedicated "clock" wires the FPGA might be distributing inside itself? (apologies for jumping in randomly like that into someone else's conversation thread :)
<ZipCPU>
Hello, somlo!
<ZipCPU>
Welcome to the discussion
<shapr>
ZipCPU: upgraded to "needy student" :-)
<ZipCPU>
Yes, that is one of the possible problems
<ZipCPU>
Another one has to deal with making sure the tools can properly do timing analysis on your design
<shapr>
since I'm already asking that kind of question
<ZipCPU>
It can be dfficult to do that with logic
<ZipCPU>
I discussed this in an article some time ago ... I just don't remember which one! :D
<shapr>
you have so much content!
<ZipCPU>
(It wasn't the main topic of the article)
<shapr>
I'm glad you have a patreon, I don't feel as bad about asking piles of stupid questions.
* ZipCPU
changes the sentence structure: "You are so content" ... and likes that better
<ZipCPU>
lol
<ZipCPU>
shapr: Go on, am I helping out with your questions still?
<shapr>
yes!
<ZipCPU>
So ... I have an I2S controller I built some time ago but never used
<shapr>
ok, so PLL could have different phase, hm
<ZipCPU>
I got far enough along that I was at the point where I needed to configure the audio chip and ... that's where I got stuck
<ZipCPU>
Apparently, a lot of audio devices want some really weird frequency: 48.192 MHz or something like that
<ZipCPU>
Creating that frequency is ... not trivial
<shapr>
I will happily mail you a digilent i2s pmod to match the one I own
<shapr>
and a beaglewire
<ZipCPU>
Would love it!
<shapr>
heck, I'll mail you a whole kit of goodies
<shapr>
because then I can ask noobie questions about those goodies!
<ZipCPU>
So far, the only audio out I've done successfully has been with either PWM, or unintentional FM
<ZipCPU>
(well, intentional unintentional FM)
<shapr>
heh
<ZipCPU>
It turns out those GPIO wires can be made to "broadcast" at your favorite frequency ... :D
<shapr>
oh, did you see the hackaday article yesterday?
<ZipCPU>
One project of mine involved playing Queen on my favorite local Christian radio station
<tpb>
Title: Your USB Serial Adapter Just Became a SDR | Hackaday (at hackaday.com)
<ZipCPU>
No, I hadn't seen that one ... I'll look forward to reading it
<tmeissner>
ZipCPU I've found a forum wheresome users of ArchLinux ran into the same compile error
<ZipCPU>
tmeissner: You might consider trying to build one of the other Avy branches ... you might find it builds easier, but I can't comment on whether or not it would work better
<tmeissner>
ZipCPU they fixed it by adding a option to cmake that gcc don't take these errors only as warning
<ZipCPU>
Sounds like a good temporary patch
<tmeissner>
ZipCPU the master branch of avy is pretty old (2015), so maybe you're right, that one of the other branches don't have this problem
<ZipCPU>
Looks like most of the work is being done in the new_quip branch
<ZipCPU>
There's also a quip branch which appears to have been stable for half a year or so
<tmeissner>
Let's try the new_quip first, I'm a adventurer today :D
<shapr>
ZipCPU: so your suggestion was to change the clock signal on the BeagleWire to match the 500MHz of the original board?
<shapr>
no wait...
* shapr
reads back
<ZipCPU>
500MHz? What runs at 500MHz? The example you shared had 500 kHz in it ..
<shapr>
er, I thought the incoming clock was 500MHz for the xilinx board this synthesizer was created to run on?
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<ZipCPU>
Here's some of the rules I use to make certain the memories I create/define are inferred properly: https://imgur.com/a/cISRlrS
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<ZipCPU>
I think rule #2 is perhaps the most common frustration among beginning designers using memory
<shapr>
oh
<shapr>
ram init seems sensible enough
<shapr>
ZipCPU: if you have multiple always blocks, do they act as one?
<ZipCPU>
Officially: No Unofficially, it might depend by what you mean
<ZipCPU>
I typically write my designs with as many always blocks as I have variables, or just shortly less than that--mostly for cost savings
<shapr>
mostly wondering if multiple always blocks in the same module are equivalent to one always block with the same code
<ZipCPU>
Roughly, yes, but it doesn't work in reverse
<shapr>
because ordering?
<ZipCPU>
Ordering, yes, and also references to things within the block
<ZipCPU>
The simulator is free to pick whatever order it wants to execute the always blocks using
<ZipCPU>
This is where blocking (=) vs non-blocking (<=) gets ugly
<shapr>
yeesh
<shapr>
not sure I actually like verilog
<ZipCPU>
If you have a blocking (=) assignment in one always block, and a reference to the value in another, which will get executed first?
<shapr>
but it's what I have
<ZipCPU>
You'll also have problems with Verilator ... it doesn't handle blocking assignments (=) very well
<ZipCPU>
To avoid hardware/simulation mismatch, always use the non-blocking operator (<=) within any clocked always block, and the blocking operator (=) within any combinatorial always block
<ZipCPU>
(That much was in the tutorials ... see lesson two)
<tmeissner>
I think there are some goop papers from sunburst regarding thi problems with (non)blocking assignments
<ZipCPU>
Could be ... but I don't remember seeing any such papers
<ZipCPU>
I might need to look again--that would be valuable
<adamgreig>
what's the deal with always @* begin bla = 1'h0; bla = some_other_sig; end
<tmeissner>
But the hint of ZipCPU is best for beginners I think
<adamgreig>
odd syntax for initialise to 0 and thereafter combinatorially equal to some_other_sig?
<ZipCPU>
adamgreig: Not at all. the first assignment will be ignored in favor of the second.
<tmeissner>
I can remember to some Verilog 4 VHDL users course at Doulos. And this problem was handled very at the beginning
<adamgreig>
where bla is "reg bla"
<adamgreig>
ZipCPU: so the first assignment is meaningless?
<somlo>
"always @*" is combinational, though (always_comb in System Verilog)
<ZipCPU>
adamgreig: Yes
<adamgreig>
yea, so why would you write two blocking assignments in a combinatorial block to the same register?
<somlo>
as opposed to always @(some_edge some_signal), which is where you'll want to limit yourself to nonblocking
<somlo>
adamgreig: so you can have Verilog sort things out for you: bla = 0; if (something) then blah = 4'hF; else ... etc
<adamgreig>
i mean just literally "reg foo; always @* begin foo = 1'h0; foo = other_sig; end"
<somlo>
you get a default value, and if some conditions are true you might end up assigning something else -- but you'll always have assigned *something* to it
<somlo>
I think that's redundant (legal, but the 1'h0 thing gets optimized out)