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
I am using the Coregen Dual-Port Virtex II Block Ram. In Coregen, you can simply enter a 0 and it should initialise all your entries to '0'; But when I simulate (functional) in Modelsim I get 'X's. I have also tried using the Memory editor to create a COE file, and it created a .mif, which was referenced in the component declaration. But still in Modelsim, I get X's. Is there something else I should be doing? Thanks.Article: 56601
"Dave Farrance" <davefarrance@yahooERASETHIS.co.uk> wrote in message news:048bevgpligq7qqtjqap2e60fbfra3tfgu@4ax.com... > hmurray@suespammers.org (Hal Murray) wrote: > Pardon if this is a common question, but is there any sort of standard > for inferring complex functions? I've used 4 VHDL compilers, and they > each had differences. > (The most recent spec I've got to hand is IEEE 1076-1993 and that > doesn't even mention flip-flops) The base VHDL and Verilog standards don't directly cover synthesis. For both languages there are "synthesis interoperability" standards that define what language constructs a synth tool should process, and exactly how those constructs should be interpreted - the key goal being to assure equivalence between simulation and hardware behaviour. The relevant standards are 1076.6 for VHDL and 1364.1 for Verilog. The bad news is that these standards are currently only at a baseline level, so for all practical purposes they specify the common subset that will be processed successfully by any professional-quality existing tools. No magical functions and no fireworks, I'm afraid. So your gripe about four tools dealing with your VHDL in four different ways still holds good. The good news is that people are working on enhancing those standards, so that a wider subset of the languages should in future be handled consistently by all tools. But for the time being there is no substitute for knowing the right coding style and language restrictions for your current tool. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 56602
> > Any suggestions? Thanks. > > > > --Josh Model > > MIT/LL > > > A little magic with google on <fpga pc104> should get you started! > APS has been around awhile too. Yah, I've tried that, and was really surprised at the paucity of results compared to what you can get either with Non-PC104 FPGA dev boards, or DSP/CPU PC-104 boards. You're down to APS, Nova Engineering and Mesa. APS is fine, but is relatively expensive for the product you get (compared to the functionality and price of non-PC104 FPGA boards) Nova isn't bad, but also a bit pricey. Mesa seems to be more in line with the price, but is really bare bones on functionality. And all the choices are a couple of generations back in terms of which devices they support. --JoshArticle: 56603
I have a project based on ACEX1k100 made using Synopsys Altera Edition for synthesys and MaxPlusII v10.0 for fitting. Now I have to make some changes and I would like to migrate to Synplify and Quartus. So I syntesyzed the opriginal files with Synplify and I made a new project with Quartus, importing the MaxPlusII .acf file in it. Quartus was not able to fit the project that MaxPlus did because it was not able to route all the nets! to be more precise, it was not able to compile the project even with the original Synopsys synthetyzed files! Does someone have any suggestions? Regards AndreaArticle: 56604
hmurray@suespammers.org (Hal Murray) wrote in message news:<veajr7kvs2efe6@corp.supernews.com>...
> >Absolutely... if you feed into the lsb and do not reset those nets,
> >you can obtain resource savings (flops and routing) by letting the
> >tools infer an SRL:
>
> Are the tools not smart enough to recognize the other pattern?
> (left shift vs right shift, if you want to think that way)
>
> The SRL only goes in one direction, but the software could/should
> be smart enough to assign FFs in either order. (or for that matter,
> to find a chain of arbitrarily named signals that don't go anyplace
> other than the input of the next FF.)
I've had Synplify infer an SRL with arbitrarily named signals. It
appears to me like the limitation here is if you use a single vector
name in your VHDL, you'd better feed it into the lsb.
IE, the following does become an SRL for me:
readCtrlPipeline : PROCESS (clk)
BEGIN
IF clk'EVENT AND clk = '1' THEN
readPtr2_chan <= readPtr_chan;
readPtr3_chan <= readPtr2_chan;
readPtr4_chan <= readPtr3_chan;
readPtr5_chan <= readPtr4_chan;
readPtr6_chan <= readPtr5_chan;
readPtr7_chan <= readPtr6_chan;
END IF;
END PROCESS readCtrlPipeline;
But note that it only became an SRL for stages 4 to 7. I use
readPtr3_chan somewhere else, so that stage couldn't be absorbed into
the SRL.
Have fun,
Marc
Article: 56605"M.Randelzhofer" <mrandelzhofer@uumail.de> wrote: >"Krzysztof Szczepanski" <kszczepa@poczta.wp.pl> schrieb im Newsbeitrag >news:bc442u$bfs$1@korweta.task.gda.pl... >> Hello >> >> I have a problem with programming the XC95288-HQ208-15 device. I can see >the >Any clocks connected to the pld ? The chip must not have any free running >signal on any pin during programming. > >see: >http://www.xilinx.com/xapp/xapp104.pdf Which says... "If free running clocks are delivered into the ISP CPLD, it may be necessary to disconnect or disable their entry into the CPLD while programming." I don't see any 'must' in that. It seems XC95 series JTAG programming is generally a bit flakey. I have a design which programmed a blank part fine on the first attempt. 3 months later when a minor bug came to light I couldn't re-program it without stopping its clock.Article: 56606
Andrea Sabatini wrote: > I have a project based on ACEX1k100 made using Synopsys Altera Edition for > synthesys and MaxPlusII v10.0 for fitting. Now I have to make some changes > and I would like to migrate to Synplify and Quartus. So I syntesyzed the > opriginal files with Synplify and I made a new project with Quartus, > importing the MaxPlusII .acf file in it. Quartus was not able to fit the > project that MaxPlus did because it was not able to route all the nets! to > be more precise, it was not able to compile the project even with the > original Synopsys synthetyzed files! > > Does someone have any suggestions? Are the compiler settings identical ? I guess not. MaxPlus2 had a bunch of settings on how to optimize dispersed under various menues. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 56607
I have this Pseudo Random Shift Register with some XORed feedbacks. Now this generates a one-bit random distribution, while I should have a few more bits for a DAC. Can I just combine any shift register intermediate taps to my parallel DAC or do I have to follow some rules. - the randomity, ahem the repetition length should be unchanged - preferably the full range of the DAC should be used, meaning for a 8bit DAC, all 256 values should occur Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 56608
"Rene Tschaggelar" <tschaggelar@dplanet.ch> schrieb im Newsbeitrag news:8b8f3536f7c903b3fae34b5378764032@free.teranews.com... > I have this Pseudo Random Shift Register with some XORed feedbacks. > Now this generates a one-bit random distribution, while I should > have a few more bits for a DAC. Can I just combine any > shift register intermediate taps to my parallel DAC or do I have > to follow some rules. > - the randomity, ahem the repetition length should be unchanged > - preferably the full range of the DAC should be used, > meaning for a 8bit DAC, all 256 values should occur If you want a 8 bit random value, you need to a) use 8 bit from 8 intermediate taps, but you can do this only each 8th. clock cycle b) use 8 parallel LFSRs, loaded with differnt strating values Iam not sure if both approaches cover the FULL 8 bit range (0..255). -- MfG FalkArticle: 56609
"Jonathan Bromley" <jonathan@oxfordbromley.u-net.com> wrote: >The base VHDL and Verilog standards don't directly cover synthesis. >For both languages there are "synthesis interoperability" standards >that define what language constructs a synth tool should process, >and exactly how those constructs should be interpreted - the key >goal being to assure equivalence between simulation and hardware >behaviour. The relevant standards are 1076.6 for VHDL and 1364.1 >for Verilog. > >The bad news is that these standards are currently only at a >baseline level, so for all practical purposes they specify the >common subset that will be processed successfully by any >professional-quality existing tools. ... I see that a draft of 1076.6 is downloadable http://vhdl.org/siwg/66_D6X.PDF It is basically, as you say, a common synthesisable subset. However, I'm a bit surprised to see that it includes what I believe are Synopsys attribute names for inferring some hardware functions. e.g. INFER_MUX for multiplexors and RAM_BLOCK for RAMs. -- Dave FarranceArticle: 56610
Has anyone figured out (or tried to) the format of the bitstream used to configure an FPGA. Obviously each vendor's, and maybe each part's, bitstream format is different. I'm curious if it just serially goes along and sets up 16x1 LUTs (in the 4-input LUT case), and then there are all the special cases for embedded RAMs, MACs, etc. I suppose by making a one-LE circuit with the LE manually placed, and then making another one-LE circuit with the LE placed one LE to the right, etc, and then diff'ing the bitstream, one could eventually determine the bitstream layout. Or maybe it is much more involved? I'm asking because I wonder how difficult it would be to write one's own synthesizer and router, if only to see if it can be done without years of man-hours invested. -- PeteArticle: 56611
Hi all, Has anyone out there successfully implemented a DVI (Digital Video Interface) in a Virtex-II (or any other FPGA for that matter)? The tricky bit seems to be the physical layer which is sort-of-differential-but-not-really (it's called TMDS - transition minimised digital signalling). I'm sure there's a nifty way of doing it though... Thanks in advance! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 56612
Hi, Your board's data sheet should give you enough information on this. Find out the FPGA pins that correspond to the address lines, data lines and read/write signals from the FPGA to the onboard RAM. Use these pins to write to the RAM. If the RAM is asynchronous then you may need more than one cycle to read/write. To go to a specific location in the RAM, you need to be sure you have that address on the address lines. Prashant kalimuddin@hotmail.com (Muhammad Khan) wrote in message news:<7d350237.0306091218.50273b52@posting.google.com>... > Hi there > I want to write the result of the calculation done in Xilinx Vertex > device into the SRAM on board and then to the PC. Can anybody have any > idea how to do this I know I can used PC API function in my C file to > take data from memory location on SRAM. I don't know what should I > write in my VHDL code in order to make sure that I output of the pin > always goes to particular memory location in SRAM say X. > > Any help in this matter will be highly appreciated. > > Regards > > KhanArticle: 56613
On Tue, 10 Jun 2003 06:50:13 -0700, Josh Model wrote: >> > Any suggestions? Thanks. >> > >> > --Josh Model >> > MIT/LL >> >> >> A little magic with google on <fpga pc104> should get you started! APS >> has been around awhile too. > > Yah, I've tried that, and was really surprised at the paucity of > results compared to what you can get either with Non-PC104 FPGA dev > boards, or DSP/CPU PC-104 boards. > > You're down to APS, Nova Engineering and Mesa. APS is fine, but is > relatively expensive for the product you get (compared to the > functionality and price of non-PC104 FPGA boards) > > Nova isn't bad, but also a bit pricey. Mesa seems to be more in line > with the price, but is really bare bones on functionality. And all the > choices are a couple of generations back in terms of which devices they > support. > > --Josh Actually I would like to use the latest chips but since the PC/104 bus is 5V that does limit your choices. Sure you can add resistors, CPLDS or other mickey-mousery but that adds cost and complexity. This 5V trouble is also true of PCI cards. There are still _many_ 5V PCI cards around. All you need is one 5V card in a backplane and your 3.3V limited FPGA card is in trouble... PCWArticle: 56614
henrique@bmrio.com.br (Henrique) wrote in message news:<a296425.0306091736.631c43bf@posting.google.com>... > Hi all, > I am trying to find a place where i can buy virtex ii online (xc2v500 > or xc2v1000), but i am having a hard time. Can anyone help me?, Does > anyone know where i can buy? > tanks. Try AVNET at http://www.avnetmarshall.com/dynamic/search. Enter XC2V500 in the part search field. Bill HannaArticle: 56615
Hi, You can try the Altera divider (LPM_DIVIDE) which supports any bit width. If you are using Simulink, install DSP Builder (which contains the divider block) from : http://www.altera.com/products/software/system/products/dsp/dsp-builder.html Then you can simulate and evaluate in Simulink the Altera Divider block in your MDL model. Philippe Molson Altera Salman Sheikh <sheikh@pop500.gsfc.nasa.gov> wrote in message news:<bc2jdm$74$1@skates.gsfc.nasa.gov>... > Hello, > > I modeled my system in Xilinx System Generator and Matlab (using floating > then fixed point blocks). I found I need to divide a 31 bits number by a 24 > bits number and need to retain a 44 bit result consisting of an 8 bits > representing the integer result and 38 bits the fractional part. I tried > using the Xilinx pipelined divider core but it only handles 32 bit > remainder or fraction. Anybody have any idea where I can get a core or > should I try to code this thing from scratch (extremely painful)? > > > Thanks in advance. > > > SalmanArticle: 56616
Martin Thompson wrote: > Hi all, > > Has anyone out there successfully implemented a DVI (Digital Video > Interface) in a Virtex-II (or any other FPGA for that matter)? The > tricky bit seems to be the physical layer which is > sort-of-differential-but-not-really (it's called TMDS - transition > minimised digital signalling). I'm sure there's a nifty way of doing > it though... I think it's like with Ethernet that can not directly plugged into an FGPA. As far as I understand you need to have an PHY chip. There is a project at www.opencores.org you might want to have a look at, or at least ask them. KarstenArticle: 56617
Dave Farrance" <davefarrance@yahooERASETHIS.co.uk> wrote in message news:utobevsg86r25vvroe84115knng3uku0qq@4ax.com... > I see that a draft of 1076.6 is downloadable > http://vhdl.org/siwg/66_D6X.PDF > > It is basically, as you say, a common synthesisable subset. > > However, I'm a bit surprised to see that it includes what I believe are > Synopsys attribute names for inferring some hardware functions. e.g. > INFER_MUX for multiplexors and RAM_BLOCK for RAMs. I was referring to the published 1076.6-1999, which is a formally released IEEE standard and therefore costs money :-( The draft you mention is of the so-called "Level 2" version of 1076.6, containing many enhancements. If I recall correctly, the brief for Level 2 was to include everything useful that had at least one commercial implementation - and therefore an existence proof that it's possible - whereas the original Level 1 was essentially the common subset, a lowest-common-denominator that would ensure interoperability with most existing tools (apart from a few syntactic cleanups on attribute names etc). Hence the names of attributes in the Level 2 draft are probably taken from whichever tool implements those features. Sorry I can't be more specific - I stopped following the 1076.6 discussions about a year ago. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 56618
Karsten Becker wrote: > I think it's like with Ethernet that can not directly plugged into an > FGPA. As far as I understand you need to have an PHY chip. > There is a project at www.opencores.org you might want to have a look > at, or at least ask them. I found some PHY chips: http://www.siimage.com/products/display.asp#transmitters They look like what you need. At least like what I need ;-) KarstenArticle: 56619
If all you want is test all 8-bit combinations, then you can use any combination of taps you want ( after having fixed the LFSR to include the all-ones state) But that does not give you a random sequence of byte values, since the next byte is almost a shifted copy of the previous one. If you want better randomness, you can use eight LFSRs of different length, each generating one bit of the output. LFSRs are dirt-cheap in flip-flop-rich FPGAs, and even cheaper when you use SRL16s ( up to 16 bits in one LUT) Peter Alfke, Xilinx ========================= Rene Tschaggelar wrote: > > I have this Pseudo Random Shift Register with some XORed feedbacks. > Now this generates a one-bit random distribution, while I should > have a few more bits for a DAC. Can I just combine any > shift register intermediate taps to my parallel DAC or do I have > to follow some rules. > - the randomity, ahem the repetition length should be unchanged > - preferably the full range of the DAC should be used, > meaning for a 8bit DAC, all 256 values should occur > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > & commercial newsgroups - http://www.talkto.netArticle: 56620
Hi, I am trying to persuade Xilinx's abomination of gdb to allow me to step through the startup code on a Virtex II Pro using their stub and JTAG cable debugging support kit. I can trace regular C code as one would expect but even after verifying the code is being compiled with appropriate '-g' or '-gstabs' flags[0] and so forth - I am frustrated. Any helpful comments appreciated. Cheers, Jon. [0] Both inside the EDK and using my own separated build environment and make files. I am missing something trivially obvious I know. :-)Article: 56621
Andrea Sabatini wrote: > I have a project based on ACEX1k100 made using Synopsys Altera Edition for > synthesys and MaxPlusII v10.0 for fitting. Now I have to make some changes > and I would like to migrate to Synplify and Quartus. Try giving quartus just the Synplify .edf file and no other constraints. If that works, fix up the pins and clk constraint on the Quartus GUI and and rerun the place and route. -- Mike TreselerArticle: 56622
The AFX demostration boards for the Virtex, Virtex-E, Virtex-II, and Virtex-II Pro have socketed FPGAs and PROMs. Online Store --> Development Boards Regards, MicholArticle: 56623
Pete, don't even try! It is easy enough to find the LUT-bit and RAM-bit locations through a systematic search. But most configuration bits are used to control the interconnect. Take the XC2V6000: It has roughly 1 million LUT bits, and 3 million BlockRAM bits, but a total of 19 million configuration bits. That means 15 million of the 19 million config bits are used to control the interconnect structure plus various control functions. It's the old joke: "We sell interconnect, logic comes for free". Peter Alfke =============================== Peter Sommerfeld wrote: > > Has anyone figured out (or tried to) the format of the bitstream used > to configure an FPGA. Obviously each vendor's, and maybe each part's, > bitstream format is different. > > I'm curious if it just serially goes along and sets up 16x1 LUTs (in > the 4-input LUT case), and then there are all the special cases for > embedded RAMs, MACs, etc. I suppose by making a one-LE circuit with > the LE manually placed, and then making another one-LE circuit with > the LE placed one LE to the right, etc, and then diff'ing the > bitstream, one could eventually determine the bitstream layout. Or > maybe it is much more involved? > > I'm asking because I wonder how difficult it would be to write one's > own synthesizer and router, if only to see if it can be done without > years of man-hours invested. > > -- PeteArticle: 56624
You need the PHY chip. Maybe V2P can dispense with that too. I currently have DVI working out of a V2 at up to 165MHz using a Silicon Image Sii-164 PHY chip. Not very difficult, but board design and timing are, of course, important. Rather than resorting to a DCM-based clock feedback mechanism I chose to generate the source-synchronous clock at the IOB's by using the DDR mechanism. This assumes you've done a good job during layout to time all signals coming into the PHY chip. Works very well. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Martin Thompson" <martin.j.thompson@trw.com> wrote in message news:u4r2youcy.fsf@trw.com... > > Hi all, > > Has anyone out there successfully implemented a DVI (Digital Video > Interface) in a Virtex-II (or any other FPGA for that matter)? The > tricky bit seems to be the physical layer which is > sort-of-differential-but-not-really (it's called TMDS - transition > minimised digital signalling). I'm sure there's a nifty way of doing > it though... > > Thanks in advance! > Martin > > -- > martin.j.thompson@trw.com > TRW Conekt, Solihull, UK > http://www.trw.com/conekt > >
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