Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi folks, I've just been re-reading the "JTAG madness" thread from a couple of weeks ago, some great stuff in there, and has raised a question in my mind: If you have a mixture of Xilinx and non-Xilinx devices in a JTAG chain, assuming you have a BDSL file for the non-Xilinx parts, can the Xilinx JTAG tools handle this situation? Specifically, will iMPACT puke if there's a non-xilinx device in the chain? What about the XMD program that drives the JTAG port to do debugging for Microblaze and V2PRo PPC systems? I'd like to stick with the standard Xilinx programming tools if possible, so if they can't handle heterogenous JTAG chains then I might be better splitting it out into 2 distinct chains... any thoughts or suggestions? Thanks, JohnArticle: 58151
I wrote: > Specifically, will iMPACT puke if there's a non-xilinx device in the > chain? After RTFM the iMPACT manual claims it can handle this. Anyone actually done it and have any comments? > What about the XMD program that drives the JTAG port to do > debugging for Microblaze and V2PRo PPC systems? Still curious about this one. Cheers, JohnArticle: 58152
>This implementation and consequent resulting delays issue is begining to >drive me around the bend. >Below is a small diagram of my schematic. >To ensure tha OP2 (Output 2) changes state after OP1 (Output 1) >I set up the circuit as shown. >However I find in my simulation results that OP2 changes state >before OP1. >This appears to defy the laws of physics but Im sure there is a simple >explenation. The fundamental problem is that the tools don't support what you are trying to do. And if you need a minimum delay, the silicon doesn't really support it either. When you draw a pile of gates like that, the system tosses them in the air and comes up with an equivalent circuit that usually fits better in the part. While doing that, it doesn't worry about relative timing. It's just trying to meet setup times for the next clock. It often makes copies of your "gates" since they are free if the LUT has unused inputs. Have you tried the floorplanner or such to see what they actually did? The first approach is to find some way to do the job with "simple" cleanly clocked logic. That's what the tools expect you to be doing. If you can get a 2x clock, then you can put a FF after the OR gate for OP1, (and fixup the logic) and then run that signal over to the gate for OP2. That doesn't guarantee that OP1 will get to the outside world before OP2. Can you add a half clock (double clock?) delay? If so, add a FF on OP2 and clock it on the other edge. If you really want clean timings on the outside world, you want to use FFs in the IOBs. (perhaps cloning the logic, so you have a copy inside to feed to other logic) You probably CAN trick the tools into doing something useful, but you will have problems like this, and if you change anything or the tools change, you might have to go through this all over again. It's an interesting chicken-egg problem. Because the tools don't support this sort of thing, not many people try to do it. Since not many people do it, there is no demand for the tools to support it. Do you have spare IO pins? One thing you can do is bring OP1 out on one pin and back in on another without telling the system about the external connection. You can probably bring it back in on the same pin, but now you are taking the risk that some smart tool will see what you are doing and "fix" it up for you. -- 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: 58153
> I'm making a pcb with a xilinx FPGA. I will obviously put a JTAG header >on my board. I simply want to know what is the standard pinout for the >header. Looking a the specs for the Parallel IV cable from xilinx I found >the following pinout: ... > Conclusion, I don't know what to use. The pinout from xilinx seems space >wasteful. What would you put on your board? What are you going to connect it to? There are various semi-smart boxes that have an ethernet port (or RS232/USB) and a JTAG connector. The ones I've seen have a ribbon cable with lots of grounds. I think the JTAG standards committee blessed this setup and probably even has mechanical specs on the connector. (I think I've seen a reset signal on pin 12 or 14.) The wasteful grounds will let you use a longer cable before you run into signal ingegrity problems. If you are just using a JTAG pod with short individual wires setup to push on 0.025 pins, use any connector that's convenient. -- 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: 58154
Can anyone tell me what the effect of dendrites is? I think I know what
they are physically, but I wonder what the effect is electrically and over
what sort of time frame they develop.
Thanks,
Theron
<james> wrote in message news:pr26hv0eeukppkjos0ehr7nm6un5l8c9oo@4ax.com...
> My experience comes from layout of small circuit boards for wireless
> data communications. In this arena the reciever antenna was generally
> not more than 0.5 inch distance from one to two microcontrollers and
> memeory chips. So the minimization of any ground and power loops and
> radiation was a primary concern as they were the high current carrying
> traces. Even at 1 Mhz internal buss frequency you would be surprised
> how much noise comes out of an MC68HC11 micro controller. Especially
> when the receiveing antenna is only half an inch away from the chip.
>
> Ceramic chips do have their problems with dendrites if the PCB is not
> thoroughly cleaned of chlorides. Tantalums can be damaged during
> drops. They also do not like RF currents either.
>
> Then there is ESD spikes! that is another subject to its own.
>
> james
>
>
> On Sun, 13 Jul 2003 22:53:46 -0400, "t hicks" <hicksthe@egr.msu.edu>
> wrote:
>
> >James,
> > Some good points, however I will disagree on two issues. First, I
> >personally do my power routing last on multilayer boards. I expect that
I
> >will need to shove some traces slightly in order to get them in.
However,
> >for me this gets better overall routing with very short traces to power
> >pads. The one exception to this is in FPGA designs where I do carefully
> >route the FPGA supplies first. Even then I expect that I will need to do
> >some substantial re-routing to finally get all the signals in.
> > Also, I detest high value ceramics. From painful experiences with
> >strange leakage behavior (such as behaving like a low voltage zener) I am
> >now avoiding them like the plague.
> > Of course, these are only my personal experiences. The routing, I am
> >sure is puerly a matter of personal preference. I know that many people
use
> >large value ceramics with no problems, so consider that to be just a
> >warning. If you see the same issues, then you usually can get away with
> >mounting a small tantalum on a large (1206 size or bigger) ceramic as
long
> >as the voltage is very low. By the way, I use many more bulk capacitors
> >that the norm as I have had problems with noise showing up in the low
noise
> >analog parts of my system. On a spartan2e, I am using 8 0.1uf ceramics
and
> >8 10uf 4v tantalums per supply (1 pair {tant and ceramic} per bank per
> >supply) . And before you ask... Is that _really_ necessary? Yes, it
does
> >seem to show up in the final system noise behavior.
> >
> >Thanks,
> >Theron
> >
> ><james> wrote in message
news:cog3hv8kgkapng9q83fr24h9n7nqtgiud3@4ax.com...
> >> Many of the comments here have been great.
> >>
> >> I would add this from some thoughts and experience in layout.
> >>
> >> If the device is not being used near any RF circuitry then the bypass
> >> caps are of adequate value. If there is nearby RF circuitry then add
> >> either 100pF or 30pF caps. The 100pF is good for VHF frequencies and
> >> the 30pF cap is good for UHF. I would change from tant caps to ceramic
> >> for the 10uF caps though.
> >>
> >> Still all the steps used to elliminate EMI suggested are good. A note
> >> on the 208 pin package, it is big and it will radiate no matter how
> >> careful your bypasses are and board layout.
> >>
> >> I reccommend that the you do a signal layer, followed by a ground
> >> layer, then power, and finally the bottom layer can be mixed but
> >> should primarily be signal. The power layer can have multiple voltages
> >> on the plane. It is best to keep a 20 to 1 separation between powers.
> >> Thus if you are using a 0.062 laminate, you will have between 18 and
> >> 22 mils between layers. I then would leave at least 40 mils preferably
> >> 80 mils between traces on the different power busses. This will
> >> minimize E-fields that fringe off the power runners.
> >>
> >> I am not a big fan of blind vias as Xilinx shows in their app note.
> >> They are expensive and difficult to troubleshoot. Heaven forbid if one
> >> is open either. The board is then shot. Avoid them at all costs.
> >>
> >> Vias to the ground plane and power should be at least two of them per
> >> trace. Especially in high current, peak or constant, traces. Good idea
> >> in case the PCB fabricator screws up on the plated through holes. Vias
> >> through the power and ground planes should have at least 20 mil anular
> >> space around the via. More on faster switching lines if possible.
> >>
> >> One very important thing. Layout power and ground first. Before you
> >> route any signal line do power and ground first. They should be as
> >> direct from the source to the devices as possible. Avoid power loops.
> >> Branch power from the power buss to the components. Also keep all
> >> power runners 40 to 80 mils from the edge of the board. Ground plane
> >> can extend to about 10 mils to the edge. Signals should not be closer
> >> than 20 mils to the edge.
> >>
> >> some thoughts
> >>
> >> james
> >>
> >> On Fri, 11 Jul 2003 15:51:01 -0400, "..:: Gabster ::.."
> >> <gabsterblue@hotmail.com> wrote:
> >>
> >> >Hi,
> >> >
> >> >I'm made many 2-layer PCB's in the past years, but I'm about to start
the
> >> >desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx
> >> >Spartan IIE XC2S300 in PQ208 package running at ±12MHz), 3 power
supply
> >> >regulators, an oscillator block, a PROM and a logic IC.
> >> >
> >> >In addition to other literature, I read the following document:
> >> >http://www.xilinx.com/xapp/xapp623.pdf
> >> >but it is rather complicated and not straight foward for a rookie like
me
> >in
> >> >FPGA design! So here's a few direct questions:
> >> >
> >> >1) 4-layer, why is it so important?
> >> >
> >> >2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or
> >> >TOP/POWER/GND/BOTTOM), why?
> >> >
> >> >3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1µF
> >per
> >> >power pin (1.8V and 3.3V) + one 10µF per power supply (1.8V and 3.3V).
Is
> >> >that accurate? Should I do more? What should I avoid?
> >> >
> >> >4) What is the concept surrounding islands on the power plane? What
> >should
> >> >that plane look like? What should I avoid? What the hell about it,
this
> >> >plane is a mystery for me!!!
> >> >
> >> >In order to avoid asking 1000's other questions, I wonder if someone
> >could
> >> >also direct me toward a complete document talking about PCB design
> >> >guidelines for PQ package FPGA's. I found that for the BGA packages on
> >> >xilinx website, but it didn't help me much.
> >> >
> >> >Thanks a lot,
> >> >Gabriel
> >> >
> >>
> >
>
Article: 58155If you folks are looking for DIMM format FPGA module for development/prototype work I have such a beast. The module accept Xilinx Virtex FPGA (PQ-240/HQ-240) for more information - you can visit my web page at http://snaplogix.tripod.comArticle: 58156
Dendrites (small migrations of metals or other conductive material) will
short out adjacent connections. Exotic materials (like silver without
the anti-dendrite palladium) or normal materials under a bias during
processing can cause the growth of dendrites.
We had a battery for our Real Time Clock that went through the solder
wave. The battery was spec'ed for the process, allowing the short
duration short circuit. But once through the wave, the battery provided
a nice little field between ADJACENT power and ground pins on the RTC
chip. Some boards outright didn't come up. Other boards failed over
time or were out of spec because the dendrites provided a resistive path
rather than a dead short. Fun!
t hicks wrote:
> Can anyone tell me what the effect of dendrites is? I think I know what
> they are physically, but I wonder what the effect is electrically and over
> what sort of time frame they develop.
>
> Thanks,
> Theron
>
> <james> wrote in message news:pr26hv0eeukppkjos0ehr7nm6un5l8c9oo@4ax.com...
>
>>My experience comes from layout of small circuit boards for wireless
>>data communications. In this arena the reciever antenna was generally
>>not more than 0.5 inch distance from one to two microcontrollers and
>>memeory chips. So the minimization of any ground and power loops and
>>radiation was a primary concern as they were the high current carrying
>>traces. Even at 1 Mhz internal buss frequency you would be surprised
>>how much noise comes out of an MC68HC11 micro controller. Especially
>>when the receiveing antenna is only half an inch away from the chip.
>>
>>Ceramic chips do have their problems with dendrites if the PCB is not
>>thoroughly cleaned of chlorides. Tantalums can be damaged during
>>drops. They also do not like RF currents either.
>>
>>Then there is ESD spikes! that is another subject to its own.
>>
>>james
>>
>>
>>On Sun, 13 Jul 2003 22:53:46 -0400, "t hicks" <hicksthe@egr.msu.edu>
>>wrote:
>>
>>
>>>James,
>>> Some good points, however I will disagree on two issues. First, I
>>>personally do my power routing last on multilayer boards. I expect that
>>
> I
>
>>>will need to shove some traces slightly in order to get them in.
>>
> However,
>
>>>for me this gets better overall routing with very short traces to power
>>>pads. The one exception to this is in FPGA designs where I do carefully
>>>route the FPGA supplies first. Even then I expect that I will need to do
>>>some substantial re-routing to finally get all the signals in.
>>> Also, I detest high value ceramics. From painful experiences with
>>>strange leakage behavior (such as behaving like a low voltage zener) I am
>>>now avoiding them like the plague.
>>> Of course, these are only my personal experiences. The routing, I am
>>>sure is puerly a matter of personal preference. I know that many people
>>
> use
>
>>>large value ceramics with no problems, so consider that to be just a
>>>warning. If you see the same issues, then you usually can get away with
>>>mounting a small tantalum on a large (1206 size or bigger) ceramic as
>>
> long
>
>>>as the voltage is very low. By the way, I use many more bulk capacitors
>>>that the norm as I have had problems with noise showing up in the low
>>
> noise
>
>>>analog parts of my system. On a spartan2e, I am using 8 0.1uf ceramics
>>
> and
>
>>>8 10uf 4v tantalums per supply (1 pair {tant and ceramic} per bank per
>>>supply) . And before you ask... Is that _really_ necessary? Yes, it
>>
> does
>
>>>seem to show up in the final system noise behavior.
>>>
>>>Thanks,
>>>Theron
>>>
>>><james> wrote in message
>>
> news:cog3hv8kgkapng9q83fr24h9n7nqtgiud3@4ax.com...
>
>>>>Many of the comments here have been great.
>>>>
>>>>I would add this from some thoughts and experience in layout.
>>>>
>>>>If the device is not being used near any RF circuitry then the bypass
>>>>caps are of adequate value. If there is nearby RF circuitry then add
>>>>either 100pF or 30pF caps. The 100pF is good for VHF frequencies and
>>>>the 30pF cap is good for UHF. I would change from tant caps to ceramic
>>>>for the 10uF caps though.
>>>>
>>>>Still all the steps used to elliminate EMI suggested are good. A note
>>>>on the 208 pin package, it is big and it will radiate no matter how
>>>>careful your bypasses are and board layout.
>>>>
>>>>I reccommend that the you do a signal layer, followed by a ground
>>>>layer, then power, and finally the bottom layer can be mixed but
>>>>should primarily be signal. The power layer can have multiple voltages
>>>>on the plane. It is best to keep a 20 to 1 separation between powers.
>>>>Thus if you are using a 0.062 laminate, you will have between 18 and
>>>>22 mils between layers. I then would leave at least 40 mils preferably
>>>>80 mils between traces on the different power busses. This will
>>>>minimize E-fields that fringe off the power runners.
>>>>
>>>>I am not a big fan of blind vias as Xilinx shows in their app note.
>>>>They are expensive and difficult to troubleshoot. Heaven forbid if one
>>>>is open either. The board is then shot. Avoid them at all costs.
>>>>
>>>>Vias to the ground plane and power should be at least two of them per
>>>>trace. Especially in high current, peak or constant, traces. Good idea
>>>>in case the PCB fabricator screws up on the plated through holes. Vias
>>>>through the power and ground planes should have at least 20 mil anular
>>>>space around the via. More on faster switching lines if possible.
>>>>
>>>>One very important thing. Layout power and ground first. Before you
>>>>route any signal line do power and ground first. They should be as
>>>>direct from the source to the devices as possible. Avoid power loops.
>>>>Branch power from the power buss to the components. Also keep all
>>>>power runners 40 to 80 mils from the edge of the board. Ground plane
>>>>can extend to about 10 mils to the edge. Signals should not be closer
>>>>than 20 mils to the edge.
>>>>
>>>>some thoughts
>>>>
>>>>james
>>>>
>>>>On Fri, 11 Jul 2003 15:51:01 -0400, "..:: Gabster ::.."
>>>><gabsterblue@hotmail.com> wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I'm made many 2-layer PCB's in the past years, but I'm about to start
>>>>
> the
>
>>>>>desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx
>>>>>Spartan IIE XC2S300 in PQ208 package running at ±12MHz), 3 power
>>>>
> supply
>
>>>>>regulators, an oscillator block, a PROM and a logic IC.
>>>>>
>>>>>In addition to other literature, I read the following document:
>>>>>http://www.xilinx.com/xapp/xapp623.pdf
>>>>>but it is rather complicated and not straight foward for a rookie like
>>>>
> me
>
>>>in
>>>
>>>>>FPGA design! So here's a few direct questions:
>>>>>
>>>>>1) 4-layer, why is it so important?
>>>>>
>>>>>2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or
>>>>>TOP/POWER/GND/BOTTOM), why?
>>>>>
>>>>>3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1µF
>>>>
>>>per
>>>
>>>>>power pin (1.8V and 3.3V) + one 10µF per power supply (1.8V and 3.3V).
>>>>
> Is
>
>>>>>that accurate? Should I do more? What should I avoid?
>>>>>
>>>>>4) What is the concept surrounding islands on the power plane? What
>>>>
>>>should
>>>
>>>>>that plane look like? What should I avoid? What the hell about it,
>>>>
> this
>
>>>>>plane is a mystery for me!!!
>>>>>
>>>>>In order to avoid asking 1000's other questions, I wonder if someone
>>>>
>>>could
>>>
>>>>>also direct me toward a complete document talking about PCB design
>>>>>guidelines for PQ package FPGA's. I found that for the BGA packages on
>>>>>xilinx website, but it didn't help me much.
>>>>>
>>>>>Thanks a lot,
>>>>>Gabriel
>>>>>
>>>>
>
>
Article: 58157Hi Bruce - will you be able to tell us if Platform Flash can be used to configure SpartanXL? --Neeraj "Bruce Jorgens" <bruce.jorgens@xilinx.com> wrote in message news:3F1427A9.DBA42BFD@xilinx.com... > Gabriel, > > The size of the bitstream required to configure the FPGA does not change as > you use more of the FPGA resources. Based on the 89% full PROM, I assume you > are using the XC2S300E device. As you exploit more of the FPGA your PROM will > stay 89% full so there is no need for you to use a larger PROM. > > If you want the lowest cost, smallest boardspace solution, you should look at > our recently released Platform Flash family of configuration PROMs. The > XCF02S is available now and will configure your XC2S300E. You can find the > cross-reference to Spartan-IIE at: > > http://www.xilinx.com/isp/compfpgatables/pfp_spartan.htm > > Bruce Jorgens > > "..:: Gabster ::.." wrote: > > > The size of the PROM recommended for each Spartan model is shown here: > > http://www.xilinx.com/isp/compfpgatables/prom_spartan.htm > > > > Why can't I use a 4Mb PROM with my Spartan IIE FPGA. Right now, on a 2Mb > > (the recommended one), the PROM is 89% full but the FPGA is far from being > > completly exploited. > > > > thanks, > > Gabriel >Article: 58158
Thanks a lot for the help, Best regards, Javier Philip Freidin <philip@fliptronics.com> wrote in message news:<80l8hvglo180v5ook1n4cva4b23um5415l@4ax.com>... > On 14 Jul 2003 10:14:35 -0700, javodv@yahoo.es (javid) wrote: > >Hello to All, > > > >I was wondering if it is possible to program a PLD/CPLD via a PIC > >(without connecting external memory). The PIC I am using has a > >internal RAM of 768 bytes and 16k of flash. I have seen some app.notes > >from Altera/Xilinx/Lattice but I think that I need a more powerful > >micro for doing the CPLD reprograming with it. Is there any new small > >CPLD easy to reprogram?. I would appreciate any suggestion or link. > > > >Thanks a lot and best regards, > > > >Javier > > You may find the following two links helpfull > > http://www.fpga-faq.com/FAQ_Pages/0036_Config_FPGA_with_PIC_and_Cheap_SEPROM.htm > > http://www.fpga-faq.com/FAQ_Pages/0038_Config_FPGA_from_a_processor.htm > > > > Philip Freidin > FliptronicsArticle: 58159
Hi, I'm using ISE 5.02.03 It looks like they (Xilinx) removed the EDIF option from XST. I found it in a google groups search (lots of people using it in 4.2i), and I found it in the version 3 XST manuals: set the output format to EDIF with -omft EDIF When I try that with 5.2i, I get an error:1361 (invalid omft option) So... How does one create and EDIF with XST? Please Help, Gary gwhelbig -at- yahoo -dot- comArticle: 58160
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:bf2ckr$rj6$1@bunyip.cc.uq.edu.au... > > I wrote: > > > Specifically, will iMPACT puke if there's a non-xilinx device in the > > chain? > > After RTFM the iMPACT manual claims it can handle this. Anyone actually > done it and have any comments? We had an Atmel atmega16 device in series with an XCR3032XL, we had a valid BSDL file for it, and iMPACT (I think we tried 5.1 and the latest and greatest) would give us a curious message like: 100010000 expected 100010000 returned yes they are identical. This was the expected SIR result from scanning the jtag chain. IF there was a subtle error in the BSDL, we'll never know. Later I had the pleasure of building programming equipment for our product, so I know the chain on this one is properly connected. This took some time as I modified the 5.00 version of XSVF player to retarget devices on the fly (this feature was present in an earlier version, but appears to be have taken out). My own TAP software will tell me that there's an Atmel-unknown in position 1, XC3032XL in position 2, and so forth. Why can't xilinx' tool? To be fair, Atmel's ICE is just as stupid. There seems to be very little focus on getting the file into the device, I wonder if other companies have to do similar kludges. /Kasper *The interface I use is compatible with Parallel-III, but electrically it's quite different from it, and does not suffer from the P3's port-, crosstalk-, bounce-, or level problems. Whoever designed the P-3 was in a hurry and on a very small budget.Article: 58161
>Second, can I get the bus working correctly for the data stuff. Note: the >bus uses standard lvttl (3.3v) for logic signals at a minimum pulse width of >about 40 ns. As a straw man, consider PCI. It runs a bit faster than 40 ns, but it doesn't get anywhere near 18 slots. > The bus has a total of 19 connectors spaced at about .75" apart. > Some of the connectors could be left open and also there will be a sort stub > on the individual cards that must be terminated in some fashion. Usual practice with multidrop back plane busses is to make that stub as short as possible and live with it. (no termination) It screws things up, generally by looking like a small cap which reduces the effective impedance of the backplane. (Same math as a row of memory chips on a bus.) Sometimes with things like this, you can gain a factor of 2 by putting the master card in the middle and splitting the bus into two. Or you split it into 4 and interlace the cards on each side. One thing to consider is putting terminators at each end of the backplane and using something other than LVTTL. I expect you will be doing lots of simulations. Please let us know what you decide to build and/or how well it works. -- 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: 58162
Mike Treseler <mike.treseler@flukenetworks.com> wrote: > If I have constants and functions to share between processes, > I use the default "work" library, as this is much less trouble > and more portable than naming and maintaining my own library. I don't think that this is very portable. If you reuse your code, you have to be very careful about constant names, there might be more packages including a constant with a specific name. Eg. you use a library bus_master and a library bus_slave, you don't have to care about constants names with the same name for master and slave IP. bye ThomasArticle: 58163
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F140004.C45EBEAA@yahoo.com>... > Antti Lukats wrote: > > > > Hello, > > > > I have read the docs, but still unclear if the JTAG boundary scan could > > be used during configuration, i.e. > > > > 1) small microcontroller connected to JTAG and selectmap pins > > 2) Xilinx Spartan II/Virtex > > 3) Parallel flash connected to FPGA > > > > microcontroller used Boundary scan to fetch from Flash > > then writes the configuration using selectmap > > > > as per xilinx docu this doesnt sound like not possible but I wonder > > if anyones has experience with that, or knows for sure if this > > approuch could work or not > > > > I think using boundary scan during JTAG configuration is not allowed > > but during selectmap? > > > > antti > > None of this sounds hard to me. The step of reading the Flash by > driving the JTAG pins seems a bit complex and will be very slow, but it > should work. But where are you going to store the configuration data > while in the JTAG Flash read mode? It will be much more expensive to > have that much RAM available. It would be better to hang the Flash off > the MCU rather than on the FPGA. Then you can program each byte as you > read it and don't need all that RAM storage. > > I have recently taken a look at NAND flash and it does not need the > large number of address lines and is much cheaper than NOR Flash. You > only need about 12 or 14 signals to connect to it and control it through > the 8 bit data port. It is easy to do this through a pair of 8 bit > ports on an MCU. > thats the point I start selectmap configuration, then fetch byte from flash and write to fgpa then fetch another and so on I only need 1 word buffer in the micro the flash will later on be used as instruction memory for Microblaze I could add a small PLD to the flash address pins (for config), but that takes more board space anttiArticle: 58164
"tk" <tokwok@hotmail.com> wrote in message news:<bf1124$60r$1@hkueee5.eee.hku.hk>... > Hi all, > > When I try to follow the steps to make a bitstream of ML300 Embbedded > reference system in Virtex-II Pro Development Kit, I get the following > error during Mapping: > > ERROR:Pack:18 - The design is too large for the given device and package. > Please check the Design Summary section to see which resource requirement > for your design exceeds the resources available in the device. .. > I would like to ask how could I solve the *OVERMAPPED* problem? > There is pre-built bitstream file in the reference design. How come I > can't create one myself ?! welcome abroad!!! this what you just discovered is driving me crazy too - because almost nothing fits into VP7 if you try to use XST synthesis !!! Xilinx reply was: V2PDK reference designs are all targeted for Synplify. I am trying to use XST what works only if 1) I use Verilog (VHDL gives error in v2pdk_lib_utils or somewhere..) 2) when I disable almost all peripherals (to be able to fit) Synplify probably removes the non-related logic better tha XST that all. And thats all thing you done know (until you buy ML300) anttiArticle: 58165
>I'm made many 2-layer PCB's in the past years, but I'm about to start the >desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx >Spartan IIE XC2S300 in PQ208 package running at ±12MHz), 3 power supply >regulators, an oscillator block, a PROM and a logic IC. I'll start by repeating Kolja's suggestion to get a copy of "High Speed Digital Design - A Handbook of Black Magic". Johnson and Graham. List is $95. It won't solve this problem directly, but it will give you the background you need to think about this area. It's also fun reading. Every time I go to look something up I get sucked into rereading some other section. It's got the right level of math for me. The formulas are there if I ever need them, but it's got enough rules of thumb that I can (mostly) avoid the formulas. One thing to keep in mind is that your 12 MHz isn't the critical parameter, it's the edge rate on the signals. You want to run the edges as slow/gentle as you can. Set the IOBs to low drive current and such. If I was working on a board like this, I'd start by asking how I was going to get the power to the FPGA. Multiple power supplies are a lot simpler if you have a plane per power rail and another for ground. Since you only have 2 layers for power planes, you are off by 2 from the simple case. I'm assuming that you can place the other parts so that the general layout is (say) 2.5 V parts on the left and 3.3 V parts on the right. If so, then you can "split" the power plane down the middle with a "cut" in the copper and get two planes on one layer. Note that you have to think about any signals that cross that cut. The mirror currents have to get from one side of the split to the other. They can't jump across the cut. (General idea is "don't do that".) That cut might run down the middle of the FPGA. That (hopefully) saves one plane, but you still have one to go. Is the routing on your board going to be "nice"? At least around the FPGA? Can you basically run most of the signals directly from the pads on the top layer over to where they connect? (or do you have all sorts of signals crossing and tripping over eachother?) If the routing is clean, then the top layer under the chip isn't needed for routing. I'd put a small plane in there for the core voltage. It gets low inductance connections to all the core pins. Then I'd put bypass caps on the bottom, under the chip, inside the pads. Again, that assumes that space isn't needed for routing. That's where they can get good connections to both the core "plane" and the ground plane. > 3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1µF per > power pin (1.8V and 3.3V) + one 10µF per power supply (1.8V and 3.3V). Is > that accurate? Should I do more? What should I avoid? That's a reasoanable ballpark. Inductance is what you want to avoid. Vias count, so do long traces from pads to vias. > 4) What is the concept surrounding islands on the power plane? What should > that plane look like? What should I avoid? What the hell about it, this > plane is a mystery for me!!! A plane is just a convenient way to get low-inductance. You have to find a way to position the planes and the chips (and bypass caps) so they can connect easily (rather than running long traces way over to there). Don't forget remote sense on the power regulator. How much IR drop will you have between the regulator on the far corner of the board and the chip where the power gets used? (Planes are low resistance too.) This is especially important for the core voltage to the FPGA if you don't have a plane to dedicate to it. Might be OK if you can make the feeder trace fat enough. Just another thing for the checklist. -- 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: 58166
"Brad Smallridge" <bsmallridge@dslextreme.com> wrote in message news:<vh901e9sds8c26@corp.supernews.com>... > Dear folks, > > I am a Cypress user and have had the trouble of laying out a board using 134 > of what I thought were 136 available I/O lines going into the device. Eight > of these lines were global control or global clocks. I had thought that I > could use all of them but the Warp 6.2 only lets me use 128 I/Os. What > gives? Is there a special declaration I should be using for the global pins? > Do I only get 128 I/Os even though there are 136 I/O pins? > > Thanks, > > Brad > > P.S Details of my discussion with Cypress below: > > Created at: 06/20/03 03:45 PM > > Part Number: Delta 39K > Product: Programmable Logic > Programmable Logic Devices > Subject: Error with Max IO > Description: I am running Warp6.2 for a 39k100 and get error EMP043 > Resource Limit Maximum Number of IO Cells Exceeded (max=128, needed 134) > although I believe this chip should have enough IO. > > Brad > > Attachments: > > Interactions > > Cypress Response 07/15/03 08:03 AM | Web > Hi Brad, > > I hope we have fully addressed your inquiry. I am closing this case for now, > if you require further assistance on this issue please re-open this case > (using the radio button for Status, Open, and clicking Submit) and we will > be glad to assist you. For all other inquiries please open a new case. > > > Thank you for using Cypress products, > > Cypress Applications Support > > > Cypress Response | 07/10/03 02:51 PM | Web > Hi Brad, > > The global clock and control signal pins are declared as inputs (for OE) > Warp will route these signals as in the 11c signal in your design. > > > Cypress Applications Support > > > Customer Comment Brad Smallridge | 07/10/03 11:33 AM | Web > Are there some sort of other pin type assignemnts similar to in, out, or > inout that should be used with the global clock and global control pins? > > Cypress Response | 07/07/03 09:33 AM | Web > Hi Brad, > > Sorry for all the confusion. > > In reference to your response: > > The data sheets state that I have 136 IOs available. Is there some sort of > internal architecture that limits me to 128 IOs? What pins may I or may I > not use? > > Page 2 of the datasheet states that of the 208 packages. " Device Package > Offering and I/O Count Including Dedicated Clock and Control Inputs", is > 136. > > Pages 50 thru 56 of the datasheet explain the pins and their functions for > the CY39100V208-200NTC package. If you count the number of pins that can > function as I/O's there are 128. Depending how you configure the I/O's this > number decreases. > > Please see application note: Delta39K and Quantum38K I/O Standards and > Configurations > > I/O Standards and Configurations > > > Thank you for your patience > > > Cypress Applications Support > > > > > Customer Comment Brad Smallridge | 07/03/03 12:48 PM | Web > This reply seems non-responsive. The data sheets state that I have 136 IOs > available. Is there some sort of internal architecture that limits me to 128 > IOs? What pins may I or may I not use? I think I need a better answer since > I have already committed to, and spent money on, a hardware design. > > > Cypress Response | 07/02/03 01:51 PM | Web > Hi Brad, > > The pin attributes in your design are fine. Whether or not the design can be > fitted to the device depends on the rest of your design which you have > commented out. There are too many floating signals to determine if this > design as coded can be compiled to fit the device. > > From what I have been able to determine, you will probably not have enough > I/O's to support your design. > > > Thank you for your patience > > > Cypress Applications Support > > > Customer Comment Brad Smallridge | 07/02/03 09:24 AM | Web > I am not using VCCIO for signals. Perhaps you can look at my VHD pin list > and tell me what pins I can not use? > > Cypress Response | 06/30/03 09:09 AM | Web > Hi Brad, > > I did try to contact you, I left a msg on your voice-mail. > > I hope we have fully addressed your inquiry. I am closing this case for now, > if you require further assistance on this issue please re-open this case > (using the radio button for Status, Open, and clicking Submit) and we will > be glad to assist you. For all other inquiries please open a new case. > > > Thank you for using Cypress products, > > Cypress Applications Support > > > Cypress Response | 06/27/03 03:20 PM | Web > Hi Brad, > > Thank you for using the Cypress On-Line ConnectionCenterT. In reference to: > > > Error EMP043 Resource Limit Maximum Number of IO Cells Exceeded (max=128, > needed 134) although I believe this chip should have enough IO. > > Ans: The available number of I/O's for this device is 128, the additional 8 > I/O's (VCCIO) are for power to the I/O banks and not for signals. > > > Note: > > If you limit your design to the use of 128 I/O's it will compile > > > > Thank you for your patience > > Cypress Applications Support > > > Customer Comment Brad Smallridge | 06/27/03 12:03 AM | Web > 1) CY39100V208B-200NTC > 2) no other errors > > VHD file is attached > test08.vhd > > > Cypress Response | 06/23/03 10:27 AM | Web > Hi Brad, > > We are presently looking into your case and will respond as soon as > possible. I want to clarify your issue, "Error with Max IO": > > 1) What is the entire part description of the device that you are targeting? > > 2) Are their any other errors being generated by the compiler? > > > Please include your design files that we may further investigate this issue. > > > Thank you for your patience > > Cypress Applications Support Brad, Using the Cypress data, sheet I count 128 IO pins, 4 global clock pins and 4 global control pins. This does add up to 136 "IO" pins. However, the global clock pins can be used only for clock signals and, according to the data sheet, "There are four dedicated inputs (GCTI[3:0]) that are used as Global Control Signals available to every IO cell. These global control signals may be used as output enables, register resets, and register clock enables as shown in figure 8." So the global control signals are dedicated inputs and the global clocks can be used only for clocks. This should explain why you are not able to use 136 pins for general purpose IO. Best regards, CharlesArticle: 58167
Hi mates Could any body tell me how to edit and see the encrypted NGC file produced by using XILINX ISE 5 version. Cheers Rgds ISAACArticle: 58168
Robert McGee wrote: > tlbwe among other tlb instructions are treated as an illegal instructions > when the PPC405's TIEc405MmuEn signal is set to 0. I bet this is the case in > your design. Yes it was so thanks very much indeed! To quote me yesterday ``it's almost like it's not there''... :-). After setting the line to net_vcc it still did not work and we discovered that the MHS file had to be hand altered as the diagram had somehow become out of sync - not the first time that has happened with the EDK tools here. Jon.Article: 58169
Does anyone know where I can get the pinouts needed for the Xilinx PCI core. I think that I can get away with a simple slave only interface (which I can write myself) but I don't want any surprises if I ultimately need the Xilinx core for mastering. Thanks in advance RobArticle: 58170
thx very much, antti !!!!! > 1) I use Verilog (VHDL gives error in v2pdk_lib_utils or somewhere..) i also encounter the VHDL problem too bad, i'm not familiar with Verilog!! btw, how's ur progress with EDK ? any good news for its support with Linux ? tk "Antti Lukats" <antti@case2000.com> wrote in message news:80a3aea5.0307160149.209fdbf3@posting.google.com... > "tk" <tokwok@hotmail.com> wrote in message news:<bf1124$60r$1@hkueee5.eee.hku.hk>... > > Hi all, > > > > When I try to follow the steps to make a bitstream of ML300 Embbedded > > reference system in Virtex-II Pro Development Kit, I get the following > > error during Mapping: > > > > ERROR:Pack:18 - The design is too large for the given device and package. > > Please check the Design Summary section to see which resource requirement > > for your design exceeds the resources available in the device. > .. > > I would like to ask how could I solve the *OVERMAPPED* problem? > > There is pre-built bitstream file in the reference design. How come I > > can't create one myself ?! > > welcome abroad!!! > > this what you just discovered is driving me crazy too - because > almost nothing fits into VP7 if you try to use XST synthesis !!! > > Xilinx reply was: V2PDK reference designs are all targeted for Synplify. > > I am trying to use XST what works only if > 1) I use Verilog (VHDL gives error in v2pdk_lib_utils or somewhere..) > 2) when I disable almost all peripherals (to be able to fit) > > Synplify probably removes the non-related logic better tha XST that all. > > And thats all thing you done know (until you buy ML300) > > anttiArticle: 58171
Hi Guys Many thanks for all the input. Its given me loads to mull over. Ill do some more work and get back to you all. Regards and thanks Denis Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3F12DC74.7030606@flukenetworks.com>... > Denis Gleeson wrote: > > > I realise that normally to obtain a given timing relationship one would > > use synchronous logic. But in this case as I require signals with the > > same frequency as the main clock I must use combinational logic. > > > > From the output of my logic simulator I am seeing some issues which > > confuse me: > > > > (a) Different logic gates have different delays, A NOT has less delay than > > an OR gate. May be this should have been obvious to me. Is it correct? > > > > (b) If I add a gate to create a delay, it seems to be getting optimised out. > > Is there some way to stop a gate added for this purpose from being removed? > > > Consider using an FPGA with an on-chip PLL. > With a 4x internal clock you might be able > to use the synchonous template for your > design and eliminate those issues. > > -- Mike TreselerArticle: 58172
Antti Lukats wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F140004.C45EBEAA@yahoo.com>... > > Antti Lukats wrote: > > > > > > Hello, > > > > > > I have read the docs, but still unclear if the JTAG boundary scan could > > > be used during configuration, i.e. > > > > > > 1) small microcontroller connected to JTAG and selectmap pins > > > 2) Xilinx Spartan II/Virtex > > > 3) Parallel flash connected to FPGA > > > > > > microcontroller used Boundary scan to fetch from Flash > > > then writes the configuration using selectmap > > > > > > as per xilinx docu this doesnt sound like not possible but I wonder > > > if anyones has experience with that, or knows for sure if this > > > approuch could work or not > > > > > > I think using boundary scan during JTAG configuration is not allowed > > > but during selectmap? > > > > > > antti > > > > None of this sounds hard to me. The step of reading the Flash by > > driving the JTAG pins seems a bit complex and will be very slow, but it > > should work. But where are you going to store the configuration data > > while in the JTAG Flash read mode? It will be much more expensive to > > have that much RAM available. It would be better to hang the Flash off > > the MCU rather than on the FPGA. Then you can program each byte as you > > read it and don't need all that RAM storage. > > > > I have recently taken a look at NAND flash and it does not need the > > large number of address lines and is much cheaper than NOR Flash. You > > only need about 12 or 14 signals to connect to it and control it through > > the 8 bit data port. It is easy to do this through a pair of 8 bit > > ports on an MCU. > > > > thats the point I start selectmap configuration, > then fetch byte from flash and write to fgpa > then fetch another and so on > > I only need 1 word buffer in the micro I don't know that you can fetch bytes from the Flash using the JTAG while programming the device with selectmap. I expect you will not be able to make this work. > the flash will later on be used as instruction memory for Microblaze > I could add a small PLD to the flash address pins (for config), but that takes > more board space Xilinx used to have a parallel master mode which would configure the FPGA from an addressable Flash like this. But I think your plan will not work with the newer devices. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 58173
The '297 is a good starting point. The loop I described above was also for a
pixel clock on a photo printer. The '297 circuit was not good enough in the
application I was dealing with.
--
--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: 58174rickman <spamgoeshere4@yahoo.com> wrote: > There are a lot of issues concerning co-compatibility. I have seen > older software that won't run under the newer OS and the newer software > is not supported under the older OS. Do you have specific examples? I haven't been using any Xilinx version earlier than 3.x, but 3.x and later all run fine on Win2K. > Even those issues aside, it is hard to maintain proficiency on the older > tools since they change the GUI and even the synthesis tool every few > years. This can make it very hard to maintain an older design since > under a newer tool a design can get much larger. But if you try to run To Xilinx's credit the command line interface has changed very little; I can't think of any incompatible changes at all since 3.x, possibly earlier. In all honesty I've never run the 5.x GUI. You can also install multiple versions of Synplify pretty easily. Lately each major version installs into its own directory automatically (7.2.3 still overwrites 7.2.2 but you can easily work around that). We have machines with 6 or more different versions installed :-| hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
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