I am using a ifm AC1421 PLC. I am using a ifm AC2218 D/A module to operate the actuators i.e. proportional valves. A/D module AC2517 ifm is used to get the data from pressure sensors.
I wanted to have an idea on how is the I/O mapping done in Codesys i.e. at what address do i need to define them.
I have attached an image which shows the current assigned variables.
Say for ex. I have assigned my PV1 at %QW47 and PV2 at %QW50.
Can I not assign PV2 at %QW48 or %QW49?
If i assign them the PV2 doesn't get operated
Similar goes with the Sensors I have assigned at %IW32,33 and 34. Can i not assign them at %IW37,38 or 39?
Actuators
Sensors
AFAIK, unless you need to know the exact memory address of those inputs/variables elsewhere in your code, you shouldn't really pay attention to the address. What you should care about are the Channels. Where you should assign/map your variables to will depend on what channel your input is wired to.
Related
I've used Enterprise Architect (EA) to create pretty drawings and I've liked it for that purpose. I find that I have a lack of understanding on how diagram elements link between one another. What I find particularly frustrating is that there is very little documentation on how this linking works (although lots of documentation on how to draw pictures).
I would like to create a model of a simple processor/ECU (electronics control unit). Here is the behaviour:
An ECU has an instance of NVRAM (which is just a class) for an attribute
An ECU has a voltage supply (an analog value representing the voltage level supplied to the ECU)
An ECU has two digital input ports
Each digital input port fires signals when its value changes
the ECU has a state machine with three states; the state machine enters state 1 on entry; the state machine transitions to state 2 on a firing of either digital input ports so long as the ECU voltage supply is greater than 10 V
the ECU exists to state 3 when Voltage drops below 8; and goes back to normal processing when Voltage rises above 9
Can you develop a model that demonstrates how these elements interact? (Is there some reference I can read on how to understand this approach?)
Here's my first attempt:
State Machine
I used a composite diagram in the ECU state so that I could have access to the digital ports diagramatically. I created a link for each port so that they "realize" class input PIn. I assume I can depict class attributes this way.
I "create a link" so that the DIO triggers realize the DIO ports. Not sure I can do this.
The class state machine is where I get lost. Not sure on how to create a trigger for ECU.Voltage < 8.
I want to communicate three modules, one is a control unit, second is an arithmetic unit, and the third is Ram-like memory.
I'm a beginner, I know that I can connect two modules by instantiate one inside the other. For example the ALU ports inside the Control Unit.
What I want to do now is to extract a data from the RAM and send it to the ALU, only if Control Unit ask it to do it.
So it seems I would have to instantiate the same module, some ports at the Control unit and some of the (the data) to the ALU.
// In the Control Unit part of the port of the same instantiation
RAM_U RAM_U_inst1 (
.read (read)
);
// In the ALU module the other part
RAM_U RAM_U_inst1 (
.data (data)
);
In this case when RAM_U receive the order to read, it will send the data to the ALU.
Is this the correct way to do this? FPGA Synthesizable
Please don't do this, either make instance of all module in single top module called module micro_controller(....).
What I want to do now is to extract a data from the RAM and send it to the ALU, only if Control Unit ask it to do it.
Control unit will give address to RAM, and fetch data from it, and then provide to ALU, now result produced by ALU or RAM write can also done with control unit.
Are you able to understand?
The logic that I am using is set up to expect a diff-pair clock port. However, for one specific application, I can only input a single ended clock (due to hardware limitation). Modifying the logic to accept single ended clock is not an option as there are many files and lines of code involved. Is there a way I can input a single ended port and somehow feed it to diff-pair ports of modules? So for example in my top level I want to have a port like this:
input single_ended_clk
And I want to feed this to a module that takes the following ports:
input diff_pair_clk_p;
input diff_pair_clk_n;
A very naïve approach would be to do this:
mymodule m_i (
.diff_pair_clk_p(single_ended_clk),
.diff_pair_clk_n(~single_ended_clk),
);
but I don't think this is the proper way to do this.
Most chip designs, either ASICs or FPGAs explicitly instantiate clock buffers rather than infer them. In the FPGA world, the synthesis engines usually aren't smart enough to recognize a clock and hook the buffer outputs to the dedicated clock routing resources. So you really probably need to explicitly instantiate a clock buffer.
Now as to the case where sometimes you want a single ended clock buffer and sometimes you want a double edge clock buffer. While you can use generate statements referencing a parameter to decide which buffer to instantiate, you can't control the port list of the chip this way. You can keep the clock buffer inside the lower level module.
I would not recommend recreating a differential signal inside the chip. There are several problems with this. First, a differential clock buffer expects to be connected to external pins, not internally buffered signals. Secondly, there is a timing mismatch between the positive and negative clock which could create glitches on your resulting clock post-buffer which would make a real mess of your design.
Instead, keep both _n and _p inputs to your sub-module, and use a generate to select the type of clock buffer to be instantiated. In the case of a single ended clock, the _n input is left unconnected and only the _p input is used.
Here's an example for a Xilinx FPGA. The buffer primatives will be named differently in other types of FPGAs or ASIC libraries.
module clock_buffer (
input pin_clk_p,
input pin_clk_n,
output clk_int
);
parameter DIFF = 0;
generate
if (DIFF = 1)
clk_buf IBUFGDS(
.I (pin_clk_p),
.IB (pin_clk_n),
.O (clk_int)
);
else
clk_buf IBUFG(
.I (pin_clk_p),
.O (clk_int)
);
endgenerate
endmodule
There will be a phase offset, it might be within tolerance. It is hard to say without knowing timing requirements for the differential paired clock and single clock, how the clock tree is being handled, timing of buffers and inverters. You may be able to handle this from within the synthesizer by identifying the clocks and there relation. To do this, assign the clocks individually at the appropriate hierarchy level, maybe its own sub-module. diff_pair_clk_p and single_ended_clk are functionally the same, but they should be separated for load balancing and clock-tree balancing.
assign diff_pair_clk_p = single_ended_clk;
assign diff_pair_clk_n = ~single_ended_clk;
Sometime there are predefined modules that are part of the standard/macro cell library which are intend for solving or simplifying specific design challenges. Instantiate these modules where needed, a dont_touch pragma may be needed. Specifically look for cells described as symmetrical buffers and inverters. You may still need to give additional guidance to the synthesizer.
Referring to my earlier question here, I've been utilizing tri-states to work with a common bus. I still appear to have some implementation issues.
The tri-states use this type of code:
assign io [width-1:0] = (re)?rd_out [width-1:0]:{width{1'bz}};
Synthesis and translation goes well. No warnings or errors I wasn't expecting (I was expecting some since this is only a trial run and most of the components don't do anything and will hence be left unconnected). But when I actually try to implement it, all busses (there are three) output a 1111111111111111, or a -1, as converted by my binary to BCD converter. I checked if it really the case by instructing the control matrix to halt if the instruction received on the bus is -1, and it did halt.
The warning I receive for the tri-state being converted to logic is:
Xst:2040 - Unit Neptune_I: 16 multi-source signals are replaced by logic (pull-up yes)
Xst:2042 - Unit alu: 16 internal tristates are replaced by logic (pull-up yes):
And so on. Neptune_I is the top module, and I believe the multi-source signals it's referring to are the busses.
I have a doubt whether the pull-up yes is the root of this problem. Is it simply pulling everything up, causing it to be -1 all the time? But this does not make sense to me, because when the tri-state is activated, the signal should be controlled by whatever entity it is supposed to be controlled by.
I would like to take the time to replace the code with logic instead of the tri-states, but I'm unsure how to proceed.
Any help would be appreciated.
Are these signals going off-chip? Or are they internal to your FPGA? If the answer is the latter, you need to change your code. Modern FPGAs (like Spartan 6) no longer support internal tri-state buffers. They only exist for off-chip signals.
You need to write all of you internal code to avoid tri-state buffers. Create dedicated paths between components, no bidirectional interfaces.
I've been coding a 16-bit RISC microprocessor in Verilog, and I've hit yet another hurdle. After the code writing task was over, I tried to synthesize it. Found a couple of accidental mistakes and I fixed them. Then boom, massive error.
The design comprises of four 16-bit common buses. For some reason, I'm getting a multiple driver error for these buses from the synthesis tool.
The architecture of the computer is inspired by and is almost exactly the same as the Magic-1 by Bill Buzzbee, excluding the Page Table mechanism. Here's Bill's schematics PDF: Click Here. Scroll down to page 7 for the architecture.
The control matrix is responsible for handling when the buses and driven, and I am absolutely sure that there is only one driver for each bus at any given instance. I was wondering whether this could be the problem, since the synthesis tool probably doesn't know this.
Tri-state statements enable writing to a bus, for example:
assign io [width-1:0] = (re)?rd_out [width-1:0]:0; // Assign IO Port the value of memory at address add if re is true.
EDIT: I forgot to mention, the io port is bidirectional (inout) and is simply connected to the bus. This piece of code is from the RAM, single port. All other registers other than the RAM have separate input and output ports.
The control matrix updates a 30-bit state every negative edge, for example:
state [29:0] <= 30'b100000000010000000000000100000; // Initiate RAM Read, Read ALU, Write PC, Update Instruction Register (ins_reg).
The control matrix is rather small, since I only coded one instruction to test out the design before I spent time on coding the rest.
Unfortunately, it's illogical to copy-paste the entire code over here.
I've been pondering over this for quite a few days now, and pointing me over to the right direction would be much appreciated.
When re is low, the assign statement should be floating (driving Zs).
// enable ? driving : floating
assign io [width-1:0] = (re) ? rd_out [width-1:0] : {width{1'bz}};
If it is driving any other value then the synthesizer will treat is as a mux and not a tri-state. This is where the conflicting driver message come from.