EDK : FSL macros defined by Xilinx are wrong

[rickman]

Allan Herriman wrote on 12/18/2017 3:54 AM:

On Sat, 16 Dec 2017 12:44:35 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 11:32 AM:
On Sat, 16 Dec 2017 09:27:37 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 4:50 AM:
On Fri, 15 Dec 2017 10:57:50 -0500, rickman wrote:

Allan Herriman wrote on 12/15/2017 5:21 AM:
On Thu, 14 Dec 2017 10:18:25 -0500, rickman wrote:

Allan Herriman wrote on 12/14/2017 6:39 AM:
On Thu, 14 Dec 2017 10:49:41 +0000, Allan Herriman wrote:


The placement and routing is quite easy to control from your
favourite HDL, once you know how. This is important to get
right as otherwise
the
results will not be repeatable.

This Xilinx forum thread gives some examples of placement and
routing
in VHDL:

https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
oscillator/m-p/808774/highlight/true#M5557

When you say "routing", it doesn't appear to deal with the actual
routing.
He does mention that the attributes assign specific I/Os on the
LUTs
and so
which pin is connected to which is determined. But the routing
interconnects still need to be wired up in the chip editor I
believe.

There is no manual step needed. Once you lock the pins, the
routing will be fixed (to an extent).

"To an extent" is one of those things where the devil is in the
details.
Routing within a block is dedicated and either a path exists or it
doesn't. But routing between blocks is much more flexible and so
subject to variations depending on what the software chooses.

In general, I agree with that. Look sideways at the PAR software or
make a trivial change to the source code and it will do something
completely different, and often something unexpected. Sometimes it
will do something wildly suboptimal.

But in this case, I believe Larkin has just one connection that will
be contained within a single switch box next to the IOB. It will not
use any inter-switchbox routing (with all the uncertainty that
entails).

My experience has been that in this particular case (and this
particular case only), locking the pins correctly may remove any
choice the router has, resulting in repeatable routing. (I won't say
repeatable timing, because we still have PVT to worry about.)

Depending on the exact switchbox resources used, this may also
require that other routing be prohibited in that area to work.


Perhaps I should point out that whilst I have done some of this sort
of manual placement and routing recently, I have not done the exact
route of IBUF output to OUTFF clear input. Sometimes there are
quirks that do not become apparent until the design hits the tools.

I guess my work with Xilinx parts is getting old. I didn't remember
the IOB FFs *having* accessible async Clear/Preset inputs which would
have required a FF from the fabric. But I looked at the Xynq data
sheet and the IOB FF have accessible Clear/Preset inputs. So there
will be routing on the general fabric as I expect there is no direct
connection between the input and the Clear pin within the IOB.


I can't try it here (I'm not at work and I deliberately don't have the
tools installed at home) but I believe both signals appear on the same
switchbox, which is about as close to a direct connection as one can
get outside a slice.


As to your presumption of this removing "any choice the router has", I
think that is fallacious. The switch matrix is a general purpose
routing medium and I have seen the tool do, as you say, "wildly
suboptimal" routes.


I'm fairly sure that rather than being general purpose, the switch
matrix is sparse and doesn't support all input to output connections.
(The exact details are not documented publicly.) With pin locking, one
can force particular paths through the switchbox. This is based on my
observations of tool behaviour rather than an inspection of the die,
thus there is a chance that it is wrong as you suggest.

Please note that I'm only referring to intra-switchbox routing. All
bets are off once the routing goes outside the local switchbox.


The only way to tell is to give it a try.

Oh yes.

You are more familiar with the newer devices than I am. The issue isn't
even if you can get the route through the local switchbox. It is
whether it will always pick the same route. As you say, the switch
matrix is somewhat sparse, but the issue is whether it goes through a
single switchbox or not. I guess we'll find out when John tries it.

I thought the problem was going to be the lack of a reset pin on the IOB
FF which would have forced the use of a fabric FF with routing to/from
the IOB.
Then I think the locking of LUTs (for delay) and the FF to a single
CLB
would have been the approach with the best shot at producing a
controlled pulse width even if the routing delay to the IOB would have
been variable. But that can be constrained since it is a path from the
"clock" (trigger input) to the output pin.


I ran an experiment today at work. I used the following VHDL source in
the smallest Kintex 7 part (which has the same fabric as the OP's Zynq).
The net obuf_input (FF Q to pin driver) used dedicated routing and didn't
go through any switchboxes at all.

That's certainly expected.

The net ibuf_output (which connects back to the FF reset input) was
restricted to the local switchbox as expected. It needed multiple passes
though the switchbox though, as clearly this isn't a connection that
Xilinx expects customers to use often.
I didn't check, but I imagine that the path through the switchbox would
change if other routing was also passing through the switchbox (which
does happen in a dense design).

I have not simulated this code or tested it in any way. Use at own risk.

Interesting. Can you provide any details on the switch box routing, like an
image, perhaps? Or should I install the tools and try it myself? I've
always found the chip editor to be a messy tool to learn, but just looking
at stuff hasn't been too hard. My main reason for not wanting to install
the Xilinx tools is dealing with the licensing issues that always seem to be
a PITA.

I suspect there aren't too many choices for how to route the signal through
the one switch box. But if the design is not otherwise empty and any of the
switch box paths used in this iteration are used by another route, it may
end up using multiple switch boxes resulting in significant routing delays.
Adding a timing constraint for clock to output won't help with this feedback
path.

I don't recall if there are any timing constraints for such an async loop.
They are hard for the tools to analyze which is the main reason for avoiding
them like the plague. Yes, it can be made to work obviously, but FPGA
companies have enough to do without supporting this sort of feature which
would open huge cans of worms for them. So short of generating a timing
analysis script, there will be no automation for even verifying timing of
this path every time you route the design.

--

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

 

[Allan Herriman]

On Mon, 18 Dec 2017 12:07:40 -0500, rickman wrote:

Allan Herriman wrote on 12/18/2017 3:54 AM:
On Sat, 16 Dec 2017 12:44:35 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 11:32 AM:
On Sat, 16 Dec 2017 09:27:37 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 4:50 AM:
On Fri, 15 Dec 2017 10:57:50 -0500, rickman wrote:

Allan Herriman wrote on 12/15/2017 5:21 AM:
On Thu, 14 Dec 2017 10:18:25 -0500, rickman wrote:

Allan Herriman wrote on 12/14/2017 6:39 AM:
On Thu, 14 Dec 2017 10:49:41 +0000, Allan Herriman wrote:


The placement and routing is quite easy to control from your
favourite HDL, once you know how. This is important to get
right as otherwise
the
results will not be repeatable.

This Xilinx forum thread gives some examples of placement and
routing
in VHDL:

https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-
ring-
oscillator/m-p/808774/highlight/true#M5557

When you say "routing", it doesn't appear to deal with the
actual
routing.
He does mention that the attributes assign specific I/Os on the
LUTs
and so
which pin is connected to which is determined. But the routing
interconnects still need to be wired up in the chip editor I
believe.

There is no manual step needed. Once you lock the pins, the
routing will be fixed (to an extent).

"To an extent" is one of those things where the devil is in the
details.
Routing within a block is dedicated and either a path exists or it
doesn't. But routing between blocks is much more flexible and so
subject to variations depending on what the software chooses.

In general, I agree with that. Look sideways at the PAR software
or make a trivial change to the source code and it will do
something completely different, and often something unexpected.
Sometimes it will do something wildly suboptimal.

But in this case, I believe Larkin has just one connection that
will be contained within a single switch box next to the IOB. It
will not use any inter-switchbox routing (with all the uncertainty
that entails).

My experience has been that in this particular case (and this
particular case only), locking the pins correctly may remove any
choice the router has, resulting in repeatable routing. (I won't
say repeatable timing, because we still have PVT to worry about.)

Depending on the exact switchbox resources used, this may also
require that other routing be prohibited in that area to work.


Perhaps I should point out that whilst I have done some of this
sort of manual placement and routing recently, I have not done the
exact route of IBUF output to OUTFF clear input. Sometimes there
are quirks that do not become apparent until the design hits the
tools.

I guess my work with Xilinx parts is getting old. I didn't remember
the IOB FFs *having* accessible async Clear/Preset inputs which
would have required a FF from the fabric. But I looked at the Xynq
data sheet and the IOB FF have accessible Clear/Preset inputs. So
there will be routing on the general fabric as I expect there is no
direct connection between the input and the Clear pin within the
IOB.


I can't try it here (I'm not at work and I deliberately don't have
the tools installed at home) but I believe both signals appear on the
same switchbox, which is about as close to a direct connection as one
can get outside a slice.


As to your presumption of this removing "any choice the router has",
I think that is fallacious. The switch matrix is a general purpose
routing medium and I have seen the tool do, as you say, "wildly
suboptimal" routes.


I'm fairly sure that rather than being general purpose, the switch
matrix is sparse and doesn't support all input to output connections.
(The exact details are not documented publicly.) With pin locking,
one can force particular paths through the switchbox. This is based
on my observations of tool behaviour rather than an inspection of the
die, thus there is a chance that it is wrong as you suggest.

Please note that I'm only referring to intra-switchbox routing. All
bets are off once the routing goes outside the local switchbox.


The only way to tell is to give it a try.

Oh yes.

You are more familiar with the newer devices than I am. The issue
isn't even if you can get the route through the local switchbox. It
is whether it will always pick the same route. As you say, the switch
matrix is somewhat sparse, but the issue is whether it goes through a
single switchbox or not. I guess we'll find out when John tries it.

I thought the problem was going to be the lack of a reset pin on the
IOB FF which would have forced the use of a fabric FF with routing
to/from the IOB.
Then I think the locking of LUTs (for delay) and the FF to a single
CLB
would have been the approach with the best shot at producing a
controlled pulse width even if the routing delay to the IOB would have
been variable. But that can be constrained since it is a path from the
"clock" (trigger input) to the output pin.


I ran an experiment today at work. I used the following VHDL source in
the smallest Kintex 7 part (which has the same fabric as the OP's
Zynq). The net obuf_input (FF Q to pin driver) used dedicated routing
and didn't go through any switchboxes at all.

That's certainly expected.


The net ibuf_output (which connects back to the FF reset input) was
restricted to the local switchbox as expected. It needed multiple
passes though the switchbox though, as clearly this isn't a connection
that Xilinx expects customers to use often.
I didn't check, but I imagine that the path through the switchbox would
change if other routing was also passing through the switchbox (which
does happen in a dense design).

I have not simulated this code or tested it in any way. Use at own
risk.

Interesting. Can you provide any details on the switch box routing,
like an image, perhaps?

The ratsnest doesn't show much:
http://www.users.on.net/~julide/larkin_oneshot_1.png

but the routing view shows the switchbox (the rectangle on the right). I
highlighted the ibuf_output net (which goes back to the FF reset input).
http://www.users.on.net/~julide/larkin_oneshot_2.png

Or should I install the tools and try it
myself? I've always found the chip editor to be a messy tool to learn,
but just looking at stuff hasn't been too hard. My main reason for not
wanting to install the Xilinx tools is dealing with the licensing issues
that always seem to be a PITA.

Small parts (such as the one the OP is using) use the free Webpack
license. It will call home with usage information. You can always use
an airgap if you don't like that.
https://www.xilinx.com/support/download.html

I don't recall if there are any timing constraints for such an async
loop. They are hard for the tools to analyze which is the main reason
for avoiding them like the plague. Yes, it can be made to work
obviously, but FPGA companies have enough to do without supporting this
sort of feature which would open huge cans of worms for them. So short
of generating a timing analysis script, there will be no automation for
even verifying timing of this path every time you route the design.

I'm fairly sure you can constrain any path.

Allan

 

[rickman]

Allan Herriman wrote on 12/19/2017 5:11 AM:

On Mon, 18 Dec 2017 12:07:40 -0500, rickman wrote:

Allan Herriman wrote on 12/18/2017 3:54 AM:
On Sat, 16 Dec 2017 12:44:35 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 11:32 AM:
On Sat, 16 Dec 2017 09:27:37 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 4:50 AM:
On Fri, 15 Dec 2017 10:57:50 -0500, rickman wrote:

Allan Herriman wrote on 12/15/2017 5:21 AM:
On Thu, 14 Dec 2017 10:18:25 -0500, rickman wrote:

Allan Herriman wrote on 12/14/2017 6:39 AM:
On Thu, 14 Dec 2017 10:49:41 +0000, Allan Herriman wrote:


The placement and routing is quite easy to control from your
favourite HDL, once you know how. This is important to get
right as otherwise
the
results will not be repeatable.

This Xilinx forum thread gives some examples of placement and
routing
in VHDL:

https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-
ring-
oscillator/m-p/808774/highlight/true#M5557

When you say "routing", it doesn't appear to deal with the
actual
routing.
He does mention that the attributes assign specific I/Os on the
LUTs
and so
which pin is connected to which is determined. But the routing
interconnects still need to be wired up in the chip editor I
believe.

There is no manual step needed. Once you lock the pins, the
routing will be fixed (to an extent).

"To an extent" is one of those things where the devil is in the
details.
Routing within a block is dedicated and either a path exists or it
doesn't. But routing between blocks is much more flexible and so
subject to variations depending on what the software chooses.

In general, I agree with that. Look sideways at the PAR software
or make a trivial change to the source code and it will do
something completely different, and often something unexpected.
Sometimes it will do something wildly suboptimal.

But in this case, I believe Larkin has just one connection that
will be contained within a single switch box next to the IOB. It
will not use any inter-switchbox routing (with all the uncertainty
that entails).

My experience has been that in this particular case (and this
particular case only), locking the pins correctly may remove any
choice the router has, resulting in repeatable routing. (I won't
say repeatable timing, because we still have PVT to worry about.)

Depending on the exact switchbox resources used, this may also
require that other routing be prohibited in that area to work.


Perhaps I should point out that whilst I have done some of this
sort of manual placement and routing recently, I have not done the
exact route of IBUF output to OUTFF clear input. Sometimes there
are quirks that do not become apparent until the design hits the
tools.

I guess my work with Xilinx parts is getting old. I didn't remember
the IOB FFs *having* accessible async Clear/Preset inputs which
would have required a FF from the fabric. But I looked at the Xynq
data sheet and the IOB FF have accessible Clear/Preset inputs. So
there will be routing on the general fabric as I expect there is no
direct connection between the input and the Clear pin within the
IOB.


I can't try it here (I'm not at work and I deliberately don't have
the tools installed at home) but I believe both signals appear on the
same switchbox, which is about as close to a direct connection as one
can get outside a slice.


As to your presumption of this removing "any choice the router has",
I think that is fallacious. The switch matrix is a general purpose
routing medium and I have seen the tool do, as you say, "wildly
suboptimal" routes.


I'm fairly sure that rather than being general purpose, the switch
matrix is sparse and doesn't support all input to output connections.
(The exact details are not documented publicly.) With pin locking,
one can force particular paths through the switchbox. This is based
on my observations of tool behaviour rather than an inspection of the
die, thus there is a chance that it is wrong as you suggest.

Please note that I'm only referring to intra-switchbox routing. All
bets are off once the routing goes outside the local switchbox.


The only way to tell is to give it a try.

Oh yes.

You are more familiar with the newer devices than I am. The issue
isn't even if you can get the route through the local switchbox. It
is whether it will always pick the same route. As you say, the switch
matrix is somewhat sparse, but the issue is whether it goes through a
single switchbox or not. I guess we'll find out when John tries it.

I thought the problem was going to be the lack of a reset pin on the
IOB FF which would have forced the use of a fabric FF with routing
to/from the IOB.
Then I think the locking of LUTs (for delay) and the FF to a single
CLB
would have been the approach with the best shot at producing a
controlled pulse width even if the routing delay to the IOB would have
been variable. But that can be constrained since it is a path from the
"clock" (trigger input) to the output pin.


I ran an experiment today at work. I used the following VHDL source in
the smallest Kintex 7 part (which has the same fabric as the OP's
Zynq). The net obuf_input (FF Q to pin driver) used dedicated routing
and didn't go through any switchboxes at all.

That's certainly expected.


The net ibuf_output (which connects back to the FF reset input) was
restricted to the local switchbox as expected. It needed multiple
passes though the switchbox though, as clearly this isn't a connection
that Xilinx expects customers to use often.
I didn't check, but I imagine that the path through the switchbox would
change if other routing was also passing through the switchbox (which
does happen in a dense design).

I have not simulated this code or tested it in any way. Use at own
risk.

Interesting. Can you provide any details on the switch box routing,
like an image, perhaps?


The ratsnest doesn't show much:
http://www.users.on.net/~julide/larkin_oneshot_1.png

but the routing view shows the switchbox (the rectangle on the right). I
highlighted the ibuf_output net (which goes back to the FF reset input).
http://www.users.on.net/~julide/larkin_oneshot_2.png

The routing view doesn't do much to indicate how other routing might
conflict. Looks like they have means internally of cross connecting traces
in the switch box through multiple connections. I believe this is done
through pass transistors rather than buffers, so even if one routing
iteration uses four rather than three connections it won't be much
variation. The concern is if local congestion causes this route to leave
the switch box to use a longer route and/or other switch boxes.

Or should I install the tools and try it
myself? I've always found the chip editor to be a messy tool to learn,
but just looking at stuff hasn't been too hard. My main reason for not
wanting to install the Xilinx tools is dealing with the licensing issues
that always seem to be a PITA.


Small parts (such as the one the OP is using) use the free Webpack
license. It will call home with usage information. You can always use
an airgap if you don't like that.
https://www.xilinx.com/support/download.html

I'm talking about the simple hassle of getting the licensing to work. It's
fine 95% of the time, but that other 5% can be a bear. I just don't look
forward to installing any tools using Flexlm.

I don't recall if there are any timing constraints for such an async
loop. They are hard for the tools to analyze which is the main reason
for avoiding them like the plague. Yes, it can be made to work
obviously, but FPGA companies have enough to do without supporting this
sort of feature which would open huge cans of worms for them. So short
of generating a timing analysis script, there will be no automation for
even verifying timing of this path every time you route the design.


I'm fairly sure you can constrain any path.

I'd love to see the syntax for this. My understanding is all the
constraints operate on endpoints defined by clocks and I/O pads. Async path
loops can not even be evaluated as the tool reports an async loop as an
error. I have never seen a timing constraint that operates on an arbitrary
route or async path segment.

--

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

 

[John Larkin]

On 18 Dec 2017 08:54:34 GMT, Allan Herriman
<allanherriman@hotmail.com> wrote:

On Sat, 16 Dec 2017 12:44:35 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 11:32 AM:
On Sat, 16 Dec 2017 09:27:37 -0500, rickman wrote:

Allan Herriman wrote on 12/16/2017 4:50 AM:
On Fri, 15 Dec 2017 10:57:50 -0500, rickman wrote:

Allan Herriman wrote on 12/15/2017 5:21 AM:
On Thu, 14 Dec 2017 10:18:25 -0500, rickman wrote:

Allan Herriman wrote on 12/14/2017 6:39 AM:
On Thu, 14 Dec 2017 10:49:41 +0000, Allan Herriman wrote:


The placement and routing is quite easy to control from your
favourite HDL, once you know how. This is important to get
right as otherwise
the
results will not be repeatable.

This Xilinx forum thread gives some examples of placement and
routing
in VHDL:

https://forums.xilinx.com/t5/UltraScale-Architecture/Gated-ring-
oscillator/m-p/808774/highlight/true#M5557

When you say "routing", it doesn't appear to deal with the actual
routing.
He does mention that the attributes assign specific I/Os on the
LUTs
and so
which pin is connected to which is determined. But the routing
interconnects still need to be wired up in the chip editor I
believe.

There is no manual step needed. Once you lock the pins, the
routing will be fixed (to an extent).

"To an extent" is one of those things where the devil is in the
details.
Routing within a block is dedicated and either a path exists or it
doesn't. But routing between blocks is much more flexible and so
subject to variations depending on what the software chooses.

In general, I agree with that. Look sideways at the PAR software or
make a trivial change to the source code and it will do something
completely different, and often something unexpected. Sometimes it
will do something wildly suboptimal.

But in this case, I believe Larkin has just one connection that will
be contained within a single switch box next to the IOB. It will not
use any inter-switchbox routing (with all the uncertainty that
entails).

My experience has been that in this particular case (and this
particular case only), locking the pins correctly may remove any
choice the router has, resulting in repeatable routing. (I won't say
repeatable timing, because we still have PVT to worry about.)

Depending on the exact switchbox resources used, this may also
require that other routing be prohibited in that area to work.


Perhaps I should point out that whilst I have done some of this sort
of manual placement and routing recently, I have not done the exact
route of IBUF output to OUTFF clear input. Sometimes there are
quirks that do not become apparent until the design hits the tools.

I guess my work with Xilinx parts is getting old. I didn't remember
the IOB FFs *having* accessible async Clear/Preset inputs which would
have required a FF from the fabric. But I looked at the Xynq data
sheet and the IOB FF have accessible Clear/Preset inputs. So there
will be routing on the general fabric as I expect there is no direct
connection between the input and the Clear pin within the IOB.


I can't try it here (I'm not at work and I deliberately don't have the
tools installed at home) but I believe both signals appear on the same
switchbox, which is about as close to a direct connection as one can
get outside a slice.


As to your presumption of this removing "any choice the router has", I
think that is fallacious. The switch matrix is a general purpose
routing medium and I have seen the tool do, as you say, "wildly
suboptimal" routes.


I'm fairly sure that rather than being general purpose, the switch
matrix is sparse and doesn't support all input to output connections.
(The exact details are not documented publicly.) With pin locking, one
can force particular paths through the switchbox. This is based on my
observations of tool behaviour rather than an inspection of the die,
thus there is a chance that it is wrong as you suggest.

Please note that I'm only referring to intra-switchbox routing. All
bets are off once the routing goes outside the local switchbox.


The only way to tell is to give it a try.

Oh yes.

You are more familiar with the newer devices than I am. The issue isn't
even if you can get the route through the local switchbox. It is
whether it will always pick the same route. As you say, the switch
matrix is somewhat sparse, but the issue is whether it goes through a
single switchbox or not. I guess we'll find out when John tries it.

I thought the problem was going to be the lack of a reset pin on the IOB
FF which would have forced the use of a fabric FF with routing to/from
the IOB.
Then I think the locking of LUTs (for delay) and the FF to a single
CLB
would have been the approach with the best shot at producing a
controlled pulse width even if the routing delay to the IOB would have
been variable. But that can be constrained since it is a path from the
"clock" (trigger input) to the output pin.


I ran an experiment today at work. I used the following VHDL source in
the smallest Kintex 7 part (which has the same fabric as the OP's Zynq).
The net obuf_input (FF Q to pin driver) used dedicated routing and didn't
go through any switchboxes at all.

The net ibuf_output (which connects back to the FF reset input) was
restricted to the local switchbox as expected. It needed multiple passes
though the switchbox though, as clearly this isn't a connection that
Xilinx expects customers to use often.
I didn't check, but I imagine that the path through the switchbox would
change if other routing was also passing through the switchbox (which
does happen in a dense design).

I have not simulated this code or tested it in any way. Use at own risk.


library ieee;
use ieee.std_logic_1164.all;
library unisim;
use unisim.vcomponents.all;


entity larkin_oneshot is
generic (
IOSTANDARD : string := "LVCMOS18"
);
port (
trig : in std_logic;
oneshot_pin : inout std_logic
);
end entity larkin_oneshot;


architecture rtl of larkin_oneshot is

signal obuf_input : std_logic;
signal ibuf_output : std_logic;

begin -- architecture rtl of entity larkin_oneshot

iobuf_inst : component IOBUF
generic map (
IBUF_LOW_PWR => FALSE,
SLEW => "FAST",
IOSTANDARD => IOSTANDARD
)
port map (
O => ibuf_output,
IO => oneshot_pin,
I => obuf_input,
T => '0'
);

oddr_inst : component ODDR
generic map (
DDR_CLK_EDGE => "SAME_EDGE",
SRTYPE => "ASYNC"
)
port map (
Q => obuf_input,
C => trig,
CE => '1',
D1 => '1',
D2 => '1',
R => ibuf_output
);

end architecture rtl; -- of entity larkin_oneshot

That's cool. We'll try it and see what it does.

John

--

John Larkin Highland Technology, Inc

lunatic fringe electronics

 

On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:

Does any manufacturer make a very small programmable logic device (with
FLASH storage) is say a SOIC-8 or similar.

It's for a small home project that only has one output and only one input
(plus CLK)

Thanks in advance.

Ian

I know this is many years since the original question, but...
....Times, they are a changin'...
Here is an under $2 FPGA that sports 11 I/O pins in a tiny 4x4 BGA package (16 pins total).
https://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/ICE40UL1K-SWG16ITR50/220-1960-1-ND/5129490

 

Dear JĂźrgen,

sorry for reviving this thread after all these years - but your mentioned eMail address is invalid meanwhile.
So if you are still listening - did you find the searched disassemblers in the last 18 years?
I have found some pieces, so maybe they might be of interest for you too.

Andreas

 

On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com wrote:

On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
Does any manufacturer make a very small programmable logic device (with
FLASH storage) is say a SOIC-8 or similar.

It's for a small home project that only has one output and only one input
(plus CLK)

Thanks in advance.

Ian

I know this is many years since the original question, but...
...Times, they are a changin'...
Here is an under $2 FPGA that sports 11 I/O pins in a tiny 4x4 BGA package (16 pins total).
https://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/ICE40UL1K-SWG16ITR50/220-1960-1-ND/5129490

Yes, Lattice has been introducing a number of low pin count and medium pin count devices, but they are all in very fine pitch BGA packaging. Great for high volume manufacturing, but sometimes difficult for medium volume work and near impossible for low volume, hand assembly.

Rick C.

 

[Jon Elson]

On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:

On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com wrote:
On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
Does any manufacturer make a very small programmable logic device
(with FLASH storage) is say a SOIC-8 or similar.

It's for a small home project that only has one output and only one
input (plus CLK)

Thanks in advance.

Ian

I know this is many years since the original question, but...
...Times, they are a changin'...
Here is an under $2 FPGA that sports 11 I/O pins in a tiny 4x4 BGA
package (16 pins total).
https://www.digikey.com/product-detail/en/lattice-semiconductor-
corporation/ICE40UL1K-SWG16ITR50/220-1960-1-ND/5129490

Yes, Lattice has been introducing a number of low pin count and medium
pin count devices, but they are all in very fine pitch BGA packaging.
Great for high volume manufacturing, but sometimes difficult for medium
volume work and near impossible for low volume, hand assembly.

Xilinx has the XC95xxXL series of CPLDs, starting at 44 pins quad flat
pack with leads. Very easy to hand solder. These have an internal
architecture based on the old PLD devices, ie. 36-wide and gates, and are
non-volatile. They are also single-voltage (3.3 V).

They also have the CoolRunner II series of CPLDs which are similar in
architecture to FPGAs, non-volatile, available down to 44 pins, same
package as above. These do need dual power supplies (I think 3.3 and 1.2
V).

Jon

 

On Monday, May 21, 2018 at 1:46:15 PM UTC-4, Jon Elson wrote:

On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:

On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com wrote:
On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
Does any manufacturer make a very small programmable logic device
(with FLASH storage) is say a SOIC-8 or similar.

It's for a small home project that only has one output and only one
input (plus CLK)

Thanks in advance.

Ian

I know this is many years since the original question, but...
...Times, they are a changin'...
Here is an under $2 FPGA that sports 11 I/O pins in a tiny 4x4 BGA
package (16 pins total).
https://www.digikey.com/product-detail/en/lattice-semiconductor-
corporation/ICE40UL1K-SWG16ITR50/220-1960-1-ND/5129490

Yes, Lattice has been introducing a number of low pin count and medium
pin count devices, but they are all in very fine pitch BGA packaging.
Great for high volume manufacturing, but sometimes difficult for medium
volume work and near impossible for low volume, hand assembly.
Xilinx has the XC95xxXL series of CPLDs, starting at 44 pins quad flat
pack with leads. Very easy to hand solder. These have an internal
architecture based on the old PLD devices, ie. 36-wide and gates, and are
non-volatile. They are also single-voltage (3.3 V).

They also have the CoolRunner II series of CPLDs which are similar in
architecture to FPGAs, non-volatile, available down to 44 pins, same
package as above. These do need dual power supplies (I think 3.3 and 1.2
V).

Both the Coolrunner II and the 9500 series are very limited in capability and in the case of the Coolrunner II can be rather expensive for the larger devices. They also only package the smallest devices in the smallest packages. They just aren't useful for much other than simple CPLD type applications. Maybe that's because they are simple CPLDs?

Rick C.

 

[Jon Elson]

On Thu, 24 May 2018 10:26:58 -0700, gnuarm.deletethisbit wrote:

On Monday, May 21, 2018 at 1:46:15 PM UTC-4, Jon Elson wrote:
On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:

On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com
wrote:
On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
Does any manufacturer make a very small programmable logic device
(with FLASH storage) is say a SOIC-8 or similar.

It's for a small home project that only has one output and only
one input (plus CLK)

snip

Both the Coolrunner II and the 9500 series are very limited in
capability and in the case of the Coolrunner II can be rather expensive
for the larger devices. They also only package the smallest devices in
the smallest packages. They just aren't useful for much other than
simple CPLD type applications. Maybe that's because they are simple
CPLDs?

Well, the OP did say he had ONE input and ONE output (plus clock) so that
seems like it could be a pretty small circuit. I have a case where I
needed 3 sequential reset pulses to put an Analog Devices chip in the
proper state upon power-up. The smallest XC9536 (now upgraded to
XC9536XL) was perfect, and smaller than I could have done it with 2
74HC4538s plus R & C.

Since the OP didn't give much info, I had to make assumptions on how much
logic he needed.

Jon

 

On Thursday, May 24, 2018 at 3:23:44 PM UTC-4, Jon Elson wrote:

On Thu, 24 May 2018 10:26:58 -0700, gnuarm.deletethisbit wrote:

On Monday, May 21, 2018 at 1:46:15 PM UTC-4, Jon Elson wrote:
On Sun, 20 May 2018 08:46:24 -0700, gnuarm.deletethisbit wrote:

On Sunday, April 1, 2018 at 4:49:58 PM UTC-4, mctuv...@gmail.com
wrote:
On Sunday, April 20, 2003 at 6:30:57 AM UTC-4, Ian Hickey wrote:
Does any manufacturer make a very small programmable logic device
(with FLASH storage) is say a SOIC-8 or similar.

It's for a small home project that only has one output and only
one input (plus CLK)

snip

Both the Coolrunner II and the 9500 series are very limited in
capability and in the case of the Coolrunner II can be rather expensive
for the larger devices. They also only package the smallest devices in
the smallest packages. They just aren't useful for much other than
simple CPLD type applications. Maybe that's because they are simple
CPLDs?
Well, the OP did say he had ONE input and ONE output (plus clock) so that
seems like it could be a pretty small circuit. I have a case where I
needed 3 sequential reset pulses to put an Analog Devices chip in the
proper state upon power-up. The smallest XC9536 (now upgraded to
XC9536XL) was perfect, and smaller than I could have done it with 2
74HC4538s plus R & C.

Since the OP didn't give much info, I had to make assumptions on how much
logic he needed.

Yeah, but if you are still working on the OPs needs he said he wanted a device in an "SOIC-8 or similar".

That is the crux of the problem. There are some number of applications which require more logic than a 22V10 but in a similar size package. Just as there is a wide range of MCU sizes in capability and packages it would be useful to have a similar range of capacities and packages for FPGAs. Not all MCUs in a 20 pin package are limited to 8 kB of Flash, some go well beyond that. But in FPGAs they seem to be less interested in a proliferation of die types so when they plan their devices a die with this must logic has this many I/O pins and they try to make as many as possible in the packages.

I was once told the die sizes in low end FPGAs are I/O bound. So the higher pin counts become a self fulfilling prophesy so they can charge more. I've also been told the FPGA makers have no interest in competing in the same application space as MCUs since the margins are much narrower. The big two FPGA makers are in the same mindset that their primary market is to supply the larger devices to the large communications vendors. Everything else is picking up bread crumbs.

If it weren't for that FPGAs would support many of the same interfaces that MCUs do and be available in similar packaging - able to compete head to head for applications that don't take a quarter MB of program to implement. Lattice presently has a 384 LUT device for just a couple of bucks, but it is in a package with 0.4 mm ball pitch which is not so easy to work with without a very fine PWB process and micro vias.

Rick C.

 

[Jon Elson]

On Thu, 24 May 2018 13:37:46 -0700, gnuarm.deletethisbit wrote:

Yeah, but if you are still working on the OPs needs he said he wanted a
device in an "SOIC-8 or similar".

Yup, that makes the problem harder. Really, the 44-pin QFP isn't a WHOLE
bunch bigger than an SOIC-8. And, maybe there are some devices I don't
know about that are in such a small package.

Jon

 

On Friday, May 25, 2018 at 3:01:56 PM UTC-4, Jon Elson wrote:

On Thu, 24 May 2018 13:37:46 -0700, gnuarm.deletethisbit wrote:



Yeah, but if you are still working on the OPs needs he said he wanted a
device in an "SOIC-8 or similar".

Yup, that makes the problem harder. Really, the 44-pin QFP isn't a WHOLE
bunch bigger than an SOIC-8. And, maybe there are some devices I don't
know about that are in such a small package.

I've never seen anything in an 8 pin package, not even a PLD. There are companies that make "programmable" logic in very pin limited packages. But they aren't "programmable" in the same way as PLDs. More like a 2 input mux (I don't recall the exact details) intended so you can wire it into your circuit to be a number of different types of 2 or 3 input gates. The goal is to replace multiple part numbers with a single line item in the BOM. Here is one just emailed to me recently.

https://www.digikey.com/en/product-highlight/n/nxp-semi/dual-pcb-configurable-logic

Rick C.

 

On Tuesday, April 22, 2003 at 12:01:26 AM UTC-5, Jim Granville wrote:

Ian Hickey wrote:

Yes there are many small 8-pin micros out there which are very cheap sub $1.
The project does have some medium speed requirement but probably could be
achieved with PIC12C508 or MSP430F1101A.

My main reason for looking for a CPLD or similar was I have years of micro
work and was looking for a challenge.

Is no one aware of a third tier manufacturer specialising in medium speed
10MHz to 30MHz logic with small pin count?

Currently you have SPLD and (smaller) CPLD to choose from.

SPLD come in TSSOP packages, so are quite small, but have quite low
register counts.
Lattice have just released a MLF package ispGAL22V10.

In CPLD, TQFP44 (10mm) is the most common small package.
Some offer BGA, but these have problems on single sided PCBs
TQFP48 (7mm) is appearing 'selectively'.

MLF packages are obvious for (smaller) CPLDs, as they have
high density and low electrical and thermal impedances, and can
be used right down to single sided PCBs.
The PLD industry is rather slower at seeing this, than the
uC industry.

-jg

It should be mentioned that the Cypress PSOC family has a modest CPLD fabric and is available in QFN-24+ and SOIC-8+ packages. Get a free Cortex M1.

 

On Friday, May 25, 2018 at 7:42:54 PM UTC-4, jim.bra...@ieee.org wrote:

On Tuesday, April 22, 2003 at 12:01:26 AM UTC-5, Jim Granville wrote:
Ian Hickey wrote:

Yes there are many small 8-pin micros out there which are very cheap sub $1.
The project does have some medium speed requirement but probably could be
achieved with PIC12C508 or MSP430F1101A.

My main reason for looking for a CPLD or similar was I have years of micro
work and was looking for a challenge.

Is no one aware of a third tier manufacturer specialising in medium speed
10MHz to 30MHz logic with small pin count?

Currently you have SPLD and (smaller) CPLD to choose from.

SPLD come in TSSOP packages, so are quite small, but have quite low
register counts.
Lattice have just released a MLF package ispGAL22V10.

In CPLD, TQFP44 (10mm) is the most common small package.
Some offer BGA, but these have problems on single sided PCBs
TQFP48 (7mm) is appearing 'selectively'.

MLF packages are obvious for (smaller) CPLDs, as they have
high density and low electrical and thermal impedances, and can
be used right down to single sided PCBs.
The PLD industry is rather slower at seeing this, than the
uC industry.

-jg

It should be mentioned that the Cypress PSOC family has a modest CPLD fabric and is available in QFN-24+ and SOIC-8+ packages. Get a free Cortex M1..

I have worked with the PSOC and I don't really consider it to contain FPGA capability. The blocks they provide are much higher level than LUTs and FFs. They have function units with a degree of programmability. I believe they offer some support for programming in Verilog, but I have no idea how constrained that is. The device I worked with most recently really didn't have the general blocks at all, it had some highly configurable serial port units that could be UART, USART, SPI, etc. Not at all PLD like.

I think I read something about their newer devices, but I don't recall what was new. Here it is, PSOC6 dual core ARM, CM4, CM0+. I believe there is a version with a BLE stack on the CM0+. They have versions with 12 UDBs (universal digital blocks) or none. I guess that is PLD like, but I recall they didn't let you in on the details. Rather they have software that lets you chain preconfigured functions graphically.

Rick C.

 

On Tuesday, April 24, 2018 at 6:32:38 AM UTC-4, azie...@gmail.com wrote:

Dear JĂźrgen,

sorry for reviving this thread after all these years - but your mentioned eMail address is invalid meanwhile.
So if you are still listening - did you find the searched disassemblers in the last 18 years?
I have found some pieces, so maybe they might be of interest for you too.

Andreas

Hello. I am looking for some disassemblers too. 8051 In particular. Can you help?

 

[David Brown]

On 16/12/18 21:06, frankcovending@gmail.com wrote:

On Tuesday, April 24, 2018 at 6:32:38 AM UTC-4, azie...@gmail.com wrote:
Dear JĂźrgen,

sorry for reviving this thread after all these years - but your mentioned eMail address is invalid meanwhile.
So if you are still listening - did you find the searched disassemblers in the last 18 years?
I have found some pieces, so maybe they might be of interest for you too.

Andreas

Hello. I am looking for some disassemblers too. 8051 In particular. Can you help?

It should not be hard to find an 8051 disassembler with a little google
searching.

If you want to get help from a Usenet group, please remember that these
really are communities - Google Groups is an archive, so searching for
old posts and replying to them is not going to get you anywhere. Get a
real newsreader client (Thunderbird is fine, and works on all
platforms), get a real Usenet server (news.eternal-september.org is a
good, free choice), and join the groups that interest you.
comp.arch.embedded is probably your best bet here.

 

I've spent hours searching and kept coming up empty. I've found all of the manuals and all software through google, but that 8051 compiler just isn't easy. You are probably right that replying to old emails etc is not going to get me far, but it is a resource and I'm going to exhaust all of them. I'll look into the resources you have provided.

 

[David Brown]

On 17/12/18 13:40, frankcovending@gmail.com wrote:

I've spent hours searching and kept coming up empty. I've found all
of the manuals and all software through google, but that 8051
compiler just isn't easy. You are probably right that replying to old
emails etc is not going to get me far, but it is a resource and I'm
going to exhaust all of them. I'll look into the resources you have
provided.

A compiler is entirely different from a disassembler. You said "I am
looking for some disassemblers too. 8051 in particular". Now you say
you want a compiler. Which is it?

There are /lots/ of compiler for the 8051. Many commercial ones, and at
least one solid open source one. I don't know about disassemblers for
the core, having never needed to use one, but google finds plenty within
a few seconds.

You need to figure out what tool(s) you are actually looking for - or at
least figure out what you want to do with them. You need to figure out
whether you are dealing with the core in general, or specific devices,
whether you want commercial tools or free ones, and so on.

And if you want help from people, you will have to say what you have
tried so far and why those tools have been inappropriate. Otherwise no
one can help.

But as I say, please drop the "Google Groups" interface - it is
absolutely terrible for posting to Usenet (though it is okay for
searching archives). If you can't use a proper Usenet client, then at
least learn to use Google Groups properly - it's default options are
contrary to standard Usenet usage. (This is not your fault, it is
Google's fault - but it is you, the GG poster, who has to make the
effort.) Quote posts correctly, with attribution and appropriate
snipping, and split your lines correctly.

And then, when you have this figured out, post to comp.arch.embedded -
it is the best newsgroup for such tools. (comp.arch.fpga is a fine and
helpful group too, but c.a.e. will reach more 8051 users.)

 

On Monday, December 17, 2018 at 9:31:21 AM UTC-5, David Brown wrote:

On 17/12/18 13:40, wrote:
I've spent hours searching and kept coming up empty. I've found all
of the manuals and all software through google, but that 8051
compiler just isn't easy. You are probably right that replying to old
emails etc is not going to get me far, but it is a resource and I'm
going to exhaust all of them. I'll look into the resources you have
provided.


A compiler is entirely different from a disassembler. You said "I am
looking for some disassemblers too. 8051 in particular". Now you say
you want a compiler. Which is it?

There are /lots/ of compiler for the 8051. Many commercial ones, and at
least one solid open source one. I don't know about disassemblers for
the core, having never needed to use one, but google finds plenty within
a few seconds.

You need to figure out what tool(s) you are actually looking for - or at
least figure out what you want to do with them. You need to figure out
whether you are dealing with the core in general, or specific devices,
whether you want commercial tools or free ones, and so on.

And if you want help from people, you will have to say what you have
tried so far and why those tools have been inappropriate. Otherwise no
one can help.

But as I say, please drop the "Google Groups" interface - it is
absolutely terrible for posting to Usenet (though it is okay for
searching archives). If you can't use a proper Usenet client, then at
least learn to use Google Groups properly - it's default options are
contrary to standard Usenet usage. (This is not your fault, it is
Google's fault - but it is you, the GG poster, who has to make the
effort.) Quote posts correctly, with attribution and appropriate
snipping, and split your lines correctly.

And then, when you have this figured out, post to comp.arch.embedded -
it is the best newsgroup for such tools. (comp.arch.fpga is a fine and
helpful group too, but c.a.e. will reach more 8051 users.)

My mistake on my prior reply. I did not intend to say compiler. I meant to say disassembler. My mistake, human...

I get what you're saying about everything being on google, but it's a tool not the means to an end. I'm trying to get my hands on the 8051 disassembler for the pm3585 logic analyzer. I'm trying to learn how to debug the 8051 using the pm3585.


Now I have been out of the electronics/computer field for quite some time and I had shifted my focus to mechanical and civil engineering. I am just getting back into hobby electronics. I am working on some mechatronics project at home in my free time and I'm prototyping with off the shelf controllers, but my goal is to develop my own controller and I am tempted to use the 8051 or a Z80. I'm leaning towards the 8051 because the DS89C4XX has everything I need and I have the components from a sample pack I got almost a decade ago. I have a Z80 as well.