Hi,

I am trying to implement a combinational logic using agtes such that the output goes high on high output from Comp_1(High level comparator) and remains high till the signal from Comp_2( Low level Comparator) goes low. Can any one help me out on this issue as with the setup (attached) the output is high when the Comp_1 output is high but the output switches to low as soon as the comp_1 goes low.

 The logic to be implemented is  Out= High+(Out*low)

I try to write this as a truth table:

C1 C2 out
0  0  0
0  1  0
1  0  0
1  1  1

Is this right? Then you need a AND gate - but this will result in what you described: when C1 goes low so does the output.

Or do want to have a time-sensitive logic? Then you need a DFF: connect C1 to its Clock-Input, a logic 1 to the D input, and the inverted C2 to the reset input.

That way, the rising flank of C1 will set the output to 1, and it will stay there even if C1 goes low again. When C2 goes low, it will reset the DFF so the output goes low againb.

That circuit works when implemented using discrete logic files because of propagation delays but inside PSOC it might be optimised out diferently.

You need to use a FF to store the previous state.

I cannot look at any of these images, I always get an error message:

The request has exceeded the allowable time limit Tag: CFQUERY

How should Comp_2 behave: when it gioes low, the output goes low. But when it goes high again, should the output still stay low?

I would implement it this way:

(which is what I explained above). Feeding back the out signal to the enable input will only ensure that the DFF triggers once, because after that the clock input will be ignored).

Seems like a bit of a guessing game going on.

Some questions -

1) Comparators looking at same signal ? Or two different signals ?

2) Can you provide a state diagram :? Your logic expression confers

simple combinatorial logic, no delay elements.....This would also give forum

init state as well as reset state/conditions.

3) Timing diagram ?

4) Analog signal origin, type, bandwidth....

Regards, Dana.

@dana: the logic expression uses 'out' both as input and output, so there is clearly delay involved...

  PSOC73's pictures are spot-on, unfortunatelly they require a clock signal. 

HLI's solution is great, but what happens at power on?

UDB's FF's are initialized to a 0 value. Therefore, there might a malfuntion if at power on comp1 output is high and the FF output will still be low. Logic should be added to ensure it is initialised high if comp1 is high.

I think the easiest way would be to build a custom UDB component, a couple of always@(posenge A or B) would do the trick

I stand corrected, the delays are implicit, not explicit. Not only that I missed

schematic posted, and delay discussion in original description. Time for a vacation.

Looking at top level schematic originally posted, any reason not to do entire

design with a A/D and some code to effect thresholds and "levels" detected.

Which rasies what are the signal properties ? Again what is function being sought

for design.

Regards, Dana.

Don't forget, if you can do it with A/D and code, the A/D's input buffer

can amp by a factor up to 8, eg. eliminate the PGA in the design as well.

Regards, Dana.

@zeta: the comparators will only run when they are activated in software. At this moment, the FF should be ready, so everything should work OK (because only then the comparator will compare, and will generate the low-to-high-transition).

But this looks to me like a comparator with hysteresis: assert the output when a certain threshold (temperature maybe) is reached, and only de-assert it when a certain, lower, threshold is crossed.

maybe @rats can shed some light on this?

@dana: the problem with using an ADC is that it relies on software. The reaction times of the comparators are lower then the conversion period of even the SAR ADC, so they won't miss even small glitches. Also, using the ADC means that you will spend a significant amount of CPU time in the IRQ, since you cannot use DMA then...

But if we are talking about slow-moving signals, one can spend software to save hardware resources. But Bob would say 'this is not the PSoC way' :)

Right now the forum is spending a lot of time guessing what thread orginator

is dealing with, design goals, etc..That includes me.

Lets get more comprehensive design goals, functionality, before we draw any

more conclusions, or continue with guess of the minute.

Regards, Dana.

Comparator response times not exacly smoking in a 66 Mhz system. But again we do not know

what the design goals are.

"Also, using the ADC means that you will spend a significant amount of CPU time in the IRQ,

since you cannot use DMA then... But if we are talking about slow-moving signals, one can

spend software to save  hardware resources. But Bob would say 'this is not the PSoC way' :)"

Are we talking about a 1 Hz signal, or a 100 Mhz signal, none of us know......? The tradeoff of

HW vs SW is fairly well understood. We know the A/D has more precision than the comparator,

but is slow, all things considered, but what are the design constraints......?

 Hi everyone,

The project in hand involves the detectionof a upper threshold and keeping the output high till a lower threshold is detected. Further the output shold become high only on detection of the upper threshold and not on overcoming the lower threshold. 

From my basic knowledge I think that the use of ADC would involve higher delay than using of comparator

Thankyou

So it is like a Comparator with hysteresis? (Asserting the output when a threshold is reached, but de-asserting it only when a certain other, loer, threshold is crossed)

@Rats, what is the nyquist rate of the signal you are dealing with ?

What is the max rate at which you would like the detection to operate at ?

Also what is the signal from ? Basically a functional description of what

you are trying to detect and why, if not proprietary.

Regards, Dana.

This project is a part of the project intended  to work as a window comparator to extract only those signals that lie between the upper and lower threshold settings. any signal crossing the upper threshold are to be rejected. This module will be used as the front end for a radiation spectrometry peak detection module. The signal here is being derieved from a preamplifier whose output is a semigaussian pulse with a pulse duration of 2-5 microseconds. the input frequency is random in nature with a max consideration of about 4 Mhz.

This project is a part of the project intended  to work as a window comparator to extract only those signals that lie between the upper and lower threshold settings. any signal crossing the upper threshold are to be rejected. This module will be used as the front end for a radiation spectrometry peak detection module. The signal here is being derieved from a preamplifier whose output is a semigaussian pulse with a pulse duration of 2-5 microseconds. the input frequency is random in nature with a max consideration of about 4 Mhz.

With 4 Mhz signal comparator approach with logic/lut makes sense,

as A/D approach simply not fast enough, especially with decision

code necessary.

Regards, Dana.

What you now described dsiffers from what you asked in the beginning. Now it looks like a normal window comparator: the output is true when the signal is higher than the lower threshold (the lower comparator is true), but less than the upper threshold (the upper comparator is false). This has no timing component in it.

Or is the logic in that when a signal has crossed the upper threshold, you need to ignore it until it has fallen down below the lower threshold?

Btw: note that a 4 MHz signal is pushing the comparator to its limits: with only 50 mV overdrive, it has a response time of (worst case) 100 nS, which is about 9 MHz.