<phire>
Is it sane to implement multi-phase logic in amaranth? I'm reimplementing a design from the 70s, and it uses four phase logic
<tpw_rules>
from what i remember, that would be kind of hard on FPGAs in general?
<tpw_rules>
at least directly. but four phase logic is conventionally designed, the four phases are more related to the physical layout iirc
<phire>
well, sane on FPGAs is a separate question
<tpw_rules>
i mean one of the nice things i like about amaranth is it tries to make those the same question
<tpw_rules>
have you used amaranth before?
<phire>
yeah, part of what originally attracted to migen. In this case, I'm actually more interested in an accurate model for simulation
<phire>
on and off. never long enough to get good at it
<tpw_rules>
it has a pretty similar comb/multi-domain sync model as migen
<phire>
my understanding is that the multi-domain stuff is more intended for isolated clock domains, which you then sync across.
<tpw_rules>
yes
<phire>
in this case, all for phases are in sync, so there isn't a need for crossing the domain (in fact, you cross the domain four times per clock)
<tpw_rules>
there's not really anything stopping you from setting up four domains with the four phase relationships but i'm not exactly sure what you would put in each domain
<tpw_rules>
amaranth only really implements D flip flops, where the clock is some domain. i'm not actually sure how you would do a latch
<phire>
I think it's something like: phase 1: load latches for adder input, phase 2: do addition, phase 4: load output latch
<tpw_rules>
pretty sure one of the design goals was you can't infer one
<phire>
this is an area I don't really understand at all. my current problem is that I'm trying to convert the design to single phase on the fly. And it's really confusing to work out which registers to convert to comb logic, and which registers to keep
<phire>
and I was wondering if it would be smarter to just implement the model as four phase logic, then maybe try to autoconvert it to something better later
<phire>
this is the 8086, it only runs at ~5mhz. One way to reimplement on an fpga is just running 4x faster and only changing the signals every forth clock
<tpw_rules>
"Dynamic logic depends on a two-phase clock"
<phire>
oh.. did I misread
<phire>
:(. well, it's still more or less the same question, but with two phases instead of four
<tpw_rules>
well now they don't overlap which is easier
<tpw_rules>
"Note that unlike a standard logic gate, the dynamic logic gate's output is only valid during clock phase 2." so then i think you would just use one phase logic
<tpw_rules>
and have a register on the output of each gate to use the clock
<phire>
for phases doesn't automatically mean overlap (at least as I understand it), they are edge triggered. So four independnt events
<phire>
*four
<tpw_rules>
Four Phase Logic™ was its own thing which is what i thought you were talking about
<phire>
I was thinking about the scheme used by the Sharp LR35902 (in the gameboy). which as I understand is four independant clock signals
<phire>
which aren't even spaced evenly
<tpw_rules>
anyway i think the dynamic logic gates in the 8086 are the same as a regular logic gate with a d flip flop at the end
<tpw_rules>
is that an internally generated thing?
<phire>
from memory that was internally generated
<tpw_rules>
like iirc the gameboy does the z80 four t cycles per m cycles but it's not got four clock pins
<phire>
I'm remembering this 3rd hand from a conversation I had from someone who knew better. The chip takes a 4mhz clock (t cycle) but the actual IP core of the CPU takes (or makes) four clock lines, one per t-cycle.
<tpw_rules>
afaik that's just a z80 design thing. idk how much bearing it has on the internal implementation. but it's why all the z80 machines are clocked like 4x the speed of 6502 machines
<tpw_rules>
cause each logical cycle (memory access, ocpode fetch, compute whatever) on a z80 is 4 input clock cycles
<tpw_rules>
that link seems to fail some permissions check
<phire>
probally need to be logged into discord. discord is an annoying dark web
<phire>
a regular z80 is diffrent. from memory, the number of T cycles can vary. some instructions take 5 T cycles
<tpw_rules>
yeah that link works now
<phire>
" (there's like 9 "clock" inputs with varying phases and duty cycles)"
<phire>
"so there's literally like a "write to register" clock that only goes high (or low, I don't know the polarity) during the register writeback"
<tpw_rules>
love how discord doesn't have an option for "i don't want to be in every server i ever joined forever"
<tpw_rules>
what makes that count as a clock and not an enable i wonder
<tpw_rules>
i guess if it goes to a latch
<phire>
well, it's all dynamic logic
<phire>
I guess by that point, it is difficult to still call it a clock
<phire>
it's kind of async logic, but driven by a complex multi-phase generator
<phire>
So, the only real restriction is that amaranth deliberatly can't do latches. But I guess I could implement such a design by converting every latch to a d flip flop.
<phire>
and having 9 sync domains
<tpw_rules>
you could also just make a verilog latch module and instantiate it
<phire>
I don't need the actual properties of a latch. As long as you feed these dynamic designs a sane clock, these latches will act equlivent to flops
<tpw_rules>
that was my impression too
<phire>
you probally can't synthisize such a design to an FPGA. not with 9 diffrent clocks
<tpw_rules>
you probably can, it would just be unhappy with the clock routing
<tpw_rules>
it might have trouble passing timing even at a few mhz
<phire>
yeah. but doesn't matter. my interest lies in software simulation, and being able to hook the model up to an accurate visulation.
<tpw_rules>
why do you choose to involve amaranth?
<phire>
Or maybe being able to transform the model to something logically equlivent that can be synthesized
<d1b2>
<zyp> nine clocks shouldn't be an issue for a decent fpga
<phire>
because lofty convinced me it was a bad idea to learn systemverilog :D
<d1b2>
<zyp> e.g. ecp5 got 16 clock nets per quadrant
<phire>
interesting.
<tpw_rules>
do they cover the whole quadrant?
<d1b2>
<zyp> I'd expect so?
<tpw_rules>
yes
<phire>
also, I never really understood FPGAs until I started using migen, so I'm biased.
<lofty>
[21:30:26] tpw_rules: you could also just make a verilog latch module and instantiate it <--- amaranth goes via Yosys, and Yosys has the $dlatch cell there.
<phire>
just write a yosys script that converts all d flops in a given domain to $dlatch
<lofty>
[21:37:11] phire: because lofty convinced me it was a bad idea to learn systemverilog :D <--- and I stubbornly insist this is the right call :p
<lofty>
I mean, yes, you can do that
<tpw_rules>
i'd say it's definitely horrible if you intend to target an fpga. less immediately convinced for other purposes
<koschei[m]>
phire: I’m glad I’m not the only one — the migen/amaranth model clarifies a lot about what HDL code is actually doing for me
<phire>
I understand enough that I could go back now. Now that I know verilog/VHDL are really hardware verification languages that have been abused to create unoffical synthesizable subsets.
<lofty>
There's technically an official synthesisable subset of Verilog
<lofty>
(IEEE 1364.1)
<phire>
still feels like a hack
<lofty>
Oh absolutely
<lofty>
I didn't say it wasn't :p
<phire>
the the wider HDL/FPGA community is not very good at supporting people who self-teach themself. I assume (or hope) the offical text books do a better job at explaining it. But your random verilog/VHDL tutorial just starts spurting code at you
<tpw_rules>
i actually taught a course on that at my uni last semester. they do a little bit
<tpw_rules>
but it's still apparently very hard for students to get
<tpw_rules>
and the tooling and resources and examples available does not help
<koschei[m]>
Once I start internalizing Amaranth and FPGA design a bit more, I really want to start writing good tutorials
<koschei[m]>
The amaranth community seems very friendly, but I’ve noticed the greater FPGA community generally isn’t, which makes learning a lot harder
<phire>
ASICs are even worse
<tpw_rules>
the openlane stuff looks neat but all the tooling is an abject horror
<tpw_rules>
like, even though they have the web based whatever i'm terrified of what's actually happening
<phire>
I suspect the long cycle times of ASIC designs means the entire field gets used to not talking publically about their work
<koschei[m]>
Oh definitely, almost all ASIC tooling is proprietary and considered trade secrets, right? So it actively punishes knowledge sharing
<tpw_rules>
i want to sit down and chart it all out one day (<3 reproducible builds) but idk
<phire>
and even when they do press-event, they have to talk about the amazing invoations of $newproduct, despite the fact they designed it years ago and are currently working on $newproduct+3
<koschei[m]>
tpw_rules: Nix! Probably the least painful way to do reproducible builds and derive dependency graphs from them automatically, if you don’t mind a learning curve on the language
<tpw_rules>
koschei[m]: precisely, that's what i meant. redo it in nix instead of a shambling horror of nested dockerfiles and custom package manager
<phire>
shipping tooling is a bit of an unsolved problem. People try to use docker, but it's really not designed for tooling. It's designed for services
<koschei[m]>
tpw_rules: Nice! I get so much mileage out of Nix in that role. I really want to do a general Nix flake template for FPGA projects, like fusesoc but capable of pulling in tooling and not just cores