<joshua_>
(I wish to hand-instantiate a DFF with very careful control over what the RTL looks like so that I know that I get exactly one DFF and that the synthesis tool gives me one DFF with the reset pins hooked up the way I want)
CarlFK has joined #litex
whitequark[cis] has joined #litex
<whitequark[cis]>
with my Amaranth hat on: write the entire thing in Verilog and instantiate it
Degi_ has joined #litex
<whitequark[cis]>
I don't think this is even sound, as you make no effort to reserve {nam}_q in ns
<whitequark[cis]>
(or, the way I could actually write it, though it's very different from your approach, is to branch on the platform you're synthesizing for, and emit a platform primitive for Xilinx, Lattice, etc, whatever you care about)
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
<joshua_>
I was kind of thinking of doing that as an Instance, yes. my hope was I guess that the idiomatic thing I was truly looking for was that someone had already written a DFF special that I just hadn't seen
<whitequark[cis]>
since by the time you need that precise of a control you typically tie yourself to a specific platform or few platforms
<joshua_>
(the specific thing I am trying to achieve here is having a register in my design that is combinationally reset as a S/R latch when the PLL loses its mind, so that the system can assert some safe GPIO state even if the clock never ticks again)
<joshua_>
I am not super worried about soundness since I am doing this thing exactly once
<whitequark[cis]>
I mean Migen emits everything into one global namespace
<whitequark[cis]>
so anything else in your design can conflict with it potentially
<whitequark[cis]>
re: S/R latch, do you basically want a clock domain with async reset (which Migen notoriously doesn't support)?
<joshua_>
in theory, yes, in practice, 'pll_unlock_dff_q' is an unusual sounding name for anything other than what I am trying to do
<whitequark[cis]>
because I don't think many FPGAs support S/R latches, and even fewer FPGA toolchains bother exposing them
<joshua_>
yes, clock domain with async reset seems fine. I did not like it because this is not "really" a clock domain or a global set/reset that makes sense for anything else
<whitequark[cis]>
any distinct async control set of a DFF is a clock domain
<whitequark[cis]>
(even if you just change the async reset pin)
<whitequark[cis]>
(async reset is just one time use clock)
<joshua_>
I know that Xilinx will infer latches from incomplete `always @(*)` (and scream the entire time). I have no idea if Efinix's tools will or what happens if you try it. you can implement it by hand with a LUT if you are brave, I suppose
<whitequark[cis]>
Xilinx will infer D-latches
<whitequark[cis]>
but you are mentioning an S/R latch, which is fairly different
<whitequark[cis]>
that being said, your actual code shows a DFF with async reset, which is completely fine
<joshua_>
I guess I would implement a S/R latch in RTL as a D latch. and indeed, this is a DFF with async reset because I did not want to play games with incomplete `always @(*)` and I could express it this wa ytoo :)
<whitequark[cis]>
there is just that annoying terminological ambiguity over whether a DFF is a "latch"
<joshua_>
(in this case, making the S synchronous and the R async)
<whitequark[cis]>
I think that's not really an S/R latch even?
<whitequark[cis]>
I think to make a DFF into an SR latch you'd fix D at 1, set ARST_VALUE to 0, use posedge clk and posedge rst, and now your CLK input is S and RST input is R
<whitequark[cis]>
(we could also take the discussion of what is a man^W latch elsewhere since we're clearly on the same page)
<joshua_>
in this case if I were implmenting it as a S/R latch, I would say that S = ~pll_locked, R = self.pll_unlock_lockout_reset.re, and in this case, R is made synchronous so it's sort of a latch and sor tof a flop, but yes, indeed, we are broadly on the same page
<joshua_>
(I am aware that self.pll_unlock_lockout_reset.re would be quite bad as an async reset if it were not constrained to exactly be the Q pin of a flop, though!)