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
This is a multi-part message in MIME format. --------------961C48C6CEDFAD43BCAC025D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit One of my favorite reference books for synthesizable code, for both VHDL and Verilog is "VHDL and Verilog HDL Chip Design" by Douglas J. Smith, Doone Publications - also known unofficially as the 'big blue meatgrinder book'. It's particularly good if you want to compare synthesizable VHDL to synthesizable Verilog (if you already know one, and you're trying to learn the other, for example). Regardless, I consider it as one of the best beginner/intermediate level synthesis reference books out there. There might be something better for advanced VHDL techniques - I don't know, perhaps someone can comment... -Scott Schlachter V Ram wrote: > Hello! > > I have a few questions regarding synthesizing VHDL... > > Is there a website or document that describes what parts of VHDL > are/aren't synthesizable? I have the Designer's Guide to VHDL (Ashenden) > but I have no clue how synthesizable his code is... > > Typically the code I've written is simple enough that is has > synthesized(MaxPlus II & FPGA Express), but I might want to use variables > or do a few other things and I don't know what's suggested or not. > > My biggest complaint about Ashenden's book is that he doesn't really give > you clues as to what design method(s) you should take if you want your > designs to be synthesizable. > > Any hints, tips, website or recommended books would be nice to know about. > > Really any website that has code that *has* been synthesized would be > fantastic. I know about the Leon SPARC core and the Hamburgh VHDL archive > but lots of the models there aren't synthesizable. > > Thanks, > V Ram. --------------961C48C6CEDFAD43BCAC025D Content-Type: text/x-vcard; charset=us-ascii; name="scott.schlachter.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott Schlachter Content-Disposition: attachment; filename="scott.schlachter.vcf" begin:vcard n:Schlachter;Scott tel;work:408-879-6876 x-mozilla-html:TRUE url:www.xilinx.com org:Xilinx;General Products Division adr:;;2100 Logic Drive;San Jose;CA;95124-3400;USA version:2.1 email;internet:scott.schlachter@xilinx.com title:Systems Engineer fn:Scott Schlachter end:vcard --------------961C48C6CEDFAD43BCAC025D--Article: 27401
I posted the common telecom rules of thumb in another CRC thread. These things can be calculated, but it is rather tedious. I have read some good articles in IEEE comms years ago (which is where these rules of thumb come from), so you can search their online library for references to CRCs. Cheers, Herman http://www.AerospaceSoftware.com Joe Durusau wrote: > > Well, in the olden days of mainframe computers, the larger IBM > systems came with a memory that read something like 32 bits of data and > 8 bits of crc with each memory reference. There was a special trick > that > the service people did to find out if the memory controller was seeing > (and correcting) errors. Never did a day go by that there was not an > error. > Simple parity checks helped, but did not allow correction of the data. > If the bit in question did something serious, like say "dump the air > from > the space station" or "reset and reboot all the flight contorl logic in > the aircraft" the problems could be quite spectacular. There are > hardware > implementations for crc in existance, for those who need speed. > > I guess it just depends on how important the accuracy offthe data is. > After > all, in the telephone networkm if Aunt Minnie sounds a little off, > nobody > will likely care. OTOH, if a missile gets launched at the wrong country > because a bye gets exchanged with another, I suspect a lot of folks > would > care, at least for a short time. > > Speaking only for myself, > > Joe Durusua > > Niall Murphy wrote: > > > > Dan Kotlow <dank@micrologic.com> wrote in message > > news:3a138b05.91598579@news.ma.ultranet.com... > > > > > > I'm sure you get much better performance with the methods you suggest, > > > provided that you don't count undetected errors as reducing > > > performance. However, if undetected errors are important in your > > > application, then those arithmetic checks suck badly compared to real > > > CRC. > > > > > > I, in particular, have the misfortune to be working with a satellite > > > communications provider that uses the Fletcher checksum for error > > > control. We get corrupted data constantly. It only takes two > > > "well-placed" bit errors to fool the Fletcher checksum. > > > > > I agree with you completely, that the previous poster was misleading > > everyone by implying that the IP checksum is as good as a CRC (and Michael's > > articles referenced in the original post explain all that in detail). My > > question is that I am curious if a CRC would solve your specific problem. > > When you say that you get corrupted dataconstantly, do you mean that you get > > data with a valid checksum, even though it has been corrupted? > > > > Mathematically CRC is definitly better than a checksum, I have just not come > > across a real practical case where the difference could be identified. I > > suspect that it is a function of how large the packets are - 16 bits as a > > check on 100 bytes seems reasonable, but as a check on 10000 bytes seems > > riskier to me (but I do not know if there is a simple mathematical > > justification of that) - what is the ratio on your appication. If anyone > > knows a recommended ratio where you should switch to CRC I would be curious. > > Niall Murphy (http://www.panelsoft.com)Article: 27402
This is a multi-part message in MIME format. --------------E45E885A1F5096C5F94BDCAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I was wondering the same - if the ADC has a 5V CMOS level input threshhold, the switching level should be about 2.5V. Why use a pull-up/open drain configuration at all? Niel, you mentioned that it took 40ns to transition from 1V to 4V; is the ADC switching from L->H at 4V??? Sounds a bit high... which ADC is this? -Scott Schlachter Ray Andraka wrote: > I think he is using only one driver. His issue, if I'm reading this right is > that the ADC needs to see a level higher than the 3.3v output (I don't know what > ADC he's using), so he's using the FPGA output as an open drain to get the low > level and a pull-up for the high. > > My first thought is to pick a different ADC. There are several out there that > provide an option for 3.3v interface and 5v Analog. If for some reason you are > stuck with that ADC, you might use a quickswitch as a level translator. Those > things get you a nearly transparent translation...propagation delay is well > under a nanosecond. I'm not sure Peter's suggestion of delaying the tristate > will help or not, as I am not sure what will happen if the active output is > externally pulled up to 5v. I suspect it will continue on up close to 5v > without incident as long as the protection diodes are enabled. > > Andy Peters wrote: > > > > Nial Stewart wrote: > > > > > > The guy who did the board I'm currently working on had a > > > 3.3V IO spartan 2 driving (or not) the 5V CMOS inputs > > > on an ADC. > > > > > > I implemented the 'tri-state when driving high ie > > > > > > signal_out <= 'Z' when (signal_internal = '1') else signal_i; > > > > > > with an external pull up' which allows the driven signals > > > to reach 5V, but a couple of the lines are clocks and > > > were taking 40nS to get from 1V -> 4V. I think this was > > > causing problems with the DAC. > > > > What value of pullup resistor are you using? Smaller = faster! > > > > One thing I don't understand: why are you using open-drain outputs to > > drive a clock input? Seems to me that you'd want to arrange your logic > > such that one (and only one) driver clocks the ADC. > > > > -- a > > ---------------------------- > > Andy Peters > > Sr. Electrical Engineer > > National Optical Astronomy Observatory > > 950 N Cherry Ave > > Tucson, AZ 85719 > > apeters (at) n o a o [dot] e d u > > > > "It is better to be silent and thought a fool, > > than to send an e-mail to the entire company > > and remove all doubt." > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com or http://www.fpga-guru.com --------------E45E885A1F5096C5F94BDCAC Content-Type: text/x-vcard; charset=us-ascii; name="scott.schlachter.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Scott Schlachter Content-Disposition: attachment; filename="scott.schlachter.vcf" begin:vcard n:Schlachter;Scott tel;work:408-879-6876 x-mozilla-html:TRUE url:www.xilinx.com org:Xilinx;General Products Division adr:;;2100 Logic Drive;San Jose;CA;95124-3400;USA version:2.1 email;internet:scott.schlachter@xilinx.com title:Systems Engineer fn:Scott Schlachter end:vcard --------------E45E885A1F5096C5F94BDCAC--Article: 27403
Express mode is supported by Spartan family and it is 8 bit parallel mode. -- Yury Wolf In article <8vcf6r$1e3$1@wedge.sfu.ca>, "S.Ivanov" <stefan1@canada.com> wrote: > Hello all, > > We have a board with 6 FPGAs. So far we have been using the XC4000 family > for all the 6. > The configuration is done from a 8-bit EEPROM via a daisy chain, where the > first device > is in Parallel Master Mode and the rest are in Serial Slave Mode. > Now we want to switch to Spartan devices. The Spartan devices, however, > don't have a > parallel configuration mode. Since it is an existing board and we can not > change anything, > I am considering the option of keeping the first device in the chain as an > XC4000 and > replacing the other 5 with Spartans. Is this going to work? Is the serial > data stream coming > out of the XC4000 devise compatible with the serial stream for Spartan > devices? > > Thanks, > Stefan Ivanov > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27404
I don't think you are serious Barry. -- Yury Wolf In article <wl%R5.280335$4d.36048590@news02.optonline.net>, "Barry Schneider" <barry61s@optonline.com> wrote: > I am presently working at a ASIC consulting company and we have a huge > backlog of work. We need help and will pay well. We have a great office > and have very flexible hours. We are looking for Verilog and/or VHDL > experience. > Synthesis and/or Mixed Signal a plus. If you are interested in a Good Job > e-mail me at barry61s@optonline.com > Hope to hear from you. > > Sincerely, > Barry > > PS: We have needs in: Commack, Long Island New York, > Hazlet, New Jersey > Bethlehem, Pennsylvania. > Cherry Hill, New Jersey > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27405
On Mon, 20 Nov 2000 16:27:01 -0800, "S.Ivanov" <stefan1@canada.com> wrote: >Hello all, > >We have a board with 6 FPGAs. So far we have been using the XC4000 family >for all the 6. >The configuration is done from a 8-bit EEPROM via a daisy chain, where the >first device >is in Parallel Master Mode and the rest are in Serial Slave Mode. >Now we want to switch to Spartan devices. The Spartan devices, however, >don't have a >parallel configuration mode. Since it is an existing board and we can not >change anything, >I am considering the option of keeping the first device in the chain as an >XC4000 and >replacing the other 5 with Spartans. Is this going to work? Is the serial >data stream coming >out of the XC4000 devise compatible with the serial stream for Spartan >devices? Yes, the bitstreams are compatible. But are you sure that you can drop Spartans into the footprint of your existing XC4000 parts (the 5 you intend to change). I ask, because the pinout of Spartan packages are not identical to the XC4000E parts from which they are derived. For instance, look at the mode pins. You say that "Since it is an existing board and we can not change anything". I think you will have to make at least some very minor board layout changes. Or much more ugly: rework. >Thanks, >Stefan Ivanov Philip Freidin Philip Freidin FliptronicsArticle: 27406
I've been trying to access Lucent's website, in order to get datasheets
for their ORCA FPGAs. Unfortunately for the past few weeks they've been
down (at least I can't access them)! What I need to know specifically
is whether or not the LUTs in their logic clusters can be used as
memories. If anyone can tell me this (or point me to a datasheet not on
Lucent's site) I'd be most appreciative.
Thanks in Advance
Steve
Steve Oldridge
M.A.Sc. Student (FPGA Architecture Research)
University of British Columbia
steveo@ece.ubc.ca.removethis
Article: 27407Ben Franchuk <bfranchuk@jetnet.ab.ca> writes: >glen herrmannsfeldt wrote: >> >> If you don't need so many bits for mantissa or exponent, it might not >> be too bad. Multiply is big in an FPGA, either fixed or floating. >> Divide is even worse, fixed or floating. >> >> If you did it base 16 (like IBM S/360 and S/370), it would take less >> barrel shift logic. >But the round off errors kill you. Why not just go back to DECIMAL >Floating point. Hmm. I don't think the round-off is necessarily worse, but it is harder to analyze. IBM used 24 bits for a base 16 mantissa and 7 for the characteristic. Because the three high bits could be 0, it really is only 21 bits. If you only expect 21 bits, but sometimes you get 24, is that bad? If you use only 21 bits, you get three more bits for the characteristic, but you need more bits to get the same exponent range. Numerical analysis people want to get every last bit they can, and this is more difficult. The IBM double still uses a 7 bit characteristic (about 1e-78 to 7e75), and 7 hex digits, or 53 to 56 bits. IEEE double, is, if I remember, 53 bits, though with a larger exponent range. I do believe that there would be some use for BCD floating point in general purpose processors. You need more bits to get the same precision, though, and this probably makes it too expensive in FPGA's. Maybe base 8 wouldn't be too far off? I think an even power of two might be better for most FPGA's, though. -- glenArticle: 27408
In article <3A195D6F.79D731CD@Connriver.net>,
Hawker <Hawker@Connriver.net> wrote:
> (this may be a double post - sorry my browser is doing strange things)
>
> Hello all.
>
> I need to cost down some products that have a pile of 74LS244 and
> 74HC374s on them. Ideally I would love to be able to use an XC9500 part
> for this. The problem seems to be that I can't program a tri-state I/O
> in the 9500 if I understand correctly. Seems the next step would be a
> regular Spartan, but that does not seem to have tri state outputs/inputs
> either. This does not make sense as I thought I have seen folks use
> them for '8031 to i/o interfaces. What am I missing. What Xilinx Part
> (as that is the only toolset I have) would be good to use here. There
> won't be much other logic going on - decode to 64 outputs, encode 16
> inputs and a few timers/dividers going on. Cost is a big factor.
>
> I need a 5V part with 5V outputs not 3.3 than can dive 5v ins. The end
> product needs to fire a pile (256) LEDs (2ma each) so I need to be able
> to sink some current as well. I assume I need to split this up into
> several small Xilinxs for current draw issues. Hopefully each xilinx
> can fire 64 points (~150ma).
>
> Thanx.
>
You can also use the cheaper 3.3V parts to drive the LEDs from 5V.
Setting the output to high impedance switches the LED off.
The output of the CPLD will then be pulled up to 5V, but there is
not problem since they are 5 V tolerant.
Be avare that both the 5V versions and the 3V versions have TTL
levels on the inputs/outputs. The can be driven and drive exactly
the same devices.
Check the data sheet about the maximum current for the SUPPLY pins
to see how much LEDs you can drive. The currents in the single outputs
are summed up on the supply pins!
Hope this helps
Klaus
--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen
Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 27409On Thu, 16 Nov 2000 06:53:04 -0800, Joe Durusau <joseph.a.durusau@lmco.com> wrote: > Well, in the olden days of mainframe computers, the larger IBM >systems came with a memory that read something like 32 bits of data and >8 bits of crc with each memory reference. There was a special trick >that the service people did to find out if the memory controller was seeing >(and correcting) errors. Are you sure that they used CRC (Cyclic Redundancy Check), since I have never heard of anybody using CRC for error _correction_. The PDP-11s I used, had a 32 bit memory word and 6 ECC (Error Correction Code) bits capable on correcting a single bit error and detecting and odd number of bit errors in the memory word. This was some kind of Hamming ECC, definitely not CRC. PaulArticle: 27410
Andy Peters wrote: > > I guess Rambus is gonna come after my ass because I put an SDRAM > controller into my last FPGA? > With memory makers, they attacked the weakest first before stepping up. FPGA having the unique characteristic that the "infringing" circuit can be built by much smaller entities, even individual designers unlike all other kind of chips that are more or less "bigger guys" businesses. I really see a risk here that they could try to "go after your ass", and others to make them sign licences and NDA, thinking it will be a piece of cakeand pave the way for more substantial lawsuits. It's not only SDRAM related, they also patented an awful lot of commonly used high speed design techniques such as clock feedback, high speed bus or DLL. To see the (124 at this time) patents that have been issued (do not forget that a lot more that have been filed), go here : http://www.delphion.com/ and type "rambus" in the search field. here is a sample of what you'll find : US05614855, US06125157 : Delay-locked loop circuitry for clock delay adjustment http://www.delphion.com/details?pn=US06125157__ http://www.delphion.com/details?pn=US05614855__ http://www.delphion.com/details?pn=US06070222__ Synchronous memory device having identification register (AFAIK this one is used against SDRam makers) US06067592 : System having a synchronous memory device http://www.delphion.com/details?pn=US06067592__ (roughly patents the concept of pipelined memory) US05977798 : Low-latency small-swing clocked receiver (this seems to apply to "gigabit" transceivers) and more than 120 others of the same kind. At first, they asked for royalties for their Rambus memories (normal), then they asked for SDRAM, then DDR Sdram, now memory controllers and processors with integrated SDRAM interface. What's next ? [Every known digital design technique] applied to static RAM [Every known digital design technique] applied to Flash storage [Every known digital design technique] applied to Processors [Every known digital design technique] applied to network routers [Every known digital design technique] applied to [Every possible application] This business model, based on using a swarm of weak patents to collect a toll on a broad range of digital circuit designs should be a reason for concern. > > Here's a thought: BUY MICRON MEMORY. > They're very litigious too, but this time, they're on the right side of it. Buying from them is an indirect way to support this fight. My point is that, if Rambus is successful in enforcing their swarm of patents, others will soon follow the same litigious business model and designing a digital device might soon become a matter of avoiding patent related trouble & litigation or paying them skyrocketing tolls. Eric.Article: 27411
Dynamic run-time reconfiguration of the PCI target is not feasible. BIOS assigns PCI resources at startup. But you might use "semi-dynamic" reconfiguration: Use onboard EEPROM with enough space for two FPGA bitstreams. First bitstream will be a PCI interface with ability to reprogram EEPROM's upper part. Second bitstream will be a real PCI function you want to use. Bitstream selection could be done simply by jumper. Interesting approach for reconfiguration is used in HOT II board by VCC (http://www.vcc.com/Hotii.html). Another interesting site which can help is http://www.maxlock.com/products.htm There are full VHDL source files of PCI Interface for FPGAs JohnArticle: 27412
Andy Peters wrote: > > Xilinx = Rambus? > No, at least for one reason : Xilinx makes products that *actually work* and relies on that as a primary source of revenue. Rambus relies on their lawsuits to extract a toll, that's a very different business model. Eric.Article: 27413
Neil Franklin <neil@franklin.ch.remove> writes: > "Dines Justesen" <dcj_k@rescom.dk> writes: > > > > While I could make quite a few comments on this, > > > I think I will just give you the link: > > > > > > > > > http://www.xilinx.com/prs_rls/xilinxwin.htm > > > > Alteras response is here: > > > > http://www.altera.com/html/new/pressrel/pr_litigation1.html > > Thanks for the other sides link. > > Hmmm. Xilinx says Flex and all follow ups, Altera says only Flex8000 > is treatened. Anyone got any info on who is bending the truth by how > much? Both, a lot? Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 27414
"Hawker" <Hawker@Connriver.net> wrote in message news:3A195D6F.79D731CD@Connriver.net... > (this may be a double post - sorry my browser is doing strange things) > > Hello all. > > I need to cost down some products that have a pile of 74LS244 and > 74HC374s on them. Ideally I would love to be able to use an XC9500 part > for this. The problem seems to be that I can't program a tri-state I/O > in the 9500 if I understand correctly. Seems the next step would be a > regular Spartan, but that does not seem to have tri state outputs/inputs > either. This does not make sense as I thought I have seen folks use > them for '8031 to i/o interfaces. What am I missing. What Xilinx Part > (as that is the only toolset I have) would be good to use here. There > won't be much other logic going on - decode to 64 outputs, encode 16 > inputs and a few timers/dividers going on. Cost is a big factor. > > I need a 5V part with 5V outputs not 3.3 than can dive 5v ins. The end > product needs to fire a pile (256) LEDs (2ma each) so I need to be able > to sink some current as well. I assume I need to split this up into > several small Xilinxs for current draw issues. Hopefully each xilinx > can fire 64 points (~150ma). > Some comments: * XC95xx has tristate * The LED's could be lit by a pulldown to GND by the CPLD, thus real 5V output is not an issue. * Your LED's could most probably be operated on 3.3V, you'll just have to adjust the current limiting resistors. * If your 256 LEDs are intended for the human eye, you can most probably time multiplex them, e.g. as a 16x16 array. Then you'll only need 32 pins to drive them all and get into a cheaper (and only *one*) package. The only concern here is the total current.... I'll guess the cost saving of using one CPLD would more than pay for using some hefty 74xx244 buffers (24/48 mA types) externally. Alternatively you can substitute the '244s for the row or column drive with a '154 and get down to 20 CPLD pins. Some lab bench experiments on the visual impact of 1/16th multiplex vs. frequency is recommended though...... Regards, - OlafArticle: 27415
Hello,
I'm using Foundation Express 3.1i tools.
I want to implement a simple counter with a asynchronous Reset signal in
a Spartan FPGA.
This design is OK with a Virtex or Spartan II device but it's don't work
with Spartan (signal RST has no effect) ...
I would like to know if anybody had a similar problem and what can I
do...
Is there something wrong in my code ?
Thanks,
Xavier Regal.
Here is my VHDL program :
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.ALL;
entity TEST is
port (
RST : in std_logic ;
CK : in std_logic;
CPT_OUT : out std_logic_vector(1 downto 0)
);
end TEST;
architecture ARCHI of TEST is
signal CPT_CK : std_logic_vector(1 downto 0); -- compteur diviseur de CK
begin
process(CK, RST) begin -- division de la frequence d'horloge par 4
if RST = '1' then
CPT_CK <= "00";
elsif CK'event and CK = '1' then
CPT_CK <= CPT_CK+1;
end if;
end process;
CPT_OUT <= CPT_CK;
end ARCHI;
Article: 27416> Thanks Edwin but I meant a program that allows me to make > "black-boxes" out of my VHDL and then use standard primatives like NAND2, > OR2, etc and graphically hook it up. As the other posted said one could > make these components in Renoir and then hook it up, but that defeats the > purpose... I'm afraid you might have to go vendor-specific to do that. The newer tools from Xilinx (Foundation ISE and WebPACK ISE) let you do exactly this. When you draw a schematic in these tools, a VHDL file will be created for you which instantiates library primitives (if you have used them in your schematics). Regards, Rune BaeverrudArticle: 27417
Ray Andraka wrote: > > I think he is using only one driver. His issue, if I'm reading this right is > that the ADC needs to see a level higher than the 3.3v output (I don't know what > ADC he's using), so he's using the FPGA output as an open drain to get the low > level and a pull-up for the high. That's correct. > My first thought is to pick a different ADC. There are several out there that > provide an option for 3.3v interface and 5v Analog. If for some reason you are > stuck with that ADC, you might use a quickswitch as a level translator. Ray, I've had a look at the App note for these (AN-11A) and they only seem to operate when using 5V logic with TTL input levels. "The function of the 5v to 3V converter is to limit the voltage seen by the 3V TTL device to acceptable levels, typically no more than the 3.3V supply (minus) 0.5V." This doesn't get me any further as the SpartanII (that is being used) inputs are 5V tolerant anyway. Does anyone know of an active 3v TTL -> 5V CMOS driver in a small package (8 pin soic, two channel would be ideal)? Nial.Article: 27418
I am writing VHDL code for a Xilinx Virtex FPGA. I do not have access to an external reset signal. How do I make sure my flip-flops are reset after power-up? I realize that after configuration the internal GSR signal is high for a number of clock cycles to reset everything, but when I look at the map.mrp file it does not show that the Startup block was instantiated. Do I need to instantiate the Startup block in my VHDL code so that the GSR signal is used, or are the Startup block and the GSR signal related to different internal circuits? If I instantiate a Startup block in my VHDL code, do I need to specify an external reset input signal? Or do I need to use ROC? Is ROC strictly for simulation so that a valid reset is generated at the start of simulation, or does the ROC component get passed through synthesis? If ROC gets passed through synthesis does it become the Startup block or GSR signal? Best regards, Kevin BreedingArticle: 27419
Hello, I make a device with Xilinx XCS10 device for my diploma. I must controll the device by parallel port of PC and get the result by it. Do you know some cores of EPP interface (schematics not VHDL) which I could use or look at them because I have some trouble to implement it in the XCS10. When I test it by enabled buffers all the time it work but when I connect it to Data Strobe it stop to work. Thank you in advance! Latchezar Kostov Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27420
All, It may be that there are reflections which result in 'ringing' that is messing up the picture. Neil thinks it is a "5 V CMOS interface issue". It may be just bad signal integrity, and the signal easily passes through 2.5 Vdc. But it does so twice (or more) on each edge! With the tristate pull down, resistor pull up, the 40 ns edge is inviting disaster from a noise sensitivity point of view. Using the active pullup for part of the transistion to a '1' may cause so much ringing due to the mis-match, the signal is again useless. I would try a weaker IO strength output (LVTTL 6 mA is ~50 ohms), or a series resistor at the driver (series termination) and no external pullup. Austin Scott Schlachter wrote: > I was wondering the same - if the ADC has a 5V CMOS level input threshhold, the > switching level should be about 2.5V. Why use a pull-up/open drain configuration at > all? Niel, you mentioned that it took 40ns to transition from 1V to 4V; is the ADC > switching from L->H at 4V??? Sounds a bit high... which ADC is this? > -Scott Schlachter > > Ray Andraka wrote: > > > I think he is using only one driver. His issue, if I'm reading this right is > > that the ADC needs to see a level higher than the 3.3v output (I don't know what > > ADC he's using), so he's using the FPGA output as an open drain to get the low > > level and a pull-up for the high. > > > > My first thought is to pick a different ADC. There are several out there that > > provide an option for 3.3v interface and 5v Analog. If for some reason you are > > stuck with that ADC, you might use a quickswitch as a level translator. Those > > things get you a nearly transparent translation...propagation delay is well > > under a nanosecond. I'm not sure Peter's suggestion of delaying the tristate > > will help or not, as I am not sure what will happen if the active output is > > externally pulled up to 5v. I suspect it will continue on up close to 5v > > without incident as long as the protection diodes are enabled. > > > > Andy Peters wrote: > > > > > > Nial Stewart wrote: > > > > > > > > The guy who did the board I'm currently working on had a > > > > 3.3V IO spartan 2 driving (or not) the 5V CMOS inputs > > > > on an ADC. > > > > > > > > I implemented the 'tri-state when driving high ie > > > > > > > > signal_out <= 'Z' when (signal_internal = '1') else signal_i; > > > > > > > > with an external pull up' which allows the driven signals > > > > to reach 5V, but a couple of the lines are clocks and > > > > were taking 40nS to get from 1V -> 4V. I think this was > > > > causing problems with the DAC. > > > > > > What value of pullup resistor are you using? Smaller = faster! > > > > > > One thing I don't understand: why are you using open-drain outputs to > > > drive a clock input? Seems to me that you'd want to arrange your logic > > > such that one (and only one) driver clocks the ADC. > > > > > > -- a > > > ---------------------------- > > > Andy Peters > > > Sr. Electrical Engineer > > > National Optical Astronomy Observatory > > > 950 N Cherry Ave > > > Tucson, AZ 85719 > > > apeters (at) n o a o [dot] e d u > > > > > > "It is better to be silent and thought a fool, > > > than to send an e-mail to the entire company > > > and remove all doubt." > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com or http://www.fpga-guru.comArticle: 27421
I installed the Webpack 3.2 on Windows NT 4.0 If i run the Design Implementation it stops with exit code 0128 (EXEWRAP detected a return code of '128' from program 'ngdbuild.exe') I tried it with several Example Projects. How can i solve this problem?Article: 27422
I have a complex video processing application - wavelet or DCT compression in an FPGA for a 1Kx1K 30 frame per second video stream. I need very low power consumption. Ideally, I would like to leave the FPGA powered down until I need it, but it would have to be ready in under 100mSec. I've only worked with the Xilinx FPGAs and was wondering if someone out there with a more varied background could point me in the right direction. I need enough resources and speed to do the algorithm, but at minimum power. As an aside, anyone out there with compatible experience or can point me towards a web site for real-time, high resolution compression? Thanks, Steve NordhauserArticle: 27423
Steve Oldridge <steveo@ece.ubc.ca> wrote: > I've been trying to access Lucent's website, in order to get > datasheets for their ORCA FPGAs. Unfortunately for the past > few weeks they've been down (at least I can't access them)! In keeping with their minimalist marketing strategy, they sometimes move their website so that only their dedicated customers know where it is. Currently it's at: http://www.lucent.com/micro/netcom/orca/ > What I need to know specifically is whether or not the > LUTs in their logic clusters can be used as memories. > If anyone can tell me this (or point me to a datasheet > not on Lucent's site) I'd be most appreciative. Yes. Each logic block (PFU) has 8 LUTs and can be used as a 32x4 dual-port synchronous RAM. Note that Dual port ram uses all the RAM bits, unlike the Xilinx parts and Orca2, which use two 16x1 Luts to implement a single 16x1 dual-port RAM. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27424
Yuri, That's right, the Express Mode is 8-bit parallel, but it requires some logic to generate the addresses and the controlling signals for the EEPROM :-( (and it is supported only by the Spartan-XL family, which is not the problem in our case). And all the FPGAs have to be connected to the EEPROM. The convenience of the Parallel Mode supported by the XC4000 family is, that it is glueless and very easy to implement. Thanks, Stefan <yuryws@my-deja.com> wrote in message news:8vcrcv$kdr$1@nnrp1.deja.com... > Express mode is supported by Spartan family and it is 8 bit parallel > mode. > > -- Yury Wolf > In article <8vcf6r$1e3$1@wedge.sfu.ca>, > "S.Ivanov" <stefan1@canada.com> wrote: > > Hello all, > > > > We have a board with 6 FPGAs. So far we have been using the XC4000 > family > > for all the 6. > > The configuration is done from a 8-bit EEPROM via a daisy chain, where > the > > first device > > is in Parallel Master Mode and the rest are in Serial Slave Mode. > > Now we want to switch to Spartan devices. The Spartan devices, > however, > > don't have a > > parallel configuration mode. Since it is an existing board and we can > not > > change anything, > > I am considering the option of keeping the first device in the chain > as an > > XC4000 and > > replacing the other 5 with Spartans. Is this going to work? Is the > serial > > data stream coming > > out of the XC4000 devise compatible with the serial stream for Spartan > > devices? > > > > Thanks, > > Stefan Ivanov > > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.
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