Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 58150

Article: 58150
Subject: JTAG and Xilinx
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 16 Jul 2003 12:15:38 +1000
Links: << >>  << T >>  << A >>
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,

John


Article: 58151
Subject: Re: JTAG and Xilinx
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 16 Jul 2003 12:23:11 +1000
Links: << >>  << T >>  << A >>

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,

John


Article: 58152
Subject: Re: Combinational logic and gate delays - Help
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 16 Jul 2003 02:31:26 -0000
Links: << >>  << T >>  << A >>
>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
Subject: Re: JTAG standard connector
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 16 Jul 2003 02:38:51 -0000
Links: << >>  << T >>  << A >>
>    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
Subject: Re: Graduation Day: My first 4-layer PCB
From: "t hicks" <hicksthe@egr.msu.edu>
Date: Tue, 15 Jul 2003 22:44:29 -0400
Links: << >>  << T >>  << A >>
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: 58155
Subject: Re: Looking for DIMM format FPGA board
From: "John Pham" <jpsc@hotmail.com>
Date: Wed, 16 Jul 2003 03:02:39 GMT
Links: << >>  << T >>  << A >>
If 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.com




Article: 58156
Subject: Re: Graduation Day: My first 4-layer PCB
From: John_H <johnhandwork@mail.com>
Date: Wed, 16 Jul 2003 04:21:37 GMT
Links: << >>  << T >>  << A >>
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: 58157
Subject: Re: PROM size for spartan
From: "Neeraj Varma" <neeraj@cg-coreel.com>
Date: Wed, 16 Jul 2003 10:06:00 +0530
Links: << >>  << T >>  << A >>
Hi 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
Subject: Re: programming a PLD/CPLD with a PIC?
From: javodv@yahoo.es (javid)
Date: 15 Jul 2003 22:18:54 -0700
Links: << >>  << T >>  << A >>
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
> Fliptronics

Article: 58159
Subject: Xilinx XST - how to create an EDIF?
From: email_address@message.end
Date: Wed, 16 Jul 2003 06:10:14 GMT
Links: << >>  << T >>  << A >>
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- com


Article: 58160
Subject: Re: JTAG and Xilinx
From: "Kasper Pedersen" <ngfilter@kasperkp.dk>
Date: Wed, 16 Jul 2003 08:26:26 +0200
Links: << >>  << T >>  << A >>

"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
Subject: Re: edge card connectors and high speed design
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 16 Jul 2003 08:47:44 -0000
Links: << >>  << T >>  << A >>
>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
Subject: Re: what are libraries for??
From: thomas@stanka-web.de (Thomas Stanka)
Date: 16 Jul 2003 01:49:11 -0700
Links: << >>  << T >>  << A >>
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 Thomas

Article: 58163
Subject: Re: JTAG Boundary scan during configuration
From: antti@case2000.com (Antti Lukats)
Date: 16 Jul 2003 02:18:05 -0700
Links: << >>  << T >>  << A >>
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

antti

Article: 58164
Subject: Re: "ML300 Embedded" Mapping Help
From: antti@case2000.com (Antti Lukats)
Date: 16 Jul 2003 02:49:00 -0700
Links: << >>  << T >>  << A >>
"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)

antti

Article: 58165
Subject: Re: Graduation Day: My first 4-layer PCB
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 16 Jul 2003 10:05:34 -0000
Links: << >>  << T >>  << A >>
>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
Subject: Re: I/Os with Cypress chip
From: charles.elias@wpafb.af.mil (Charles M. Elias)
Date: 16 Jul 2003 04:10:49 -0700
Links: << >>  << T >>  << A >>
"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,

Charles

Article: 58167
Subject: How to edit encrypted NGC file produced using XILINX ISE 5
From: fpga_uk@yahoo.co.uk (Isaac)
Date: 16 Jul 2003 05:01:53 -0700
Links: << >>  << T >>  << A >>
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

ISAAC

Article: 58168
Subject: Re: Virtex II Pro Exceptions
From: Jon Masters <jonathan@jonmasters.org>
Date: Wed, 16 Jul 2003 13:10:54 +0100
Links: << >>  << T >>  << A >>
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
Subject: vertex2 pci pinout
From: rjd@transtech-dsp.com (rob d)
Date: 16 Jul 2003 05:50:20 -0700
Links: << >>  << T >>  << A >>
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

Rob

Article: 58170
Subject: Re: "ML300 Embedded" Mapping Help
From: "tk" <tokwok@hotmail.com>
Date: Wed, 16 Jul 2003 21:10:40 +0800
Links: << >>  << T >>  << A >>
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)
>
> antti



Article: 58171
Subject: Re: Combinational logic and gate delays - Help
From: dgleeson-2@utvinternet.com (Denis Gleeson)
Date: 16 Jul 2003 06:49:03 -0700
Links: << >>  << T >>  << A >>
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 Treseler

Article: 58172
Subject: Re: JTAG Boundary scan during configuration
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 16 Jul 2003 10:00:07 -0400
Links: << >>  << T >>  << A >>
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 FAX

Article: 58173
Subject: Re: An All Digital Phase Lock Loop
From: Ray Andraka <ray@andraka.com>
Date: Wed, 16 Jul 2003 10:09:13 -0400
Links: << >>  << T >>  << A >>
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: 58174
Subject: Re: Xilinx ISE drops support for more parts
From: hamish@cloud.net.au
Date: 16 Jul 2003 14:33:29 GMT
Links: << >>  << T >>  << A >>
rickman <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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search