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
Hello Vladislav, Thanks for the reply. Yes i also think my implementation is correct. I have ported it to FPGA and i am facing the same problem. I am able to read the internal register (reset value) in only slave interface but if i trisatate the bus for interfacing the master and slave i reading all zeros. After probing the internal signal through chipscope i came to know that all the signal which i am tristating is being connected to ground. I am using synplify for synthesis and then EDF being implemented on ISE. Thanks and regards williamsArticle: 89276
Folks, The 25P10A from ST do work fine. > Looking at the *.pof for a Cyclone configured to load from an EPCS4, the > string EPCS4 is included at the start. Yes the *.pof knows what is the target device. > I'm not sure of why I think this, but I've an idea that the devices check > the device ID at the start of config, although this might be wrong. That info on the *.pof file is for the programmer soft-module to know how to program, and that doesn't go into the device. > If this is the case you'd have to use a device with the same ID. The Cyclone device check the device ID to know how much data it may have to load, just that... I think. I can't tell what ID's are recognized by the Cyclone load engine... but at least the ones corresponding to the EPCS1 and EPCS4 are for sure. The bottom line is still, ST25P10A has the exact same ID as the EPCS1 and quartus II still fails to load them. However is a fact that once programmed (by other means) Cyclone devices do read them without trouble. Luis C. "Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message news:4321c8d9$0$21184$db0fefd9@news.zen.co.uk... >> I have no idea which of these parts might work. The SST parts are pin >> compatible but have different IDs. They probably cannot program from >> quartus but they might read OK. > > > Looking at the *.pof for a Cyclone configured to load from an EPCS4, the > string EPCS4 is included at the start. > > I'm not sure of why I think this, but I've an idea that the devices check > the device ID at the start of config, although this might be wrong. > > If this is the case you'd have to use a device with the same ID. > > > Nial. > > > > ------------------------------------------------------------- > Nial Stewart Developments Ltd > FPGA and High Speed Digital Design > www.nialstewartdevelopments.co.uk >Article: 89277
I'm very excited to be traveling home Saturday! To see the chip! :) The inputs to the chip are: 01 - CLK - 16MHz 02 - I - D0 03 - I - D1 04 - I - D2 05 - I - D3 06 - I - D4 07 - I - D5 08 - I - /DMA 09 - I - TC 11 - /OE - TSEN 12 - R - /DMALD 13 - R - PWM 14 - R - NC 15 - R - NC 16 - R - NC 17 - R - NC 18 - R - NC 19 - R - NC So its a pretty simple device. I'm going to try to ignore those output pins when I am reading the device. I want to make sure I try doing this blind. :)Article: 89278
Please go through the topic "Disconnect the FPGA I/O pads from the outside world". I think our problem is similar.Article: 89279
Marc Battyani wrote: (snip) > In fact I'm not sure that full IEEE floating point accuracy is needed. For > sure single precision is not enough but probably double precision is not > really needed. The problem is that people who write the algorithms do it in > C(++) using double precision floats and they use double precision libraries, > etc. So it's not obvious to see what precision is really needed. After all > in an FPGA we can use the exact number of bit needed. (In fact it is even > possible that a fixed point format could work) If fixed point will do it, even significantly wider than floating point, it is likely the best way. Floating point add is a lot more expensive than fixed point. The difference is much smaller for multiply and divide, not counting any overhead specific to full IEEE implementations. -- glenArticle: 89280
Bob Myers wrote:
> I'm used to having an external reset line feed one of the pins, that
> could be
> specified to Leonardo 4.22 as the global_sr signal.
Actually, Leo will find the external reset and put
it on a global line for you if you use a standard
synchronous template.
> When I try to read in the design, I get told by Leonardo that the GSR
> net name
> that I'm using does not have a source --> looking at the schematic
> viewer, I
> find that all of the GSR nets get grounded.
Use of the GSR in your design description
is optional and the Leo default
is to not use it. I think this is a good thing
as it makes your design more portable and
easier to simulate.
Consider using an external pin for reset.
-- Mike Treseler
Article: 89281Does anybody have a general feel for whether or not Actel (or any other vendor) is going to bring out a new generation of antifuse fpgas on a newer process (90nm)? Or has this device style basically been shelved as only a specialty item for people who are ultra-sensitive to soft errors above all other factors? I'm mainly curious about whether or not the speed advantages will continue on newer processes. In theory, an antifuse should have less capacitance than an SRAM-based pip, giving you lower propagation delays and hence higher clock rates. It looks like this was probably true doing a 150nm-to-150nm comparison of the Axcellerator versus FPGAs made on a similar generation of process technology. However, I have to believe that the antifuse stuff requires a special process/fab, and that fab isn't going to be doing anywhere close to the volume that a strictly-CMOS fab would. That in turn drives up prices or else forces compromises that affect performance (in order to bring down costs). So, ultimately, I'm wondering how this will play out. Obviously any comments at this point are pure speculation, but I'd appreciate speculation from somebody who knows more about this stuff than myself. - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 89282
I'm the guy that usually says to use the wizard but its not appropriate for your case. Directly implementing an opb master is quite straightforward--plb is more complicated. The CoreConnect OPB Bus specification will give you all the signals, but OPB has a pretty simple request-grant scheme. A colleague created a master in HDL to interface with the opb_ddr controller. It was only a couple of lines of code. Paul "arincm@hotmail.com" wrote: > > Hello fpga-faq, > > I want to create a user module that will act as a master on an opb bus. > I am using xilinx Platform Studio, version 7.1i. Now before you say > it, I have read the http://www.xilinx.com/ise/embedded/est_rm.pdf guide > on using the create/import wizard for xps. I have read it, and seen > the skeleton, but have not been successful with a master bus. I have > created a custom slave module, and succeeded... > Has anyone done this? I just want some sample code that does anything > as a master on an opb bus. > In case it is not clear why this would be a good thing, there are many > edk tools that will only work over an opb bus- but in many fpga > designs, you don't really need a processor, just custom code. All I > want is the edk uartlite over a opb bus, but I have to be the opb > master to do it. > > thank you, > ~arinArticle: 89283
Hi Robert, I am not sure this is what you are looking for, but my company Brace Design Solutions has just released a Xilinx (TM) LogiCORE (TM) PCI compatible PCI IP core called BDS XPCI PCI IP core. BDS XPCI32 PCI IP core is available for as little as $100 for non-commercial, personal use, and the 64-bit version BDS XPCI64 PCI IP core (Includes BDS XPCI32 PCI IP core) goes for $200. Obviously, this version is going to restrict the use to non-commercial, personal use, but that shouldn't be a problem for FPGA beginners, FPGA hobbyists, computer hardware enthusiasts, or student graduation projects. With this PCI IP core, almost anyone can make their own PCI device for as little as $400. ($275 Insight Electronics Spartan-II 200 PCI Development Kit + $100 BDS XPCI32 PCI IP core.) Insight Electronics Spartan-II 200 PCI Development Kit is fully supported by this PCI IP core, and Avnet Xilinx Spartan-3 Evaluation Kit support will be added in the future. (The PCI IP core works fine with Spartan-3.) For commercial users who want to modify BDS XPCI PCI IP core or want to convert a design that uses Xilinx LogiCORE PCI to an ASIC, BDS XPCI PCI IP core is available in Verilog HDL RTL, although it isn't cheap like the non-commercial, personal use version. For more information, visit Brace Design Solutions website at http://www.bracedesignsolutions.com. Kevin Brace Robert wrote: > Hi! > > Has anyone successfully used opencores PCI in FPGA desings? > > I have seen this question posted a few years ago and I would like to > see if there are new answers to it. > -- Brace Design Solutions Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available for as little as $100 for non-commercial, personal use. http://www.bracedesignsolutions.com Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.Article: 89284
Brian, Thanks for your comments. All accurate. Why they The ML450 pcb team) used the external 100 ohms is beyond me. If we don't meet the C spec, then why bother to be concerned about the R spec. You are correct instating the resukts work better with the internal R. We'd love to "slim down" the IOBs. Anyone have a list of standards that are useless? Seems like there are a few out there that folks don't use much, but then again ... Austin Brian Davis wrote: > Austin wrote: > >>It really is 5pF across 100 ohms >> > > > As presently documented in your datasheets and IBIS files, it's > really two 10 pFs in shunt to ground across a 100 ohm +/-20% R. > > It may appeal to your inner marketeer to call it 5 pF, but that > won't make your parts work any better. > > If you're going to continue to 'correct' folks who quote your > own documentation, at least have the technical honesty to point > out that modeling two shunt C's as an across-the-pair 1/2 C is > ONLY valid if the input signal is perfectly differential. > > Here's to hoping that when you eventually publish S3E IBIS and > SSO info, those slimmed-down DCI-less I/O buffers have a lower C. > ( And I'd still love to see some of the smaller S3E parts appear > in a ground-paddle VQFP or QFN package ) > > >>As well, "they" use an external 100 ohms for all their simulations, >>where we recommend use of the internal 100 ohms for all high speed >>interfaces (really makes things look worse due to the stub). >> > > > Perhaps you should review your own documentation before throwing > stones at others. > > The last time we went round on this, you pointed to the ML450 V4 > evaluation board as a shining example of SI design. > > If you look at the ML450 schematic, BOM, and board layout, you'll > notice that the HyperTransport input lines are terminated using > external 100 ohm resistors, with stub lengths of about half an inch. > > Maybe this was done because you can't meet the HyperTransport +/- 10% > terminator R spec with the _DT terminators, but I'd wager that the > internal R's would work better than those big stubs, especially with > the non-compliant Cin values of your HyperTransport inputs. > > I didn't spot any supporting IBIS sims for the ML450 layout anywhere; > perhaps you could publish some 500 MT/s and 1 GT/s simulations in > the user guide, using a fast HyperTransport compliant driver, with > waveforms plotted both at the internal FPGA Rx and at a HyperTransport > bus probe connector on the driving board :) > > From HyperTransport 2.0: > > internal terminator Rt : 100 ohm +/- 10% > > single ended Cin (400-800 MT/s) : 5 pF > single ended Cin (1-2 GT/s) : 2 pF > > single ended Cout (400-800 MT/s) : 5 pF > single ended Cout (1-2 GT/s) : 3 pF > > Any mention of HyperTransport in your datsheets, app notes, and > user guides should be appropriately footnoted as non-compliant. > > > Brian >Article: 89285
Adam,
I think you have it well understood.
I am sure there is work on better and smaller efuse technologies, as
even non-fuse based FPGAs may use fuses (for redundancy). Also, ASICs
and ASSPs use fuses for redundancy, repair, and setting bias voltages.
A big fuse cell is a pain in the neck. Smaller is better.
However, right now Actel has a bigger problem: the issue of their fuses
blowing on their parts (see NASA/JPL advisory notice 'do not use') due
to SI issues (large overshoot/undershoot on IOs). They have claimed
this is solved, and is not a problem on any family other than the one
affected, but it has had a huge sobering effect on the fuse FPGA
mil-aero community ("how can I ever trust these parts ever again? my
mission was scrapped ... I lost my job because the contract was
canceled" - heard in the hallways of JPL ...).
I love fuses, when they work.
Austin
Adam Megacz wrote:
> Does anybody have a general feel for whether or not Actel (or any
> other vendor) is going to bring out a new generation of antifuse fpgas
> on a newer process (90nm)? Or has this device style basically been
> shelved as only a specialty item for people who are ultra-sensitive to
> soft errors above all other factors?
>
> I'm mainly curious about whether or not the speed advantages will
> continue on newer processes. In theory, an antifuse should have less
> capacitance than an SRAM-based pip, giving you lower propagation
> delays and hence higher clock rates. It looks like this was probably
> true doing a 150nm-to-150nm comparison of the Axcellerator versus
> FPGAs made on a similar generation of process technology.
>
> However, I have to believe that the antifuse stuff requires a special
> process/fab, and that fab isn't going to be doing anywhere close to
> the volume that a strictly-CMOS fab would. That in turn drives up
> prices or else forces compromises that affect performance (in order to
> bring down costs).
>
> So, ultimately, I'm wondering how this will play out. Obviously any
> comments at this point are pure speculation, but I'd appreciate
> speculation from somebody who knows more about this stuff than myself.
>
> - a
>
Article: 89286
Hi ,
Do u have Xilinx EDK 6.2 tools, in case u have them then , if u
go to /hw/XilinxReferenceDesigns/pcores/opb_core_msp0_v1_00_b/ , thats
nothing but a OPB Bus Master design with Write capability. The only
catch is that it uses a very old version of IPIF. If you are ok with
that then you can go ahead and use it.
In case u dont have EDK 6.2 , then just send me an e-mail and I
can tar the file and send it to you ..
--
Parag Beeraka
Article: 89287Hi, I have an old Xilinx XChecker Serial cable which has served me well. Apparently (not that I can tell) and unfortunately, it is not supported in the newer ISE 7.1i tools. Which cable do you guys suggest to use? My only real restriction is that it needs to work with Linux / Linux versions of the ISE 7.1i tools. USB cables seem too flaky, but maybe that's changed? I'm also wondering if I should consider the Chameleon POD which can emulate many useful JTAG adaptors. Ideas? Thanks. RAMArticle: 89288
you could make them all signed... but have you ever looked at symplify's output? if you use a signed 8 bit number for a counter counting from 0 to 255, then it will generate a 'warning count<8> is not used' I personally check every warning and every error... I've had designs producing several hundred warnings ... all of which are just junk (code portability). but try to get it down to less than 20 warnings by the time the project is finished. so I will stick to signed types.. and unsigned types... unsigned by default as unsigned math is easier and signed only when absolutely necessary Simon "Marko" <cantsay@comcast.net> wrote in message news:gea3i15r0ucrnuggagmil1ug8jj7v22669@4ax.com... > In Verilog, I do it by defining all variables as signed. Then it's > automatic. > > reg [7:0] p1; > reg [7:0] p2 > wire signed [8:0] p1s; > wire signed [8:0] p2s; > wire signed [8:0] diff; > > assign p1s = p1; > assign p2s = p2; > assign diff = p1s - p2s; > > Notice that I made all variables 9-bits to ensure that values up to > 255 will be treated as positive numbers and so that the result can > represent the full range of -255 to +255. > > Marko > > > On Wed, 7 Sep 2005 06:21:37 +0200, "news.green.ch" <rb@freesurf.ch> > wrote: > > >Hi > >I'am a newbe, and know how to add unsigned numbers in Verilog HDL, but how > >to define a signed number? > >I've the following situation: > > > >reg [7..0] p1 //(is an unsigned value from AD converter) 0..255 > >reg [7..0] p2 // is the unsigned value that we should have 0..255 > > > >now I want to substract p1-p2, to have the differenz, to correct the error > >reg[7..0] diff //should be a signed value > > > >how do I define this in Verilog HDL > > > > > >best regards remo > > > > > > > >----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- > >http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups > >----= East and West-Coast Server Farms - Total Privacy via Encryption =---- >Article: 89289
Ram wrote: > Hi, > > I have an old Xilinx XChecker Serial cable which has served me well. > Apparently (not that I can tell) and unfortunately, it is not supported in > the newer ISE 7.1i tools. > > Which cable do you guys suggest to use? My only real restriction is that > it > needs to work with Linux / Linux versions of the ISE 7.1i tools. USB > cables seem too flaky, but maybe that's changed? > > I'm also wondering if I should consider the Chameleon POD which can > emulate many useful JTAG adaptors. > Hi RAM. The Xilinx CPLD=DK I got last week from Xilinx Jtag Cable connects to the DB25 Pin parallel port and works correctly on ISEi 7.1 and 7.1.1a. http://toolbox.xilinx.com/docsan/data/alliance/jtg/fig26.htm gives it all to you. On the RHS of the schematic there are two pinouts. Top one is for direct connect to CPLD Jtag SIL header, the bottom RHS connection is for the FPGA connection. Hope this assists you. ------------- Cheers GrahameArticle: 89290
Bob Myers wrote:
> I have converted an old Xilinx schematic design into VHDL. However,
> I'm running into a problem with how to implement the GSR function
> properly.
>
> I'm used to having an external reset line feed one of the pins, that
> could be specified to Leonardo 4.22 as the global_sr signal. This
> design, however, used an internally generated pulse from the
> configuration section to pulse the registers.
>
The method I use in VHDL to implement the GSR is to instantiate within
the design a ROC primitive (which is in the Xilinx unisim library). All
of the Xilinx tools for many years have understood that this net is the
GSR, and I would assume that Leonardo would too. ROC simply outputs a
reset pulse of a few 100nS, just like the real GSR.
-- synthesis translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- synthesis translate_on
...
component roc
port (
O : out std_logic
);
end component;
...
roc_e: roc
port map(
O => RESET
);
Article: 89291Hey i have spartan 3 and i wanna know about Block RAM available with it.from xilinx website i came to know that i have 12 number of 18Kb block's . now i want to use 4 blocks for my work . how to instantiate all these 4 . just give me a sample of that (my confusion is with the module name .... what will be the name of these 4 ) if i want to use SelectRAM_A9_B9 , just tell me how to instantiate it another problem is if i want to make a block of 8k . now i need 4 numbers of 2k blocks . how to group these 4 . u just give me example of joining 2 blocks , i will do the rest. what is DCM and how to use it with spartan FPGA ?? nitinArticle: 89292
Robert wrote: > Has anyone successfully used opencores PCI in FPGA desings? Yes, we're using one atm. It is yet to be released but is fully functional. Regards, MarkArticle: 89293
When I got home I tried to take my own higher resolution pictures, but it seems the chip has corroded...? Or maybe my imaging technique is bad. Take a look: http://media.diywelder.com/images3/091105-40xASG_DSCF0724.jpg I am going to the university on Monday to use ther metallurgy microscope. It has a video camera mounted to it, and will go higher than 40x. Here is an image I took with a 40x microscope with my 3x camera zoomed held to the eye piece ;) I'm pretty sure I'm zoomed in on the block for pin 7. http://media.diywelder.com/images3/091105-findingthemap_DSCF0724.jpg And this is what the block should look like empty. I'm having a hard time locating the input and output feedback connections. They don't seem to be where I'd expect them. http://media.diywelder.com/images3/091105-pin7fusemap.jpg Here is an image showing how I identified the pins: http://media.diywelder.com/images3/091105-ASGwithpinout.jpg Is the gold blob I identified a fuse that has not been removed? Or in this case since its a HAL a fuse that was deposited? HALs probably just wouldn't have a fuse where as a pal should have one burnt? Any suggestions at all? And is there a chance with this HAL that its fusemap visually would be different from the datasheet organization or a regular PAL? Since its not programmed but manufactured at a factory? Any industry contacts anyone could recomend? I'd love to figure this out. :) I'll try to get some better pictures on Monday.Article: 89294
austin <austin@xilinx.com> writes: > However, right now Actel has a bigger problem: the issue of their > fuses blowing on their parts Yeah, although this is the part of the whole antifuse debate that kinda annoys me. Whenever the issue comes up, people only talk about reliability and radiation. Obviously those are important for a really big market, but not for me. Right now I'm interested in prototyping new/alternative fabrics for FPGAs. Short of doing a MOSIS run (which I will do eventually -- just not yet), I'm trying to figure out the best way to do a mock-up prototype. All I care about is speed (aka propagation delay), size, and the ability to map my "virtual CLBs" efficiently. I only need to program the device once. Given those (admittedly unusual) constraints, I'm trying to evaluate what's out there. Additionally, most of my stuff will be QDI self-timed, so clock distribution innovations aren't a big feature for me. > I love fuses, when they work. Now Austin, you wouldn't be FUDding us just a *leeetle* bit there now would you? ;) Thanks for the reply though! - aArticle: 89295
How to manage several ucf files when working with different projects on the same chip? i.e. top_pads.ucf, that is always the same and top_area_1.ucf or top_area2.ucf any 'include' directive?Article: 89296
I've got my design talking to some (Kingston) KVR133X64/1G SDRAM
modules and running at only 66MHz, doing some simple testing (the
data=address or maybe data={address,address}) and have found some funnies.
There are a few dozen single bit errors. There are also several
locations that come back with some F digits (as if the cells just
don't exist). Also they are mid-burst as much as not which indicates
it isn't a timing problem.
I have done testing on different FPGAs with different SDRAM modules
and the errors definitely go with the modules and are quite
repeatable.
I have checked the refresh timing and it's good.
Is Kingston SDRAM really that bad ? The fact they are made of
repainted Infineon chips such that you can't read the original part
number makes me suspicious that these might not be the real
thing. They claim 100% testing but I wonder what they do with modules
tested as bad. Is it because the FPGA can keep memory busy in a way a
processor can't ? Should I speed up the refresh ? We intend to try
some Micron parts anyway.
Jon
Article: 89297Hello Guys, I am facing fatal error when i am synthesizing my RTL code. The same code gets synthesized in synplify but not in ISE 6.3i. I tried my luck for finding the answer in xilinx site but found no information about. FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This application has discovered an exceptional condition from which it cannot recover. Has anyone faced this type of problem. Can you please suggest how can i solve this problem. Thanks and Regards WilliamsArticle: 89298
Hi! Is there a way to write a placer and router for Xilinx FPGAs. Or the FPGA technology is closed at this level ??Article: 89299
stud_lang_jap@yahoo.com wrote: > FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This > application has discovered an exceptional condition from which it > cannot recover. I would start at having a closer look at the synthesis report file. Most of the time when something like that happens there are earlier error or warning messages that could hint at what's really wrong. You can open the synthesis report either in ISE (but there the function to display it usually only works when there are no fatal erros) or by opening the *.syr-file ISE creates in your project directory with a text editor. Maybe there are some clues there. Otherwise, there's really not much you can do... FATAL_ERRORS are supossed to only show up when there's something really terribly wrong somewhere... Mostly, bugs in the software... Plus, have you looked at Xilinx Answer Records on http://support.xilinx.com ? This looks similar to your problem, although the ISE version doesn't match: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17481 cu, Sean
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