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
Definitely a Doh! moment :-( Cheers, Simon.Article: 80826
xing1234@yahoo.com wrote:
>I already have the RTL code available which is designed for ASIC and
>targeted to work at 200Mhz. Now if I want to implement the logic into
>FPGA, how can get the idea in advance that how fast my logic can work
>on the FPGA? What the best way to calculate this number? Is this
>something you have to think about first before you do FPGA design?
>BTW, I am going to use the Xilinx VirtexII 6000.
>
>Thanks!
>
>
>
It really depends on how the design is done. If it is implemented to
minimize the logic between flip-flops to four input functions and
arithmetic, you can reach the 200 Mhz target. If on the other hand it
has layers and layers of logic between flip-flops you may only get a few
tens of MHz. As a first cut, try synthesizing the design with the
Xilinx as a target using synplify or XST and look at the post synthesis
speed estimates.
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 80827lecroy7200@chek.com wrote: >I am looking at a design that was done several years back which uses >several XC3000 devices. All devices are programmed with the same core >from a computer on power up. What I am seeing is that once or twice a >year, one of the devices will enter a non-recoverable mode. In this >mode, the device appears to be in power down or reset. Once in this >mode I am no longer able to program the device. Pulling the XC3000's >reset low for 10us has no effect. The problem appears random. The >only way to reprogram the part is to power down the IC. I have tried >running tests where I just reprogram the device, over heat the device, >change the supply voltages, etc. and can't reproduce the problem. When >the Xilinx device is in this mode, it draws little power. It can be >held in this mode for what appears an infinite amount of time and >causes no damage to the device. > >Was there some kind of an undocumented test mode built into the XC3000 >that I may be seeing? Does anyone else ever remember seeing a problem >like this? > > > I haven't used the XC3000, only 95xx and Spartan. But, I'm assuming it has jtag or something to download the config. Is the download controlled by an onboard CPU, or is it a pin header that you plug a programming cable into? If it is a header, do you jumper the pins to prevent stray fields from producing clocks on the download pins? Well, presumably, it isn't a classic CMOS latchup event, or it would either fry the device or overload the power supply on the whole board. JonArticle: 80828
Ray Andraka <ray@andraka.com> writes: > FWIW, I don't even load a mjor release anymore until service pack 1 is > out. Better to let someone else find the easy bugs! I just load it in a different directory. If I have trouble with it, I can easily switch back to the previous release.Article: 80829
Or, you may be able to use both edges of the clock to produce a de-facto 180 MHz. Use with care. Jason "Peter Hermansson" <peter.hermansson@sts.saab.se> wrote in message news:4fc631bb.0503110703.43ef50ad@posting.google.com... > ALuPin@web.de (ALuPin) wrote in message > news:<b8a9a7b0.0503110036.1b73c25c@posting.google.com>... >> Hello @ VHDL people out there, >> >> I have the following problem. Maybe someone of you has experienced the >> same: >> >> The signal "input_data" comes from a 12MHz clock domain. >> Now I want to sample that signal that way that I generate one >> sample-enable >> which is close to the center position of the bits. >> One possibility to do so is to use a over-sampling clock, let us assume >> 48MHz. >> >> >> The problem: 90 is not a multiple of 12. >> Is there a possibility to sample the 12MHz signal right in the center ? >> > > Hi, > > 90/12 = 7.5 and fractional division may be performed by dividing by 7 > one cycle and 8 the next. If the jitter is acceptable, the resulting > divisor is 7.5. > > /PeterArticle: 80830
MM wrote: > "Marc Randolph" <mrand@my-deja.com> wrote in message > news:1110509935.634028.77710@g14g2000cwa.googlegroups.com... > > > > xGMII (RGMII is what we > > use) is another, possibly easier way (or at least, slower speed that > > doesn't require MGT's). Physical layer chips for 1000Base-T cost > > something over ~$10/port. 1000Base-T SFP's cost something approaching > > 10x that (depending on volume). > > If you don't mind telling, which PHY chip are you using? Howdy Mikhail, I'm not sure if you are asking because I put a ballpark price in my response, or if you're just wondering my experience with the parts. I happen to be using a quad-port Broadcom part, although not in 1000Base-T mode (I use 1000Base-X mode). Support isn't the fastest, and you have to put up with their never-ending paranoia, but the parts work well. As for pricing, I don't remember the details. Seems like it was mid or high-teen's until you get to real high volume, which is when it falls closer to $10/port. I would expect parts from Vitesse or Marvell to be in the same price range, and with the same features. Agere has some parts as well, as might Intel, NEC, and others. For fiber only, there are even more choices. Have fun, MarcArticle: 80831
morpheus wrote:
> To extend your suggestion, suppose i have 5 levels of hierarchy.
I'd rather suppose one or two.
I don't use hierarchy for it's own sake.
However, when reusing a substantial module
already having a testbench, it is probably
smarter to instance it than risk combining
designs directly.
> My question is if I use your advice, I would be registering 'OUT' at
> each level, is that what I should do?
I don't really know what your are doing other
than drawing boxes inside boxes. The fact that
you are counting up output registers leads me to
think that you might need fewer boxes with
more logic in them.
-- Mike Treseler
Article: 80832
Johnson Lee wrote:
> My simulation is ok!
> But the result is not as what I planned to have.
Consider a synchronous design.
-- Mike Treseler
Article: 80833In article <1110556640.014510.68500@g14g2000cwa.googlegroups.com>, lecroy7200@chek.com writes: >I am looking at a design that was done several years back which uses >several XC3000 devices. All devices are programmed with the same core >from a computer on power up. What I am seeing is that once or twice a >year, one of the devices will enter a non-recoverable mode. In this >mode, the device appears to be in power down or reset. Once in this >mode I am no longer able to program the device. Pulling the XC3000's >reset low for 10us has no effect. The problem appears random. The >only way to reprogram the part is to power down the IC. I have tried >running tests where I just reprogram the device, over heat the device, >change the supply voltages, etc. and can't reproduce the problem. When >the Xilinx device is in this mode, it draws little power. It can be >held in this mode for what appears an infinite amount of time and >causes no damage to the device. It's been a long long time... I can't find the data sheet on their web page and my memory is (more than) a bit rusty... I forget the details of how configuration works. I think reset is just a global reset of the FFs. It doesn't have anything (much?) to do with configuration. I think there is a combined ~prog and done pin. It's pulled low (open drain) by the 3000 until it gets configured. Power up starts needing configutation. A high-to-low transition on ~prog asks for another configuration cycle. If your attempted configuration gets confused, there is no way to start over until you finish configuration since ~done is held low so you can't make it go high-to-low. Configuration starts with a 24 bit bit-count value. After that many configuration clocks, all the devices in the the chain release their done pulldown. If one of the devices in the chain gets (somehow) a low value in that counter you have to cycle through 2**24 cycles to wrap around and finish the current cycle. How clean is your configuration clock? Try cold rather than hot on your lab setup. The description of configuration in the data book is pretty good, but maybe only after you know the answer because you have read it many times. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 80834
Hello, I am wondering if someone could clear this doubt for me, in case of UART, the clock speed is 1.8432 MHZ, however it is able to transmit maximum of 115,200 bps, however even if we are able to transmit at 1 bit per cycle we should be able to transmit at 1,843,200 bps. What is the rationale for making something go slowly, when it can go much faster. PS, I really could not find any suitable group for this question, follow-ups to a more suitable group are welcome. TIA -- Imanpreet Singh AroraArticle: 80835
On Fri, 11 Mar 2005 09:15:30 -0800, "Ulf Ochsenfahrt" <ulfjack@gmx.de> wrote: >Just for the fun of it. Here's my solution: > > <http://server1.conquer-space.net/~ulf/fan-shot.jpg> > >The picture won't be there forever, if you'd like to keep it, you may want to mirror it. > >Cheers, > >-- Ulf Do you run the fan in oscillating mode, or stationary? Here are some things to think about: The regulators on the board may be current limiting at 1000mA The regulators may be going into thermal shut down, (add a heat sink and maybe a smaller (muffin) fan?) You are measuring current by looking at the front panel of your power supply (or maybe a multimeter in the power line to your board). This current measurement is an average measurement. If for instance it shows 1200 mA, and your system causes a 10uS transient of 2000 mA, the meter will probably still show 1200 mA. You need to look at the VCC rail, close to the FPGA with a fast scope, at least 100 MHz bandwidth. What you are looking for is transient drop in the VCC voltage that the FPGA sees, not what the bench power supply says it is supplying. >My thought then was that maybe the FPGA pulls down that pin >for whatever reason. So I specified a pull-up in the >constraints file. This helps. But not much. The board still >resets itself, just after a slightly longer amount of time. This suggest a power supply problem. >Then, a colleague also said that it's most likely a problem >with the power supply. I agree. >So I got a fancy electronic power supply, where you can set >the voltage to a certain level and it shows the current. Both voltage and current reading are average, at the power supply. What you need to know is what the FPGA is seeing. With your design running, the current consumption varies depending on what is happening. Depending on how the voltage regulation and decoupling is done on the board, this variable current consumption will cause variation in the voltage. None of the high speed behaviour will be shown on your bench power supply meters. You may need to add more decoupling capacitors, as well as heat sinks and fans to the on-board regulators. >The current tops at 1300 mA, which is more than the previous >power supply could handle (it says 1200 mA max). The improved >power supply helps. But, the board _still_ resets itself. The problem is likely the on-board regulator cant handle the current you design needs (although only at transient events). >Now here's something interesting: My old (working) design only >draws 1000 mA. This supports all previous conclusions. Philip Freidin =================== Philip Freidin philip.freidin@fpga-faq.com Host for WWW.FPGA-FAQ.COMArticle: 80836
> I am wondering if someone could clear this doubt for me, in case of >UART, the clock speed is 1.8432 MHZ, however it is able to transmit >maximum of 115,200 bps, however even if we are able to transmit at 1 >bit per cycle we should be able to transmit at 1,843,200 bps. What is >the rationale for making something go slowly, when it can go much >faster. The traditional implementation uses a 16x clock on the receiver. It looks for the transition on the leading edge of the start bit, then starts counting. After 1.5 baud times, it samples the first bit in the byte. That's the middle of the bit cell. 16*115200 is 1843200 You can use slower clocks, say 8x, but they you will (sometimes) be farther from the center of the bit cell and errors will be more likely. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 80837
Mook Johnson wrote:
> I'm looking to implement four, 150 tap FIR filters in an Actel MX
> series FPGA. The filters I'm designing are 16 data bit input, 16 bit
> coeffienencs and
> 1khz sample rate. FPGA will be clocked with a 10MHz clock and will
> have a state machine to retrieve the samples from the A2D following a
> 1khz
> HW interrupt.
>
> How do I estimate the resource requirements to implement the filter
> section? Any
> special hurdles in implelenting FIR filters in a Actel MX series FPGA?
>
> MX series is a fixed quantity and cannot be changed.
>
> thanks
Have you heard about the FPSLIC?
This combines an FPGA + an AVR microcontroller.
The smallest part have 20 kB of SRAM and 5 k gates.
There ar 36kb + 10kg or 36 kB + 40kg available as well.
The SRAM is by 8 only.
You have 150 coefficients and 150 samples
Each are 16 bit so you need (150 + 150) * 2 = 600 bytes per filter.
Total of 2400 bytes needed for the coefficient and the samples.
You can allocate 4 KB of the SRAM for the FPGA portion
16 or 32 kB allocated for the
You have to do 150 multiply and add per millisecond per filter,
so 600 multiply in 10000 clock cycles.
This means 16 clocks are available per multiply.
For the smallest FPSLIC part you get 12 x (32 x 4 DPRAMs).
There are 4 more, but they are ROM only.
You use 10 of them to implement an 40 bit dual port register file.
Implement an 8 bit multiplier in the FPGA and run 4 cycles.per multiply.
R0 := LowCoeff1 (Cl); temp = 40'b0; Acc =
0; -- init
R1 := LowSample1 (Sl) ; temp = {24'b0,Cl * Sl}; Acc = Acc +
temp; -- add 0 the first time
R2 := HiSample1 (Sh) ; temp = {16'b0,Cl * Sh,8'b0}; Acc = Acc +
temp;
R3 := HiCoeff1 (Ch); temp = {16'b0,Ch * Sl,8'b0}; Acc = Acc +
temp;
R0 := LowCoeff2 (Cl); temp = {8'b0Ch * Sh,16'b0}; Acc = Acc + tem
p;
R1 := LowSample2 (Sl) ; temp = {24'b0,Cl * Sl}; Acc = Acc
+temp;
...
The AVR will handle the interrupt and the ADC.
Can probably read the ADC using bitbanging to save FPGA real estate.
The AVR can write to the FPGA RAM without any problems.
The FPGA never writes to the RAM so it will only use the read port.
Think this should be a real nice application for the FPSLIC.
--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
Article: 80838Hi everyone, I'm going to buy Xilinx ISE Foundation, I'd like to know if this package contains also IP cores like DDC, FFT and so on. It seems that the "LogiCore" IPs should be shipped within ISE Foundations, am I right? -- I do whatever the voices tell me to do. |\ | |HomePage : http://nem01.altervista.org | \|emesis |XPN (my nr): http://xpn.altervista.orgArticle: 80839
On 11 Mar 2005 07:57:20 -0800, lecroy7200@chek.com wrote:
>I am looking at a design that was done several years back which uses
>several XC3000 devices. All devices are programmed with the same core
>from a computer on power up. What I am seeing is that once or twice a
>year, one of the devices will enter a non-recoverable mode. In this
>mode, the device appears to be in power down or reset. Once in this
>mode I am no longer able to program the device. Pulling the XC3000's
>reset low for 10us has no effect. The problem appears random. The
>only way to reprogram the part is to power down the IC. I have tried
>running tests where I just reprogram the device, over heat the device,
>change the supply voltages, etc. and can't reproduce the problem. When
>the Xilinx device is in this mode, it draws little power. It can be
>held in this mode for what appears an infinite amount of time and
>causes no damage to the device.
>
>Was there some kind of an undocumented test mode built into the XC3000
>that I may be seeing? Does anyone else ever remember seeing a problem
>like this?
This sounds like something that used to be called the "brownout" problem.
I did a xilinx search, but found nothing. Must have been purged.
I seem to remember that the problem occurs if there is a low going
transient that drops below some level (like 3.0 V) which causes
the chip to do house cleaning (wiping the config memory), but doesn't
go low enough to trigger the re-configuration logic.
Maybe Peter Alfke can remember better than me? This problem was fixed
around 1989 I think.
The solution may involve changes to your power supply, such that if
the voltage ever dips below say 4.5V, you make sure it goes all the
way down to 0V, for maybe 100 mS, before it comes back up.
A google search found this:
http://www.sltf.com/articles/pein/pein9507.htm
which sort of confirms the fault mode.
Philip Freidin
Philip Freidin
Fliptronics
Article: 80840"Hal Murray" <hmurray@suespammers.org> wrote in message news:tdednf4NTuXAL6_fRVn-vg@megapath.net... > > I am wondering if someone could clear this doubt for me, in case of > >UART, the clock speed is 1.8432 MHZ, however it is able to transmit > >maximum of 115,200 bps, however even if we are able to transmit at 1 > >bit per cycle we should be able to transmit at 1,843,200 bps. What is > >the rationale for making something go slowly, when it can go much > >faster. > > The traditional implementation uses a 16x clock on the receiver. > > It looks for the transition on the leading edge of the start bit, > then starts counting. After 1.5 baud times, it samples the first bit > in the byte. That's the middle of the bit cell. The oversampling not only makes it possible to determine the position of the start bit, but also it combats the noise and errors. The 16 consecutive sampled values (each being 0 or 1) are used to decide on the actual bit value. If most of these 16 samples are 1, it's 1. Otherwise, it's 0. A better (in terms of error immunity) UART is one that works with a current loop instead of the regular that works with voltage. > 16*115200 is 1843200 > > You can use slower clocks, say 8x, but they you will (sometimes) be > farther from the center of the bit cell and errors will be more likely. The start bits help to resynchronize. If the data flow isn't continuous but often have all ones, the receiver and xmitter clocks may not match each other well, provided all bits in a byte are decoded correctly. Good hardware implementations may adjust themselves to the clock offset. AlexArticle: 80841
> I don't really know what your are doing other > than drawing boxes inside boxes. The fact that > you are counting up output registers leads me to > think that you might need fewer boxes with > more logic in them. I think the OP asked for a proper design demo on the single signal path example.Article: 80842
Hi, The part looks promising, but I don't believe that someone in the newsgroup will have experience with it. The device is only announced last week. But if indeed soneone has experience, please let me know too. Luc On 9 Mar 2005 07:48:30 -0800, "Teo" <themarenas@comcast.net> wrote: >Does anyone have experience with Lattice's XP (flash + sram) fpga? >This technology looks great, instant on, reconfigurable & total >security. >I've been impressed with the progress of their sw, althogh it is not up >to ISE, it seem more than adequate.Article: 80843
ezpcb.com wrote: > > sorry for spamming, but good to everybody: > > There's a way to get $200 laser-cut SMD soldering stencils for free! > see http://www.ezpcb.com for details > > mike Yes, spamming this is indeed ... Just looked at ezpcbs.com to compare prices with www.pcbexpress.com, a company we have used in the past and are *very* satisfied with. A few weeks ago we had pcbexpress make 25 proto boards for us. 4 layers, 8.5 cm x 13 cm, 7 mil t/s, silk screen on both sides, fr4 ... Total cost was $650, including international UPS shipping. According to ezpcb.com web site, just the boards would cost us $1028,75 USD using some unknown outlet in Beijing .... that likes to spam this newsgroup ... pcbexpress offers a stencil *kit* for some $150 USD as well, so even if you buy the stencil, you still save money ... I don't know ... what do you mean with "good to everybody" anyway ? Check out http://www.pcbexpress.com Just a happy customer .... rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 80844
Rudolf Usselmann wrote: > ezpcb.com wrote: > >>sorry for spamming, but good to everybody: >> >>There's a way to get $200 laser-cut SMD soldering stencils for free! >>see http://www.ezpcb.com for details >> >>mike > > > Yes, spamming this is indeed ... > > Just looked at ezpcbs.com to compare prices with www.pcbexpress.com, > a company we have used in the past and are *very* satisfied with. > > A few weeks ago we had pcbexpress make 25 proto boards for us. > 4 layers, 8.5 cm x 13 cm, 7 mil t/s, silk screen on both sides, > fr4 ... Total cost was $650, including international UPS shipping. > > According to ezpcb.com web site, just the boards would cost > us $1028,75 USD using some unknown outlet in Beijing .... that > likes to spam this newsgroup ... > > pcbexpress offers a stencil *kit* for some $150 USD as well, so > even if you buy the stencil, you still save money ... > > I don't know ... what do you mean with "good to everybody" > anyway ? Check out http://www.pcbexpress.com > > Just a happy customer .... > ANd what the hell has SMD stencil to do with FPGA newsgroup? Apparently this spammer has only posted here... I would never order any prototype boards from China...or generally outside Europe..even have problem with certain countries in Europe as well... And besides...I'm still the kinda person which also looks at the first impression...and this website looks like in those good ole days when I used netscape 1.x/2.x (o; rickArticle: 80845
> The start bits help to resynchronize. If the data flow isn't continuous but Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the pauses between bytes can be of arbitrary time. Only the timings between bits in a byte are established. Serial line has no notion of the "packet". -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.comArticle: 80846
Rudolf Usselmann wrote: > ezpcb.com wrote: > > A few weeks ago we had pcbexpress make 25 proto boards for us. > 4 layers, 8.5 cm x 13 cm, 7 mil t/s, silk screen on both sides, > fr4 ... Total cost was $650, including international UPS shipping. > 25 pieces of 4-layer boards this size incl. 2nd silkscreen costs around 600 US$ at eurocircuits. And that is including VAT and shipping costs... rickArticle: 80847
Sorry for the basic question! I' d like to know if with the ISE Webpack of Xilinx i can obtain the .vhd file of the synthesized netlist. I can view the RTL schematic double-clicking on the "View RTL schematic" option of the Synthesize tag and i can view the .vhd report of the traslate tag. The latter ( as is specified in the file ) is only for simulation purpose and haven't a one to one correspondence with the primitives and the hardware really used. Is the VHDL netlist voluntarily hidden? If not, where i can find the file? If yes, is there something that i can do to obviate it? I'm asking that because i' d like to obtain a netlist synthesized in VHDL and try a place and route with another tool, with a standard cell library mapped on the basic gates of a XC9500 architecture. Thanks in Advance!Article: 80848
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message news:d0ur3u$1vn9$1@gavrilo.mtu.ru... > > The start bits help to resynchronize. If the data flow isn't continuous but > > Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the > pauses between bytes can be of arbitrary time. Only the timings between bits in > a byte are established. > > Serial line has no notion of the "packet". Packetization is an artificial thing. Normally, the physical data channels are continuous and bear no idea of any data packetization. Packets are just a way to transfer data in portions, which is most useful in the channels, where the data can be lost or corrupted. Chunks of data are numbered and redundancy is appended to make sure anything lost or corrupted can be requested for retransmission. Another way to combat data corruption is to add the redundancy into the data itself, by some forward error correction (FEC) mechanism. The receiving party can recover some errorneus bits in the data from the data with added redundancy. Although FECs can help a lot, they're not always practical because they require bigger bandwith and of course not every error can be corrected with them (the Hamming distance of the FEC determines the correcting performance). AlexArticle: 80849
"Marc Randolph" <mrand@my-deja.com> wrote in message news:1110603050.126155.280760@o13g2000cwo.googlegroups.com... > > I'm not sure if you are asking because I put a ballpark price in my > response, or if you're just wondering my experience with the parts. > > I happen to be using a quad-port Broadcom part, although not in > 1000Base-T mode (I use 1000Base-X mode). Support isn't the fastest, > and you have to put up with their never-ending paranoia, but the parts > work well. Thanks Marc. I was interested in your experience... /Mikhail
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