2022-12-29 01:21:41 <KipIngram   > Oh, oops.
2022-12-29 01:21:45 <KipIngram   > I see a problem.
2022-12-29 01:22:07 <KipIngram   > When I run the lit opcode, it's supposed to move the number addressed by the IP register to the stack and increment IP.
2022-12-29 01:22:32 <KipIngram   > But... by my earlier discussion, IP isn't addressing RAM anymore after I leave the instruction cell fetch state and start executing opcodes.
2022-12-29 01:22:39 <KipIngram   > That following cell is inaccessible.
2022-12-29 01:23:02 <KipIngram   > And there is no way to tell on the previous cycle, before the clock edge, that I'm about to execute a lit opcode.
2022-12-29 01:23:17 <KipIngram   > Well, I shouldn't say "no way" - I'm sure I could cook something up.
2022-12-29 01:23:24 <KipIngram   > But that's complexity that I don't want.
2022-12-29 01:24:30 <KipIngram   > Man, darn Xilinx for not making that input register bypassable the way the output register is.
2022-12-29 01:24:42 <KipIngram   > That thing is just causing all manner of problem.
2022-12-29 01:25:55 <KipIngram   > The EASIEST way out is to change what lit does.
2022-12-29 01:26:37 <KipIngram   > Instead of picking up the next 32-bit cell in instruction memory as a full literal, I could have it trat the following opcode slot as 6 bits of a literal.  Likely it would shift TOS left six its and then OR those six bits in.
2022-12-29 01:26:52 <KipIngram   > Then 0 followed by a set of lit commands could build up any constant.
2022-12-29 01:27:00 <KipIngram   > I've seen this done somewhere over the years.
2022-12-29 01:27:13 <KipIngram   > It might actually be BETTER, since most lits are likely to be small anyway.
2022-12-29 01:27:52 <KipIngram   > Wow, it's a good thing I wasn't planning to have jump distances inline in the instruction stream.
2022-12-29 01:27:59 <KipIngram   > Because this would affect that as well.
2022-12-29 08:54:06 <KipIngram   > Ok.  That issue from late last night will just need to be tackled head-on.  I always no what state op_control is about t go to.  There are six states; one is for instructino word fetches and the other five are for each of the five opcode slots.  If I'm headed into the instruction fetch cycle, then I know I'm going to need to read IP so I can prepare for that.  If I'm headed into an opcode cycle, then I've GOT
2022-12-29 08:54:08 <KipIngram   > an instruction word, and so I have all my opcodes.  if I know which slot I'm working with on the next cycle, then I know what opcode I'll have.  Therefore I can know what value to present to all the block rams.
2022-12-29 08:54:57 <KipIngram   > If I'm headed into a lit opcode cycle, I know to apply IP to the rams.  Otherwise, I apply A or B.
2022-12-29 08:55:21 <KipIngram   > And this removes the need for A and B to have different ports to use - they can both work through a single port.
2022-12-29 08:56:34 <KipIngram   > It's a cleaner design; instead of applying bandaids in specific situations, I'm just... SOLVING the problem.
2022-12-29 08:57:57 <KipIngram   > If the upcoming opcode is a double return, I know I need the stack circuit in the return stack to have at port 2.  it's an across the board solution.
2022-12-29 08:58:16 <KipIngram   > And MrMobius, yeah, it's a TYPE of pipelining.
2022-12-29 08:58:59 <KipIngram   > You could think of it as a pipleine that has a "RAM planning" unit and an "execution" unit.
2022-12-29 09:35:07 <thrig       > a RAM planer sounds like it would make a lot of dust
2022-12-29 09:36:43 <Zarutian_iPad> bleeting all the way too
2022-12-29 12:21:00 <KipIngram   > Some of the things I've had to do on this have turned out to have pretty simple logic.  This look-ahead is not one of them.  Six input LUTs just don't quite "get there the easy way."
2022-12-29 12:21:36 <KipIngram   > I'll always know what state I'm in now, of course, but the state that will follow depends on several things.
2022-12-29 12:22:09 <KipIngram   > Usually it will be "the next slot."  But if the current opcode is a conditional one, then it will be "the second slot over."
2022-12-29 12:22:48 <KipIngram   > And if the current opcode is rep, then it will be state 1, unless there's an interrupt pending or the counter is expiring, in which case it will be state 0.
2022-12-29 12:22:58 <KipIngram   > So that's four possible next states, in general.
2022-12-29 12:23:20 <KipIngram   > That part isn't too bad, because a 4-1 selector does fit in one LUT.
2022-12-29 12:23:56 <KipIngram   > But there's also the business of all the states we can actually be in now - how to extract the "now op" and the "next op" from the instruction word depends on that too.
2022-12-29 12:25:17 <KipIngram   > I may go back to the plan of shifting the instruction word over each time, six or twelve bits.  This morning I was considering keeping an unshifted instruction word and just selecting out the fields I need at any given time.  But shifting may be better after all.
2022-12-29 12:28:43 <KipIngram   > Then the "now" op is always the low order bits, and "next" will be either six over or 12 over, or slot 1 from the UNSHIFTED COPY that I also keep.  Or state 0, which doesn't depend on that word at all - no ops needed in state 0.
2022-12-29 13:10:44 <KipIngram   > Yeah, the shifting method is significantly simpler.