<vancz>
Do you have any advice to cope with verilog apparently being terrible, while trying to learn verilog? This is terribly demotivating; https://danluu.com/why-hardware-development-is-hard/ "Verilog is weird"
<vancz>
(nevermind that apparently this is another context where "standard" seems to leave a lot on the table)
<whitequark[cis]>
i use amaranth
<vancz>
I'm not even sure why I'm bothering (well, ok the third sentence of this message), I guess it's still the common denominator. Amaranth is probably a good step up, and maybe I will eventually get around to properly trying clash. A project I'm trying to do involves trying to C bind against compiled verilog like verilator or something like that.
<vancz>
Maybe you have a suggestion for this? Whats the most beginner friendly way to talk to compiled verilog from C code? It seems like verilator and cxxrtl (or what was it?) are both C++
<whitequark[cis]>
i use cxxrtl :)
<whitequark[cis]>
oh, cxxrtl has a c api
<whitequark[cis]>
it's written mostly for FFI purposes but is quite easy to use manually
<vancz>
At this point I'm kind of cached/committed to using verilator (no particular reason), I guess I should convince myself to go for cxxrtl instead.
<whitequark[cis]>
it's slower to compile but nicer to use than verilator
<whitequark[cis]>
more or less
<vancz>
I somehow managed to get terrible compilation speed for trivial code with verilator. I haven't had a chance to figure out what was going on.
<vancz>
10 seconds or something.
<vancz>
So I guess everyone compiles down to a known working subset of verilog?
<vancz>
hm, or just directly to netlists
<Wanda[cis]>
hmm.
<Wanda[cis]>
I should definitely write an HDL
widlarizerEmilJT has joined #prjunnamed
<widlarizerEmilJT>
The more the merrier
<whitequark[cis]>
what kind of HDL?
<Wanda[cis]>
idk
<Wanda[cis]>
something boring and uninspiring. just, you know, not verilog.
<Wanda[cis]>
in all seriousness
<Wanda[cis]>
I was thinking of doing something like that as warm-up for verilog (and/or vhdl) frontend
<Wanda[cis]>
define a language with roughly the featureset of synthesizable verilog except less batshit, so I can experiment and iterate on the design of the frontend without actually having to deal with the major annoyances
<Wanda[cis]>
then port it to actual verilog once I feel ready to commit to the design
leocassarani[m] has joined #prjunnamed
<leocassarani[m]>
Do you think you'd want to tackle that before or after pnr?
<Wanda[cis]>
it's one of the things that are tempting me to start on them immediately
<Wanda[cis]>
but no
<Wanda[cis]>
after pnr; we're already committed to doing pnr next, and the only thing I'm delaying it on is the prjcombine-siliconblue work
<Wanda[cis]>
which is, obviously, a hard dependency
<Wanda[cis]>
(and a bunch of general prjcombine cleanups)
<whitequark[cis]>
<Wanda[cis]> "define a language with roughly..." <- thought so
<whitequark[cis]>
reminds me of s-expressions
<vancz>
(i have no idea what im talking about) doesnt the insanity of verilog originate from that there isnt a good mapping from arbitrary procedural code to to arbitrary primitives? this sounds patently false on the surface though and i guess the implementations just suck?
<vancz>
my experience with verilog so far is all of a week of trying to slog through the sutherland rtl modeling book
galibert[m] has joined #prjunnamed
<galibert[m]>
maybe an issue with system verilog is that the grammar (not the semantics) is 2000 lines by itself
<galibert[m]>
verilog is what you get when the comittee has sub-comittees
<vancz>
ha
<Wanda[cis]>
there's multiple problems with verilog
<Wanda[cis]>
one of the core ones is that it's an imperative programming language for writing simulation testbenches that is (badly) reused for synthesis, and doesn't quite keep the same semantics when used that way
<vancz>
(I didnt look into it but i think i saw something about an llvm IR for hdl)
<galibert[m]>
ascii and lsb-first from what I'm reading?
<Wanda[cis]>
vancz: and you never will! there isn't one.
<vancz>
lol damnit
<Wanda[cis]>
when you write a string, it's just interpretted as a bitvector
<vancz>
and here i wanted to hardcode some strings
<Wanda[cis]>
as if it was literally a base-256 number
<Wanda[cis]>
which means that characters are indexed starting from the end of the string.
<vancz>
i mean...whats the alternative
<vancz>
ah, lol
<Wanda[cis]>
the verilog standard has a section that tells you how to use normal HDL operators to do string operations.
<vancz>
i havent learned my terminology yet, i know theres the two different indexes, but doesnt the order depend on the order specified in the type? of course if strings just go with the given order then thats that
<Wanda[cis]>
then it has another section, which tells you that lol this doesn't actually work, strings are just completely fucked
<vancz>
amazin
<Wanda[cis]>
can recommend IEEE 1364-2005 section 5.2.3.2
<vancz>
they might as well have just not put it in the standard
<Wanda[cis]>
vancz: yeah you can change whether the index goes up or down and also what it starts from
<Wanda[cis]>
but this doesn't actually change anything
<vancz>
i happen to want a little bit of strings but is there a real use case for strings in hdl
<Wanda[cis]>
because when you assign a string to a variable or parameter or whatever, it is still right-aligned
<Wanda[cis]>
so your options are "you index from the right starting at index 0" or "you still index form the right but the starting index is the size of your container, not size of the string"
<Wanda[cis]>
you'll note that both are useless.
<Wanda[cis]>
vancz: parametric modules, mostly
<galibert[m]>
I see, concatenation doesn't
<Wanda[cis]>
that plus testbenches, but then it's a mistake to use the same language for sim anyway so let's not speak of that
<Wanda[cis]>
I mean, you could also use stuff like enums for parametric modules instead of strings. that'd be objectively better
<Wanda[cis]>
except uhh.
<Wanda[cis]>
guess what my next complaint is going to be about
<vancz>
from what i hear the synthesis vendors tools arent too good so i guess its not exactly surprising that the standard dost not spark joy
<galibert[m]>
Danm I forgot the popcorn
<vancz>
oh no enums are bad? :(
<Wanda[cis]>
there are no enums. easy.
<galibert[m]>
they're not that bad, they just have a user experience that makes unix feel friendly
<vancz>
galibert[m]: enums or the tools
<Wanda[cis]>
I mean I spent the morning fixing bugs in a vendor toolchain with a hex editor, I'm definitely not going to call them good.
<galibert[m]>
the tools
<galibert[m]>
not that bad does not in any way mean good
<vancz>
Wanda[cis]: hardcore
<vancz>
do uh tell?
<Wanda[cis]>
I complained about it on the other channel
<Wanda[cis]>
(the other channel being #prjcombine:catircservices.org / #prjcombine)
<vancz>
i succeeded at making the logical leap
<vancz>
for once
<vancz>
in slight defense of the verilog implementors, i guess they would need to be experienced and good at both compilers and at hardware
<vancz>
and thats just expecting too much? :PP
<Wanda[cis]>
I mean, isn't that literally their job description
<whitequark[cis]>
lmao
<vancz>
are there any good places for noob questions or might i as well ask here
mei[m] has joined #prjunnamed
<mei[m]>
ask, worst case we redirect you with the additional context of what your question actually is
<vancz>
I dont really get the whole blocking/nonblocking assignments thing. Is there anything _good_ to read on this?
<vancz>
also the thing about unintended inferres latches seems to make sense to me but but i do not feel confident about it
<vancz>
thats probably exacerbated a bit by lack of experience in digital design
<Wanda[cis]>
so you know how the core problem with verilog is that it's a simulation language?
<vancz>
apparently
<Wanda[cis]>
the blocking/nonblocking assignment mess is a direct result of that
<vancz>
oh. so this has nothing to do with hardware?
<Wanda[cis]>
it makes more sense if you think of the whole thing from the "how would you write a simulator" point of view
<Wanda[cis]>
correct. there is no such thing as a blocking or non-blocking assignment in hardware.
<vancz>
and well, hardware description either?
<vancz>
i guess im veering in the direction of things like "syntactic sugar" does not show up in the end result
<vancz>
its just event model shenanigans?
<Wanda[cis]>
it's not syntactic sugar, it's a direct consequence of verilog not being designed for synthesis (or, not competently so at least)
<vancz>
(well apparently this still has to have an effect on the inferred hardware otherwise it wouldnt be a problem)
<Wanda[cis]>
so first, think of the actual hardware you're trying to model
<vancz>
i guess im already doing that yeah, danluu said as much as well x')
<Wanda[cis]>
vancz: it doesn't! it has an effect on the simulation though. causing what is known as simulation-synthesis mismatch, which you do not want.
<vancz>
(im sorry this feels frustratingly f'ing stupid, i know everyone thinks this but im still going to complain a little about it)
<vancz>
why do i have to reverse engineer my shit into a description language instead of just writing it down
<vancz>
anyway
<Wanda[cis]>
the synthesizer will not care whether you used as blocking or non-blocking assignment, beyond maybe emitting a warning, because it doesn't have any means of realizing that stuff
<vancz>
aha
<vancz>
sounds to me like the solution is to simulate the result of synthesis xp
<vancz>
i imagine thats bad for perf for big designs
<Wanda[cis]>
depends on how you do it
<Wanda[cis]>
if you use something like cxxrtl? it's quite damn efficient
<vancz>
im so spoiled by modern softare tooling
<Wanda[cis]>
mostly because it doesn't actually synthesize all the way, just goes through the verilog frontend
<vancz>
neat
<vancz>
a third thing, why do functions exist given modules exist? i guess one is intended for describing hardware the other is intended for behavioral stuff, but the hybridization of verilog makes it funky? or is it a code factoring thing?
<Wanda[cis]>
functions have different uses
<Wanda[cis]>
for one, you can const-eval them
<Wanda[cis]>
ie. you can use a function call when computing a module parameter and similar stuff
<Wanda[cis]>
also, well, functions can be convenient when you write procedural code, yes
<Wanda[cis]>
this includes actual synthesizable stuff too
<Wanda[cis]>
(as a side note, spade also has functions, despite not being designed like verilog/vhdl at all; they're kinda like modules that can only do combinational logic)
<vancz>
sooo...space is a rust hdl edsl?
<vancz>
spade
<Wanda[cis]>
it's not an edsl
<Wanda[cis]>
it's kinda just ... a rust-themed hdl
<vancz>
aha
<vancz>
is there any cultural context for this or did someone just go and do a rust flavored hdl
<Wanda[cis]>
shrug
<vancz>
"Frans Skarman Spade - An HDL Inspired by Modern Software Languages. " ok sure
<vancz>
im down
<Wanda[cis]>
I'm not sure I actually understand spade's niche
<Wanda[cis]>
I kinda found it... not very inspiring?
<Wanda[cis]>
like, yeah, someone sat down and made a rust-themed HDL, and that seems to be its appeal
<vancz>
well, "apply good software development methodology tooling to X design domain" sounds good on the tin
<Wanda[cis]>
and having an actual type system and modern practices applied to an HDL already puts you ahead of the curve in many ways
<vancz>
tooling is (not good) ass, what if not (not good) ass
<Wanda[cis]>
but then you start thinking about actually using it for larger projects
<vancz>
though you may then ask how its better than any of the other attempts, and i ugess thats how you get to your current point?
<Wanda[cis]>
and you run into the problem of its generics being not very good
<Wanda[cis]>
or const-eval, which, kinda the same thing
<vancz>
well, my impression is that apparently writing a good type system requires big brain so ok its not as easy as just throwing together another imperative language
<vancz>
get a phd in math *shrug* ?
<Wanda[cis]>
that's the one thing that makes amaranth ridiculously good, to the point of making it near-impossible to compete with it
<vancz>
or lurk a lot?:
<vancz>
s/://
<Wanda[cis]>
your const-eval system is just python.
<vancz>
thats the difference between using code to describe rtl and inferring rtl?
<Wanda[cis]>
kinda
<vancz>
(havent used amaranth but unless wq also does some fancy python overloading to build stuff from ...id call them traces but thats probably not the right term? , i guess thats what happens?)
<Wanda[cis]>
oh it has some overloading alright
<vancz>
haha
<Wanda[cis]>
but it doesn't attempt to make HDL look like actual python code
<Wanda[cis]>
you don't write "python that's compiled to hardware". you write python that builds hardware.
<vancz>
yeah i think thats what i was trying to say
<Wanda[cis]>
this results in a bunch of annoying boilerplate, but it's also incredibly powerful
<vancz>
every (?) alternate hdl does that
<vancz>
I havent looked into HLS at all
<Wanda[cis]>
every? oh come on
<Wanda[cis]>
spade doesn't, for one. and that is my core complaint.
<vup>
Wanda[cis]: wait, what do you mean by the synthesizer does not care wether you used blocking vs non-blocking assignments. If you read from a register you previously did a blocking assignment to it get synthesized to something different than if that previous assignment would have been nonblocking, no?
<vancz>
i do wonder about pulling up some hls on top of clash with haskell shenanigans heh, but thats a long way down the road
<vancz>
Wanda[cis]: ok noted
<vancz>
bbiab need to eat apparently..... bodies do that
<vancz>
hrmblgrmbl
<Wanda[cis]>
it's not an edsl that you can build via rust code, it's just... some rust-themed custom thing
<Wanda[cis]>
vup: ... ah yeah, in that particular case, yes
<Wanda[cis]>
I was thinking of the cross-process case, my bad
<vup>
ah right, makes sense
<vancz>
i will just have to shoot myself in the foot several times and waste a lot of time, then maybe i will understand
<vup>
yeah the cross process parts of verilog really suck
<vancz>
ok so yeah back to the blocking/nonblocking...what actually do i need to understand here...
<vancz>
(btw does anyone have a take on TL-verilog?)
<vup>
vancz: I feel like this statement probably doesn't help you, but with a non blocking assignment, any reads to the variable in the same process will get the old value, with a blocking assignment you get the value of that assignment for reads "after" (ie the statement comes after that write statement)
<vancz>
that...sounds like deciding whether to take input from an incoming port or from the result of an operation?
<vup>
yeah kind of. Doesn't have to be a port though. Just, do you get the output of the flip flop, or do you read the output of some combinatorial logic connected to the output of the flip flop
<Wanda[cis]>
except that's not what you should be thinking of at all
<vup>
ie consider maybe something like this
<vup>
```
<vup>
module a(input wire clk, rst_n, a, b, output int num);
<vup>
always_ff @(posedge clk or negedge rst_n) begin
<vup>
if (~rst_n) begin
<vup>
num <= 0;
<vup>
end else begin
<vup>
if (a) num = num + 1;
<vup>
if (b) num = num - 1;
<vup>
end
<vup>
end
<vup>
endmodule
<vup>
```
<vup>
this results in `num` containing the delta of the number of clock cycles that a and b were high.
<vup>
Now if you swap the assignments non blocking ones this increments `num` if `a` is high and `b` is not and decrements whenever `b` is high (regardless of wether `a` is high
<Wanda[cis]>
dear gods no
<Wanda[cis]>
this code should never be written like that, end of story
<vup>
lol
<Wanda[cis]>
this is asking for a disaster
<galibert[m]>
Requiring more than asking
<galibert[m]>
Please insert a disaster here, kthnx
<Wanda[cis]>
see, this is the problem with verilog. the code above is nondeterministic and will just fuck you up some day without you even knowing what hit you or where.
<Wanda[cis]>
you are using a process to model a flop. you even use the always_ff systemverilog construct to confirm that is your intention. and then you just write something that doesn't behave like a flop at all.
<Wanda[cis]>
so consider how a flop works. when there is a clock edge, every flop in your design that uses that clock will instantly get a new value computed from the old values of all other flops involved (and whatever primary inputs you have).
<Wanda[cis]>
that is the only thing you can actually create in hardware
<Wanda[cis]>
now consider how the blocking and non-blocking assignments work
<Wanda[cis]>
the = assignment executes the assignment now. the variable will read as the new value from now on for every statement executed, whether in this process or another
<Wanda[cis]>
but the `<=` assignment *schedules* the assignment to happen when the simulator is done with all the currently pending tasks, and the variable will continue to have the *old* value for everything that's still in the pending task queue
<Wanda[cis]>
(well, one of the queues; I'm simplifying a little bit, but basically all processes that got kicked off from this same clock edge)
<Wanda[cis]>
if you use the `<=` assignment to model synchronous logic, you get something that *works*, because it happens to match what happens in hardware (everything looks at the old value while computing the new value)
<Wanda[cis]>
but if you use =, and there is another process that reads num in the above example (and I presume there is one, since num is an output), that other process will see... well, it depends
<Wanda[cis]>
if the other process gets scheuled before the example process, it reads the old value; if it gets scheduled after, it gets the new value.
<Wanda[cis]>
and scheduling processes in verilog is non-deterministic. hence, the above code is a disaster waiting to happen.
<vup>
ah well true, making it an output is really not good. I just made it one to avoid yosys removing the logic
<Wanda[cis]>
thank you for illustrating the point of verilog being garbage.
<Wanda[cis]>
so. the rule is.
<Wanda[cis]>
*always* use `<=` when assigning to something that is a flop (ie. is an output from a clocked process), or you get fucked over
<vup>
consider my new and refined example :P
<vup>
```
<vup>
always_ff @(posedge clk or negedge rst_n) begin
<vup>
int new_num;
<vup>
module a(input wire clk, rst_n, a, b, output int num);
<vup>
if (~rst_n) begin
<vup>
num <= 0;
<vup>
end else begin
<vup>
new_num = num;
<vup>
if (a) new_num += 1;
<vup>
if (b) new_num -= 1;
<vup>
num <= new_num;
<Wanda[cis]>
use = for temporary variables that are only ever read within a single process
<vup>
end
<vup>
end
<vup>
endmodule
<vup>
```
<Wanda[cis]>
vup: stop
<Wanda[cis]>
if you insist on using irc, use a pastebin or something
<vup>
sorry
<Wanda[cis]>
... and continuing the rule
<Wanda[cis]>
use = for combinational processes (ie. always_comb / always(*))
<Wanda[cis]>
and for latches, you should.... well, you should not use latches, preferably
<Wanda[cis]>
if you must, I think `<=` was the correct one
<galibert[m]>
Also in general it’s not a good idea to leave what happens when both a&b are true non-explicit
<vancz>
reading backlog obv i need to catch up -, this is whats wrong with verilog, well intentioned experts and then the immediate reaction of "this is requiring disaster"
<vancz>
and well there we go<Wanda[cis]> thank you for illustrating the point of verilog being garbage.
<vancz>
i read the section on the combined assignment operators in my book and i was like ok im not going to understand this i should just not use it at all <vup> consider my new and refined example :P
<vancz>
*im not going to understand the nuances of this
<vancz>
im going to have to reread the scroll a few times.
<vancz>
regarding verification, which people say is most of the effort and RTL design pain is negligible in comparison, is there any wisdom or development regarding this?
<vancz>
i imagine it helps if you arent introducing bugs that take debugging time due to bad tooling
<vancz>
i guess maybe thats less important if you are a big company idk
<vancz>
Wanda[cis]: sounds like one needs to understand how simulation works to get a better idea of how tools intend to translate to hardware? meh...
<Wanda[cis]>
mhm
* vancz
groans
<Wanda[cis]>
or just don't use verilog; it's a perfectly cromulent option for hobbyist purposes
<Wanda[cis]>
(the calculus changes a lot if you want to land a job at an established hardware-making company)
<vancz>
right
<Wanda[cis]>
as for verification
<Wanda[cis]>
that's a question of what you're making and your methodology
<vancz>
well i admit i did a 30 second search for synopsys and mentor graphics sweng salaries earlier
<vancz>
though that could be anything, if id bothered i would have tried looking harder for compiler engineering stuff
<Wanda[cis]>
writing a glasgow applet? just hack this shit up and if it works it's good, we can push a bugfix later
<Wanda[cis]>
manufacturing an ASIC? you better be damn sure this thing works before you pay a few million
<vancz>
i was thinking the latter, but i see
<widlarizerEmilJT>
<Wanda[cis]> "like, yeah, someone sat down and..." <- The Rust theme is not the draw to me. I tried it for AoC and I liked some non-unique things about it - that the arithmetic is super explicit for discarding bits, that it really pushes you away from an imperative approach towards a structural one making use of its type system. I didn't write anything significantly complex in it so of course make of that what you will
<Wanda[cis]>
(note: when manufacturing an ASIC, it is in fact customary to not get this thing to work on the first try)
<galibert[m]>
Wanda: I know people who just wing it by lack of time in a project, but they’re crazy experienced
<galibert[m]>
The alternative was not having the chip before the end of the project, so…
<galibert[m]>
I’ll never forget the « I simulated it in my head»
<widlarizerEmilJT>
<Wanda[cis]> "this results in a bunch of..." <- I'm over caring about syntax as long as the syntax is consistent
<mupuf>
Wanda[cis]: Go tell Intel they need to be damn sure the ASIC would work before committing 🤣 Back when I was there l, we had like ten steppings before shipping the damn thing 🤣
<mupuf>
Contrast that with NVIDIA that ships consistently A0, with sometimes a minor hickup fixed in A1... Night and day experience!
<widlarizerEmilJT>
Get real, all of these companies have top talent. Anandtech news and gamerbro tech explainer commentd are detached from reality so often
<widlarizerEmilJT>
Oh I misread your message entirely. I'm not running on too much sleep today
<vancz>
how _did_ you read it? xD
<vancz>
(at this point i would be satisfied if i counted as mediocre talent....but i still wouldnt like to work at a company where all the processes are shit
<vancz>
)
<mupuf>
but nvidia does co design and high level synthesis when Intel is writing verilog, using a lot of copy paste, having a separate implementation of RTL and the simulator based on a spec, and super limited emulation time
<widlarizerEmilJT>
I think I have a condition where I gloss over anything with too many emojis and my brain autofills it
<Wanda[cis]>
it was ... two
<vancz>
twoo many
<Wanda[cis]>
hmm
<Wanda[cis]>
I should write with more emoji 💙✨😼
<vancz>
its been a few years but didnt intel fire their entire (half?) verification team at some point
<Wanda[cis]>
okay no I should no, gods is using the picker slow
<galibert[m]>
GPUs have it somewhat easier, you never program them directly so the driver/compiler can do unspeakable things
<widlarizerEmilJT>
anyway, incidentally, I've been wrestling MLIR so that I can create an RTLIL dialect, hence my degraded sanity. I hope you understand
<vancz>
I know I'm not the benchmark here but I believe Ive established that I have low expectations ;) <Wanda[cis]> I mean, isn't that literally their job description
<widlarizerEmilJT>
Anyway, back on topic. Wanda, you mentioned the next step is pnr, got any notes for what your approach is?
<widlarizerEmilJT>
It does, if it's up to date - I'm interested in which placer and router algorithms you want to try out
<Wanda[cis]>
oh, mostly just copy whatever shit nextpnr implements for a start
<Wanda[cis]>
though I think Catherine has a somewhat more detailed plan based on discussions with gatecat ?
<whitequark[cis]>
<vancz> "regarding verification, which..." <- if your design language isnt worth shit of course you will spend all your time verifying it
<vancz>
hooray for correctness by construction
<whitequark[cis]>
thats part of it, but also like verilog doesnt have libraries
<whitequark[cis]>
it has "i pee"
<whitequark[cis]>
and they are very limited in how they're integrated and tested
<vancz>
i was reminded of the question because i ran across the term "verification eye pee"
<Wanda[cis]>
mmm eye pee
<vancz>
lizards shooting blood out of their eyes . gif
<vancz>
using the function name for the return value is so weird
<vancz>
does this originate in some fucked up comiler hack
<vancz>
or i guess trying to save memory on really old computers
<whitequark[cis]>
it originates in fortran iirc? or algol?
<vancz>
huh.
<galibert[m]>
It wasn’t pascal?
<vancz>
"If the multiply operator ( * ) had been used in Example 7-2, synthesis compilers could map the operator to the most efficient multiplier implementation for a specific target ASIC or FPGA." well thanks but at this point im so afraid of doing anything other than directly implementing logic,...
<vancz>
meant to ask this here;
<vancz>
well, doing part of the synthesis tool's job manually basically
<vancz>
is it a thing for people to write hdl based on their own primitive library, and then retarget their model to different hardware by reimplementing the library
<vancz>
so idk, having a generic adder module and then for one target implementing a ripple carry adder and for another target using built in addition primitives, idk
<whitequark[cis]>
this does sometimes happen
<whitequark[cis]>
much less so recently
<galibert[m]>
I’d say adder no, multiplier is iffier
<vancz>
how the hell am i supposed to read procedural code
<vancz>
unrelated; so...a non-total case statement will infer a latch, but "unique" will, besides removing priority behavior...also not require totality and will _not_ infer a latch?
<vancz>
"For synthesis, the unique decision modifier indicates that every case item expression will have a mutually exclusive, “unique” values, and therefore the gate-level implementation can evaluate the case items in parallel. The unique modifier further informs synthesis that any case expression values that were not used in the case state ment can be ignored. This can trigger synthesis optimizations that reduce gate counts and propagation paths, but these
<vancz>
optimizations might not be desirable in some designs. The synthesis effects and best practice guidelines for using unique are discussed in Chapter 9, section 9.3.5 (page 340)."
<Wanda[cis]>
hmm that sounds wrong
<Wanda[cis]>
ah no, unique does that, yeah
<Wanda[cis]>
it's the combo one
<Wanda[cis]>
well.
<Wanda[cis]>
excellent question, honestly
<Wanda[cis]>
unfortunately, it cannot be answered, because there is no systemverilog synthesis standard
<Wanda[cis]>
most likely, given a somewhat reasonable implementation, unique will indeed force no latch
<Wanda[cis]>
unique does two different things because it's actually the combination of two separate modifiers, unique0 and priority
<Wanda[cis]>
unique0 removes priority behavior, priority considers the fallthrough case impossible
<Wanda[cis]>
the names are unhinged.
<Wanda[cis]>
plain verilog has these two things as (* full_case *) and (* parallel_case *), which are actually somewhat better named and actually have specified synthesis behavior, except they're also more unhinged because they're completely ignored by simulation, providing an excellent way to fuck yourself over.
<widlarizerEmilJT>
That's impressively chaotic
<Wanda[cis]>
see, there are many reasons why I consider verilog to be hostile hateful pile of garbage
<Wanda[cis]>
so many I can't remember them all
<widlarizerEmilJT>
I would prefer if they used random strings instead. Just like for "reg"
<vancz>
real world engineering without being neurotically aesthetic and having principles as attractors will do that to you i think
<Wanda[cis]>
and there's like 10× as many reasons why I consider systemverilog to be gargantuan hostile hateful pile of garbage
<vancz>
oh no
<vancz>
and here i thought i was being a good boy learning sv
<Wanda[cis]>
so.
<Wanda[cis]>
sv is .... indeed better, by some metric
<Wanda[cis]>
in that it contains solutions to some verilog problems
<vancz>
though i can easily understand how a bigger language will lead to quadratic chaos, especially if its more of the same
<Wanda[cis]>
it is the exact same gender of language design as c++. in fact, systemverilog is to verilog exactly what c++ is to c. or what lung cancer is to lung.
<vancz>
lmao
<Wanda[cis]>
you know how c++ "fixes" many C problems by providing you with several times as many ways to do things, inventing a lot of new footguns, and also keeping all the original footguns for compatibility? that is systemverilog.
<vancz>
can i at least hope that verilog is worse than C on its own scale?
<widlarizerEmilJT>
Good simile, both lung cancer and systemverilig create big consolidated market segments selling products for coping
<vancz>
lmfao
<widlarizerEmilJT>
The C standard is fairly pleasant
<Wanda[cis]>
I can't claim to have come up with it, unfortunately. comes straight from the UNIX-HATERS handbook.
<Wanda[cis]>
I wish that book was more outdated.
<vancz>
i havent doen any serious engineering with it, though i have been trying to work on the qemu codebase a bit, im starting to think C isnt that bad? (oh no?) thoguh there is a lot of tooling these days
<vancz>
on the other hand the minimalism means that qemu implemented its own object oriented system, which has its own issues
<vancz>
ok yeah true id like a more expressive type system
<Wanda[cis]>
yeah systemverilog does have a .... serviceable type system
<vancz>
and i havent run into arcana recently since ive been reading it more than writing it
<Wanda[cis]>
... do you know how to write a parametric struct type in systemverilog, by the way?
<Wanda[cis]>
it's absolutely hilarious.
<vancz>
if the book mentioned it i dont remember so id have to look it up
<Wanda[cis]>
see, you cannot have generics in struct definitions
<Wanda[cis]>
so, you cannot.
<Wanda[cis]>
or at least not directly
<vancz>
my wild guess is struct defined in parametric module?
<vancz>
(is that a thing?)
<Wanda[cis]>
you can have generics in class definitions. but classes are completely different from structs.
<vancz>
i also recall something about a class system actually
<vancz>
oh yeah there we fucign go lol
<vancz>
book hasnt even talked about classes, "by the way this is how you parametrically define a struct, with classes"
<Wanda[cis]>
so you nest a struct definition within a parametric class definition, and just never instantiate the class
<vancz>
(the book is weird with pacing tbf)
<vancz>
i think i saw this yesterday
<Wanda[cis]>
is it synthesizable? who the fuck knows, there is no such thing as synthesizable systemverilog defined anywhere
<vancz>
wonderful that they dont even try
<vancz>
as if that was not the entire fucking point
<Wanda[cis]>
classes are definitely wildly non-synthesizable as soon as you actually instantiate one
<Wanda[cis]>
but there's no reason to disallow just defining one, so maybe?
<vancz>
why is there even oop
<vancz>
i imagine sv doesnt just go and define its own c++
<Wanda[cis]>
same about generic functions, btw. just add static methods on a class.
<Wanda[cis]>
vancz: it does literally that.
<vancz>
are these some kind of structural definitions which then go and shell out to real c++ code for behavioral modeling or something?
<Wanda[cis]>
or... idk, something like a cross between c++ and java and its own secret third thing?
<Wanda[cis]>
it's not interoperable with c++, no
<vancz>
what the fuck
<vancz>
id understand if they just wanted to go and use c++
<vancz>
thoguh even then youd do the standard thing of just going through C ffi however painful that is
<Wanda[cis]>
but it's the whole oop shebang. inheritance, virtual methods, java-like interfaces, public/private/protected fields.
<vancz>
that is so fucking niche the bugs must be amazing
<vancz>
does this have something to do with HLS
<Wanda[cis]>
it's not synthesizable
<vancz>
or is it reall y just for simulation
<vancz>
ok
<vancz>
but whyy
<Wanda[cis]>
like.... you're definitely not going to synthesize a java-like object model and a GC, come on
<Wanda[cis]>
(oh. right. there's GC. I forgot to mention.)
<vancz>
programming languages are fun and al but people need to stop putting their own _shitty_ executions of programming language implementation into tools?
<vancz>
Wanda[cis]: i mean, ok its a programming language, why not?
* vancz
mumbles something about regulatory capture
<Wanda[cis]>
it's far from the most unhinged part of the sv standard, btw.
<Wanda[cis]>
classes are at least... implementable, if I was writing a simulator
<vancz>
whats unhinged if i give up on it needing to be synthesizable or amenable to any form of static analysis
<vancz>
(sure, the second half is letting through a bit more snark than necessary)
<Wanda[cis]>
for the real unhinged shit, see constrained random generation. also whatever the hell covergroups are about. and SVA while we're at it.
<vancz>
we have "OOP language" at home
<vancz>
i have seen named the first two of those three concepts
<Wanda[cis]>
it's what puts sv firmly into the non-implementable category
<vancz>
hard because weird semantics or hard because underspecced
<Wanda[cis]>
yes
<vancz>
random test case generation and assertions dont sound hard superficially speaking...
<Wanda[cis]>
"yeah just stuff an SMT solver into your simulator capable of doing whatever the user might ask for, and also make it find solutions with a uniform random distribution"
<vancz>
lol ok
<Wanda[cis]>
actually not uniform. you can specify weights.
<vancz>
i guess traCTABILITY IS LEFT UP TO THE USER
<vancz>
whoops
<vancz>
i know its not this easy but i mean yeah i guess just shove z3 in there and then run your models on a couple thousand cores at 1000$ per core license or whatever :P
<vancz>
whats the problem
<vancz>
solvers are magic
<vancz>
the rest of the problem is for the solver engineers
<Wanda[cis]>
there's also the "sample from this particular weighted random distribution" part
<vancz>
yeah thats weird
<vancz>
does anyoen actually implement both of those simultaneously, did they throw that in for the lols
<whitequark[cis]>
<vancz> "i know its not this easy but i..." <- only 1k per core? wow
<whitequark[cis]>
nobody would sell it that cheap
<vancz>
i just made some shit up
<vancz>
naturally
<vancz>
its funny because that was the number i picked to try not to be embarrassingly high
<vancz>
for that kind of money i find it hard to believe people cant make their own hdl in house with blackjack and hookers
<vancz>
but then theres all the other infra like the collaboration with fabs on their technology integration and idk?
<widlarizerEmilJT>
<Wanda[cis]> ""yeah just stuff an SMT solver..." <- oh my god what
<vancz>
its insane that there is a whole separate verification methodology step just to make sure that the compiler gave you what you expected it to
<vancz>
its not completely insane because compiler bugs exist even in programming buz geez
<vancz>
but
<vancz>
youd thin theyre afraid of improving the tooling because people would become less rigirous and start losing money on untested ahrdware
<ignaloidas>
> "also make it find solutions with a uniform random distribution" there are tools for that, but god, that's quite a painful thing to just throw in
<_whitenotifier>
[prjunnamed] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-77-062d47fe8a3ba5c84db8c576877efeca369f3587 - https://github.com/prjunnamed/prjunnamed
<vancz>
i imagine they had an existing solution and then had that standardized?
<ignaloidas>
I'm far from certain that the solution was a thing on SV release time to be honest
<Wanda[cis]>
I'd expect something else
<Wanda[cis]>
ie. that they had a partial solution
<Wanda[cis]>
or several competing partial solutions
<Wanda[cis]>
and the standardization process decided to describe this shit as vaguely as possible to avoid committing to anything, and effectively required something that has never been implemented
<ignaloidas>
but certainly a very developing field then
<ignaloidas>
and still quite active these days tbh, there's already a paper on fast generation using GPUs that's from this year
<ignaloidas>
oh, wait, misread the year, it's 2002
<ignaloidas>
but in the references there seems to be some older works exploring the same concepts
<whitequark[cis]>
<Wanda[cis]> ""yeah just stuff an SMT solver..." <- hold the fuck on what
<whitequark[cis]>
that's not ... a thing
<whitequark[cis]>
that's not, like, how SMT solvers work
<galibert[m]>
Reality is not a criteria
<whitequark[cis]>
jix: do you happen to have context for that particular questionable combination of decisions in SV?
<galibert[m]>
It's systemverilog you're talking about
<Wanda[cis]>
have I mentioned I consider systemverilog to be completely unimplementable?
<jix>
nope, but several competing partial solutions sounds very plausible to me
<ignaloidas>
there are solutions these days that work semi-decently, but AFAIK good ones are limited to SAT and are still slow
<jix>
you can get a decent speedup if you don't need any theoretical guarantees of uniformness (i.e. close enough in practice is good enough)
<jix>
that's the cmsgen approach
<ignaloidas>
oh, yeah, guaranteed uniform is insanity, pseudo-uniform should be enough for this stuff
<jix>
then there are notions that are not exactly uniform but allow you to get arbitrary close to that if you're willing to pay for it, that's the unigen/approxmc approach
<jix>
and then there's guaranteed uniform which is more or less equivalent to exact model counting iirc, at that point it's probably faster to just do full formal verification of whatever you want to test with random samples
<jix>
if the solution space is sufficiently well connected using a suitable metric *handwaving* there might also be something markov chain monte carlo based?
<Wanda[cis]>
psst it's not even uniform, the constraints can also assign weights to parts of the solution space
<jix>
yeah but reducing nonuniform to uniform is the easy part in all of this
<Wanda[cis]>
oh have I mentioned that constraints are defined on classes? it's also tied up with the OOP stuff, you can have virtual and pure virtual constraints 🙂
<jix>
(assuming your sampler does support projected sampling, which might not be the case for everything I mentioned)
<jix>
(or whatever the corresponding thing to projected model counting is for sampling, I only know this stuff because I'm interested in model counting but that's so connected to sampling)