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
pawel5732@my-deja.com wrote: > > Hi, > What FPGAs do support a partial reconfiguration? > What FPGAs can be reconfigured "on-the-fly"? > Is this possible to use this feature with a tool? > Thank you, > Pawel > > Sent via Deja.com > http://www.deja.com/ The Atmel devices can be partially reconfigured, as can the Xilinx Virtex devices (and their derivatives). Tools are relatively few and far between. I don't know about the Atmel ones, I'll let Ulf deal with that one. Xilinx Virtex devices can be partially configured using the JBits API, with details on the Xilinx website here http://www.xilinx.com/products/jbits/index.htm AFAIK, no 'mainstream' tool supports partial. Phil -- --------------------------------------------------------------------- __ / /\/ Dr Phil James-Roxby Direct Dial: 303-544-5545 \ \ Staff Software Engineer Fax: Unreliable use email :-) / / Loki/DARPA Email: phil.james-roxby@xilinx.com \_\/\ Xilinx Boulder ---------------------------------------------------------------------Article: 28651
Pawel, Virtex II is the first FPGA with internal access to the configuration interface as a 'component' in verilog/vhdl and schematic. The problem with it, is the same as always, how do you floorplan so you don't step on yourself while reconfiguring? The new 3.2i tools provide for floorplanning the designs, and pin locking at the boundries, so we are excited to hear about people trying out their dynamic reconfiguration ideas with Virtex II. Admittedly, this isn't a well trod path, so there will be a lot of expertise required to implement such designs. But all of the 'hooks' are there. Austin pawel5732@my-deja.com wrote: > Hi, > What FPGAs do support a partial reconfiguration? > What FPGAs can be reconfigured "on-the-fly"? > Is this possible to use this feature with a tool? > Thank you, > Pawel > > Sent via Deja.com > http://www.deja.com/Article: 28652
Hi, Is there any on the Web site with a table or chart of "FPGA market shares" - for free? And how does it change during last years? I've looked for, but I didn't find them, except "for registered people". Thanks, Pawel -- Pawel Tomaszewicz Warsaw University of Technology 00-665 Warsaw, Nowowiejska 15/19, Poland Sent via Deja.com http://www.deja.com/Article: 28653
On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka <ray@andraka.com> wrote: >1) You might use the block rams in the XCV50 for the FSM, it will provide a >faster machine, and >alot less sensitivity to changes in the state machine definition. I think there >may be a >xilinx app-note on it. The BRAM is used as a ROM that outputs the next state, >plus any decoded outputs >as a function of the current (encoded) state and some inputs. If there are many >inputs, they can usually >be selected by a mux using the current state to reduce the number of address >pins needed for the memory. This is new way for the old style FSM made with a latch and EPROM as lookup table that fills the whole possible 'state space'. But with the distributed memory in the FPGA aproach there is holes in the 'state space', what hapens when an illegal state are reached? (due to noise, bug, etc.). There is a predictable way of recover?. I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach. ( http://www.terra.es/personal2/melus0/gwlhw0n.html ). Sorry if this is a stupid question, I've only done small FSMs. And I know that when done with independent flip/flops something similar happens. (A 17 state machine with 16 flip/flops). 73's de Luis mail: melus0(@)teleline(.)es Ampr: eb7gwl.ampr.org http://www.terra.es/personal2/melus0/ <- PCBs for Homebrewed HardwareArticle: 28654
Thanks to everyone for all the advice on this, I'm still doing research trying to work out the exact specification and requirements, this info and your websites help a lot. Thanks again Tom In article <3A66E863.BB20E611@xilinx.com>, Ken Chapman <ken.chapman@xilinx.com> wrote: > Dear Tom, > > In simple terms, this is about the required horsepower for the application. > If you can really perform all the processing that you need to in a single > DSP processor chip then it does provide you with a very easy way to > prototype your system. > > However, at 50MHz sample rate you will soon burn up the available number of > MIPS available to you in a DSP processor. If we consider the > TMS320VC5410-10 device, it has a single 17x17 multiplier clocked at 100MHz. > This would only allow you to perform 2 operations at 50MHz. Obviously you > will be performing down-conversion to carry out most of your work at a > lower sample rate, but this down-conversion in itself will almost certainly > require more than this 100MIPS. These processors are really excellent when > you have lots of time between samples such as in audio. At At 48KHz the > 100MIPS provides over 2000 operations per sample. Sent via Deja.com http://www.deja.com/Article: 28655
I (Doug Hillmer) wrote:
>
>
> Any pointers on where I could get it would be
> welcomed.
>
Here is the info for anyone who wants to check it
out:
You may also visit my (future) web site:
http://www.truebluesoftware.com
Article: 28656Maybe this is "old hat", but here are my suggestions for a brute-force table-look-up FSM in Virtex: Use the 4K bit RAM, properly initialized during configuration. So it really is a ROM, since you never write into it. Use it as 512 x 8 ROM. Feed 5 of the 8 outputs back to the input and use the remaining 4 inputs as control. You now have a 32-state FSM with 4 condition inputs, and 3 extra arbitrarily decoded outputs, beyond the 5 encoded outputs. You can define everything, like recovery from illegal states, etc. No holes. In Virtex-II the ROM is bigger, 18K bits. So you can have a 128-state FSM with 4 control inputs, with the ROMconfigured 2K x 9. Or 64 states with 5 control inputs. Since these are synchronous dual-ported ROMs, you don't need any extra output or input registers, and you can run at 200 MHz. Also, you automatically get two FSMs in the same memory, both with the identical transition table, but individual control inputs and individual clocking. It's all pretty obvious once you think about it... Peter Alfke, Xilinx Applications ======================================== Luis Yanes wrote: > On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka <ray@andraka.com> wrote: > > >1) You might use the block rams in the XCV50 for the FSM, it will provide a > >faster machine, and > >alot less sensitivity to changes in the state machine definition. I think there > >may be a > >xilinx app-note on it. The BRAM is used as a ROM that outputs the next state, > >plus any decoded outputs > >as a function of the current (encoded) state and some inputs. If there are many > >inputs, they can usually > >be selected by a mux using the current state to reduce the number of address > >pins needed for the memory. > > This is new way for the old style FSM made with a latch and EPROM as lookup > table that fills the whole possible 'state space'. > > But with the distributed memory in the FPGA aproach there is holes in the > 'state space', what hapens when an illegal state are reached? (due to > noise, bug, etc.). There is a predictable way of recover?. > > I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach. > ( http://www.terra.es/personal2/melus0/gwlhw0n.html ). > > Sorry if this is a stupid question, I've only done small FSMs. And I know > that when done with independent flip/flops something similar happens. > (A 17 state machine with 16 flip/flops). > 73's de Luis > > mail: melus0(@)teleline(.)es > Ampr: eb7gwl.ampr.org > http://www.terra.es/personal2/melus0/ <- PCBs for Homebrewed HardwareArticle: 28657
Jamie Lokier wrote: > > Andy Peters writes: > >> Andy Peters writes: > >> > ModelSim and Synplify both use dongles (which I vastly prefer over > >> > that FlexLM bogosity) but the Mac ain't got a parallel port so I'm SOL > >> > there. > >> > >> And even if the MAC did have a parallel port... > >> > >> I vastly prefer FlexLM because there is some hope of it working in an > >> emulator. In my experience dongle reading code does seriously weird > >> things to your parallel port, and doesn't work in an emulator. > > > Yeah, but if FlexLM is keyed to your ethernet MAC (not Macintosh!) > > address and you want to, say, do some work at home, you're hosed. > > OTOH if you run it in an emulator, you get to choose the reported MAC > addess :-) If you are using VMware as your emulator, you can only choose part of the MAC address. The rest is, unfortunately, fixed. -- My real email is akamail.com@dclark (or something like that).Article: 28658
Peter Alfke wrote: > Chris, you may want to look at an article about crossing asynchronous > clock boundaries that I published about a year ago. Mayeb it helps > you. > > http://www.isdmag.com/editorial/2000/design0003.html > > Peter Alfke, Xilinx Applications > ================================ Peter, I have just reread your nice article. The asynchonous FIFO is a perfect solution when it comes to streams of data that the FPGA processes. In my application FPGA registers are maped into the DSP memory. These registers can set hardware switches, and in some cases the DSP data will be transfered to a synchronous FIFO through a pipeline, or the other way round: data from an other FIFO can be read by the DSP as well. Using synchronous FIFOs forced me to operate these FIFOs at the speed of the DSP interface (120MHz), but the real data rates are much lower. The fastest part in my design are the DSP interfaces, all other stuff is much much slower. The DSP is able to write to a register and read from it in the next access. The effictive data rate of the DSP is about 25 MHz, but DSP write strobes are very short (12 ns), and the DSP expects to valid data 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. This is the reason for choosing an asynchronous read access. But unfortunately, async. logic can produce glitches, this may be a problem. I don't know how to use async. FIFOs in this case. I cannot implement a FIFO for each register bank, and the read after a write access makes the use of FIFOs difficult. I have to implement a lot of these kind of interfaces and I am looking for a clean solution. May a cache build of BlockRAM be a possiblity? My Virtex-E has some free RAM cells left. The DSP can have fast access to the cache, and all write accesses to the registers can be pipelined then. But what external clock can be used for this cache? There is just the read and write signal of the DSP. Originally I thought of this as a school book example, because mapping FPGA registers into DSP memory seems to be pretty standard. I'm not sure any more. Best regards, Chris > > "Chris G. Schneider" wrote: > >> I want to design an interface between a DSP and a FPGA. The DSP >> should >> be able to access FPGA registers, via the DSP parallel port. The >> DSP parallel port has address, data, chip select, read and write >> lines. >> Just the usual stuff. >> >> I just designed this interface, but I am not happy with the results >> in >> terms of speed and design stability. So I want to ask this audience >> for >> some design hints. >> >> 1) Write access: I just synchronize the DSP write signal and >> generate an >> internal write strobe to fetch the data. Is it a better solution to >> use >> the write signal to store the data in a register and then >> synchronize >> the register contents to the internal clock? This makes it possible >> to >> detect very short write strobes of the DSP and to reduce the number >> of >> WS, in the application. >> >> 2) Read access: I use a async. read access at the moment. Is it >> possible >> to make this work synchronously? The problem is that synchronizing >> just >> eats up a lot of time, and timing constraints of modern DSP are >> pretty >> tight. There will be a problem if the FPGA does not release the DSP >> data >> bus fast enough, because read and write accesses can appear very >> soon >> after each other. >> >> Any suggestions, or literature tips? >> >> -- >> chris >Article: 28659
Austin Lesea wrote:
> By the way, good catch. Thought you had us, didn't you? We are not perfect
> (!!!! especially me), so if we do miss something, tell us right away,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Flat packs. Xilinx missed the importance of the small guy.
Bitstream specs. Xilinx missed the significance of open source
phenomena.
That said, XC2V looks truly impressive - wonder if distributors
are going to have parts in stock within a year...
- Reinoud
Article: 28660Chris, the article I mentioned also describes, in the beginning, how to transfer a single register across the clock boundary... Just in general terms, 120 MHz and 12 ns are no longer scary values. Not for the recent Virtex-E and Spartan-II devices, and definitely not for the newest Virtex-II, where synchronous 24-bit counters can run at 300 MHz ( without allowing for external delays). Asynchronous FIFOs in either BlockRAMs or CLBs can run at 200 MHz, but to generate reliable FULL and EMPTY handshake signals you must use Grey counters, as described in our App note XAPP051 ( and if you want to use that, send me an e-mail for newer improvements ). It is impossible for me to evaluate all aspects of your design, but I want to give you confidence that the newer chips are much faster than they were in the past. And the most recent designs have amazed me. Half a nanosecond is the new standard value for clock-to-Q, or set-up time, or routing to the nearest CLB. And ripple-carry delay per bit are ten times less. Greetings Peter Alfke, Xilinx Applications ================================= "Chris G. Schneider" wrote: > Peter Alfke wrote: > > > Chris, you may want to look at an article about crossing asynchronous > > clock boundaries that I published about a year ago. Mayeb it helps > > you. > > > > http://www.isdmag.com/editorial/2000/design0003.html > > > > Peter Alfke, Xilinx Applications > > ================================ > > Peter, > > I have just reread your nice article. The asynchonous FIFO is a perfect > solution when it comes to streams of data that the FPGA processes. > > In my application FPGA registers are maped into the DSP memory. These > registers can set hardware switches, and in some cases the DSP data will > be > transfered to a synchronous FIFO through a pipeline, or the other way > round: data from an other FIFO can be read by the DSP as well. > > Using synchronous FIFOs forced me to operate these FIFOs at the speed of > > the DSP interface (120MHz), but the real data rates are much lower. > > The fastest part in my design are the DSP interfaces, all other stuff is > > much much slower. > > The DSP is able to write to a register and read from it in the next > access. The effictive data rate of the DSP is about 25 MHz, but DSP > write strobes are very short (12 ns), and the DSP expects to valid data > 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. > > This is the reason for choosing an asynchronous read access. But > unfortunately, async. logic can produce glitches, this may be a problem. > > I don't know how to use async. FIFOs in this case. I cannot implement a > FIFO for each register bank, and the read after a write access makes the > > use of FIFOs difficult. > > I have to implement a lot of these kind of interfaces and I am looking > for a clean solution. May a cache build of BlockRAM be a possiblity? > My Virtex-E has some free RAM cells left. The DSP can have fast access > to the cache, and all write accesses to the registers can be pipelined > then. But what external clock can be used for this cache? There is just > the read and write signal of the DSP. > > Originally I thought of this as a school book example, because mapping > FPGA registers into DSP memory seems to be pretty standard. I'm not sure > > any more. > > Best regards, > > Chris > > > > > "Chris G. Schneider" wrote: > > > >> I want to design an interface between a DSP and a FPGA. The DSP > >> should > >> be able to access FPGA registers, via the DSP parallel port. The > >> DSP parallel port has address, data, chip select, read and write > >> lines. > >> Just the usual stuff. > >> > >> I just designed this interface, but I am not happy with the results > >> in > >> terms of speed and design stability. So I want to ask this audience > >> for > >> some design hints. > >> > >> 1) Write access: I just synchronize the DSP write signal and > >> generate an > >> internal write strobe to fetch the data. Is it a better solution to > >> use > >> the write signal to store the data in a register and then > >> synchronize > >> the register contents to the internal clock? This makes it possible > >> to > >> detect very short write strobes of the DSP and to reduce the number > >> of > >> WS, in the application. > >> > >> 2) Read access: I use a async. read access at the moment. Is it > >> possible > >> to make this work synchronously? The problem is that synchronizing > >> just > >> eats up a lot of time, and timing constraints of modern DSP are > >> pretty > >> tight. There will be a problem if the FPGA does not release the DSP > >> data > >> bus fast enough, because read and write accesses can appear very > >> soon > >> after each other. > >> > >> Any suggestions, or literature tips? > >> > >> -- > >> chris > >Article: 28661
Duane <junkmail@junkmail.com> writes: > If you are using VMware as your emulator, you can only choose part of > the MAC address. The rest is, unfortunately, fixed. Which is one reason why I intend to switch from VMware to Plex86 soon. I don't begrudge the money I spent on VMware, as it's a pretty good product, but I don't like their attitude that I shouldn't be allowed to change some aspects of the configuration because they know what's best for me. Plex86 is no where near as fancy (yet), but it looks like it will do what I want, and I can hack the source if necessary.Article: 28662
Nial Stewart wrote: > John Grider wrote: > > > > "Juan M. Rivas" wrote: > > > > > > I'm looking for a Progrmming Cables from Xilinx, for a stand alone FPGA > > > proyect: Does anyone know wher I can by one, and which one is good? > > > > > > I've been looking for the Multilinx, and the Xcheqer, but I can't > > > decide...Besides I can't find where to find them (Always out of stock) > > > > > > Suggestions??? > > > > > > Thanks all > > > > You could always build your own parallel/jtag cable - the schematics are > > availible from xilinx's web site. It looks simple, just two 74xxx's and > > a couple diodes, caps, etc. > > -- John > > Xilinx couldn't supply any more parrallel cable so the technician here > built a few more. > > They work well and are _much_ faster than the multilinx cable (programming > an xcv_1802 takes about 20 seconds as opposed to several minutes with the > multilinx). > > Nial. If you want a really simple way of doing it look at the apps note XAPP058. This was orginally intended for an embedded micro-controller but the s/w is easy to modify to drive a Win95/98 PC's parallel port. All you need then is a cable with a Centronics D25 at one end & 4 flying wires at the other although it is useful to buffer the JTAG on your board through an LS125. The associated s/w is called eisp_4.06 & is somewhere in the downloads directory. We've been using it off & on to allow users to update CPLDs on our board. Its still much slower than the parallel-III cable or at least the V2.0 was, maybe V4.06 has speeded up - we'll see next week. Its even possible to do an NT version.Article: 28663
The server was indeed down, but has been up as of 1/15. If you are still having problems, please feel free to contact us via email at support@synplicity.com and we will help. Andrew Muzaffer Kal wrote: > Rick Filipkiewicz <rick@algor.co.uk> wrote: > > > > > > >Utku Ozcan wrote: > > > >> What happened to Synplicity's newsgroup? > >> The newsgroup browser tells that the server is down... > >> > >> Utku > > > >I've never been able to get to it either - I contacted Synplicity about > >this a long time ago but never got any result. > > > It's gone down just two days ago. There wasn't much traffic on it but > I have been able to access to it till then. For a short while web site > was down too but it came up, news didn't. > > Muzaffer > > FPGA DSP Consulting > http://www.dspia.com -- Andrew Dauman Vice President of Corporate Applications Synplicity, Inc. 935 Stewart Drive Sunnyvale, CA 94086 Phone: 408-215-6000 E-mail: Andrew Dauman mailto:andrew@synplicity.com Technical Support: mailto:support@synplicity.comArticle: 28664
The Atmel 40K would probably be a good match for this. I wouldn't use them in most DSP apps because they lack a fast carry chain, making it hard to get anywhere near the performance/density of the Xilinx and Altera parts with fast carry. I've always had an issue with the "pin compatibility" claim of these parts, ever since before they actually came out. Pin compatibility in this case means that they can go into a xilinx 4K socket without making smoke, and if you are willing to do a complete redesign of the FPGA, you can often create an equivalent design. The internal architectures are quite different. If Atmel had the foresight (and perhaps the intellectual property rights) to put a carry chain in these parts, they would have been a decent competitor to the 4K parts that were available on its introduction. Xilinx came out with the Spartan line shortly after Atmel introduced the 40K, shattering Atmel's price point advantage. Oh well... Ulf Samuelsson wrote: > > : I am looking at building a small number 10-20 pcbs that will use one of > : Xilinx's FPGAs. The logic required is small but may be expanded later. > : Essentially it is a FPDP i/f feeding some fifos that are feeding a D/A. > : > : I am looking initially at a Spartan II for a fifo or DPRAM to hold some > : data for the D/A. > : I like the idea of using the block ram for the small DPRAM or fifo. Speed is > : slow by most people's standards on this group. D/A will be run at 120KSa/s > : or so but I am doing > : 8 channels + on each FPGA. > : > You may want to try the Atmel AT40K FPGA family. > They have "distribued" 10 ns SRAM suitable for FIFOs. > There is a 32 x 4 DPRAM for every 16 macrocell, > and they are hardwired, do not use configuration RAM. > The AT94Kxx FPSLIC has 12kB of SRAM useable for the FPGA > on top of the distributed SRAM. > They are pin compatible with the XC4000 series > Tools are for free at Atmels homepage. > The FPSLIC demoboard will set you back $500 for a 4 months > license but then you get really good tools. > Mentor Modelsim, Leonardo,Seamless. > > -- > Best Regards > Ulf at atmel dot com > These comment are intended to be my own personal view > and may or may not be shared by my Employer Atmel Sweden. -- -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 or http://www.fpga-guru.comArticle: 28665
Austin, a hook that I haven't seen yet is the ability to lock down the locations of the ROUTING going in and out of a partial configuration overlay, as well as the "fences" required to keep routing in or out of an area that is to be partially reconfigured. The only way around that I can see in the current tools is painstaking hand routing in the FPGA editor. Care to comment? Austin Lesea wrote: > > Pawel, > > Virtex II is the first FPGA with internal access to the configuration > interface as a 'component' in verilog/vhdl and schematic. > > The problem with it, is the same as always, how do you floorplan so you > don't step on yourself while reconfiguring? > > The new 3.2i tools provide for floorplanning the designs, and pin > locking at the boundries, so we are excited to hear about people trying > out their dynamic reconfiguration ideas with Virtex II. > > Admittedly, this isn't a well trod path, so there will be a lot of > expertise required to implement such designs. But all of the 'hooks' > are there. > > Austin > > pawel5732@my-deja.com wrote: > > ? Hi, > ? What FPGAs do support a partial reconfiguration? > ? What FPGAs can be reconfigured "on-the-fly"? > ? Is this possible to use this feature with a tool? > ? Thank you, > ? Pawel > ? > ? Sent via Deja.com > ? http://www.deja.com/ -- -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 or http://www.fpga-guru.comArticle: 28666
If you use the block RAM, it is the same as the old ROM based FSMs. The whole state space is covered, and in the VIrtex devices you have at least 8 address bits to deal with. If one is a muxed input, that leaves you with 128 states plus a control input. Change the BRAM to a handful of 4Kx1's and you get 2048 states plus one control. This ought to cover a large majority of the cases. Note, this is not your father's distribute ram, these are the blcok rams found in virtex and Altera 10 and 20K parts we're talking about in this case. (of course you could use the distributed RAM for smaller FSMs). Luis Yanes wrote: > > On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka ?ray@andraka.com? wrote: > > ?1) You might use the block rams in the XCV50 for the FSM, it will provide a > ?faster machine, and > ?alot less sensitivity to changes in the state machine definition. I think there > ?may be a > ?xilinx app-note on it. The BRAM is used as a ROM that outputs the next state, > ?plus any decoded outputs > ?as a function of the current (encoded) state and some inputs. If there are many > ?inputs, they can usually > ?be selected by a mux using the current state to reduce the number of address > ?pins needed for the memory. > > This is new way for the old style FSM made with a latch and EPROM as lookup > table that fills the whole possible 'state space'. > > But with the distributed memory in the FPGA aproach there is holes in the > 'state space', what hapens when an illegal state are reached? (due to > noise, bug, etc.). There is a predictable way of recover?. > > I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach. > ( http://www.terra.es/personal2/melus0/gwlhw0n.html ). > > Sorry if this is a stupid question, I've only done small FSMs. And I know > that when done with independent flip/flops something similar happens. > (A 17 state machine with 16 flip/flops). > 73's de Luis > > mail: melus0(@)teleline(.)es > Ampr: eb7gwl.ampr.org > http://www.terra.es/personal2/melus0/ ?- PCBs for Homebrewed Hardware -- -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 or http://www.fpga-guru.comArticle: 28667
Peter Alfke wrote: > > Maybe this is "old hat", but here are my suggestions for a brute-force table-look-up > FSM in Virtex: > > Use the 4K bit RAM, properly initialized during configuration. So it really is a > ROM, since you never write into it. > Use it as 512 x 8 ROM. Feed 5 of the 8 outputs back to the input and use the > remaining 4 inputs as control. > You now have a 32-state FSM with 4 condition inputs, and 3 extra arbitrarily decoded > outputs, beyond the 5 encoded outputs. You can define everything, like recovery from > illegal states, etc. No holes. Peter, If you need more states, you can use a mux to select the appropriate condition input for a given state. In most cases, you can reduce your condition inputs to the ROM to only one or maybe two condition inputs. Additional outputs can be had by installing parallel ROMs for as many decoded outputs as you require. > > In Virtex-II the ROM is bigger, 18K bits. > So you can have a 128-state FSM with 4 control inputs, with the ROMconfigured 2K x > 9. > Or 64 states with 5 control inputs. > > Since these are synchronous dual-ported ROMs, you don't need any extra output or > input registers, and you can run at 200 MHz. Also, you automatically get two FSMs in > the same memory, both with the identical transition table, but individual control > inputs and individual clocking. > > It's all pretty obvious once you think about it... > Peter Alfke, Xilinx Applications > ======================================== > Luis Yanes wrote: > > ? On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka ?ray@andraka.com? wrote: > ? > ? ?1) You might use the block rams in the XCV50 for the FSM, it will provide a > ? ?faster machine, and > ? ?alot less sensitivity to changes in the state machine definition. I think there > ? ?may be a > ? ?xilinx app-note on it. The BRAM is used as a ROM that outputs the next state, > ? ?plus any decoded outputs > ? ?as a function of the current (encoded) state and some inputs. If there are many > ? ?inputs, they can usually > ? ?be selected by a mux using the current state to reduce the number of address > ? ?pins needed for the memory. > ? > ? This is new way for the old style FSM made with a latch and EPROM as lookup > ? table that fills the whole possible 'state space'. > ? > ? But with the distributed memory in the FPGA aproach there is holes in the > ? 'state space', what hapens when an illegal state are reached? (due to > ? noise, bug, etc.). There is a predictable way of recover?. > ? > ? I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach. > ? ( http://www.terra.es/personal2/melus0/gwlhw0n.html ). > ? > ? Sorry if this is a stupid question, I've only done small FSMs. And I know > ? that when done with independent flip/flops something similar happens. > ? (A 17 state machine with 16 flip/flops). > ? 73's de Luis > ? > ? mail: melus0(@)teleline(.)es > ? Ampr: eb7gwl.ampr.org > ? http://www.terra.es/personal2/melus0/ ?- PCBs for Homebrewed Hardware -- -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 or http://www.fpga-guru.comArticle: 28668
It can be done without block rams. Depending on what the registers hold, you may not need synchronizing logic (a mode bit for instance often can be set without timing consequence if the processor it controls is idle). Let's assume you need to write synchronously into a sytem with an async DSP write. The DSP write occurs on a write strobe that is async to any clocks you have. What you do is let the DSP write pulse clock an input register(s) that essentially gets written with the DSP data. You might also want to write a few bits of the address so you can figure out where the data is supposed to go. So far, we're not doing anything to get into the timing of our FPGA logic, this is all self timed from the DSP (you may want to connect the write pulse to a clock buffer). For readback, internally select the register using just the address, as it comes earlier, then turn on the output buffers with the qualified read. Now, if you need the data syncrhonized to your FPGA clock, you toggle an additional flip-flop with the write pulse, so that each time a write occurs, the toggle flop changes to the opposite state. You synchronize that toggle flop output to the FPGA clock domain through a flip-flop or two, and then drive a state machine that generates a 1 clock wide write pulse each time it sees that synchronized toggle change state. That write pulse can then be used to synchronously and safely copy the data captured in the write register to another register in your FPGA clock domain. The only requirement is you have to guarantee the capture register is not changed before the transfer occurs, which can usually be done by making sure the local clock goes through at least 3 or 4 cycles in the fastest possible DSP write time (if not, you can assemble several DSP writes into a long word and transfer only after the nth write). Reading back can be a little trickier, but the same sort of set up can be used. Here, it helps if the read address is known ahead of time. "Chris G. Schneider" wrote: > > Peter Alfke wrote: > > ? Chris, you may want to look at an article about crossing asynchronous > ? clock boundaries that I published about a year ago. Mayeb it helps > ? you. > ? > ? http://www.isdmag.com/editorial/2000/design0003.html > ? > ? Peter Alfke, Xilinx Applications > ? ================================ > > Peter, > > I have just reread your nice article. The asynchonous FIFO is a perfect > solution when it comes to streams of data that the FPGA processes. > > In my application FPGA registers are maped into the DSP memory. These > registers can set hardware switches, and in some cases the DSP data will > be > transfered to a synchronous FIFO through a pipeline, or the other way > round: data from an other FIFO can be read by the DSP as well. > > Using synchronous FIFOs forced me to operate these FIFOs at the speed of > > the DSP interface (120MHz), but the real data rates are much lower. > > The fastest part in my design are the DSP interfaces, all other stuff is > > much much slower. > > The DSP is able to write to a register and read from it in the next > access. The effictive data rate of the DSP is about 25 MHz, but DSP > write strobes are very short (12 ns), and the DSP expects to valid data > 23 ns after read assertion which is less than 3 clock cycles at 120 MHz. > > This is the reason for choosing an asynchronous read access. But > unfortunately, async. logic can produce glitches, this may be a problem. > > I don't know how to use async. FIFOs in this case. I cannot implement a > FIFO for each register bank, and the read after a write access makes the > > use of FIFOs difficult. > > I have to implement a lot of these kind of interfaces and I am looking > for a clean solution. May a cache build of BlockRAM be a possiblity? > My Virtex-E has some free RAM cells left. The DSP can have fast access > to the cache, and all write accesses to the registers can be pipelined > then. But what external clock can be used for this cache? There is just > the read and write signal of the DSP. > > Originally I thought of this as a school book example, because mapping > FPGA registers into DSP memory seems to be pretty standard. I'm not sure > > any more. > > Best regards, > > Chris > > ? > ? "Chris G. Schneider" wrote: > ? > ?? I want to design an interface between a DSP and a FPGA. The DSP > ?? should > ?? be able to access FPGA registers, via the DSP parallel port. The > ?? DSP parallel port has address, data, chip select, read and write > ?? lines. > ?? Just the usual stuff. > ?? > ?? I just designed this interface, but I am not happy with the results > ?? in > ?? terms of speed and design stability. So I want to ask this audience > ?? for > ?? some design hints. > ?? > ?? 1) Write access: I just synchronize the DSP write signal and > ?? generate an > ?? internal write strobe to fetch the data. Is it a better solution to > ?? use > ?? the write signal to store the data in a register and then > ?? synchronize > ?? the register contents to the internal clock? This makes it possible > ?? to > ?? detect very short write strobes of the DSP and to reduce the number > ?? of > ?? WS, in the application. > ?? > ?? 2) Read access: I use a async. read access at the moment. Is it > ?? possible > ?? to make this work synchronously? The problem is that synchronizing > ?? just > ?? eats up a lot of time, and timing constraints of modern DSP are > ?? pretty > ?? tight. There will be a problem if the FPGA does not release the DSP > ?? data > ?? bus fast enough, because read and write accesses can appear very > ?? soon > ?? after each other. > ?? > ?? Any suggestions, or literature tips? > ?? > ?? -- > ?? chris > ? -- -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 or http://www.fpga-guru.comArticle: 28669
I still seems to be down. Netscape is unable to locate the server new.synplicity.com. Worked before last week. Hasn't worked at all this week. Did the server name change? Andrew Dauman wrote: > > The server was indeed down, but has been up as of 1/15. > If you are still having problems, please feel free to contact us > via email at support@synplicity.com and we will help. > > Andrew > > Muzaffer Kal wrote: > > ? Rick Filipkiewicz ?rick@algor.co.uk? wrote: > ? > ? ? > ? ? > ? ?Utku Ozcan wrote: > ? ? > ? ?? What happened to Synplicity's newsgroup? > ? ?? The newsgroup browser tells that the server is down... > ? ?? > ? ?? Utku > ? ? > ? ?I've never been able to get to it either - I contacted Synplicity about > ? ?this a long time ago but never got any result. > ? ? > ? It's gone down just two days ago. There wasn't much traffic on it but > ? I have been able to access to it till then. For a short while web site > ? was down too but it came up, news didn't. > ? > ? Muzaffer > ? > ? FPGA DSP Consulting > ? http://www.dspia.com > > -- > > Andrew Dauman > Vice President of Corporate Applications > Synplicity, Inc. > 935 Stewart Drive > Sunnyvale, CA 94086 > Phone: 408-215-6000 > > E-mail: Andrew Dauman mailto:andrew@synplicity.com > Technical Support: mailto:support@synplicity.com -- -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 or http://www.fpga-guru.comArticle: 28670
Hi Ray, It should be "news.synplicity.com", can netscape see that? The server name did not change, it may be a "cache" problem (i.e. name mapping records are not all updated yet). If so, try 209.157.48.251, Thanks Andrew Ray Andraka wrote: > I still seems to be down. Netscape is unable to locate the server > new.synplicity.com. Worked before last week. Hasn't worked at all this week. > Did the server name change? > > Andrew Dauman wrote: > > > > The server was indeed down, but has been up as of 1/15. > > If you are still having problems, please feel free to contact us > > via email at support@synplicity.com and we will help. > > > > Andrew > > > > Muzaffer Kal wrote: > > > > ? Rick Filipkiewicz ?rick@algor.co.uk? wrote: > > ? > > ? ? > > ? ? > > ? ?Utku Ozcan wrote: > > ? ? > > ? ?? What happened to Synplicity's newsgroup? > > ? ?? The newsgroup browser tells that the server is down... > > ? ?? > > ? ?? Utku > > ? ? > > ? ?I've never been able to get to it either - I contacted Synplicity about > > ? ?this a long time ago but never got any result. > > ? ? > > ? It's gone down just two days ago. There wasn't much traffic on it but > > ? I have been able to access to it till then. For a short while web site > > ? was down too but it came up, news didn't. > > ? > > ? Muzaffer > > ? > > ? FPGA DSP Consulting > > ? http://www.dspia.com > > > > -- > > > > Andrew Dauman > > Vice President of Corporate Applications > > Synplicity, Inc. > > 935 Stewart Drive > > Sunnyvale, CA 94086 > > Phone: 408-215-6000 > > > > E-mail: Andrew Dauman mailto:andrew@synplicity.com > > Technical Support: mailto:support@synplicity.com > > -- > -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 or http://www.fpga-guru.com -- Andrew Dauman Vice President of Corporate Applications Synplicity, Inc. 935 Stewart Drive Sunnyvale, CA 94086 Phone: 408-215-6000 E-mail: Andrew Dauman mailto:andrew@synplicity.com Technical Support: mailto:support@synplicity.comArticle: 28671
Hopefully we can get a good thread started on this useful subject. Please contribute. We all would like to be more productive FPGA designers. Obviously this varies with experience, technique and your tools etc. Designers develope different approaches and habits. Is there an optimal approach? What are the pitfalls to avoid ? Where does the time go? (or get wasted ?) This is helpful to know, so these areas can be focused on. What important lessons have you learned ? What are the best tools? Sincerely Daniel DeConinck High Res Technologies, Inc.Article: 28672
Spend lots of time cruising newsgroups. That helps productivity immensely.Article: 28673
In article <949ph3$kbq$1@nnrp1.deja.com>, pawel5732@my-deja.com wrote: > Hi, > What FPGAs do support a partial reconfiguration? > What FPGAs can be reconfigured "on-the-fly"? > Is this possible to use this feature with a tool? > Thank you, > Pawel > > Sent via Deja.com > http://www.deja.com/ > Thanks for information about Virtex. I've found some other AppNotes about other chips: Orca2, Orca3 from Lucent, DY6000, DY8000 from DynaChip. Does anybody have experience with partial reconfiguration with these chips? What about tools to use this feature? Do Altera's chips offer that feature? Thanks, Pawel -- Pawel Tomaszewicz Warsaw University of Technology 00-665 Warsaw, Nowowiejska 15/19, Poland Sent via Deja.com http://www.deja.com/Article: 28674
eml@riverside-machines.com.NOSPAM writes:
> On 17 Jan 2001 15:35:10 +0100, Petter Gustad <dev.null@dev.null.org>
> wrote:
>
> >What kind of functionality does MKS provide that CVS do not?
>
> 3 things I can think of off-hand:
Thank you for the extensive reply.
> file manager, come to think of it). You get an immediate view of the
> whole project, you can see which files are modified, you can sort on
I do this from bash with an alias i have in my .bashrc file:
alias cvss='cvs status 2>/dev/null | grep Status: | grep -v Up-to-date'
I then type cvss on the top level of the source tree and get a list of
modified files or files which require a merge. In emacs I just type
C-x v d (sorry, I don't remember the command) and it will traverse the
source tree and give you the same information in an emacs buffer.
> tags, you can sort on modified files (irrespective of directory) so
> that you can check in all modded files at once, you can checkout only
> the required files without having to painfully remember and type each
> one, or creating a new module name for each set you're likely to want,
You can check in all modified files files in CVS by going to the top
of the source tree and type "cvs commit". I always keep the top of the
source tree in my bash directory stack, so going to the top of the
source tree is a matter of typing pushd.
> you can see who's got what file checked out, and a dozen other things.
This you can't do in CVS. I guess this is because you don't have locks
(i.e. reserved checkouts). See below.
> 2)
> The other obvious one - CVS doesn't have reserved checkouts. In fact,
This is sort of like a religion... I had used SCCS for quite a few
years and then RCS of some projects and I have to admit that I
disliked CVS for a while, mainly because the "anarchy" of no locks.
Now I'm used to it and I like it.
You don't into situations like: where is John, I need him to check in
the cpu.v file so I can fix a bug for the synthesis tonight, what,
he's sick, what's his password, where's the sysadmin with the root
password.. And what if John was working from the other side of the
globe and went on a four week snowboard vacation to Alaska. (I guess
some revision control systems has a local admin which might be
different from the root account to do these kinds of things)
As sombody has pointed out, you can enable locks with the cvs admin
command (actually you can do most RCS commands in CVS since its
repository handling is based upon RCS).
> I had an argument with someone recently who had used CVS on a large
> ASIC project, and their reply was that "this doesn't happen in
> practice". IMO, it will happen eventually, and the whole point of a
> management tool is to enforce systems to prevent this sort of thing
> happening.
Yes, this happens, and I never had any problems with it. Usually
people don't work on the same code segment within a file, so it
doesn't happen that frequently. If it does the last person to check it
in is responsible to make sure it's correct. Of course the CVS user
has to be aware of this, otherwise they will complain that their
Verilog simulator is broken, complaining about syntax errors on
>>>>>>>>>>> which I never typed in my code...
I never had this happen with binary files and machine generated files
since we don't have two people synthesising the design and checking in
the netlist. This is usually done by one person. But I see your point,
it would be smart to lock those files.
> you may want to make sure that only some people can create or delete
> archives. IMO, this is important when you have development groups with
> a large range of abilities in them (and in which only a few people, if
> any, have previously used a VCS).
You can do this with CVS too. It's done with lots of open source
projects where people from all over the world is working on a project.
The general user is not allowed to check in files, but can do updates
to get the latest source rather than to download the entire tarball. A
few key developers have write access and can check in and tag files...
A final note. I'm not saying that CVS is better than MKS. I can't
since I have never used MKS. I'm just making some comments based upon
my experience with CVS for several projects.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
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