Sounds like you could use a register (14 bits wide) for each component, that have their data inputs connected in parallel. Then you'd have 40 write strobes, with some decode logic you could reduce that to 1 write strobe + a 6 bit component 'address' select. Basically a write-only bus, consisting of 14 data bits, 6 address bits and a write strobe.- In each state a special number should be fed to the input of each component, which is a different number for each component. (In fact we have 40 look-up tables, each having 10 rows)
- The fed data should be kept until the time comes for the next state (see? I've completely forgotten how you guys say such things in the literature )
That's a 500us cycle for "all outputs updated". Do you have any requirements for the time between "component 1 updated", "component 2 updated", "component 3 updated" etc. :?:- The system remains in each state for about 500us. So things should happen fast enough.
All the components should be updated "at once".That's a 500us cycle for "all outputs updated". Do you have any requirements for the time between "component 1 updated", "component 2 updated", "component 3 updated" etc. :?:
By 'register' one always means 'shift register', right? :???:Sounds like you could use a register (14 bits wide) for each component, that have their data inputs connected in parallel.
In that case you'd need a 2-stage process: for each component, first write new data into a temporary holding location (=register), while component uses another register to output current (previous) data. Repeat for all components (with timing delays in between), such that when done, all components still output their previous data but have the new data available locally.All the components should be updated "at once".
No. Register is very generic something that can hold data. There are ones where you shift bits in serially, and there are ones where you present all bits on parallel inputs, and clock those in with 1 clock pulse. See for example 74HC574.By 'register' one always means 'shift register', right? :???:
Perhaps, but that wouldn't help you here as it could only output a small set of bits at a time. Read: that would re-introduce delays between updating component 1, component 2, etc.Question: Is there anything such as a "register bank" out there? Something that I can store, say, 64 bytes in it, and direct the bytes into the output one bye one?
you'd need a 2-stage process
Something such as a "register bank" can be helpful now with this new strategy. Why? Because as you remember I have 10 different states, so the data should be "loaded" to the registers every time. I don't want this 'loading' to be performed each time. What I have in mind is to have a design in which there are extra registers that kinda act as a memory. So I'd just need to do some 'shifts' and a final 'output'.PerhapsQuestion: Is there anything such as a "register bank" out there? Something that I can store, say, 64 bytes in it, and direct the bytes into the output one bye one?
Do consider FAN out and FAN in capabilities of devices don't end up in sourcing or sinking more current
why cannt you emulate this in microcontrollers with some software coding...
I need a device which is sort of a "shift register bank". Something that provides with a lot of shift registers. Something that can store, say, 64*8 bits inside.
I think I can also call this hypothetical device a "FIFO memory" or a "Sequential Access Memory".
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?