![]() |
|
|
|
#1 |
|
Hello
I found some strange behaviour in ISE WebPack 8.2.03i when trying to synthesize the following VHDL-Code for an XC9572 CPLD: Port-modes: OUT: buffer, IN1/2: in OUT <= '0' when IN1 = '1' else '1' when IN2 = '1' else OUT; ISE generates the following warning: Removing unused input(s) 'IN1'. The input(s) are unused And indeed, Signal IN1 does not work. The RTL/Technology-Schematic shows everything as expected, IN1 is connected properly, but the fitter seems to "optimize" it away later in the process. I am aware that there are other, better ways to achieve the intended behaviour, but I wonder if ISE is right with what it does here and if so, why? Thanks for listening, Florian Florian Heinz |
|
|
|
|
#2 |
|
Posts: n/a
|
Florian Heinz wrote:
> Hello > > I found some strange behaviour in ISE WebPack 8.2.03i when trying to > synthesize the following VHDL-Code for an XC9572 CPLD: > > > Port-modes: OUT: buffer, IN1/2: in > > OUT <= '0' when IN1 = '1' else > '1' when IN2 = '1' else > OUT; > > ISE generates the following warning: > Removing unused input(s) 'IN1'. The input(s) are unused > > And indeed, Signal IN1 does not work. > The RTL/Technology-Schematic shows everything as expected, IN1 is > connected properly, but the fitter seems to "optimize" it away later > in the process. > I am aware that there are other, better ways to achieve the intended > behaviour, but I wonder if ISE is right with what it does here and if > so, why? > > Thanks for listening, > > Florian You've got a combinatorial loop here involving the signal OUT. ISE is probably getting messed up because of it (I'm not sure what you intention is either). Also, I'm surprised it let you use OUT as a signal name, since 'out' is a reserved word. perhaps: output_driver <= '0' when IN1='1' else '1' when IN2='1' else 'Z'; was more like what you intended? this drives the output to hi_Z when neither IN1 nor IN2 are high. Or were you really looking to have a circuit with memory here? Combinatorial loops are poor form, and are prone to timing problems even if you coax the tool into dealing with them correctly. |
|
|
|
#3 |
|
Posts: n/a
|
On 2006-11-21, Ray Andraka <> wrote:
> You've got a combinatorial loop here involving the signal OUT. ISE is > probably getting messed up because of it (I'm not sure what you > intention is either). It's a Flipflop. > Also, I'm surprised it let you use OUT as a signal > name, since 'out' is a reserved word. Right, read "OUT1". > > perhaps: > > output_driver <= '0' when IN1='1' else '1' when IN2='1' else 'Z'; > > was more like what you intended? this drives the output to hi_Z when > neither IN1 nor IN2 are high. Or were you really looking to have a > circuit with memory here? Yes, for example this works as expected: OUT1 <= IN1 nor OUT2; OUT2 <= IN2 nor OUT1; > Combinatorial loops are poor form, and are prone to timing problems even > if you coax the tool into dealing with them correctly. As I wrote, I am aware of these problems. But do you really think, it's ok that ISE behaves like that? Florian |
|
|
|
#4 |
|
Posts: n/a
|
sky schrieb:
[quote extended] >>> OUT <= '0' when IN1 = '1' else >>> '1' when IN2 = '1' else >>> OUT; >> (I'm not sure what you >> intention is either). > > It's a Flipflop. No, it is a latch, reset with IN1, set with IN2 and retaining its value otherwise. Why do you model it this may? It would be equivalent to do it this way (note that I have changed the name OUT to OUT1): OUT1 <= '0' when IN1 = '1' else '1' when IN2 = '1'; So you don't need OUT1 to be an output signal of type buffer. Seems to be an RS-latch without the forbidden state. Am I right? Ralf |
|