Using GCK pin as both clock and signal (Spartan 2)

if falling_edge(clock2) then
	out2 <= data2;
end if;

if clock2='0' then out1 <= 'Z';
elsif falling_edge(clock1) then out1 <= data1;
end if;

(This is just a sample VHDL)

Clock2 is used both as a GCK and as a signal.

ISE (10.1) complains on Spartan 2.


I've tried replacing clock2 with clock2a:
	signal clock2a : STD_LOGIC;

	component ibufg port (
		O : out STD_LOGIC;
		I : in  STD_LOGIC);
	end component;

	attribute box_type : string;
	attribute box_type of ibufg : component is "black_box";

	temporary : ibufg port map (I => clock2, O => clock2a);

From the manual: "The IBUFG can be routed to your choice of logic
to allow the use of the dedicated clock pins for general logic."
Am I using it the correct way?


I've also tried variations of buffer_type, no luck either.
	attribute buffer_type: string;
	attribute buffer_type of clock2: signal is "bufgp";


Even if I get it to work on this small example, ISE always
complains on the complete project.

Currently, I connect clock two 2 pins, GCK and a IOB, but this
can probably be avoided. How?

You probably don't want what you are describing, so please explain why
you need that particular construct. Further, what you are describing
cannot be constructed from logic components, so please explain how you
expect that to be implemented in your FPGA.

- Nathan

On Oct 16, 7:03=A0am, aleksa <aleks...@gmail.com> wrote:
> if falling_edge(clock2) then
> =A0 =A0 =A0 =A0 out2 <=3D data2;
> end if;
>
> if clock2=3D'0' then out1 <=3D 'Z';
> elsif falling_edge(clock1) then out1 <=3D data1;
> end if;
>
> (This is just a sample VHDL)
>
> Clock2 is used both as a GCK and as a signal.
>
> ISE (10.1) complains on Spartan 2.
>
> I've tried replacing clock2 with clock2a:
> =A0 =A0 =A0 =A0 signal clock2a : STD_LOGIC;
>
> =A0 =A0 =A0 =A0 component ibufg port (
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 O : out STD_LOGIC;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I : in =A0STD_LOGIC);
> =A0 =A0 =A0 =A0 end component;
>
> =A0 =A0 =A0 =A0 attribute box_type : string;
> =A0 =A0 =A0 =A0 attribute box_type of ibufg : component is "black_box";
>
> =A0 =A0 =A0 =A0 temporary : ibufg port map (I =3D> clock2, O =3D> clock2a=
);
>
> From the manual: "The IBUFG can be routed to your choice of logic
> to allow the use of the dedicated clock pins for general logic."
> Am I using it the correct way?
>
> I've also tried variations of buffer_type, no luck either.
> =A0 =A0 =A0 =A0 attribute buffer_type: string;
> =A0 =A0 =A0 =A0 attribute buffer_type of clock2: signal is "bufgp";
>
> Even if I get it to work on this small example, ISE always
> complains on the complete project.
>
> Currently, I connect clock two 2 pins, GCK and a IOB, but this
> can probably be avoided. How?

On Oct 16, 5:12=A0pm, Nathan Bialke <nathan.bia...@gmail.com> wrote:
> You probably don't want what you are describing, so please explain why
> you need that particular construct. Further, what you are describing
> cannot be constructed from logic components, so please explain how you
> expect that to be implemented in your FPGA.
>
> - Nathan
>
> On Oct 16, 7:03=A0am, aleksa <aleks...@gmail.com> wrote:
>
>
>
> > if falling_edge(clock2) then
> > =A0 =A0 =A0 =A0 out2 <=3D data2;
> > end if;
>
> > if clock2=3D'0' then out1 <=3D 'Z';
> > elsif falling_edge(clock1) then out1 <=3D data1;
> > end if;
>
> > (This is just a sample VHDL)
>
> > Clock2 is used both as a GCK and as a signal.
>
> > ISE (10.1) complains on Spartan 2.
>
> > I've tried replacing clock2 with clock2a:
> > =A0 =A0 =A0 =A0 signal clock2a : STD_LOGIC;
>
> > =A0 =A0 =A0 =A0 component ibufg port (
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 O : out STD_LOGIC;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I : in =A0STD_LOGIC);
> > =A0 =A0 =A0 =A0 end component;
>
> > =A0 =A0 =A0 =A0 attribute box_type : string;
> > =A0 =A0 =A0 =A0 attribute box_type of ibufg : component is "black_box";
>
> > =A0 =A0 =A0 =A0 temporary : ibufg port map (I =3D> clock2, O =3D> clock=
2a);
>
> > From the manual: "The IBUFG can be routed to your choice of logic
> > to allow the use of the dedicated clock pins for general logic."
> > Am I using it the correct way?
>
> > I've also tried variations of buffer_type, no luck either.
> > =A0 =A0 =A0 =A0 attribute buffer_type: string;
> > =A0 =A0 =A0 =A0 attribute buffer_type of clock2: signal is "bufgp";
>
> > Even if I get it to work on this small example, ISE always
> > complains on the complete project.
>
> > Currently, I connect clock two 2 pins, GCK and a IOB, but this
> > can probably be avoided. How?- Hide quoted text -
>
> - Show quoted text -

This is more closer to what I am actually doing/trying:

Here, WR is used as GCK and also as signal:

-- main CPU writes a command to slave CPU, via FPGA

	if rising_edge(WR) and <other coditions, like address..> then
		COMMAND <=3D DBUS;   -- register command
	end if;


-- slave CPU ready flag

	if WR=3D'0' and <same other coditions..> then
		READY <=3D '0';   -- write detected, signal slave CPU is busy

	elsif rising_edge(SLAVE_CPU_ACK) then
		READY <=3D '1';
	end if;

(I need this READY signal to be edge sensitive,
not level, since slave CPU is really slow.)


Another example is a bi-dir data bus (RD is also used as GCK,
elsewhere):

	DBUS <=3D DATAOUT when RD=3D'0' else "ZZZZZZZZ";

ISE gives warning (again, it works on Spartan 3):

MapLib:95 - IBUF symbol "RD_IBUF" (output signal=3DRD_IBUF1)
is promoted to indicate the use of GCLKIOB site.

On Oct 16, 10:08=A0am, aleksa <aleks...@gmail.com> wrote:
> On Oct 16, 5:12=A0pm, Nathan Bialke <nathan.bia...@gmail.com> wrote:
> Here, WR is used as GCK and also as signal:

I would suggest not doing that.

>
> -- main CPU writes a command to slave CPU, via FPGA
>
> =A0 =A0 =A0 =A0 if rising_edge(WR) and <other coditions, like address..> =
then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 COMMAND <=3D DBUS; =A0 -- register comman=
d
> =A0 =A0 =A0 =A0 end if;
>
> -- slave CPU ready flag
>
> =A0 =A0 =A0 =A0 if WR=3D'0' and <same other coditions..> then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '0'; =A0 -- write detected, si=
gnal slave CPU is busy
>
> =A0 =A0 =A0 =A0 elsif rising_edge(SLAVE_CPU_ACK) then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '1';
> =A0 =A0 =A0 =A0 end if;
>
> (I need this READY signal to be edge sensitive,
> not level, since slave CPU is really slow.)

I would suggest that you don't want to do your bus interface this way.
The way you are following is fraught with danger. There are also much
easier ways to do what I think you want to do. Specifically, if the
slave CPU is really slow, make a synchronous interface yourself by
synchronizing the CPU signals into the FPGA timing domain.

> Another example is a bi-dir data bus (RD is also used as GCK,
> elsewhere):
>
> =A0 =A0 =A0 =A0 DBUS <=3D DATAOUT when RD=3D'0' else "ZZZZZZZZ";
>
> ISE gives warning (again, it works on Spartan 3):
>
> MapLib:95 - IBUF symbol "RD_IBUF" (output signal=3DRD_IBUF1)
> is promoted to indicate the use of GCLKIOB site.

I would suggest that your design probably isn't working in a Spartan-3
as well as you think. Using asynchronous control signals as clocks is
not going to work particularly well in any FPGA.

On Oct 16, 10:32=A0pm, Nathan Bialke <nat...@bialke.com> wrote:
> On Oct 16, 10:08=A0am, aleksa <aleks...@gmail.com> wrote:
>
> > On Oct 16, 5:12=A0pm, Nathan Bialke <nathan.bia...@gmail.com> wrote:
> > Here, WR is used as GCK and also as signal:
>
> I would suggest not doing that.
>
>
>
>
>
>
>
> > -- main CPU writes a command to slave CPU, via FPGA
>
> > =A0 =A0 =A0 =A0 if rising_edge(WR) and <other coditions, like address..=
> then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 COMMAND <=3D DBUS; =A0 -- register comm=
and
> > =A0 =A0 =A0 =A0 end if;
>
> > -- slave CPU ready flag
>
> > =A0 =A0 =A0 =A0 if WR=3D'0' and <same other coditions..> then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '0'; =A0 -- write detected, =
signal slave CPU is busy
>
> > =A0 =A0 =A0 =A0 elsif rising_edge(SLAVE_CPU_ACK) then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '1';
> > =A0 =A0 =A0 =A0 end if;
>
> > (I need this READY signal to be edge sensitive,
> > not level, since slave CPU is really slow.)
>
> I would suggest that you don't want to do your bus interface this way.
> The way you are following is fraught with danger. There are also much
> easier ways to do what I think you want to do. Specifically, if the
> slave CPU is really slow, make a synchronous interface yourself by
> synchronizing the CPU signals into the FPGA timing domain.

Why is it dangerous? How would you do it?

As I see it, it is a register with asynchronus reset.
The XILINX people say that it is more resource consuming,
but they dont say that it wont work.

The speed of the slave CPU is important in this example beacuse
this may happen if the level was tested and not edge:

1. main  CPU writes a command.
2. slave CPU (which is 100 times slower) responds to command and then
sets SLAVE_CPU_ACK to '0'.
3. main  CPU tests the status of the slave to see if it is ready.
4. since it is ready, the main CPU writes another command before the
slave
   has set the SLAVE_CPU_ACK back to '1' with the result of the new
command being lost.


I have several examples like that in my VHDL code:

This one, for example, is not speed critical:

if (CS=3D'0' and RD=3D'0' and ADDR=3D"1100") or (RESET=3D'0') then IRQ <=3D=
 '0';
elsif falling_edge(SLAVEIRQ) then IRQ <=3D '1'; end if;

(Slave can send me an IRQ and I can ACK it by
reading the slave's status or by hard reset)


Then I have this:

if SLAVECS=3D'0' and SLAVEADDR=3D"1011" then REGISTER <=3D SHIFTIN;
elsif rising_edge(WR) and CS=3D'0' and ADDR=3D"1111" then REGISTER <=3D
DBUS; end if;

(The main CPU can write to REGISTER, and also the slave can write it).
(after shifting data in serially to SHIFTIN register, which is not
shown)



> > Another example is a bi-dir data bus (RD is also used as GCK,
> > elsewhere):
>
> > =A0 =A0 =A0 =A0 DBUS <=3D DATAOUT when RD=3D'0' else "ZZZZZZZZ";
>
> > ISE gives warning (again, it works on Spartan 3):
>
> > MapLib:95 - IBUF symbol "RD_IBUF" (output signal=3DRD_IBUF1)
> > is promoted to indicate the use of GCLKIOB site.
>
> I would suggest that your design probably isn't working in a Spartan-3
> as well as you think. Using asynchronous control signals as clocks is
> not going to work particularly well in any FPGA.- Hide quoted text -
>
> - Show quoted text -

How else can I make a bi-dir data bus?
The only signals I can monitor are CS=3D0, RD=3D0 and
correct address bus (CS and ABUS not shown in the above code).

I can get by the whole thing (ie. ISE doesn't complain) if I connect
a RD and WR to two pins, a GCK pin and a IOB pin.
Then I call them cRD, cWR, sRD and sWR (c=3Dclock, s=3Dsignal)
and use c or s version where appropriate.


And yes, I haven't tested anything on a real hardware yet.

> How else can I make a bi-dir data bus?
> The only signals I can monitor are CS=0, RD=0 and
> correct address bus (CS and ABUS not shown in the above code).
>
> I can get by the whole thing (ie. ISE doesn't complain) if I connect
> a RD and WR to two pins, a GCK pin and a IOB pin.
> Then I call them cRD, cWR, sRD and sWR (c=clock, s=signal)
> and use c or s version where appropriate.
>
> And yes, I haven't tested anything on a real hardware yet.

Your FPGA has a clock. If it doesn't have a clock, it needs a clock.
Either these signals are not synchronous to the FPGA clock or they
aren't. If the signals are asynchronous, make the FPGA clock much
faster than the CPU clock (this seems to be the case) and put the CPU
control signals through synchronizers. Then sample those signals as
synchronous using standard logic design practices. If the signals are
synchronous, then you don't need to treat them as a clock - you can
sample them with the FPGA clock.

The fact that ISE will synthesize and build the design does not imply
the design will work. Using control signals as clocks is nearly always
a bad idea - in fact, I can't think of a time when it isn't.

I'm going to have to asset again that you don't want to do what you're
doing. There is a better way. Synchronous design principles do indeed
work.

Good luck!

- Nathan

On Oct 17, 1:02=A0am, Nathan Bialke <nat...@bialke.com> wrote:
> > How else can I make a bi-dir data bus?
> > The only signals I can monitor are CS=3D0, RD=3D0 and
> > correct address bus (CS and ABUS not shown in the above code).
>
> > I can get by the whole thing (ie. ISE doesn't complain) if I connect
> > a RD and WR to two pins, a GCK pin and a IOB pin.
> > Then I call them cRD, cWR, sRD and sWR (c=3Dclock, s=3Dsignal)
> > and use c or s version where appropriate.
>
> > And yes, I haven't tested anything on a real hardware yet.
>
> Your FPGA has a clock. If it doesn't have a clock, it needs a clock.
> Either these signals are not synchronous to the FPGA clock or they
> aren't. If the signals are asynchronous, make the FPGA clock much
> faster than the CPU clock (this seems to be the case) and put the CPU
> control signals through synchronizers. Then sample those signals as
> synchronous using standard logic design practices. If the signals are
> synchronous, then you don't need to treat them as a clock - you can
> sample them with the FPGA clock.
>
> The fact that ISE will synthesize and build the design does not imply
> the design will work. Using control signals as clocks is nearly always
> a bad idea - in fact, I can't think of a time when it isn't.
>
> I'm going to have to asset again that you don't want to do what you're
> doing. There is a better way. Synchronous design principles do indeed
> work.
>
> Good luck!
>
> - Nathan

I don't understand why it shouldn't work.


This is an example from the 'Language Templates':

   if <reset>=3D'1' then
      <output> <=3D '0';
   elsif (<clock>'event and <clock>=3D'0') then
      <output> <=3D <input>;
   end if;

How is this different from my examples above?
The only thing is more conditions, which should not matter.


Example for Bi-dir I/O, unregistered:

-- Declare the <top_level_port> as a 8-bit inout port
<top_level_port> <=3D <input_signal> when <output_enable_signal> =3D '0'
else "ZZZZZZZZ";
	<input_signal> <=3D <top_level_port>;

How does that differ?

Anyway, I'm off to bed.

aleksa wrote:
> -- slave CPU ready flag
> 
> 	if WR='0' and <same other coditions..> then
> 		READY <= '0';   -- write detected, signal slave CPU is busy
> 
> 	elsif rising_edge(SLAVE_CPU_ACK) then
> 		READY <= '1';
> 	end if;
> 
> (I need this READY signal to be edge sensitive,
> not level, since slave CPU is really slow.)
> 
> 
> Another example is a bi-dir data bus (RD is also used as GCK,
> elsewhere):
> 
> 	DBUS <= DATAOUT when RD='0' else "ZZZZZZZZ";
> 
> ISE gives warning (again, it works on Spartan 3):

So are you saying this works on some targets, but not others,
and it works on small examples, but not larger ones ?

You can check the code is ok, by splitting
the offending signal to two pins, and then RST use
of the Clock is removed.

If the tools (or silicon) still refuse to co-operate fully,
you can always join two pins :)

-jg

> I don't understand why it shouldn't work.

It can work if you're very careful and happen to be adept at
asynchronous logic design. However, there are probably easier and more
robust ways of doing what you want to do. FPGA clock lines are
designed to drive the clock inputs of flip-flops. To drive the non-
clock inputs of flip-flops, the signal must leave the global line.
Depending on the part, leaving a clock line can add much more delay
than you'd expect. The delay will also vary build-to-build unless you
constrain it appropriately. Even more fun to deal with will be the
skew between the "clock" version of the signal and the "signal"
version of your signal.

> This is an example from the 'Language Templates':
>
> =A0 =A0if <reset>=3D'1' then
> =A0 =A0 =A0 <output> <=3D '0';
> =A0 =A0elsif (<clock>'event and <clock>=3D'0') then
> =A0 =A0 =A0 <output> <=3D <input>;
> =A0 =A0end if;
>
> How is this different from my examples above?
> The only thing is more conditions, which should not matter.

Strictly speaking, you are correct - I must admit I was confused by
the description of having two clocks drive a variable (hence, I was
thinking of a two-clock flip-flop, which doesn't exist in Xilinx
FPGAs). However, that's not the issue here. I would suggest that even
if you get your design to synthesize, you are going to have issues
with asynchronously loading registers and status flags. Unless you are
extraordinarily careful (in particular, by ensuring all asynchronous
paths are properly constrained and that any asynchronous loads do not
lead to race conditions down the line in the data path), your build
will fail randomly depending on temperature, process, and voltage
variations. Further, you will have issues porting this code to other
FPGA architectures if necessary.

I don't want to discourage you, but I'd feel bad if an FPGA new-comer
lost interest in the device by following non-standard design
principles and then getting bit by them.

- Nathan

> So are you saying this works on some targets, but not others,
> and it works on small examples, but not larger ones ?

Yes.

Please test this on XC3S50 TQFP144 and then on XC2S50 TQFP144:

----------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity test is Port (
		DBUS : out STD_LOGIC;

		clock1 : in  STD_LOGIC;
		clock2 : in  STD_LOGIC;

		data1 : in  STD_LOGIC;
		data2 : in  STD_LOGIC;

		out1 : out  STD_LOGIC;
		out2 : out  STD_LOGIC);
end test;

architecture Behavioral of test is

--	attribute buffer_type: string;
--	attribute buffer_type of clock2: signal is "bufgp";

begin

process (clock1, clock2)
begin

	if falling_edge(clock2) then
		out2 <= data2;
	end if;

	if clock2='0' then out1 <= 'Z';
	elsif falling_edge(clock1) then out1 <= data1;
	end if;

end process;

DBUS <= data1 when clock2='0' else 'Z';

end Behavioral;
----------------------------------------

That should show that it works on S3 but fails on S2.

As for the "and it works on small examples, but not larger ones"
remove the comment on attribute lines and it will work on S2
(but not on S3).
I'm not at liberty to show the complete design, however.

BUFGP is probably a bad idea, anyway.


> You can check the code is ok, by splitting
> the offending signal to two pins, and then RST use
> of the Clock is removed.
>
> If the tools (or silicon) still refuse to co-operate fully,
> you can always join two pins :)

That is what I was doing from the start (see s and c version)
but wanted to have only one pin with the SAME SIGNAL.

Since I'm meeting too much resistance, two pins-same signal
is the way to go..