If the PC register is simultaneously read and written, does its read data contain the previous data or the newly-written data? Based on my understanding of sequential circuits, the effect of the write command does not instantly take effect in the PC register due to propagation delay so, at the rising edge of the clock, the read command will get the old value. But corollary to my question is if this is the case, shouldn't the read command would also have a delay in some sense and could possibly read the newly-written data?
A program counter is normally special enough that it's not part of a register file with other registers. You don't have a "read command", its output is just always wired up to other parts that read it when appropriate. (i.e. when its output is stable and has the value you want). e.g. see various block diagrams of MIPS pipelines, or non-pipelined single-cycle or multi-cycle designs.
You'd normally build such a physical register out of edge-triggered flip-flops, I think. (https://en.wikipedia.org/wiki/Flip-flop_(electronics)). Note that a D flip-flop does latch the previous input as the current output on a clock edge, and then the input is allowed to change after that.
There's a timing window before the clock edge where the input has to remain stable, it can start to change a couple gate delays after. Note the example of a shift register built by chaining D flip-flops all with the same clock signal.
If you have a problem arranging to capture a value before it starts changing, you could design in some intentional clock skew so the flip-flop reliably latches its input before you trigger the thing providing the input to change it. (But normally whatever you're triggering will itself have at least a couple gate delays before its output actually changes, hence the shift-register made of chained D flip-flops.)
That wiki article also mentions the master-slave edge-triggered D Flip-Flop that chains 2 gated (not clocked) D latches with an inverted clock, so capturing the input happens on the opposite clock edge from updating the output with the previously-captured data.
By comparison and for example, in register files for general-purpose registers in classic RISC pipelines like MIPS, IIRC it's common to build them so write happens in the first half-cycle and read happens in the second half-cycle of the ID stage. (So write-back can "forward" to decode/fetch through the register file, keeping the window of bypass-forwarding or hazards shorter than if you did it in the other order.)
This means the write data has a chance to stabilize before you need to read it.
Overall, it depends how you design it!
If you want the same clock edge to update a register with inputs while also latching the old value to the output, you a master-slave flip-flop will do that (capture the old input into internal state, and latch the old internal state onto the outputs).
Or you could design it so the input is captured on the clock edge, and propagates to the output after a few gate delays and stays latched there for the rest of this clock cycle (or half cycle). That would be a single D flip-flop (per bit).
Related
I am reading a book Digital Design and Computer Architecture and in the chapter on the D trigger at the transistor level it says "A compact D latch can be constructed from a single transmission gate" and the following is an example of building a latch using this and buffers.
I have a few questions:
How is it that a latch can be built from a single transmission gate, if the Latch is a memory cell that should consist of two looped elements and store the state, and not just pass through a bit of information on a clock pulse.
What are buffers used for when building a D trigger? I couldn't figure it out from what was written in the book. Can you explain this point in a little more detail? And why do they all invert the passing values?
Figure 3.12 (a). D latch constructed from a single transmission gate
Figure 3.12 (b) 12 transistor D latch
Figure 3.13 D-trigger
Figure 3.12
Figure 3.13
What are buffers used for when building a D trigger?
A latch is always and continuously open to respond to inputs that can change the value the latch stores.
However, many designs timed and are clocked, so that means we want to accept changes (requests to store potentially new value) only at the clock edge boundary but otherwise hold the latch with current state as is, as well as hold its output steady. Clocked designs are tuned/timed so that the combinational (non-sequential) circuitry in between storage completes (just) before the next clock boundary and so can be recorded in registers and the next cycles go forth. The general concept here is called an Edge Triggered Latch, which is also known as a Flip Flop used in clocked designs.
In order to limit the time period allowed for change of a latch, we add extra circuitry in front of the latch, the effect of this circuitry is to allow inputs to go through on certain time periods and otherwise suppress inputs for the others — allowing change only once per cycle, e.g. at a positive clock edge.
The extra circuitry added can be either a 2nd latch or pulse trigger. These operate differently and have different advantages and disadvantages.
The 2nd latch approach typically always has one latch in the accepting change state and the other in the opposite state, the storage state (i.e. ignoring input changes). The states of the two latches reverse every single clock edge (e.g. on the half clock). Because of this, data transmits from one latch to another only at clock edge boundaries, and with two latches put together, we can make devices that accept input only on rising edge (or only on falling edge) of the clock, e.g. once per full clock cycle.
We might call the extra latch a buffer.
In pulse-triggered designs, we clip short the clock signal going to the latch so that it doesn't last as long as the full half cycle of the clock, and latch sees only a quick blip instead, as another approach to limiting the period of change.
For more information on the variations in Flip Flop designs and their trade offs see this text:
http://bwrcs.eecs.berkeley.edu/Classes/icdesign/ee241_s01/Lectures/lecture22-flipflops.pdf
The simple latch is actually acting like a sample and hold for analog signals. The memory is held by a capacitor holding the voltage or logic level. It doesn't pass through when in hold state, because the input is actually disconnected from the latching (holding) capacitor when in that state.
The buffer is there to ensure a minimal load to the output of the latching (holding) capacitor. The buffer is in an inverted mode, and the input to the latch capacitor also is an inverter, hence canceling the inversion.
This is my first GitHub, I want to write a report but this green line keeps popping up next to my text and I don't want it to do so. This is what my text should be but it appears like this: https://gyazo.com/f593db78a387623fcad31c744ac9a120
How can I control this?
System Hardware Final Report
The project designed shows the functioning behind computer's.
The topics covered will include:
Introduction to Binary & Logic Gates
Commonly Used Parts
Logic Functions
The Timing Signal Generator
The Bus, Arithmetic Unit and Program Counter
Data Registers and the Memory Address Register
Program Memory
The Control Signal Generator
The outcome of this project will enable one to build a computer with a CPU (central processing unit) that can do simple
instructions such as moving data from one register to another and performing simple arithmetics.
Introduction to Binary & Logic Gates
Breadboard
The breadboard will be used to setup the components and all circuits. It is divides in 8 parallel coloumns and contains 5 columns that
provides power. In fact, the breadboard is made up of two important supply connections: the VCC for the red
line and the GND for the blue line. The holes are all connected row-by-row in lines of 5.
Switches
This happens when you make changes to a file (this is called a diff), then preview it. Green indicates something was added, while red indicates something was removed. Committing the changes will not make the lines stay in the file.
I am currently developing a subset of the 6502 in LogiSim and at the current stage I am determining which parts to implement and what can be cut out. One of my main resources is Hanson's Block Diagram.
I am currently trying to determine how exactly the increment logic works. In a previous project that I worked on in school, the program counter was incremented via a single instruction coming from the decoded instruction memory. In this diagram, the program counter logic looks like it works differently than I have previously encountered.
How exactly does this logic work and does it use an instruction from the instruction memory to increment? As a follow up, Is it possible to simplify the program counter logic to use one or two instructions from the instruction memory to increment?
The 6502 has only one program counter. It is 16 bits wide. Because a lot of other things in the CPU are exactly 8 bits wide, it makes hardware sense to cut the 16 bit program counter into two halves, so that each half fits in 8 bits. For example, each half is loaded separately, one by one, with an instruction like JMP. And the relative branch instructions bring PCL to an ALU input.
Those halves are just called PCH and PCL internally. You can see that PCL has increment logic attached to it, and one of the outputs is a carry out signal called PCLC. That's the input to another circuit that increments PCH.
None of this matters to a program. The program just cares that PC points to the instruction that's going to be executed next, and uses that fact to influence its own flow. But if you're interested in knowing more of these details, I'll point you to the Visual6502 simulation. It's much more accurate and detailed than Hanson's Block Diagram.
I'm having an issue which is partially Matlab- and partially general programming-related, I'm hoping that somebody can help me brainstorm for solutions.
I have an external microcontroller that generates a large stream of binary data (~40kb) every 400ms and sends it via UART to a PC running Matlab scripts. The data is not encoded in hexa or dec characters, but true binary (hence, there's no terminator defined as all 256 values are possible, valid combinations of data). Baudrate is set at 1024000. In short, it takes roughly 375ms for a whole stream of data to be sent, with 25ms of dead time in between streams
In Matlab, the serial port is configured correctly (also 1024000, 8x bits, 1x stop bit, no parity, no hardware flow control, etc.). I am able to readout the data I'm sending via the microcontroller correctly (i.e. there's no corruption of data), but I'm not being able to synchronize the serial readout on Matlab. My script is as follows:
function data_show = GetDATA
if ~isempty(instrfind)
fclose(instrfind);
end
DATA_TOTAL_SIZE = 38400;
DATA_buffer = uint8(zeros(DATA_TOTAL_SIZE,1));
DATA_show = reshape(DATA_buffer(1:2:end)',[160,120])';
f_data_in = false;
f_data_out = true;
serialport = serial('COM11','BaudRate',1024000,'DataBits',8,'FlowControl','none','Parity','none','StopBits',1,...
'BytesAvailableFcnCount',DATA_TOTAL_SIZE,'BytesAvailableFcnMode','byte','InputBufferSize',DATA_TOTAL_SIZE * 2,...
'BytesAvailableFcn',#GetPortData);
fopen(serialport);
while (get(serialport,'BytesAvailable') ~= 0) % Skip first packet which might be incomplete
fread(serialport,DATA_TOTAL_SIZE,'uint8');
end
f_data_out = true;
while (1)
if (f_data_in)
DATA_buffer = fread(serialport,DATA_TOTAL_SIZE,'uint8');
DATA_show = reshape(DATA_buffer(1:2:end)',[160,120])'; %Reshape array as matrix
DATAsc(DATA_show);
disp('DATA');
end
pause(0.01);
end
fclose(serialport);
delete(serialport);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function GetPortData (obj,~)
if f_data_out
f_data_in = true;
end
end
end
The problem I see is that what I end up reading is always the correct size, but belongs to multiple streams, because I haven't found a way to tell Matlab that these 25ms of no data should be used to synchronize (i.e. data from before and after that blank period should belong to different streams).
Does anyone have any suggestions for this?
Thanks a lot!
For completeness, I would like to post the current implementation I have fixing this issue, which is probably not a suitable solution in all cases but might be useful in some.
The approach I took consists in moving into a bi-directional communication protocol, in which Matlab initiates the streaming by sending a very short command as a trigger (e.g. single, non-printable character). Given the high baudrate it does not add significant delay due to processing in the microcontroller's side.
The microcontroller, upon reception of this trigger, proceeds to transmit only one full package (as opposed to continuously streaming package at a 5Hz rate). By forcing Matlab to pickup a serial package of the known length right after issuing the trigger, it ensures that only one package and without synchronization issues is received.
Then it becomes just a matter of encapsulating the Matlab script in a routine with a 5Hz tick given by a timer, in which the sequence is repeated (send trigger, retrieve package, do whatever processing, and repeat).
Advantages of this:
It solves the synchronization problems
Disadvantages of this:
Having Matlab running on a timer tick does not ensure perfect periodicity, and hence the triggers might not always be sent at exactly 5Hz. If triggers are sent at "inconvenient" times for the microcontroller, packages might need to be skipped in order to avoid that a package is updated in memory while it is still being transmitted (since transmission takes a significant part of the 200ms time slot)
From experience, performance can vary a lot depending on what the PC running Matlab is doing. For example, it works fine when the PC is left on its own to do the acquisition, but if another program is used (e.g. Chrome), Matlab begins to lag and that results in delays in transmission of triggers.
As mentioned above, it's not a complete answer, but it is an approach that might be sufficient in some situations. If someone has a more efficient option, please fell free to share!
I need to control a conveyor (driven by Micromaster 440) from a PC program using SFC14/15.
The scheme will be: Supervisors PC ->(ethernet)-> S7-1200 ->(profibus)-> Micromaster 440.
At the moment, Micromaster's output frequency is controlled via a potentiometer (analog inputs) by the "field" operator. The problem is that sometimes the operator increases the conveyor speed in order to do his job faster and this affects the production negatively. The "supervisor" wants to be able to limit output frequency using the PC program.
Of course I've seen the list of MM440 parameters and I know about P1082, but I've discovered that, unfortunately, MM440 should be stopped before the new value of P1082 takes effect. In my case it's preferable to be able to change the value on the run.
Fortunately, it seems that P0757 - P0760 - (input scaling) can be changed on the run, but this parameter has sign "first confirm", which means that
the “P” button on the operator panel (BOP or AOP) must be pressed before the
changes take effect.
But the MM440 has only one slot for the Profibus/BOP/AOP panel and I'll be using Profibus. So, in this case, what will be the behavior of mm440 like? I want to believe that, perhaps, this condition is not obligatory when using profibus panel...
I would opt for a solution where the operator no longer operates the belt speed directly but tells the S7-1200 PLC a what speed he would like the belt to run (either by using 2 +/- buttons or a pot-meter). The PLC can then control the speed of the belt (either by analog output or 2 digital (+/-) outputs).
As an added bonus you can stop the belt when it is accidentally left on and things like that...