<kc8apf>
Tired of explaining that verilog isn't an IR
<whitequark>
kc8apf: migen has an EDIF backend
<whitequark>
problem is, if you want to target FOSS tools *and* non-FOSS tools, you either build two toolchains, or use verilog
<kc8apf>
Right. Any attempt to have a discussion about building FOSS low-level tools either gets hijacked to talk about FIRRTL or insisting that yosys is all that anyone needs
<whitequark>
iirc sb0 tried to do synthesis for xilinx with yosys, at the same time as EDIF backend came into existence
<whitequark>
the design ran so slow it was unusable
<whitequark>
that's how migen ended up generating verilog, which I agree is bullshit in principle
<whitequark>
firrtl seems to be an academic scala thing
<whitequark>
is it useful?
<daveshah>
The problem is there are at least five different levels that need to be dealt with. RTL; word-level netlists; bit-level generic (ie AIG or SoP) netlists; techmapped netlists and post or inter PnR designs
<sorear>
I'd have locked or deleted all of those issues days ago tbh
<sorear>
"hijacked to talk about FIRRTL" thank yoiu
jevinskie has joined ##openfpga
rohitksingh has joined ##openfpga
m4ssi has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
<tnt>
daveshah: is there anyway to make timing analysis ignore loops ? I mean ... I'm creating a ring oscillator, obviously there is a loop :p
<daveshah>
tnt: in nextpnr you can use --force
<daveshah>
icetime doesn't have anything like that
<tnt>
nextpnr is what I was looking for.
<tnt>
Thanks !
Hamilton has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
<tnt>
very rough first test. Going from 1.2 to 1.35 is ~ 30% faster.
<daveshah>
I wanna graph :P
<tnt>
I know, but this was just me backfeeding 1.35v to the 1.2v regulator of the icebreaker ... I need to make a proper setup :) Just got the solderpaste out of the fridge to assemble a test board for that ... need to wait for it to warm up a bit.
luvpon has joined ##openfpga
<tnt>
I'm a bit surprised the ring oscillator doesn't toggle faster though. I mean it's a chain of 9 LUTs and I get ~ 15 Mhz out of it. I would have expected more.
<daveshah>
Routing delays might play some part in that
<q3k>
tnt: so what's the oscillation frequency of that?
<tnt>
~ 15 MHz
<q3k>
... what happens if you blast it with a hairdryer / compressed air? ^^
<tnt>
I tried compressed air ... didn't really see much of a difference tbh.
<tnt>
Didn't try to heat it up.
pie_ has joined ##openfpga
<sorear>
so that's T, have you tried P or V?
* sorear
grumbles that P is not "pressure"
* sorear
is suddenly wondering about semiconductor characterization at extreme pressure
<tnt>
sorear: as written above, I tried V=1.35 (instead of 1.2) and got ~ 30 faster.
<daveshah>
I think putting significant pressure on the dice does change things
<tnt>
I just tried blasting 150C hot air at it ... and hard to see a difference.
<tnt>
What does P stand for ?
<daveshah>
Process
<daveshah>
ie variation between wafers and different positions on the wafer
<daveshah>
I think at least on some processes chips at the centre are different to those at the edges
<tnt>
That's going to be tricky for me to test :p
<sorear>
in more practical terms, if you have two ice40 chips, preferably not from the same lot (bought at different times, etc)
<daveshah>
Just buying 5 chips from a few different distributors should be decent coverage
<sorear>
and/or try the same circuit with different placement constraints
<tnt>
Yeah, I have the icebreaker, the upduino, some chips I got from mouser and some I got from digikey.
<Bob_Dole>
Steve from Gamer's Nexus was talking about that, the server memory always coming from center of the wafers because of better quality there. (and the memory manufacturers having expanded the qualifying area for it, lowering supply of dies for consumer modules)
<tnt>
But they're all mounted on different boards with different regulator / supplies / ...
<sorear>
a lot of it is "semiconductor fabrication is an analogue, optical process but the final gate is either 10 atoms wide or 11 atoms wide, never 10.5, so transistors differ from each other"
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<Bob_Dole>
don't they often use light sources that should only be able to make features over.. I forget, but I think it was over 90nm but under 200, and using properties of a fluid to kind of lens it down to the tiny sizes that became more common place a couple years ago?
<Bob_Dole>
I'm not familiar enough but I'd have to assume everyone stopping at 28nm for a good while might have been the limit of that technique
<sorear>
Bob_Dole: the words you're looking for are "immersion lithography" and "multiple patterning"
<sorear>
the industry has used 193 nm argon fluoride excimer lasers for years
<sorear>
less than 193nm is "extreme ultraviolet", and is only going into revenue service now
<Bob_Dole>
when did multi-patterning become necessary? I feel like that happened after 45nm
<Bob_Dole>
but I'm not sure at what size
<sorear>
i'm finding less information than I expected on *operating* ICs in high-pressure environments
rohitksingh has joined ##openfpga
<adamgreig>
have you seen the silicon carbide ICs NASA made for venus landers?
<adamgreig>
mostly they're very hot but also quite high pressure
<adamgreig>
(90 bar?)
<_whitenotifier>
[Glasgow] marcan closed issue #70: Add a DNP resistor footprint between CYP_MEM A1 and Vcc - https://git.io/fpEcP
<_whitenotifier>
[whitequark/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fpEcX
<_whitenotifier>
[whitequark/Glasgow] marcan 9fa367d - revC: all routed, top silkscreen cleaned up
<sorear>
adamgreig: I read a bunch of the VEXAG papers a few years ago, I seem to have missed discussion of pressure effects there
<sorear>
90 bar is not a huge amount of pressure though
<_whitenotifier>
[Glasgow] marcan closed issue #67: Add pullups/pulldowns on every pin - https://git.io/fpBfv
<_whitenotifier>
[Glasgow] marcan commented on issue #67: Add pullups/pulldowns on every pin - https://git.io/fpEcM
<sorear>
that actually might have been more recently than I looked
<adamgreig>
someone was working late
<sorear>
I remember they were doing stuff with diamond (not SiC) and having trouble getting anything that would amplify microwaves
<adamgreig>
day after boxing day, ideal time to run the publish queue
<sorear>
how gastight are typical chip packages? "this chip operates in a slightly corrosive atmosphere" seems like a weird thing to test
<adamgreig>
depends on the gas, I guess you saw the thing about mems oscillators in helium :p
<sorear>
also, 1MHz for a 3-stage ring oscillator at *48 volts* Vdd-Vss? wtf
<sorear>
yes
<sorear>
2.5 ppb HF might be a challenge for typical chip packaging hmm
<tnt>
Oh man, the glasgow revc is going to be much more of a pain to build by hand :p
<q3k>
tbh replacing the fx2 qfn with a bga package (is there one?) would make it much easier to assembly by hand
<q3k>
since there's already one bga, not having to solder a qfn makes it easier
<sorear>
oh I have quite a few papers to read now
<sorear>
-125C to 600C niiiiice
<tnt>
q3k: well, qfn is at least easier to rework. But I mostly meant the sheer number of individual parts to mount :p
<sorear>
hmm, if you're doing PCBs for 475C ambient I guess you can't use normal solder
<whitequark>
q3k: no
<whitequark>
it's a 0.5 mm bga
<whitequark>
three row
<azonenberg_work>
sorear: or fr4? :p
<sorear>
i'm not a fiberglass person, 475c is well below the melting point of SiO2 or C-C bond scission temperatures but there are probably other factors I don't know to consider
<whitequark>
fr4 starts to carbonize at slightly over 300
<whitequark>
mechanical properties go to shit long bbefore
<azonenberg_work>
sorear: well the glass transition point of normal fr4 is only around170C so...
<azonenberg_work>
475 is on the edge of incandescence
<azonenberg_work>
the Draper point is around 525C
<adamgreig>
how bad is splitting some rmii pins between two io banks likely to be?
<adamgreig>
only it would make my routing that much nicer
<tnt>
adamgreig: on what ? ecp5 ?
<adamgreig>
both have the same supply etc
<adamgreig>
ice40 hx
<tnt>
it's fine.
<adamgreig>
just what i wanted to hear :) thanks
<tnt>
tbh you should be using IOB registers and then it really won't matter.
<azonenberg_work>
well, on a 7 series part i would say timing for rmii is almost totally unimportant :p
<azonenberg_work>
Because it's so slow lol
<sorear>
the SiC tech still has a good way to go though
<sorear>
and TASHE is still cooler
<zkms>
i ran my GMSK modulator on real hardware for the first time (ice40 with yosys/nextpnr) and it worked! the curves look exactly like what's in gtkwave! https://pbs.twimg.com/media/Ds4NYonU0AAkeBH.jpg:orig
rohitksingh has quit [Ping timeout: 246 seconds]
rk[ghost] has quit [Ping timeout: 272 seconds]
<tnt>
zkms: are you alt_kia on twitter (or is there two person implementing gmsk modulators :p)
<zkms>
i am indeed
<tnt>
Is your impl posted somewhere ? did you do it "the hard way" or using something like Laurent's decomposition, or LUTs ?
<tnt>
Wow, that paper mentions 64 samples per symbol ... in GSM you usually work with 1, 2, maybe 4 at most.
Hamilton has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
pie__ has quit [Excess Flood]
pie__ has joined ##openfpga
<swetland>
TIL that lattice icecube2 does not consider having *no* constraints mapping top level signals to pins a situation that warrants an error or even a warning severe enough to catch your attention
<_whitenotifier>
[Glasgow] q3k opened pull request #82: revC: length match LVDS pairs - https://git.io/fpE4I
<swetland>
tnt: I think vivado gets really cranky if you have nothing mapped but maybe I misremember
<daveshah>
Vivado won't generate a bitstream but will waste your time going through PnR first
<tnt>
lol
<whitequark>
lol what
<daveshah>
Nothing in the FOSS or vendor Lattice ecosystem will complain
<swetland>
lattice will happily hand you a bitstream with no external connectivity
<daveshah>
It does have external connectivity
<whitequark>
no external connectivity?
<daveshah>
Just on random pins
<whitequark>
or just not constrained?
<tnt>
I think ISE worked with no constraint.
<swetland>
oh shit, I didn't consider that
<swetland>
that's possibly even worse
<daveshah>
I wonder whether this should require --force with nextpnr
<daveshah>
Tempted to add this tbh
<swetland>
it does make sense in a way
<swetland>
but still
<whitequark>
daveshah: I strongly feel that the FOSS ecosystem does not have nearly enough focus on lint-type things
<q3k>
imo not constraining pins is perfectly valid
<whitequark>
for Glasgow and nextpnr I very much want not passing timing to be a hard error
<q3k>
as in, might be a valid strategy for some people
<whitequark>
q3k: the only use case I can think of is trying to eke out the last MHz from some high-speed design
<swetland>
whitequark: it would seem like ideally we'd have equivalents for -Wall -Wno-xyz -Werror, etc
<whitequark>
by letting placer optimize IOBs
<tnt>
q3k: yeah
<q3k>
whitequark: yes
<swetland>
so one could dial in just how severe you want enforcement of things to be
<whitequark>
q3k: that seems like someone almost no one (in the grand scale of things) wants
<whitequark>
so it should be opt-in
<whitequark>
not opt-out
<q3k>
right, but putting it under --force is eh
<daveshah>
whitequark: mostly if you want to estimate timing for a design
<q3k>
--force is too much of a hammer
<whitequark>
yes
<whitequark>
I agree it should be more fine-grained
<q3k>
as swetland said, it would be nice to have different levels of force
<whitequark>
--force is pretty silly
<tnt>
need a -Werror
<whitequark>
-Werror needs to be the default, really
<daveshah>
I'd be very happy to merge PRs that fix this
<swetland>
I'm certainly in favor or severe errors by default
<daveshah>
Things are starting to go in that direction
<swetland>
it always astonishes me how many warnings eda tools emit that in other environments would be fatal errors
<whitequark>
daveshah: so, I talked to Clifford about erring out on multiple drivers
<daveshah>
Combinational loops are already a hard error
<gruetzkopf>
mostly from vendor IP :D
<tnt>
whitequark: revc uses a part that has 2 PLLs right ? with nextpnr you might hit the 'random pll selection' issue ...
<whitequark>
daveshah: first, the fact that in verilog multiple drivers are apparently OK is batshit insane.
<swetland>
yay. design builds on both foss and lattice again. cpu not happy on the metal yet, but one step at a time
<whitequark>
and the fact that such things are OK in verilog seems to poison the minds of FOSS toolchain developers, to an extent.
<whitequark>
like it happens with C.
<whitequark>
second, I tried to write a fix but got frustrated threading it through the entire synth pipeline
<daveshah>
tbh Clifford's philosophy is that a design is broken unless it is simulated or FVd anyway
<daveshah>
Not saying that's correct in any way
<daveshah>
But that's why he's always been less keen on this kind of stuff
<whitequark>
I asked Clifford for help and he made the horrifying warning regexp match hack.
<whitequark>
which I refuse to use out of principle.
<swetland>
I definitely find test/sim-drive development more compelling on the digital design world
<swetland>
but I firmly believe that if software can provide a net it ideally should
<whitequark>
of course, yosys/nextpnr is happy to warn about completely bullshit "issues" like WMASK floating in BRAM.
<whitequark>
it does warn about *some* cases of multiple drivers but not others.
<whitequark>
daveshah: re: simulation and FV.
<whitequark>
I do simulate a large part of Glasgow's gateware, but I cannot and will not build models for every DUT.
<whitequark>
this is simply not feasible.
<daveshah>
Yes I have been meaning to remove that bullshit error for a while
<daveshah>
Thanks for reminding me
<daveshah>
Sure I agree about simulation
<whitequark>
also, migen simulation wouldn't catch multiple drivers either
<whitequark>
Glasgow relies on the synthesis toolchain to catch errors migen doesn't, and where yosys ought to catch something, I will either make it do that or die on this hill
<daveshah>
I'm happy to improve the nextpnr side of things at least
<whitequark>
I have very few complaints about nextpnr, really
<whitequark>
I've only had minor issues with like one-line fixes so far, everything else has been a strict major improvement over all other toolchains
<daveshah>
Timing failures won't be an error by default BTW. But I'm happy for this to be an option
<whitequark>
it's impressive how few critical bugs (zero) I have found in nextpnr place/synthesis code
<whitequark>
definitely wasn't expecting that
<whitequark>
er
<whitequark>
place/route
<daveshah>
If my design that takes an hour to build fails timing by 1% I want a bitstream
<whitequark>
oh sure.
<q3k>
whitequark: wouldn't verilator in lint mode help here?
<swetland>
q3k: it catches some stuff but not all
<daveshah>
Testing PnR tools is actually quite easy
<daveshah>
picosoc catches almost every problem
<whitequark>
ha
<whitequark>
daveshah: re: timing not being an error by default
<swetland>
especially it's not going to understand anything that happens beyond initial elaboration
<daveshah>
There was one issue with an obscure carry pattern that I fixed a month ago
<whitequark>
what about making timing be a non-critical error by default?
<whitequark>
i.e. nextpnr continues but returns 1
<daveshah>
That seems sensible
<whitequark>
I wonder if that would satisfy everyone?
<whitequark>
I do want a bistream too, I just want build_top.sh to die
luvpon has quit [Ping timeout: 252 seconds]
<sorear>
relocation truncated to fit
<whitequark>
sorear: ghhhhh
<whitequark>
god I hate that error so much
<sorear>
can't remember if it's even an error; vaguely recall ld generating bogus executables after it
<whitequark>
it's an error but it doesn't cause ld to exit with nonzero code
<whitequark>
i think
<swetland>
hmm. pll doesn't seen to be working in nextpnr (but does in arachnepnr) on this latest iteration of things
<whitequark>
which makes it a pretty boneless error
<whitequark>
i have deifnitely hit that issue
<whitequark>
there is exactly zero cases where you want "relocation truncated to fit"
<daveshah>
swetland: ping tnt
<tnt>
lol
<swetland>
passthrough clock is live, pll clock (globalb) appears not (have both mapped to IO pins for quick "is it alive" scope checks
<tnt>
swetland: how is it not working ?
<swetland>
poking through the logs to see if I can find a smoking gun
<swetland>
make will build (out/ice40.bin) with arachnepnr make USE_NEXTPNR=true (after make clean) will use nextpnr
<swetland>
tip of tree from a couple days ago
<swetland>
I'm on cf83d546f1139fdfdafa5a309f0378ccff82fac4 Merge pull request #133 from YosysHQ/yield_gui
<tnt>
btw, very cool project, very much looking fwd to it :p I had started mine a couple month ago, but writing the toolchain/assembler for it discouraged me ...)
<swetland>
let me bump nextpnr to tot and give it another go
<swetland>
looks like mostly ecp5 changes but one regarding PAD PLLs
<tnt>
a few days ago should be fine.
<tnt>
just wanted to make sure it included my PRs from last week.
<swetland>
basically when I build w/ arachne the vga block is happy but cpu is not (not surprising first run on the metal)
<swetland>
on nextpnr nothing on screen and the 25m clk sent to out2 is flatline
<swetland>
which would explain the vga block not being happy
<daveshah>
It's merely convention that initial is not ignored for fpga synthesis
<swetland>
the lattice tools will honor $readmem[hb]() in initial for ram/rom init
<daveshah>
But not on registers afaik
<daveshah>
There are some grey areas with BRAM outputs
Hamilton has quit [Quit: Leaving]
<daveshah>
Where Yosys will honour the initial and thus not map bram
<daveshah>
Whereas imo it would be better to ignore the init and infer a bram
* swetland
nods. yeah you can init brams but (under some configs?) initial read port values are undetermined
<daveshah>
I would like to see Yosys either ignore the initial statement here or produce a warning
<daveshah>
Otherwise it tends to confuse people as to why their otherwise valid memory failed to infer BRAM
<swetland>
I wish I could override it's efficiency constraints
<swetland>
yes, I really want a bram, yes I know the register file is comparatively tiny
<swetland>
ah well, I can always invoke the primitive directly
<tnt>
swetland: mmm, the PLL config seem identical in bitstream produced by arachne and nextpnr.
<sorear>
memory synthesis is cursed
<daveshah>
swetland: are you sure it is efficiency that is the problem?
<daveshah>
From memory the threshold for ice40 is pretty low
<swetland>
daveshah: that is the reason it gave for rejecting it
<sorear>
daveshah: pretty sure ice40 can do initials for bram at a hardware level?
<daveshah>
sorear: but not for the BRAM output port
<daveshah>
Which is what I was referring to
<sorear>
ah
<daveshah>
Initials for bram content are fine and supported
<daveshah>
From memory Xilinx does define and support initials for the output port too
<daveshah>
Yosys requires 2% efficiency for BRAM mapping on ice40
<swetland>
okay this is new
<daveshah>
That's only about 80 bits
<swetland>
if I comment out everything below the pll, arachne gives me a working device w/ clocks on out1 and out2
<sorear>
add inverters on the input and output ports and selectively invert the initial data columns? :p
<swetland>
ah so does nextpnr even though it warns
<swetland>
Warning: No clocks found in design
<daveshah>
That's because you don't have any registers in that case
<swetland>
if I omit the cpu (but leave vga and spi debug port) I get a working design in nextpnr
<swetland>
github project updated with a `define WITH_CPU that can be commented out in hdl/ice40.v
<zkms>
i-i still don't know how i made my lfsr work, apparently doing "reg [7:0] lfsr = 69;" worked but not "lfsr <= 69;" in a block that runs once? so confusing >_<
<whitequark>
zkms: neither of these is guaranteed to work by the synthesizable verilog standard
<whitequark>
if you could call that a standard.
<whitequark>
the portable way is to use an explicit reset
<tnt>
also tbh, you really want your design to be resetable from a fabric signal anyway ...
<daveshah>
In general a block that runs once sounds like a simulation only construct
<whitequark>
tnt: not necessarily
<whitequark>
that wastes resources if it's only ever done on configuration
<tnt>
whitequark: not always ... but assuming you're using lik a pll, your clock isn't stable before it locks and you can't rely on the global reset.
<daveshah>
Some FPGAs like the ecp5 have a dedicated internal global set reset too
<whitequark>
tnt: for example glasgow does not use a pll in most designs
<zkms>
the way i've been doing my resets is with "if (reset == 0) begin reset <=1 [other stuff] end"
<zkms>
how should i be doing my resets
<whitequark>
zkms: in an always @(posedge clk or negedge reset) block ?
<whitequark>
wait
<tnt>
(1) there is really no reason to use negative logic in a fpga.
<tnt>
(2) use async reset in the ice 40.
<tnt>
(with a sync release)
<whitequark>
yeah, nevermind what i said
<azonenberg_work>
whitequark, zkms: "reg foo = 1" is a widely supported construct in most fpga synthesis tools
<azonenberg_work>
Which is treated as equivalent to "reg food; initial foo = 1"
<azonenberg_work>
foo*
<whitequark>
azonenberg_work: I know
<whitequark>
but it's not guaranteed by the spec
<whitequark>
so, it depends on what you target with the verilog you're writing
<tnt>
swetland: huh ... that's weird.
<azonenberg_work>
yeah that bit me on a project a while ago
<azonenberg_work>
apparently synopsys DC will actually error out on that
<tnt>
swetland: I mean, if it was an issue with the pll config, the surrounding logic shouldn't matter.
<azonenberg_work>
Rather than silently ignoring initials, like most asic tools do
<azonenberg_work>
that syntax in particular will make it error
<swetland>
tnt: yeah it's a bit puzzling
mumptai has quit [Quit: Verlassend]
<azonenberg_work>
Which is annoying because using the same hdl in fpga is problematic :p
<whitequark>
azonenberg_work: reason number five hundred why i use migen
<whitequark>
and refuse to use bare verilog
<azonenberg_work>
Lol
<swetland>
tnt: can you tell from the asc if GLOBALB of the pll is successfully routed to the IO?
<azonenberg_work>
well its more an architectrural issue
<azonenberg_work>
in xilinx land, you are expected to use initials as much as you can
<azonenberg_work>
and avoid resets unless you really need runtime reset
<swetland>
because it seems like either a. the pll is not working right (seems unlikely if config is identical) or the clk25m out is not getting where it should
<whitequark>
if you ask me this is a language design issue
<whitequark>
you should not ever write resets explicitly to target anyspecific platform
<whitequark>
the language should solve this for you, or it is worthless
<tnt>
swetland: huh no idea how to read the routing infos tbh ...
<swetland>
I assume the pll *input* is getting to it, since the clk12m on GLOBALA is making it to out1 (or it somehow bypassed clk12m_in through that)
<azonenberg_work>
whitequark: eh, its nontrivial because "reset" is not a super well defined construct
<azonenberg_work>
thinking at the abstract netlist issue, not language level
<swetland>
tnt: I'll fire up the nextpnr gui and see if I can follow the wires around
<azonenberg_work>
you can have sync or async reset, por, etc
<azonenberg_work>
you may want to do different things for each
<whitequark>
azonenberg_work: migen solves this by focusing on synchronous logic as the main target
<zkms>
this reset/initial stuff is so complicated ;--;
<zkms>
i dont know what i should be doing
<azonenberg_work>
whitequark: yeah which is probably fine for more trivial FPGA stuff
<tnt>
whitequark: can you ask for an async reset in migen btw ?
<zkms>
otoh i do have pretty constellation/eyes so idk life is not that bad
<azonenberg_work>
but sometimes that isnt the only optoin
<whitequark>
tnt: it's a primitive
<whitequark>
azonenberg_work: you can ask for other resets directly
<tnt>
swetland: you can't really follow global nets.
<whitequark>
by instantiating them
<whitequark>
more or less
<whitequark>
well, POR is expressible as a reset-less clock domain and some logic.
<azonenberg_work>
yeah but then you are explicitly coding to a particular reset architecture
<whitequark>
in FPGAs.
<azonenberg_work>
which was exactly my point
<whitequark>
but you are still doing that in verilog
<azonenberg_work>
it doesnt matter how the language expresses it, different fpgas and asic are not the same
<azonenberg_work>
and you need to design resets for one or the other
<azonenberg_work>
and that has to be a conscious engineering decision
<swetland>
tnt: bummer
<azonenberg_work>
Or fine points of clocking/clock gating
<azonenberg_work>
Like making sure pll outputs don't glitch before fully locked
<whitequark>
yes
<whitequark>
what I'm saying is that making the programmer express all this through inferred constructs is not any sort of solution either
<tnt>
swetland: I need to find which IO sites those out1/2 are on ...
<zkms>
azonenberg_work: do you have something with like, a list of best practices/recommendations for this reset/initial stuff in verilog?
<azonenberg_work>
No
<azonenberg_work>
it's mostly vendor docs
<azonenberg_work>
i have my own verilog linter wishlist notes that i have to go through and review
<azonenberg_work>
at some point i wanted to add support for them to yosys
<azonenberg_work>
i have to update it for systemverilog too
<zkms>
i see
<tnt>
zkms: for the ice40, as I stated above, I'd recomment async reset with a synchronous release. Also I don't rely on reg xxx = xxx; kind of init (or initial blocks). Just my 2ct.
<swetland>
yosis has almost enough sv. enums + typedefs + structs (in that order of priority) and I'd be a very happy camper
<azonenberg_work>
swetland: yeah same here
<azonenberg_work>
those are my main requirements
<azonenberg_work>
interfaces would be nice
<tnt>
+1
<swetland>
I haven't tried but it claims support for interfaces, modports, logic, bit, and definitely handles always_comb/ff
<azonenberg_work>
but even *vivado* does not handle arrays of interfaces right
<azonenberg_work>
Unions would be nice too
<swetland>
I do not want to ever do something like AXI (or more so) w/out interfaces again
<azonenberg_work>
for decoding packed protocols
<azonenberg_work>
right now my vivado-compatible SV coding style is to have one struct for input and one for output ports
<azonenberg_work>
instead of an interface
<azonenberg_work>
Since i can easily make arrays of these on (say) a bus router
* swetland
nods
<azonenberg_work>
and have a vector port of apb3_miso_t and apb3_mosi_t structs
<swetland>
I really enjoyed building AXI widgets but it's just a lot of signals to wrangle per endpoint
<tnt>
swetland: instead of sending it to the pin directly, could you make a toggle flip flop driven by those clock and output that ?
<swetland>
sure
<azonenberg_work>
swetland: my problem with axi is the lack of any way to tell who sent you a message
Dolu has quit [Ping timeout: 246 seconds]
<azonenberg_work>
also i wasnt a huge fan of the "everything is memory mapped" flow
<swetland>
that gives me a 6MHz output (expected) and flatline (no change)
<azonenberg_work>
So i developed my own NoC protocol for antikernel that was based on remote procedure calls, interrupts, and DMA read/write transactions
<swetland>
azonenberg_work: well the security features can sort of encode initiator IDs I suppose
<azonenberg_work>
and had explicit sender IDs tagged on everything so you could allow or deny a request based on that
<azonenberg_work>
swetland: afaik trustzone only has a single secure/nonsecure bit
<azonenberg_work>
there's no way to implement multiple mutually untrusting security domains
<swetland>
on modern/fancier systems with IOMMUs they've expanded it a bit iirc
<azonenberg_work>
My architecture, rather than having an iommu, pushes security decisions to the endpoints
<azonenberg_work>
like an exokernel
<azonenberg_work>
so the ram controller keeps track of which endpoint (including virtual threads on a CPU) owns what page of ram
<azonenberg_work>
and allows/denies access at the physical address level based on that
<azonenberg_work>
ditto for flash etc
<tnt>
swetland: does the pll lock ?
<swetland>
time to send lock to out3!
<tnt>
lol
futarisIRCcloud has joined ##openfpga
<swetland>
lock is high in both scenarios (vga+spi clkm25 works) (vga+spi+cpi clkm25 notworks)
<tnt>
wtf
<swetland>
yeah I am puzzled
<swetland>
icecube+synplify does build this design and no clock weirdness there