pie___ has quit [Remote host closed the connection]
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 252 seconds]
_whitelogger has joined ##openfpga
mkdir has joined ##openfpga
<mkdir>
heddo, fresh blood here
<mkdir>
like a lil noob
<mkdir>
is all verilog portable across different dev boards
<whitequark>
nope
<whitequark>
you have to spend a lot of effort to make it portable
<mkdir>
mm I see
<mkdir>
do you have an ice40?
<whitequark>
sure
<mkdir>
I was wondering if you could answer some simple questions about the verilog source example code: https://pastebin.com/daEiEfHc
_whitelogger has joined ##openfpga
<whitequark>
verilog has both blocking and nonblocking assignments, and you have to use them very very carefully if you want your logic to actually work
<whitequark>
the general rules are:
<mkdir>
is >= a thing?
<fseidel>
it
<fseidel>
's greater than or equals
<whitequark>
1) <= is used only in a clocked block, always @(posedge clk), or always @(posedge clk or posedge rst) (it could be negedge too, usually)
<mkdir>
well yes, but in verilog. not sure why less than or equals is used as a nonblocking assignment (maybe there is some intuition I am missing)
<whitequark>
2) = is used only in a combinatorial block, always @(*)
<emily>
it's an arrow.
<fseidel>
annoyingly, <= is also "less than or equals" so the meaning varies with context
<mkdir>
thanks whitequark
<whitequark>
3) any combinatorial block that assigns a certain variable *must* assign that variable in each branch, or you'll get latches, and you really dont' want latches
<whitequark>
i.e. something like `always @(*) if(foo) a = 1;` is not valid
<emily>
fseidel: oh god lol
<emily>
why is verilog
<mkdir>
ahh I see fseidel
<whitequark>
emily: wait until you see SystemVerilog. it has typedef *and* enum.
<whitequark>
it's like someone looked at C++ and thought "wow, what a well-designed language"
<fseidel>
FWIW, I think always_comb and always_ff were good additions to the language
<whitequark>
yes. SV has fixed the absolute worst sins of Verilog.
<fseidel>
(and I guess always_latch, but I hardly use that)
<whitequark>
and then it added like 10x as much on top
<mkdir>
whitequark: what are latches, and is = used for blocking assignments
pie___ has joined ##openfpga
lopsided98 has joined ##openfpga
forrestv has joined ##openfpga
nrossi has joined ##openfpga
henriknj has joined ##openfpga
nats` has joined ##openfpga
edmoore has joined ##openfpga
unkraut has joined ##openfpga
kmehall has joined ##openfpga
ormiret has joined ##openfpga
TAL has joined ##openfpga
implr has joined ##openfpga
tnt has joined ##openfpga
Hoernchen has joined ##openfpga
Zorix has joined ##openfpga
Richard_Simmons2 has joined ##openfpga
<whitequark>
mkdir: latches are storage elements like flip-flops (google "D-latch"), and yes
<emily>
petition to replace the <= assignment operator with ⇐
asy_ has joined ##openfpga
knielsen has joined ##openfpga
futarisIRCcloud has joined ##openfpga
kervel has joined ##openfpga
florolf has joined ##openfpga
indefini[m] has joined ##openfpga
SpaceCoaster has joined ##openfpga
tpw_rules has joined ##openfpga
mearon has joined ##openfpga
thehurley3[m] has joined ##openfpga
sorear has joined ##openfpga
kuldeep has joined ##openfpga
miek has joined ##openfpga
show has joined ##openfpga
bibor has joined ##openfpga
guan has joined ##openfpga
reportingsjr has joined ##openfpga
<mkdir>
emily: agreed, never thought it that way lol ofcouse <== is used often in mathematics and pseudocode
<fseidel>
the main thing to get out of latch VS FF is that the latch is level sensitive (value updates when enable line is active, holds when inactive)
<mkdir>
or rather that arrow symbol
<whitequark>
mkdir: oh also. you can write a lot of things inside `always @(...)`, but only three ever make sense. @(*), @(posedge clk), and @(posedge rst). (their negedge variants are sometimes useful, too.)
<mkdir>
<= just looks like less than or quals
<whitequark>
everything else will not synthesize or will synthesize to something you will regret running
<fseidel>
FFs are edge sensitive, so they update on the clock edge and hold when not on edge
<fseidel>
FPGAs do not handle latches well
<mkdir>
whitequark: what does posedge mean
<whitequark>
mkdir: that whatever is inside of the block runs on the rising edge of the specified signal
<emily>
mkdir: did you know that \ was originally included in ASCII to allow the formation of the \/ and /\ for logical and/or?
<whitequark>
emily: thanks I hate it
<emily>
and yet C just straight up ignored :this '(
<emily>
I don't hate it! it's good syntax
<mkdir>
mm I see what is posedge rst?
<fseidel>
that's a really neat fact, I'm gonna keep that one for later
<fseidel>
rst is the name of a signal, likely a reset
<mkdir>
emily: I did not, very interesting
<fseidel>
so the block triggers when rst transitions from low to high
<emily>
<= isn't too weird for me, because I'm used to Haskell's do notation using <- for assignment
<mkdir>
mm I see
<emily>
Verilog and Haskell being the intimately-related languages they are
<mkdir>
emilly: well now that I think of it like an arrow, it feels more right
<whitequark>
but <- is ambiguous with less than minus something :p
<whitequark>
I guess at least you can greedily parse the operator
<mkdir>
emily*
<whitequark>
so it's not context-sensitive
<emily>
(actually VHDL and Haskell are a lot more related, in that they both take syntax cues from Ada)
<emily>
(or maybe Algol? I forget where -- comment syntax appeared, e.g.)
<whitequark>
VHDL is straight up a subset of some old Ada revision, isn't it?
<mkdir>
what are the reg types? the look like variable initializations but the types seem to have indexes like arrays
<emily>
lol ok algol 68 used ¢ comments ¢
<mkdir>
is it defining the parts of the register?
<emily>
for your "two cents"
<mkdir>
emily: I think it was ada
<fseidel>
mkdir: you mean the "posedge rst" line?
<fseidel>
oh
<whitequark>
mkdir: wire and reg in verilog allow you to define multi-bit wires and registers
<emily>
I wonder how Haskell inherited that comment syntax... via Miranda I think, but where did Miranda get Ada inspiration from...? ...but this is super off-topic, sorry >_>
<fseidel>
the reg type is the type which can be assigned in a procedural block
<mkdir>
fseidel: 11 - 14
<whitequark>
the syntax for that is `wire [N:0] foo;` or `reg [N:0] foo;` where N is the width
<whitequark>
so a `wire [31:0] foo;` is a bit like `uint32_t;` in C
<fseidel>
yeah
<whitequark>
`uint32_t foo;` I mean
<fseidel>
* wire N-1:0
<whitequark>
^ right
<mkdir>
what is reg akin to? uint8?
<fseidel>
nothing specific
<fseidel>
reg just means you can assign in an always block
<whitequark>
both wire and reg define a similar kind of entity
<mkdir>
I see what's the difference
<whitequark>
in fact, in SystemVerilog instead of wire and reg you only have one keyword, logic
<fseidel>
wire can be assigned via the "assign" statement
<fseidel>
(this is why we teach SV at CMU, so we can avoid wire/reg confusion)
<mkdir>
SystemVerilog really sounds much better lol
<whitequark>
it's more that Verilog is an atrociously bad language
<mkdir>
so when do you use wire and when do you use reg?
<whitequark>
almost completely unsuitable for defining synchronous logic
<mkdir>
as a rule of thumb (convention)?
<whitequark>
it's not convention
<mkdir>
Why didn't people just stick with VHDL, is it too long?
<whitequark>
there are arbitrary requirements in the standard
<whitequark>
`wire` can be used if you assign that signal using the `assign` statement, and `reg` is used if you assign that signal in an `always` block
<whitequark>
note that `reg` does *not* necessarily result in a register (synchronous storage element) in your design!
<whitequark>
if you assign a `reg` in an `always @(*)` statement you get purely combinatorial logic
<whitequark>
you declare it outside of an `always` block
<emily>
mkdir: I hear Europeans use VHDL a lot!
<whitequark>
and then assign it inside
<fseidel>
and if you assign reg in an always @(*) and forget to assign on a path, you get latches, and those are very bad as whitequark mentioned above
<emily>
at least the first hardware stuff I was exposed to was VHDL via a british researcher, so it probably depends what bubble you're in
<whitequark>
VHDL is still bad, just not as bad as Verilog
<mkdir>
emily: and U.S government labs like DoE
<emily>
I think SystemVerilog dominates in industry though
<whitequark>
and FOSS support for VHDL is nonexistent
<fseidel>
Japan likes VHDL too, so my friend tells me
<mkdir>
so is SystemVerilog the best?
<whitequark>
no. they're all awful.
<emily>
BlueSpec or nmigen might be the best :p
<mkdir>
lol
<emily>
or CLaSH, or...
<fseidel>
I wouldn't say best, but it's certainly the most usable from my experience with the 3
* whitequark
got fed up with bad HDLs and implemented her own
<fseidel>
oh? which HDL?
<mkdir>
whitequark and fseidel, thanks I think understand the wire and reg better now
<whitequark>
there's a bunch of new HDLs like CLaSH or HardCaml or nMigen that avoid all those pitfalls
<emily>
(n)migen
<whitequark>
fseidel: I made nMigen
<fseidel>
oh, I've been looking at normal migen, I'll have to look at nmigen
<whitequark>
it's a ground up redesign of Migen that avoids pretty much all known issues with it
<mkdir>
whitequark: you made a language?
<whitequark>
sure. i'm a professional language designer
<whitequark>
(in the sense that i get paid for doing that)
<fseidel>
I need to break out of my V/SV comfort zone at some point :-P
<mkdir>
ooh, that's 🔥
<whitequark>
it gets boring after fourth or fifth one
<emily>
mkdir: you can make a language too
<mkdir>
What's the process like to create a language?
<emily>
it's a fun activity for the whole family
<mkdir>
write a compiler?
<whitequark>
that entirely depends on the kind of language you want to make
<emily>
come up with guiding principles, derive the necessary abstract components, give them a concrete syntax and semantics, implement them as an eDSL or a standalone compiler or ...
<whitequark>
^
<mkdir>
mmm I'd be interested
<emily>
nmigen is embedded in python, bluespec is a standalone language that's haskell contorted into the shape of systemverilog or something
<mkdir>
to try it as a project
<whitequark>
most new HDLs are embedded in some non-hardware language
<mkdir>
what is eDSL?
<mkdir>
whitequark: are there any performance issues? Like for example how a code runs slower when implemented in a higher level software language
<whitequark>
mkdir: "it depends"
<whitequark>
the short answer is no
<whitequark>
generating logic from Python is not any different than generating logic from Verilog
<mkdir>
Oooh even better
<whitequark>
the long answer is that many of the new HDLs, including nMigen, choose to provide safer defaults at the cost of slightly larger designs
<whitequark>
there are no true FPGA debuggers, so making your design more reliable at a small increase in size is almost always worthwhile
<mkdir>
true I could see that
<fseidel>
(it's worth noting that on-chip logic analyzers do exist, but aren't nearly as powerful as something like GDB/LLDB/IDA)
<whitequark>
(there were some FPGAs that came with real non-intrusive debuggers, like Tabula, but none of them still exist)
<whitequark>
yes. you can insert some additional logic to work as a logic analyzer
<whitequark>
unfortunately, that logic may well perturb your design into working
<whitequark>
it also often makes the design too slow to be usable, or too large to fit into your FPGA...
Miyu has joined ##openfpga
<mkdir>
do people use verilator to simulate and test before loading onto the dpga
<whitequark>
yes.
<fseidel>
I had a DRAM controller get its timing completely fucked by SignalTap years ago
<whitequark>
you *always* use a simulator first.
<whitequark>
(especially if you're just learning)
<whitequark>
in fact, don't use verilator.
<whitequark>
use iverilog.
<mkdir>
oh good to know
<mkdir>
kk
<mkdir>
is it on mac
<whitequark>
both verilator and synthesis tools like yosys take shortcuts with Verilog semantics that match how FPGAs work
<whitequark>
these shortcuts will often hide the brokenness in your design caused by Verilog flaws
<mkdir>
heck yea, I can get iverilog on mac and it has a GNU license
<whitequark>
something like iverilog implements Verilog semantics faithfully and will show those issues in various ways
<mkdir>
coo
<whitequark>
unfortunately, neither iverilog, nor verilator, nor synthesis tools will help you write code that makes sense when synthesized for an FPGA
<whitequark>
you have to know upfront the rules for doing that
<mkdir>
sure, makes sense
<mkdir>
that's why I'm tryna learn
<fseidel>
many of them are clocking related, be VERY careful with what you do with clocks
<whitequark>
to be very clear: if your code doesn't follow the rules for synthesizable designs, it's pretty much like undefined behavior: the synthesis tool can and will silently turn it into something completely broken
<whitequark>
and if you report it as a bug, it will be rejected
<mkdir>
are there good resources? I found some books, but atm I am just trying to learn by implentation
<mkdir>
since I've already read some theory and I am familiar with coding
<whitequark>
I usually read the synthesizable Verilog spec... not exactly an introductory resource
<fseidel>
I TAed a course using "Logic Design and Verification Using SystemVerilog"
<fseidel>
and found it to be a pretty good itnro book
<fseidel>
but that's SV, not Verilog Classic
<mkdir>
cool thanks , I will check out both
<whitequark>
Verilog Classic, more like Verilog Obsolete *hides*
<mkdir>
fseidel: you at CMU?
<whitequark>
(the usual name is Verilog-2005)
<fseidel>
I was for 5 years, recently left
<mkdir>
lmao whitequark
* fseidel
couldn't remember the year, d'oh
<whitequark>
(after Verilog-2005 it got folded into SystemVerilog, so strictly speaking Verilog is no more; there will never be another release of it)
<mkdir>
oh nice, I'm at Dartmouth atm
<mkdir>
yeah I heard that whitequark
<fseidel>
perhaps this goes without saying, but if you have an FPGA course over there, it might be worth taking
<mkdir>
We might, alot of EE these days seems to be focused on Analog
<mkdir>
but there has to be atleast one
<fseidel>
wow, complete opposite at CMU, I guess it's different everywhere
<mkdir>
yeah CMU is heavy digital / CS / AI, it seems but I've only heard from friends
<mkdir>
so I could be wrong
<fseidel>
nah, that sounds about right
<fseidel>
although CS and AI are their own departments separate from ECE (with ML as a department within the school of CS)
<mkdir>
would be better for me tbh, my fpga stuff is directly related to AI
<mkdir>
is AI part of the CS school or it's own school
<fseidel>
the ML department is within the CS school, if that's what you're getting at
<mkdir>
well yeah I guess it sounded like AI and CS were separate but separate departments (not schools)?
<fseidel>
there's a CS department within the CS school... it's weird and confusing, and the labeling sucks
<mkdir>
Dartmouth only has a single engineering school
<mkdir>
I see
<mkdir>
yeah CMU is bigger so they may want to split it more
<mkdir>
IDK
<fseidel>
but all the FPGA stuff is in the ECE department over in the college of engineering, which is where I spent the last 5 years of my life :-P
<mkdir>
Ayy, nice. very cool.
<mkdir>
I'm actually in the Neuro department (AI) which is a pretty large department compared to other universities
<mkdir>
but we collab with the engineering school all the time
<mkdir>
thanks for all the help guys
<mkdir>
much appreciated
mkdir has quit [Ping timeout: 260 seconds]
emeb_mac has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
flea86 has joined ##openfpga
jfng has quit [Remote host closed the connection]
thehurley3[m] has quit [Remote host closed the connection]
indefini[m] has quit [Write error: Connection reset by peer]
kervel has quit [Remote host closed the connection]
xobs has quit [Remote host closed the connection]
nrossi has quit [Remote host closed the connection]
henriknj has quit [Write error: Connection reset by peer]
swedishhat[m] has quit [Remote host closed the connection]
Jybz has joined ##openfpga
Richard_Simmons has joined ##openfpga
nrossi has joined ##openfpga
marex-cloud has quit [Ping timeout: 250 seconds]
Jybz has quit [Client Quit]
Richard_Simmons2 has quit [Ping timeout: 252 seconds]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 272 seconds]
flaviusb has quit [Ping timeout: 250 seconds]
edmoore has quit [Ping timeout: 252 seconds]
flaviusb has joined ##openfpga
nickjohnson has quit [Ping timeout: 250 seconds]
nickjohnson has joined ##openfpga
edmoore has joined ##openfpga
ormiret has quit [Ping timeout: 252 seconds]
vonnieda has quit [Ping timeout: 250 seconds]
vonnieda has joined ##openfpga
ormiret has joined ##openfpga
marex-cloud has joined ##openfpga
Jybz has joined ##openfpga
Asu` has quit [Quit: Konversation terminated!]
Jybz has quit [Remote host closed the connection]
indefini[m] has joined ##openfpga
xobs has joined ##openfpga
thehurley3[m] has joined ##openfpga
henriknj has joined ##openfpga
jfng has joined ##openfpga
swedishhat[m] has joined ##openfpga
kervel has joined ##openfpga
plaes has quit [Ping timeout: 250 seconds]
plaes has joined ##openfpga
pie___ has quit [Ping timeout: 252 seconds]
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
lutsabound has joined ##openfpga
Jybz has joined ##openfpga
<cr1901_modern>
whitequark: Excellent, that means I can knock off the simulator mk2 sometime soon :P?
Jybz has quit [Quit: Konversation terminated!]
Jybz has joined ##openfpga
indy has quit [Ping timeout: 272 seconds]
pie_ has joined ##openfpga
_whitelogger has joined ##openfpga
Maya-sama has joined ##openfpga
Miyu has quit [Ping timeout: 245 seconds]
Maya-sama is now known as Miyu
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
emeb has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
Maya-sama has joined ##openfpga
Miyu has quit [Ping timeout: 245 seconds]
renze has joined ##openfpga
Maya-sama is now known as Miyu
Miyu has quit [Ping timeout: 245 seconds]
Jybz has quit [Quit: Konversation terminated!]
<whitequark>
cr1901_modern: I was thinking about defining the semantics of instructions in the decode tables as well
<whitequark>
and reusing those semantics for the simulator *and* formal model
<cr1901_modern>
whitequark: Whatever works best. As-is, beyond redoing the opcode decoding, the only other thing I had in mind for the simulator was to make the I/O hooks async or something
<whitequark>
cr1901_modern: opcode decoding definitely shouldn't be in the simulator
<whitequark>
well, you'll see once I push the disassembler
<cr1901_modern>
Oh okay I see. I'm implicitly combining the task of "opcode decoding" with the task of "actually implementing the semantics that are deducted from decoding".
mumptai has joined ##openfpga
balrog has quit [Quit: Bye]
emeb has left ##openfpga [##openfpga]
balrog has joined ##openfpga
emeb_mac has joined ##openfpga
mumptai has quit [Quit: Verlassend]
<mithro>
Anyone know the a way to find an ARM MCU with 2-4 * I2C controllers?
<emeb_mac>
there are many like that. what other features do you want?