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
Neato! Say, how's the voltage coefficient on that, with respect to Vcore I suppose? Would be good for calculating how much ripple it can tolerate. Tim -- Deep Friar: a very philosophical monk. Website: http://seventransistorlabs.com "John Larkin" <jlarkin@highlandtechnology.com> wrote in message news:s9fv199t3h9qtmbjrcmnkfe4dlqrv60tlm@4ax.com... > > > We're experimenting with heat sinking an Altera Cyclone 3 FPGA. To > measure actual die temperature, we built a 19-stage ring oscillator, > followed by a divide-by-16 ripple counter, and brought that out. > > The heat source is the FPGA itself: we just clocked every available > flop on the chip at 250 MHz. We stuck a thinfilm thermocouple on the > top of the BGA package, and here's what we got: > > https://dl.dropboxusercontent.com/u/53724080/Thermal/R2_Temp_Cal.jpg > > > We can now use that curve (line, actually!) to evaluate various heat > sinking options, for both this chip and the entire board. > > The equivalent prop delay per CLB seems to be about 350 ps. The prop > delay slope is about 0.1% per degree C. > > > -- > > John Larkin Highland Technology, Inc > > jlarkin at highlandtechnology dot com > http://www.highlandtechnology.com > > Precision electronic instrumentation > Picosecond-resolution Digital Delay and Pulse generators > Custom laser drivers and controllers > Photonics and fiberoptic TTL data links > VME thermocouple, LVDT, synchro acquisition and simulationArticle: 155776
On Thu, 29 Aug 2013 22:47:11 -0500, "Tim Williams" <tmoranwms@charter.net> wrote: >Neato! > >Say, how's the voltage coefficient on that, with respect to Vcore I >suppose? Would be good for calculating how much ripple it can tolerate. > >Tim Vcore comes from an LM1117 with the ADJ pin grounded, so it's not really easy to twiddle. I might if I'm ever feeling energetic. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generatorsArticle: 155777
On 8/29/2013 4:37 PM, jg wrote: >> >> I think you mean Lattice offers a part in the QFN32. I only found the >> XO2-256. A selection guide that isn't even a year old says they offer >> an iCE40 part in this package, but it doesn't show up in the data sheet >> from 2013. I guess the product line is still a little schizo. They >> haven't finished cleaning house and any part or package could be next. > > The part code for this is ICE40LP384-SG32 > Showing on price lists, but still 0 in the stock column. > Mouser says 100 due on 9/30/2013 Just goes to show, you have to keep up on the data sheets. They just released a new one last week, 8/22/2013. This one includes the 32 pin QFN. Still, it is the poor step child of the family with no memory at all other than the FFs. Actually, I looked back through my history of data sheets and I must have had a brain cramp, they all show the QFN32. I have been looking at these parts for some time and I never realized they don't include distributed RAM using the LUTs. This part was not designed by Lattice, so I guess this may still be covered by patent. Lattice has a license on many Xilinx owned patents because they bought the Orca line from Lucent who had gotten all sorts of licensing from Xilinx in a weak moment. Not that this has hurt Xilinx much, but it is so out of character for them. I'll never understand why they licensed their products to Lucent. Maybe some huge customer required a second source for the 3000 and 4000 series. Or maybe it was just a huge wad of cash Lucent waved under their noses. Likely we'll never know. The point is I'm not nearly as enamored with the iCE40 parts as I was a year ago. They dropped the 600 LUT member of their family and replaced it with this 384 LUT member. At the same time they raised the quiescent current spec for the 1k part from 40 uA to 100 uAs. The entire iCE65 product line was dropped (which was even lower static current). They just can't seem to pick a direction and stick with it. >> In fact, that is an option, to add an MCU for >> most of the I/O and processing, then use something like the XO2-256 in a >> QFN32 to do the high speed stuff. I'm just not sure I can fit the >> design in 256 LUTs. Maybe the QFN32 is small enough I can use two? 5x5mm! > > Try it and see. I found the XO2-256 seems to pack full quite well, and the tools are ok to use, so you can find out quite quickly. > I did a series of capture counters in XO2-256, and once it worked, I increased the the width to fill more of the part. > IIRC it got into the 90%+ with now surprises. > > I've been meaning to compare the ICE40LP384 with the XO2-256, as the iCE40 cell is more primitive, it may not fit more. "Try it" is not so simple. The existing design is all logic. To "try it" requires repeating the design with a dichotomy of slow functions in software, fast functions in hardware and interfaces which will allow it all to function as a whole. It's not a huge project, but some of the functions (like a buffer size controlled FLL) might be a bit tricky to get right in software and may need to remain in gateware. Without block RAM this is hard. The beauty of doing it all in the FPGA is that the entire design can be run in one VHDL simulation. If the processor were integrated into the FPGA, then we are back to a single simulation, schweet! I'll more than likely go with one of the BGA packages, possibly the BGA256 because of the large ball spacing. This gives fairly relaxed design rules to the PCB. That then opens up the possibilities to a wide range of very capable parts. We'll see... -- RickArticle: 155778
Hi Chris, On 29/08/2013 02:29, Chris wrote: > On Tuesday, August 27, 2013 5:34:46 AM UTC-7, alb wrote: >> Hi everyone, I have several ports of my design that are not driving >> anything and left 'open' on purpose, using the 'open' keyword in my >> component instantiation in vhdl. Now I receive loads of 'Warning: >> CMP201...' from Designer because of this. Is there a way not to be >> annoyed by these warnings with the possibility to miss an important >> one? [] > OK I just reread this and noticed you just want a way to silence > these warnings if I am reading correctly... yes, you are reading correctly. Unfortunately warnings are not born all equal and a design may have several of them, some can be ignored and some should not. I simply would like to get rid of the ones I do not care about. nope I do not know how to > silence specific warnings with the Microsemi Designer. You probably > have to pull the text into python and do it there if you really need > to. I quickly looked through the literature I have on Actel and the > only related thing I saw was to limit the total number of warnings > shown. The default is 10,000 but you can change it with the tcl > command "-pdc_eco_max_warnings value" where value is the max number > of warnings. This is not going to fix your issue though. IMO having a maximum number of warning is extremely risky. You may fall in the situation where you may miss important ones. On top of it I consider warnings an indication that something is not going ok and I can live with a warning if and only if I know exactly why is there. But I do not want to keep trace of zillions of warnings which are meaningless. Svenn suggested to use the 'unused' attribute in SmartGen, but SmartGen is a just a macro generator and you would have to instantiate the component in your vhdl anyhow and it is typically assigned to 'open' (vhdl keyword). But this will flag a stupid warning in Designer.Article: 155779
Another way to clear these warnings is to make a mux'ed set of signals goin= g to unused pins that you never select using an outside trigger. For examp= le for ten signals that are giving you unconnected warnings and assuming yo= u have some spare IO make a test mux that is high impedance in the default = setting and selects these unused signals in other settings that never actua= lly get selected. You just need to fool the synthesis tool by making the s= elector an outside signal. I have done this with a mux selector coming fro= m a mmi from a processor and it works. You can probably do a -no prune dir= ective to save the mux too. Kind of a pain but it would fix the problem if= you have the spare IO.Article: 155780
rickman wrote: > I have been looking at these parts for some time and I never > realized they don't include distributed RAM using the LUTs. Also of note, the ICE40 Block RAM's two ports consist of one read-only port, and one write-only port; vs. the two independent read+write ports of many other FPGA families. > Lattice has a license on many Xilinx owned patents because > they bought the Orca line from Lucent who had gotten all > sorts of licensing from Xilinx in a weak moment. <snip> > I'll never understand why they licensed their products to Lucent. I'd reckon AT&T/Lucent had a large semiconductor patent portfolio with which to apply strategic "leverage" for a favorable cross-licensing agreement. > If the processor were integrated into the FPGA, then we > are back to a single simulation, schweet! As a yardstick, a system build for my homebrew RISC, including 4 Kbyte BRAM, UART and I/O, fits snugly into one of the 1280 LUT4 XO2 devices: : Number of logic LUT4s: 890 : Number of distributed RAM: 66 (132 LUT4s) : Number of ripple logic: 110 (220 LUT4s) : Number of shift registers: 0 : Total number of LUT4s: 1242 : : Number of block RAMs: 4 out of 7 (57%) The core proper (32 bit datapath, 16 bit instructions) is currently ~800 LUT4 in its' default configuration. [ I miss TBUF's when working on processor datapaths.] I don't have the XO2 design checked in, but the similar XP2 version is in the following code repository, under trunk/hdl/systems/evb_lattice_xp2_brevia : http://code.google.com/p/yard-1/ The above is still very much a work-in-progress, but far enough along to use for small assembly projects ( note that interrupts are currently broken ). -BrianArticle: 155781
On 9/2/2013 9:56 PM, Brian Davis wrote: > rickman wrote: > >> I have been looking at these parts for some time and I never >> realized they don't include distributed RAM using the LUTs. > > Also of note, the ICE40 Block RAM's two ports consist of > one read-only port, and one write-only port; vs. the two > independent read+write ports of many other FPGA families. The iCE family of products have a number of shortcomings compared to the large parts sold elsewhere, but for a reason, the iCE lines are very, very low power. You can't do that if you have a lot of "fat" in the hardware. So they cut to the bone. This is not the only area where the parts are a little short. The question is how much does it matter? For a long time I've heard how brand X or A or whatever is better because of this feature or that feature. So the iCE line has few of these fancy features, how well do designs work in them? >> Lattice has a license on many Xilinx owned patents because >> they bought the Orca line from Lucent who had gotten all >> sorts of licensing from Xilinx in a weak moment. > <snip> >> I'll never understand why they licensed their products to Lucent. > > I'd reckon AT&T/Lucent had a large semiconductor patent > portfolio with which to apply strategic "leverage" for a > favorable cross-licensing agreement. Possible, but I don't think so. Any number of folks could have had semiconductor patents and no one else got anything like this. I would speculate that Xilinx needed a second source for some huge customer or maybe they were at a critical point in the company's growth and just needed a bunch of cash (as opposed to cache). Who knows? >> If the processor were integrated into the FPGA, then we >> are back to a single simulation, schweet! > > As a yardstick, a system build for my homebrew RISC, > including 4 Kbyte BRAM, UART and I/O, fits snugly into > one of the 1280 LUT4 XO2 devices: > > : Number of logic LUT4s: 890 > : Number of distributed RAM: 66 (132 LUT4s) > : Number of ripple logic: 110 (220 LUT4s) > : Number of shift registers: 0 > : Total number of LUT4s: 1242 > : > : Number of block RAMs: 4 out of 7 (57%) > > The core proper (32 bit datapath, 16 bit instructions) > is currently ~800 LUT4 in its' default configuration. > [ I miss TBUF's when working on processor datapaths.] > > I don't have the XO2 design checked in, but the similar > XP2 version is in the following code repository, under > trunk/hdl/systems/evb_lattice_xp2_brevia : > > http://code.google.com/p/yard-1/ > > The above is still very much a work-in-progress, but > far enough along to use for small assembly projects > ( note that interrupts are currently broken ). The trick to datapaths in CPU designs is to minimize the number of inputs onto a "bus" which is implemented as multiplexers. Minimizing inputs gains speed and minimizes logic. When possible put the muxes inside some RAM on the chip to good use. I got sidetracked on my last iteration of a CPU design which was going to use a block RAM as the "register file" and stack in one. Since then I've read about some other designs which use similar ideas although not identical. Why did you roll your own RISC design when each FPGA maker has their own? The Lattice version is even open source. -- RickArticle: 155782
rickman wrote: > >>> I'll never understand why they licensed their products to Lucent. >> >> I'd reckon AT&T/Lucent had a large semiconductor patent >> portfolio with which to apply strategic "leverage" for a >> favorable cross-licensing agreement. > > Possible, but I don't think so. Any number of folks could > have had semiconductor patents and no one else got anything > like this. I would speculate that Xilinx needed a second source > There was definitely a second source in the XC3000 days, first from MMI (bought by AMD), later AT&T; but I don't remember there being anyone second sourcing the XC4000 IIRC, as Xilinx introduced the XC4000, AT&T went their own way in the ORCA, with similar features (distributed RAM, carry chains), but using the Neocad software. My speculation is that at this juncture, AT&T leveraged rights to the Xilinx FPGA patents. Back in 1995, the AT&T press release responding to the Neocad acquisition was re-posted here: https://groups.google.com/forum/message/raw?msg=comp.arch.fpga/Oa92_X3iDao/w63G0Z4dlCcJ and stated: " " When AT&T Microelectronics decided not to second source " the Xilinx 4000 family of FPGAs, we accelerated the " introduction of the ORCA family. " ----------------- > The trick to datapaths in CPU designs is to minimize > the number of inputs onto a "bus" which is implemented > as multiplexers. Yes, that's why I miss the TBUF's :) In the XC4000/Virtex days, the same 32 bit core fit into 300-400 LUT4's, and a good number of TBUF's. The growth to ~800 LUT4 is split between the TBUF replacement muxes and new instruction set features. > Why did you roll your own RISC design when each FPGA > maker has their own? When the YARD core blinked it's first LED in 1999, there wasn't much in the way of free vendor RISC IP. Being a perpetually-unfinished spare-time project, I never got enough loose ends tidied up enough to make the sources available until recently. > > The Lattice version is even open source. > At the initial announcement, yes; but when I looked a couple years ago, the Lattice Mico source files had been lawyered up with a "Lattice Devices Only" clause, see the comments on this thread: http://latticeblogs.typepad.com/frontier/2006/08/open_source.html -BrianArticle: 155783
On 9/3/2013 6:27 PM, Brian Davis wrote: > rickman wrote: >> >>>> I'll never understand why they licensed their products to Lucent. >>> >>> I'd reckon AT&T/Lucent had a large semiconductor patent >>> portfolio with which to apply strategic "leverage" for a >>> favorable cross-licensing agreement. >> >> Possible, but I don't think so. Any number of folks could >> have had semiconductor patents and no one else got anything >> like this. I would speculate that Xilinx needed a second source >> > > There was definitely a second source in the XC3000 days, > first from MMI (bought by AMD), later AT&T; but I don't > remember there being anyone second sourcing the XC4000 > > IIRC, as Xilinx introduced the XC4000, AT&T went their > own way in the ORCA, with similar features (distributed RAM, > carry chains), but using the Neocad software. > > My speculation is that at this juncture, AT&T leveraged > rights to the Xilinx FPGA patents. > > Back in 1995, the AT&T press release responding to the > Neocad acquisition was re-posted here: > > https://groups.google.com/forum/message/raw?msg=comp.arch.fpga/Oa92_X3iDao/w63G0Z4dlCcJ > > and stated: > " > " When AT&T Microelectronics decided not to second source > " the Xilinx 4000 family of FPGAs, we accelerated the > " introduction of the ORCA family. > " Yes, that is what we are discussing. Why did *Xilinx* give out the family jewels to Lucent? We know it happened, the question is *why*? > ----------------- > >> The trick to datapaths in CPU designs is to minimize >> the number of inputs onto a "bus" which is implemented >> as multiplexers. > > Yes, that's why I miss the TBUF's :) > > In the XC4000/Virtex days, the same 32 bit core fit into > 300-400 LUT4's, and a good number of TBUF's. > > The growth to ~800 LUT4 is split between the TBUF > replacement muxes and new instruction set features. My understanding is that TBUFs may have been a good idea when LUT delays were 5 nS and routing was another 5 to 10 between LUTs, but as they made the devices more dense and faster they found the TBUFs just didn't scale in the same way, in fact the speed got worse! The capacitance being driven didn't go down much and the TBUFs needed to scale which means they had less drive. So they would have actually gotten slower. No, they are gone because TBUFs just aren't your friend when you want to make a dense, fast chip. >> Why did you roll your own RISC design when each FPGA >> maker has their own? > > When the YARD core blinked it's first LED in 1999, > there wasn't much in the way of free vendor RISC IP. > > Being a perpetually-unfinished spare-time project, > I never got enough loose ends tidied up enough to > make the sources available until recently. Ok, that makes sense. I rolled my first CPU around 2002 and, like you, it may have been used, but still is not finished. >> The Lattice version is even open source. >> > At the initial announcement, yes; but when I looked > a couple years ago, the Lattice Mico source files > had been lawyered up with a "Lattice Devices Only" > clause, see the comments on this thread: > > http://latticeblogs.typepad.com/frontier/2006/08/open_source.html Oh, that is a horse of a different color. So the Lattice CPU designs are out! No big loss. The 8 bitter doesn't have a C compiler (not that I care) and good CPU designs are a dime a dozen... I guess, depending on your definition of "good". -- RickArticle: 155784
HT-Lab <hans64@htminuslab.com> writes: > Quartus used to connect unused pins to ground, not sure if this is > still the case. It seems to be the input tri-stated with weak pull-up now, in Quartus 13.0. I think I've used a Quartus fairly recently though where it's still output driving ground...Article: 155785
rickman wrote: [snip] > My understanding is that TBUFs may have been a good idea when LUT delays > were 5 nS and routing was another 5 to 10 between LUTs, but as they made > the devices more dense and faster they found the TBUFs just didn't scale > in the same way, in fact the speed got worse! The capacitance being > driven didn't go down much and the TBUFs needed to scale which means > they had less drive. So they would have actually gotten slower. No, > they are gone because TBUFs just aren't your friend when you want to > make a dense, fast chip. > I think TBUFs went away along with "long lines" due to capacitive delay as you noted. Modern FPGA's use buffered routing, and tristates don't match up with that sort of routing network since the buffered routes become unidirectional. The silicon for line drivers is now much faster than routing prop delays, making the buffered network faster than a single point driving all that line capacitance. So the new parts have drivers in every switch box instead of just pass FETs. I think the original Virtex line was the first to use buffered routing, part of the Dyna-Chip aquisition by Xilinx. They still had long lines and TBUFs, but that went away on Virtex 2. -- GaborArticle: 155786
HT-Lab <han...@htminuslab.com> writes:=20 >> Quartus used to connect unused pins to ground, not sure if this is=20 >> still the case.=20 >It seems to be the input tri-stated with weak pull-up now, in Quartus=20 >13.0. I think I've used a Quartus fairly recently where it's=20 still output driving ground...=20 Not true...Quartus allows you to specify unused pins as:=20 As input tri-stated=97 The pins are reserved as tri-state input pins. As output driving ground=97 The pins are reserved as output pins and drive = the ground signal. As output driving an unspecified signal=97 The pins are reserved as output = pins and drive any signal. As input tri-stated with bus-hold circuitry=97 The pins are reserved as tri= -state input pins with bus-hold circuitry. As input tri-stated with weak pull-up=97 The pins are reserved as tri-state= input pins with weak pull-up resistors. http://quartushelp.altera.com/11.1/mergedProjects/comp/comp/comp_tab_dp_unu= sed_pins.htmArticle: 155787
Chris <catalsma@gmail.com> writes: > HT-Lab <han...@htminuslab.com> writes: > >>> Quartus used to connect unused pins to ground, not sure if this is >>> still the case. > >>It seems to be the input tri-stated with weak pull-up now, in Quartus >>13.0. I think I've used a Quartus fairly recently where it's still >>output driving ground... > > Not true...Quartus allows you to specify unused pins as: I don't understand. What part did you feel was not true? I merely pointed out the default has been changed fairly recently. Oh, I guess the default being implicit rather than explicit confused you?Article: 155788
rickman <gnuarm@gmail.com> wrote: >> " > > Yes, that is what we are discussing. Why did *Xilinx* give out the > family jewels to Lucent? We know it happened, the question is *why*? (snip) >> Yes, that's why I miss the TBUF's :) >> In the XC4000/Virtex days, the same 32 bit core fit into >> 300-400 LUT4's, and a good number of TBUF's. >> The growth to ~800 LUT4 is split between the TBUF >> replacement muxes and new instruction set features. > My understanding is that TBUFs may have been a good idea when LUT delays > were 5 nS and routing was another 5 to 10 between LUTs, but as they made > the devices more dense and faster they found the TBUFs just didn't scale > in the same way, in fact the speed got worse! The capacitance being > driven didn't go down much and the TBUFs needed to scale which means > they had less drive. So they would have actually gotten slower. No, > they are gone because TBUFs just aren't your friend when you want to > make a dense, fast chip. That is probably enough, but it is actually worse than that. At about 0.8 micron, the wiring has to use a distributed RC model. Above, you can treat it as driving a capacitor with a current source. All points are, close enough, the same voltage, and the only thing that matters is what that voltage is. (LC delay is pretty low.) Below 0.8 micron, and besides the fact that the lines are getting longer, the resistance is also significant. It is then modeled as series resistors and capacitors to ground, all the way down the line. (As well as I remember, the inductance is less singificant that resistance, but I haven't thought about it that closely for a while now.) -- glenArticle: 155789
On Wednesday, September 4, 2013 7:50:15 AM UTC-7, Anssi Saari wrote: > Chris writes: > HT-Lab <han...@htminuslab.com> writes: > >>> Quartus used= to connect unused pins to ground, not sure if this is >>> still the case. = > >>It seems to be the input tri-stated with weak pull-up now, in Quartus >= >13.0. I think I've used a Quartus fairly recently where it's still >>outpu= t driving ground... > > Not true...Quartus allows you to specify unused pin= s as: I don't understand. What part did you feel was not true? I merely poi= nted out the default has been changed fairly recently. Oh, I guess the defa= ult being implicit rather than explicit confused you? Sorry if my comment offended you, that was not my intention. The post you = wrote left me with the impression that the Quartus tools would only either = connect unused pins to ground or tri-state them. That is not true which is= why I flagged it. I went back and looked at HT-Lab's original post you cu= t/pasted and saw that he mentions that he starts out his Quartus runs defin= ing what the unused pins do- you lost that context by not copying it. Afte= r going back and reading that post your comment makes more sense now. Agai= n, it wasn't meant to offend you. By the way, I do remember a version of Quartus, 5.X IIRC, that had a defaul= t setting of tieing unused pins to ground. It caused some spectacular resu= lts on a board I was working on a decade or so ago. Like HT-Lab I learned = my lesson on that one.Article: 155790
Gabor wrote: > I think TBUFs went away along with "long lines" due to capacitive delay I appreciate the rationale. Yet still I miss their functionality for processor designs. [ "Lament of the TBUF" would make an excellent dirge title ] > Modern FPGA's use buffered routing, and tristates don't match up with that I think I once read that the last generation or few of TBUF's were actually implemented with dedicated muxes/wired OR's, or something similar. I wish that had been continued on a reduced scale, TBUF's every 4 or 8 columns, matching the carry chain pitch, spanning some horizontal fraction of a clock region. -BrianArticle: 155791
Brian Davis <brimdavis@aol.com> wrote: > Gabor wrote: (snip) >> Modern FPGA's use buffered routing, and tristates don't >> match up with that > I think I once read that the last generation or few of > TBUF's were actually implemented with dedicated muxes/wired > OR's, or something similar. As far as I know, they are still implemented by the synthesis tools as either OR or AND logic. I don't know any reason to remove that ability, as it doesn't depend on the hardware. Then again, it isn't hard to write the logic directly. -- glenArticle: 155792
Hi, Does anyone know where I can buy EP3CLS70U484C8N from the shelf ? I'm lookin for only 1 pcs. Best regards AdamArticle: 155793
On 05/09/13 13:23, Adam Górski wrote: > Does anyone know where I can buy EP3CLS70U484C8N from the shelf ? > I'm lookin for only 1 pcs. http://octopart.com/partsearch#search/requestData&q=EP3CLS70U484C8NArticle: 155794
In article <l08jta$9m8$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Brian Davis <brimdavis@aol.com> wrote: >> Gabor wrote: >(snip) >>> Modern FPGA's use buffered routing, and tristates don't >>> match up with that > >> I think I once read that the last generation or few of >> TBUF's were actually implemented with dedicated muxes/wired >> OR's, or something similar. > >As far as I know, they are still implemented by the synthesis >tools as either OR or AND logic. I don't know any reason to remove >that ability, as it doesn't depend on the hardware. Then again, it >isn't hard to write the logic directly. We do this now in verilog - declare our read data bus (and similar signals) as "wor" nets. Then you can tie them all together as needed. Saves you the hassle of actually creating/managing individual return data, and muxxing it all. The individual modules must take care to drive 0's on the read_data when not in use. Then you're really creating multi-source signals (like past bus structures), but relying on the "wor" to resolve the net. Works in Xilinx XST and Synplicity. Don't know about others. Don't know if this trick would work in VHDL. --MarkArticle: 155795
Mark Curry <gtwrek@sonic.net> wrote: (snip, I wrote) >>As far as I know, they are still implemented by the synthesis >>tools as either OR or AND logic. I don't know any reason to remove >>that ability, as it doesn't depend on the hardware. Then again, it >>isn't hard to write the logic directly. > We do this now in verilog - declare our read data bus > (and similar signals) as "wor" nets. Then you can tie them > all together as needed. Saves you the hassle of actually > creating/managing individual return data, and muxxing it all. > The individual modules must take care to drive 0's on the > read_data when not in use. Then you're really creating > multi-source signals (like past bus structures), but > relying on the "wor" to resolve the net. I think you can also do it with traditional tri-state gates, but pretty much the same as AND with the enable, and then onto the WOR line. > Works in Xilinx XST and Synplicity. Don't know about others. > Don't know if this trick would work in VHDL. I can usually read VHDL but don't claim to write it. -- glenArticle: 155796
The standard data type (std_logic) is tri-statable in VHDL, so that would b= e the preferred choice, rather than WAND or WOR. It does come in handy in t= hat a single bidirectional port in RTL can represent both input and output = wires, and part of the mux, at the gate level. Tri-state bidirectional ports allow distributed address decoding in the RTL= (give a module the address and a generic to tell it what addresses to resp= ond to), even though at the gate level it will all get optimized together a= t the muxes. Some synthesis tools can even "register" tri-state values to allow you to s= implify pipelining in the RTL. Synthesis takes care of the details of separ= ating out the tri-state enable from the data, and registering both appropri= ately. AndyArticle: 155797
El mi=E9rcoles, 17 de mayo de 2006 05:06:47 UTC-3, Uwe Bonnes escribi=F3: > Laurent Pinchart <laurent.pinchart@skynet.be> wrote: > ... > > As I can't modify iMPACT to get rid of the Jungo dependency, I went the > > other way and tried to write a simple command line software to drive th= e > > cable. Unfortunately, the USB protocol seems to be classified top secre= t, > > and reverse engineering the EZUSB firmware didn't give me enough > > information. That's why I asked for more information on here. >=20 > I have adapted so xc3stools can talk to XC3S via the FT2232 on USB. If yo= u > are interested, talk to me.=20 Hi Uwe Bonnes, I am working with a JTAG-USB programmer based in FT2232D. The interface is = the OOCDLink-s[0] board. Can you give me any information about how you adapted a FPGA(Spartan 3) wit= h FT2232 on USB? Thanks very much in advance. Regards, Luis [0] http://www.xo2link.de/wp/?page_id=3D15 >=20 > Otherwise, I understand your concerns about WinDriver. It's the first thi= ng > that gives you trouble when you come back to ISE after some time. As one > probaly upgraded the kernel in the meantime, you first have to hunt for a > fitting Windriver. And that for a task that could be done with on board > means (parallel port access with /dev/parport and usb access vin > /proc/bus/usb). As a hint for the Xilinx developpers: Libusb exists for > Win32 too. >=20 > --=20 > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de >=20 > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 155798
Luis Alberto Guanuco <guanucoluis@gmail.com> wrote: > El miércoles, 17 de mayo de 2006 05:06:47 UTC-3, Uwe Bonnes escribió: > > Laurent Pinchart <laurent.pinchart@skynet.be> wrote: > > ... > > > As I can't modify iMPACT to get rid of the Jungo dependency, I went the > > > other way and tried to write a simple command line software to drive the > > > cable. Unfortunately, the USB protocol seems to be classified top > > > secret, and reverse engineering the EZUSB firmware didn't give me enough > > > information. That's why I asked for more information on here. > > > > I have adapted so xc3stools can talk to XC3S via the FT2232 on USB. If you > > are interested, talk to me. > Hi Uwe Bonnes, > I am working with a JTAG-USB programmer based in FT2232D. The interface > is the OOCDLink-s[0] board. Can you give me any information about how > you adapted a FPGA(Spartan 3) with FT2232 on USB? Thanks very much i > advance. Look at the code for xc3sprog on the sourceforge SVN repository. Discuss specific problems on the xc3sprog mailing list. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 155799
Followups set to s.e.d. In sci.electronics.design John Larkin <jlarkin@highlandtechnology.com> wrote: > We're experimenting with heat sinking an Altera Cyclone 3 FPGA. Did you try different kinds of heat sink grease? Apparently toothpaste and Vegemite work pretty well: http://www.dansdata.com/goop.htm Matt Roberds
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