Ok, in the attached code, you forgot to include the FP_lpm functions.
LPM_COMPARE, LPM_COUNTER, LPM_DIVIDE and LPM_MULT?
I'm in the process of looking up what the LPM functions are. Not finding much info on them other than they're a library of parametrised modules, or Lagrangian Particle Methods (don't think they're the last one!)
What are they? What's their use-case?
Anyways, I would have not used all those dumb strobes in the _top.sv.
For the format, that should be I'm guessing a write port and you should include it's strobe into the ALU.
Using that strobe for the function, you can latch the all of the 'IO_WR_DATA' which should be directly tied to the input_A & input_B to your new ALU's internal register's in_A and in_B.
Yes, it's an IO port that the host writes to so that it can set the ALU's function. Currently, you set the function and the output of the ALU changes accordingly. The output is 'live', so you send the floats to the ALU by writing to the 8 IO ports for them and read the result, either setting the function before or after the floats are sent (I do it before).
You're saying I should stop updating the IO_RD_DATA array with any writes to the FPU IO ports by using the FORMAT IO strobe to signal to the FPU to latch all the IO_WR_DATA ports to the appropriate inputs (a, b)?
I understand passing a strobe into the ALU module will be useful, but it's handy to be able to read the value on each ALU IO port so I'm not sure of the benefits of latching the IO_WR_DATA directly to the ALU's inputs?
Now, it will be possible to add functions combined with the function's 'strobe' for a single stroke action to, for example, copy all of the multiply/divide/add/sub's output back into register in_A or in_B. Or, you can swap in_A and in_B.
Surely I can do this currently, as inputs a & b to the ALU module aren't passed directly to the FPU sub-modules and can be redirected by the ALU?
These are suggestions to allow a few more examples, like in the future having 16x in_A and 16x in_B registers with an output table of results. This may help in storing rotation/scale factors and requesting a block of computation or transformation matrix in a single go.
Sounds good! I think I just need to understand the reasoning behind moving the IO_WR_DATA bus directly into the ALU module; there's clearly something I'm misunderstanding.
![Roll Eyes ::)](https://www.eevblog.com/forum/Smileys/default/rolleyes.gif)