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 35450

Article: 35450
Subject: QuartusII compiler error message
From: "Andrea Sabatini" <sabatini@nergal.it>
Date: Fri, 5 Oct 2001 14:00:45 +0200
Links: << >>  << T >>  << A >>
Hi all.

I'm trying to compile the project that I used to synthesize with MaxPLusII
with the new QuartusII v1.1 but the following message appears:

Can't route source node <name> of type <type> to destination node <name> of
type <type>

I looked for explaination in Quartus help and the only thing that I found
was:

CAUSE:REDIRECT EFDV_MUX_CANT_ROUTE
ACTION:REDIRECT EFDV_MUX_CANT_ROUTE

See also:
REDIRECT EFDV_MUX_CANT_ROUTE

that, of course, doesn't mean anything!!!
I looked in Altera web site but, again, I didn't find anything!!!

Does anyone out there know what I have to do to have my project compiled
with that tool?

Thanks in advance.

Andrea


----------------------------------------
Andrea Sabatini
Geosound Business Unit
Nergal s.r.l.
via Bardanzellu 8
00155 Rome ITALY
tel.+39-06-40801173
mob.+39-339-2038931
fax.+39-06-40801283
email: sabatini@nergal.it
web: www.nergal.it
----------------------------------------



Article: 35451
Subject: Re: sensitivity list
From: "Andrea Sabatini" <sabatini@nergal.it>
Date: Fri, 5 Oct 2001 14:21:13 +0200
Links: << >>  << T >>  << A >>
The synthesised circuit is made onbly of wires (it is a combinationl
network), so it's correct that Y is updated after just a little delay since
B is modified. if you want to make Y change the next time A changes, you
have to write a process with a "syncronize" (sorry for the word but it's the
best that comes to my mind now!) process, which means you have to include a
statement like "wait until A'event" or "if A'event". It will be synthesized
in a combitinal circuit and Y will be updated with a "A change" delay
respect to B.

Andrea


----------------------------------------
Andrea Sabatini
Geosound Business Unit
Nergal s.r.l.
via Bardanzellu 8
00155 Rome ITALY
tel.+39-06-40801173
mob.+39-339-2038931
fax.+39-06-40801283
email: sabatini@nergal.it
web: www.nergal.it
----------------------------------------
"yaohan" <engp1590@nus.edu.sg> wrote in message
news:191C91BDFE8ED411B84400805FBE794C188A716A@pfs21.ex.nus.edu.sg...
> Thank you guys.....
>
> "yaohan" <engp1590@nus.edu.sg> wrote in message
> news:191C91BDFE8ED411B84400805FBE794C1884252F@pfs21.ex.nus.edu.sg...
> > hi,
> > I have a problem which I feel difficult to explain.
> >
> > library ieee;
> > use ieee.std_logic_1164.all;
> >
> > entity test is
> >  port(
> >       A: in integer range 0 to 127;
> >       Y: out integer range 0 to 127
> >  );
> > end test;
> >
> > architecture test_bev of test is
> >      signal B: integer range 0 to 127;
> > begin
> >      process (A)          --process A
> >     begin
> >        B <= A;
> >        Y <= B;
> >  end if;
> >  end process;
> > end test_bev;
> >
> > As for my understanding, the process A will only execute when change on
> > signal A. So Let say, I only change the value A for once, this value
> should
> > be assigned to B; Mean while Y is assigned with OLD B value. As long as
no
> > change on signal A, this process will be suspended, i.e Y == value of
OLD
> B.
> >
> > However, when I simulate using MAX+PLUS II, the results show that Y is
> > update to A input values after short delay. As if the sensitivity list
> does
> > not have any effect .. ( Or may be the compiler has included all the
> signal
> > into sensivity list ...)..
> >
>
>



Article: 35452
Subject: Re: Xilinx: JTAG parallel connection problem
From: Rienk van der Scheer <R.van.der.Scheer@3t.ignorespam.nl>
Date: Fri, 05 Oct 2001 16:16:29 +0200
Links: << >>  << T >>  << A >>
Maybe you should try to set the printerport mode in BIOS to
'bi-directional' instead of ECP/EPP?

Rienk

Sebastian wrote:
> 
> Hi Group
> 
> My iMPACT program can not establish communication with the cable when trying
> to reach the JTAG chain.
> 
> My setup is straightforward: a standard pc with ecp+epp printerport, windows
> 2000 and the small Virtex2 evaluation board connected to the parallel port.
> I'm using Xilinx ISE4.
> 
> The cable, power, etc. are all properly connected. What can be the cause? Do
> i need to make specific port settings in Windows?
> 
> thanx in advance,
> regards,
> Sebastian

Article: 35453
Subject: Re: Xilinx: JTAG parallel connection problem
From: "Seb" <someone@microsoft.com>
Date: Fri, 05 Oct 2001 14:54:51 GMT
Links: << >>  << T >>  << A >>
i think i found out what the problem is: the Xilinx parallel III driver was
not installed (at least it didn't appear in the fileset file as the
documentation states). However, after installing the driver using the custom
installation in the setup tool, communication still doesn't work (and the
driver is still not mentioned in the fileset file). I'm puzzled (it may be a
bug?)

I finally installed the good old JTAG programmer of the Webpack. This one
works.

regards,
Sebastian


"Sebastian" <novalid@ress> wrote in message
news:3bbc1ee6$0$216$4d4ebb8e@oce.news.eu.uu.net...
> Hi Group
>
> My iMPACT program can not establish communication with the cable when
trying
> to reach the JTAG chain.
>
> My setup is straightforward: a standard pc with ecp+epp printerport,
windows
> 2000 and the small Virtex2 evaluation board connected to the parallel
port.
> I'm using Xilinx ISE4.
>
> The cable, power, etc. are all properly connected. What can be the cause?
Do
> i need to make specific port settings in Windows?
>
> thanx in advance,
> regards,
> Sebastian
>
>



Article: 35454
Subject: ROM based FSMs
From: barnish@hotmail.com (Andrew Barnish)
Date: 5 Oct 2001 10:34:49 -0700
Links: << >>  << T >>  << A >>
Hi,

Does anybody know of a tool that makes implementation of a ROM based
Finite State Machine easy? - preferably from VHDL
Do any synthesis tools support such implementations?

I am considering implementing a large FSM using Xilinx Virtex Block
RAM, which should allow it to run much faster than the LUT equivalent.
The problem is just how to describe such a structure.

See:
http://www.xilinx.com/publications/xcellonline/virtex/leftovers.htm

Cheers,

Andy

Article: 35455
Subject: Re: ROM based FSMs
From: "Sergio Masci" <sergio@NO.SPAM.xcprod.com>
Date: Fri, 5 Oct 2001 19:17:18 +0100
Links: << >>  << T >>  << A >>
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?

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?

Regards
Sergio Masci

http://www.xcprod.com/titan


Andrew Barnish <barnish@hotmail.com> wrote in message
news:c92b233a.0110050934.2c9186a5@posting.google.com...
> Hi,
>
> Does anybody know of a tool that makes implementation of a ROM based
> Finite State Machine easy? - preferably from VHDL
> Do any synthesis tools support such implementations?
>
> I am considering implementing a large FSM using Xilinx Virtex Block
> RAM, which should allow it to run much faster than the LUT equivalent.
> The problem is just how to describe such a structure.
>
> See:
> http://www.xilinx.com/publications/xcellonline/virtex/leftovers.htm
>
> Cheers,
>
> Andy



Article: 35456
Subject: Re: ROM based FSMs
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Oct 2001 19:03:09 GMT
Links: << >>  << T >>  << A >>
One of the tricks we've used to handle more inputs or events, is to use a mux
addressed by state bits to select from a larger set of inputs.  While 4 inputs
many times is not enough for the whole state machine, 4 inputs is often plenty
for a subset of the states.

Sergio Masci wrote:

> 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?
>
> 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?
>
> Regards
> Sergio Masci
>
> http://www.xcprod.com/titan
>
> Andrew Barnish <barnish@hotmail.com> wrote in message
> news:c92b233a.0110050934.2c9186a5@posting.google.com...
> > Hi,
> >
> > Does anybody know of a tool that makes implementation of a ROM based
> > Finite State Machine easy? - preferably from VHDL
> > Do any synthesis tools support such implementations?
> >
> > I am considering implementing a large FSM using Xilinx Virtex Block
> > RAM, which should allow it to run much faster than the LUT equivalent.
> > The problem is just how to describe such a structure.
> >
> > See:
> > http://www.xilinx.com/publications/xcellonline/virtex/leftovers.htm
> >
> > 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: 35457
Subject: Re: ROM based FSMs
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 05 Oct 2001 12:56:43 -0700
Links: << >>  << T >>  << A >>
Andrew Barnish wrote:
>
> Does anybody know of a tool that makes implementation of a ROM based
> Finite State Machine easy? - preferably from VHDL
> Do any synthesis tools support such implementations?


You don't really need any special tools.
Just instansiate or infer a Rom and Input, 
Output and State registers something like:

        .--------------.
    _   |_| |______|S|_|
 --|I|----|R|------|O|----------
   >_|             >_|

Now your problem becomes figuring out the
ROM required data to do what you want.
If you have n inputs, you will have to
define 2**n rom locations for each state.
          
> I am considering implementing a large FSM using Xilinx Virtex Block
> RAM, which should allow it to run much faster than the LUT equivalent.

Once you make the rom big enough to handle 
all the inputs and states, I'm not so sure 
it's going to be any faster than a conventional 
state machine design.

> The problem is just how to describe such a structure.

The problem is writing and debugging
the microcode to run your machine without
wearing out your brain.

If you add an address counter and some muxes
to do jumps, the code gets easier, but you
may lose some speed.

      --Mike Treseler

Article: 35458
Subject: Video processing
From: "Ben" <seabybs@hotmail.com>
Date: Fri, 5 Oct 2001 22:29:50 +0100
Links: << >>  << T >>  << A >>
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?
 I've been to Xilix, Altera etc, but want to get as much information as
possible.

Any information greatly appreciated,
Ben.



Article: 35459
Subject: Re: Video processing
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Oct 2001 22:52:40 GMT
Links: << >>  << T >>  << A >>
I haven't seen anything in the way of books specifically addressing video
processing in FPGAs.  I did one paper on a video processor back in '96 that used
dynamic reconfiguration for a video processor that broke an image down into
polygons of interest, then found the location and motion vectors, and color
classification of the object.  That design was in a tiled array of 4 CLAy31
(similar to Atmel 6005) FPGAs.  I've seen a few other papers over the years, but
not a huge stack.

You might try talking to one of the companies that are specializing in
videoprocessor boards such as Visicom (ask for John Smith) or Coreco.  Both of
them use FPGAs as the compute engine on video processor boards.

Ben wrote:

> 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?
>  I've been to Xilix, Altera etc, but want to get as much information as
> possible.
>
> Any information greatly appreciated,
> Ben.

--
--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: 35460
Subject: Re: Xilinx Spartan-II slave parallel configuration
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Sat, 6 Oct 2001 00:56:18 +0100
Links: << >>  << T >>  << A >>
Since nobody replied to this (on my newsfeed), herewith some comments
which may help...

"Chris Elliott" wrote

> I am trying to configure a Spartan-II XC2S50 using Slave Parallel Mode and
> am unsuccessful.  DONE never goes high and INIT never goes low.  Is there
> any way to debug what state the configuration is in?  For instance do the
> FPGA drive a pin after it detects the sync pattern (or something like that)?

There is a configuration troubleshooter somewhere on the Xilinx site.
Under support.xilinx.com I suppose.

> The manual states the "The D0 pin is considered the MSB bit of each byte."
> I thought I knew how to interpret that, but I'm not sure.  The 5th byte is
> the bit stream is 0xaa.  Do the bits D7-D0 read 10101010 or 01010101?  I
> have tried both with no success, so I must have other problems.

0xaa is 1010_1010 and the MSB=1.  Xilinx have D0 as the MSB, so
we have D0..D7 = 1010_1010, D7..D0 = 0101_0101

>
> Here is what I am doing:
>
> 1.  Drive PROG  low.
> 2.  Wait for DONE to go low.
> 3.  Drive PROG high.
> 4.  Wait for INIT to go high.
> 5.  Drive CS and WRITE low.
> 6.  Write 64 bytes of 0xff (CCLK is driven low then high during each byte).
> 7.  Write 69900 bytes of bit stream (CCLK is driven low then high during
> each byte).
> 8.  Write 64 bytes of 0x00 (CCLK is driven low then high during each byte).

From old 2000/3000/4000 days, I would bang in some 0xffs here, though I
cannot see why this should be useful in Virtex-land.

> 9.  Drive CS and WRITE high.
> 10. Wait for INIT to go low or DONE to go high (neither occurs).
>
> I added the 64 bytes of 0xff at the beginning, because I don't have a
> freerunning CCLK and need to make sure the FPGA configuration state machine
> is ready.  I wasn't sure if I should have CS & WRITE low during these
> writes, but it looks like it is designed to throw out the extra 0xff bytes
> before the sync word.  The same thing goes for the 0x00 bytes at the end.





Article: 35461
Subject: Synplify vs. Leonardo
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sat, 06 Oct 2001 10:55:14 GMT
Links: << >>  << T >>  << A >>
     Has anyone done a trade study recently on Synplify vs. Leonardo?  If
yes and you would like to share the results, please do so here or email me
privately.  A client company has asked me to do a trade study of the several
products on the market, and I would like to get some preliminary information
on these two products.  I am particularly interested in actual synthesis
results of real application test cases.  A simple description of the test
cases along with the results is sufficient.  Also, I am interested in any
outstanding features and/or quirks of the two products.
     Thank you very much.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA



Article: 35462
Subject: Re: ROM based FSMs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 06 Oct 2001 12:47:46 +0100
Links: << >>  << T >>  << A >>


Sergio Masci wrote:

> 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?
>
> 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?
>
> Regards
> Sergio Masci

I don't understand why this BlockRAM based FSM is likely to be a win anyway.

o There's going to have to be some high-ish level syntax from which the the
``ROM'' contents are compiled. As Mike T pointed out: If you don't do
something like this you're back into brain twisting '70/80's era ucode.

o We already have such a syntax in VHDL/Verilog/ABEL case statements.

o The ``event'' above itself conceals a lot of complexity.

o For all but the most simple FSMs a layer of muxes is going to slow down the
apparent speed gain.
   Also BlockRAMs positioning on the die could lead to long routing delays
and/or make the placement of other logic more awkward. The usual trick of
adding a an external register after the BRAM outputs would make the FSM design
more difficult (maybe FSM ``compilers'' can allow for that ?).

o For an FF-rich architecture like Xilinx it makes a lot of sense to use
one-hot encoded ``case'' derived SMs.

I can only really see one win in high density designs using otherwise unused
BlockRAMs .





Article: 35463
Subject: Re: ROM based FSMs
From: Ray Andraka <ray@andraka.com>
Date: Sat, 06 Oct 2001 13:52:38 GMT
Links: << >>  << T >>  << A >>
I mostly agree.  The block RAMs are typically the slowest element in my designs
that use them.  It certainly doesn't make sense to use them for simple state
machines.   There are two places where I have found them useful:  1) where the
block rams aren't needed for something else and speed is not critical.  The input
muxes are generally not a problem for speed.  You pipeline them and switch them
ahead of when you actually use them.  The pipelining can be worked around.  2)
where the state machine sequence is subject to changes, but you don't want to redo
the PAR to incorporate the changes.  In that case, the second port can be used to
change the function of the state machine.  In the 60's and 70's, the flexibility
was one of the major advantages to microcoded state machines.

Rick Filipkiewicz wrote:

> Sergio Masci wrote:
>
> > 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?
> >
> > 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?
> >
> > Regards
> > Sergio Masci
>
> I don't understand why this BlockRAM based FSM is likely to be a win anyway.
>
> o There's going to have to be some high-ish level syntax from which the the
> ``ROM'' contents are compiled. As Mike T pointed out: If you don't do
> something like this you're back into brain twisting '70/80's era ucode.
>
> o We already have such a syntax in VHDL/Verilog/ABEL case statements.
>
> o The ``event'' above itself conceals a lot of complexity.
>
> o For all but the most simple FSMs a layer of muxes is going to slow down the
> apparent speed gain.
>    Also BlockRAMs positioning on the die could lead to long routing delays
> and/or make the placement of other logic more awkward. The usual trick of
> adding a an external register after the BRAM outputs would make the FSM design
> more difficult (maybe FSM ``compilers'' can allow for that ?).
>
> o For an FF-rich architecture like Xilinx it makes a lot of sense to use
> one-hot encoded ``case'' derived SMs.
>
> I can only really see one win in high density designs using otherwise unused
> BlockRAMs .

--
--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: 35464
Subject: Re: ROM based FSMs
From: "Sergio Masci" <sergio@NO.SPAM.xcprod.com>
Date: Sat, 6 Oct 2001 15:52:06 +0100
Links: << >>  << T >>  << A >>

Mike Treseler <mike.treseler@flukenetworks.com> wrote in message
news:3BBE107B.C541A533@flukenetworks.com...
> Andrew Barnish wrote:
> >
> > Does anybody know of a tool that makes implementation of a ROM based
> > Finite State Machine easy? - preferably from VHDL
> > Do any synthesis tools support such implementations?
>
>
> You don't really need any special tools.

So you don't need any special tools

> Just instansiate or infer a Rom and Input,
> Output and State registers something like:
>
>         .--------------.
>     _   |_| |______|S|_|
>  --|I|----|R|------|O|----------
>    >_|             >_|
>
> Now your problem becomes figuring out the
> ROM required data to do what you want.
> If you have n inputs, you will have to
> define 2**n rom locations for each state.

So you do need a special tool to help you "figure out
the ROM required data to do what you want"

>
> > I am considering implementing a large FSM using Xilinx Virtex Block
> > RAM, which should allow it to run much faster than the LUT equivalent.
>
> Once you make the rom big enough to handle
> all the inputs and states, I'm not so sure
> it's going to be any faster than a conventional
> state machine design.
>
> > The problem is just how to describe such a structure.
>
> The problem is writing and debugging
> the microcode to run your machine without
> wearing out your brain.

Again this is what tools are for, to make working things out easier, to
reduce the possibility of introducing errors, to make it easier to maintain.

>
> If you add an address counter and some muxes
> to do jumps, the code gets easier, but you
> may lose some speed.
>

Implementing a complex state machine in a ROM that takes a few
cycles to process an event has still got to be a hell of a lot faster
(execution wise) than implementing a CPU core to do the
processing. If you had a 100MHz clock and could process only
one event every 4 cycles this would allow you to process
25,000,000 events a second. A CPU capable of doing this sort
of processing would probably need to be:
    2 cycles per instruction
    50 instructions per event using complex linked lists of states
        and events (sparse tables)
    25,000,000 events / second
    = 2500MHz RISC  CPU

Regards
Sergio Masci



Article: 35465
Subject: Re: ROM based FSMs
From: "Sergio Masci" <sergio@NO.SPAM.xcprod.com>
Date: Sat, 6 Oct 2001 16:04:12 +0100
Links: << >>  << T >>  << A >>

Rick Filipkiewicz <rick@algor.co.uk> wrote in message
news:3BBEEF62.A7B5208E@algor.co.uk...
>
>
> Sergio Masci wrote:
>
> > 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?
> >
> > 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?
> >
> > Regards
> > Sergio Masci
>
> I don't understand why this BlockRAM based FSM is likely to be a win
anyway.
>
> o There's going to have to be some high-ish level syntax from which the
the
> ``ROM'' contents are compiled. As Mike T pointed out: If you don't do
> something like this you're back into brain twisting '70/80's era ucode.

How does a purpose built FSM design tool that uses state machine diagrams,
entered by the user, sound? Draw your state diagrams, generate the binary,
blow it straight into your PROM. AND as a byproduct you also get
printed documentation which is guarenteed to be upto date.

>
> o We already have such a syntax in VHDL/Verilog/ABEL case statements.
>
> o The ``event'' above itself conceals a lot of complexity.
>
> o For all but the most simple FSMs a layer of muxes is going to slow down
the
> apparent speed gain.
>    Also BlockRAMs positioning on the die could lead to long routing delays
> and/or make the placement of other logic more awkward. The usual trick of
> adding a an external register after the BRAM outputs would make the FSM
design
> more difficult (maybe FSM ``compilers'' can allow for that ?).
>
> o For an FF-rich architecture like Xilinx it makes a lot of sense to use
> one-hot encoded ``case'' derived SMs.
>
> I can only really see one win in high density designs using otherwise
unused
> BlockRAMs .
>
>
>
>



Article: 35466
Subject: Re: ROM based FSMs
From: "Sergio Masci" <sergio@NO.SPAM.xcprod.com>
Date: Sat, 6 Oct 2001 16:16:47 +0100
Links: << >>  << T >>  << A >>

Ray Andraka <ray@andraka.com> wrote in message
news:3BBE040D.2EC1DBD5@andraka.com...
> One of the tricks we've used to handle more inputs or events, is to use a
mux
> addressed by state bits to select from a larger set of inputs.  While 4
inputs
> many times is not enough for the whole state machine, 4 inputs is often
plenty
> for a subset of the states.
>

I'm not sure what you mean here. I thought of converting 4 inputs to 2 bits
but
you lose the 0->1 or 1->0 transition info. Also how would you cope with
queuing
events or deciding which events have priority in a given state?

> Sergio Masci wrote:
>
> > 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?
> >
> > 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?
> >
> > Regards
> > Sergio Masci
> >
> > http://www.xcprod.com/titan
> >
> > Andrew Barnish <barnish@hotmail.com> wrote in message
> > news:c92b233a.0110050934.2c9186a5@posting.google.com...
> > > Hi,
> > >
> > > Does anybody know of a tool that makes implementation of a ROM based
> > > Finite State Machine easy? - preferably from VHDL
> > > Do any synthesis tools support such implementations?
> > >
> > > I am considering implementing a large FSM using Xilinx Virtex Block
> > > RAM, which should allow it to run much faster than the LUT equivalent.
> > > The problem is just how to describe such a structure.
> > >
> > > See:
> > > http://www.xilinx.com/publications/xcellonline/virtex/leftovers.htm
> > >
> > > 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: 35467
Subject: Re: ROM based FSMs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 06 Oct 2001 18:53:24 +0100
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> I mostly agree.  The block RAMs are typically the slowest element in my designs
> that use them.  It certainly doesn't make sense to use them for simple state
> machines.   There are two places where I have found them useful:  1) where the
> block rams aren't needed for something else and speed is not critical.  The input
> muxes are generally not a problem for speed.  You pipeline them and switch them
> ahead of when you actually use them.  The pipelining can be worked around.  2)
> where the state machine sequence is subject to changes, but you don't want to redo
> the PAR to incorporate the changes.  In that case, the second port can be used to
> change the function of the state machine.  In the 60's and 70's, the flexibility
> was one of the major advantages to microcoded state machines.

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

As far as I can see to avoid a re-PAR when changing such a machine there are these
options ?

- Load the ROM from some external storage at boot time. For SMs that aren't needed
immediately on start-up the local CPU could do this.

- .ncd -> .xdl -> Change the INIT params -> .ncd

- JBits.

or am I missing something ?


Article: 35468
Subject: Re: ROM based FSMs
From: "Sergio Masci" <sergio@NO.SPAM.xcprod.com>
Date: Sat, 6 Oct 2001 19:42:47 +0100
Links: << >>  << T >>  << A >>

Rick Filipkiewicz <rick@algor.co.uk> wrote in message
news:3BBF4514.411C73A8@algor.co.uk...
>
>
> Ray Andraka wrote:
>
> > I mostly agree.  The block RAMs are typically the slowest element in my
designs
> > that use them.  It certainly doesn't make sense to use them for simple
state
> > machines.   There are two places where I have found them useful:  1)
where the
> > block rams aren't needed for something else and speed is not critical.
The input
> > muxes are generally not a problem for speed.  You pipeline them and
switch them
> > ahead of when you actually use them.  The pipelining can be worked
around.  2)
> > where the state machine sequence is subject to changes, but you don't
want to redo
> > the PAR to incorporate the changes.  In that case, the second port can
be used to
> > change the function of the state machine.  In the 60's and 70's, the
flexibility
> > was one of the major advantages to microcoded state machines.
>
> IIRC there were even some CPUs with ``writeable'' control store that
allowed the
> instruction sets to be tailored to some degree [Fairchild Clipper ?].

I'm pretty sure this was not possible with the CLIPPER. The Fairchild
CLIPPER
was pushed as a RISC CPU with CISC extensions. It had what they called macro
instructions but I don't ever remember seeing anything that suggested you
could
modify these.

On the other hand TI did do an emulator that let you write into the control
store
of its TMS7000 and for a price they would (at one time anyhow) build MCUs
masked with control stores to your specs.

Didn't some company (again I think it was TI) annouce a CPU (maybe even a
DSP) a few months ago that is user microcodeable?

>
> As far as I can see to avoid a re-PAR when changing such a machine there
are these
> options ?
>
> - Load the ROM from some external storage at boot time. For SMs that
aren't needed
> immediately on start-up the local CPU could do this.
>
> - .ncd -> .xdl -> Change the INIT params -> .ncd
>
> - JBits.
>
> or am I missing something ?
>



Article: 35469
Subject: Re: ROM based FSMs
From: Ray Andraka <ray@andraka.com>
Date: Sat, 06 Oct 2001 19:33:24 GMT
Links: << >>  << T >>  << A >>
Dual port ROM with original program loaded with bitstream via INIT=Attributes.  To
reload it, you need to write the second port, which I think is what you said in bullet
#1.  If you need the change updated on power up, you are left with either changing
init=attributes or modifying it with Jbits.  JBits may be less work, but then it is not
backannotated into your original design...

Rick Filipkiewicz wrote:

> Ray Andraka wrote:
>
> > I mostly agree.  The block RAMs are typically the slowest element in my designs
> > that use them.  It certainly doesn't make sense to use them for simple state
> > machines.   There are two places where I have found them useful:  1) where the
> > block rams aren't needed for something else and speed is not critical.  The input
> > muxes are generally not a problem for speed.  You pipeline them and switch them
> > ahead of when you actually use them.  The pipelining can be worked around.  2)
> > where the state machine sequence is subject to changes, but you don't want to redo
> > the PAR to incorporate the changes.  In that case, the second port can be used to
> > change the function of the state machine.  In the 60's and 70's, the flexibility
> > was one of the major advantages to microcoded state machines.
>
> IIRC there were even some CPUs with ``writeable'' control store that allowed the
> instruction sets to be tailored to some degree [Fairchild Clipper ?].
>
> As far as I can see to avoid a re-PAR when changing such a machine there are these
> options ?
>
> - Load the ROM from some external storage at boot time. For SMs that aren't needed
> immediately on start-up the local CPU could do this.
>
> - .ncd -> .xdl -> Change the INIT params -> .ncd
>
> - JBits.
>
> or am I missing something ?

--
--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: 35470
(removed)


Article: 35471
Subject: Re: Xilinx XST synthesis signal naming
From: newman5382@aol.com (Newman5382)
Date: 06 Oct 2001 22:33:15 GMT
Links: << >>  << T >>  << A >>
My guess would be that at the higher effort level, that the tool flattened the
design to unconstrain its efforts.

Article: 35472
Subject: Re: ROM based FSMs
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 06 Oct 2001 22:52:28 GMT
Links: << >>  << T >>  << A >>
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?

Speed:
The much maligned BlockRAMs have extremely short set-up time ( <  1 ns ) and about 3 ns
clock-to-out. So you can run this design at 200 MHz. That should be fast enough for the
majority of state machines.

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.
Or 64 states with 8-way branch, or 32 states with 16-way branch and 31 free outputs.
In a single BlockRAM, you can also implement two completely independent state machines,
each with the same features as above, but each limited to 11 to 13 free outputs. (The
address MSB is permanently Low in one port, High in the other )

Cost:
I explicitly assumed that you have an extra unused BlockRAM, so the cost is zero.

Have fun !

Peter Alfke, Xilinx Applications






Article: 35473
Subject: Re: ROM based FSMs
From: barnish@hotmail.com (Andrew Barnish)
Date: 6 Oct 2001 16:28:44 -0700
Links: << >>  << T >>  << A >>
"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

Article: 35474
Subject: Re: Xilinx Foundation vs. ISE
From: "KsTiger" <ksnospamtiger@swbell.net>
Date: Sun, 07 Oct 2001 00:24:20 GMT
Links: << >>  << T >>  << A >>
You will receive a version of Foundation 4.1 as well as ISE 4.1.  You should
see it very soon as a matter of fact.  You don't have to convert quite yet,
but you might not want to start a new design using the Foundation Classic
tools.

"Noddy" <g9731642@campus.ru.ac.za> wrote in message
news:1002181956.172189@turtle.ru.ac.za...
> So, essentially, what you are saying is that, given I have quite a big
> design which I DEFINATELY do not want to lose, it would be wise to hold
off
> on upgrading
> to 4.1 until I have finished with my design? Is there someone here from
> Xilinx who could give a definitive answer?
>
> adrian
>
>
>
> > It seems that the schematics are not compatible!!! And as the my local
> > application engineer from AVNET says : there is no conversion program
> > available, and there will never be a conversion program available.
> >
> > The thing is, Xilinx wants everyone to use VHDL and/or Verilog. Here is
> the
> > good point, the XST synthesiser has no 'node locked' and or 'time'
> > restrictions. So I think (and I hope) once installed, you never have to
> look
> > again for new license files, ... as for example for the synopsys stuff.
> >
> > The bad thing is that I've used synopsys until now and while converting
a
> > project from foundation to ISE, I saw that the syntax to include
> > constraints(like the contents of a RAM block) in HDL (verilog in my
case)
> is
> > different with the XST compiler. So you are fucked anyway, either
> schematic
> > or HDL is not fully compatible.
> >
> > On the other hand, you cannot wait to start using the latest software
for
> > new things, otherwise the gap is getting bigger and bigger. Xilinx wants
> to
> > sell mare and more bigger components, so the need bigger and bigger
> > software. I think Xilinx (and also Altera) wants to go faster to new
> > technologies than most of their customers, but everyone is forced to
> follow
> > them. This is the bat thing about only two really big companys on the
top
> of
> > the programmable logic mountain.
> >
> > See you,
> >
> > Stefaan
> >
> >
> > "Richard Dungan" <postmaster@[127.0.0.1]> schreef in bericht
> > news:fdgmrt4apvaejfmq3ksgmhracbu5fhj9t4@4ax.com...
> > > Hi all.
> > >
> > > I'm running Xilinx Foundation Base Express (the one with VHDL added
on).
> > > I've used this for several years and by remembering to pay for
support,
> > > I've avoided getting drawn into the time-based licence thing.
> > >
> > > I received a letter recently from Xilinx, telling me that Foundation
> > > 4.1i is about to ship. All well and good.
> > >
> > > The letter goes to some length to extol the virtues of Xilinx' new ISE
> > > package, and I'm curious as to the pros and cons of moving over to
this.
> > >
> > > Things that particularly concern me are:
> > >
> > > 1) What are the licence implications? I understand that Foundation is
to
> > >    be canned in due course. When it becomes ISE *only* will I suddenly
> > >    be expected to buy a time-based licence?
> > >
> > > 2) What kind of support does ISE give to schematic entry? I foresee an
> > >    ongoing need for this (partly driven from outside) for some time to
> > >    come. This may include updates to Foundation projects.
> > >
> > > Any opinions would be welcome.
> > >
> > > Richard
> > >
> > > ------------Richard Dungan-------------
> > > Radix Electronic Designs, Orpington, UK
> > >    richardATradixDASHdesignDOTcoDOTuk
> > > ---------------------------------------
> >
> >
>
>





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