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
> But poster above claims it is a bad design practice. Use product term clocks at your own risk. Every time you change the design and re-fit, your skew and delay can be different. You will be using lots of signal routing resources if the clock tree is large. All this will just get worse as the design is enlarged. Global clocking resources have guaranteed skew times and delays regardless of how dense the design is packed.Article: 64677
I am beginning the design with Spartan-3 in the FG456 package. Can anybody give an estimate how many PCB layers are necessary for this package with 6 perimeter I/O rows and GND, VCCINT, VCCO inside? Is it possible to design reliable board for it without buried vias? Any response will be appreciated.Article: 64678
I want to read an image file into vhdl....how it could be done...can u please explain it in detail...Article: 64680
Remis Norvilis wrote: > > And then Ralph Malph wrote: > > > remis norvilis wrote: > >> > >> I'm considering to get Spartan-3 LC Dev. Kit (DS-KIT-3SLC400) from > >> Insight. Anybody used it? Comments would be appreciated. > >> > >> Remis > > > > I couldn't find anything on the Insight web site about this. Where did > > you see the info? > > Check this site: > http://legacy.memec.com/devkits/americas.shtml I do find the USB2.0 interface interesting. Otherwise this is not anything special that I can see. Is there any additional info available? How about a user guide? I am always suspicious when the USB 2.0 term is used. This does not always mean high speed. I would like to see more IO made available on a module like this. If they used a BGA package with a lot more IO, I could do some prototyping with it.Article: 64681
Bob Perlman wrote: > > On 30 Dec 2003 09:53:47 -0800, news@sulimma.de (Kolja Sulimma) wrote: > > >> If you think there's even a chance that you're going to be designing > >> in a certain component, get a formal price quote from the salesman, > >> rep, or distributor. And if you can't get a quote, maybe you can't > >> get the part, either. > >> > Bob Perlman > >> Cambrian Design Works > > > >The issue was, that the formal quotes for pieces in 5k quantities > >where a factor of 20 above the prices quoted by Xilinx for 250k > >quantities. > >And nobody in this group really believed that you get a 95% volume > >discount. > > If a formal quote for 5k pieces comes in at 20X a formal quote for > 250k pieces, that's interesting information. But if a formal quote > for 5k pieces is 20X the 250k price stated in a press release, that's > hardly surprising. > > Which is it? > > Any price you see in a press release should have a "j" after it. "J" for joke? A friend told me that the 50,000 piece price on the slowest XC3S400 in the FG456 package would be around $20. The press releases are talking about the "smallest" package and 250,000 quantities giving a price around $5. I don't know what the "smallest" package is, but I would like to meet the guy who is getting the $5 price. Seems to me the whole point of the Spartan 3 chips is low price. They are not faster, or lower power or anything else other than cheap. If they don't come in below the competition, what good are they? Heck, with three power supplies and very touchy IO voltage specs, they seem to me like a PITA to design in!Article: 64682
Browsing the 'cyclone device handbook' I spent a great length to find : -the max current for each supply ( VCCIO & VCCINT ) -the expected clocking frequency at the input. I'm aware that 1MHz may not be sufficient to PLL it up to 400MHz or such. to little avail. While I can live with 2 switchmode supplies generating 1.5V and 3.3V at 2A each, and a generic 8pin socket to swap oscillators for a prototype, the documentation is somehow inclomplete. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 64683
The Altera Cyclone Programming device EPCS1 are shown to be programmed in the AS mode requiring an own connector. Since the JTAG was never officially declared outdated, I'd expect a way to program the cyclone plus the EPCS1 in JTAG mode. I wasn't able to find it yet though. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 64684
Rene Tschaggelar wrote: > I started reading some documents about the configuration > devices EPCS1 & EPCS4. They appear to be programmed with a > new download cable, the Byteblaster2. > The Byteblaster2 claims compatibility with the previous models, > the Byteblaster and the ByteblasterMV. Unfortunately, there > is no schematics included in the Byteblaster2 datasheet. > Is the 74HC244 being changed to a 74LV244 this time ? > > > Rene A link to the schemtaic for the ByteBlaster II was posted on this site a while back !!Article: 64685
Rene Tschaggelar wrote: > According to the Serial Configuation Devices() Datasheet > (chapter 4 of configuration handbook volume 2), > I understand that the Cyclones and their configuration devices > are programmed in the so called AS mode with the Byteblaster2. > > Debugging is done with the usual JTAG connector, I assume. > The Byteblaster2 also supports JTAG. > > Meaning I have to swap the connector ? > > Rene No, you do not have to swap the connector as the ByteBlaster II supports multiple configuration modes. The JTAG functionality is always available, but depending on how you set the MSEL(0,1) pins, you can programming the cyclone devices either in AS or PS modes.Article: 64686
suneetha wrote: > I want to read an image file into vhdl....how it could be done...can u > please explain it in detail... http://groups.google.com/groups?q=vhdl+binary+file+read -- Mike TreselerArticle: 64687
I believe you need six layers minimum. No need for buried vias as far I as know. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Jaromir Kolouch" <kolouch@cedo.cz> wrote in message news:ee81d5e.-1@WebX.sUN8CHnE... I am beginning the design with Spartan-3 in the FG456 package. Can anybody give an estimate how many PCB layers are necessary for this package with 6 perimeter I/O rows and GND, VCCINT, VCCO inside? Is it possible to design reliable board for it without buried vias? Any response will be appreciated.Article: 64688
Ben Popoola wrote: > Rene Tschaggelar wrote: > >> According to the Serial Configuation Devices() Datasheet >> (chapter 4 of configuration handbook volume 2), >> I understand that the Cyclones and their configuration devices >> are programmed in the so called AS mode with the Byteblaster2. >> >> Debugging is done with the usual JTAG connector, I assume. >> The Byteblaster2 also supports JTAG. >> >> Meaning I have to swap the connector ? >> >> Rene > > > No, you do not have to swap the connector as the ByteBlaster II supports > multiple configuration modes. > I figured out that Byteblaster2 masters different modes. What I wasn't able to figure out yet was how to use the JTAG mode on the AS mode pins. Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1) the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, nCE. And JTAG uses TCK, TMS, TDI, TDO. > The JTAG functionality is always available, but depending on how you set > the MSEL(0,1) pins, you can programming the cyclone devices either in AS > or PS modes. > Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the same cable and connector for debugging too. That was possible with the ACEX family at least. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 64689
Ben Popoola wrote: > Rene Tschaggelar wrote: > >> I started reading some documents about the configuration >> devices EPCS1 & EPCS4. They appear to be programmed with a >> new download cable, the Byteblaster2. >> The Byteblaster2 claims compatibility with the previous models, >> the Byteblaster and the ByteblasterMV. Unfortunately, there >> is no schematics included in the Byteblaster2 datasheet. >> Is the 74HC244 being changed to a 74LV244 this time ? >> >> >> Rene > > > A link to the schemtaic for the ByteBlaster II was posted on this site > a while back !! Thanks. I have all messages 3 month back and was to find it. One paper claims to redo BBMV into BB2, but without 1.5V. The other, ... I'll have a look at them anyway. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 64690
Rene Tschaggelar wrote: > Ben Popoola wrote: > >> Rene Tschaggelar wrote: >> >>> According to the Serial Configuation Devices() Datasheet >>> (chapter 4 of configuration handbook volume 2), >>> I understand that the Cyclones and their configuration devices >>> are programmed in the so called AS mode with the Byteblaster2. >>> >>> Debugging is done with the usual JTAG connector, I assume. >>> The Byteblaster2 also supports JTAG. >>> >>> Meaning I have to swap the connector ? >>> >>> Rene >> >> >> >> No, you do not have to swap the connector as the ByteBlaster II >> supports multiple configuration modes. >> > > I figured out that Byteblaster2 masters different modes. What I wasn't > able to figure out yet was how to use the JTAG mode on the AS mode pins. > Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1) > the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, nCE. > And JTAG uses TCK, TMS, TDI, TDO. > >> The JTAG functionality is always available, but depending on how you >> set the MSEL(0,1) pins, you can programming the cyclone devices either >> in AS or PS modes. >> > Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the same > cable and connector for debugging too. > That was possible with the ACEX family at least. > > Rene Yes, I agree entirely. With the Actel proAsic devices ( flash based FPGA) not only do you do everything through the JTAG interface, but you can also add your own logic to the JTAG chain. Thus, doing things like in-system programming are a stroll in the park.Article: 64691
Ben Popoola wrote: > Rene Tschaggelar wrote: > >> Ben Popoola wrote: >> >>> Rene Tschaggelar wrote: >>> >>>> According to the Serial Configuation Devices() Datasheet >>>> (chapter 4 of configuration handbook volume 2), >>>> I understand that the Cyclones and their configuration devices >>>> are programmed in the so called AS mode with the Byteblaster2. >>>> >>>> Debugging is done with the usual JTAG connector, I assume. >>>> The Byteblaster2 also supports JTAG. >>>> >>>> Meaning I have to swap the connector ? >>>> >>> No, you do not have to swap the connector as the ByteBlaster II >>> supports multiple configuration modes. >>> >> >> I figured out that Byteblaster2 masters different modes. What I wasn't >> able to figure out yet was how to use the JTAG mode on the AS mode pins. >> Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1) >> the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, >> nCE. >> And JTAG uses TCK, TMS, TDI, TDO. >> >>> The JTAG functionality is always available, but depending on how you >>> set the MSEL(0,1) pins, you can programming the cyclone devices >>> either in AS or PS modes. >>> >> Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the >> same >> cable and connector for debugging too. >> That was possible with the ACEX family at least. >> > > Yes, I agree entirely. > > With the Actel proAsic devices ( flash based FPGA) not only do you do > everything through the JTAG interface, but you can also add your own > logic to the JTAG chain. > > Thus, doing things like in-system programming are a stroll in the park. > Hmm, and what should I do with the Cyclone ? Have 2 connectors, one for the AS, doing the EPCS1 and the Cyclone and the other for the JTAG debugging ? Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 64692
I am contemplation writing special apps core designs in VHDL for licensing. Does anyone know how cores are protected against theft these days? Does particular device targeting affect the protection scheme (if any)? ThanksArticle: 64693
Rene Tschaggelar wrote: > Ben Popoola wrote: > >> Rene Tschaggelar wrote: >> >>> Ben Popoola wrote: >>> >>>> Rene Tschaggelar wrote: >>>> >>>>> According to the Serial Configuation Devices() Datasheet >>>>> (chapter 4 of configuration handbook volume 2), >>>>> I understand that the Cyclones and their configuration devices >>>>> are programmed in the so called AS mode with the Byteblaster2. >>>>> >>>>> Debugging is done with the usual JTAG connector, I assume. >>>>> The Byteblaster2 also supports JTAG. >>>>> >>>>> Meaning I have to swap the connector ? >>>>> >>>> No, you do not have to swap the connector as the ByteBlaster II >>>> supports multiple configuration modes. >>>> >>> >>> I figured out that Byteblaster2 masters different modes. What I wasn't >>> able to figure out yet was how to use the JTAG mode on the AS mode pins. >>> Meaning (Fig3-7 configuration handbook / cyclone device handbook vol1) >>> the AS mode uses Data, DCLK, nCs/nCSO, ASDI/ASDO, nConfig, Conf_Done, >>> nCE. >>> And JTAG uses TCK, TMS, TDI, TDO. >>> >>>> The JTAG functionality is always available, but depending on how you >>>> set the MSEL(0,1) pins, you can programming the cyclone devices >>>> either in AS or PS modes. >>>> >>> Preferably I'd program the EPCS1 & the Cyclone with JTAG, and use the >>> same >>> cable and connector for debugging too. >>> That was possible with the ACEX family at least. >>> >> >> Yes, I agree entirely. >> >> With the Actel proAsic devices ( flash based FPGA) not only do you do >> everything through the JTAG interface, but you can also add your own >> logic to the JTAG chain. >> >> Thus, doing things like in-system programming are a stroll in the park. >> > > Hmm, and what should I do with the Cyclone ? Have 2 connectors, one > for the AS, doing the EPCS1 and the Cyclone and the other for the JTAG > debugging ? > > Rene I think that you can also program the EPCS1 via the Cyclone chip itself but I do not know how off head. This might work: (1) Configure the FPGA through the JTAG port. (2) If you have an I/O connection between your logic in the Cyclone and a PC, download your configuration bitstream into the EPCS1 via your logic in the Cyclone. (3) Turn the power off then on. The Cyclone should boot from the EPCS1.Article: 64694
On Sun, 11 Jan 2004 10:54:29 -0800, "Jaromir Kolouch" <kolouch@cedo.cz> wrote: >I am beginning the design with Spartan-3 in the FG456 package. >Can anybody give an estimate how many PCB layers are necessary for this package >with 6 perimeter I/O rows and GND, VCCINT, VCCO inside? Is it possible to design >reliable board for it without buried vias? > >Any response will be appreciated. You have posted an article to comp.arch.fpga via the Xilinx gateway to this news group. Unfortunately, this gateway mistakenly allows HTML posting, and even turns text postings into HTML. For all news groups, including comp.arch.fpga, the format is supposed to be text only. I have advised Xilinx about this problem, which they have said they will fix, but no schedule. This concerns me for 2 reasons. First, many other users of comp.arch.fpga either can't read your postings, or it is a pain, and secondly, I maintain the archive of this news group at www.fpga-faq.com and I have to spend several hours each month cleaning up the mess that is caused by HTML posts. (11/08/2003 www.fpga-faq.com is currently off the air due to a Denial of Service attack. I expect that it will be enabled again early next month) An alternative free system that will allow you to read and post articles to comp.arch.fpga and that does not have this problem is the gateway provided by Google, which also maintains archives (for all news groups) in text form only. (The archive for this news group at google should have the same content as the one I maintain, but mine has nicer indices and threading by author, topic, and date) You can use google starting from the following page: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.arch.fpga There is a link in the top right corner for posting. You may have to create an identity before posting, but that is free too. Thanks Philip Freidin =================== Philip Freidin philip@fliptronics.com Host for WWW.FPGA-FAQ.COMArticle: 64695
Both VHDL and Verilog have a synthesis subset. Some aspects of the synthesis subset are intuitive, you can't synthesize access types. Both have a separate standard that govern the synthesis subset. For VHDL this is 1076.6, for Verilog it is 1364.1. If you want to see vendors support portable coding styles, ask them to support these standards. You do need to ask because for EDA vendors supporting a standard is an investment. They expect to get something in return - like users buying their tools. The VHDL synthesis standard is quite a bit broader than the Verilog standard, particularly with respect to registers. For example, VHDL supports dual edged registers (separate clocks or rising and falling edges). Some of this is representative of VHDL being more popular for FPGA design (and FPGA's supporting devices like this). See also my follow up to the guy who stated: "Verilog is a very simple language so it's easier for the tools guys to get it right." If you are making a saftey critical design, you would be better off using VHDL. There are lots of ways to hang yourself with Verilog (and none of them give you anything useful at the end of the day). To sum this up in another way, "On a bad day coding VHDL, the compiler is going to abuse you (hence this explains why some hate VHDL), however, on a bad day coding Verilog, you can embed bugs that make it essential that you have a great testbench to find." Cheers, Jim Lewis -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Carlen wrote: > Greetings: > > I am reading J Bhasker's "Verilog HDL Synthesis" along with "A Verilog > Primer" in order to learn not only Verilog, but how to make sure I can > model designs in a way that is synthesizable. > > What I have just learned is that the synthesis system (such as if I am > using Xilinx ISE Webpack and it's associated synthesis tools) dictates > what style must be followed, because one system might be able to > synthesize model 'A' and not 'B', whereas another system might be able > to synthesize 'B' and not 'A', even though models 'A' and 'B' are > functionally equivalent. > > Thus, this leads to the question of how to I learn about what modeling > style will be synthesizable for my particular tools? > > The text won't be able to teach me this, since it is just dealing with > the problem in general. Obviously this must be in the tooll > documentation, so I would ask: > > Is there good modeling style info in Xilinx tools so that one can learn > how to make synthesizable models for Xilinx tools reliably? > > Finally, how to VHDL and Verilog compare in terms of *inherent* > synthesizability of models, or does the same problem essentially exist > for both? > > Thanks for input. > > Good day!Article: 64696
> Verilog is a very simple language so it's easier for > the tools guys to get it right. This is an incorrect assumption. Verilog is a less consise language. If you don't follow some adhoc methodology for coding styles, you will not get it right. This fact has been proven time and time again by Verilog experts who have given numerous conference papers how they overcame yet another Verilog issue. And by the way, according to my sources (Cliff C.) this is not a feature that is being fixed in SystemVerilog. VHDL is a very consise language. Code written and simulated in one simulator will behave exactly the same in another simulator. So going back to simple. Verilog is simple to start producing code, however, if you fail to follow the adhoc rules of Verilog coding, it is very easy to get it wrong. Note, this happens to Verilog experts. If you want to get it right with Verilog, you would be best to invest in a Lint tool. In VHDL many lint tool features are built into the language. As a result, you need to learn these rules from either a good book or from a good class. If you fail to learn these rules, getting started will be painful to get by the compiler. However, once you produce working code the likely hood of it being correct is much higher. For example, at DVCon last year, a company who codes their IP in Verilog and translates to VHDL has imposed the strong typing rules of VHDL onto their Verilog designers (via a lint tool). 75% of the time a lint violation resulted in a real bug. It is certainly better to find these issues at compile/lint time rather than spending time simulating an incorrect design. > Personnally I stick strictly to Verilog 95, I'm not even > considering using any Verilog 2001 constructs in synthesizable code for > another year. As for things like System C, that's targeted at testbenches > at the moment, I do think that there are any synthesis tools that can > handle it. > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 64697
>What's the way to do this? It's common for me to run into situations where >I have a bus or bus pin, and I need to connect the same net to different >lines on the bus. Another common one is I have 2 busses, both of which have >a line that should connect to a single net. The documentation doesn't seem >to give any hints. Thanks for any input. What does "connect the same net to different lines on the bus" mean? Do you want a mux or tri-state driver, to read a status bit when a particular register is selected? Or do you want a solid connection 100% of the time? If you want a hard connection, then physically, you are merging several nets into one. That seems a bit strange if two of them are part of the same bus. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 64698
tbx135 <tbx135@msn.com> wrote: >> But poster above claims it is a bad design practice. > > Use product term clocks at your own risk. Every time you change the > design and re-fit, your skew and delay can be different. You will be > using lots of signal routing resources if the clock tree is large. > All this will just get worse as the design is enlarged. > > Global clocking resources have guaranteed skew times and delays > regardless of how dense the design is packed. Using non-dedicated clock networks on FPGAs is certainly dangerous, and Xilinx ISE issues a warning when you do. But in CPLDs like XC9500s, routing should be predicable as it is done through a regular routing matrix, unlike FPGAs. And ISE gives no warning when using product term clocks. If they weren't safe to use, it would be a major fault of the fitter not to warn about them. In my XC9500XL designs using many product term clocks, I haven't seen any problems with them. A global clock network, while saving a product term in each macrocell and giving a faster Tco, isn't very flexible as it can only be driven from the three physical GLK pins, and not from internally generated signals. So in many designs, product term clocks are very handy. Since the fitter readily uses them, it would be a pity if you had to look through the .rpt file for flipflop equations where the clock wasn't commented by "// GCK". But all this is circumstantial evidence. Could someone from Xilinx please comment on whether product term clocks in XC9500 are safe or unsafe? Karl OlsenArticle: 64699
> VHDL is a very consise language. Code written and > simulated in one simulator will behave exactly the > same in another simulator. > Jim - Concise means succinct, i.e., the opposite of verbose. I've never heard anyone make that claim about VHDL. Maybe you meant precise? Do you have a link to that DVCon paper? I'd like to read it. If not, can you briefly summarize some of the rules this company imposed? Thanks, Robert
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