I'm using Xilinx ISE and generated a memory using the CORE Generator & Architecture Wizard.
The problem is that it created a write enable signal (wea) as a STD_LOGIC_VECTOR(0 downto 0) and that results in a type mismatch:
Line ###: Type error near encnt ; current type std_logic; expected type
std_logic_vector
How can I cast encnt, which is std_logic, to a one bit std_logic_vector?
(ISE doesn't allow me to change wea from the file of memory.)
This is a pretty common scenario with these IP blocks. You can easily associate your std_logic signal like this:
wea(0) => encnt,
Instead of associating wea as a whole, you are just associating that one element (0). As wea only has one element, this assigns the whole vector.
Related
In a distributed Erlang system pids can have two different representations: i) internal; ii) external.
The internal representation has the following shape: < A.B.C >
The external representation, used for instance when a message has to travel across different nodes, is instead composed of the following elements: < node_id, ID, serial, creation > according to the official documentation.
Where node_id is the name of the node, ID and serial identify the process on node_id and creation is an integer used to distinguish the node from past (crashed) version of itself.
What I could not find is how the creation integer is created by the VM.
By setting a small experiment on my PC, I have seen that if I create and kill the same node several times the counter is always increased by 1, and by creating the same node on different machines, the creation integers are different, but have some similarities in their structure, for instance:
machine 1 -> creation integer = 1647595383
machine 2 -> creation integer = 1647596018
Do any of you have any knowledge about how this integer is created? If so could you please explain it to me and possibly reference some (more or less) official documentation?
The creation is sent as a part of the response to node registration in epmd, see details on that protocol.
If you have a custom erl_epmd module, you can also provide your own way of creating the creation-value.
The original creation is the local time of when the node with that name is first registered, and then it is bumped once for each time the name is re-registered.
I have a weird question which sounds self explanatory in vhdl, but the code does not output to an oscilloscope even though the logic seems okay. I need to drive 0's and 1's for each bit in the vector below, and I need to do this with combinations of sliderswitches. I am using the Digilent Nexys 3.
My problem is that when I run this code or any code that has more than 3 outputs per if statement, one of the outputs does not output to logic '1' when given the right combination.
I gave my code below, which seems extremely simple. Can someone tell me why I can only output 3 things per if statement? I need to be able to output 20 or more signals per if statement.
I have tried everything I can think of, from using bit_vector, to using different syntax. Any help on why I can only get 3 outputs at most would be greatly appreciated.
Library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.all ;
entity pulse_gen_toVGA is port (
clk_50,sw0,sw1,sw2,sw3 : in std_logic ;
rst : in std_logic;
output : out std_logic_vector(3 downto 0));
end pulse_gen_toVGA;
architecture top of pulse_gen_toVGA is
begin
process(sw0,sw1,sw2,sw3)
begin
if (sw0='0' and sw1='0' and sw2='0' and sw3='0') then
null;
end if;
if(sw0='1') then
output<="0001";
elsif(sw1='1') then
output<="0010";
elsif(sw2='1') then
output<="0100";
elsif(sw3='1') then
output<="1000";
end if;
end process;
end top ;
Here is my ucf file of the outputs that I am using.
net "clk_50" loc="v10";
net "output<0>" loc="t12";
net "output<1>" loc="n10";
net "output<2>" loc="p11";
net "output<3>" loc="h3";
net "sw0" loc="t10";
net "sw1" loc="t9";
net "sw2" loc="v9";
net "sw3" loc="m8";
Well, your code is not exactly O.K.. Let's see:
if (sw0='0' and sw1='0' and sw2='0' and sw3='0') then
null;
end if;
This if does nothing, except waste precious bytes on your hard drive and several microseconds of cpu time everytime you synthesise or simulate. Having these lines or not changes absolutely nothing, so might as well remove them.
if(sw0='1') then
output<="0001";
elsif(sw1='1') then
output<="0010";
elsif(sw2='1') then
output<="0100";
elsif(sw3='1') then
output<="1000";
end if;
What happens if none of the switches is '1'? Implicitely, that a signal must not change its value if it is not assigned, which requires a memory element since when all switches are '0', output depends on the last switch that was active.
In that case, the synthesizer will infer a latch. Latches are known to behave erratically and should really only be used by experts. They appear every time you forget to assign a signal in one logical path of a combinational process.
You have two choices to fix your code, either you add an else to your if statement, setting output to 0 for example, or you use a proper memory element known as a register. In the first case, you will have a combinational circuit, containing only logic gates with no latch/register. In the second case, you will have the same behaviour as the latch circuit, but without the erratically of the latch. Here's how to implement a register:
process(clk_50)
begin
if rising_edge(clk_50) then
if(sw0='1') then
output<="0001";
elsif(sw1='1') then
output<="0010";
elsif(sw2='1') then
output<="0100";
elsif(sw3='1') then
output<="1000";
end if;
end if;
end process;
I have to add that the register route is not entirely fine, and encourage you to search for metastability, asynchronous input and resynchronization. Basically, using asynchronous signals (like your switches) without synchronizing it can cause problem.
Finally, it may not solve your problem, but we can look into that once you have a "clean" code.
Before you go making changes there are a couple of thing you can check.
There are not outputs labelled output in Nexys3_Master.ucf. Show us how (where) output goes that you're detecting it doesn't occur.
We can't replicate your problem with what you've provided, it isn't an Minimal, Complete, and Verifiable example.
Next, simulate your design.
Here is a simple testbench:
library ieee;
use ieee.std_logic_1164.all;
entity pgtv_tb is
end entity;
architecture foo of pgtv_tb is
signal clk_50: std_logic;
signal sw0, sw1, sw2, sw3: std_logic;
signal rst: std_logic;
signal output: std_logic_vector (3 downto 0);
begin
DUT:
entity work.pulse_gen_toVGA
port map (
clk_50 => clk_50,
sw0 => sw0,
sw1 => sw1,
sw2 => sw2,
sw3 => sw3,
rst => rst,
output => output
);
STIMULUS:
process
begin
wait for 100 ms;
sw0 <= '0';
sw1 <= '0';
sw2 <= '0';
sw3 <= '0';
wait for 100 ms;
sw0 <= '1';
wait for 100 ms;
sw0 <= '0';
wait for 100 ms;
sw1 <= '1';
wait for 100 ms;
sw1 <= '0';
wait for 100 ms;
sw2 <= '1';
wait for 100 ms;
sw2 <= '0';
wait for 100 ms;
sw3 <= '1';
wait for 100 ms;
sw3 <= '0';
wait for 100 ms;
wait;
end process;
end architecture;
And it produces:
(clickable)
Now the first thing we see is the inferred latches Jonathan Drolet was concerned with from the null statement in the first if statement.
Changing all the switch inputs to '0' didn't affect output, this happens four more times in the simulation.
But you can see we actually do get four outputs, which says
... when I run this code or any code that has more than 3 outputs per if statement, one of the outputs does not output to logic '1' when given the right combination
Isn't evident in the VHDL code. And that strongly suggests there's something wrong somewhere getting output to show up, and it's not evident in your code.
(Your code doesn't reproduce the problem for which you are asking help, regardless of whether you want those latches there or not).
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.all;
entity reset40 is
Port ( CLOCK : in STD_LOGIC; --50MHz
CIKIS : out STD_LOGIC
);
end reset40;
architecture Behavioral of reset40 is
signal A:std_logic;
begin
process(CLOCK) --line20
variable fcounter: unsigned(24 downto 0);
variable counter_A:integer range 0 to 40:=0;
begin
if rising_edge (CLOCK) then
fcounter := fcounter+1;
end if;
A<=fcounter(6); --fa=fclock/2^6
if ((rising_edge (A)) and (counter_A/=40)) then
counter_A:= counter_A+1;
CIKIS<=A;
else
CIKIS<='0';
end if;
end process;
end Behavioral;
ERROR:Xst:827 - "C:/Users/reset40/reset40.vhd" line 20: Signal CIKIS
cannot be synthesized, bad synchronous description. The description
style you are using to describe a synchronous element (register,
memory, etc.) is not supported in the current software release.
What is the error about clock? How come is it a 'bad synchronous description'?
Your basic mistake is that all the code that is in the process needs to run only on the rising edge of the clock. This is because the target chip only has flipflops which can respond on one edge.
The process you have written is sensitive to changes in clock due to this line:
process(clock)
so it is sensitive to both clock edges.
You have then put part of the code inside an
if rising_edge(clock) then
which limits activity to just the rising edge, which is good. The rest of your code is unfortunately outside of that if clause, and so is described as operating on every edge of the clock, either rising or falling. In simulation this will be fine, but the synthesiser cannot find any flipflops which can do that, hence the error.
Other things to note - you need to reset or initialise your counter somehow. Either with a reset signal, so that any time the reset signal is high, the counter is set back to all zeros. Or using an initialisation statement.
You can get away without them for pure synthesis, as the sythesiser will (in the absence of init or reset code) automatically set the counter to all zeros when the FPGA starts up. It's poor-form though as:
it won't work in simulation and simulation is vital. You may not have realised this yet, but you will eventually!
if you port the code to another architecture which cannot magically initialise things, you wil get random 1s and 0s in the counter at startup. This may or may not matter, but it's best to avoid having to decide.
Besides the bad synchronous description there is also bad coding style :)
First off all you should not use variables in a process if you want to describe a counter. So use a signal declared in the architecture region.
2.
Decide what signal type you want to use for counters: unsigned or integer. I would advice unsigned.
3.
Signal A is not in the sensitivity list. But adding A to the sensitivity list of your process is no solution, because having two different clocks (clock and A) in one process is (a) not supported by every synthesis tool and (b) bad coding style => so use a second process for the second counter which is using a second clock.
4.
You are using A in a 'if rising_edge(...) then' statement. Synthesis tools would infer a (new) clock signal for the signal given in brackets. So your description would lead to an asynchronous description which is also bad style. A good style would be to derive a clock enable signal from fcounter(x) which enables a second counter (counter_A). counter_A is also clocked with your main clock 'clock'
5.
fcounter has no init value despite it's a register.
6.
Why has fcounter 25 bits? you are using only 7 bits.
Besides that, using bit 6 in fcounter(6) will result in a by 128 (2^7) divided clock.
Using fcounter(0) represents a toggle flip flop, which outputs f/2. fcounter(1) -> f74 and so on...
So, how should it look like?
architecture [...]
[...]
signal fcounter : unsigned(6 downto 0) := (others => '0');
signal counter_a : unsigned(5 downto 0) := (others => '0');
begin
process(clock)
bein
if rising_edge(clock) then
-- I'm using one more bits for the counter overflow, which resets the fcounter
if (fcounter(6) = '1') then
fcounter <= (others => '0');
else
fcounter <= fcounter + 1;
end if;
-- enable counter_A every 64 cycles
if (fcounter(6) = '1') then
counter_A <= counter_A + 1;
[...]
end if;
end if;
end process;
end;
But in the end there is another question: What should this module do? Do you want to create a new /64 clock or do you want to create some kind of a reset? There are other ways to generate these kinds of signals.
Reply to Mehmet's comment:
Normally a pulse train is generated by a shift register of n bits, which is reseted to all ones and the input is assigned with '0'. For short pulse trains it's a good solution, but in your case a counter is more resource efficient :)
Example for short pulse (constant) trains
input <= '0';
--input <= any_signal;
process(clock)
begin
if rising_edge(clock) then
if (reset = '1') then
pulse_train <= (others => '1');
else
pulse_train <= pulse_train(pulse_train'high - 1 downto 0) & input;
end if;
end if;
end process;
output <= pulse_train(pulse_train'high);
Ok, in the case of supplying an external low frequency IC with a derived clock, it's ok to use a counter. If the counter can't supply the recommended frequency and duty cycle, you can use a counter to produce f_out*2 and feed this signal through a toggle flip flop. The T-FF restores the duty cycle to 50/50 and divides the clock by two to f_out.
I get the following error with MPICH-2.1.5 and PGI compiler;
Fatal error in PMPI_Waitall: Invalid MPI_Request, error stack:
PMPI_Waitall(311): MPI_Waitall(count=4, req_array=0x2ca0ae0, status_array=0x2c8d220) failed
PMPI_Waitall(288): The supplied request in array element 0 was invalid (kind=0)
in the following example Fortran code for a stencil based algorithm,
Subroutine data_exchange
! data declaration
integer request(2*neighbor),status(MPI_STATUS_SIZE,2*neighbor)
integer n(neighbor),iflag(neighbor)
integer itag(neighbor),neigh(neighbor)
! Data initialization
request = 0; n = 0; iflag = 0;
! Create data buffers to send and recv
! Define values of n,iflag,itag,neigh based on boundary values
! Isend/Irecv look like this
ir=0
do i=1,neighbor
if(iflag(i).eq.1) then
ir=ir+1
call MPI_Isend(buf_send(i),n(i),MPI_REAL,neigh(i),itag(i),MPI_COMM_WORLD,request(ir),ierr)
ir=ir+1
call MPI_Irecv(buf_recv(i),nsize,MPI_REAL,neigh(i),MPI_ANY_TAG,MPI_COMM_WORLD,request(ir),ierr)
endif
enddo
! Calculations
call MPI_Waitall(2*neighbor,request,status,ierr)
end subroutine
The error occurs when the array_of_request in mpi_waitall gets a null value (request(i)=0). The null value in array_of_request comes up when the conditional iflag(i)=1 is not satisfied. The straight forward solution is to comment out the conditional but then that would introduce overheads of sending and receiving messages of 0 sizes which is not feasible for large scale systems (1000s of cores).
As per the MPI-forum link, the array_of_requests list may contain null or inactive handles.
I have tried following,
not initializing array_of_requests,
resizing array_of_request to match the MPI_isend + MPI_irecv count,
assigning dummy values to array_of_request
I also tested the very same code with MPICH-1 as wells as OpenMPI 1.4 and the code works without any issue.
Any insights would be really appreciated!
You could just move the first increment of ir into the conditional as well. Then you would have all handles in request(1:ir) at the and of the loop and issue:
call MPI_Waitall(ir,request(1:ir),status(:,1:ir),ierr)
This would make sure all requests are initialized properly.
Another thing: does n(i) in MPI_Isend hold the same value as nsize in the corresponding MPI_Irecv?
EDIT:
After consulting the MPI Standard (3.0, Ch. 3.7.3) I think you need to initialize the request array to MPI_REQUEST_NULL if you want give the whole request array to MPI_Waitall.
Given a Windows socket, I want to determine which values it is using for the TCP keepalive idle time and the TCP keepalive interval time (roughly equivalent to the TCP_KEEPIDLE and TCP_KEEPINTVL settings on Berkeley sockets).
I see that you can set these values using a WSAIoctl call (see http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220%28v=vs.85%29.aspx ). However, there does not appear to be any API for reading their current values. I tried calling WSAIoctl with a populated output parameter but NULL input parameter, like this:
DWORD bytes_returned;
struct tcp_keepalive keepalive_opts;
int rv = WSAIoctl(socket, SIO_KEEPALIVE_VALS, NULL, 0, &keepalive_opts, sizeof(keepalive_opts), &bytes_returned, NULL, NULL);
But this returns me a WSAEFAULT ("The system detected an invalid pointer address in attempting to use a pointer argument in a call.").
I could call WSAIoctl with both an input and an output parameter, but I don't want to set the values, I just want to read them. And as far as I can tell, providing any non-NULL input parameter would cause the parameters to be set to whatever values happen to be in that memory space (defined by the struct tcp_keepalive; again see http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220%28v=vs.85%29.aspx ).
The above also highlights another problem with not knowing what the current values are: I can't set just one of the keepalive idle time or the keepalive interval time - I must blow away both (unknown) values at the same time since they're both members of the struct I'm required to provide.
I know that I could assume things about what values are set based on Windows documentation, but I'd rather not assume. I see that http://technet.microsoft.com/en-us/library/bb726981.aspx#EDAA defines KeepAliveInterval and KeepAliveTime default values. However, the Parameters folder in my Windows 7 registry does not contain either of those keys, so I really have to rely on the documentation being 100% correct here (to know the default values a socket will receive), which is much worse than programmatically retrieving them (even retrieving them from the registry might be ok, but the above experience shows I can't).
Is there any way to get the current TCP keepalive idle time and the TCP keepalive interval time values for a Windows socket?
Unlike TCP_KEEPIDLE and TCP_KEEPINTVL, which can be used with getsockopt(), there is no way to read the current SIO_KEEPALIVE_VALS values for a socket, only to set them.