Re: What do we call non-pipelined designs?

On 12/8/2024 5:05 PM, MitchAlsup1 wrote:

On Sun, 8 Dec 2024 22:10:15 +0000, Marcus wrote:
 

I usually (and simplistically) divide CPU designs (implementations) into
two main categories:
>
- Pipelined
- Non-pipelined
>
Of course, there is a sliding scale at play, but let's not get into that
debate.
>
My question is: What is the best name for non-pipelined designs?

 If any portion of the design fetches the next instruction before the
last calculation of the previous instruction, then the design is
pipelined. CDC 6600 had a pipelined front end and serially reusable
calculation units. {{Also note under this definition 6800, 68000, and
8086 were (partially pipelined) architectures.
 

Seems like there are classes (on FPGA):
   Small bit-serial designs,
     usually people trying to make the smallest cores;
     Not super obvious how this works.
   Non-pipelined:
     Seemingly mostly existing as educational examples;
     Prioritizing logic simplicity over speed.
   Pipelined 1-wide scalar:
     Common;
   Pipelined 2-wide superscalar:
     Also common.
   Wider:
     Rarer.
OoO cores are generally rare on FPGA, and tend to need much bigger FPGAs (seemingly more of the type where one rents access to it via a cloud server, rather than the type one buys and has sitting on their desk).

I'm thinking about CPU:s that transition through several states (one
clock cycle after another) when executing a single instruction (e.g.
FETCH + DECODE + EXECUTE), and where instruction and data typically
share the same memory interface.

 Given that one can take an off the shelf (rather cheap) FPGA and
implement a fully pipeline RISC ISA implementation::
 Why, in this day and age, would anyone want to even consider doing
something less pipelined than that ?!?!?
 

Cheap is relative...
Though, someone could in theory make cheaper boards if they had custom PCB's made and soldered everything themselves (with the added complexities of small surface mount and BGA components; as bare FPGA+QSPI Flash+FTDI+... seems to be somewhat cheaper than the typical cost of a pre-assembled dev-board).
Granted, one would need to be making a lot of them, as this stuff tends to come with a minimum order.
Companies like Digilent seemingly take a pretty big cut for themselves.
Seems mostly like the lower end has mostly dropped out of dev boards:
   XC7S6 / XC7S15: No one bothers.
   XC7A12 / XC7A15 / XC7A25: No one bothers.
   XC7S25 and XC7A35T: Seemingly the smallest anyone bothers with.
     Were previously on Arty boards, but seemingly discontinued;
       Well, maybe, Arty XC7S25 appears to be back.
     Still used on CMod boards (*1), but, no real external RAM.
   XC7S50 / XC7A50T: Semi common.
   XC7A75T / XC7A100T: Semi common (medium/high end of dev-boards)
   XC7A200T: Rarer, a lot more expensive.
Beyond this:
Kintex: Expensive, and much beyond XC7K70T can't use free version of Vivado (so, the biggest Kintex in free Vivado mostly gives higher clock-frequencies, but limited to smaller designs than if one goes for an Artix, while also more expensive).
Where, in Xilinx naming, the final number gives roughly the number of "logic cells" (LUT count being roughly 0.63 * LogicCellCount).
*1: A lot of boards still using these smaller FPGAs are using form-factors where they will plug into a DIP socket or bread-board.
A lot of the boards using Altera chips are comparably more expensive, so not bothered with these.
At least on commonly available Xilinx chips, yeah, not really any reason not to do a pipelined design. On most of the chips that "actually have RAM", may as well also go superscalar...
The Lattice FPGAs are also available, and have FOSS tools (getting them to work is another matter), seem to be popular amongst hobbyists making their own dev boards, but are comparably "weaker". The FPGAs themselves are cheaper, but as far as dev boards go, they are not.
Say:
   ECP5 vs Xilinx:
     LUT4 vs LUT6, so needs more LUTs;
     CARRY2 vs CARRY4 (needs more resources for ADD'ers);
     Weaker in terms of hard-logic DSP multipliers and Block-RAM.
If a person were targeting an ECP5, they would likely need to have smaller caches (than on an Artix) and to be more sparing with the 18-bit multipliers. The there are fewer memory blocks, but they are similar capacity (18kb), but can use comparably narrower widths than Xilinx BRAMs (possibly a merit for ECP5 here).
Though, in my past (currently stalled) idea for trying to mess around with printable electronics, had considered making it mimic a Lattice style FPGA:
Existing FOSS tools actually support them (can use existing Verilog compilers);
It seemed much more viable to try to map LUT4 netlists to logic gates than to try to map LUT6 netlists.
Little idea about RAM blocks, as I don't yet know of a viable (semi-compact) way to design these (seems actually like LUTRAMs would be preferable).
Though, if using uniform-sized blocks, the LUTRAM blocks would need comparably much denser logic than the LUT4s, so likely layout could not realistically use a fixed-size grid (say, some bigger units might need a 2x2 or 3x3 space relative to a "basic" LUT4).
Say, possibly using a 3x3 space (or bigger) for a SRAM block, but dunno, not worked out the specifics. Looks like to mimic the ECP5, would need a dual-port 16x2-bit RAM (but, could mimic this with two 16x1 bit RAM blocks).
Hmm... It also comes up as an idle thought:
   What if I wrote something to try to simulate the PMOS logic,
   and then tried to get a genetic algorithm to work some of this out?...
(Then again, would likely be very slow...).
...
Say, for example, if one imagines layers like:
   Substrate;
   PMOS ink;
   Insulator mask;
   Metal ink;
   Insulator mask.
Though, for something like RAMs, might need two PMOS layers and 2 or 3 metal layers for signal routing.
Say, for example, if one imagines layers like:
   Substrate;
   PMOS ink;
   Insulator mask;
   Metal ink;
   Insulator mask;
   PMOS ink;
   Insulator mask;
   Metal ink;
   Insulator mask;
   Metal ink;
   Insulator mask.
Could reduce the number of layers some, noting as how an inkjet could reasonably do any of the 3 on the same layer (but, one does still need to be able to have a layer of insulator between any not-connected non-insulator layers). Could be relevant for things like signal routing though.
All this might be asking a bit much for a genetic algorithm to work out in any reasonable timeframe though (more so, as simulating the PMOS logic is likely to be fairly slow; effectively it will work like resistors that vary their resistance based on the voltage of the nearby layers; and for each steady-state would need a number of update cycles for the voltages to stabilize across a grid, ...).
Would likely work under the assumption of, say, 72 or 144 dpi with around 0.030" of layer alignment variability (sheet might not always grab at the same spot, or might shift relative to the paper feed mechanism).
Printer DPI might be higher, but may not matter if one can't always feed at exactly the same spot.
For more accuracy, would likely be better to have a mounted substrate with a CNC controlled print-head, but then the problem is making the print head. Likely printing mechanism could be driven by using stepper motors to turn a lead-screw that drives a syringe (*). Would need to make some impractically small holes though (though, could almost make sense to stick a sowing needle into a CNC toolholder and use it like a precision hole poker, with some sort of adapter to allow holding a needle in an ER11 collet as I don't think they go that small).
For thin materials, could maybe try using a needle as a drill (vs just poking a hole), ... Likely, using something like plastic sheet or an extra thick aluminum foil (I wouldn't imagine a spinning sewing needle would hold up against much more than about 0.010-0.020" or so of aluminum; or, say, maybe several layers of aluminum foil glued together).
*: Say, for example: Takes a largish syringe, drills a hole down the middle of the plunger handle, epoxies a 10-24 nut or similar on the end of the handle, and uses 10-24 all-thread as a leadscrew (probably driven using a NEMA-17 or similar, as while overkill these ironically seem to be cheaper than the smaller steppers). Such a machine would need roughly 6 steppers (3 for X/Y/Z, 3 for the syringe pumps).
May need to gear down the pump.
   Stepper: 200 steps/rev (typical)
   Say, one uses an 0.375 diameter syringe, 0.442 in^3 / inch.
     0.000092 in^3 (0.0015 ml) / step.
Say, one wants a desired drop size of 0.005":
   0.000000065 in^3 (0.000001 ml)
   Would need around a 1000:1 reduction on the stepper
     (this is assuming micro-stepping).
     Most likely option: Probably a worm-gear or similar.
Could maybe try using an X/Y table, possibly using a very short Z leadscrew (or just a hex-head cap-screw, say, if one only needs 0.200" of Z travel). Could maybe have a heated bed (like with a 3D printer), so that the "drying" phase can happen during printing. Would likely want the head to be ~ 0.003-0.007" or so from the substrate during printing (so that the drops can touch, but the print head should not touch the substrate).
Nevermind if there is still the big issue of the high cost of the PEDOT:PSS ink and similar...
But, dunno...