Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

help for signal_quiet attribute

Status
Not open for further replies.

sresam89

Member level 2
Joined
Sep 9, 2009
Messages
48
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,576
i used a code

x:=ORFLAG'QUIET(400 ns)

xilinx shows an error
"The predefined attribute QUIET is unsupported"

can anyone help.am i not using any special pacakages for this?
what should i be looking for?
 

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,076
Helped
2,078
Reputation
4,173
Reaction score
2,032
Trophy points
1,393
Activity points
39,237
you cannot use the 'quiet attribute in synthesisable code (thats why you're getting an unsupported error). You can only use it in simulation.

Also, Quiet is in no way appropriate for synthesisable code, because it checks transactions, not changes to the signal. A transaction occurs every time a signal is assigned, not just when it changes.

so in this code:

Code:
process(clk)
begin
  if rising_edge(clk) then
    output <= '0';
  end if;
end process;

a transaction occurs on every clock cycle, so the output is only "QUIET" for the period between clocks.
 

sresam89

Member level 2
Joined
Sep 9, 2009
Messages
48
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,576
you cannot use the 'quiet attribute in synthesisable code (thats why you're getting an unsupported error). You can only use it in simulation.

so what would be the alternative to see the changes.

Also, Quiet is in no way appropriate for synthesisable code, because it checks transactions, not changes to the signal. A transaction occurs every time a signal is assigned, not just when it changes.a transaction occurs on every clock cycle, so the output is only "QUIET" for the period between clocks.

what is the difference between TRANSACTION and CHANGES you mention to? i thought both of them were same.

please suggest an alternative to check for any changes in the signal ORFLAG after 500 ns.(code as such would be of great help)
 

TrickyDicky

Advanced Member level 5
Joined
Jun 7, 2010
Messages
7,076
Helped
2,078
Reputation
4,173
Reaction score
2,032
Trophy points
1,393
Activity points
39,237
Alternatives, you will have to build a circuit that detects if the signal has changed. Almost none of the attributes are synthesisable.

As for transactions - a transaction occurs whenever a signal is assigned. So with this code:

a <= '0';
wait for 0 ns;
a <= '0';
wait for 0 ns;
a <= '0';

3 transactions have occured, but 0 events (changes, but thats the 'event attribute) have occured. But transactions are not synthesisable (they are for simulation purposes).

The code you need will depend on your clock speed.
Method 1: You will need a pipeline long enough to store a 500ns history and then check that all the bits along the pipeline are the same. If the clock speed is high, thats quite a lot of registers.
Method 2: Have a counter running that resets every time the signal changes. When the counter gets to a certain number (high enough to cover 500ns) you know it has not changed for long enough.
 

sresam89

Member level 2
Joined
Sep 9, 2009
Messages
48
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,576
Alternatives, you will have to build a circuit that detects if the signal has changed. Almost none of the attributes are synthesisable.

As for transactions - a transaction occurs whenever a signal is assigned. So with this code:

a <= '0';
wait for 0 ns;
a <= '0';
wait for 0 ns;
a <= '0';

3 transactions have occured, but 0 events (changes, but thats the 'event attribute) have occured. But transactions are not synthesisable (they are for simulation purposes).

The code you need will depend on your clock speed.
Method 1: You will need a pipeline long enough to store a 500ns history and then check that all the bits along the pipeline are the same. If the clock speed is high, thats quite a lot of registers.
Method 2: Have a counter running that resets every time the signal changes. When the counter gets to a certain number (high enough to cover 500ns) you know it has not changed for long enough.

all the above for finding stuck at faults for basic gates. can you give a reference for the same or a code sample.help of any kind for this fault finding is truly appreciated...
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top