clockstopper?

[Jaytersen]

Hello everybody

i'm making a multiprocessor system in vhdl and i've come across a
problem. The thing is that when one of the processors try to get onto
the bus but someone else is using it, that processor will have to wait
for its turn. The processors(or rather microcontrollers) does not have
built in facilities for this, so i have to devise a way to make them
halt until the bus is free. The way i'm going, is to try and halt the
clock signal for the individual unit. However i'm having alot of trouble
doing this. The way i'm trying to do it is by making an entity with a
"clk" input(of course) and a "clk_o" output and two control signals
("start" and "stop"). Now: when "stop"(bus request) goes high, the clock
signal should be latched, and when "start" (bus granted) goes high the
"clk_o" should resume the clock.

One of the things i'm trying to avoid is the situation where the latched
clock signal was high for instance and then the "start" signal goes high
just before a rising clock edge, thereby getting a very fast change from
high to low and back to high again.

Another problem is how vhdl handles the fact that "clk_o" is not a
"real" clock signal. For instance i get a lot of warnings about "gated
clock signal" and "clock output driven by combinatorial logic" and stuff.

I'm using Xilinx web-pack 4.2 and the hardware is to be implemented on a
Spartan-2 fpga.

Any views on this would be highly appreciated.

--

Jay

 

[Brent Hayhoe]

Hi Jay,

Jaytersen wrote:

Hello everybody

i'm making a multiprocessor system in vhdl and i've come across a
problem. The thing is that when one of the processors try to get onto
the bus but someone else is using it, that processor will have to wait
for its turn. The processors(or rather microcontrollers) does not have
built in facilities for this, so i have to devise a way to make them
halt until the bus is free. The way i'm going, is to try and halt the
clock signal for the individual unit. However i'm having alot of trouble
doing this. The way i'm trying to do it is by making an entity with a
"clk" input(of course) and a "clk_o" output and two control signals
("start" and "stop"). Now: when "stop"(bus request) goes high, the clock
signal should be latched, and when "start" (bus granted) goes high the
"clk_o" should resume the clock.

One of the things i'm trying to avoid is the situation where the latched
clock signal was high for instance and then the "start" signal goes high
just before a rising clock edge, thereby getting a very fast change from
high to low and back to high again.

Yes, a very valid problem. I've dealt with this in the past a number of times
and it involves building an asynchronous state machine to control the 'turn on'
and 'turn off' of the clock.

This is not trivial if you've never done it before.

It's something I've always done manually, as I've not trusted any synthesis
engine to get it right. All transitions in the state machine have to be gray coded.

From memory, here's a rough example of typical state machine:-

off clk = '0' clk = '1'
- normal ->- wait0 ---->---- arm0 ---->---- clk off -
| 000 001 011 010 |
^ v
| 100 101 111 110 |
- clk on ----<----- arm1 ----<---- wait1 -<- idle ---
clk = '1' clk = '0' on

clk_gate = {clk on} + {normal} + {wait0] + {arm0}

In order to define the state machine manually, use the state equations defined by:-

s = {switch on terms}*not(s) + not{switch off terms}*s

so, for example, if the state variables were defined as signals x,y,z, then the
'switch on terms' for z would be:-

/x*/y*{off} + x*y*{on}

In the past, I've defined the asynchronous memory element as an entity
implementing the equation for 's' above, i.e.

s = a*/s + /b*s

placed a synthesis 'dont_touch' attribute on it and let the synthesis tool
reduce the equations. This normally results in small 'locally fed back' SR type
of latch.

Hope this helps.

Another problem is how vhdl handles the fact that "clk_o" is not a
"real" clock signal. For instance i get a lot of warnings about "gated
clock signal" and "clock output driven by combinatorial logic" and stuff.

It's generally not VHDL that has the problem, rather the place and route tool
for the FPGA, as architectures don't generally lend themselves to mapping logic
(internally) onto the clock trees. You can always get around this by going off
chip and back in. However, you may end up with a whole new area of timing
problems then

I'm using Xilinx web-pack 4.2 and the hardware is to be implemented on a
Spartan-2 fpga.

Any views on this would be highly appreciated.

--

Regards,

Brent Hayhoe.

Aftonroy Limited
Email: <A
HREF="mailto:&#066;&#114;&#101;&#110;&#116;&#046;&#072;&#097;&#121;&#104;&#111;&#101;&#064;&#065;&#102;&#116;&#111;&#110;&#114;&#111;&#121;&#046;&#099;&#111;&#109;">

 

[David R Brooks]

It's generally a Bad Idea to gate clocks, especially on FPGAs. It can
prevent you using the dedicated clock routing resources. Clocks run in
general wiring can be subject to unacceptable skews.
Assuming you have access to the source code of the microprocessor,
the safest way might be to go through and add an Enable to the input
of each register in it. These enables are efficiently implemented in
most FPGAs (the FF output simply loops back to its input).

Jaytersen &lt;agent1@mip.sdu.dk&gt; wrote:

:Hello everybody
:
:i'm making a multiprocessor system in vhdl and i've come across a
roblem. The thing is that when one of the processors try to get onto
:the bus but someone else is using it, that processor will have to wait
:for its turn. The processors(or rather microcontrollers) does not have
:built in facilities for this, so i have to devise a way to make them
:halt until the bus is free. The way i'm going, is to try and halt the
:clock signal for the individual unit. However i'm having alot of trouble
:doing this. The way i'm trying to do it is by making an entity with a
:"clk" input(of course) and a "clk_o" output and two control signals
"start" and "stop"). Now: when "stop"(bus request) goes high, the clock
:signal should be latched, and when "start" (bus granted) goes high the
:"clk_o" should resume the clock.
:
:One of the things i'm trying to avoid is the situation where the latched
:clock signal was high for instance and then the "start" signal goes high
:just before a rising clock edge, thereby getting a very fast change from
:high to low and back to high again.
:
:Another problem is how vhdl handles the fact that "clk_o" is not a
:"real" clock signal. For instance i get a lot of warnings about "gated
:clock signal" and "clock output driven by combinatorial logic" and stuff.
:
:I'm using Xilinx web-pack 4.2 and the hardware is to be implemented on a
:Spartan-2 fpga.
:
:Any views on this would be highly appreciated.

 

[Jim Wu]

The thing is that when one of the processors try to get onto
the bus but someone else is using it, that processor will have to wait
for its turn. The processors(or rather microcontrollers) does not have
built in facilities for this,

The way i'm trying to do it is by making an entity with a
"clk" input(of course) and a "clk_o" output and two control signals
("start" and "stop"). Now: when "stop"(bus request) goes high, the clock
signal should be latched, and when "start" (bus granted) goes high the
"clk_o" should resume the clock.

If I understand correctly, your processors do not support bus arbitration.
Where does "bus request" come from and and "bus granted" go to?

Jim Wu
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips