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
On 2 Mrz., 11:50, knight <krshe...@gmail.com> wrote: > Hi > > Can any1 tell me how to use an ODDR output to internal logic in XIlinx > FPGAs...???? > Is there any other way to serialize Double data rate signals in Xilinx > FPGAs...??? Sure, feed the ODDR output into an IDDR input. take a lok at some DDR-controller reference Design to see how synchronizing and data handling is done and that's it. Have a nice synthesis EilertArticle: 138651
Hi. I am having a problem using xilinx sysgen cordic divider. Situation is this. I made a simple test. I instantiated cordic dvidier block and I added inputs and output gateways. I need data that is word length 16. My output data should be represented also with 16 bit data and I wanted matlab to interpet it in range 0 to 1 so I used "reinpret" block also. situation is like this When I instante cordic for the first time and use default setup (11 stages and latency [ 1 1 1 1 1 1 1 1 1 1] ) I get rigth results at the output. But when I change latency vector for example [0 0 0 0 1 0 0 0 0 1 0 1]. I get wrong results. Also when I set binary point on the input vectors (in cordic block to 0). I also get wrong results. I can't understand anuthing and help is not very much helpfull:):) For the test inputs I used x=2 and y=counter that counts up from 0. outpu=x/y I am using spartan 3A 1400 if this could be some problem also but I don't see how it would be. thanks for any kind of help ZoranArticle: 138652
On 2009-03-03, Essy <ehsan.hosseini@gmail.com> wrote: > The constants should be set all at the power-up, so using block rams > won't be a good idea since each block ram will be used for only one of > them. I was thinking of saving these constants as initial values of > the FFs. In this case, the resources and routing won't be affected. > But, the problem is how to change the initial value of FFs. Are they > accessible through the bitstream? What really happens when we assign > the initial values of the registers in the VHDL or Verilog code? If you want to change the powerup values of FFs you can do that fairly easy by converting the place and routed NCD into an XDL file (which is an ASCII representation of your design), change the powerup value, and convert the XDL file back into NCD file format. After that you can run bitgen on the new NCD file. This would be much faster than resynthesizing the entire design and wouldn't require that much effort to do. A faster solution (which you may want to research if you want to produce thousands of different bitstreams each day) is to modify the bitfile directly. I would guess that changing the powerup value is fairly easy, but I don't know whether the ISE EULA allows this kind of bitstream manipulation or not. /AndreasArticle: 138653
Hi all, In my recent design, I have a number of constants which change from time to time. I have written a VHDL package in which the constants are declared. These values are then passed to different modules as generic inputs. The rest of design is fixed. My question is: "Is there a way to avoid repeating the lengthy process of synthesis and PAR in this case?" I was thinking of guided PAR, but I found it useless based on the previous posts and the manual (Development System Reference Guide). P.S. I'm using Xilinx ISE design flow with XST as synthesizer. Thanks.Article: 138654
Essy wrote: > Hi all, > > In my recent design, I have a number of constants which change from > time to time. I have written a VHDL package in which the constants are > declared. These values are then passed to different modules as generic > inputs. The rest of design is fixed. My question is: "Is there a way > to avoid repeating the lengthy process of synthesis and PAR in this > case?" I was thinking of guided PAR, but I found it useless based on > the previous posts and the manual (Development System Reference > Guide). > > P.S. I'm using Xilinx ISE design flow with XST as synthesizer. > > Thanks. Assuming you've got a block ram, but them in a rom and then use data2mem to change the rom constants. (Untested by me, but it might work!) regards Alan -- Alan Fitch Doulos http://www.doulos.comArticle: 138655
On Mar 3, 7:40=A0am, Essy <ehsan.hosse...@gmail.com> wrote: > Hi all, > > In my recent design, I have a number of constants which change from > time to time. I have written a VHDL package in which the constants are > declared. These values are then passed to different modules as generic > inputs. The rest of design is fixed. My question is: "Is there a way > to avoid repeating the lengthy process of synthesis and PAR in this > case?" I was thinking of guided PAR, but I found it useless based on > the previous posts and the manual (Development System Reference > Guide). > > P.S. I'm using Xilinx ISE design flow with XST as synthesizer. > > Thanks. Most likely not. Without knowing the details of what is in your packages, one could still envision that the constants could define something like data bus widths, so a simple change of a constant from 8 to 16 could cause all kinds of additional resources to be needed to support the wider data bus and/or processing path. Data bus widths are but one simple example of an entire class of generics that directly influence the number of logic resources required. In general, increasing the number of logic resources used increases the amount of time required to synthesize the design (i.e. generating 16 hunks of something and figuring out the interconnect takes longer.than 8 hunks). Of course there can also be constants that affect only the logic operations and do not inherently affect the amount of logic resources required. An example of this type could be some form of "Product ID" or "Revision" software port where you're changing the contents of some read only field (i.e. "01", "02",.... for a design revision field that the software folks can query). This all gets generated by logic but it's not inconceivable that even such a simple change could cause need for one or two more (or fewer) logic cells to be required, possibly also affecting timing as well. If you want to lock this down, you would basically have to write the code such that these constants get implemented in a block ram in the device, using it in a read-only mode. Presumably you could then simply edit the file that defines the contents of the memory and get a quicker synthesis. This probably only makes sense though if you have a bunch of such constants and you only need access to one of them at a time...or if you have a bunch of unused block rams. Kevin JenningsArticle: 138656
On Mar 3, 9:58=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Mar 3, 7:40=A0am, Essy <ehsan.hosse...@gmail.com> wrote: > > > Hi all, > > > In my recent design, I have a number of constants which change from > > time to time. I have written a VHDL package in which the constants are > > declared. These values are then passed to different modules as generic > > inputs. The rest of design is fixed. My question is: "Is there a way > > to avoid repeating the lengthy process of synthesis and PAR in this > > case?" I was thinking of guided PAR, but I found it useless based on > > the previous posts and the manual (Development System Reference > > Guide). > > > P.S. I'm using Xilinx ISE design flow with XST as synthesizer. > > > Thanks. > > Most likely not. =A0Without knowing the details of what is in your > packages, one could still envision that the constants could define > something like data bus widths, so a simple change of a constant from > 8 to 16 could cause all kinds of additional resources to be needed to > support the wider data bus and/or processing path. =A0Data bus widths > are but one simple example of an entire class of generics that > directly influence the number of logic resources required. =A0In > general, increasing the number of logic resources used increases the > amount of time required to synthesize the design (i.e. generating 16 > hunks of something and figuring out the interconnect takes longer.than > 8 hunks). > > Of course there can also be constants that affect only the logic > operations and do not inherently affect the amount of logic resources > required. =A0An example of this type could be some form of "Product ID" > or "Revision" software port where you're changing the contents of some > read only field (i.e. "01", "02",.... for a design revision field that > the software folks can query). =A0This all gets generated by logic but > it's not inconceivable that even such a simple change could cause need > for one or two more (or fewer) logic cells to be required, possibly > also affecting timing as well. =A0If you want to lock this down, you > would basically have to write the code such that these constants get > implemented in a block ram in the device, using it in a read-only > mode. =A0Presumably you could then simply edit the file that defines the > contents of the memory and get a quicker synthesis. =A0This probably > only makes sense though if you have a bunch of such constants and you > only need access to one of them at a time...or if you have a bunch of > unused block rams. > > Kevin Jennings The constants should be set all at the power-up, so using block rams won't be a good idea since each block ram will be used for only one of them. I was thinking of saving these constants as initial values of the FFs. In this case, the resources and routing won't be affected. But, the problem is how to change the initial value of FFs. Are they accessible through the bitstream? What really happens when we assign the initial values of the registers in the VHDL or Verilog code?Article: 138657
Hi, we are using a Virtex4 fx200 on our own board design. Now we plan to upgrade to Virtex6 with 10 Gbit/s MGTs. Do we need to develop a complete new board or are the two families compatible so that we can replace the Virtex4 with a Virtex6 with faster IOs and the board design remains the same? Thanks. SaulArticle: 138658
Essy wrote:
> In my recent design, I have a number of constants which change from
> time to time. I have written a VHDL package in which the constants are
> declared. These values are then passed to different modules as generic
> inputs. The rest of design is fixed. My question is: "Is there a way
> to avoid repeating the lengthy process of synthesis and PAR in this
> case?" I was thinking of guided PAR, but I found it useless based on
> the previous posts and the manual (Development System Reference
> Guide).
I might be able to *reduce* the time by declaring
all the possible settings in a constant array
with a generic index.
If the point is to *verify* a new configuration,
that can be done quickly by rerunning a sim.
-- Mike Treseler
Article: 138659On Feb 27, 4:59=A0pm, Antti wrote: > it seems they even have working silicon :) > well PCIe was already offered in ECP2 I am not familiar with the Lattice world. Would it be reasonable to design a board with the ECP3 at this point if I want to be selling them in two months or so? For other vendors I would wait at least a year before doing something like this. Though the Lattice site already has a "buy samples" link on the ECP3 page, it doesn't return any results. -- JecelArticle: 138660
On Mar 3, 7:21=A0am, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2009-03-03, Essy <ehsan.hosse...@gmail.com> wrote: > > > The constants should be set all at the power-up, so using block rams > > won't be a good idea since each block ram will be used for only one of > > them. I was thinking of saving these constants as initial values of > > the FFs. In this case, the resources and routing won't be affected. > > But, the problem is how to change the initial value of FFs. @Essy: Commentary, relying on intial value settings for flip flops is dicey. When the device comes alive after being configured, what do you think will happen if the very first clock edge that occurs does not meet the setup/hold timing requirements? Unless you're only turning the device on a couple times in its lifetime and it's not safety or business critical, or this is a homework assignment that's why any robust design would use some form of actual reset signal to get things into a known state. Initial values define only the state of a flip flop of the device when it comes out of configuration...that's it...at t=3D0...it says nothing about what state those flops are in at t=3D1ns. >> Are they > > accessible through the bitstream? What really happens when we assign > > the initial values of the registers in the VHDL or Verilog code? @Essy: They are accessible, but you're putting effort into something that is likely going to be making your life miserable in the end because your source code is not going to match the reality defined by the bitstream. You'll also get no support from Xilinx in investigating any potential problem that might be tool related (i.e. what if the ISE generated bitstream has some issue...this newsgroup is littered with queries from people who've (re)discovered various tool bugs). It sounds like you're trying to come up with a way to avoid creating separate packages for your separate designs which probably relates fundamentally back to a source control issue. In the end, you'll likely be better off by using good source control methods, splitting the design into the multiple designs that you're really creating (and presumably supporting...except if this is homework) so that each design will always inherit the 'common' stuff (i.e. all but the package). > If you want to change the powerup values of FFs you can do that fairly > easy by converting <snip> And thus we choose to start down the path where the source code diverges from the implementation... Robert Frost said "I took the one less traveled by, And that has made all the difference" Frost didn't say that it turned out to be a 'good' difference, just that it made all the difference. In this case I think I would choose to take the more traveled road and avoid some easily avoidable pitfalls... KJArticle: 138661
Andreas Ehliar wrote: (snip) > A faster solution (which you may want to research if you want to produce > thousands of different bitstreams each day) is to modify the bitfile > directly. I would guess that changing the powerup value is fairly easy, > but I don't know whether the ISE EULA allows this kind of bitstream > manipulation or not. I have been interested in designs with ROMs that are loaded into the bitstream after the bit file has been generated. In the XC4000 days the bit locations of LUT RAMs were given in Xilinx documentation, as they were needed when doing readback and comparing against the loaded bitstream. Also, I believe that it could have been done with Jbits, though I don't know the current status of that. I believe it should be allowed to find the locations of bits for either distributed or BRAM ROMs such that the bits can be patched into a bit file. -- glenArticle: 138662
Essy wrote: > The constants should be set all at the power-up, so using block rams > won't be a good idea since each block ram will be used for only one of > them. I was thinking of saving these constants as initial values of > the FFs. In this case, the resources and routing won't be affected. > But, the problem is how to change the initial value of FFs. Are they > accessible through the bitstream? What really happens when we assign > the initial values of the registers in the VHDL or Verilog code? When you use XST, at least in version 10.1 (haven't tried any others), it does evaluate and apply the initial values of signals. So when you declare a signal in your VHDL that is later used as a register and assign an inital value to it, that's the register's value after power-up. These initial values could be set using changing generics, and at least theoretically in this case a guided par should work OK and save some time. But this has some downsides: 1. Doesn't work with every synthesis tool. I know that Precision Synthesis ignores initial values (at least it did the last time I checked), don't remember if Synplify does, don't know if Quartus does. So if there's a chance you're going to work with any other synthesis tool besides XST sometime, you'll have to find yet another solution then. Some, but again not all tools, use the reset values assigned to FFs as the power-up value. You could use the reset value and then make sure the design is actually reset. 2. When you're working with generics, you can usually forget any guided modes. The reason is that tools tend to use the generics for their internally generated instance names. E.g. Precision generates names like instancename_genericvalue1_genericvalue2_genericvalue3 and so on in its netlists. So, if one of the generics changes, the instance names change, and any guided mode won't find the proper instances the second time around, hence re-implementing almost everything. I suppose in these cases changing constants declared in a package work better. But then again, if a package changes, all the modules using it will probably be re-implemented by default... So, basically, I feel your pain. :) Usually, what I do in these cases is: 1. Do what KJ suggested, if feasible in that case, or 2. Use an external (or maybe internal) microcontroller to set the register values via software. I usually have the luxury of actually having an external uC hooked up to the FPGA, so this works well. Lets me peek and poke at the regs on-the-fly as well, which is always nice. Of course this only works if the changing stuff doesn't modify bus widths and such, things that actually have bigger impact on the logic that is created. cu, SeanArticle: 138663
KJ wrote: (snip) > @Essy: Commentary, relying on intial value settings for flip flops is > dicey. When the device comes alive after being configured, what do > you think will happen if the very first clock edge that occurs does > not meet the setup/hold timing requirements? Unless you're only > turning the device on a couple times in its lifetime and it's not > safety or business critical, or this is a homework assignment that's > why any robust design would use some form of actual reset signal to > get things into a known state. Initial values define only the state > of a flip flop of the device when it comes out of > configuration...that's it...at t=0...it says nothing about what state > those flops are in at t=1ns. For many FPGAs, the initial state is also that of a global reset signal. Even so, I agree that it is better to have designs that will work without it. For example, state machines should work (get to a legal state in a reasonable number of cycles) even if they get into an otherwise illegal state, and not depend on the power up state. -- glenArticle: 138664
Xilinx CORE Generator produces inefficient CORDICs.Article: 138665
Our new boards Craignell2 and Mulldonich2 engineering product pages are now linked into our engineering website. Follow the "Board Products" to find them or use link http://www.enterpoint.co.uk/boardproducts.html. John Adair Enterpoint Ltd.Article: 138666
Links to out new boards Craignell2 and Mulldonch2 now on http://www.enterpoint.co.uk/boardproducts.html. John Adair Enterpoint Ltd.Article: 138667
Craignell2 and Mulldonnoch2 now listed ubder our board products page (engineering website www dot enterpoint dot co dot uk). John Adair Enterpoint Ltd.Article: 138668
On Mar 3, 9:46=A0am, "S. Bernstein" <jiffyl...@freenet.de> wrote: > Hi, > > we are using a Virtex4 fx200 on our own board design. Now we plan to upgr= ade > to Virtex6 with 10 Gbit/s MGTs. Do we need to develop a complete new boar= d > or are the two families compatible so that we can replace the Virtex4 wit= h a > Virtex6 with faster IOs and the board design remains the same? > > Thanks. > Saul I happened to notice one thing, Virtex6 does not support 3.3V I/O. BarryArticle: 138669
S. Bernstein schrieb: > Hi, > > we are using a Virtex4 fx200 on our own board design. Now we plan to upgrade > to Virtex6 with 10 Gbit/s MGTs. Do we need to develop a complete new board > or are the two families compatible so that we can replace the Virtex4 with a > Virtex6 with faster IOs and the board design remains the same? Virtex6 and Virtex4 are not pin-compatible, as far as I know, so the board will have to change. Plus, core voltage is different for the two families, so the power supply will have to be adjusted. Plus, as another poster noted, there is no more 3.3V-IO, which might be a problem for you as well if you need it. I'm sure there's a lot more subtle differences... cu, SeanArticle: 138670
Lattice ECP3 devices are available to order. Well at least the first two devices of the family. The evaluation boards for ECP3 has "Coming Soon" listed. Jecel wrote: > On Feb 27, 4:59=A0pm, Antti wrote: > > it seems they even have working silicon :) > > well PCIe was already offered in ECP2 > > I am not familiar with the Lattice world. Would it be reasonable to > design a board with the ECP3 at this point if I want to be selling > them in two months or so? For other vendors I would wait at least a > year before doing something like this. Though the Lattice site already > has a "buy samples" link on the ECP3 page, it doesn't return any > results. > > -- JecelArticle: 138671
Hi, I'm porting an ASIC design to virtex-5. In the design there is a 32x32->64 bit signed multiplier and I can't seem to do any better than synthesis at this point (tried two different synthesis tools which give the same results also). What would be the fastest way to do a 32x32 multiplier in Virtex-5? I'm trying to get it to run at 125 MHz on a xc5vlx50-1. Area is no problem and I'm currently using 4 DSP48E blocks. I haven't tried a fabric only implementation but I can't imagine that being faster. Alas adding pipelining to the existing design is out of the question. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138672
On Mar 3, 1:07=A0pm, Jecel <je...@merlintec.com> wrote: > On Feb 27, 4:59=A0pm, Antti wrote: > > > it seems they even have working silicon :) > > well PCIe was already offered in ECP2 > > I am not familiar with the Lattice world. Would it be reasonable to > design a board with the ECP3 at this point if I want to be selling > them in two months or so? For other vendors I would wait at least a > year before doing something like this. Though the Lattice site already > has a "buy samples" link on the ECP3 page, it doesn't return any > results. > > -- Jecel I don't have any experience with Lattice new introductions, but I think Xilinx is the only FPGA maker that has introductions and won't sell to small companies for 6 months or more. Altera seems to pride themselves on being more conservative with introductions, waiting until the product is nearly ready to ship to distributors before they announce. I think Lattice is like that too. I know nothing about Actel. Do they *have* new products? RickArticle: 138673
rickman wrote: > I don't have any experience with Lattice new introductions, but I > think Xilinx is the only FPGA maker that has introductions and won't > sell to small companies for 6 months or more. Altera seems to pride > themselves on being more conservative with introductions, waiting > until the product is nearly ready to ship to distributors before they > announce. I think Lattice is like that too. I know nothing about I think that the introductions are more market driven. For example Stratix IV was announced long before there were any chips available, quite probably due to the V5 pressure. On the other hand some Xilinx chips have been available for big customers before the official introduction. I think on the long run all the vendors are quite equal in their introductions. If the situation is tight they announce early, and if they are comfortable it is enough to announce the chips to big customers and test with them the samples. --KimArticle: 138674
Kim Enkovaara wrote: > rickman wrote: > >> I don't have any experience with Lattice new introductions, but I >> think Xilinx is the only FPGA maker that has introductions and won't >> sell to small companies for 6 months or more. Altera seems to pride >> themselves on being more conservative with introductions, waiting >> until the product is nearly ready to ship to distributors before they >> announce. I think Lattice is like that too. I know nothing about > > I think that the introductions are more market driven. For example > Stratix IV was announced long before there were any chips available, > quite probably due to the V5 pressure. > > On the other hand some Xilinx chips have been available for big > customers before the official introduction. I think on the long run all > the vendors are quite equal in their introductions. If the situation > is tight they announce early, and if they are comfortable it is enough > to announce the chips to big customers and test with them the samples. > My impression is that Altera says they introducing a new device when they have internal test samples, then give a timetable for rolling out the devices. When Xilinx says a device is "available", they really mean that the marketing brochures are available (assuming you are a very large customer)... Either way, it's always best to check with your distributor - they should know the real situation.
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