Vinalon has quit [Remote host closed the connection]
Vinalon has joined #yosys
<dpiegdon>
quit
<dpiegdon>
ups :)
dpiegdon has quit [Quit: leaving]
Degi_ has joined #yosys
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
<ZirconiumX>
Does -x get lowered to 0-x?
Vinalon has quit [Ping timeout: 264 seconds]
N2TOH is now known as N2TOH_US
Vinalon has joined #yosys
<tux3>
Well, I tried implementing hierarchical param references, but I can't really find a design I like. Maybe I missed something?
<tux3>
Identifier resolution and constant folding seems like it's normally done in ast.cc:simplify(), however the AST of other modules is thrown away as soon as we can convert it to RTLIL, so I certainly can't walk any AST module hierarchy.
<tux3>
And I need plain constant integers for the width of my wires as soon as genRTLIL(), can't wait until later.
<tux3>
But at this point it's both too soon to have the nice RTLIL hierarchy and too late to run the AST constant folding.
<tux3>
So there's hopefuly a better idea than crudely reimplementing ast const eval and a hierarchy pass inline in genRTLIL, but I can't hink of anything nice right now :/
adjtm_ has quit [Ping timeout: 240 seconds]
adjtm has joined #yosys
Cerpin has quit [Quit: leaving]
Vinalon has quit [Ping timeout: 240 seconds]
anticw is now known as cw
cw is now known as anticw
Vinalon has joined #yosys
Cerpin has joined #yosys
citypw has joined #yosys
Vinalon has quit [Ping timeout: 256 seconds]
<az0re>
> And I need plain constant integers for the width of my wires
<az0re>
Check out frontends/verilog/const2ast.cc
<az0re>
I don't know exactly what you mean by hierarchical param references; can you give me an example?
<az0re>
^ tux3
Vinalon has joined #yosys
<tux3>
az0re, I mean the syntax `foo.bar.param`. E.g. if I instantiates a (system)verilog module `submod_type submod;` somewhere, and say my module `submod` has a localparam `lparam`. I want to be able to write `logic [submod.lparam:0] x` in the parent.
<tux3>
If I understand correctly const2ast turns a verilog string literal into an AST node, right?
<tux3>
My problem is turning arbitrary constant expressions that reference identifiers in other verilog modules.
<az0re>
Sorry, I'm not super up on SystemVerilog syntax
<az0re>
What is `logic [submod.lparam:0] x` supposed to do?
<tux3>
Say I have this systemverilog somewhere: `module submod_type(); localparam lparam = 5; endmodule`, this declares a module with a localparam `lparam` that has value 5
<tux3>
Then AIUI `logic [submod.lparam:0] x` declares x as having a width of lparam+1 (5+1)
<tux3>
Essentially I want to access params defined in a module.
<tux3>
So that's equivalent to `logic [5:0] x`
<tux3>
FWIW, I saw the PR that adds fully qualified names from packages in scope of all modules, and I've temporarily switched to using that instead, so I might just give up in hierarchical refs for now.
<tux3>
Params in packages are entirely good-enough for my current needs, and as a complete beginner I don't really have the confidence to go making large refactorings in Yosys =]
<az0re>
<tux3> Then AIUI `logic [submod.lparam:0] x` declares x as having a width of lparam+1 (5+1)
<az0re>
Aaah
<az0re>
I see
<az0re>
I had trouble mentally parsing that
<az0re>
Glad you found a way that works in the end
emeb_mac has quit [Quit: Leaving.]
az0re has quit [Ping timeout: 240 seconds]
citypw has quit [Ping timeout: 240 seconds]
gmc has joined #yosys
lambda has joined #yosys
<pepijndevos>
How do I initiate a Yosys $lut in verilog? If I just do $lut mylut (a, y); it seems to not recognize it as anything if I do show.
<daveshah>
You need to do read_verilog -icells
<pepijndevos>
ERROR: Found error in internal cell \top.\mylut ($lut) at kernel/rtlil.cc:772:
<pepijndevos>
mwk, yea it seems so... or I'm missing something.
<pepijndevos>
uh, a LUT5 is 2 LUT4, a LUT6 is 2 LUT5, so 4 LUT4, and a LUT7 is two LUT6, so 8 LUT8, so still one tile.
<pepijndevos>
But it seems the topmost MUX is just hardwired to the 7 MUX output of the next tile.
<pepijndevos>
As far as I can tell, there is no wire from the 7 MUX output anywhere.
<ZirconiumX>
pepijndevos: so you can't actually use a LUT7 output directly?
Vinalon has joined #yosys
<pepijndevos>
ZirconiumX, you can, it's just one of the OF outputs, but it's ALSO hardwired to the MUX inputs of the next tile as far as I can tell
<ZirconiumX>
Oh, huh.
<pepijndevos>
But... maybe I'm just an idiot and there are some routing bits I'm missing.
<ZirconiumX>
Can't hurt to find out
<pepijndevos>
I mean... it's like finding aliens... I've never seen them, but until you see them it's never 100% sure they aren't there
<ZirconiumX>
Well, anyway, it's one less thing to route :P
<pepijndevos>
But... like... I'm directly parsing the vendor chipdb. I'll tell you all the things you can put an OF output into... one sec
<pepijndevos>
OF7 can go into N270 S270 E270 W270 SN20 E130 W130 per the vendor chipdb
<pepijndevos>
Although.... there are a few wire tables with weird stuff that we don't understand, which could be hiding some aliens. But IIRC the general logic tiles don't even have those.
<pepijndevos>
Funny thing... OF0 can go to DI0, likewise OF1 can go to DI1, but OF7 (8 MUX) does not go to DI7.
<pepijndevos>
I'm actually not 100% sure what DI is
<pepijndevos>
or maybe I was and I forgot
<pepijndevos>
ahh... lutram inputs?
<ZirconiumX>
... How big are the lutrams?
citypw has joined #yosys
<pepijndevos>
eh... fair point... I assume 16 bits for every lut4 right
<pepijndevos>
Have not looked at them much tbh
<pepijndevos>
I guess the proper method would be to instantiate some lutrams and see what happens, but not my priority right now
Vinalon has quit [Ping timeout: 264 seconds]
emeb has joined #yosys
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #yosys
<ZirconiumX>
What I'd really like is a slow LUT6 architecture so I can measure if my designs are faster on e.g. Cyclone V because I've subconsciously optimised for LUT6 or because Cyclone V is actually faster
proteusguy has quit [Ping timeout: 260 seconds]
proteusguy has joined #yosys
Vinalon has joined #yosys
<ZirconiumX>
daveshah: is -x lowered to 0-x?
<mwk>
... hmm
<mwk>
considering adding an R latch to yosys, for orthogonality
<mwk>
did anyone ever actually use such a thing...
<mwk>
... better than the T latch, I guess
<daveshah>
ZirconiumX: no idea, give it a try
<daveshah>
mwk: R latch? A latch that can only be reset?
<ZirconiumX>
I would if I knew how
<sorear>
a T latch is a gated ring oscillator :p
<mwk>
daveshah: .. or only set, yes
<mwk>
it's not as useless as it sounds if it has an init value
<daveshah>
Yes
<daveshah>
Sounds like something you'd get in a power on reset circuit or something
<mwk>
it's the obvious result of optimizing a $dlatchr with enable tied to 0, or an $adff with const clock
<mwk>
and since it's significantly different from both from dfflegalize PoV, I'm tempted to throw it in
<mwk>
(in particular, it can be implemented via $dlatch even if the FPGA is of the match-reset-init kind)
<Sarayan>
hmmm, match-reset-init?
<mwk>
it's also a crucial part of the circuit needed to emulate a mismatched-reset-init $adff
<mwk>
Sarayan: FPGAs where the FF initial values have to match their reset values
<mwk>
ie. if your FF has a reset pin, it has to be initialized to 0; if it has a set pin, it has to be initialized to 1
<mwk>
for example: ecp5 and spartan 6
<daveshah>
ECP5 doesn't have initialisable latches, so it doesn't work for mismatched adffs on ECP5
<mwk>
right
<mwk>
can ecp5 do latches at all?
<daveshah>
It's complicated
<mwk>
async load?
<daveshah>
Yeah
<mwk>
that sounds quite powerful, really
<daveshah>
But that uses the SR path so the init value is the latch D input
<mwk>
hrm
<daveshah>
You can actually synthesis an FF initialised to an IO
<daveshah>
It's also undocumented and not used by diamond
<daveshah>
Which uses logic loops for latches
<mwk>
ok, that sounds 10 kinds of horrible
<mwk>
... still, I can actually do this trick properly for spartan 6
<daveshah>
Yeah
Cerpin has quit [Ping timeout: 264 seconds]
<ZirconiumX>
daveshah: alumacc turns $neg into a $macc then a $alu, so yes, it does
<mwk>
eh, screw $rlatch
<mwk>
it'll never be a target primitive for anything anyway, and it's simply a $dlatch with a const D
<mwk>
I can recognize that easily enough
emeb_mac has joined #yosys
<mwk>
... yay, found unsound $dffsr optimization
<mwk>
(tying S to 1 doesn't force Q to 1)
az0re has joined #yosys
anticw is now known as cw
cw is now known as Guest3061
Guest3061 is now known as anticw
Cerpin has joined #yosys
strongsaxophone has joined #yosys
Vinalon_ has joined #yosys
Vinalon has quit [Ping timeout: 265 seconds]
klotz has joined #yosys
N2TOH_US has quit [Ping timeout: 256 seconds]
N2TOH_US has joined #yosys
klotz has quit [Quit: klotz]
N2TOH_US has quit [Ping timeout: 256 seconds]
N2TOH_US has joined #yosys
indy has quit [Ping timeout: 264 seconds]
strongsaxophone has quit [Quit: Lost terminal]
indy has joined #yosys
N2TOH_US has quit [Ping timeout: 258 seconds]
N2TOH_US has joined #yosys
az0re has quit [Quit: Leaving]
cr1901_modern has quit [Read error: Connection reset by peer]