<ZipCPU>
git pull didn't turn up any updates since the last ttime, some long time ago
<shapr>
from what you've taught me previously, I thought I could change the numbers used to do .. it's not clock division, wasn't there a different/better name?
<ZipCPU>
Hmm .... don't see any Verilator C++ files anywhere around here either ...
<shapr>
I found this on github, asked the author to add a license so I could use it
<shapr>
thing is, I have the same digilent pmod the author used
<ZipCPU>
synthesizer.v is the top module?
<shapr>
but a different clock speed
<ZipCPU>
Ooohh, okay
<shapr>
I think so?
<ZipCPU>
Do you have all the specification sheets?
<shapr>
I vaguely recall that this was developed on a Xilinx board, but I have forgotten the details of our previous discussion
<ZipCPU>
Do you have a trace of that code at all? (pmod_out that is)
<shapr>
I do remember we stopped when you pointed out that the *phase* of a signal must be preserved, I can't just change the divider numbers however I like
<shapr>
I have nothing
<shapr>
except this source, and a burning desire to get it working on the beaglewire
<shapr>
I also have nearly zero clue about FPGA design, just what I've heard here, and read in your tutorials.
<ZipCPU>
Ok, if you've read the tutorials, do you remember how cover() works?
<shapr>
I do not
* shapr
quickly opens the tutorials
<ZipCPU>
I start discussing cover() in lesson 3
<ZipCPU>
Ever after that, we use it as part of our verification steps
<shapr>
I pretty much skipped the verification parts... figured I wasn't up to that yet
<ZipCPU>
Let's start that here: Add a line `ifdef FORMAL, followed by an `endif // FORMAL, and then we'll add some more between those
<ZipCPU>
Specifically, let's create a 10 bit counter: reg [9:0] counter; initial counter = 0;
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<shapr>
my room is heating up while I build z3
<ZipCPU>
That shows you the code modifications to pmod_out.v, and the sby file I created
<ZipCPU>
I named the sby file: pmod_out.sby
<ZipCPU>
To run, just type: sby -f pmod_out.sby
* shapr
takes notes
pie_ has joined #yosys
<ZipCPU>
Then to view the trace, type: gtkwave pmod_out/engine_0/trace0.vcd
<ZipCPU>
Looks like our trace isn't quite long enough ;)
<shapr>
you can tell that because one of the lines only makes a single transition from zero to one?
<shapr>
is that right?
<ZipCPU>
Really long traces are a challenge to formal. While creating a trace is easy, getting a long one can take some work
<ZipCPU>
Yes, that's right
<shapr>
sclk to be specific
<ZipCPU>
Let's see if I can exhaust (i.e. formal) out to 2052 steps ... usually this is too far ...
<ZipCPU>
Well, not just the sclk, but also the lrclk
<ZipCPU>
The lrclk should toggle with every switch from the left speaker to the right speaker
<ZipCPU>
(and back again)
<shapr>
oh, I hadn't noticed lrclk
<ZipCPU>
I've made it to 1200 ... still going ...
<ZipCPU>
... it's starting to slow down ....
<shapr>
uh oh
<ZipCPU>
I asked it to go to 2052. Normally, the longest trace I do is about 300 steps or so
<ZipCPU>
Usually those traces really load the system--it's much easier to get a long trace via simulation than formal
<ZipCPU>
I'm up to about 1800 now ...
<shapr>
maybe there's a bug?
<ZipCPU>
... and just realized there is a bug and this isn't going to work ... I created a 12'bit counter, and I wanted an 11'bit counter ...
<shapr>
that is, perhaps the transition doesn't happen because of a bug in the verilog?
<shapr>
how could a too-large counter affect this?
<ZipCPU>
Nah, I'm covering a counter--not a transition
<ZipCPU>
Using the cover statement, I'm asking the formal tool to find a way, any way, to make the statement true
<shapr>
how do you know what size counter you need?
<shapr>
oh right, SMT solver
<ZipCPU>
cover(expr); /// finds anyway to make expr true
<ZipCPU>
To see your lrclk_count "tick", you'll need at least 1600 steps
<ZipCPU>
Let's let this run again, and chat about the tutorial
<ZipCPU>
You say you've read through the tutorial?
<shapr>
I skipped all the parts about formal anything :-/
<ZipCPU>
Lol!
<ZipCPU>
... and you expected your code to work? ;)
<shapr>
I expected code to blow up in creative ways that would teach me something
<ZipCPU>
See, that's what formal is for: to get the code to blow up in strange and creative ways--but where and while you can watch it
<shapr>
ok, fair point
<ZipCPU>
When the code blows up in strange ways on the hardware, you might wonder what's going on and have no way to figure it out
<ZipCPU>
Doesn't Haskell have a sort of "correct-by-design" methodology within it?
<shapr>
it does, but you get to choose your level of correctness
<ZipCPU>
Tell me, how so?
<shapr>
you can ignore all the safety if you want, or you can use the type system to check everything
<ZipCPU>
Do you tell it what to check, and what checks need to be valid?
<ZipCPU>
(Yes, there is a reason to my topic diversion here ...)
<shapr>
sort of, you could use a list in all sorts of ways, or you could define a datatype that acts like a list but constrains how you can use thta list
<ZipCPU>
How about a counter? Can you create a counter and then insist that it stay between 0 and say 62?
<shapr>
you can, yes
<shapr>
though it's not simple to constrain a value like that, it's doable
<ZipCPU>
I ask because formal methods are something kind of similar to that
<ZipCPU>
By constraining values to only those values something should have, and expressing relationships between things using formal, you can guarantee that when you place your design on actual hardware that it works
<shapr>
from what I know about SMT solvers (such as z3) you can ask it to find some combination of inputs that sets certain values to true or false
<shapr>
the wikipedia page for I2S shows a timing diagram
<ZipCPU>
First things first with any project or hardware. Once you get/acquire/purchase hardware, the first thing you want to do is to gather some files together. Among these files are the schematic for the board, and the data sheets for all of the chips on the board
<ZipCPU>
Also grab any documentation the vendor provides
<ZipCPU>
Grab this at the beginning of any project, lest the vendor make updates to things and not (necessarily) tell you about them.
<shapr>
ah, like vendoring a library when building an application
<ZipCPU>
Not familiar with the term
<shapr>
get a version of a library saved locally so when you become familiar with its bugs, etc things don't change out from under you
<ZipCPU>
That said, most of my projects have a core directory structure with two entries: refs/ for all of these reference files, and trunk/ for all of my project files (left over from those old svn days)
<ZipCPU>
Yes!
<shapr>
ok
* shapr
makes more notes
<ZipCPU>
Some projects also have a third directory, xilinx/, in which I force the vendor to place all their specific stuffs into
<shapr>
why so?
<ZipCPU>
This directory is not covered under git
<shapr>
is that for generated outputs?
<ZipCPU>
That makes it easy to blow it away and rebuild it, without worrying about damaging any source files
<ZipCPU>
Yes
<shapr>
ok
<ZipCPU>
It's for the project file, generated outputs, reports, etc
<ZipCPU>
Most of the fun parts of a project are within the trunk/ directory
<shapr>
right, makes sense
<ZipCPU>
Within that directory you get an rtl/ subdirectory for all the Verilog, a bench/cpp for all the C++ test bench stuffs, and a bench/formal for all my sby files and a Makefile to run them
<shapr>
ok
<ZipCPU>
If software is involved in the project (other than the bench tests), I'll often create a sw/ directory. sw/host will hold the things that run on my host (i.e. PC) computer
<shapr>
do you also have a top level Makefile so you can make clean to blow away generated files in xilinx/ ?
<ZipCPU>
(I had someone try and run PC programs on the ZipCPU, so I make a distinction there)
<ZipCPU>
No
<ZipCPU>
One of the items on my bucket list is to finally figure out how to "make" a Xilinx project
<ZipCPU>
I haven't figured it out yet, although it doesn't look all that hard to do
<ZipCPU>
The other problem with removing the xilinx/ directory is ... some of the items within there can take many minutes to build. You don't normally want to delete it therefore, although there will be times when Vivado isn't treating you nicely and ... you get the picture.
pie_ has joined #yosys
<ZipCPU>
So for this project, you really need a bench/formal directory (to make sure the surprises happen where you can watch and understand them) and a bench/cpp directory (for long term simulation)
<ZipCPU>
The files themselves can be moved into an rtl/ subdirectory
<ZipCPU>
This doesn't need to be done now
<shapr>
ok
<ZipCPU>
(Perhaps when we are done0
<ZipCPU>
)
* ZipCPU
pulls up the spec sheet pdf he downloaded
<ZipCPU>
Did you download the Cirrus Logic spec sheet?
<shapr>
no, I've been building my way towards SymbiYosys
* shapr
downloads
<shapr>
ok, got it
<ZipCPU>
Check out page 10
<shapr>
I'm accustomed to working at the adafruit level
<shapr>
Lady Ada tends to make clear documentation meant for newbies
<ZipCPU>
Lol ... this is the level I've been successful working at
<ZipCPU>
This is also how I've managed to answer so many questions on Digilent's forums--by looking for the underlying spec sheets and reading them
<shapr>
what's a left-justified interface?
* ZipCPU
hasn't answered nearly as many Digilent forum posts recently
<ZipCPU>
Most significant bit first
<shapr>
oh, huh
<shapr>
never would have guessed that
<shapr>
there are two different chip numbers
<ZipCPU>
That's one of the big things about I2S ... by placing the MSB's to the left (i.e. first), you can send only as many bits as you have and then just stuff things with zeros
<shapr>
does this mean there are two chips in the pmod?
<ZipCPU>
No
<ZipCPU>
It means the vendor built two chips but only put the time into writing one spec
<ZipCPU>
Why write two specs if you can stuff all the information into one?
<shapr>
so next step is to figure out which chip is in the pmod I own?
<ZipCPU>
Exactly! That should be marked on the schematic
<shapr>
aha, 5343
<shapr>
according to the digilent webpage at least
<shapr>
the chip difference appears to be something about the lrclk being to the left?
<shapr>
what should that tell me?
<ZipCPU>
Ok, I like your I2S chip ... there's no nasty set of 50k registers to set up in order to do anything useful
<ZipCPU>
What page are you reading that from?
* shapr
opens a window to keep his laptop from overheating
<shapr>
same page 10
<shapr>
I'm trying to see the difference between the cs5343 and the cs5344
<ZipCPU>
Yeah, okay, I see it
<shapr>
that is, what's different between the top and bottom timing diagrams?
<ZipCPU>
The difference is that on one chip, the MSB takes place while LRCLK changes, and on the other chip it takes place after LRLK changes
<ZipCPU>
*LRCLK
<ZipCPU>
While the change is minor, it's something you'll need to knwo
<ZipCPU>
know
<shapr>
ok
<shapr>
and the chip I have is where LRCLK changes before MSB is sent
<ZipCPU>
So ... what can we learn from this ... usually there's some good timing information ...
<ZipCPU>
Yes
<ZipCPU>
Ideally you'd want to formally verify that's the case
<shapr>
is it important to notice the *phase* of these signals as well?
<ZipCPU>
... or rather, that such is the case of what pmod_out produces
<ZipCPU>
Let's look up t_sclkw and t_stp
<shapr>
if sclk were inverted, would I still be able to send audio?
<shapr>
previous page
<ZipCPU>
Not sure
<ZipCPU>
Usually my goal is to follow the diagram given on a page like this, rather than to divert from it
<shapr>
does duty cycle imply the max or min window of time something has to change?
<shapr>
ok
<ZipCPU>
If you make the waveforms match this one, you know the design will work
<ZipCPU>
Is your clock, i_clk, running at 50MHz or 100MHz?
<shapr>
BeagleWire stock is 100MHz according to the docs
<ZipCPU>
Perfect! Our trace has the right timeunits then
<ZipCPU>
(There's got to be a way to change the timeunits, but 10ns has always worked for me)
<shapr>
er, what?
<ZipCPU>
So now we can measure how long the mclk is, as an example
<ZipCPU>
(You can see from the picture the duty cycle is 50% ..)
<ZipCPU>
Looks like 500ns for MCLK
<shapr>
somewhere in the verilog we set the unit to 10ns?
<shapr>
or is this for the formal stuff?
<ZipCPU>
The 10ns was the step size in the trace the formal stuff created
<ZipCPU>
There's got to be a way to match it to your design ... I've just never done it
<shapr>
ok, that's where they need to match
<ZipCPU>
So, if your design was using 50MHz (20ns) ... the two wouldn't match at this point
<shapr>
how does 50MHz translate to 20ns?
<shapr>
oh, each clock is X ns?
<ZipCPU>
Each clock period is some number of nanoseconds. So take 1 / (CLOCK RATE) and you should get 10e-9 for a clock rate of 100MHz, or 20e-9 for a clock rate of 50MHz
<shapr>
ok, that makes sense
<ZipCPU>
I'd like to know how the MCLK corresponds to a particular sample rate ... but I'd need to read the data sheet more
<ZipCPU>
That should be an important part of your design -- matching the two
<ZipCPU>
Ideally, you should be able to play a tuning note from whatever musical instrument, and also play a note on your FPGA and the two pitches should match
<shapr>
ok
<ZipCPU>
Let's see ... you'd be running this in slave mode, right? (Can't see why not)
<shapr>
no clue
* ZipCPU
was looking at the wrong half of the chart
<ZipCPU>
Ok, then let me tell you: Yes
<ZipCPU>
Since you are providing the clock to the chip, the chip will act as the slave and you the master
<shapr>
means the clock is coming from the beaglewire?
<shapr>
ok, got it
<ZipCPU>
Yep!
<ZipCPU>
So the chip offers two useful modes for this SCLK period: Single-speed 384x mode, and single-speed 256x mode
<ZipCPU>
Oohh ... the SCLK period needs to directly relate to the sample rate (see the equation?)
<shapr>
how do you know they're useful for this?
* shapr
looks for the equation
<ZipCPU>
It's about 5-lines from the bottom of page 9
<shapr>
oh, I see it
<ZipCPU>
An SCLK period of 500ns corresponds to a 31.25kHz sample rate if you run the equation and solve for Fs
<ZipCPU>
The last three lines give us some nice formal properties we can work with
<shapr>
why is there a negative value there?
<ZipCPU>
You can see from the trace we have SCLK falling on the LRCK edge, so that's good
<shapr>
sclk falling to lrck edge
<shapr>
why is that good?
<ZipCPU>
It's just that you've got some slop there
<shapr>
oh, ok
<ZipCPU>
Given when LRCK changes, SCLK must change within 20ns of that--two clocks basically
<ZipCPU>
In the trace we just generated, SCLK is falling at the same time LRCLK is changing--so that's perfect
<ZipCPU>
We can quantify that as: always @(posedge i_clk) if ((f_past_valid)&&(!$fell(o_i2s_sclk))) assert($stable(o_i2s_lrclk));
<shapr>
wait, I don't see sclk changing when lrck changes in the trace
<shapr>
sclk changes at 0.5 ns, right?
<shapr>
er, microsecond, sorry
<ZipCPU>
Hmm ... yeah, you are right
<ZipCPU>
I got it confused with the MCLK
<ZipCPU>
So, that'd be broken then--good catch
<shapr>
I'm just trying to verify that I can at least see what you're saying :-)
<ZipCPU>
Good, good
<ZipCPU>
Looks like I mucked around with it. (I'd forgotten about that) Let me revert back to what's in the repo and see if it changes anything
<shapr>
hm, super_prove_build fails to build, I can figure that out later
<ZipCPU>
Yeah ... I've struggled to get that one to build
<ZipCPU>
I don't use it, so it hasn't bothered me much
<ZipCPU>
I really spend all my time with yices and boolector
<shapr>
since I don't know what pieces I'll need, I'm just building everything in clifford's list
<ZipCPU>
;)
* shapr
warms the room with make -j12 in extavy
<ZipCPU>
Lol
<ZipCPU>
So, ... I reverted back to the repo's version and now I'm getting a bunch of bugs ...
<shapr>
so right now you're trying to confirm that the verilog code in the repo matches the requirements in the spec sheet?
<shapr>
not surprised...
<ZipCPU>
Well, where else would you start?
<ZipCPU>
This is how I get things to work ... read the spec sheet, look specifically for the pretty drawings, and check the timings
<shapr>
I don't know where I'd start, so I'm confirming that I do understand what and why
<ZipCPU>
Ok, found the bug ... you can't initialize sig_temp to sig because sig isn't constant. (That's on my line 25)
<ZipCPU>
shapr: Yep! Start with the schematic and the data sheets
<ZipCPU>
Match the pins on your FPGA to the pins on the data sheet via the schematic
<ZipCPU>
Use the schematic to find the data sheets of relevance, then look for the pretty pictures
<ZipCPU>
Usually, there's also some kind of instructions as well as the pictures--things like, set this register to this to accomplish that
<shapr>
earlier you said this doesn't need a bunch of that?
<ZipCPU>
For example, my ethernet chip has a register that I can use to make the port lights blink manually
<shapr>
"no nasty set of 50k registers to setup"
<shapr>
huh, interesting
<ZipCPU>
Exactly. This chip is unusual among the I2S chips I've looked at, since it doesn't have an I2C (not I2S) requirement allowing/requiring you to (re)configure it
<shapr>
morse code :-D
<ZipCPU>
Well ... this is why I haven't started my own I2S journey
<ZipCPU>
It's not because I don't have the code, and its not because I don't have a board with I2S on it
<ZipCPU>
It's because I can't decide how to go about configuring the I2S that I have
<ZipCPU>
or rather ... the sound chip (with the I2S ports) that I have
* ZipCPU
is still running the 2k samples to see if he destroyed the SCLK ...
<ZipCPU>
Ok ... cover just passed, let's look at this new/updated trace ...
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<ZipCPU>
&counter is an expression that will only ever be true if the *and* of all the bits in the counter is 1'b1
<ZipCPU>
cover() is a formal operator that instructs the formal tools (when using mode cover) to exhaustively examine your design to see if there is some way to make the expression within true
<ZipCPU>
So ... I'm using it to quickly get a trace of 2048 timesteps
emeb_mac has joined #yosys
<ZipCPU>
If you now zoom in on the LRCLK transition, you can see that it takes place at a time where SCLK falls as well
<shapr>
yes
* ZipCPU
backs up to take a peak at the rest of the project
<shapr>
I'd be perfectly happy being able to send noise out of the pmod
<ZipCPU>
Lol!
<ZipCPU>
Be careful ... you might find yourself sending silence out of it, and not realizing what you've done
<ZipCPU>
Did you write the osc_sine.v function?
<shapr>
nope!
<shapr>
I wrote zero of this
<shapr>
like I said, found it on github, seemed like the thing I wanted, asked the author to add a license
<ZipCPU>
I'm not sure I know of any hardware that can do a divide
<ZipCPU>
Some hardware can do multiplies, but divides? Those are ... two steps past reality
<shapr>
ohh, that line 19 in osc_sine.v ?
<ZipCPU>
No, not that. All the initial stuff is done by the synthesizer, not the hardware
<shapr>
so that'll need to change for it to work on this ice40?
<ZipCPU>
I'm more worried about linse 39 and 41
<shapr>
I think this was written for a Xilinx Zynq board?
<ZipCPU>
Those are divides by constants, so they might work ... since you could turn them into multiplies
<ZipCPU>
Yeah, this might not work on an ice40
<ZipCPU>
(Other things would)
<ZipCPU>
For example, what equation defines cos_curr from start to finish?
<shapr>
My mother was an English teacher, I had that kind of thing drilled into me.
<shapr>
I could put up PRs to fix your blog if you like :-)
* shapr
spots more typos
<ZipCPU>
My problem is ... I read things things in all kinds of formats ...
<ZipCPU>
I first build it in markdown, then add links, then try to read it on the page but often end up switching to markdown, ... etc, etc, etc
<shapr>
makes sense
<shapr>
I often see what I think I wrote
<shapr>
so, how do I set the frequency from the BBB?
<ZipCPU>
Good question, let's go back to the schematic
<shapr>
output a single frequency from the verilog, and have an input signal to move the frequency?
<ZipCPU>
Sure!
<shapr>
that wouldn't require division?
<ZipCPU>
It sort of depends upon how much work you want to put into the communication
<ZipCPU>
No division
<shapr>
could I write verilog that acts like division? or would that be too slow?
<shapr>
I assume I'll have space
<ZipCPU>
You actually do have space. I've placed a divide unit onto an 8k before with space left over for the CPU that uses it :D
<ZipCPU>
What you don't have is time
<shapr>
oh
<shapr>
divide unit takes multiple cycles?
<ZipCPU>
The code you have asks for a division to be accomplished in one clock cycle
<shapr>
ah
<shapr>
man, this is weirder than a C programmer writing Haskell
<ZipCPU>
My divide unit takes (roughly) 32 clock cycles to divide a 32'bit number by another one
<shapr>
oh wow
<ZipCPU>
Lol
<ZipCPU>
And the multiply unit? That's crazier
<ZipCPU>
I finally got a *REALLY* good multiply unit to work on my ice40
<shapr>
whew
<ZipCPU>
It costs half as much as any other one I might try
<ZipCPU>
However, it also costs about N+2 cycles for an N-bit multiply
<shapr>
multiply can be done in a single cycle, but division only if you have a DSP
<ZipCPU>
No, other way around
<shapr>
division can be done in a single cycle?
<ZipCPU>
Multiply can be done in one cycle if you have a DSP, division always takes many cycles (or a *REALLY* slow clock)
<shapr>
ohh
<shapr>
my brain is getting full
<ZipCPU>
So, since the iCE40hx8k doesn't have DSP's, my multiply algorithm takes N+2 clocks for an NxN multiply
<ZipCPU>
This is good, right?
<shapr>
yes!
<shapr>
exactly what I wanted!
<shapr>
drinking from the firehose!
<ZipCPU>
Ok, I do have a recommendation for you:
<shapr>
1. read the formal parts of the zipcpu tutorials
<shapr>
2. install all the tools
<ZipCPU>
Go back through the tutorial, and do *all* the exercises. Get them to work on your hardware
<shapr>
3. read ALL the zipcpu tutorial blog posts
<shapr>
yeah!
<ZipCPU>
That'll give you several examples to work with that are (roughly) similar to this one
<shapr>
spiffy
<ZipCPU>
It'll also give you a base to work with, so that you can understand this problem when you get to it
<ZipCPU>
Do you have a serial port to work with?
<shapr>
I sort of wish the beaglewire had DSPs, but I'm sort of glad it doesn't, I have to learn the real stuff
<shapr>
er, sort of
<ZipCPU>
Sort of?
<shapr>
I have an FTDI cable
<shapr>
I have some arduinos that only take serial input, don't have their own FTDI chips
<shapr>
I may have a serial pmod
<shapr>
I bought a whole bunch
<ZipCPU>
Serial pmod is good ... I think it's calld a Pmod USBUART
<ZipCPU>
Double check the power on it though--you don't want to be fighting with the BBB's power
<ZipCPU>
(There's a jumper that needs to be set properly)
<ZipCPU>
You might also have a serial port directly into the BBB---check your schematic
<ZipCPU>
That'd probably be the easiest one to work with
<ZipCPU>
(Remember: Download the schematic first ... that'll tell you what's hooked up to what)
<shapr>
I don't have a serial pmod
<ZipCPU>
The RaspberryPi as I recall had a serial port on its extension pad ... but I might need to check that
<shapr>
they do sell a usb to uart
<ZipCPU>
(I'm checking to see if I have a BBB schematic ...)
<shapr>
the BBB is way more complicated than the rpi, imo
<shapr>
also far more oshw
<ZipCPU>
Yes, I think you are right on that account
<shapr>
(see my earlier comments in #openfpga about the closed-ness of the rpi)
<ZipCPU>
There it is ... yes, you have a couple of UART's on your expansion header
<shapr>
oh good
<ZipCPU>
That's on the last page of the BBB schematic I have (page 11)
<ZipCPU>
Looks like you might even have 4 separate UARTs ... neat. Not sure what you'd use 4 UART's for .... but you have them
<shapr>
then I could talk to one of my arduinos that only have serial?
<ZipCPU>
Yes
<ZipCPU>
It's also an easy way to talk to your FPGA and figure out what's going on within it, and to tell the FPGA what you want it to do
<shapr>
how do you do that?
<ZipCPU>
The tutorial focuses in many ways on the serial port, so having one will make your task easier
<shapr>
serial from your desktop to your FPGA?
<ZipCPU>
Absolutely!
<ZipCPU>
Not only that, but imagine running a C++ program on your desktop with calls to readio(ADDR) and writeio(ADDR, VALUE); which you can use to read and write values within your FPGA
<shapr>
since I have the beaglewire daughterboard (cape?) perhaps some of the ice40 pins connect to uart pins on the bbb?
<shapr>
that would be handy
<ZipCPU>
You know, one value might set the frequency of your tone, and another the amplitude?
<shapr>
reminds me of ws2812 code I've written
<ZipCPU>
;D
<shapr>
yeah, I did that for neopixels, where I'd send RGB values for each pixel
<ZipCPU>
See ... this is another reason why you want to start with the schematic--it lets you know what toys you have to play with
<shapr>
got slow with 144 though
<ZipCPU>
What did you write the code with?
<ZipCPU>
As in, what hardware did you use to control your ws2812?
<shapr>
I was using the arduino IDE, it's sort of C++
<shapr>
I sent it text commands over the usb<->serial, and it set the ws2812 values
<ZipCPU>
Ok, even better, now imagine connecting that to an FPGA. You could toggle those lines as fast as they could go, instead of as slow as the arduino would go
<shapr>
that would be *cool*
<shapr>
I have an unreasonable number of ws2812
<ZipCPU>
Indeed, using the FPGA, you could probably toggle the lines *too fast*, so you'd need to make sure you ran at the right speed
<ZipCPU>
Ooohh, even better, why not use your FPGA to toggle several of them at once? ;)
<ZipCPU>
Lots of possibilities there.
<shapr>
power problems
<ZipCPU>
Let's get back and focus, though ...
<ZipCPU>
Start with the serial port.
<shapr>
ok
<ZipCPU>
On the BBB, you'll use a program called "minicom" to communicate with the serial port
<shapr>
I think I have several hundred watts worth of ws2812b in various form factors
<ZipCPU>
Lol
<shapr>
yup, familiar with minicom
<ZipCPU>
Perfect!
<shapr>
used that for talking to the arduinos
<ZipCPU>
Do you have any buttons on your BeagleWire?
<shapr>
yes, three
<ZipCPU>
Ooohhhh!!! You've got to try the button pressing project
<keesj>
I see next_xorshift32_state reused different times in the always block and kinda find that .. strange (compared to my understanding). I expect the next_xorshift32_state on the right side to .. only change value past the always block e.g. while the first line (28) modifies the next_xorshift32_state I expect this modification to not be visible on the next line (29)
<daveshah>
keesj: the modification is visible because a blocking assignment (=) is used rather than a non-blocking assignment (<=)
<keesj>
am I correct and if so.. I am corret in thinking only the last line (29) actually result in something?
<keesj>
A.. ok
<daveshah>
think of it like := with a variable in VHDL
<keesj>
and would this change be visible externally ? e.g. the stant changes be visible
<daveshah>
eh, it's complicated
<daveshah>
not in hardware
<keesj>
ok.. I (might ) get it..
<daveshah>
in simulation you get all kinds of ugly race condition possibilities that I can't exactly remember
rohitksingh has quit [Ping timeout: 246 seconds]
seldridge has quit [Ping timeout: 250 seconds]
_whitelogger has joined #yosys
seldridge has joined #yosys
mms has joined #yosys
<mms>
Evening fellas
<daveshah>
Heya mms
<mms>
Has anyone done or know any comparison done between yosys and vtr?
<daveshah>
I'm not aware of any detailed comparisons
<daveshah>
Last time I looked Yosys' Verilog support was much broader than ODIN II's
<mms>
I see
<mms>
I guess I have to check their Verilog support, thanks daveshah
<daveshah>
Is there anything in particular you are interested in?
<mms>
daveshah, No. I'm really new to logic synthesis and I was looking to get an general overview of these two.