[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed
bugzilla-daemon at libre-riscv.org
bugzilla-daemon at libre-riscv.org
Tue Apr 30 20:58:14 BST 2019
http://bugs.libre-riscv.org/show_bug.cgi?id=64
--- Comment #49 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #48)
> http://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/add/singlepipe.py;
> h=8296bf2d4ecd9702cd2d32c20dc345734ed2a641;
> hb=55f59ae36e2e29b383a97074e59a0e0b4d1010f2#l1043
>
> Found it in the commit history, the point where I made Queue look exactly
> like a ControlBase as far as the que and deq ports are concerned and
> literally connected them back to back just like any other object conforming
> to the ControlBase API.
>
> All it took: faking up PrevControl and NextControl with some name-changing
> assignments.
>
> NO logic involved AT ALL.
>
> And If you look at Queue you will see that there is literally variable
> assignments where not even the names from the original port that you did
> have been changed.
>
> Again, zero change to the log4ic.
>
> Does this help make it clear all that these objects are all literally the
> same concept?
>
> It really should not be a surprise because ready/valid is such a fundamental
> part of computer science / digital data handling. Want to write data, you
> need to say "i want to write data", and you need an acknowledgment back.
to clarify, I had meant having the enq and deq signals grouped into separate
port objects, similar to how entry/exit signals are grouped in Block. I totally
get that the signals are identical, I was just objecting to how they had been
changed to be ungrouped.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-riscv-dev
mailing list