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
> Can the phase shift be "wrapped around" such that decrementing past -255 > ends up back at zero? Nope, at least not on the XC2V1000 ES I have. Variable phase works, but does not wrap. The errata sheet says that variable phase shift is not available in the ES parts. Maybe because of the wrap??? BryanArticle: 35001
Sebastian, For pre-synthesis functional simulation you must use the unisim VHDL library. Catalin Baetoniu Sebastian wrote: > That's clear to me. If i simulate after synthesis, the special components > can be simulated. This simulation however, is too far in the end of the > chain. I want to verify/correct my vhdl more quickly. > > I think i need functional models of the components, or something. > > regards, > Sebastian > > "Jens-Christian Lache" <lache@tu-harburg.de_removeTheUnderscore> wrote in > message news:3BA5F15E.1C5A1E7C@tu-harburg.de_removeTheUnderscore... > > Sebastian wrote: > > > > > How to simulate the FPGA's special feature 'components' (such as > embedded > > > multipliers and on-chip memory)? > > > > In the thread "using BlockRam" started on friday is some code included > which > > > > shows how to use BlockRAM of a spartan-II. (In the message I posted this > > morning) I suppose its similar to the virtex. If you have your design > > syntethized, you can simulate it using a stimuli file, for example: > > > > restart | ******* RESTART ******* > > delete_signals > > stepsize 5.0ns > > clock clock 1 0 > > watch N_clock > > vector address_ address[9:0] > > assign address_ 00\h > > vector N_address_ N_address[9:0] > > vector dq_ dq[15:0] > > assign dq_ 00\h > > vector N_dq_ N_dq[15:0] > > vector dqOut_ dqOut[63:0] > > vector N_dqOut N_dqOut[63:0] > > |vector ram0 ram0.DO[15:0] > > |vector ram1 ram1.DO[15:0] > > |vector ram2 ram2.DO[15:0] > > |vector ram3 ram3.DO[15:0] > > watch N138 > > watch N138_BUFGed > > watch n_24 > > watch n_5 > > watch n_43 > > watch n_61 > > watch GND > > watch GTS > > assign enable 0 > > watch N_enable > > assign writeEnable 0 > > watch N_writeEnable > > assign reset 0 > > > > Look on the web side from xilinx for app notes! You'll probably find s.th. > > about memory. Keep in mind, that there is a big difference between > > "simulation" and "verification", although you can use the same stimuli > > file. As long as you just simulate your design, the VHDL world is fine, > > to understand the verification output you need a lot more knowledge > > about the gate arry. > > > > Hope that helps, I am a newby (as well (?)). Good luck! > > > > -jc- > >Article: 35002
Bryan, No. There is no wrap. The sticking variable phase shift was a synchronizer design error caught in the lab, and fixed in subsequent tape outs. Austin Bryan wrote: > > Can the phase shift be "wrapped around" such that decrementing past -255 > > ends up back at zero? > > Nope, at least not on the XC2V1000 ES I have. Variable phase works, but > does not wrap. The errata sheet says that variable phase shift is not > available in the ES parts. Maybe because of the wrap??? > > BryanArticle: 35003
Michael Strayer wrote: > > Hello, > I'm trying to use Xilinx's Webpack software to implement > a design on a Spartan II. Part the the design is a bitclock > generator that divides the system clock down to two other > freq's. When I try to use these clocks in other parts of the > design Webpack complains that I am routing clocks using > non-dedicated resources. > > I've read the section in the online help about assigning > signals to global clock buffers using the attribute statement > but when I try this I get a message stating the BUFG is an unknown > attribute. > > How do I go about assigning an internally generated signal to > a global clock net?? In schematic, place an BUFG element. Synthesis tools (Synplify and Leonardo) should infer the BUFG and do the right thing. =aArticle: 35004
Hi Michael, What Tim is referring to as the "real man" version of Foundation is Foundation Elite, as opposed to what you are using which seems to be Foundation Express. Express allows you to target Virtex-E devices up to an XCV1000E, while Elite allows you to target all devices in the family (and all other families). What you'll need to do is upgrade your license to the Elite version to target the XCV1600E. I hope this helps. Best regards, Kamal Patel For more info Michael Boehnel wrote: > Are there really two different Foundation versions? What is the name of this > "real man" :-) version? > > MichaelArticle: 35005
Nicolas Matringe wrote: > I don't remember of Rick speaking french... I suppose my english is > better than his french :o) > Hi Nicolas, Joking apart your English is very much better than my out of practice French, esp written, but also if you remember when I visited (you were still DotCom then) I was with another colleague who doesn't speak it and also hates not knowing what's going on! Its that famous English politeness again :o) I must admit to enjoying the French words & phrases appearing from my keyboard, all I have to do now is figure out how to get the accent marks.Article: 35006
Michael Boehnel wrote: > Are there really two different Foundation versions? What is the name of this > "real man" :-) version? > > Michael I think it used to called some pompous marketing title like ``Elite Edition''. With the new 4.1i tools all Virtex/Virtex-E/Virtex-2 devices are supported by the standard Alliance/Foundation release (or so I've been told). The only s/w package distinction is whether or not you have the FPGA-Express synth tool. If you are ``in maintenance'' you should get 4.1i as an upgrade.Article: 35007
Austin Lesea wrote: > Rick, > > The 2V3000, 2V1000, and 2V6000 are are available in the sample material > right now. > > We chose the release the parts such that for development, one could start > with the 2V3000, and drop into the smaller parts for production. The > packaging roadmap ensures compatibility. > I suppose that makes sense but in my situation what I need is the XC2V1000 as a standard part but the XC2V1500 in the same package for the extra pins needed to support an alternative CPU with a very wide demuxed bus. > > And now for my own little comment: > > The 2V40 is also available. Poor little 2V40, all but ignored as its > larger cousins are passing it by. The 2V40 costs less than the "robot > clock" chips, and does a heck of a lot lot more. Anyone need variable > phase shift, fixed phase shift, skew management, multiple skew and duty > cycle corrected clock output driver that is programmable? > One of the little problems might be needing a $12 EEPROM for a $30 FPGA [24-off prices from the NuHorizons site]. If Xilinx could apply to the serial PROMs the same bang/buck technology that's moved us from the 3K series to Virtex-2 ...Article: 35008
Rick, We are working on it (both, in fact). Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > Rick, > > > > The 2V3000, 2V1000, and 2V6000 are are available in the sample material > > right now. > > > > We chose the release the parts such that for development, one could start > > with the 2V3000, and drop into the smaller parts for production. The > > packaging roadmap ensures compatibility. > > > > I suppose that makes sense but in my situation what I need is the XC2V1000 as > a standard part but the XC2V1500 in the same package for the extra pins > needed to support an alternative CPU with a very wide demuxed bus. > > > > > And now for my own little comment: > > > > The 2V40 is also available. Poor little 2V40, all but ignored as its > > larger cousins are passing it by. The 2V40 costs less than the "robot > > clock" chips, and does a heck of a lot lot more. Anyone need variable > > phase shift, fixed phase shift, skew management, multiple skew and duty > > cycle corrected clock output driver that is programmable? > > > > One of the little problems might be needing a $12 EEPROM for a $30 FPGA > [24-off prices from the NuHorizons site]. If Xilinx could apply to the serial > PROMs the same bang/buck technology that's moved us from the 3K series to > Virtex-2 ...Article: 35009
Hi everybody! I'm using the Quartus II 1.1 for designing with a APEX 20KE. The VHDL code (i.e. State-Machines) I generated with Mentor Graphics HDL Designer Series Pro. Now I tried to simulate my target device within the Quartus Software. The result was kind of frustrating: Signals I asserted in the same state of a state machine clocked with 133MHz had an output skew of more than 3ns (and these signals should have a setup and hold relationship to the corresponding clock signal of 1 ns as they are the command bits of a DDR SDRAM). After looking at the (in my opinion quite poor) online documentation, I know that there are different ways of "grouping" signals or logic together to reduce such skew or to accelerate the whole design, but so far I tried and had no real success. Does anyone know how to correct these problems? Also I detected strange flickerings at some signals with a frequency of more than 1.1GHz and a duty cycle of 25%. Where do these come from? I use signal frequencies of 33MHz and multiples of 2x, 4x and 8x (only on internal signals), but I don't think they have a relation to these flickering. Or can I ignore that problem? But it seems to me as if the simulation is quite exactly and the problems would occur in the chip also. Thanks, RafaelArticle: 35010
Rick Filipkiewicz wrote: > > One of the little problems might be needing a $12 EEPROM for a $30 FPGA > [24-off prices from the NuHorizons site]. If Xilinx could apply to the serial > PROMs the same bang/buck technology that's moved us from the 3K series to > Virtex-2 ... I really agree. That's the most annoying part about the xilinx FPGAs. Like DEC alpha running on core memory ;-) cheersArticle: 35011
lennart wrote: > > why do you invert the clock signal? It looks like causes a great deal of delay. Clock inversions should be taken care of by muxes in front of the various clock destinations, and incur no extra delay. -aArticle: 35012
Paul wrote: > > Hi, > > I'm trying to do my first examples with FPGA's and I am running into > some problems with a Xilinx VirtexE in a demo board. > > I want to make a counter and to display the count in a 7-segment > display of the board. The clock for this counter schould be a > press-button of the board. The problem is that the button is > physically connected to the pin P95 of th FPGA and the Xilinx tool > (ISE 3.1) doesn't allow me to place this input signal in this pin. If > I constrain this signal to this pin I get the following error: > > ERROR:MapLib:93 - Illegal LOC on symbol "clk.PAD" (pad signal=clk) or > BUFGP > symbol "clk_BUFGP" (output signal=clk_BUFGP), IPAD-IBUFG should > only be LOCed > to GCLKIOB site. > > I guess that it is not possible to chose whatever pin for a clock > signal, but since this button is physicaly conected to this pin, i can > not change it. > > How could I overcome this? Perhaps, instead of using the pushbutton to toggle the counter's clock (which, IMHO, is a bad idea), why not use the oscillator that I imagine is connected to a clock pin as your FPGA's global clock, and code up some logic that looks for a change in state on the pushbutton's input pin? Once you see that change in state, you know that you should update the counter. This is all covered in any basic text in Synchronous Logic 101. --aArticle: 35013
Dave Colson wrote: > Also, is FPGA Express "crippled" like ModelSim is i.e. intentionally > made slow. It > takes 30 mins. to do a synthesis on a Spartan II 150. XST only take s > couple of mins. FPGA Express is crippled, but not intentionally...Article: 35014
Dear SoC Professionals, Please join the VSI Alliance at our USA Member Meeting, October 1, 2001, in San Jose, Calif. at the Communications Design Conference. The Keynote Speaker is Augusto DeOliviera - VP of System ASIC Technology at Philips Semiconductors. He will discuss the issues of SoC and platform development with emphasis on the need for embedded software reuse in the specification, design, verification and test of these leading-edge semiconductor devices. A Panel Discussion on SoC embedded software issues will follow as well as an update on VSIA's Verification Development Working Group (DWG) and details of the new Test Access Standard for SoC. Please register for this important meeting at: www.vsi.org. 1:30 - 5:30 pm at the San Jose Convention Center, Room J2. Registration opens at 12:30. A cocktail reception follows the meeting, which is open and free to all! Stan Baker, Executive Director, VSI AllianceArticle: 35015
I'm not sure you answered Ray's question. Are the pins you're seeing the glitches on connected to flip-flop outputs, or are they connected to some combinatorial function? -a Paul McCallion wrote: > > They are being driven by combinatorial logic, but are driving flip-flops. > > Ray Andraka <ray@andraka.com> wrote in message news:<3B99677B.4D6262DE@andraka.com>... > > What is driving the outputs? Are they being driven directly by > > flip-flops (as opposed to combinatorial logic or tristates)? > > > > Paul McCallion wrote: > > > > > Hi, > > > Has anyone seen any glitch problems with Actel's A42MX series? I have > > > seen 10nS glitches on outputs for several minutes after power on and > > > with the application of freezer spray to the FPGA. > > > > > > PaulArticle: 35016
I got the kit with epm7064 device, CD, and byteblaster a couple of days ago (three months after doing the survey). Was there an acex survey? Jon wrote: > > Of those who took the trouble to take part in their survey some months ago > how many of you actually got the promised Acex evaluation board ? > > JonArticle: 35017
Thanks to all for the explanation. Best Regards MichaelArticle: 35018
Hy Ray, again some question, some mounth ago, I ask to you about what's better for a Cordic NCO, to start with I = 1 and Q = 0 or to start with I = 0.60725 and Q = 0 , you suggest me this second option, I implement both and in the first case I have SFDR = 65dBc and in the second case instead I've SFDR = 58dBc but I can also avoid using the two multipliers to reduce the result, You suggest me to use the second configuration with 15 bits then truncated to 12 but I'm implementing an Unrolled Cordic, this means that I've to use all adders at 15 bits inputs instead of 12 and just truncate at the output of the COrdic ?? Thanks ... Antonio D'OttavioArticle: 35019
rafael plonka <rafael.plonka@gmx.de> wrote in message news:<3BA66964.4EF25F1D@gmx.de>... > Hi everybody! > > I'm using the Quartus II 1.1 for designing with a APEX 20KE. The VHDL > code (i.e. State-Machines) I generated with Mentor Graphics HDL Designer > Series Pro. Now I tried to simulate my target device within the Quartus > Software. The result was kind of frustrating: Signals I asserted in the > same state of a state machine clocked with 133MHz had an output skew of > more than 3ns (and these signals should have a setup and hold > relationship to the corresponding clock signal of 1 ns as they are the > command bits of a DDR SDRAM). After looking at the (in my opinion quite > poor) online documentation, I know that there are different ways of > "grouping" signals or logic together to reduce such skew or to > accelerate the whole design, but so far I tried and had no real success. Have yo tried to code your FSM as "one-hot" ? Have you specified FSM clock as a "global clock" ? Finally, may be that registering the outputs showing the worst skew could reduce it. > Does anyone know how to correct these problems? Also I detected strange > flickerings at some signals with a frequency of more than 1.1GHz and a > duty cycle of 25%. Where do these come from? I remember a latch, in my simulation, showing the same high frequency oscillation due to a glitch on its input. This glitch, fedback by the latch's combinatorial logic, started an unwanted oscillation. I have replaced it with a flip-flop. ByeArticle: 35020
Note. all of the following problems are regarded by myself as the bugs
brought about by the software because I could not fix them after a
long-time efforts. Any discussion is welcome. Please feel free to
contact me! My available email: slash11@263.net. Thanks in advance!!!
1.Does anybody who is using HDL Design Series developed by Mentor
Graphics face the following case? I encounter it recently.
I once tried to call megafunction wizard in HDS directly. However,
in many cases, I was informed that a file (named rtl.vhd) could not be
imported successfully. Actually, I can not find such a file in the
file list generated by Megafuntion wizard when it's invoked in Quartus
II enviornment. It causes the fail to import lpm directly in HDS
enviornment. Therefore, the only way is to invoke megafunction wizard
seperately in Quartus II, then import the generated files into HDS by
the "HDL import" feature.
I think rtl.vhd is just a temporary file and removed after the lpm
is generated. Just for this, I regard it's a bug of HDS.
Maybe, someone will suggest me to instance lpm by using the lpm
library that is available in HDS. I have tried it. However, do you
think it's a good way for you to configurate the lpm module when there
are many parameter should be defined? I don't think so. Frankly, I try
this way as well. However, other problem appears. It's described in 2.
2.Does anybody who once instantiated the lpm_counter of Altera find
there is some bug with the lpm model? I got some problems.
Just for the above reason, I should instatiate the lpm_counter in
the following steps.
i. Invoke Quartus II, and run Mega-Function Wizard.
ii. Check the type of the output files "VHDL" and module
"lpm_counter".
iii. Configurate the lpm_counter, then generated the required VHD
file at the finalization of the whole process
iv. Invoke HDS and import the VHD file (counter.vhd)
v. After the HDS generated HDL files, the previous imported file
was modified by HDS.
vi. Invoke Active-hdl (or Modelsim) to simulate the regenerated file
(counter.vhd). The problem is revealed. The counter doesn't output
anything!!!!!!! Trace back to the regenerated file (counte.vhd).
No reason!! I tried to remove unused port declaration and rerun
the simulation. Then, the counter began working!!! So strange!!!
3.Does anybody who once instantiated the lpm_compare of Altera find
there is some bug with the mega-function wizard of Quartus II 1.1? I
got some too.
Likewise, I instantiate lpm_compare.
dataa and datab is the two inputs of this lpm module. And the dataa
is fixed to constant, which means the data on datab port will be
compared to this constant. In mega-function wizard of Quartus II 1.1.
I was required to assign the constant that is needed to be input in
binary. I fix it in "10101010". However, in the generated file,
compare.vhd, the constant is changed by mega-function wizard. Of
course, this causes the fail of simulation. With respect to this, I
regard it's the bug of mega-function wizard.
Article: 35021Andy Peters wrote: > lennart wrote: > > > > why do you invert the clock signal? It looks like causes a great deal of delay. > > Clock inversions should be taken care of by muxes in front of the > various clock destinations, and incur no extra delay. > > -a The clock invertion I used in my code to ensure t_BACK and t_BDCK turned out to be unnecessary. These parameters must be stored in the library, the implementaion stage takes them into account and triggers the BlockRAM on the falling edge ANYWAY. It takes 22,5 ns for a read, until the data is stable on the pad: 1 ns route (input) 4 ns until the falling edge 10 ns SRAM delay 7,5 ns t_BCKO + 1 ns route + IOB to pad delay (t_IOOP) (Or s.th. like that. I don't get why there is no equivialent to t_IOOP on the input side of the SRAM, but thats how the verification looked like) This leaves me 7.5 ns to meet the SDRAM timings... I can do it maybe. Thanks for your help! -jc-Article: 35022
I am looking to prototype a 40K Spartan 240 pin 5v part, so far I have
managed to find a APS-X240 development board, are these boards ok ? or
are there better alternatives out there?
Thanks
Jas
Article: 35023Hi All, I am having a problem with Synplify inferring BUFG cells when it has actually run out of BUFGs to add. In this case, I am using Synplify 6.1.3 and have instantiated a BUFGDLL and a single BUFG. Obviously this takes up 2 of the 4 BUFGs in the Virtex2E that I'm using, but then Synplify infers 3 more BUFGs as it decides that I have only instantiated 1 BUFG in my code. I have tried usign Synplify 6.2.4 but that actually synthesises some of my logic incorrectly. Is this BUFG problem a bug with Synplify 6.1.3 or can Synplify just not count to 4 properly? Has anyone else had this problem? Cheers, RichArticle: 35024
Have you try to make timing assignments for your IO pins with the assignment organizer (Tools Menu). You should also use the FastIO register (1 Fast IO register available per pin)which improve tco, tsu of your IO pins. I met these timing problems because i have designed an SDRAM Controler in an Apex20KE. -- Jean Baptiste MONNARD Ingénieur HorizonTechnologies 01 60 92 10 15 "rafael plonka" <rafael.plonka@gmx.de> a écrit dans le message news: 3BA66964.4EF25F1D@gmx.de... > Hi everybody! > > I'm using the Quartus II 1.1 for designing with a APEX 20KE. The VHDL > code (i.e. State-Machines) I generated with Mentor Graphics HDL Designer > Series Pro. Now I tried to simulate my target device within the Quartus > Software. The result was kind of frustrating: Signals I asserted in the > same state of a state machine clocked with 133MHz had an output skew of > more than 3ns (and these signals should have a setup and hold > relationship to the corresponding clock signal of 1 ns as they are the > command bits of a DDR SDRAM). After looking at the (in my opinion quite > poor) online documentation, I know that there are different ways of > "grouping" signals or logic together to reduce such skew or to > accelerate the whole design, but so far I tried and had no real success. > Does anyone know how to correct these problems? Also I detected strange > flickerings at some signals with a frequency of more than 1.1GHz and a > duty cycle of 25%. Where do these come from? I use signal frequencies of > 33MHz and multiples of 2x, 4x and 8x (only on internal signals), but I > don't think they have a relation to these flickering. Or can I ignore > that problem? But it seems to me as if the simulation is quite exactly > and the problems would occur in the chip also. > > Thanks, > > Rafael >
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