Talk:Hardware register

I've put the nav template back as this page lacks links, and I feel the template adds functionality. Please see the revised rootpage concept. Most electronics pages seem to have retained the templates I set up, and this page does naturally complete the set. Note that I am not suggesting in any way that this is purely part of Electronics, but it takes away nothing currently to attach it to that set, and makes it much more likely to be accessed by users. --Lindosland 16:15, 27 March 2006 (UTC)Reply

Strobe Registers

This line was removed from the article: "A strobe register is not actually a register as it has no memory cells. Instead of storing data, it triggers an action (e.g., reset a peripheral) each time it is "written" or "read", or both. They are a means of signaling."

I agree that the cite was irrelevant. I am not sure what such a signalling device would be called but it certainly exists. An example of a use would be to acknowledge to an interrupting device that its ISR has started and it can drop its interrupt request. This allows interrupts to be re-enabled for higher priority requests. Perhaps this action-trigger could be described as a zero-bit hardware register. It should be described in this article as it otherwise lacks notability. RastaKins (talk) 16:25, 10 November 2025 (UTC)Reply

Hi RastaKins. When no storage is involved, this would seem to be purely an address decoder application in which the decoder outputs a signal when the associated address and write (or read) are asserted. On the other hand, such signals certainly are relevant to registers if they enable a register write or gate register outputs onto a bus. It so happens that I have been working hard to document these two applications for inclusion in this article. My plan is to describe them in a generic way, so it might be worthwhile to add specific examples (e.g., interrupt req/ack) in subsequent sections. I hope to have these posted in the next few days along with related images. Lambtron talk 22:19, 10 November 2025 (UTC)Reply
Looking forward to your coverage. I suppose one way to think of it would be there really is a hardware register out there, a flip-flop, that is holding the pending interrupt status. It may not be readable or writable via the data bus but the flip-flop's state can be changed by a read or write to a certain address. RastaKins (talk) 00:03, 11 November 2025 (UTC)Reply
I added an image and explanation for interrupt status register. Let me know if it's not what you had in mind, or feel free to revise. Lambtron talk 22:17, 26 November 2025 (UTC)Reply
Nice illustrations! The example might be a little complicated. Here's why: 1:Software interrupts should not be considered. On many, if not all architectures, software interrupts happen the moment they are encountered. They are a glorified "call", not an asynchronous event that may be delayed. Software interrupts require no external hardware. 2:The interrupt pending flip flop should be dedicated to one interrupt source only. So it could be as simple as an RS or D flip flop. Interrupt event happens, sets the flop. Interrupt service routine (ISR) happens, clears the flop with a read or write, and then services the hardware device. There cannot be conflict because the interrupt is cleared before the hardware is armed for the next interrupt. The next interrupt might come in before or after the ISR is finished. It doesn't matter. The interrupt will be remembered by the flop even of the ISR has not finished. Early interrupt will be handled after the ISR exits and re-enables interrupts. 3:The read port to the data bus is unnecessary. A unilateral clear of the flop during initialization will define its state. Signaling of a change of state is through the interrupt system reacting to the change of state. This is a example of a zero-bit register addressable by the processor. RastaKins (talk) 03:46, 27 November 2025 (UTC)Reply
My last reply was in November and I am starting to feel neglected. Let me approach this from a different angle. I will try to point out some problems. 1:SWI should be removed. There are no microprocessor architectures that require hardware support for software interrupts. Software interrupts are just glorified calls and execute immediately just like any instruction. 2:INTEN should be removed. Interrupt enables are handled internally in most processors and none (except the Intel 8080) have an INTEN output. If you want to keep it, you could call it MASK. There are some architectures that can mask or prioritize interrupts. Or an external mask could be added to any architecture. 3:Wouldn't an RS or D flop illustrate this concept better? 4:If you must use JK, why the AND in the input to K? HWI would be removed before ACK is sent by the software. In a way, we are latching the interrupt twice: the thing that drives HWI and then the JK. RastaKins (talk) 19:56, 28 July 2026 (UTC)Reply

I created two alternatives: File:IRQ register 01.jpg and File:IRQ register addressable.jpg. Both preserve the JKFF -- standard practice for synchronous FF with independent R & S. DFF would require additional gates and feedback; synchronous RSFF is theoretically possible but not used in modern practice; RSL is verboten in synchronous systems. Removed SWI and HWI, leaving only generic service request. Eliminated INTEN (assume downstream masking). Eliminated AND gate, which is not essential to explanation. Lambtron talk 19:02, 29 July 2026 (UTC)Reply

Those two diagrams are great! Thanks for considering my comments. RastaKins (talk) 21:22, 29 July 2026 (UTC)Reply

Addressable registers

Write operation: Mr. Lambtron, the diagram in this section may be a bit confusing. In practice, wouldn't the WR- be connected to what you show as CLK on the latches and a higher significant-bit address decoder would be connected to the E input of the decoder? The latches would capture bus data only if their upstream address is fully valid on the trailing edge of a WR-. RastaKins (talk) 18:38, 25 June 2026 (UTC)Reply

Hi RastaKins. They're D registers, so ADDR, WR and DATA are set up asynchronously and then along comes a clock edge to trigger the write. I agree that latches would be treated differently; they would require a write strobe instead of a clock and other circuit changes as well. BTW, I haven't forgotten about your feedback on the interrupt example -- it's on my todo list. Lambtron talk 21:28, 25 June 2026 (UTC)Reply
Perhaps I should have used WE instead of WR. Is that the point of confusion? Lambtron talk 21:30, 25 June 2026 (UTC)Reply
The problem is the signals are not similar to static RAM signals. Static RAMs do not have a clock. On nearly every processor, the trailing edge of WR- or WE- or whatever is what actually clocks the data into sRAM. On most processors, address gets set up first, then data, then the trailing clock edge of WR- latches the data. I think what you are showing is the somewhat oddball way that the 6502 works. Check out figure 5 here.[[1]] RastaKins (talk) 22:05, 25 June 2026 (UTC)Reply
There's no processor or RAM involved here; it's just an array of D registers. Sorry if I'm missing something here -- if so, it's probably due to too many years designing FPGA apps, where addressable register arrays like this are the norm and latches are dangerous beasts to be avoided. Lambtron talk 22:43, 25 June 2026 (UTC)Reply
I am thinking of it from this perspective: that sRAMs are addressable latches. If one observes the minimum address, enable, and data setup times, sRAMs work just like addressable D flops. If you changed the signal labeled CLK to WR- and the signal labelled WR to EN, then your circuit would behave just like sRAM. Advantages: no CLK and you now have the option to NOT write a register. Currently, your circuit is not qualified with any MS address bits. A register always get written when WR is true, assuming CLK is a free-running clock. RastaKins (talk) 00:45, 26 June 2026 (UTC)Reply

In my experience, addressable registers are commonly clocked synchronously with a continuous clock to ensure predictable timing and data integrity. For example: register files in processors including general-purpose registers, status registers, and control registers; memory-mapped registers in communication devices; and register banks in FPGAs and ASICs. Having said that, it's true that many addressable registers are write-strobed -- something that's probably worthy of mention and possible elaboration, but which has no affect a reader's understanding of this circuit. The origin of WR (and ADDR/CLK/RST) depends on the application and IMO is not necessary to reach an understanding. If it still seems confusing then perhaps a timing diagram is called for? Lambtron talk 16:00, 26 June 2026 (UTC)Reply

Just get rid of the extra line. Consider simplifying the example to match the 74259 addressable latch with no separate WR AND CLK lines. Yea, I realize this device does not use D flops but it could. [2] RastaKins (talk) 17:22, 26 June 2026 (UTC)Reply
Mr. Lambtron, I like your solution that makes both chip designers and system designers happy. Good job! RastaKins (talk) 23:37, 10 July 2026 (UTC)Reply

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.