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
Hi All: I think you should know the star point first - where are all of these grounds connected? By introducing a fourth ground, we now have more ground loops to consider. For strict EMI shielding, copper pours on the surface and another plane would be good (yes, I read Howard Johnson), but we still have 4 grounds, and no idea of the impedance and voltage difference. First thing to do here is get a map of how the whole system is grounded, and work from there. This is NOT a simple question that can be dealt with easily, and mistakes can have disatrous consequences in the field - I have done these things (ouch, double ouch, triple ouch), and found them very hard to diagnose. Andrew Walter Dvorak wrote: >:: Gabster :: <gabsterblue@hotmail.com> wrote: > > >> My FPGA PCB has 4 layers: ground, power and two signal layers. I'm >>wondering if I should put a ground plane on the 2 signals layer. At first I >>believe it wasn't required because of the ground layer then I thought about >>EMI/RFI protection it could bring. What is the usual way to do it? If yes, >>to what ground should I tie it: digital, analog or power? >> >> > > if you need a seperation between (digital) ground (DGND) and chassis >at low frequencies use a seperate "chassis plane" which should be placed next >to the (digital) ground plane in the layer stack. Keep care about symmetric >arrangements of the power planes in the layer stack. If the isolation betweens >DGND and chassis doesnt matter in your application, connect DGND to the chassis. > > a good information source on this topic is Johnson, Graham: "High >Speed Digital Design - a handbook of black magic", Prentice Hall. > >WD > >Article: 58851
Jon Masters wrote: > > kryten_droid wrote: > > > After I bought one and installed the Xilinx Web Pack, I found that this was > > packed with far more useful examples than the non-cheap book. > > I was after something to read while travelling around where it is > impractical to carry a development environment and necessary tools. > > ``Digital System Design with VHDL'' seems like a reasonable book which I > am looking at for now and then I will follow up with the suggestion from > Paul. I have been getting back into VHDL after more than a year of doing other stuff and I have forgotten a lot. I have five books and the one I am using the most is VHDL Made Easy by David Pellerin and Douglas Taylor. At first I was not crazy about it, but I am finding that it sits beside my computer most of the time while the others stay on the shelf. The other reference I have on my desk is the LRM. There is not much that these two don't cover pretty well. The "Easy" book gives me the short version and the LRM gives me all the details I can swallow. -- 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: 58852
A little bit of ascii art here. Imagine each letter has a inch square (my board is 3" x 5"). D is digital ground, A is analog ground and P is power ground. These three are on the ground plane and star connected where the three regions meet: DDD DDD DPP APP AAA At this moment I have simply duplicated the three ground regions on the top and bottom layers. I've attached these to their respective ground. I believe this is a simple way to deal with the situation regards, Gabriel "Andrew Paule" <lsboogy@qwest.net> wrote in message news:tgXWa.35$tt6.48403@news.uswest.net... > Hi All: > > I think you should know the star point first - where are all of these > grounds connected? By introducing a fourth ground, we now have more > ground loops to consider. For strict EMI shielding, copper pours on the > surface and another plane would be good (yes, I read Howard Johnson), > but we still have 4 grounds, and no idea of the impedance and voltage > difference. First thing to do here is get a map of how the whole system > is grounded, and work from there. This is NOT a simple question that > can be dealt with easily, and mistakes can have disatrous consequences > in the field - I have done these things (ouch, double ouch, triple > ouch), and found them very hard to diagnose. > > Andrew > > Walter Dvorak wrote: > > >:: Gabster :: <gabsterblue@hotmail.com> wrote: > > > > > >> My FPGA PCB has 4 layers: ground, power and two signal layers. I'm > >>wondering if I should put a ground plane on the 2 signals layer. At first I > >>believe it wasn't required because of the ground layer then I thought about > >>EMI/RFI protection it could bring. What is the usual way to do it? If yes, > >>to what ground should I tie it: digital, analog or power? > >> > >> > > > > if you need a seperation between (digital) ground (DGND) and chassis > >at low frequencies use a seperate "chassis plane" which should be placed next > >to the (digital) ground plane in the layer stack. Keep care about symmetric > >arrangements of the power planes in the layer stack. If the isolation betweens > >DGND and chassis doesnt matter in your application, connect DGND to the chassis. > > > > a good information source on this topic is Johnson, Graham: "High > >Speed Digital Design - a handbook of black magic", Prentice Hall. > > > >WD > > > > >Article: 58853
In article <3F2B2C11.5060200@ionsky.com>, thad@ionsky says... > > That introduces some additional considerations. A VCO would be fairly > stable for a given control voltage. Is this true of the motor? If > there are load variations, can the controller keep it within the narrow > speed window to maintain your phase margin. Even if the controller > increases the drive to compensate for a load increase, it probably won't > do anything to recover accumulated phase error. If you absolutely need > 0.1 degree maximum phase error while the load changes, you might need a > much stiffer motor drive, as well as immediate feedback from the motor > to the controller, probably a high resolution rotary encoder. If there > is very little load change or your phase error limit can be exceeded at > times, it won't be as bad. Well, for this application my load is fixed but moving air and so on would certainly cause rotational variations. There will be a rotary encoder so I can get position/frequency/phase information from the setup. The type of encoder is not yet set (absolute or incremental) and neither is the number of Counts Per Revolution (CPR). I know it'll have to be high though around 512 or 1024/1000. For the suggestion in another response that I follow what Peter said and do it all digitally, that was always my goal! =) I am using a CPLD to do the phase detector, quadrature encoder and phase error counter. The control-loop will also be done digitally(probably in a uC simply due to the limited arithmetic resources of the CPLD) but the control out from the circuit will have to be something like PWM. I've looked at Sigma-Delta converters before and always thought it was effectively a PWM type setup. By filtering the harmonics you recover your fundamental which is possibly(and probably) changing in time. The same "principle" I always thought is what was behind class-D/class-T audio setups where you PWM your output and the speaker itself will low- pass filter. Though I wonder if/how they get their 16x frequency out *AND* maintain 16-bits of resolution, given for any pure digital PWM implementation there is the divide of 2^n where n is number of bits. I guess they could do something like a tapped delay-line in silicon or a Delay-Lock-Loop and/or the other tricks Xilinx & co uses for things like the DCM. Back to the motor situation, my PWM output is driving an H-bridge. My understanding was the motor effectively low-pass filters my square wave (modulating the H-bridge) and this setup approximates a buck type switching power supply and/or the Sigma-Delta setup. For what it's worth, I do plan on adding an LC input and LC output filter to the H- bridge (to reduce harmonics being injected back into the line and reduce harmonics to the motor). I guess I'm not sure how I can get any better than this setup. As usual, I welcome all suggestions. Thanks everyone for your valuable insights! -- Jay.Article: 58854
Hi, I did the synthesis with Synplify 7.3 and got the output "top.edif". Then I used "edif2ngd" to convert "top.edif" to "top.ngo". This is where I got the problem. The "top.ngo" was not properly produced, so the program stopped and popped up the error: "ERROR:XdmHelpers:828: File "top.ngo" is not in NGD or XDB format". I could not figure out what the problem is. Any help would be very appreciated. Lan Peter Ryser <ryserp@xilinx.com> wrote in message news:<3F276433.EFFC08BE@xilinx.com>... > Lan, > > while XST is not supported for the ml300_embedded_* design shipping with ML300/V2PDK 1.5 it > will work with the Verilog version but not work with VHDL. However, you will have to remove > some peripherals from the system by modifying flow.cfg and changing the yes/no table at the > end of the file. > > The default setup for the ml300_embedded_verilog design is the one that is part of the > ML300 ACE files, ie. Linux will boot even if there are devices like AC97 and others that > are not directly supported by Linux. > > flow.cfg is the central file for all configurations, tools, SW, peripherals, etc. > > - Peter > > > Lan Nguyen wrote: > > > Hi Peter, > > > > I've got the Developer's Kit V2PDK VP4. I wanted to run the reference > > designs and test the results via the serial port. I tried and got > > nothing in the HyperTerminal. > > > > Does XST work for the synthesis ? If so, what modifications do I have > > to make ? > > > > (I was told that the only way is to get Synplify synthesis tool) > > > > Thanks > > > > Lan > > > > Peter Ryser <ryserp@xilinx.com> wrote in message news:<3F1F1FE4.B2A8FCB1@xilinx.com>... > > > Yes, it does. The reference design actually comes with the MLD (Microprocessor > > > Library Definition) technology that allows you to automatically generate a BSP > > > for Linux consisting of Xilinx layer 0 and 1 drivers according to the hardware > > > definition (MHS). When you generate the libraries from the system_linux.xmp > > > project file you will get this BSP. > > > > > > The BSP will also contain necessary patches to the Linux kernel to make the > > > design work with MontaVista Linux 3.0 (FYI: the only thing that needs to be > > > patched is the code for the Xilinx interrupt driver since the interrupt > > > controller from V2PDK and EDK are different) > > > > > > - Peter > > > > > > > > > tk wrote: > > > > > > > Hi Peter, > > > > > > > > I would like to ask if the reference design support > > > > MontaVista Linux Pro 3.0 ? > > > > > > > > Thanks very much! > > > > > > > > tk > > > > > > > > Peter Ryser wrote: > > > > > > > > > Antti, > > > > > > > > > > the EDK reference design for ML300 contains > > > > > - 1 PPC 405 > > > > > - 1 PLB DDR > > > > > - 1 PLB bus with arbiter > > > > > - 1 PLB2OPB bridge > > > > > - 1 PLB BRAM controller with 32 KB BRAM attached > > > > > - 1 OPB Uart > > > > > - 2 OPB GPIO > > > > > - 1 OPB 10/100 Ethernet (interrupt driven) > > > > > - 1 OPB IIC > > > > > - 1 OPB System ACE CF > > > > > > > > > > There is no touchscreen, PS/2, TFT, parallel port and AC97. Adding these > > > > > peripherals to the design is planned for a later release that will most > > > > > likely happen towards the end of the year. > > > > > > > > > > There is some documentation in the zip file that lists the peripherals and > > > > > explains the design. > > > > > Again, please contact your Xilinx FAE if you would like to get access to > > > > > this design. > > > > > > > > > > Thanks, > > > > > - Peter > > > > > > > > > > > > > > > > > > > > Antti Lukats wrote: > > > > > > > > > >> Peter Ryser <ryserp@xilinx.com> wrote in message > > > > >> news:<3F1846C0.776CD1F5@xilinx.com>... > > > > >> > > > > > >> > If you want to work with EDK please contact your FAE and ask him to get > > > > >> > you access to the EDK reference design for ML300. He will be able to > > > > >> > get you access to the design. > > > > >> > > > > >> Hi Peter, > > > > >> > > > > >> when we received the EDK + DDR project, I also asked to be notified > > > > >> when a better EDK ref. design will be available, and so far have not > > > > >> got any more info, could you please enlight us what additional cores > > > > >> are available in the EDK ref. design you mentioned? > > > > >> > > > > >> ASFAIK TFT and Touchscreen are not implemented (or hopefully are now?) > > > > >> I have still having trouble to get EDK to work correctly using the > > > > >> obsoleted TFT ref. design - eg. display is looking in stripes 8 pixels > > > > >> missing after 8 ok pixels - if the problem is fixed and ref design > > > > >> availabl would be greate. > > > > >> > > > > >> anttiArticle: 58855
The guy needs something he can do by himself on a bench - How about an Actel Accelerator part - (500K gates in a PQ208) or a ProASIC (150K gates in TQFP-100), These parts are also pretty routable - 90+% is a reasonable goal. I'm sure you can get a dev kit for a pretty reasonable price too. Plus - you can socket these (yamaichi - about 65 bucks - emulation technologies carries them) . But the sockets are a beast to put on. Packaging is getting bigger because the market is in high density I/O - but there are companies that can custom pack silicon (don't know any in Austrailia). I think that the volume for high core/low I/O is small, but I could be wrong. There are other manufacturers out there (I use many, more than the two that are up here most of the time - and have no real prejudices, just use what's best for the job). I think that Rob needs to look past CLB/LAB type thinking, and decide how many registers and gates he needs. Rob - do you have a multi-platform compiler (synplicity/synopsis/icarus) available - you might try to get an idea of size with compiles on various types of FPGA/CPLD technologies - then go at things from there. I used to run my own shop, and know about soldering chips on myself at midnight when I've been up for a couple of days - try using a bunch of flux and a bigger iron with regular solder - I learned from a lady at a rework shop after too much time goofing up (old IBM/Pemstar), and I no longer run paste except for ball type parts. Andrew James Horn wrote: >Hi, Rob - how much core? Would BGA packaging be OK? Your PLCC and PQFP >packages are around 30 mm squares. You can get the XC2V3000 Virtex-II in >a 676 pin PGA that's 27mm square - nearly 20% less board area. At 3M >gates / 14336 slices / 32256 logic cells / 1728 kbits of RAM / 96 >dedicated DSP multipliers and oodles more, I suspect it should be plenty >for most applications especially for someone who hasn't pushed one of >these puppies hard before (neither have I!). > >I'm sure Altera (which I've used much more) can do as well for you too. >Modern fine pitch BGAs are amazing packages! And compared to the cost of >designing the logic within it, your cost to a board house to mount it will >be many dB below the noise level. > >Best to you and your project - > >Jim Horn (Just a happy user of both companies' parts) > >Article: 58856
We will be designing with a large (xc2v6000) Virtex-II part in a ball-grid array package that has maybe ~1000 balls, but we are using fairly few (~250) "mission logic" I/O. Add in power & ground, configuration, etc., we will have 100's of general-purpose I/O balls that are not needed. What should we do with them? Ground them? Let them float? If we can let them float, do we even need a solder pad on the PWB for them to "land on"?Article: 58857
Andrew Paule wrote: > > The guy needs something he can do by himself on a bench - Now you've got it! > How about an Actel Accelerator part - (500K gates in a PQ208) or a > ProASIC (150K gates in TQFP-100), These parts are also pretty routable > - 90+% is a reasonable goal. I'm sure you can get a dev kit for a > pretty reasonable price too. Plus - you can socket these (yamaichi - > about 65 bucks - emulation technologies carries them) . But the sockets > are a beast to put on. As a matter of fact I discovered the Actel APA150 TQFP-100 yesterday on my wanderings around the internet, and it looks to be about what I was after. No configuration chip, reasonable size, more pins than I need but I can at least mount the sucker. My only qualm is that their IP is expensive and their tools ain't free, so I may go with the Altera Cyclone EP1C3 instead. I'll be ringing the local reps of both companies tomorrow. Most likely it will come down to who can actually deliver a sample part, which isn't necessarily easy to get inside three months here. Most agents (I wouldn't elevate them to distributor status) only keep parts on indent, and expect standing orders on a monthly drop before they'll even give you the time of day. > Packaging is getting bigger because the market is in high density I/O - > but there are companies that can custom pack silicon (don't know any in > Austrailia). I think that the volume for high core/low I/O is small, > but I could be wrong. Custom pack silicon?? Bwahahaha!!! We don't have anyone here who can even MAKE silicon since AWA closed their 1 micron plant about eight years ago. As for the volumes for high core / low I/O ... well, it seems to me there would be a lot of uses. In my current application I'm redeveloping a locally-designed 64-pin PQFP that was only delivered as an engineering sample and is no longer likely to ever be produced in volume. Unfortunately for me I found a lot of uses for it. It's a DSP chip with contimuous convolution in silicon and contains both the TDP and FDP. My plan is to shoehorn the micro in there as well, since it would save a lot of board acreage. If the part had more core I could also add the 768kb of DRAM it needs to operate, which was external on the development kit. But it doesn't need hundreds of pins, and there are a lot of other applications I could mention that meet the same needs. > There are other manufacturers out there (I use many, more than the two > that are up here most of the time - and have no real prejudices, just > use what's best for the job). I think that Rob needs to look past > CLB/LAB type thinking, and decide how many registers and gates he needs. I'm guessing at 150K minimum. The more the better, but not if it makes the device unmanageable as a side-effect. Many of the products I'll be developing with the resulting chip will be sold as kits, and more than likely to people with a lot fewer clues than you or I. > Rob - do you have a multi-platform compiler (synplicity/synopsis/icarus) > available - you might try to get an idea of size with compiles on > various types of FPGA/CPLD technologies - then go at things from there. > I used to run my own shop, and know about soldering chips on myself at > midnight when I've been up for a couple of days - try using a bunch of > flux and a bigger iron with regular solder - I learned from a lady at a > rework shop after too much time goofing up (old IBM/Pemstar), and I no > longer run paste except for ball type parts. I've managed to score some tools, they're not too hard to download off the net. How useful they are depends on whether they are general enough. I don't have any of the abovementioned and if they cost anything at all I'm unlikely to ever own them either ue to low usage. Whilst I can appreciate that proper development kits make live easier, I'd just rather get on with making the darned thing. To that end I'm also looking at SystemC, which is another good reason for more core. VHDL looks more like assembler to me and I'm an engineer, not a nitpicking bios author. :) This is not to say that I don't admire what you guys do. I'm totally impressed. But I'd rather find an algorithm that works and get a product out the door than contemplate forever the efficient profiling of, say, Reed-Solomon forward error correction to squeeze out another 0.3% from the chip. Hell, that's what optimising compilers are for, and at the volumes I'm likely to move it just isn't worth the trouble. I don't see fpga as a step toward asic building; I believe the day of the asic is gone, and that we're about to see an explosion of niche designs now that cost and utility of fpga has reached critical mass. And whoever can generate those designs will do ok. Anyhow, I've ranted enough. RobArticle: 58858
Hi,
I'm trying to use stacked 100Mbit ethernet modules with the Nios Development
Kit (Apex 20K) to create a secure firewall/bridge device for a university
project.
However, I can't even get the example application included with the kit,
"nedk_bridge.c" to work.
I have the nedk_bridge program running on the Apex board. Each ethernet
module is connected via crossover cable to a PC. I then try doing a simple
ping from one PC to the other and view the results using the Ethereal packet
sniffer:
1st PC's log:
No. Time Source Destination Protocol
Info
1 0.000000 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
2 1.280622 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
3 2.780724 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
4 4.280928 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
2nd PC's log:
No. Time Source Destination Protocol
Info
1 0.000000 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
2 0.000057 Xnet_Tec_0c:7a:72 Intel_63:47:c5 ARP
192.168.0.44 is at 00:05:1c:0c:7a:72
3 1.280476 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
4 1.280524 Xnet_Tec_0c:7a:72 Intel_63:47:c5 ARP
192.168.0.44 is at 00:05:1c:0c:7a:72
5 2.780418 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
6 2.780465 Xnet_Tec_0c:7a:72 Intel_63:47:c5 ARP
192.168.0.44 is at 00:05:1c:0c:7a:72
7 4.280453 Intel_63:47:c5 Broadcast ARP Who
has 192.168.0.44? Tell 192.168.0.115
8 4.280504 Xnet_Tec_0c:7a:72 Intel_63:47:c5 ARP
192.168.0.44 is at 00:05:1c:0c:7a:72
The 1st PC sends the ARP request, the 2nd PC receives it, replies to the
request, but the 1st PC never recieves the reply. The Nios for some reason
never sends the final packet. If I initiate the ping from the other PC, the
same thing happens - the first three packets are sent, but the last one is
dropped.
Is the Nios even capable of functioning for the purpose I want to use it
for? I noticed that the Nios always initializes the ethernet modules in
half-duplex mode. Altera themselves give frustratingly little info about
this.
I am using Quartus II 2.2, SOPC builder 2.52 (Nios CPU version 2.1), and
Nios EDK 2.0 (LAN91C111 modules).
Thanks,
Simon
Article: 58859Don't assign 'em - should do fine - they'll float. A solder pad is a good idea because these things come balled, and the solder will just float around and find something to connect to (most likely a nearby ball and give you a bridge - bit**) if you don't - talk to your assembly house. Andrew William LenihanIii wrote: >We will be designing with a large (xc2v6000) Virtex-II part in a ball-grid >array package that has maybe ~1000 balls, but we are using fairly few (~250) >"mission logic" I/O. Add in power & ground, configuration, etc., we will >have 100's of general-purpose I/O balls that are not needed. > >What should we do with them? Ground them? Let them float? If we can let them >float, do we even need a solder pad on the PWB for them to "land on"? > > > >Article: 58860
In article <PJ_Wa.50$tt6.60442@news.uswest.net>, Andrew Paule <lsboogy@qwest.net> wrote: >Packaging is getting bigger because the market is in high density I/O - >but there are companies that can custom pack silicon (don't know any in >Austrailia). I think that the volume for high core/low I/O is small, >but I could be wrong. No, its low. In volume, low I/O doesn't matter, but low board-space and low package cost does, as these are all auto-assembled. A manufacturer would rather have a part where 1/2 the IOs aren't used if the package itself is smaller & cheaper: just ignore the pins, unless the board fabrication technology is very VERY crude (eg, hand soldering). Thus the proliferation of .5 mm pitch flat-packs and 1 mm pitch BGAs and chip-scale BGA packages: these provide a low area and a lot of pins. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 58861
I've got two quick question. I don't have FPGA yet, but I want someone to offer me some quick comments 1. I have got to do some 64 bit integer comparison, actually I have to do up to 64 comparisons at the same time, the output is whether there is any pair that equals. 2. If I want to create an 16 bit address space, that would translate to 512 k bits, does Vertex II give enough block RAM so I don't have to use SRAM to do that? What kind of latency performance should I expect from typical SRAM, is 5ns read access reasonable?? what is the performance of block ram?? Thanks, JimmyArticle: 58862
"Rob Judd" <judd@ob-wan.com> wrote in message = news:3F2A43B1.886F82BB@ob-wan.com... > Kolja, >=20 > I'll buy this statement about distribution. Larger companies seem to > completely forget that one successful design can propel a garage > start-up into a megalith. Or so we all keep hoping. :) >=20 > Sales sections in large distribution companies only bother with = existing > large clients, because it's what pays immediately. This is very myopic > thinking but that's the nature of sales. If they're having a slow day > they still won't do your quote, being more inclined to spend their = time > plotting how to steal more major customers from the opposition = instead. >=20 > I'll tell you something else about this game - manufacturers, are you > listening? - is that a distributor that doesn't keep stock of common > component families doesn't deserve to be a distributor. That rule = alone > would exclude every major electronics supplier here in Australia. If I > have to wait three months for parts, why the hell can't I buy them > direct across the 'net? Agreed. =20 > And before anyone screams about how hard it is to do web commerce, I'd > like to point out that I worked on a project to convert an = international > employment agency to a totally web-based business, and it wasn't = really > that hard. Think M*np*w*r. >=20 > Rob The details the local distributors here(Australia) ask for and the reputations and the way some of them work means most people give them false details of projects. Most of them do contract design work and it means you are competing for work directly with the distributors you are buying from. Dealt with a couple who refuse to sell unless you tell which company you are doing the work for, the contact details of the person you deal with etc. Thats when I hang up. The local xilinx distributors have been great. Alex GibsonArticle: 58863
Hey Rob: The Actel part would be a good call - icarus is free (http://www.icarus.com/eda/verilog) - what ip do you need - see opencores.org (or email me back) - if you need a good actel rep -I've been dealing with them in the US for some time - gimme a ping outside the newsgroup - they are very good - I can get you sample parts far faster than that from here - my brother in law will be in your part of the world at the end of the month, and I can get anything from anywhere inside a month with current delivery methods - including aust. and africa. Check out verilog - I've used this as a "semi C" variant - the include files with a quick script make them almost transparent - if you know hardware, this is the language (can you say Intel, Teradyne, Schlumberger, LSI etc), been a "verilogger" for too many years, easy language to learn. and I'm with you - owned my own shop, know the difference between money and glamour - laid off, but able to deal with it because of this - need a job in the next year or so. Andrew Rob Judd wrote: >Andrew Paule wrote: > > >>The guy needs something he can do by himself on a bench - >> >> > >Now you've got it! > > > >>How about an Actel Accelerator part - (500K gates in a PQ208) or a >>ProASIC (150K gates in TQFP-100), These parts are also pretty routable >>- 90+% is a reasonable goal. I'm sure you can get a dev kit for a >>pretty reasonable price too. Plus - you can socket these (yamaichi - >>about 65 bucks - emulation technologies carries them) . But the sockets >>are a beast to put on. >> >> > >As a matter of fact I discovered the Actel APA150 TQFP-100 yesterday on >my wanderings around the internet, and it looks to be about what I was >after. No configuration chip, reasonable size, more pins than I need but >I can at least mount the sucker. My only qualm is that their IP is >expensive and their tools ain't free, so I may go with the Altera >Cyclone EP1C3 instead. I'll be ringing the local reps of both companies >tomorrow. Most likely it will come down to who can actually deliver a >sample part, which isn't necessarily easy to get inside three months >here. Most agents (I wouldn't elevate them to distributor status) only >keep parts on indent, and expect standing orders on a monthly drop >before they'll even give you the time of day. > > > >>Packaging is getting bigger because the market is in high density I/O - >>but there are companies that can custom pack silicon (don't know any in >>Austrailia). I think that the volume for high core/low I/O is small, >>but I could be wrong. >> >> > >Custom pack silicon?? Bwahahaha!!! We don't have anyone here who can >even MAKE silicon since AWA closed their 1 micron plant about eight >years ago. As for the volumes for high core / low I/O ... well, it seems >to me there would be a lot of uses. > >In my current application I'm redeveloping a locally-designed 64-pin >PQFP that was only delivered as an engineering sample and is no longer >likely to ever be produced in volume. Unfortunately for me I found a lot >of uses for it. It's a DSP chip with contimuous convolution in silicon >and contains both the TDP and FDP. My plan is to shoehorn the micro in >there as well, since it would save a lot of board acreage. If the part >had more core I could also add the 768kb of DRAM it needs to operate, >which was external on the development kit. > >But it doesn't need hundreds of pins, and there are a lot of other >applications I could mention that meet the same needs. > > > >>There are other manufacturers out there (I use many, more than the two >>that are up here most of the time - and have no real prejudices, just >>use what's best for the job). I think that Rob needs to look past >>CLB/LAB type thinking, and decide how many registers and gates he needs. >> >> > >I'm guessing at 150K minimum. The more the better, but not if it makes >the device unmanageable as a side-effect. Many of the products I'll be >developing with the resulting chip will be sold as kits, and more than >likely to people with a lot fewer clues than you or I. > > > >>Rob - do you have a multi-platform compiler (synplicity/synopsis/icarus) >>available - you might try to get an idea of size with compiles on >>various types of FPGA/CPLD technologies - then go at things from there. >>I used to run my own shop, and know about soldering chips on myself at >>midnight when I've been up for a couple of days - try using a bunch of >>flux and a bigger iron with regular solder - I learned from a lady at a >>rework shop after too much time goofing up (old IBM/Pemstar), and I no >>longer run paste except for ball type parts. >> >> > >I've managed to score some tools, they're not too hard to download off >the net. How useful they are depends on whether they are general enough. >I don't have any of the abovementioned and if they cost anything at all >I'm unlikely to ever own them either ue to low usage. Whilst I can >appreciate that proper development kits make live easier, I'd just >rather get on with making the darned thing. To that end I'm also looking >at SystemC, which is another good reason for more core. VHDL looks more >like assembler to me and I'm an engineer, not a nitpicking bios author. >:) > >This is not to say that I don't admire what you guys do. I'm totally >impressed. But I'd rather find an algorithm that works and get a product >out the door than contemplate forever the efficient profiling of, say, >Reed-Solomon forward error correction to squeeze out another 0.3% from >the chip. Hell, that's what optimising compilers are for, and at the >volumes I'm likely to move it just isn't worth the trouble. > >I don't see fpga as a step toward asic building; I believe the day of >the asic is gone, and that we're about to see an explosion of niche >designs now that cost and utility of fpga has reached critical mass. And >whoever can generate those designs will do ok. > >Anyhow, I've ranted enough. > >Rob > >Article: 58864
"Paul Leventis" <paul.leventis@utoronto.ca> wrote in message news:<2VBWa.45716$hOa.41942@news02.bloor.is.net.cable.rogers.com>... > > Ten years ago, these numbers had some meaning (frequency or prop delay) > > but we all gave up on that. In most cases, a larger number means faster, > > but I would check that in the data sheet. > > It depends on the manufacturer. On Altera's FPGAs (at least, the recent > ones), a "-5" device is faster than a "-7" device. > > Regards, > > Paul Leventis > Altera Corp. It's true for the Stratix family. For the FLEX/ACEX families "-1" means the fastest and "-3" means the slowest. For the MAX CPLDs speed grade numbers still retain some physical meaning. Is it pin-to-pin delay ? A consistency rules !Article: 58865
I'd also advise bringing a bunch of them out to either a pad or a via that you have access to. Just in case you need to make a change and need more I/O :-). If you can bring them all out, then you (or the board house) can do boundary scan testing to ensure that all of the balls are connected. Andrew Paule wrote: > Don't assign 'em - should do fine - they'll float. > A solder pad is a good idea because these things come balled, and the > solder will just float around and find something to connect to (most > likely a nearby ball and give you a bridge - bit**) if you don't - talk > to your assembly house. > > Andrew > > William LenihanIii wrote: > >> We will be designing with a large (xc2v6000) Virtex-II part in a >> ball-grid >> array package that has maybe ~1000 balls, but we are using fairly few >> (~250) >> "mission logic" I/O. Add in power & ground, configuration, etc., we will >> have 100's of general-purpose I/O balls that are not needed. >> >> What should we do with them? Ground them? Let them float? If we can >> let them >> float, do we even need a solder pad on the PWB for them to "land on"? >> >> >> >> > -- Marc Guardiani To reply directly to me, use the address given below. The domain name is phonetic. fpgaee81-at-eff-why-eye-dot-netArticle: 58866
And just to add a little spice to that broth, it was suggested one of the local Xilinx support folks on our last design to ground all the unused IOB pins and create more of a "virtual ground" (their term, not mine). "William LenihanIii" <lenihan3we@earthlink.net> wrote in message news:5V_Wa.31676$Mc.2501134@newsread1.prod.itd.earthlink.net... > We will be designing with a large (xc2v6000) Virtex-II part in a ball-grid > array package that has maybe ~1000 balls, but we are using fairly few (~250) > "mission logic" I/O. Add in power & ground, configuration, etc., we will > have 100's of general-purpose I/O balls that are not needed. > > What should we do with them? Ground them? Let them float? If we can let them > float, do we even need a solder pad on the PWB for them to "land on"? > >Article: 58867
Anyone any experience with the FPSLIC devices ? They have several packages with low pin count (84 PLCC, 100 VQFP, 144 TQFP). Only up to 40Kgates FPGA (2800 registers), but you do have a processor core, and several peripherals, and 32Kbytes + 16 Kbytes of memory already built-in. Marc "Rob Judd" <judd@ob-wan.com> wrote in message news:3F2A9152.CE7DFE2A@ob-wan.com... > Nicholas, > > No, manufacturability is the main concern. I don't have easy access to > high volume production machinery, which is almost guaranteed to be > necessary for most of the newer packages. If I can plug it in, great. If > not, I need to be able to hand-solder it with a standard Weller iron. > > Rob > > > Nicholas C. Weaver wrote: > > > > In article <3F2A4153.66C411AD@ob-wan.com>, Rob Judd <judd@ob-wan.com> wrote: > > >Hi, > > > > > >My application requires a lot of core but few physical i/o lines. Can > > >anyone suggest a modern fpga that is delivered in a 68-pin plcc and/or > > >80-pin pqfp package? > > > > Is your concern board area? Hand soldering? Cost? > > > > A small BGA package might be appropriate, as a .5mm spacing BGA for a > > small pincount is really tiny, if the concerns are board area and > > cost. > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 58868
zhengyu wrote: > > I've got two quick question. I don't have FPGA yet, but I want someone to > offer me some quick comments > > 1. I have got to do some 64 bit integer comparison, actually I have to do up > to 64 comparisons at the same time, the output is whether there is any pair > that equals. This is not a question... :) Equality compares are easy. It uses a two input XOR for each bit with all the results being OR'd together. This will take 32 LUTs for the XOR and the first OR gate and 11 more LUTs to combine the rest for a total of 43 LUTs in four levels. If the design uses the "special" features that most chips have (ORing of LUTs within a CLB), you can use the LUTs in pairs or even groups of four and reduce the number of levels for speed. > 2. If I want to create an 16 bit address space, that would translate to 512 > k bits, does Vertex II give enough > block RAM so I don't have to use SRAM to do that? What kind of latency > performance should I expect from > typical SRAM, is 5ns read access reasonable?? what is the performance of > block ram?? Is that 16 bit address (64k words) of 8 bit words? Because 64k x 8 = 512K. You can get this much RAM in the VirtexII if you use the XC2V500 part. Or in the new Spartan3 you could use a XC3S1500. I am not sure which will be cheaper, but I bet it is the Spartan3. The speed of the block RAM will be much faster than anything external to the FPGA. The block ram will be synchronous and lends itself well to pipelined operations. A lot of how you design will be implemented will depend on your data flow which you have said nothing about. Think about how the storage will be orgainized and accessed. Obviously one large block of memory with one interface will not let you do 64 compares at one time. If you rate of performing these compares is not fast, you can use one compare logic block and run the different data through it sequentially. Then one memory could easily do the job. -- 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: 58869
I have gotten a design to the point where I am running a simulation and I have having a problem with the test bench. It has multiple processes (just two for now) to handle the control file input and the various bus interfaces that will be controlled. A couple of BOOLEAN signals are used to synchronize processes. That is where my problem seems to be. The control process sets a BOOLEAN signal "Start". The bus Process detects the flag and models the bus transfer. So far so good. There is a return BOOLEAN signal, "Busy" that tells the control process that the bus cycle is in progress. This flag is cleared before the transaction is complete because the way the bus transaction ends depends on whether another transaction is back to back. So the "Busy" flag is removed before the transaction is complete. This allows the controller to reset the "Start" flag if ready. By seeing that the "Start" flag is set, the bus controller finishes the cycle differently and reaches the end of the process. At the top of this process, it waits for the "Start" signal again, but if the "Start" flag is already set, it hangs. So does a wait statement always perform an edge detect by default? Even when it is initially executed, it does not check the condition clause, but rather pends on a change in one of the signals in the condition clause and only then checks the condition? Here is my wait statement... wait until ARM_Bus_Start or rising_edge(Reset); If ARM_Bus_Start is already set when this executes, the process hangs here. I am using ModelSim XE II/Starter 5.6e. -- 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: 58870
Yes, the chip is out there, but how many are using it? How long will this still be an avaiable product? Marc Van Riet wrote: > > Anyone any experience with the FPSLIC devices ? They have several packages > with low pin count (84 PLCC, 100 VQFP, 144 TQFP). Only up to 40Kgates FPGA > (2800 registers), but you do have a processor core, and several peripherals, > and 32Kbytes + 16 Kbytes of memory already built-in. > > Marc > > "Rob Judd" <judd@ob-wan.com> wrote in message > news:3F2A9152.CE7DFE2A@ob-wan.com... > > Nicholas, > > > > No, manufacturability is the main concern. I don't have easy access to > > high volume production machinery, which is almost guaranteed to be > > necessary for most of the newer packages. If I can plug it in, great. If > > not, I need to be able to hand-solder it with a standard Weller iron. > > > > Rob > > > > > > Nicholas C. Weaver wrote: > > > > > > In article <3F2A4153.66C411AD@ob-wan.com>, Rob Judd <judd@ob-wan.com> > wrote: > > > >Hi, > > > > > > > >My application requires a lot of core but few physical i/o lines. Can > > > >anyone suggest a modern fpga that is delivered in a 68-pin plcc and/or > > > >80-pin pqfp package? > > > > > > Is your concern board area? Hand soldering? Cost? > > > > > > A small BGA package might be appropriate, as a .5mm spacing BGA for a > > > small pincount is really tiny, if the concerns are board area and > > > cost. > > > -- > > > Nicholas C. Weaver > nweaver@cs.berkeley.edu -- 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: 58871
Hi Rick,
The condition in a wait statement is checked only when an event occure
on one of the signal include in the condition. A wait is like a process with
sensitivity list: process is executed only when an event occure on one or
more of the signal in the sensitivity list.
A change from true to true is not an event but is a transaction so you can
try something like this:
wait on ARM_Bus_Start'transaction, reset until ARM_Bus_Start or Reset =
'1';
The signal bit ARM_Bus_Start'transaction will toggle each time a transaction
occure on ARM_Bus_Start and this will create an event change for the wait
statement.
regards
FE
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F2D3AA5.D1D274D2@yahoo.com...
> I have gotten a design to the point where I am running a simulation and
> I have having a problem with the test bench. It has multiple processes
> (just two for now) to handle the control file input and the various bus
> interfaces that will be controlled. A couple of BOOLEAN signals are
> used to synchronize processes. That is where my problem seems to be.
>
> The control process sets a BOOLEAN signal "Start". The bus Process
> detects the flag and models the bus transfer. So far so good. There is
> a return BOOLEAN signal, "Busy" that tells the control process that the
> bus cycle is in progress. This flag is cleared before the transaction
> is complete because the way the bus transaction ends depends on whether
> another transaction is back to back.
>
> So the "Busy" flag is removed before the transaction is complete. This
> allows the controller to reset the "Start" flag if ready. By seeing
> that the "Start" flag is set, the bus controller finishes the cycle
> differently and reaches the end of the process. At the top of this
> process, it waits for the "Start" signal again, but if the "Start" flag
> is already set, it hangs.
>
> So does a wait statement always perform an edge detect by default? Even
> when it is initially executed, it does not check the condition clause,
> but rather pends on a change in one of the signals in the condition
> clause and only then checks the condition?
>
> Here is my wait statement...
>
> wait until ARM_Bus_Start or rising_edge(Reset);
>
> If ARM_Bus_Start is already set when this executes, the process hangs
> here.
>
> I am using ModelSim XE II/Starter 5.6e.
>
> --
>
> 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 FAX
Article: 58872rickman wrote: > . . . > differently and reaches the end of the process. At the top of this > process, it waits for the "Start" signal again, but if the "Start" flag > is already set, it hangs. > > So does a wait statement always perform an edge detect by default? No. You can wait UNTIL an expression has a value of true or you can wait ON a signal_id for *any* value change. > Here is my wait statement... > wait until ARM_Bus_Start or rising_edge(Reset); > If ARM_Bus_Start is already set when this executes, the process hangs > here. Consider View, Source and setting some breakpoints. Run/step code and watch the signals. Either the wait is in a different process or ARM_Bus_Start is not true at the right time. -- Mike TreselerArticle: 58873
40K gates is way too small for anything I'm considering, and the "added value" stuff just wastes internal space. We all know where to find AVR core and serial if we want it. Rob Marc Van Riet wrote: > > Anyone any experience with the FPSLIC devices ? They have several packages > with low pin count (84 PLCC, 100 VQFP, 144 TQFP). Only up to 40Kgates FPGA > (2800 registers), but you do have a processor core, and several peripherals, > and 32Kbytes + 16 Kbytes of memory already built-in. > > Marc > > "Rob Judd" <judd@ob-wan.com> wrote in message > news:3F2A9152.CE7DFE2A@ob-wan.com... > > Nicholas, > > > > No, manufacturability is the main concern. I don't have easy access to > > high volume production machinery, which is almost guaranteed to be > > necessary for most of the newer packages. If I can plug it in, great. If > > not, I need to be able to hand-solder it with a standard Weller iron. > > > > Rob > > > > > > Nicholas C. Weaver wrote: > > > > > > In article <3F2A4153.66C411AD@ob-wan.com>, Rob Judd <judd@ob-wan.com> > wrote: > > > >Hi, > > > > > > > >My application requires a lot of core but few physical i/o lines. Can > > > >anyone suggest a modern fpga that is delivered in a 68-pin plcc and/or > > > >80-pin pqfp package? > > > > > > Is your concern board area? Hand soldering? Cost? > > > > > > A small BGA package might be appropriate, as a .5mm spacing BGA for a > > > small pincount is really tiny, if the concerns are board area and > > > cost. > > > -- > > > Nicholas C. Weaver > nweaver@cs.berkeley.eduArticle: 58874
Hello, Where can I find the synthetisable RAM model of Proasic APA300 RAM for synopsys or Leonardo synthetiser? Thanks 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