[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