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
Marco T. wrote: > Hallo, > I bought recently a notebook with only usb, firewire, ethernet and 1 pcmcia > connectors. > > I use Parallel Cable IV. I have bought a ps/2 to usb and a parallel to usb > cables. > > But parallel to usb seems to function only with parallel printers. > > Do you know a all-in-one port replicator with usb, serial and ps/2 > connectors that works with Parallel Cable IV? > > Many Thanks > Marco > > Users of Amontec Chameleon POD ( generic JTAG interface dongle ) buy Quatech SPP-100 PCMCIA for resolving this. You may remap any parallel port address to the SPP-100. Work just nice ! Let me know if you do not find Quatech reseller. We have a large stock of SPP-100! ( Or buy a new Xilinx USB cables! ) Best regards, Laurent www.amontec.com ___________________________ Unlocking the power of JTAGArticle: 96251
Ben Marpe wrote: > My attempt would be a LUT in BRAM - but do I have to fill its content > manualy ? The LUT content (e.g. 16bit) could drive a DAC. There's probably some other way to do it, but I'd just write a quick program in C or whatver that generates the table in a format compatible with your HDL or BRAM initializer. Xilinx has a tool which takes a while to figure out but lets you insert such data into the already generated bitstream - used it a lot to change the program of a soft core processor without rebuilding the design. One thing that can be a bit of a pain is getting the data to be there in both simulation and in the bitsream - often you have to put it in twice. If the table isn't very big, encoding it in the HDL might be simplest?Article: 96252
Sean Durkin wrote: > Marco T. wrote on 01.02.2006 09:56: > >>Do you know a all-in-one port replicator with usb, serial and ps/2 >>connectors that works with Parallel Cable IV? > > Haven't been able to find one of those either... The problem seems to be > that iMPACT/Chipscope don't recognize the "virtual" LPT-ports those port > replicators usually provide... > There are parallel-port-controllers for Cardbus/PCMCIA you can plug in > to get a "real" parallel port on your laptop, but I haven't tried any of > those, so I can't comment on how good they are. > The problem is the chipset: to get decent programming speeds, the > parallel port should support 2MHz or 5MHz operation. All > PCI-plugin-cards I've seen in stores lately use the same cheap > controller-chip that doesn't support operation above 1MHz, so the cable > will work in compatibility mode and drop down to 200kHz. > > Instead, I suggest buying a Platform USB cable. Gives you much less > trouble in the long run, and works well on every modern machine. > ... if you can afford it, that is. I think it's $150, so about double > what the parallel cable costs. Plus, I'm not sure if it works under > Linux, but there have been discussions about that here lately. > > cu, > Sean If you are programming through the JTAG interface, you could try the Diligent USB-JTAG cable, which is under $40.Article: 96253
I performed a similar search a couple of years ago and came up with little. I believe the FPGA companies don't want people to know exactly how big these dies are in comparison to ASICs. I was, however, able to get some information from Semiconductor Insights (www.semiconductor.com) for use in a paper, provided that I referenced them. They dissect chips and sell reports on them. You can try contacting them, but they will only know the sizes of a few parts that they examined. It should be straightforward, however, to extrapolate to other devices. They told me that the xc2vp20 was 14.0mm x 11.4mm = 160 mm2 in a 130 nm process. This compares to a Pentium in the same process with dimensions 12.2 mm x 12.0mm = 146mm2, and a Pentium Prescott, in a 90 nm process, with an area of 10.8mm x 10.3mm = 111 mm2. So you can see why perhaps Xilinx is mum about die sizes. A smaller 2vp part is bigger than a P4 in the same process. Hope this helps, StephenArticle: 96254
Ben Marpe wrote: > Hi everybody, > > I'm trying to implement a BPSK modulation. > A sin waveform has to be generated at a given frequency (1MHz) with > phase offset (binary PSK i.e. 180°) when transition occures on a data > wire. > > Is there any "simple" LogiCORE with BPSK functionality available for my > Xilinx Spartan-3 - Board ? > > My attempt would be a LUT in BRAM - but do I have to fill its content > manualy ? The LUT content (e.g. 16bit) could drive a DAC. > > On the other hand, If I'm forced to use a external DAC, I might use a > DDS (e.g. AD9834) with all BPSK functionality on chip... ?!? > > I'm interested in your ideas and suggestions ! > > Bye, BEN > Since your frequency is only 1 MHz, and assuming you have a clock source where you can get, say 80 Mhz, you can do the DAC as s sigma-delta DAC in the FPGA, then all you need outside the FPGA is a resistor and capacitor. A LUT implemented with block RAM should give you a pretty clean sine output. Perhaps the easiest way to fill the LUT (assuming you are using VHDL) is to use excel, matlab, or C to produce one cycle of sine sampled at your desired pahse resolution as a rounded integer y= round(2^bits * sin(2*pi*n/resolution)), then cut and paste that data into a constant integer array in your VHDL, then convert the integer to the bit vector needed by the BRAM INIT= attribute using a VHDL function. Alternatively, you could generate ascii binary in your external application and past that into an array of bit_vectors directly.Article: 96255
David Brown schrieb: > If Xilinx' tools also have such verbatim copying through to the > generated bitstreams, and they do not have such stated exceptions, then > they are in a position (in my interpretation - IANAL) to claim joint > copyright ownership of the bitstream. In germany falsely claiming copyright ownership is a crime that can be punished by 5 years in prison, so Xilinx should make sure it only claims joint ownership if there are such parts in the bitstream. Think about connecting input to output in FPGA editor with a wire. Kolja SulimmaArticle: 96256
fpga_toys@yahoo.com wrote: > So, back to the question of worst case designs for supporting RC. > > What are the worst case VccInt currents that various packages will > handle? How does that relate to what is necessary for balancing the > design across multi phase clocks to spread the current spikes following > clock edges in time? You won't be limited by the current carrying capabilities of the wires. It's the thermal that will limit you. Flip-chip packages can deal with a lot more heat and they can deal with a lot more current. You're probably concerned about the wire bond packages but those have higher thermal resistance, limiting the amount of power. > Is there any means to get a handle on the current time spread profile > by knowing the distribution of routing lengths and logic depths for > each clock? To keep working under high speed *or* low speed conditions, the current effects from a single clock edges *must* be mitigated in the first few hundred picoseconds by distributed capacitance on the FPGA silicon and package. The "high frequency" capacitance needed externally is typically for the Gigahertz and below frequency range. The nice thing here is that the huge super-short current spikes don't need much capacitance to keep the voltage up. Proper decoupling needs an understanding of what the biggest current steps are in the applicable frequency range. We don't need to know the current "surge" at each clock edge in these devices; the worst case condition for this worry of yours is one single clock distributed across the chip. Single clock synchronous designs make up a large number of FPGA designs. There aren't problems. It's when you go from nearly no activity to massive activity (or back) that the external decoupling and power regulation needs to handle the massive change in current. This is design. > I assume ground pads are shared between VccInt and I/O? If so, how > would one combine worst case VccInt ground currents with the worst case > I/O ground switching currents for a worst case package level design > spec? Again, stop thinking that the wires will cause you problems. Your balls won't vaporize and your wires bonds won't fuse because the quantity and distribution of power in the FPGAs accommodates some nasty design corners. If you can remove the heat, you can source the current. If this wasn't the case there would be a significantly larger population than you freaking over the power. Symon was going over some thermal resistance values in another response. It's that level of engineering needed for proper heat sing desing. I did a quick look at the Aavid embedded fan heat sink for a XIlinx part when you were first blowing the design issues out of proportion. The junction-to-case, thermal interface material, and heat sink had thermal resistance values of 0.1 C/W, 0.2 C/W, and 1.38C/W (I think that's "respectively"). If you were designing for 40W in 45C ambient with 125C die temperature, everything's fine with that simple "active" heat sink. The 125C is the temperature you mentioned in an earlier post but the commercial and industrial *operating* die temps are lower than the "absolute maximum" junction temperature value you referenced, at 85C and 100C for the Virtex-4 series, respectively. See the ordering information for the junction temperature ranges. So in the example above you'd need a better solution than that convenient small embedded-fan heat sink. The processor heat sinks demonstrate thermal resistance values far below the 1.38C/W for this one heat sink. Proper selection - or design - of the heat sinks are required to meet your maximum operating power and maximum operating ambient temperature.Article: 96257
Hi There. Xilinx CPLD XCR3384XL with speed grade -7 have (according to the datasheet) a maximum clock frequency at 135MHz. How have they found that number? I have some timing problems on a FPGA and that trigged my curiousity. (I am assuming that they use a likewise method to find the maximum clock frequency in CPLDs and FPGAs, (but I'm not sure)). RaymondArticle: 96258
"John_H" <johnhandwork@mail.com> wrote in message news:__3Ef.16063$oo1.12158@trnddc02... > fpga_toys@yahoo.com wrote: >> So, back to the question of worst case designs for supporting RC. >> >> What are the worst case VccInt currents that various packages will >> handle? How does that relate to what is necessary for balancing the >> design across multi phase clocks to spread the current spikes following >> clock edges in time? > > You won't be limited by the current carrying capabilities of the wires. > It's the thermal that will limit you. Flip-chip packages can deal with a > lot more heat and they can deal with a lot more current. You're probably > concerned about the wire bond packages but those have higher thermal > resistance, limiting the amount of power. > Hi John, Indeed! I didn't even consider the OP meant the current carrying capabilities of the wires when I replied. Cheers, Syms. p.s. I'm glad my "balls won't vaporize"! :-)Article: 96259
cs_posting@hotmail.com wrote:
> One thing that can be a bit of a pain is getting the data to be there
> in both simulation and in the bitsream - often you have to put it in
> twice. If the table isn't very big, encoding it in the HDL might be
> simplest?
>
Yes, that is a pain. The generics for simulation want a bitvector,
while the attributes for passing to the PAR tools want hex strings.
Rather than enter the tables twice in different formats (and possibly
getting a simulation mismatch), I find it easier to use a VHDL function
to do the conversion of the bit vector to HEX:
function bv2hex (val:bit_vector) return string is
type hex_lut is array (0 to 15) of character;
constant hextable:hex_lut :=
('0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', 'A', 'B', 'C', 'D', 'E', 'F');
constant str_len:natural:=(val'length+3)/4;
variable temp:integer;
variable ret_string: string(str_len downto 1);
begin
temp:=0;
for j in 0 to val'length-1 loop
if val(j)='1' then
temp:=temp + 2**(j mod 4);
end if;
if (j mod 4)=3 or j=val'length-1 then
ret_string(j/4+1):= hextable(temp);
temp:=0;
end if;
end loop;
return ret_string;
end bv2hex;
Article: 96260Kolja Sulimma wrote: > In germany falsely claiming copyright ownership is a crime that can be > punished by 5 years in prison, so Xilinx should make sure it only claims > joint ownership if there are such parts in the bitstream. Hmm, and what about falsely accusing someone of a crime? > Think about connecting input to output in FPGA editor with a wire. May very well instantiate a non-trivial "straight through" bit pattern, or more likely several necessary patterns - really you have to configure two fairly complex IOB's, and a bunch of routing resources. And I wouldn't be suprised if there's some pattern of bits you need to put in unused areas of the chip to optimally idle them. Also, even if there are no verbatim bits, think about this. Say instead of running the software on your computer, you had to send your HDL to Xilinx and they sent you back a bitstream. Clearly they can claim some ownership rights to that, unless they signed away the rights under a work-for-hire type of contract. It would appear that their tools license is basically implying that this is what is going on, only as a convenience for fast turnaround they are letting you borrow the software to run on your computer. From the software industry perpsective, you can't purchase software the way you can purchase something like a drillpress - though it's unclear if all legal systems will uphold that view in all circumstances, especially things like software bundled with boxed retail eval kits.Article: 96261
hi I am trying to implement new bus macro "busmacro_xc2vp_l2r_async_na rrow.nmc" in ISE 8.1.01i, while following error is encountered. It seems that ISE 8.1 does not support this format. Then is anyone aware that which version (if any) support these latest BUTF bus macro ? ------------------------------------------------------------------------------------------------------------------------- WARNING:Pds - Attempted to load old format .nmc file "C:\Xilinx\Work\Partial_Ex_AND_CSPro\Full\TOP\Top/busmacro_xc2vp_l2r_async_na rrow.nmc", but this format is no longer supported. FATAL_ERROR:NgdBuild:Portability/export/Port_Main.h:127:1.5 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.comArticle: 96262
Symon wrote: > Assuming best case heatsinking, we can keep the case at c.0K with a perfect > liquid Helium cooled heatsink. Therefore we can dissapate 358/0.36 = 1000W. > Vccint can be 1.14V, so that's a maximum current of about 870A. > > Now do you see why you're asking the wrong question? ;-) Of course my > example is a ridululous exaggeration, but your posting provided little to go > on. You need to do a proper analysis with thermal simulation tools to get a > meaningful answer, and even when you get that answer it'll be wrong! If we were talking about mounting bare die to my pcb your answer would be close. Now, what is the voltage drop from my pcb pads to the die at 870A for both the ground and VccInt paths? Those little tiny balls, via's and traces on the chip carrier PCB have just enough cross sectional area to be called fuses. And not enough cross sectional area to avoid a voltage drop.Article: 96263
Hi what do you mean for the Block diagram? are you trying to design a STMx in an FPGA? Few years ago I designed an STM4, and I may give you some tips. FrancescoArticle: 96264
Well, my design really needs only ARP, ICMP ECHO, and UDP. My MAC/stack, instead of handling the various layers of the OSI model, treats each frame as simply having one really long header. So my "MAC" isn't separable from the code that handles the IP, UDP, and application headers (the ultimate datagram payload). I didn't use some open core MAC because I didn't want to build a whole stack of software to support it -- the Spartan3 PicoBlaze only supports a 1K instruction space. I just wanted to develop a simple peripheral that treats the UDP/Ethernet as a complicated serial port. I have one PicoBlaze handling Ethernet receive (through UDP), one handling application headers and payload (that doesn't even get involved in ARP and ICMP ECHO), and one handling Ethernet Transmit (UDP down through collision detect/backoff). Dedicated hardware computes FCS checksums and residues. For your research, Francesco: I'm only interested in 10BASE-T, where the PicoBlaze running at about 40MIPS was fine to handle everything including shooting the nibbles out the MII. For 100BASE-T, I would have to add more hardware to manage that. At only maybe 400 instructions in one processor and 700 in another, assembly programming was fine. Anyway, the board already exists; I'm not in a position to add AVRs or PICs. Anyone know if Avnet/Memec have an example design (already verified) that I can pop into their S3MB card to simply handle 10BASE-T ICMP ECHOs? Or are there other considerations of the Broadcom 5221 PHY or known bugs I should have to deal with to resolve this? Can a Windows PC accept my reply frames sent within 40us of the end of the requesting frame? Thanks. twv@Article: 96265
On 1 Feb 2006 07:41:04 -0800, "Francesco" <francesco.poderico@trendcomms.com> wrote: >Hi what do you mean for the Block diagram? >are you trying to design a STMx in an FPGA? > >Few years ago I designed an STM4, and I may give you some tips. Ditto for STM64. AllanArticle: 96266
<fpga_toys@yahoo.com> wrote in message news:1138808303.733536.253170@g44g2000cwa.googlegroups.com... > > Now, what is the voltage drop from my pcb pads to the die at 870A for > both the > ground and VccInt paths? > > Those little tiny balls, via's and traces on the chip carrier PCB have > just enough > cross sectional area to be called fuses. And not enough cross sectional > area to > avoid a voltage drop. > You're forgetting that the liquid helium cooling we've designed in has made your tiny balls into super-conductors. Both Lead and Tin are Type 1 superconductors. (Not sure about the solder alloy though, maybe you need RoHS parts?) You now only need to find the current that causes the critical magnetic field strength above which the superconductivity stops. Sadly, gold and copper don't superconduct; their lattice vibrations are too small. (Hint :- Think Cooper pairs.) However, the liquid helium should stop them vaporizing. All we need to do is turn up the external Vccint a little to compensate for the voltage drop in the traces and bond wires thus keeping the Vccint on the die in spec. :-) See how crazy this gets without enough data to work on? Cheers, Syms.Article: 96267
I actually did follow your instructions. I was having problems with the flow control which I had to fix before I could get back to your instructions. Thanks eitherways.Article: 96268
Symon wrote: > You're forgetting that the liquid helium cooling we've designed in has made > your tiny balls into super-conductors. Both Lead and Tin are Type 1 > superconductors. (Not sure about the solder alloy though, maybe you need > RoHS parts?) You now only need to find the current that causes the critical > magnetic field strength above which the superconductivity stops. > Sadly, gold and copper don't superconduct; their lattice vibrations are too > small. (Hint :- Think Cooper pairs.) However, the liquid helium should stop > them vaporizing. All we need to do is turn up the external Vccint a little > to compensate for the voltage drop in the traces and bond wires thus keeping > the Vccint on the die in spec. > :-) > See how crazy this gets without enough data to work on? > Cheers, Syms. No, only the heat spreader is at 0K, the die is at max temp, and the FR-4 to my pcb would have to assume chip temp less free air heat losses. Shall we review your calcs assuming the die was at commerical temp limits?Article: 96269
On 1 Feb 2006 04:18:23 -0800, "nhurley" <noelhurley@googlemail.com> wrote: >Hi Guys > >I'm looking for some die area information on FPGAs. It is prooving >quite difficult to find any information so if anyone has some pointers >or datapoints it'd be much appreciated. > >Thanks! I have made (wild) estimates of die size for all Xilinx products here: http://www.fpga-faq.org/compare/build_form.cgi Have fun, Philip Philip Freidin FliptronicsArticle: 96270
Hi Marco I had the same problem. I bought one of these http://tinyurl.com/86sc5 Then had to set XIL_IMPACT_ENV_LPT_BASE_ADDRESS=xxx Typically, "xxx" is "378," Use the Windows Device Manager to confirm the base address assigned to LPT1. Impact & chipscope both worked ok after that. QuarkArticle: 96271
fpga_toys@yahoo.com wrote: > Symon wrote: > > See how crazy this gets without enough data to work on? > > Cheers, Syms. > > No, only the heat spreader is at 0K, the die is at max temp, and the > FR-4 to my pcb would have to assume chip temp less free air heat > losses. > > Shall we review your calcs assuming the die was at commerical temp > limits See how crazy this gets without enough data to work on? You do not have a clue what the voltage drop between the host pcb and the die is at any current, much less your 870A example. Show me in the data sheet please :)Article: 96272
"quark01" <quark01@gmail.com> schrieb im Newsbeitrag news:1138814640.304450.181220@z14g2000cwz.googlegroups.com... > Hi Marco > I had the same problem. I bought one of these http://tinyurl.com/86sc5 > Then had to > > set XIL_IMPACT_ENV_LPT_BASE_ADDRESS=xxx > > Typically, "xxx" is "378," Use the Windows Device Manager to confirm > the base address assigned to LPT1. > > Impact & chipscope both worked ok after that. > > Quark > weird I am using PCI LPT ports with base addess typically set to 0xD800 and both impact and chipscope recognize it properly as LPT1 without any need to specify it manually AnttiArticle: 96273
<fpga_toys@yahoo.com> wrote in message news:1138813669.939309.62810@g47g2000cwa.googlegroups.com... > > > No, only the heat spreader is at 0K, the die is at max temp, and the > FR-4 to my pcb would have to assume chip temp less free air heat > losses. > But the Helium is superfluid so we can make it flow past the balls between the package and the FR4 with no viscous drag. Tiny balls at near 0K. OK? :-) Syms. p.s. For commercial temperature rated parts the current rating goes up by a factor of (125 + 273.13) / (85 + 273.13) . I guess.Article: 96274
Wolf, are you sure is not the power supply? does the configuration process succeded? (done high?) Aurash Wolf wrote: > Hi, > > Background: Spartan 3 FPGA, Xilinx 6.3 tools > > I am currently having a problem with what I think is a power up reset. > I have a fairly complicated design consistings of several state > machines and a controller. I can get this to work easily by either > downloading to the eeprom without powering off as well as simply > downloading the bit file over jtag. However, when I power off and on > the firmware no longer works. I know this particular board works with a > much simpler version of this bit file, and has no problems with > powering up. > > Is the fact that my new design is more complicated allowing a power up > reset problem to come into focus because the older versions of this > were much simpler and not as prone to these types of problems? Is there > some way to put a counter on the spartan 3 and do a global reset with > it? > > Tomorrow I think I will try to wire a hard reset onto the board but it > is going to be a pain, I hope someone else might have encountered and > solved a similar problem. > > thanks, > wolf >
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