<azonenberg_work>
personally, i would like a synthesis pass that finds latches and errors on them
<whitequark>
azonenberg_work: yosys has that
<azonenberg_work>
or even an argument to "proc"
<azonenberg_work>
oh?
<whitequark>
read_verilog -nolatches
<azonenberg_work>
ooooh i need to do that
<whitequark>
(* nolatches *) also works
<whitequark>
on module or process
<azonenberg_work>
"usually latches are synthesized into logic loops this option prohibits this and sets the output to 'x' in what would be the latches hold condition "
<whitequark>
azonenberg_work: >Conditionals that can never be true due to width mismatch (e.g. checking a reg[3:0] against 31)
<whitequark>
this is not illegal for synthesis and is perfectly valid in generic code
<whitequark>
e.g. imagine a register file that can be instantiated at half size and full size
azonenberg_work has quit [Ping timeout: 250 seconds]
<whitequark>
azonenberg_work: anyway, i might be open to implementing this on consulting basis (since i don't use verilog i see no need in this personally, but i know that part of yosys reasonably well)
<gruetzkopf>
it's consultants all the way down
<qu1j0t3>
hehe
Bike has joined ##openfpga
<sorear>
I’m not convinced that transforming latches into combinational loops at that phase is actually correct
<whitequark>
sorear: at which phase?
<sorear>
read_verilog
<whitequark>
it doesn't do that
<whitequark>
it doesn't even convert them to comb loops, now that i look closer
<whitequark>
it's that read_verilog emits something that proc_dlatch converts to latches
dj_pi has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
emeb has quit [Quit: Leaving.]
unixb0y has quit [Ping timeout: 244 seconds]
unixb0y has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<azonenberg>
whitequark: yes, i'm aware - that's why these are checks you can enable and disable
<azonenberg>
the point is, they're things that you'd probably want to warn about
<azonenberg>
And for the moment i dont have funding to pay anyone to implement those features
<azonenberg>
Although i would love if they got added eventually
<azonenberg>
Once the construction is done i may have some spare time and/or cash to dedicate to implementing/paying someone to implement them
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<swetland>
yeah I think you'd definitely want lint-style warnings to be -Wno-xyz-able to taste, but they're very nice to have.
<swetland>
right now I end up running multiple frontends (like verilator --lint-only, vendor tools, etc) to sort of catch most stuff in a defense-in-depth approach, but that's pretty clunky
Miyu has quit [Ping timeout: 246 seconds]
azonenberg_work has joined ##openfpga
rohitksingh_work has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<azonenberg>
swetland: yeah i need to re-tool that list at some point, policies have evolved
<azonenberg>
but i think yosys should get these features eventually
<azonenberg>
I also think it needs better systemverilog support
rohitksingh has joined ##openfpga
<swetland>
yeah that's something I'm tempted to poke at a bit. I'd really like to get enum/typedef/struct in as a minimum, then interfaces/modports
Bike has quit [Quit: Lost terminal]
dj_pi has quit [Ping timeout: 244 seconds]
pie_ has joined ##openfpga
TD-Linux has quit [Ping timeout: 260 seconds]
TD-Linux has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
<azonenberg>
swetland: interfaces are a low priority for me because my code has to compile in vivado
<azonenberg>
and while vivado supports interfaces, it does not support arrays of them
<azonenberg>
which makes any kind of parameterizable multiport router a nightmare
<azonenberg>
(e.g. noc or bus fabric)
<azonenberg>
my preferred sv coding idiom for things like that is now a struct packed of input ports and one of outputs
<azonenberg>
2 ports instead of N isnt too much boilerplate to code, and it works in most toolchains
<swetland>
yeah, you've mentioned. that's why they're lower down my list than enum/typedef/struct
<azonenberg>
So if yosys got enum, typedef, and struct i'd be in good shape
<swetland>
enum and typedef feel like they'd add a whole lot of safety and readability for the effort. I liked using them with vivado and miss them in yosys
<azonenberg>
Agreed
<azonenberg>
and structs make huge module instantiatinos waaay more readable
<swetland>
yah
<azonenberg>
and shouldnt be too hard either
<azonenberg>
its just an array with two names for each bit
<azonenberg>
i'm slowly going through all of my old verilog code and any time i have to change any of it, converting to sv and adding enums and structs as i go
<swetland>
I suspect typedef will be the most complex to implement of the three, but none of them seem like they should be all that horrible
<azonenberg>
so antikernel-ipcores is slowly moving toward 100% SV
<azonenberg>
it's mostly running on 7-series so lack of yosys compat is NBD (for now)
<azonenberg>
but by the time nextpnr gets full 7 series support i want usable sv in yosys :p
<swetland>
all my previous stuff was 7-series, but I'm enjoying poking at ice40 and I'd like to keep stuff synthesizing across multiple targets. I'd definitely prefer to get some sv into yosys than have to downgrade existing sv sources
<azonenberg>
Same here
<azonenberg>
in fact i am upgrading my code *to* sv
<azonenberg>
and i am definitely not going backwards just to get yosys to build it
<azonenberg>
i'd rather fix yosys :p
<swetland>
that does seem like the better plan
<swetland>
if only someone could shame xilinx into supporting arrays of interfaces ^^
rohitksingh has quit [Read error: No route to host]
<swetland>
I saw some forum post from late 17 saying "maybe in the future" and decided to check a recent manual for grins
rohitksingh has joined ##openfpga
m4ssi has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
Miyu has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
<edmund>
azonenberg: "by the time nextpnr gets full 7 series support i want usable sv in yosys and i am definitely not going backwards just to get yosys to build it. I'd rather fix yosys" That sounds like a plan.
<edmund>
azonenberg: what other SV HDL design beside antikernel and ARIANE (from ETHZ) do you consider a good SystemVerilog design to aim for support within Yosys?
<azonenberg>
most of antikernel proper is old v2001-2005 code
<azonenberg>
the modules i am bringing up for new work are SV
<azonenberg>
but most of that is focusing on starshipraider not antikernel research
<azonenberg>
i havent got around to updating any of the noc or other fun core stuff
<cr1901_modern>
edmund: I'd like to play around w/ concurrent asserts, since I'm well, kinda bad at them and don't have a playground for them
<cr1901_modern>
azonenberg: I didn't know they made 50 z0 probes until I saw that tweet. But why put them on the power supply?
<azonenberg>
cr1901_modern: *I* made them
<azonenberg>
:p
<azonenberg>
The PSU is a low impedance net
<cr1901_modern>
But it's not high freq either
<azonenberg>
it wont care one bit if i add 1K loading to ground on it
<azonenberg>
Glitches and noise on it are
<cr1901_modern>
100+ Megahertz of noise?
<azonenberg>
some of my captures are at 100ns/div or less
<azonenberg>
and there are spokes that are << 0.1 div across
<azonenberg>
so yes
<azonenberg>
more importantly, by using these probes i get a nice clean signal right at the source without messing around with spring ground clips or the inductance of a 4" ground wirre
<azonenberg>
i can take a measurement right off a single pin of the chip
<azonenberg>
This was also an excuse to go play with my new probes, this is the first batch i've assembled
<azonenberg>
and i really like solder-in probes for extended debug sessions vs trying to hold something on a pin
<cr1901_modern>
Well if it's less work for you, then all the power to you :P.
rohitksingh has quit [Ping timeout: 240 seconds]
_whitelogger has joined ##openfpga
soylentyellow_ has joined ##openfpga
soylentyellow__ has quit [Ping timeout: 272 seconds]
soylentyellow__ has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
<sorear>
still thinking we need a good sv+vhdl frontend that can be shared by yosys AND verilator
ayjay_t has quit [Read error: Connection reset by peer]
<sorear>
is he talking to clifford and the verilator person?
<daveshah>
I don't know
<daveshah>
haven't heard anything
<sorear>
because the coordination is the part that actually matters, we need a comprehensive FOSS toolchain with exactly the same SV and mixed language support
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 258 seconds]
Miyu has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
futarisIRCcloud has joined ##openfpga
rohitksingh has joined ##openfpga
elaforest has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 250 seconds]
emeb has joined ##openfpga
luwii has joined ##openfpga
luwii has quit [Client Quit]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
jevinskie has joined ##openfpga
jevinskie has quit [Ping timeout: 268 seconds]
jevinskie has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
edmund has quit [Quit: Ex-Chat]
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
NPHK has joined ##openfpga
emily has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
X-Scale has quit [Ping timeout: 244 seconds]
paul_99 has quit [Ping timeout: 250 seconds]
paul_99 has joined ##openfpga
<benreynwar>
kraigher is working on a VHDL parser (github.com/kraigher/rust_hdl). At the moment his main target is a language server, but it could potentially be used for yosys and verilator too.
<shapr>
ooh lsp
<sorear>
now I’m even sadder knowing there are multiple real projects and the devs aren’t talking
<shapr>
open source, closed mouth
<benreynwar>
My inclination is to have a intermediate format (like a verilog subset or FIRTTL) and convert the VHDL or SV into the intermediate format during elaboration. It should be possible for the multiple parsing projects, and multiple back-end projects to operate mostly without coordination. The tricky bit is taking a message that references the intermediate format, and transforming it into a message that references the
<benreynwar>
original source. If we had a standard way of annotating the intermediate source with messages, then all the parsing projects could use it. That would be just as useful for migen as it would for SV or VHDL.
<whitequark>
>FIRRTL
<whitequark>
we do not talk about FIRRTL
* shapr
makes a rude noise that sounds like FIRRTL
<shapr>
ok, I would ask what FIRRTL is.. but since we don't talk about it
<whitequark>
just use RTLIL, unlike FIRRTL you can actually do useful things withit
<benreynwar>
Am I OK since I referred to FIRTTL, not FIRRTL?
<benreynwar>
And really I think a minimal verilog subset might be easiest since all the projects already support it.
<whitequark>
verilog is an atrocious IR
<whitequark>
have you read the spec?
<whitequark>
have you looked at verilog signedness rules, for example?
<whitequark>
it's completely unusable as IR
<benreynwar>
I haven't. There no way to take a restrictive subset?
<whitequark>
read the spec first, make adoption suggestions second
<benreynwar>
I'll just trust there's people like you around to correct me :).
<benreynwar>
So your suggestion would be to add RTLIL support to Verilator, and then use that as the IR?
<whitequark>
I don't think that works
<whitequark>
wait, you said Verilator
<whitequark>
yeah, it will work for Verilator
<whitequark>
but not for e.g. iverilog
<whitequark>
since RTLIL (just like FIRRTL) are synthesis IRs
<benreynwar>
I don't think there a big need to have non-synthesizable mixed language support.
<benreynwar>
But I'd really love to have synthesizable mixed language support.
<benreynwar>
I write all my tests in python anyway :).
mumptai has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
jcreus has joined ##openfpga
<sorear>
benreynwar: I don’t think there is any reasonable way to replace iverilog with RTLIL, also, we can’t have multiple frontends because mixed-language support is not negotiable
X-Scale has joined ##openfpga
<whitequark>
sorear: you can have multiple frontends emitting RTLIL
<whitequark>
and then assemble all it
<whitequark>
you know, like you can mix c++ and rust and it all compiles to llvm ir
<benreynwar>
Yeah, that what I was thinking.
<whitequark>
problem is you still want to simulate mixed languages
<daveshah>
I'm not sure this works once you start adding in generics to the mix
<whitequark>
and... verilog and vhdl simulation rules are completely different
<whitequark>
daveshah: hm, you're right
<whitequark>
you'd have to emit something like rtlil plus yosys internal ast
<daveshah>
Or have a way to call back into the frontend?
<benreynwar>
I was assuming that elaboration would be done by the front-ends before emitting the RTLIL.
<daveshah>
But that elaboration can depend on parameters in the other language
<sorear>
even ignoring user-written mixed designs, we don’t want to be supporting two copies of every sim model
<daveshah>
eg if you instantiate a VHDL module with generics in Verilog
<benreynwar>
Good point.
<daveshah>
Lattice don't even provide VHDL sim models, they expect a mixed language simulator if using VHDL
<daveshah>
I think the best solution might actually involve a way of calling back to the frontend with a given set of parameter values
<daveshah>
This way you could even have, eg nMigen or HLS modules parameterised in Verilog
<benreynwar>
The front end could output the RTLIL and also the generic parameters for any modules for which it found no definitions.
<tnt>
benreynwar: hey, I hadn't noticed you were hanging out here as well :)
<benreynwar>
tnt: Hi! I've drifted from SDR over into FPGAs.
<tnt>
Well, they kind of go hand in hand imho :p
Xark has quit [Ping timeout: 245 seconds]
<benreynwar>
True.
<sorear>
daveshah: out of process frontends?
<benreynwar>
Something like fusesoc would be a good candidate to take care of elaboration and stitching all the different front-ends together.
<benreynwar>
You'd still be limited to having non-synthesizable code in a single language.
<whitequark>
that's very much not ideal
<daveshah>
Yes, particularly once you throw vendor sim models into the mix
Xark has joined ##openfpga
<benreynwar>
Hadn't thought of the vendor sim models.
<benreynwar>
So then you really need a simulator that supports non-synthesizable VHDL and verilog if you want to write your tests in VHDL.
<whitequark>
and VHDL and Verilog have completely different simulation models
<sorear>
we know they can be reconciled, because every tool vendor does exactly that
<daveshah>
I'm sure there are at least a handful of bugs in each attempt at reconciliation
<benreynwar>
If you write your test-bench in VHDL, then you have your synthesizable code which instantiates verilog sim models, then your VHDL and verilog and pretty well isolated from each other.
<daveshah>
Yes, module boundaries hopefully make things a bit easier
<daveshah>
But it would complicate developing a unifying IL
<daveshah>
As such an IL would need to be able to define the semantics of both
<benreynwar>
But do you need an IL, if you can define some parts of the design as VHDL and some parts as verilog and they only communicate over module boundaries?
<benreynwar>
Can anyone point me at something discussing the differences between the VHDL and verilog simulation models?
<tnt>
One is sane, the other isn't ? :p
<sorear>
i don’t think you’re helping
<tnt>
Well, if I had a serious answer, I woudl have, but I've never come across a direct comparaison. The best I came across was to basically stick to verilog 'best practice' (like rules when to use block/non-blocking) and it will do what you'd expect. But then I have no idea why you have the option to not follow theses ...
<q3k>
benreynwar: remember modules can be parametrized
<RaYmAn>
Somewhat vague, I know, but what's the right way to "fuzz" (e.g. add to database) something for ECP5 that I can't figure out how to get diamond itself to generate? meta fuzzer and 'hardcode'? Can you 'reverse' a bit file to ncl? It's a config word I'm looking at.
<q3k>
benreynwar: and i'm honestly not sure where in an HDL IL model this parametrization should live
<daveshah>
RaYmAn: no, there's no way to go from bit to ncl
<daveshah>
You can go from a bit file to a list of bit names using bstool -d
<daveshah>
A meta fuzzer that manually adds it to the db would probably be the way to go
<daveshah>
What config word is this?
<benreynwar>
q3k: You elaborate before generating the IL, then you don't need the parameterization in the IL.
<benreynwar>
Maybe mixing verilog and VHDL in non-synthesizable code is difficult because there's ambiguity in what order event effects should take place? Maybe I'll have to read specs like whitequark suggested.
<q3k>
benreynwar: right, but that doesn't work across languages
<q3k>
benreynwar: not sure if it should
<tnt>
I've been reading a bit in the meantime and ... it looks a bit like vhdl model is just the same as verilog without block assignements ? Is there more to it ?
<sorear>
tnt: my comment was at benreynwar “we don’t need an IR or really good design at all”
<tnt>
sorear: oh ... my bad
<tnt>
whitequark: Ah yeah, now I remember you posting this (possibly on twitter) when describing what you were trying to do in nmigen IIRC.
<tnt>
whitequark: very interesting indeed !
<benreynwar>
whitequark: Thanks! That's perfect.
RaYmAn has quit [Ping timeout: 252 seconds]
plaes has quit [Ping timeout: 272 seconds]
RaYmAn has joined ##openfpga
mumptai has quit [Quit: Verlassend]
plaes has joined ##openfpga
<benreynwar>
sorear: I do think we need an common IR for synthesizable code. I think there's less of a need for a unifying IL for non-synthesizable code (or at least it's a much harder problem). Instead you could have a simulator that that treats the VHDL and verilog sections very differently, and they communicate because they share the same event handling base. But even that would be a pain as the document whitequark shared