Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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, > SebastianArticle: 35453
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
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, AndyArticle: 35455
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
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
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: 35458Hi, 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
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: 35460Since 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
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: 35462Sergio 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
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
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: 35465Rick 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
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
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
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
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: 35470My guess would be that at the higher effort level, that the tool flattened the design to unconstrain its efforts.Article: 35472
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 ApplicationsArticle: 35473
"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, AndyArticle: 35474
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:
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