In Linux, after a signal is generated asynchronously, there are couple controls whether/when the signal is handled:
1. signal mask
This mask can be controlled by user programming.
2. task_struct's state can be TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE which allows or blocks signal
My impression is this is controlled by kernel, so user programming cannot control.
And there is no 3rd control whether/when a signal is handled.
Is my above understanding correct?
Related
I wrote some VHDL code and I wrote a simple sequential code defining a clock sensitive process. Whenever the clock rises from low to high I check another signal in the architecture and I do stuff depending on its value. Nevertheless, this signal transitions at the same time instant as the rising edge of the clock occurs.
In simulation, when the rising edge arises, the system always samples the signal value before its transition. My question is: how does this work out once the code is implemented on the corresponding FPGA? Does it produce unpredictable sampling of the signal value? Do you advice to always avoid this type of scenario within a VHDL architecture?
I am working on implementing a DDR SDRAM controller for a class and am not allowed to use the Xilinx MIG core.
After thrashing with the design, I am currently working synchronously to my system clock at 100MHz and creating a divided signal "clock" (generated using a counter) that is sent out on the IO pins to DDR SDRAM. I have some logic that feeds me the "rising" edge strobes of this signal clock as I am aware that I cannot use a signal to clock a process. However, this divided clock method runs very slow and I have concerns that I am not meeting the minimum required frequency of the external DDR SDRAM. I am hoping to speed up my read/write bursts, but to do so, my spartan3e will struggle with anything higher than 100MHz. After looking around online, I found this code from EDA Board:
process(Input_Clk,Reset_Control)
begin
if (Reset_Control = '1') then
Output_Data <= (others => '0');
elsif rising_edge(Input_Clk) then
Output_Data <= Input_Data1;
elsif falling_edge(Input_Clk) then
Output_Data <= Input_Data2;
end if;
end process ;
I have written a lot of VHDL, but have never seen something like this before. I'm sure this works fine in simulation, but it doesn't look synthesizable to me. The poster said this should be supported by 1076.6-2004. Does this infer two flip-flops, one clocked on the rising edge and one on the falling edge whose outputs both feed into a 2:1 mux? Does Xilinx support this? I want to avoid having to instantiate a DCM as crossing these clock domains will definitely slow me down and will add undesired complexity. Is there a way to safely generate my DDR data that is being sent to and received from DDR SDRAM without the Xilinx primitive for the MIG? How would I perform the receiving of DDR data in Verilog?
For reference, we have to code in Verilog, so I'm not too sure on how to translate that VHDL process to a Verilog always block if it is synthesizable. We are using the Micron MT46V32M16 if that is relevant.
Here are the timing diagrams for what I am trying to replicate:
I would say that implementing a DDR controller 'for class' is rather challenging. In the companies I worked for they where left for senior engineers to build.
First about the Verilog code shown:
Yes, you are right that can not be synthesized.
The approach to double-clocking inputs is to have two data paths. One on the rising edge and one on the falling edge. In a second stage the two are put in parallel but with double the data width. Thus a 32-bit wide DDR produces 64 data bits per 'system' clock.
More difficult is to clock the arriving data at the right time. As your read diagram shows the data arrives in the middle of the clock edge. For that you need a delayed clock. In an ASIC that is done using a 'tune-able' delay line which is calibrated at start-up and regularly checked for the phase. In an FPGA that would requires some esoteric logic.
I have not been close to DDRs chips for a while, but I think all the modern ones (DDR2 and up?), output a clock themselves to help with the read data.
Also after you have clocked the read data in, using that shifted clock, you have to get the data back to the system clock which requires an asynchronous FIFO.
I hope that gets you started.
i want to slow down clk...and take input
entity q1 is
Port ( clk: in std_logic;
a0,a1,a2,a3,a4,a5,a6,a7,a8,a9 : in STD_LOGIC_VECTOR (3 downto 0);
b0,b1,b2,b3,b4,b5,b6,b7,b8,b9 : in STD_LOGIC_VECTOR (3 downto 0);
y0,y1,y2,y3,y4,y5,y6,y7,y8,y9 : out STD_LOGIC_VECTOR (6 downto 0));
end q1;
architecture Behavioral of q1 is
signal counter : std_logic_vector(9 downto 0)='0000000000';
signal clk_en: std_logic='0';
process(clk)
begin
if (clk'event and clk='1') then
counter <= counter +1;
if (counter = 0) then
clk_en <= '1';
else clk_en='0'
end if ;
end if;
end process;
end Behavioral;
an elaborated VHDL design executes proccesses
IEEE Std 1076-2008:
11. Concurrent statements, 11.1 General, para 1:
...Concurrent statements are used to define interconnected blocks and processes that jointly describe the overall behavior or structure of a design. ...
And
Elaboration and execution 14.1 General:
The process by which a declaration achieves its effect is called the elaboration of the declaration. After its elaboration, a declaration is said to be elaborated. Prior to the completion of its elaboration (including before the elaboration), the declaration is not yet elaborated.
Elaboration is also defined for design hierarchies, declarative parts, statement parts (containing concurrent statements), and concurrent statements. Elaboration of such constructs is necessary in order ultimately to elaborate declarative items that are declared within those constructs.
In order to execute a model, the design hierarchy defining the model shall first be elaborated. Initialization of nets (see 14.7.3.4) in the model then occurs. Finally, simulation of the model proceeds. Simulation consists of the repetitive execution of the simulation cycle, during which processes are executed and nets updated.
14.2 Elaboration of a design hierarchy, para 1:
The elaboration of a design hierarchy creates a collection of processes interconnected by nets; this collection of processes and nets can then be executed to simulate the behavior of the design.
Every concurrent statement is elaborated as a process (process statements, concurrent procedure calls, concurrent assertion statements, concurrent signal assignments) or hierarchy of blocks and processes (generate statements, component instantiations and block statements).
A process is not a routine, it isn't called. Rather it is suspended and resumed. It will wrap from the last statement to the first (goto or jump, not call).
How many processes can be held in a model isn't a matter of whether it is structural or behavioral - all VHDL models are behavioral, the distinction between the two is style not execution.
Along with a resumption address process resumption is controlled by sensitivity to events or simulation time. When a process suspends is controlled by the algorithm it implements.
simulation
14.7 Execution of a model
14.7.1 General, para 1:
The elaboration of a design hierarchy produces a model that can be executed in order to simulate the design represented by the model. Simulation involves the execution of user-defined processes that interact with each other and with the environment. ...
Execution of a processes statements can occur concurrently with any other process in a model. There is no guaranteed execution order and if they aren't concurrently executed the simulation cycle treats them as if they were.
No signal assignment occurs when any process is executing. When all processes have suspended any projected output waveform scheduled signal assignments are evaluated and the next time at which a signal update is scheduled is determined. Simulation time is advanced to that time. A signal assignment scheduled to occur after 0 simulation time units occurs in the next delta cycle. When there are no further updates scheduled simulation time is advanced to the maximum time value and simulation ends.
how many processes
How many processes is implementation limitation, based more on CPU architecture (address space, size of address pointers). How many processes there can be is dependent on the total number of addressable things, model code and their size versus the size of pointers and the amount of executable code needed to support the simulation - the host operating system routines in the simulation model's memory space. The host's ability to deal with virtual memory.
Address space is commonly associated with a CPU's word size. It's implementation dependent and not a VHDL language definition limitation.
The consequence of implementation limitations affects portability.
portability
Annex D,
(informative),
Potentially nonportable constructs, paras 1:
This annex lists those VHDL constructs whose use may result in nonportable descriptions.
A description is considered portable if it
a) Compiles, elaborates, initializes, and simulates to termination of the simulation cycle on all conformant implementations, and
b) The time-variant state of all signals and variables in the description are the same at all times during the simulation,
under the condition that the same stimuli are applied at the same times to the description. The stimuli applied to a model include the values supplied to generics and ports at the root of the design hierarchy of the model, if any.
VHDL design specifications can be non-portable between implementations based on implementation limitations. Annex D enumerates non portable constructs that defined in the language definition, which does not include implementation limitations.
I'm still learning VHDL for synthesis purposes on a custom Xilinx Spartan-6 based board. My design includes a lot of FSM and I've just learned in a previous question that the single process implementation is a lot better and much easier to use.
I also learned that initialization values for signals are actually synthetizable.
So here is the question: do I really need a reset signal to put the FSM in idle with default outputs, IF I don't need to interrupt the FSM mid flow OR I already have another signal that stops it?
let's see what is the Xilinx appraoch on reset :
Xilinx FPGA includes "Global Set/Reset" module which automatically set all signals at their initialisation values at start-up. The initialisation value is declared as follow:
signal foo : std_logic := '0';
-- ^ initialisation value
When designing a new part of code, you have to think twice for each bit if it needs to be reset by something else than the GSR, because using your own global reset is actually using a second global reset.
For your FSM, it has a startup state (IDLE) and will never be reset in the whole bitstream life. We can say at first that the FSM do not need a reset. But if you just do it like it, you'll be exposed to metastability issues. The GSR is quite slow to deassert its reset and it does it asynchronously. All flip-flop won't be released at the same time and your FSM can go in an illegal state.
So, use a local reset for your FSM (and counters as well).
To complete the reset question:
avoiding the use of global reset has better place and route result, which leads to less timing errors. A global reset uses the same network as others signals in the design, it prevents some routing resource to be available for other signal distribution.
if you really need the use of a reset, prefer an active high synchronous reset or at least an active high reset, activated asynchronously and deactivated synchronously. Active High because Xilinx Flip-Flop uses active high SET and RESET, synchronous to avoid metastability problem.
Workaround:
A solution to avoid the local reset on the FSM could be the use of a bufgce module at clock entry. At startup, this module do not feed the design with the clock and wait for some clock cycles before enabling the clock. Only a local reset is used here to manage the enable input of the BUFGCE and the reset of the FGPA is reset free.
I don't know how many clock cycles have to be waited, but it can do it. The first approach is still the best for now.
If your state variable is initialised to 'idle', then having a reset which forces it to 'idle' is only useful if you need it for some other reason. One major example would be if the state machine has states, where, on noticing an erroneous input, it deliberately stops to wait for something to reset it, before resuming normal operation.
The machine might also be running from a clock that is not guaranteed to be glitch free, or is for some reason not 100% reliable. In this case it can be sensible to include a reset, so that something like a host processor or other FPGA logic can somehow detect that the state machine is no longer working, and reset it.
Lots of people seem to have a reset signal in most processes they write, but it's perfectly valid to rely on signal and output initialisation values, if the machine then meets your design requirements. If all the reset does is assert itself briefly during startup, and never again, I would say there's not much point in it.
[EDIT] Per other answers, relying on initialisation values is normally only valid in SRAM-based FPGA designs.
There are a couple of white papers from Xilinx that address the issue and they actually show up as the first two items googling for Xilinx reset.
These are WP272 Get Smart About Reset: Think Local, Not Global and WP275 Get your Priorities Right – Make your Design Up to 50% Smaller.
The first paper does a fair job of pointing out where you should use a reset as opposed to where you can depend on configuration and default values.
The second paper also points out that the reasons why are vendor and technology dependent. You could also note the reason for eliminating 'unnecessary' resets is to preserve place and route resources.
Because you don't elaborate the details of a Finite State Machine implementation while asking if the reset is really necessary, note the claim in WP272 where an asynchronous reset can be deleterious for a One Hot State Machine which would benefit from configuration load (a default value), synchronous reset or a clock synchronized asynchronous reset.
Your VHDL code with (proper) resets is ultimately more portable, should your design ever be intended for an ASIC or some other non- bit image loaded solutions. For those soft loaded designs the ultimate reset is embodied in a configuration load.
Otherwise the purpose is to conserve place and route resources.
I am writing interputs for a fpga and dsp need to interact with a dual port memory shared dpram control in vhdl.
I have External IOs coming from the SPI bus on oneside to the fpag to be communicated with dsp and on the otherhand have a camera to the to the dsp.
So my intrups are like Havinf a FIFO being reset after everytime a FSM reads and writes the interrpts with dsp.
Now my problem is
I want to enable some particular interupts at a time and disable the others.
When make a masking with logical XOR function the other interupts coming from UART goes for a timeout.
When this is done the camera gets the signal but cant be controlled.
I use the following algorithm to deal with all asynchron inputs:
In event2reg_array_proc: save all inputs to parallel buffers “fifo_data_input_array”, each input(flag) should be put into separate buffer.
In reg_array2fifo_proc2: read each buffer serially and save them in a fifo “fifo320x32”.
In main FSM read the output from fifo and do the suitable processing, each cycle read out only one value, it should be one flag.
If you get some flags which remains in register even after processing, the reason can be:
In event2reg_array_proc: and reg_array2fifo_proc2:, if one flag (in buffer) has been written in the fifo, it should be cleared from the buffer. I use the “fifo_cnt” to control this. You can use simulation to check.
Line Camera sends the FRAME_VALID signal as same as the LINE_VALID signal, so you can get a lot of CAM2DSP_FRAME_SYNC_FLAG with Line Camera.
So can any one suggest any algorithm to enable particular interupts while the the camera is still communicating with DSP.
Your question is not clearly worded enough to enable a proper answer.
But one point is clear : XOR is not a good choice for an interrupt mask!
Either AND or OR would be a better choice depending on the logic of the interrupt handler.