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
"Robert Sefton" <rsefton@abc.net> wrote in message news:2qott4F12cbadU1@uni-berlin.de... [snip] > I'm open to any and all ideas, but I can't speed up the PowerPC so Spartan-3 > looks like > a no-go on this one. > > Thanks, > Rob My 133MHz PowerPC interface hasn't been in a Spartan-3 yet but was readily implemented in the Spartan-IIE. Being the second of 2 masters interfacing to a bridge (the first is the processor), the timing was aggressive considering the complexity in a qualified bus grant. To get around the need to come in, go through logic, and go out with only one register in the path, I leveraged the FDSE primitives in the IOBs to turn the tristates on and off with the exceptionally low delays. I had the advantage of DMAs going only into the chip - I'm thinking DMAs back out would be troublesome for the 133 MHz speeds. A reconfiguration of the interface might get your bus control to behave much better with the Spartan-3 I/O timings. Another trick that I've used... if delaying the clock would help but the DCM is unavailable, add another clock buffer in the clock path. Controlling the routing to the same or opposite sides of the chip will give slightly different times. Since routing delays tend to track faster/slower with the rest of the chip, I wasn't too concerned about just "adding delays" to improve my timing.Article: 73151
"Arthur" <arthuryang42spam@yahoo.com> wrote in message news:<chlf2p$rdm@odak26.prod.google.com>... > Mukesh, > > Try running 'clean up project files' from ISE then delete any .XML > files that may be remaining in that project directory. The .XML file > contains toggle and frequency data and can conflict with the VCD > simulation file if they don't happen to target the same device. (For > example, you target a Spartan-IIe then save the settings file and then > retarget to Virtex-II and accidentally load the .XML file for the > Spartan-IIe design) > > If that doesn't help, send the design into Xilinx for analysis. They > can take a look at it and let you know what the problem is. > Regards, > Arthur Hi Arthur, Thanks for the response, I tried cleaning up as per your suggestion but that didnt help. -- MukeshArticle: 73152
> > > Several times in the past I bumped into the 8 global clocks limitation on > > Virtex II. That's why I was very exited to hear that I can use up to 32 > > global clocks, but after reading the Virtex 4 User's guide (page 21) my > > excitement cooled down a bit. There is a statement: "However, only eight > > different clocks can be driven in a single clock region. A clock region is a > > branch of the clock tree consisting of eight CLB rows up and eight CLB rows > > down. A clock region only spans halfway across the device." > > If I understand this correctly, there is still a limitation of 8 global > > clocks per device, that means max. of 8 different and completely unrelated > > clocks can be used in all regions of the chip? Please, tell me I'm wrong? ;) Actually you are wrong. Virtex 4 has several different clock regions. An LX25 for example has 12 different clock regions. Each of those 12 clock regions can only get 8 global clocks, but those 8 clocks in each of those 12 regions can come from any of the 32 global clock buffers. Plus you also get 2 regional clocks in each clock region for Source-Synchronous type applications. Enjoy, - VicArticle: 73153
Austin Lesea wrote: (snip regarding 32 global clocks in four regions) > Sorry, you are correct. Eight clocks per region. I don't understand > why folks want so many different clocks-- ever heard of synchronous > design? Regions are smaller than they used to be (smaller than > quadrants) so having different clocks for different regions still allows > a real nightmare of asynchonous clock designs. A large number of clocks doesn't preclude a synchronous design, but I have to agree that more than eight should be pretty unusual. (There were some designs discussed recently that used multiple phase clocks, all from the same clock generator. That could still qualify as a synchronous design.) It would be interesting, though, similar to the way register windows work on the SPARC processor, to have some clock inputs global across the chip, some overlap in different combinations, and the rest local to a region. -- glenArticle: 73154
> Indeed, when I saw that there are 32 global clocks in V4, my heart sank. > Unlike Igor, I'm sick and tired of fixing shoddy designs that are the result > of inexperienced designers throwing as many clocks as possible at their > designs. Go synchronous, young man! > Cheers, Syms. Part of the reasoning behind having 32 global clock buffers is that customers may want to route other high fanout nets such as resets and clock enables on global clock buffers. (The value of this depends on your design style ofcourse) - VicArticle: 73155
There are lots of situations where you need multiple clocks. If you are interfacing to a number of devices that each have their own clock you need a separate clock for each of them. Even if the devices are all using the same source clock their output clocks (for clock forwarded interfaces) are all phase shifted by an indeterminate amount so they have to be treated as asynchronous. I typically capture each device's data in an async FIFO and then transfer it into a primary clock domain. The great majority of the slices are in the primary domain so the device is mostly synchronous but there is still a need for a large number of clocks.Article: 73156
Hi Vic, So you can route clock enables on these V4 global nets? That'd be good. As for resets, fair enough, provided you're not talking about asynchronous ones! cheers, Syms. "Vic Vadi" <vic.vadi@xilinx.com> wrote in message news:4147858D.C40A8281@xilinx.com... > > Indeed, when I saw that there are 32 global clocks in V4, my heart sank. > > Unlike Igor, I'm sick and tired of fixing shoddy designs that are the result > > of inexperienced designers throwing as many clocks as possible at their > > designs. Go synchronous, young man! > > Cheers, Syms. > > Part of the reasoning behind having 32 global clock buffers is that > customers may want to route other high fanout nets such as resets > and clock enables on global clock buffers. (The value of this > depends on your design style ofcourse) > > - Vic >Article: 73157
Hi Kranthi,
I have used the student edition (a prior version) a long time
ago and in my opinion webpack seems better. It does support some
devices even upto Virtex II, some of the Spartan and all of the CPLD
devices. You can simulate your design (ships with Modelsim from
Mentor), sythesize your design, perform post synthesys simulations
(similar to back-annotation), floorplan and come out with the
configuration bit files. One good feature with this is that you can
generate simulation vectors graphically and internally it generates
the test bench for you. Try it!!
Good luck,
Digvijay.
kranthi_q@graffiti.net (Kranthi Q) wrote in message news:<ecef0ac4.0409131011.4243433@posting.google.com>...
> Hi,
>
> I want to learn to use the Xilinx Software and was wondering which one to download..
>
> What is the difference between Xilinx Student Edition 4.2i and Xilinx webpack??
>
> which is better to download??? and How are they and what do they offer??
>
> I am new to this and would appreciate the help!!!
>
> Thank you.
>
> Kranthi.
Article: 73158Vic Vadi wrote: >>>Several times in the past I bumped into the 8 global clocks limitation on >>>Virtex II. That's why I was very exited to hear that I can use up to 32 >>>global clocks, but after reading the Virtex 4 User's guide (page 21) my >>>excitement cooled down a bit. There is a statement: "However, only eight >>>different clocks can be driven in a single clock region. A clock region is a >>>branch of the clock tree consisting of eight CLB rows up and eight CLB rows >>>down. A clock region only spans halfway across the device." >>>If I understand this correctly, there is still a limitation of 8 global >>>clocks per device, that means max. of 8 different and completely unrelated >>>clocks can be used in all regions of the chip? Please, tell me I'm wrong? ;) > > > Actually you are wrong. Virtex 4 has several different clock regions. > An LX25 for example has 12 different clock regions. Each of those > 12 clock regions can only get 8 global clocks, but those 8 clocks > in each of those 12 regions can come from any of the 32 > global clock buffers. Plus you also get 2 regional clocks in each > clock region for Source-Synchronous type applications. So, supposing someone wants to create a 'phased array' of clocks, to push their time-resolution well below the 1/clock, ( as in other threads ) what is the practical limit in Virtex-4, for the number of DCM controled phases that can be generated, AND dispersed thru the chip ? ( IIRC earlier DCM's had just 4 phases ). Can each of the 32 global clock buffers be driven to +1/32 phase advance, for example ? -jgArticle: 73159
"Austin Lesea" <austin@xilinx.com> wrote in message news:ci4p3r$imf1@cliff.xsj.xilinx.com... > All, > > As Peter would say, the teasing is over: V4 is ALIVE. > > http://www.xilinx.com for all of the details. > > Now I can finally talk about it. > > Austin Any ideas if the V2 rocket MGTs are any better ? int terms of tolerance to lock freq ppm window and to be able to support more standards? AnttiArticle: 73160
"John_H" <johnhandwork@mail.com> wrote in message news:xUK1d.9$l1.933@news-west.eli.net... > > My 133MHz PowerPC interface hasn't been in a Spartan-3 yet but was readily > implemented in the Spartan-IIE. Being the second of 2 masters interfacing > to a bridge (the first is the processor), the timing was aggressive > considering the complexity in a qualified bus grant. To get around the > need > to come in, go through logic, and go out with only one register in the > path, > I leveraged the FDSE primitives in the IOBs to turn the tristates on and > off > with the exceptionally low delays. I had the advantage of DMAs going only > into the chip - I'm thinking DMAs back out would be troublesome for the > 133 > MHz speeds. > > A reconfiguration of the interface might get your bus control to behave > much > better with the Spartan-3 I/O timings. > > Another trick that I've used... if delaying the clock would help but the > DCM > is unavailable, add another clock buffer in the clock path. Controlling > the > routing to the same or opposite sides of the chip will give slightly > different times. Since routing delays tend to track faster/slower with > the > rest of the chip, I wasn't too concerned about just "adding delays" to > improve my timing. > Thanks for the ideas. I have three masters in the FPGA, and each master supports four DMA functions, so there are a total of 12 DMA channels. Plus the MPC8250 uses GPCM accesses on the 60X bus to access internal FPGA registers. Lot's of logic hanging off the critical nets. The MPC8250 has dedicated br-/bg-/dbg- lines for each master, but abb-, dbb-, psdval-, etc., are shared. I am using the DCM, but shifting the clock won't help because there are output paths that are just as critical. One upside with the Spartan-3 is that the S-3 1000 has almost 50% more logic (LUTs and FFs) than the V-2 1000. So I have more headroom there. Now that I've accepted the I/O timing situation and stopped being pissed about it maybe I can find a way to make it work.Article: 73161
Javier Castillo <jcastillo@opensocdesign.com> wrote in message news:<Xns95647797DF637jcastilloopensocdesi@193.147.184.15>... Hi Javier, please see by comments below. > I dont want to have a discussion about what is better, because is obvious > that actually Verilog or VHDL are more mature HDLs and SystemC is a newbie. > The thing I want to transmit is that systemC can be used for RT design with > its current limitations. I say current because the SystemC Synthesis > Working Group is working in improve the SystemC capabilities in order to > make SystemC a RT solution as Verilog is. I am convinced that it is possible to develop RTL using SystemC. More than that, I am also convinced that, with some efforts, it will be possible to develop RTL using Perl or any other language. The question will be: how easy will be to sell it to designers. Working Group effors are not sufficient to make SystemC a RTL Solution as Verilog is. It is about the whole chip design infrastructure. It took decades of common effort to bring Verilog-based design infrastructure to the current level. Then, the trend as I see is to reduce, but not increase the number of RTL languages. SystemVerilog is targeting this goal, inheriting most of useful RTL constructs from VHDL. In fact, there is no value to express the same design intent in different languages. As long as single language allows designers to express all he/she needs, there is no need for another one. > About your comments, I am agree in some of them because is obvious that > tools have a Verilog input and doesnt support SystemC. This Verilog input > is the reason to make a translation of the SystemC code, but I expect the > EDA suppliers will add SystemC support in their products. EDA suppliers will add SystemC support only if there will be business case for it. Business case will be developed if designers will be willing to pay money for the ability to develop RTL with SystemC. It may not happen in the nearest feature. > But I am not agree in other things, for example when you said: > > > In addition to design, I also doubt that SystemC is a good choise for > > the whole verification environment. For the system-level verification, > > it is a good choise since it allows seamless interoperability with the > > software. For the functional verification, verification-specific > > languages (HVL)or SystemVerilog would be much better choise. > > Functional verification requires advanced coverage, random generation, > > assertion support as well as may other items such as random stability > > etc. I doubt that SystemC has similar capabilities comparing to HVLs > > or SV. > > One of the strongest features of SystemC is the verification capabilities. > The SystemC Verification Library provides random generation, transaction > recording and many other features. Assertion or advance coverage is not > possible, the only thing you can do is a line coverage metric using GNU > gcov program. But as I said I expect EDA vendors will supply a SystemC > front end in their products. SystemC has good enough support for transaction-based, system-level verification. It does not have almost any support for cycle-precised verification, such as sequences, properties, assertions, coverage constructs etc. This is natural, since SystemC, according to it's name, targets system-level modeling and verification. Regards, Alexander GnusinArticle: 73162
Hi Philip, "Philip Freidin" <philip@fliptronics.com> wrote in message news:givdk0te05fhs3jaoet64tfqv2edeul24q@4ax.com... > Hi Austin, > As I shake my head in wonderment reading your post, I think to myself > (and not for the first time :-) > > "Self, isn't it great that all the really crazy clients end up in > Austin's bucket" It's not a client, it's a physicist who used an FPGA once (or twice)...and knows more than I do about electrical engineering and FPGAs. If that is true, perhaps I ought to open a hot dog stand ;-) > >Any input appreciated ;-) > > Enjoy your argument :-) Well, it's not really an argument if you aready know the right answers. Yours were pretty much the same as mine. No surprise there ;-) I think you missed this "interesting" statement though: >#1> Programming FPGAs...changes bits of non-volatile memory that is [are] >#1> used as inputs to these [logic gates in the silicon wafer] gates... The "are used as inputs to these logic gates in the silicon wafer" part... and one comment on this: "Since the devices are volatile, and infinitely re-programmable, just like a CPU, no physical modification of the internal wires occurs." Though true, there is a logical modification to the "internal wires", as in, the PIPs get programmed to route the internal signals. Regards, AustinArticle: 73163
wpiman@aol.com (MS) wrote: >We are using the trial version of the OPB Uart 16550 in one of our >designs. We are running this at 19200,8,N,1, no flow control. We are >using Hyperterminal- Yikes! Everything else snipped. Do your utmost to remove HyperTerminal as a variable. The vast majority of the time when I've thought I had a serial I/O problem, when boiling it all down to a low gravy, what was left as a problem source, was HyperTerminal. Summary: If you observe a serial I/O problem and you a using HyperTerminal, the likely cause is HyperTerminal! You've been warned! -- Dan HenryArticle: 73164
No MicroBlaze runs at 150 MHz in a V2PRo and 185 MHz in V4. That is a 23% improvement. Göran Jon Beniston wrote: >>I think it's better that I answer that. >>MicroBlaze will run about 185 MHz in speedgrade -12. >>With the new architecture Virtex4, I will need to create a different >>aspect ratio on the RPM block since this architecture is smaller and higher. >>VII and V2Pro was more rectangular in the shape. >>With the new floorplan I achieves 165 MHz in -11 and this will give us >>around 185 MHz in -12. >> >> > >So that's only 10% faster that a vIIp then? > >Don't get me wrong, a 185 MHz CPU is pretty fantasic, it just doesn't >seem that the v4 is giving it that much of a kick. > >Cheers, >JonB > >Article: 73165
Hi! My points exatly General Schvantzkoph. In a majority of designs 8 is more than enought, but in cases, when you have to interface with 4 different CPUs each running in it's own clock domain, you have 4 independent DDR channels (1-2 variable shifted clocks per channel), 2 ZBTs, USB and Ethernet interface, 1 or 2 ChipscopePro cores for debugging. Then you also have a system clock (which is used in 80% of the design) all that on the same chip,... then you are running out of IOs, out of BRAMs, out of clocks, out of everything. That's why you need to cross the regions... And on top of this, SI issues, different IO standards and voltage levels sometimes forces you use IOs in other banks... And at the end location of other devices on PCB, which are connected to FPGA also forces you to use IOs you normaly wouldn't. Some would say use bigger chip. Of course this could be a solution, but a very expensive one, because price is also a major factor. By using bigger chip (with more IOs) I would have to use 12 layer PCB instead of 10, PCB would be bigger, I had to redesign the cooling solution. All this would result in a more expensive product. Austin, It was not my intension to criticize your desicions, I just wanted to clear this matter. And If I had ISE 6.3 installed on my machine, I wouldn't ask this, instead I would try to figure this out by myself. Anyway, when can we expect CDs with ISE 6.3 to arrive? Regards, Igor Bizjak "General Schvantzkoph" <schvantzkoph@yahoo.com> wrote in message news:pan.2004.09.15.00.25.27.975530@yahoo.com... > There are lots of situations where you need multiple clocks. If you > are interfacing to a number of devices that each have their own clock you > need a separate clock for each of them. Even if the devices are all using > the same source clock their output clocks (for clock forwarded interfaces) > are all phase shifted by an indeterminate amount so they have to be > treated as asynchronous. I typically capture each device's data in an > async FIFO and then transfer it into a primary clock domain. The great > majority of the slices are in the primary domain so the device is mostly > synchronous but there is still a need for a large number of clocks. >Article: 73166
Hello everybody, I would just like to take this opportunity to tell you about a new VHDL IP website that is now up and running at... http://www.spacewire.co.uk There are some interesting bits of IP to download including a full CISC micro that comes complete with an assembler and Xilinx RAM generator. Well worth a look ;-) All the best, JohnArticle: 73167
Please have a look at the new ChipSync Interface, which is available in all I/Os and takes care of the issue that you describe. It makes the design of all source synchronous interfaces much easier. Instead of using a global clock signal for the received clock, it uses a dedicated local clock to capture the data. The clock AND the data can be delay adjusted, so that board delays and skew can be compensated. Within the FPGA you have the option to run the FIFO of your example at "line speed" or reduce the clock frequency and increase the bit-width by using the built-in SERDES. As an example, if you have data coming into the device at 1Gbps (500 MHz DDR) you may want to set the SERDES up with a divide by 4 (the value 4 is just an example that makes sense in this case) so that you get 4 bits with every clock of 250 MHz. This can easily be transferred to a BRAM / FIFO. Only when you read the FIFO, you may want to use a global clock, as this is your "real" system clock (primary domain). There are 2 local clocks per clock region. The number of clock regions depends on the device size - there are between 8 and 24 of these clock regions. A detailed description of these resources can be found in the "Virtex-4 User Guide". I can not describe all the features and capabilities in this message. There are also a couple of Application Notes available that take advantage of this technology. --Jürgen General Schvantzkoph wrote: > There are lots of situations where you need multiple clocks. If you > are interfacing to a number of devices that each have their own clock you > need a separate clock for each of them. Even if the devices are all using > the same source clock their output clocks (for clock forwarded interfaces) > are all phase shifted by an indeterminate amount so they have to be > treated as asynchronous. I typically capture each device's data in an > async FIFO and then transfer it into a primary clock domain. The great > majority of the slices are in the primary domain so the device is mostly > synchronous but there is still a need for a large number of clocks. >Article: 73168
Goran Bilski <goran@xilinx.com> wrote in message news:<4147DCBB.2020409@xilinx.com>... > No > > MicroBlaze runs at 150 MHz in a V2PRo and 185 MHz in V4. > That is a 23% improvement. The Xilinx web site (http://www.xilinx.com/ipcenter/processor_central/microblaze/performance.htm) says 150 MHz for a -6 device. I was assuming the -7 would be a bit faster. Cheers, JonBArticle: 73169
Hi, If I remember my test was with the -7 speed grade for V2Pro. So I don't think that the website is correct. It should be a -7 device. I will contact the person who is responsible for the webpage. Thanks for finding this Göran Jon Beniston wrote: >Goran Bilski <goran@xilinx.com> wrote in message news:<4147DCBB.2020409@xilinx.com>... > > >>No >> >>MicroBlaze runs at 150 MHz in a V2PRo and 185 MHz in V4. >>That is a 23% improvement. >> >> > >The Xilinx web site (http://www.xilinx.com/ipcenter/processor_central/microblaze/performance.htm) >says 150 MHz for a -6 device. I was assuming the -7 would be a bit >faster. > >Cheers, >JonB > >Article: 73170
Hi all, Can I insert my own IP core in the Xilinx Core Gen? Can I use Xilinx Core Gen to manage my OWN VHDL IP core? If not, why Xilinx does not allow that feature. Larry, www.amontec.comArticle: 73171
Hi, I was wondering how accurate the clock2x of the VIRTEX 2 FPGA was. I wanted to multiply 60 MHz by two using the clock2x in order to generate a 120 MHz clk for my logic. Has anyone had experience using this and has it worked well?Article: 73172
Hi Mukesh, Mukesh Chugh wrote: > Hi Brendon, > > Thanks Brendon for the response. > Yes, I am using 6.2.03i of xpower. Can I get web updates? You can. Our service packs are available on the web. > Also, do we > need to get update for xpower alone or we have to get for complete > ISE. Complete ISE. > I also saw on xilinx web site that ISE 6.3i is released too on > 9/13. Pls clarify what all i need to upgrade if I have ISE 6.2 and > xpower 6.2.03i There are two steps : - Firstly you need to upgrade to 6.3i. That is not a web release. That is a CD-based release. - Then you need to download (from the web) 6.3.01i Regards, Brendan > > > -- > Mukesh > > Brendan Cullen <bcullen@xilinx.com> wrote in message news:<41404E30.47F20BF8@xilinx.com>... > > > > This does indeed look similar to another problem which we've been working > > on. We have a fix for that problem (the one we've been working on) and > > the fix will be available in the next service pack - 6.3.01i - which > > should be available to you next week. However, you might be experiencing > > a diferent symptiom. One option would be for you to zip up the NCD & VCD > > file and send them to us ? Or are they huge ? The other option is for > > you to try the service pack next week. Note - in order for you to use > > 6.3.01i you'll need to have the underlying 6.3i. (From your other e-mail > > to the newsgroup it appears you are using 6.2.03i.) > > > > BrendanArticle: 73173
Hello I am getting following warning during simulation in ModelSim * Warning: *DFE3C RECOVERY High VIOLATION ON CLR WITH RESPECT TO CLK; # Expected := 1 ns; Observed := 0 ns; At : 61005 ns # Time: 61005 ns Iteration: 1 Can any one tell what is RECOVERY High VIOLATION. Thank for any help NaimeshArticle: 73174
hi,
im supposed to evaluate the same design in both altera and xilinx
devices, the problem is that altera's software seems a bit "unusual"
and doesnt understand code that all others synthetisers i've tried
recognise.
first i was having trouble with RAMs, but i solved that following
quartus II handbook coding guidelines (though i had to change several
files...and i dont like when that happens...specially because i'll
have three versions, one for each fpga family and then another for
asic!!)
now, im having trouble with ROMs, specially because the handbook has
an error...it says
*** "VHDL Synchronous ROM" ***
.
.
.
architecture ...
begin
process(clock) <- note this!
begin
case address is <- note this! no if rising_edge!!!
when "000" => data_out <= "010";
when others => blah blah;
end case;
end process;
end;
now, i've tried both ways, the right one with the "if rising_edge..."
and the wrong one, and still i cant get quartus II to infer a ROM
without using LEs, it always makes the ROM out of LEs!. Could somebody
explain it to me?. Or is it that it just cant implement a ROM in a
RAM?? and it will always use LEs??
thanks a lot in advance
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