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
John_H wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:4130AEF9.BF3AD39D@yahoo.com... > > [snip] > > > The third is to use two registers, but one logic path with a MUX in the > > front to switch registers as required by your function definition. > > [snip] > > If an FPGA with DDR support is the target, the DDR primitives can be > instantiated directly. The ability to clock on the rising and falling edges > is built-in without internal logic routing skew issues. I believe you are talking about IO clocking. Once the signal is captured in the IOBs, you still need a 2x clock internally. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 72726
"Jimmy" <mljiang@eee.hku.hk> wrote in message news:<cgq5hf$ebl$1@sf280r.eee.hku.hk>... > Hi, all , > > I am using ISE6.2 and modelsim5.8b. My design is composed of two > modules, one is VDHL design ,and the other is verilog design. Now I want to > combine them together in a top level file (in vhdl) and simulate the whole > design. Can I just instantiate the verilog design module with a compoenent > in the top file and write a testbench for the top file. > I have done this , but it fails when binding the verilog module > (rx_backend). > # ** Failure: Default binding had errors for entity 'rx_backend' on the > component declaration of line 220. See the compiler messages. > Could u give any idea on how to do the mixed vhdl and verilog design and > simulation? > Many thanks. > > Jimmy ############## Hi, Earlier i had this problem but i have solved it. What you can do is first install vhdl version, then copy vhdl folder from C:\Modeltech_xe_starter\xilinx\vhdl to different location. Then uninstall the modelsim and again install this time for verilog, this time you have C:\Modeltech_xe_starter\xilinx\verilog Now copy the vhdl from previous location to this location C:\Modeltech_xe_starter\xilinx\ If you now open the modelsim you have both libraries(verilog and vhdl) and you can start mixed language simulation. Note: This applies only to Free Modelsim XE edition(xilinx). Regards raoArticle: 72727
Paul Fulghum wrote: > PCI spec waveforms (+11V for overshoot, -5.5 for undershoot) > are specified at the resistor (55 Ohm for overshoot, > 25 Ohm for undershoot) that is part of the > test setup, not at the input pin. (section 4.2.1.3) Said section states that the resistors are voltage source impedances that define the maximum current (ie, the quasi short circuit current that clamping diodes would encounter). That is understood. > When you overshoot or undershoot, the clamp diodes > pass current causing a voltage drop across the > resistor resulting in a reduced voltage seen at > the input pin. Problem here is that the voltage drop depends on the input impedance of the following buffer or hi-z value of a tri-stated output. Given a high impedance input buffer (which is usually the case with CMOS devices) the voltage drop would not occur across the resistor as the relatively low output impedance of the voltage source but the input impedance of the buffer unless there is clamping applied. The point I was trying to make was that the data sheet does not explicitly tell whether there are clamping diodes in the 5V PCI qualified buffers or not. Since Vcco is 3.3V maximum at the input banks at the FPGA where would the clamping diodes go without a 5V supply given that clamping to 3.3V is impossible ? Thanks & regards, Christian BoehmeArticle: 72728
All, You might try reading the app notes? http://www.xilinx.com/bvdocs/appnotes/xapp653.pdf http://www.xilinx.com/bvdocs/appnotes/xapp646.pdf Austin Christian E. Boehme wrote: > Paul Fulghum wrote: > >> PCI spec waveforms (+11V for overshoot, -5.5 for undershoot) >> are specified at the resistor (55 Ohm for overshoot, >> 25 Ohm for undershoot) that is part of the >> test setup, not at the input pin. (section 4.2.1.3) > > > Said section states that the resistors are voltage > source impedances that define the maximum current > (ie, the quasi short circuit current that clamping > diodes would encounter). That is understood. > >> When you overshoot or undershoot, the clamp diodes >> pass current causing a voltage drop across the >> resistor resulting in a reduced voltage seen at >> the input pin. > > > Problem here is that the voltage drop depends on the input > impedance of the following buffer or hi-z value of a tri-stated > output. Given a high impedance input buffer (which is usually > the case with CMOS devices) the voltage drop would not occur > across the resistor as the relatively low output impedance of > the voltage source but the input impedance of the buffer > unless there is clamping applied. > > The point I was trying to make was that the data sheet does > not explicitly tell whether there are clamping diodes in the > 5V PCI qualified buffers or not. Since Vcco is 3.3V maximum > at the input banks at the FPGA where would the clamping diodes > go without a 5V supply given that clamping to 3.3V is impossible ? > > > Thanks & regards, > Christian Boehme >Article: 72729
Again, Spartan II is identical with Virtex, which means that the clamp diodes can be programmed. Thus the device can operate just fine in the 5V environment, and does meet the overshoot requirement of the PCI test without any concerns. The app notes deal with components that can not program the clamps, Austin Austin Lesea wrote: > All, > > You might try reading the app notes? > > http://www.xilinx.com/bvdocs/appnotes/xapp653.pdf > > http://www.xilinx.com/bvdocs/appnotes/xapp646.pdf > > Austin > > Christian E. Boehme wrote: > >> Paul Fulghum wrote: >> >>> PCI spec waveforms (+11V for overshoot, -5.5 for undershoot) >>> are specified at the resistor (55 Ohm for overshoot, >>> 25 Ohm for undershoot) that is part of the >>> test setup, not at the input pin. (section 4.2.1.3) >> >> >> >> Said section states that the resistors are voltage >> source impedances that define the maximum current >> (ie, the quasi short circuit current that clamping >> diodes would encounter). That is understood. >> >>> When you overshoot or undershoot, the clamp diodes >>> pass current causing a voltage drop across the >>> resistor resulting in a reduced voltage seen at >>> the input pin. >> >> >> >> Problem here is that the voltage drop depends on the input >> impedance of the following buffer or hi-z value of a tri-stated >> output. Given a high impedance input buffer (which is usually >> the case with CMOS devices) the voltage drop would not occur >> across the resistor as the relatively low output impedance of >> the voltage source but the input impedance of the buffer >> unless there is clamping applied. >> >> The point I was trying to make was that the data sheet does >> not explicitly tell whether there are clamping diodes in the >> 5V PCI qualified buffers or not. Since Vcco is 3.3V maximum >> at the input banks at the FPGA where would the clamping diodes >> go without a 5V supply given that clamping to 3.3V is impossible ? >> >> >> Thanks & regards, >> Christian Boehme >>Article: 72730
I am currently in a FPGA Desgin course that required us to design a 64 bit floating point multiplier. I am very new to FPGA but have experience in VHDL and computer architecture design. Can anyone recommend a good book or a technical document on this subject matter? Any personal knowledge on how to start this project is much appreciated.Article: 72731
There are some issues depending if the 'include is defined within the scope of the module or outside the scope. Managing with PAO for `include outside module boundaries may work for synthesis since all the core's HDL are bundled together into a single project file when synthesizing. However, (behavioral) simulation compiles each source file separately, so it doesn't work in the sim flow as things currently stand. As a current workaround, you can treat XST as a 3rd party synth tool executed outside platgen. Change the MPD option "OPTION IMP_NETLIST=TRUE" to FALSE. There is an app note about synplify integration into EDK. The flow is the same for XST outside of EDK. Make the appropriate subsitutions, and modify xst options where necessary to include -vlgincdir. http://www.synplicity.com/literature/syndicated/pdf/v4_i2/platform_studio_v4_i2.pdf This will allow you to run reiterations of platgen/xst without losing your synthesis options changes. You can have xst options to handle include directories. Rudolf Usselmann wrote: > However, we seem to have problems with include files. Our > cores are written in Verilog, and we don't know how to > specify the proper include path for include files. When > EDK compiles the IP Core it can not find the include files > unless we manually copy them to a local working directory. -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 72732
Paul N. wrote: > I am currently in a FPGA Desgin course that required us to design a 64 > bit floating point multiplier. I am very new to FPGA but have > experience in VHDL and computer architecture design. Can anyone > recommend a good book or a technical document on this subject matter? > Any personal knowledge on how to start this project is much > appreciated. If your taste leans more towards mathematical rigour than practical examples, the 2nd edition of Israel Cohen's "Computer Arithmetic Algorithms" is an excellent reference. The majority of the book deals with floating point algorithms, including multiply & divide etc. Don't get me wrong about the style - the information (in terms of process and design) is all there and extremely useful, but you do have to put some effort into translating the maths into usable verilog/vhdl code. Simon.Article: 72733
yudhvir@hawaii.edu (Gabru) wrote in message news:<74ac5c8c.0408282123.40a3ee3@posting.google.com>...
> Hey Guys,
>
> I have this "development Suite" and am wondering if it is worth
> anything, I'd like to sell it. If it isn't I'd like to know which
> deserving group I should donate it to. Thanks for any comments.
>
> * Nios Embedded Processor, Documentation and Reference Designs
> * Nios development Board
> - Stratix EP1S10 Device
> - One 10/100 Ethernet and One CompactFlash Connector
> - Two RS-232 Ports
> - 1-Mbyte SRAM, 16-Mbyte Single-Data Rate (SDR) SDRAM and 8-Mbyte
> Flash Memory
> - Mictor Trace/Debug Connector and Expansion Prototype Headers
> * Quartus II Design Software with SOPC Builder System Development
> Tool
> * GNUPro Toolkit: Software Development Suite
> * Power Supply and Cables
Yudhvir,
If your planning to donate the board, a university body would make
the best use of that kit. If you would like to donate it to the
University of Ottawa (Canada), that would be appreciated.
Pino
Article: 72734Simon <news@gornall.net> wrote in message news:<odOYc.180$E33.153@newsfe5-win.ntli.net>... > Paul N. wrote: > > > I am currently in a FPGA Desgin course that required us to design a 64 > > bit floating point multiplier. I am very new to FPGA but have > > experience in VHDL and computer architecture design. Can anyone > > recommend a good book or a technical document on this subject matter? > > Any personal knowledge on how to start this project is much > > appreciated. > > If your taste leans more towards mathematical rigour than practical > examples, the 2nd edition of Israel Cohen's "Computer Arithmetic > Algorithms" is an excellent reference. The majority of the book deals > with floating point algorithms, including multiply & divide etc. > > Don't get me wrong about the style - the information (in terms of > process and design) is all there and extremely useful, but you do have > to put some effort into translating the maths into usable verilog/vhdl > code. > > Simon. And on the opposite side I was almost tempted to buy a text on FPU design with all the schematics given, I forget the title, pretty much all gate level, pity its not been brought up to date in HDL. IIRC it was a German -> English book to supplement a DLX design tought in schools. I figure the math books would be more usefull so the above ref, I'll look into also. The HW books though could be usefull in covering some of the thorny details. Also most of the comp arch textbooks usually include some chapters on FPU implemention but not at the detail of either of the two extremes. You will no doubt be using ready made 18b muls so it will be interesting. Also there are some opensource designs out there, 1 at opencores.org regards johnjakson_usa_comArticle: 72735
Hi Mikhail, But timing simulation will not bring any improvement for timing closure.Article: 72736
> Hi all, > In TVPACK packing tool > http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html > three types of delays are being modelled > 1 block delay (Delay Through a BLE) = 0.1 > 2 Intracluster net delay = 0.1 > 3 Intercluster net delay = 1.0 > The above values are default values > We can also specify different values. Can someone give me an insight > bout how these values are being assigned and how 'll overall circuit > delay change by changing them.The author just says they got these > values as most suitable by experimentation. > Here is the paper describing TVPACK -> > http://www.eecg.toronto.edu/~vaughn/papers/fpga99b.pdf The values are above are estimates of the relative value of the delay through a BLE (LUT), the delay to use local routing within a cluster (LAB in Altera terminology), and the average delay to route a connection between clusters (LABs). Since placement and routing hasn't been performed yet (you're clustering the circuit before placement and routing) you can only crudely estimate the delay of a net that isn't captured within a cluster. In the equations above, it is saying that LUT delay = local routing delay inside a LAB Average routing delay for connections between LABs = 10x LUT delay. The quality of the packing you get isn't too sensitive to those parameters, so it isn't worth getting too hung up on their precise values. I would say that in modern FPGAs, the delay between clusters/LABs above is a bit too pessimistic for connections that are on or near the critical path. They probably usually get routed with a delay that is ~3X - 5X the delay of an "average" path through a LUT (each path through a LUT has a different delay, but the T-Vpack delay model doesn't take that into account). Local interconnect within a cluster is still about 1X - 1.5X the delay of an "average" path through the LUT, at least for the FPGAs I'm most familiar with. VaughnArticle: 72737
I'm installing ISE 6.1.i from the CD that comes with the SpartanIII starter kit. I get to the page that asks how I want to register: website, email, FAX. I click on email and nothing happens (I suspect it's trying to bring up a non-existant Outlook.) same with the other two options (I would't expect the website button to work either since I don't have a browser under wine). Does anyone have the email address for registering? PhilArticle: 72738
Phil Tomson <ptkwt@aracnet.com> wrote: : I'm installing ISE 6.1.i from the CD that comes with the SpartanIII : starter kit. I get to the page that asks how I want to register: website, : email, FAX. I click on email and nothing happens (I suspect it's trying : to bring up a non-existant Outlook.) same with the other two options (I : would't expect the website button to work either since I don't have a : browser under wine). : Does anyone have the email address for registering? If nobody helps you, run wine with the WINEDEBUG=+relay,+snoop, pipe to a file ( expect it to be large) and search for the API call that tries to open the Mailer. The adress should be available there. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 72739
Came accross this thread as I was looking for information regarding how and why ISE ties off the various mode inputs of the Virtex-II DCM module when it maps code originally written for Virtex-E instantiating DLL's from Unisim. In doing so the following control inputs are set: DSSEN = 1 PSINCDEC = 0 PSEN = 0 PSCLK = 0 The following "MODE tick-boxes" are set: CLKDIVIDE = 2 FACTORY_JF1 = 0XC0 FACTORY_JF2 = 0X80 DLL FREQUENCY MODE = LOW DFS FREQUENCY MODE = LOW DUTY CYCLE CORRECTION = TRUE CLKOUT PASE SHIFT = NONE CLK FEEDBACK = 1X STARTUP_WAIT = not ticked DSS_MODE = NONE CLKIN_DIVIDE_BY_2 = not ticked The question is why the DSSEN input gets tied high and what possible side effect this could have? Can we rely on the spread spectrum feature to be idle just by assigning DSS_MODE to NONE and ignore DSSEN? The problem that we are experiencing is (very) sporadic parity erors in a ZBT-SRAM interface where the RAM-clock is generated in a DCM in the Virtex-II, using the internal clock (generated in a different DCM) as a reference. All signals are completley IO-clocked and both reported and measuerd timing reveal no problems, but we still get these errors and are grasping for any possible explanation...Article: 72740
"Brad Smallridge" <bradsmallridge@dslextreme.com> writes: > Does anyone here have experience transmitting and receiving Channel Link or > Camera Link signals directly into a Virtex II Pro chip? Or into a Spartan > 3? Does it work? Supposedly the Channel Link signals are LVDS signals. > Yep, we've done that with Camera Link into a V-II (not Pro, but that shouldn't matter) There's an appnote (XAPP265) on doing (de)serialisation which as a very CameraLink looking appendix to it. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 72741
When doing behavioral simulation using modelsim 5.8b SE version for rocket io i am getting the warning as # No default binding for component 'gt_fibre_channel_4'(no entity gt_fibre_channel) was found. and all the outputs of mgt are having the value 'U'.Article: 72742
> Does anyone have the email address for registering? You can register it at http://support.xilinx.com/swreg.htm HTH, Jim (jimwu88NOOOSPAM@yahoo.com remove NOOOSPAM) http://www.geocities.com/jimwu88/chipsArticle: 72743
> But timing simulation will not bring any improvement for timing closure. It will not bring improvements in itself, but it will hopefully show where and why your design fails to meet your timing requirements and as a result you might be able to fix the problem much faster and cheaper. /MikhailArticle: 72744
To the Newsgroup, I answered Lars personally, but it looks like this may be a mapping bug from the older DLL primitive to the newer DCM. I have entered it into the hotline for study. There are a number of control signals to the DSS block: DSSEN, as well as the number of tap jumps (1,3 or 5) which are set by memory cells. The FPGA editor maps these into a form that is 'easy' to see (but not actually what the cell is doing). Best to use the new primitives, rather than rely on the proper mapping of older primitives when in doubt. Austin Lars Theodorsson wrote: > Came accross this thread as I was looking for information regarding how and why > ISE ties off the various mode inputs of the Virtex-II DCM module when it maps > code originally written for Virtex-E instantiating DLL's from Unisim. In doing > so the following control inputs are set: > > DSSEN = 1 > PSINCDEC = 0 > PSEN = 0 > PSCLK = 0 > > The following "MODE tick-boxes" are set: > > CLKDIVIDE = 2 > FACTORY_JF1 = 0XC0 > FACTORY_JF2 = 0X80 > DLL FREQUENCY MODE = LOW > DFS FREQUENCY MODE = LOW > DUTY CYCLE CORRECTION = TRUE > CLKOUT PASE SHIFT = NONE > CLK FEEDBACK = 1X > STARTUP_WAIT = not ticked > DSS_MODE = NONE > CLKIN_DIVIDE_BY_2 = not ticked > > The question is why the DSSEN input gets tied high and what possible side effect > this could have? Can we rely on the spread spectrum feature to be idle just by > assigning DSS_MODE to NONE and ignore DSSEN? > > The problem that we are experiencing is (very) sporadic parity erors in a ZBT-SRAM > interface where the RAM-clock is generated in a DCM in the Virtex-II, using the > internal clock (generated in a different DCM) as a reference. All signals are > completley IO-clocked and both reported and measuerd timing reveal no problems, > but we still get these errors and are grasping for any possible explanation...Article: 72745
shalini wrote: > When doing behavioral simulation using modelsim 5.8b SE version for > rocket io > i am getting the warning as > # No default binding for component 'gt_fibre_channel_4'(no entity > gt_fibre_channel) was found. A default binding means that the component AND the entity AND the instance code all use the same identifier 'gt_fibre_channel_4' and all are compiled and in scope. A vhdl configuration is an alternative to a default binding. Good luck. -- Mike TreselerArticle: 72746
our internet site now includes a link-list to FPGA related topics / sites. see: http://www.seng.de/dlk_database.html inputs to links that should be added are welcome ! Links for AVR and 8051 users are also included. with best regards, Peter Seng ############################# SENG digitale Systeme GmbH Im Bruckwasen 35 D 73037 Goeppingen Germany tel +7161-75245 fax +7161-72965 eMail p.seng@seng.de net http://www.seng.de #############################Article: 72747
I'm one of that "old" engineer with a bit of experience on ISA bus cards. Over the years I've designed and manufactured various cards for the ISA bus. But as the technology runs faster than I'm, my good-old cards become obsolete. I would like to ask what would be the simplest way of learning and experimenting on PCI bus ?Article: 72748
Is there any documentation on this block besides the vague description in Quartus Help ??? I tried simulating it but that didn't work. I donno how to use this megafunction properly... PS this is the 3rd time I face Altera's bad/none documentation for advertised features (High Speed SERDES Transceivers) which are ONLY accessible through megafunctionsArticle: 72749
Hi, I'm assuming you are interested in implementing your PCI interfaces in an FPGA because you posted to this newsgroup. As for learning about PCI, you can buy the PCI System Architecture book by Mindshare. That's a good book, especially if you don't have a copy of the spec itself. If you can get a copy of the spec, that's an added bonus. Check out http://www.pcisig.com Also, Xilinx offers PCI and PCI-X classes through the Customer Education group. If you are willing and able to enroll, they are not free but I think a great value. As for experimentation, you have a lot of options. It comes down to finding hardware you like and can afford. For example, several Xilinx distributors sell low cost (less than $500) PCI prototyping boards. You can also get one from http://www.fpga4fun.com for less than $300. If you have easy access to manufacturing and assembly, and want to build a batch of boards for a project, try http://www.engr.sjsu.edu/crabill/projects/nxm/readme.htm To use the hardware, you'll need the logic for a PCI interface. You can buy one from Xilinx, other vendors have similar products. You can write your own from the spec. I think there are some people on this newsgroup that have written their own and sell it. Also, there is http://www.opencores.org which has a PCI interface. Finally, you will need some kind of software tools to write a device driver. Perhaps someone else can give some recommendations on this topic. Good luck, Eric > I'm one of that "old" engineer with a bit of > experience on ISA bus cards. Over the years > I've designed and manufactured various cards > for the ISA bus. But as the technology runs > faster than I'm, my good-old cards become > obsolete. > > I would like to ask what would be the simplest > way of learning and experimenting on PCI bus ?
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