Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 35475

Article: 35475
Subject: Re: ROM based FSMs
From: "Sergio Masci" <sergio@NO.SPAM.xcprod.com>
Date: Sun, 7 Oct 2001 01:59:45 +0100
Links: << >>  << T >>  << A >>

Andrew Barnish <barnish@hotmail.com> wrote in message
news:c92b233a.0110061528.3007dd89@posting.google.com...
> "Sergio Masci" <sergio@NO.SPAM.xcprod.com> wrote in message
news:<ULmv7.11508$GT3.1674495@news2-win.server.ntlworld.com>...
> > If I read this right, you would have a maximum of 256 states and 4
events.
> > Presumably you could half the number of states and double the number
> > of events?
> >
>
> Yes, there are different possibilities depending on the
> size/configuration of the ROM. I think that for very large state
> machines this will perform better than the LUT equivalent, although I
> haven't done too many experiments.
> The other advantage is that you can make use of blockram that might be
> totally unused in the design, saving a fair amount of logic cells.
>
> > I might be able to get ZMech to do this for you with a few tweaks.What
> > would the tables you require (raw hex) look like.
> >
> > maybe something like
> >     <input state>, <event>, <output state>
> >     <input state>, <event>, <output state>
> >     <input state>, <event>, <output state>
> >
> > How would the binary be packed?
> >
>
>
> Yes this is the kind of description that I would like automatically
> converted into the ROM hex. Describing the connections of the block
> ram is no problem. Deriving the contents of the ROM is the
> brain-hurting part. Ideally, I would like to infer the blockram
> implementation from a traditional FSM description as registers and a
> large case statement described in VHDL. Maybe, FPGA Synthesis tools
> will do this one day.....
>
> I believe FSMs implemented in PROMs were common in the past - what
> tools did people use back then in order to derive the PROM contents?
>
> What is this ZMech you mention?
>
> Cheers,
>
> Andy

ZMech is a state machine development tool. It allows you to design complex
state machines useing state diagrams. It has a built in diagram editor and
is
capable of interactively debugging state machines directly on the diagram.
One version generates binary executable code targetted at the PIC 16 series
and comes with a built in simulator for debugging multi MCU designs (again
on the original diagram).

ZMech is built using a meta-CASE tool and it would be a simple mater to
change the code generator (actually short circuit most of it) to generate
some hex tables from the state diagrams. You would need to specify what
YOU want the tables to look like. Currently state transitions require a
nominated function, this would probably need to be changed to an output
value.

ZMech and docs can be found at http://www.xcprod.com/titan

Regards
Sergio Masci



Article: 35476
Subject: Re: ROM based FSMs
From: Ray Andraka <ray@andraka.com>
Date: Sun, 07 Oct 2001 02:56:16 GMT
Links: << >>  << T >>  << A >>
I worked with several of these in the early 80's.  No special tools are needed,  The outputs consist partly of the next state
vector.  The input selects two or more addresses.  It is pretty straight forward.  The only time it gets tricky is if you start
being creative with the state assignments so that next state bits double as outputs and arranging the states so as to minimize
the input mux if needed.

Peter brought up a good point regarding the speed.  The slow speed of the block RAMs is due mostly to the long delay for the
enable, and due to routing to get signals to/from the block RAM.  In the case of a state machine, many of your outputs are
wrapped back around to the input, so you avoid some of the penalty usually associated with the block RAMs.  You are also not
using the write enable, and you can get away with not using enables on reads (tying it high), so you can eliminate the worst
paths.



Andrew Barnish wrote:

> "Sergio Masci" <sergio@NO.SPAM.xcprod.com> wrote in message news:<ULmv7.11508$GT3.1674495@news2-win.server.ntlworld.com>...
> > If I read this right, you would have a maximum of 256 states and 4 events.
> > Presumably you could half the number of states and double the number
> > of events?
> >
>
> Yes, there are different possibilities depending on the
> size/configuration of the ROM. I think that for very large state
> machines this will perform better than the LUT equivalent, although I
> haven't done too many experiments.
> The other advantage is that you can make use of blockram that might be
> totally unused in the design, saving a fair amount of logic cells.
>
> > I might be able to get ZMech to do this for you with a few tweaks.What
> > would the tables you require (raw hex) look like.
> >
> > maybe something like
> >     <input state>, <event>, <output state>
> >     <input state>, <event>, <output state>
> >     <input state>, <event>, <output state>
> >
> > How would the binary be packed?
> >
>
> Yes this is the kind of description that I would like automatically
> converted into the ROM hex. Describing the connections of the block
> ram is no problem. Deriving the contents of the ROM is the
> brain-hurting part. Ideally, I would like to infer the blockram
> implementation from a traditional FSM description as registers and a
> large case statement described in VHDL. Maybe, FPGA Synthesis tools
> will do this one day.....
>
> I believe FSMs implemented in PROMs were common in the past - what
> tools did people use back then in order to derive the PROM contents?
>
> What is this ZMech you mention?
>
> Cheers,
>
> Andy

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35477
Subject: Re: ROM based FSMs
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sun, 07 Oct 2001 09:23:29 +0200
Links: << >>  << T >>  << A >>
Ray Andraka schrieb:
> 

> Peter brought up a good point regarding the speed.  The slow speed of the block RAMs is due mostly to the long delay for the
> enable, and due to routing to get signals to/from the block RAM.  In the case of a state machine, many of your outputs are
> wrapped back around to the input, so you avoid some of the penalty usually associated with the block RAMs.  You are also not
> using the write enable, and you can get away with not using enables on reads (tying it high), so you can eliminate the worst
> paths.

First question. Why are the enable signals so slow?

Second question. Does the static timing analyzer recognize that the
enables are not used (tied to a constant) and then ignore these timing
parameters?

-- 
MFG
Falk


Article: 35478
Subject: Re: ROM based FSMs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 07 Oct 2001 10:12:30 +0100
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> Since I indirectly started this thread ( it started with quoting my article in
> TechXclusives ) let me give my $ 0.02 worth:
>
> Tools:
> There is no software tool, but is it really needed?
> You have to decide anyhow exactly what to do in each state, where to branches and what
> outputs to activate. And that is really the only information you have to throw into the
> ROM. So, what would the software do for you?
>

IMO if such a thing is going to be useful it needs to be integrated in some way into an HDL
design flow. In particular the state transition description needs to ``compile'' down to a
bunch of BlockRAM INIT parameters that can be merged into the UCF/PCF - this could be a
simple Perl script or something more sophisticated built from yacc/lex.. Interestingly
Synplify can already

o Infer simple LUT based ROMs from ``case'' statements.

o In some limited circumstances it can infer BlockRAMs from HDL code.

Putting these 2 together gives the nice possibility of inferring a BlockRAM based FSM from
HDL
code.

Condition inputs:

> The basic design has a limited number of encoded branch control inputs. It may be
> necessary to expand this with an extra multiplexer.
>
> Just to explain the beauty of the concept:
> In one Virtex-II BlockRAM you can implement a 128-state FSM with 4-way branch and 29
> outputs.

What about us poor b*****s who are stuck with antedeluvian Virtex-Es ? Reading this NG its
getting to the point where I'm thinking of putting a sticky label over the FPGA to reduce
embarrassment. It will read ``When I grow up I want to be a Virtex-II''. :o).

More seriously using 2 512x8 BRAMs (or both parts of a single one ?) in parallel gets me
32-state, 4-way branch, 11 outputs.




Article: 35479
Subject: Altera LCELL and output pins
From: "luigi funes" <fuzzy8888@hotmail.com>
Date: Sun, 07 Oct 2001 10:26:54 GMT
Links: << >>  << T >>  << A >>
I have a problem with Altera software.
I'm non able to drive two pins with the *same*
LCELL.
This code shows the core of the problem:

LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY dout IS
  PORT
  (
    a, b, c1, c2  : IN STD_LOGIC;
    o1, o2        : OUT STD_LOGIC
  );
END dout;

ARCHITECTURE behav OF dout IS
  SIGNAL n : STD_LOGIC;
BEGIN
  n  <= a AND b;
  o1 <= n WHEN c1='1' ELSE 'Z';
  o2 <= n WHEN c2='1' ELSE 'Z';
END behav;

I'm shure it could be done with a single LCELL,
but MAX+plus II (vers. 10.0) generates two.
Any advice to avoid this waste?

Luigi




Article: 35480
Subject: Re: ROM based FSMs
From: Ray Andraka <ray@andraka.com>
Date: Sun, 07 Oct 2001 14:45:29 GMT
Links: << >>  << T >>  << A >>
I wouldn't call those 'stuck' with the Virtex-E unfortunate.   I've found that a virtexE of a
given gate density is actually more capable for DSP processing than a VirtexII of the same
density.  Consider that an XC2V1000 has a mere 5120 slices compared with 12288 in the
XCV1000e.  The gate count in the V-2s is eaten up in memory  and multipliers, and the
multipliers are quite a bit slower than what you can do in the fabric.  The net result is I can
usually pack more processing power into an equivalent E part.

Balancing out the more constrained resources however, there is the ease of use.  With the
VirtexII, one needn't be as well versed in computing hardware to get something that works.
This makes FPGA DSP more available to the average designer.

Rick Filipkiewicz wrote:

> Peter Alfke wrote:
>
> > Since I indirectly started this thread ( it started with quoting my article in
> > TechXclusives ) let me give my $ 0.02 worth:
> >
> > Tools:
> > There is no software tool, but is it really needed?
> > You have to decide anyhow exactly what to do in each state, where to branches and what
> > outputs to activate. And that is really the only information you have to throw into the
> > ROM. So, what would the software do for you?
> >
>
> IMO if such a thing is going to be useful it needs to be integrated in some way into an HDL
> design flow. In particular the state transition description needs to ``compile'' down to a
> bunch of BlockRAM INIT parameters that can be merged into the UCF/PCF - this could be a
> simple Perl script or something more sophisticated built from yacc/lex.. Interestingly
> Synplify can already
>
> o Infer simple LUT based ROMs from ``case'' statements.
>
> o In some limited circumstances it can infer BlockRAMs from HDL code.
>
> Putting these 2 together gives the nice possibility of inferring a BlockRAM based FSM from
> HDL
> code.
>
> Condition inputs:
>
> > The basic design has a limited number of encoded branch control inputs. It may be
> > necessary to expand this with an extra multiplexer.
> >
> > Just to explain the beauty of the concept:
> > In one Virtex-II BlockRAM you can implement a 128-state FSM with 4-way branch and 29
> > outputs.
>
> What about us poor b*****s who are stuck with antedeluvian Virtex-Es ? Reading this NG its
> getting to the point where I'm thinking of putting a sticky label over the FPGA to reduce
> embarrassment. It will read ``When I grow up I want to be a Virtex-II''. :o).
>
> More seriously using 2 512x8 BRAMs (or both parts of a single one ?) in parallel gets me
> 32-state, 4-way branch, 11 outputs.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35481
Subject: Re: ROM based FSMs
From: Ray Andraka <ray@andraka.com>
Date: Sun, 07 Oct 2001 14:52:12 GMT
Links: << >>  << T >>  << A >>
You'll have to ask the folks at Xilinx why.  If you look at the timing for them, you'll see that the setup and hold times for the
enable, write enable and reset are more than twice the delays for the address and data inputs.  Yes, the static timing analyzer
will ignore those inputs if they are just tied high.  If they come from logic, however, they do not get ignored.  Unfortunately,
in most cases you use the BRAMs as RAM, which often means that the write enable has to be used.  There is room to be creative in
the design so that the enables don't get used.

Falk Brunner wrote:

> Ray Andraka schrieb:
> >
>
> > Peter brought up a good point regarding the speed.  The slow speed of the block RAMs is due mostly to the long delay for the
> > enable, and due to routing to get signals to/from the block RAM.  In the case of a state machine, many of your outputs are
> > wrapped back around to the input, so you avoid some of the penalty usually associated with the block RAMs.  You are also not
> > using the write enable, and you can get away with not using enables on reads (tying it high), so you can eliminate the worst
> > paths.
>
> First question. Why are the enable signals so slow?
>
> Second question. Does the static timing analyzer recognize that the
> enables are not used (tied to a constant) and then ignore these timing
> parameters?
>
> --
> MFG
> Falk

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35482
Subject: Re: ROM based FSMs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 07 Oct 2001 20:27:46 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> I wouldn't call those 'stuck' with the Virtex-E unfortunate.   I've found that a virtexE of a
> given gate density is actually more capable for DSP processing than a VirtexII of the same
> density.  Consider that an XC2V1000 has a mere 5120 slices compared with 12288 in the
> XCV1000e.  The gate count in the V-2s is eaten up in memory  and multipliers, and the
> multipliers are quite a bit slower than what you can do in the fabric.  The net result is I can
> usually pack more processing power into an equivalent E part.
>
> Balancing out the more constrained resources however, there is the ease of use.  With the
> VirtexII, one needn't be as well versed in computing hardware to get something that works.
> This makes FPGA DSP more available to the average designer.
>
> Rick Filipkiewicz wrote:

Yeah. I was only partly joking. In slice count & number of BRAMs (o.k. they are bigger) the
XC2V1000 is ~equivalent to the XCV400E. I expect Xilinx might claim that improved interconnect will
allow higher density designs to maintain timing more easily and/or move the point where serious
floorplanning is needed to get increased speed - ease of use again.

I'm only considering the V-2s in order to get DDR DRAM going with a 125MHz target speed for the
system clock although it does turn out that the, as yet unreleased, XC2V1500 (~XCV600E) is a very
good way of meeting some high pincount requirements without paying through the nose for logic I
don't need.

Also I seem to remember some claim that in speed terms the -5 V-2  is ~= the -8 V-E.

This discussion has decided me to at least try the BRAM FSM thing, I've got 22 of them hanging
around not earning their keep.


Article: 35483
(removed)


Article: 35484
Subject: Re: ROM based FSMs
From: Ray Andraka <ray@andraka.com>
Date: Sun, 07 Oct 2001 20:30:42 GMT
Links: << >>  << T >>  << A >>
Yeah, in the V2, I think we'll be forced to look for ways to use the multipliers and BRAMs in ways they
were not intended in order to fully ustilize the device.  DDR pins is a win for V2.  DDR is a royal
pain in the patoot to pull off in the virtexE.  125 mHz internal clock isn't too bad, although you'll
have to either be really careful in your rtl or do a bit of floorplanning to make it happen in a -6.
It is certainly not an unreachable target though.

Rick Filipkiewicz wrote:

> Ray Andraka wrote:
>
> > I wouldn't call those 'stuck' with the Virtex-E unfortunate.   I've found that a virtexE of a
> > given gate density is actually more capable for DSP processing than a VirtexII of the same
> > density.  Consider that an XC2V1000 has a mere 5120 slices compared with 12288 in the
> > XCV1000e.  The gate count in the V-2s is eaten up in memory  and multipliers, and the
> > multipliers are quite a bit slower than what you can do in the fabric.  The net result is I can
> > usually pack more processing power into an equivalent E part.
> >
> > Balancing out the more constrained resources however, there is the ease of use.  With the
> > VirtexII, one needn't be as well versed in computing hardware to get something that works.
> > This makes FPGA DSP more available to the average designer.
> >
> > Rick Filipkiewicz wrote:
>
> Yeah. I was only partly joking. In slice count & number of BRAMs (o.k. they are bigger) the
> XC2V1000 is ~equivalent to the XCV400E. I expect Xilinx might claim that improved interconnect will
> allow higher density designs to maintain timing more easily and/or move the point where serious
> floorplanning is needed to get increased speed - ease of use again.
>
> I'm only considering the V-2s in order to get DDR DRAM going with a 125MHz target speed for the
> system clock although it does turn out that the, as yet unreleased, XC2V1500 (~XCV600E) is a very
> good way of meeting some high pincount requirements without paying through the nose for logic I
> don't need.
>
> Also I seem to remember some claim that in speed terms the -5 V-2  is ~= the -8 V-E.
>
> This discussion has decided me to at least try the BRAM FSM thing, I've got 22 of them hanging
> around not earning their keep.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35485
Subject: Re: Video processing
From: "Jolly Joker" <joker@blurb.co>
Date: Sun, 07 Oct 2001 21:55:54 GMT
Links: << >>  << T >>  << A >>

Ben <seabybs@hotmail.com> wrote in message
news:TFpv7.13032$GT3.1857396@news2-win.server.ntlworld.com...
> Hi,
Hi,
>  I'm doing a literature search for my university project. This is based on
> real-time digital video processing using FPGA technology.
>
> Does anyone out there have any recommendations for book, papers, websites
or
> magazine articles worth reading, or people worth speaking to on the
subject?
Look at the website of Celoxica (www.celoxica.com) in the Case study pages.
They have several impressive demos that show this (e.g. on their RC-100 eval
board).

>  I've been to Xilix, Altera etc, but want to get as much information as
> possible.
>
> Any information greatly appreciated,
> Ben.
Herman




Article: 35486
(removed)


Article: 35487
Subject: Re: future Xilinx products wish list ...
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Sun, 7 Oct 2001 23:14:33 -0400
Links: << >>  << T >>  << A >>
I agree with the original poster's comments.

Also, it would be nice if the 'done' signal were available to a user
programmable pin in addition to it's regular pin. (Perhaps it could be
tri-state isolated from the user pin after configuration). That way, it
could be used in address decoding for an eprom shared between configuration
bits and microprocessor code. Might save some external gates.

Rob
http://www.birdcomputer.ca/






Article: 35488
Subject: Re: future Xilinx products wish list ...
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 08 Oct 2001 03:40:37 GMT
Links: << >>  << T >>  << A >>
Why don't you use "any" pin, rely on the fact that it is 3-stated with weak
pull-up during configuration, and make it active Low after configuration.
Maybe add a 1 kilohm pull-up...
Or am I missing something ?

Peter Alfke

Rob Finch wrote:

> I agree with the original poster's comments.
>
> Also, it would be nice if the 'done' signal were available to a user
> programmable pin in addition to it's regular pin. (Perhaps it could be
> tri-state isolated from the user pin after configuration). That way, it
> could be used in address decoding for an eprom shared between configuration
> bits and microprocessor code. Might save some external gates.
>
> Rob
> http://www.birdcomputer.ca/


Article: 35489
Subject: IEEE 802.11 Design
From: vlsiabcd@rediffmail.com (VLSI)
Date: 7 Oct 2001 22:04:12 -0700
Links: << >>  << T >>  << A >>
Hello VLSI Gurus,
         One of my friends is trying to convince me that he with a
team of 3 (inclduing himself) can design a IEEE 802.11 (WAN) compliant
IP (atleast the softcore, i.e. RTL, plus synthesis, Verification etc.)
starting from IEEE Specs within 12 weeks.

  The average team expereince is 4 years (or 5 maximum) with hardly
any expereince on Ethernet etc. The team's Verilog strength is also
"moderate" - meaning not so great.

  My question to you all experts is: "Is this a realistic schedule"? I
thought a minimum of 6 months is needed.

Thanks a lot for any suggestions (this information will be useful for
my another friend who is willing to join this group).

Sorry for off-topic, off-techincal post.

Kind Regards,
VLSI Engr.

Article: 35490
Subject: VIRTEX-II PCIX CORE
From: aadityas@hotpop.com (Sriram S)
Date: 7 Oct 2001 23:22:04 -0700
Links: << >>  << T >>  << A >>
Hi,

The Virtex-II (FF1152 Package) PCIX soft core uses Banks 2 and 3.
Hence these banks are locked to IOSTANDARD PCIX. But surprisingly
since there is no GCLK pin in these two banks, it is using Bank 1 GCLK
pin, but the problem is that i require the bank 1 to operate in LVCMOS
and hence the PCIX clock pin will have to be in LVCMOS. I just want to
get a help in this regard whether the PCIX clock can be driven to a
GCLK pin which is configured as a LVCMOS SelectIO.


Please help...

Warm regards
rama

Article: 35491
Subject: Virtex-2 maximum clock speed
From: himan_2000@indiatimes.com (himanshu)
Date: 8 Oct 2001 01:15:55 -0700
Links: << >>  << T >>  << A >>
Hi,
  can any body tell me what is the maximum clock speed at which xilinx
virtex-2 fpga can work?? It has got 8 DLLs..what is the maximum clock
rate they can provide. do i have to divide that frequency for clock
stability?
Thanks in advance
Himanshu

Article: 35492
(removed)


Article: 35493
(removed)


Article: 35494
(removed)


Article: 35495
Subject: Re: ROM based FSMs
From: hamish@cloud.net.au
Date: Mon, 08 Oct 2001 13:18:04 GMT
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote:
> Synplify can already

> o Infer simple LUT based ROMs from ``case'' statements.

> o In some limited circumstances it can infer BlockRAMs from HDL code.

> Putting these 2 together gives the nice possibility of inferring a BlockRAM based FSM from HDL code.

Also, the ISE 4.1 mapper has a command line switch for mapping logic
functions into block RAMs. I haven't tried it, but it sounds kind of
neat if you have spare block RAMs.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 35496
Subject: Re: ROM based FSMs
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Mon, 8 Oct 2001 14:23:52 +0100
Links: << >>  << T >>  << A >>
In article <3BBF4514.411C73A8@algor.co.uk>, Rick Filipkiewicz
<rick@algor.co.uk> writes

>IIRC there were even some CPUs with ``writeable'' control store that allowed the
>instruction sets to be tailored to some degree [Fairchild Clipper ?].

Nope, the Clipper never had a user-accessible WCS as far as I am aware.
Certainly not in any of the data or appnotes I ever saw as an FAE (for
Intergraph, after they bought the Clipper product from Fairchild).

Several other machines did, though.  ISTR some of the CDC and 
Burroughs machines had them.  And I am aware of at least one British
early-80s design that did (High Level Hardware's Orion - based on 
AMD 2910 etc etc.  In the instruction decoder there was a pointer
into the writeable microcode; this pointer was visible as a CPU
register;  so you could change instruction set on the fly.  Scary.)

Anyone for reconfigurable computing? :-)
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 35497
Subject: Re: ROM based FSMs
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Mon, 8 Oct 2001 14:26:00 +0100
Links: << >>  << T >>  << A >>
In article <c92b233a.0110061528.3007dd89@posting.google.com>, Andrew
Barnish <barnish@hotmail.com> writes

>I believe FSMs implemented in PROMs were common in the past - what
>tools did people use back then in order to derive the PROM contents?

Pencil and paper, according to my increasingly jaundiced recollections.
Not entirely unreasonable with 256x8 PROMs, but still a b****y pain.
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 35498
Subject: Synplify and internal tristate
From: "Paul Butler" <c_paul_butler@yahoo.com>
Date: Mon, 8 Oct 2001 08:26:36 -0500
Links: << >>  << T >>  << A >>
In the VHDL below, I intend to synthesize two FFs:  one for the output data
and one for the output tristate.  Synthesizing with Synplify for an XC2V40,
I get 3 FFs and my tristate control for the output "SelectedData" is not a
register output.

Synplify notices that my internal tristate bus is not always enabled and
propagates the undriven states through the output data FF.

Do most people expect this behavior?  Does 1076.6 address this issue?

Thanks,
Paul Butler

----------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity tristate is
  port(
    Clk : in std_logic;

    EnableOutput : in boolean;
    address : in unsigned(3 downto 0);
    Data : in std_logic_vector(5 downto 0);

    SelectedData : out std_logic
  );
end tristate;

architecture rtl of tristate is

  signal EnableOutputQ : boolean;

  signal iSelectedData : std_logic;
  signal SelectedDataQ : std_logic;

begin

  TristateMUX:
  for i in Data'range generate
    iSelectedData <= Data(i) when i=address else 'Z';
  end generate TristateMUX;

  OutputFFs:
  Process(clk)
  begin
    if rising_edge(clk) then
      SelectedDataQ <= iSelectedData;
      EnableOutputQ <= EnableOutput;
    end if;
  end process;

  OutputTristate:
  SelectedData <= SelectedDataQ when EnableOutputQ else 'Z';

end rtl;







Article: 35499
Subject: Re: future Xilinx products wish list ...
From: Eric <erv_NO_SPAM@sympatico.ca>
Date: Mon, 08 Oct 2001 11:47:20 -0400
Links: << >>  << T >>  << A >>
Hi,

Talking about pins that could be used for user IO after configuration, there is :

- M0 M1 M2 : According to the data sheet (Spartan II, page 13), the state
of these pins is only required to be valid on the Low to High transition of INIT
(not very clear, would seem more logical if they had a setup time).
No matter the exact timing, they obviously are only required at a precise point
during configuration and are useless except at that time.
After configuration, I see no reason why they could not be used as IO.

- HSWAP_EN (Virtex II)
Same as M0 .. M2

- CCLK : Obviously, it have no function after configuration is complete, and in most
apps, I end up connecting it to another IO pin (when configuration is bit banged by a
processor, CCLK is usually connected to some kind of address decoding, and it is
used after configuration as a "Chip Select" input).
Here too, I can't see any reason for not using it as an IO

- TDI TDO TMS TCK
In previous series (at least Spartan), these could be used as IO if the boundary scan
function was not required. I miss these 4 pins (even if I screwed up once with them
and could not properly configure the chip because of random data being fed to them).
With proper care, they are great as IO too.

- DONE.
Here too, as Rob Finch said, I can't see why it's not a user IO after configuration.

- PROGRAM.

Obviously, this pin can't be used as an input, but it could be used as an Open drain output.
Hiz : Well, does nothing ...
Low : If properly latched / delayed /cleared, can be used to trigger self reconfiguration.
This self reset can be used to restart without using external logic when a faulty condition
is detected (or whenever the designer want to reboot the device).

------

Also, as Geoffrey G. Rochat stated, I miss both HDC and LDC pins too.

Another pin that might be very useful (if Master Parallel mode goes back) would be a "TDC"
pin that would toggle during configuration.
Here's how it would work :
Initially, it would be a high impedance (or high level) pin, but if the configuration fail,
it would go to "0" and start toggling each time the configuration fails.

The use would be to connect it to an address pin of the configuration ROM in systems that
require the FPGA to start even in case of a failed configuration download.

That way, the FPGA would attempt to start from the potentially corrupted configuration
data, detect the bad CRC and restart from the original "fail-safe" configuration.

This fail-safe mode is needed as soon as a potentially unreliable update must be made
(such as remote/modem update), at the expense of a doubled configuration rom size.

In applications that don't need the functions, it's very rare not to be able to find
any pin in the design that can be either pulled high, or low, or toggled during
configuration with no adverse effect.

------

These changes would help mostly with low pin count packages where these ten user IO pins
could certainly be put to good use, and since this is all programmable, it would all be
backward compatible (except HDC / LDC) for users who don't need them.

Also, not loosing pins used for configuration would allow for even more configuration options
without loosing more user pins (and/or increasing the number of Power/GND pairs without
decreasing the useable pin count).

Éric.

---------------------------------

Rob Finch wrote:

> I agree with the original poster's comments.
>
> Also, it would be nice if the 'done' signal were available to a user
> programmable pin in addition to it's regular pin. (Perhaps it could be
> tri-state isolated from the user pin after configuration). That way, it
> could be used in address decoding for an eprom shared between configuration
> bits and microprocessor code. Might save some external gates.
>
> Rob
> http://www.birdcomputer.ca/




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search