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
2019JanFebMar2019

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 63025

Article: 63025
Subject: Re: Frequency Doubler - VHDL/Verilog
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 12 Nov 2003 13:55:30 -0800
Links: << >>  << T >>  << A >>
Hal,
I like your line or thought, and I have been thinking along the same
lines, without good results.
Maybe this community can come up with a simple solution:
Use a few external components to adjust the duty cycle, and perhaps also
the alternate period problem.
For simplicity: accept a relatively low frequency ( <40 MHz).
Any takers out there?  
I can promise publication, fame and glory...
Peter Alfke
==============================
Hal Murray wrote:
> 
> >If you don't care about the 2f duty cycle, and are also  willing to live
> >with the affect of uncontrolled incoming duty cycle at f, causing
> >alternating period length at 2f, then you can use the circuit described
> >in TechXclusives "Six Easy Pieces".
> 
> Assuming the clock is always running and at least in the ballpark of
> 50-50 duty cycle...
> 
> Can I fixup the duty cycle with a cap, inverter, and big
> feedback/bias resistor?
> 
> If I'm willing to go off-chip and back in, will that work for the
> 2F clock?
> 
> [Yes, DLLs/PLLs are good.]
> 
> --
> 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: 63026
Subject: Re: System generator and Microblaze
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 13 Nov 2003 08:21:37 +1000
Links: << >>  << T >>  << A >>
Hi Si,

Si wrote:
> I am fairly new to Xilinx!
> I am looking to implement a System generator (SG) design with a
> Microblaze IP! How would one do this as I am a wear Xilinx does not
> provide intrinsic support for the PPC405 (V-II Pro) or Microblaze in
> SG?

try XAPP264 - Building OPB Slave Peripherals using System Generator

Regards,

John


Article: 63027
Subject: Re: 0.13u device with 5V I/O
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Wed, 12 Nov 2003 15:44:18 -0800
Links: << >>  << T >>  << A >>

Hi,

> Do you have any suggested parts for the level translators?

Unfortunately, I do not.  I've been dealing with bus switches
because they are bidirectional, which is important for the
application I'm dealing with.  There are a number of vendors.

> I don't really care about the rules just to check off the
> boxes.  I'm willing to cheat if I can convince myself (and
> some friends?) that the total system will work solidly.

There are many people in this same situation!

> There are two parts to that.  One is in limited cases, say
> one fewer card on the bus.  The other is in any configuration
> legal under the specs.

We've been looking at the general case, because it is hard
for us to control an end user's bus...
 
> How far did you bend the rules?  How much testing/Spicing did
> you do?

The Xilinx XAPP646, XAPP653, and XAPP659 application notes are
a good overview of a solutions Xilinx is recommending.  These
were developed by the Xilinx applications team.  I have not done
any spice simulations, but I have tested these suggestions in
hardware at the PCI Compliance Workshops and have not had any
issues.

If you are using these bus switches for 5V PCI, the only 5V PCI
bus is a 33 MHz, 5V bus.  Everything else is 3.3V.  In a 33 MHz,
5V bus, our I/O timing has so much slack that the impact of these
switches is next to nothing.  It is, however NON-COMPLIANT.

A possible area of concern is in cases where you are also
trying to support other modes, like a Universal 133 MHz PCI-X
card.  When such a card is in a 33 MHz, 5V slot, the impact
is again next to nothing...

However, when you put such a design in a 133 MHz PCI-X slot,
you don't have as much slack...  I have heard a number of
people comment on this at the PCI Compliance workshops when
they saw what I was testing.  I've tested several PCI-X 133
MHz designs using bus switches and have not had any failures.

I have also seen (but not personally tested) customers doing
5V designs using bus switches with VirtexE and Spartan-IIE.

> Do modern FPGAs have a low enough pin capacitance so that the
> added capacitance of something like a QuickSwitch fits the old
> rules?  Or are they fast enough to go through an honest repeater
> type chip so there is only one bus load?

They are fairly low delay.
 
> Mostly, I'm just curious.  If/when I get enough time, I'd like
> to build a hobby priced board that I can plug into something like
> PCI.  For now, that's old 33 MHz 5V PCI.  Spartan-II seems like
> the best bet.  But the clocking in newer chips is attractive.
> If there is a solid way to connect them to old PCI, I'd add that
> to my list of chips to consider.

I have photoplots for a board that uses the original Virtex at
http://www.engr.sjsu.edu/crabill/projects but if you are looking
at 33 MHz, 5V as your primary mode of operation, I would think
using something newer with bus switches might be more attractive.

Eric

Article: 63028
Subject: Re: Layout examples
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 13 Nov 2003 01:30:04 GMT
Links: << >>  << T >>  << A >>
"Martin Thompson" wrote:

> If you have solid planes (prefereably closely spaced) you don't need
> to worry about 'close' in the sense that you probably think of as
> close.  If you have vias to the planes on *very* short tracks, or even
> better in the pad, then the planes will act as a very low impedance
> route for your currents.  If you think of the time the energy will
> take to travel from capacitor to chip, the speed of light on FR4 is
> around 2/3c or 2e8 m/s.  In 1ns, this is around 20cm.  Halve this for
> the energy to get back and forth and even 10cm is "close".
>
> I don't have any pictures to hand, but we've done boards like this
> with 100MHz memory interfaces and 150MHz core DSP clocks that work fine.


I'll have to disagree with some of this (not meant as criticism, just a
point for discussion).

The number I use (and see in most books) for propagation in FR4 boards is
140 to
180ps/in for outer traces and about 180ps/in for inner.  That would mean
about 1.4ns/20cm.  Operating at 100MHz with, say, 1ns edges, means that a
cap 10cm away would not be able to deliver significant current for the first
0.7ns of
the edge, which pretty much hoses you.  This is under ideal conditions,
ignoring capacitor frequency-dependant characteristics; mounting-related
inductance; trace/plane inductance; board/pin interface issues, etc.

Because of this and more, I think that 10 to 20cm is far from close (that
sounds funny) for high speed design.  The characteristics of the caps and
the mounting/routing methodology can make this a serious issue.  There are
interesting threads and authorithative information about this very subject
on the signal integrity list.


For my last design truly labored over this and took the approach of writing
a custom power
distribution system simulation tool in order to get a handle on what was
going on.  Things get serious once you stare down at the prospect of
hundreds of pins switching simultaneusly at a given edge rate.  And that's
what's important, the edge rates, not the frequency.  The thinking can be
abstracted to using a bunch of caps (the decoupler array) to charge another
set of caps (the output traces) through the board-to-chip-to-board
interface.

If you start looking at the behavior of capacitors as a function of
frequency (and, in isolation of board layout/mounting effects) you'll see
that the C and L induced self-resonant behavior can play interesting tricks
with what a cap can really do.  Of course ESR and ESL are frequency
depandant themselves, although it is nearly impossible to get this data from
manufacturers.

Beyond that, I find that the field turns "religious" real fast.  There are
three basic approaches:

1- Do it the way we've been doing it 'cause it seems to work
2- Use a range of caps to cover the frequency (ehem, edge) range
3- Use only two or three a couple of values to cover the range
4- If it looks good during layout it should work.

#1 is folklore and may only have merit if a knowledgeable engineer setup
rules conservative rules that can be followed by those working on new
designs independently.  I find that many think that the old 0.1uF capacitor
rules could be adequate for high-speed design when, in reality they are just
about useless.  The same applies to a certain range of tantalums.  So, for
my money, option #1 is not a great solution unless you know where it came
from, how it got there and what the constraints might be.

#2 is promoted by one school of thought within the SI community.  It is
perfectly valid, of course.  However, I don't see it as manufacturing/BOM
friendly.  The idea of stuffing a board with a dozen different decoupling
capacitor values is not something I look forward to from many perspectives.
The theory here is that, by being intelligent about the choice of caps,
their mounting and routing, you create a very low impedance "bucket" to
cover the edge rates for the design.  Like I said, valid, but not my cup of
tea.

#3 is also supported by a sect within the SI community and happens to be
what I chose to do.  The idea here, loosely speaking, is to form the
aforementioned "bucket" with just a few values.  The value of the capacitor
is not as important as the frequency domain characteristics of the same.
This is part of the problem today.  Cap manufacturers are begining to be
pushed by SI experts to address high-speed decoupling needs and produce (and
quantify) caps that are friendlier to this approach.

By dividing the spectrum in to low, mid, mid-high and high frequency (edge
rate) zones you can select four capacitors (again, not so much values as
much as frequency related characteristics) to cover the range.  A typical
setup will have electrolytics by the power source (LF), medium-packaged
tantalums within 5 to 10 cm of relevant chips (MF to HF) and a couple of
small-package chip cap flavors within about 2cm of high-speed chips (HF).
The significance of speaking in terms of packages as opposed to values is
that the package type becomes the primary factor in such properties as ESL
(which is the dominant element as frequencies rise).  Small tantalums, for
example, like 4.7 to 10uF are absolutely worthless for high-speed decoupling
designs.  You have to get into the larger packages in order to get decent
ESR and ESL characteristics.

What attracted me to #3, aside from the obvious BOM-friendly results, was
the fact that you can engineer a much smoother impedance "bucket".  Option
#2 requires very careful design, modeling and simulation to ensure that you
are not creating a real problem or it can produce weird peaky resonant
behavior .  I wasn't equipped nor inclined to do that and #3 made more sense
overall.  What's missing in the decoupling cap world are caps with low ESL
and not so low ESR (or quantifiable ESR).  If you run the curves, you want
some ESR to mitigate peaky resonance effects.

Finally, #4, is included in my list because it was something a
"professional" PCB designer told me when I was considering using his
company's services.  The way this person did high-speed layouts was to "make
it look good and it will work fine".  I would imagine there's a lot of that
going on out there.  I can only wonder and cringe.


To address the OP's questin directly.  There are good guidelines out there
on what is required and many options on how to do it.  Every layout will be
different due to things like the which and how many pins you use.  You need
to get a set of high-speed decouplers very close to the FPGA, within a 2cm
circle, I'd say.  Modern 0402 components allow you to place a good number of
these within the device's footprint.  Fan out from there with mid to low
frequency caps to support charge transfer and avoid starving he HF caps.
Again, quantity and type depend on your design and edge rates.  There are
good books out there that cover the basics.  One such books is "High Speed
Digital Design, a Handbook of Black Magic" by Howard Johnson.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"













Article: 63029
Subject: Re: Transforming vector position to binary value
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 13 Nov 2003 05:34:14 GMT
Links: << >>  << T >>  << A >>
What's the clock frequency for this design?
At what rate are the 32 bit words generated?

Can you take 32 clocks to produce the desired results?
If not, if the frequency of operation is low enough, you could multiply it
by 32 and get your results within a clock or two.

If none of the above works, you could probably pipeline a solution.  During
each stage a prioritized decoder would pick off the first "1" and give you a
result.  At the same time, that "1" would be masked off so that it won't
appear in the next stage.  Repeat four times and you have your solution.  It
will probably take four to eight clocks depending on details (don't have my
thinking cap fully on).


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 63030
Subject: Re: Layout examples
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 13 Nov 2003 09:08:15 +0000
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> writes:

> "Martin Thompson" wrote:
> 
> > If you have solid planes (prefereably closely spaced) you don't need
> >to worry about 'close' in the sense that you probably think of as
> >close.  If you have vias to the planes on *very* short tracks, or even
> >better in the pad, then the planes will act as a very low impedance
> >route for your currents.  If you think of the time the energy will
> >take to travel from capacitor to chip, the speed of light on FR4 is
> >around 2/3c or 2e8 m/s.  In 1ns, this is around 20cm.  Halve this for
> >the energy to get back and forth and even 10cm is "close".
> >
> > I don't have any pictures to hand, but we've done boards like this
> >with 100MHz memory interfaces and 150MHz core DSP clocks that work
> >fine.
> 
> 
> I'll have to disagree with some of this (not meant as criticism, just
> a point for discussion).
> 

Fair enough :-)

> The number I use (and see in most books) for propagation in FR4 boards
> is 140 to 180ps/in for outer traces and about 180ps/in for inner.

180ps/in makes out to be 
180/25.4 ps/mm ~ 7ps/mm (1.4e8 m/s)

> That would mean about 1.4ns/20cm.  

Indeed it would, I think I must have dropped a factor of 10 somewhere,
sorry about that!  I did the sums properly when I designed the board,
honest :-)

> Operating at 100MHz with, say, 1ns
> edges, means that a cap 10cm away would not be able to deliver
> significant current for the first 0.7ns of the edge, which pretty much
> hoses you.  This is under ideal conditions, ignoring capacitor
> frequency-dependant characteristics; mounting-related inductance;
> trace/plane inductance; board/pin interface issues, etc.
> 
> Because of this and more, I think that 10 to 20cm is far from close
> (that sounds funny) for high speed design.  The characteristics of the
> caps and the mounting/routing methodology can make this a serious
> issue.  There are interesting threads and authorithative information
> about this very subject on the signal integrity list.
> 

Indeed - that's where I learned a lot of this information from... 

How about we say that 1-2cm is close enough (for the HF decouplers?)

> 
> For my last design truly labored over this and took the approach of
> writing a custom power distribution system simulation tool in order to
> get a handle on what was going on.  Things get serious once you stare
> down at the prospect of hundreds of pins switching simultaneusly at a
> given edge rate.  And that's what's important, the edge rates, not the
> frequency.  The thinking can be abstracted to using a bunch of caps
> (the decoupler array) to charge another set of caps (the output
> traces) through the board-to-chip-to-board interface.
> 

Agreed - I did much the same thing here.

> If you start looking at the behavior of capacitors as a function of
> frequency (and, in isolation of board layout/mounting effects) you'll
> see that the C and L induced self-resonant behavior can play
> interesting tricks with what a cap can really do.  Of course ESR and
> ESL are frequency depandant themselves, although it is nearly
> impossible to get this data from manufacturers.
> 

It's getting better, but there wasn't much useful data when I did this
either.  I ended up distributing lots of different values of capacitor
to get a flat impedance profile - which doesn;t half make your BOM
long. And makes population a trial.  I'm not sure if I'd do this again
unless absolutely necessary!

> Beyond that, I find that the field turns "religious" real fast.  There
> are three basic approaches:
> 
> 1- Do it the way we've been doing it 'cause it seems to work 2- Use a
> range of caps to cover the frequency (ehem, edge) range 3- Use only
> two or three a couple of values to cover the range 4- If it looks good
> during layout it should work.
> 
> #1 is folklore and may only have merit if a knowledgeable engineer
> setup rules conservative rules that can be followed by those working
> on new designs independently.  I find that many think that the old
> 0.1uF capacitor rules could be adequate for high-speed design when, in
> reality they are just about useless.  The same applies to a certain
> range of tantalums.  So, for my money, option #1 is not a great
> solution unless you know where it came from, how it got there and what
> the constraints might be.
> 

Agreed - the words "conservative rules" are appropriate... even for
low-speed designs (are there any of those any more?) you may be
spending too much on your caps.

> #2 is promoted by one school of thought within the SI community.  It
> is perfectly valid, of course.  However, I don't see it as
> manufacturing/BOM friendly.  The idea of stuffing a board with a dozen
> different decoupling capacitor values is not something I look forward
> to from many perspectives.  The theory here is that, by being
> intelligent about the choice of caps, their mounting and routing, you
> create a very low impedance "bucket" to cover the edge rates for the
> design.  Like I said, valid, but not my cup of tea.
> 

Right, should have read on before scribbling my earlier paragraph :-)

> #3 is also supported by a sect within the SI community and happens to
> be what I chose to do.  The idea here, loosely speaking, is to form
> the aforementioned "bucket" with just a few values.  The value of the
> capacitor is not as important as the frequency domain characteristics
> of the same.  This is part of the problem today.  Cap manufacturers
> are begining to be pushed by SI experts to address high-speed
> decoupling needs and produce (and quantify) caps that are friendlier
> to this approach.
> 
> By dividing the spectrum in to low, mid, mid-high and high frequency
> (edge rate) zones you can select four capacitors (again, not so much
> values as much as frequency related characteristics) to cover the
> range.  A typical setup will have electrolytics by the power source
> (LF), medium-packaged tantalums within 5 to 10 cm of relevant chips
> (MF to HF) and a couple of small-package chip cap flavors within about
> 2cm of high-speed chips (HF).  The significance of speaking in terms
> of packages as opposed to values is that the package type becomes the
> primary factor in such properties as ESL (which is the dominant
> element as frequencies rise).  Small tantalums, for example, like 4.7
> to 10uF are absolutely worthless for high-speed decoupling designs.
> You have to get into the larger packages in order to get decent ESR
> and ESL characteristics.
> 

I would add that the inductance is affected quite strongly by mounting
method (number of vias and the inductance of the copper connecting
them to the pads) and by the spreading inductance of the planes.  Did
you take advantage of thin dielectrics for extra high-quality
capacitance?  We put two 3.3V/GND 4thou separation pairs in the board,
which got us a few nF of very low inductance capacitance, which comes
in handy at the top end.

I came to the conclusion that above 100-150MHz you couldn't do a lot
with capacitors anyway.

> What attracted me to #3, aside from the obvious BOM-friendly results,
> was the fact that you can engineer a much smoother impedance "bucket".
> Option #2 requires very careful design, modeling and simulation to
> ensure that you are not creating a real problem or it can produce
> weird peaky resonant behavior .  I wasn't equipped nor inclined to do
> that and #3 made more sense overall.  What's missing in the decoupling
> cap world are caps with low ESL and not so low ESR (or quantifiable
> ESR).  If you run the curves, you want some ESR to mitigate peaky
> resonance effects.
> 

You could always fit some small resistors in series :-)

Looks like we came to the same conclusions in the end then!

> Finally, #4, is included in my list because it was something a
> "professional" PCB designer told me when I was considering using his
> company's services.  The way this person did high-speed layouts was to
> "make it look good and it will work fine".  I would imagine there's a
> lot of that going on out there.  I can only wonder and cringe.
> 

Frightening.  Unless their idea of aesthetically pleasing happens to
be trained by what will work ....

> 
> To address the OP's questin directly.  There are good guidelines out
> there on what is required and many options on how to do it.  Every
> layout will be different due to things like the which and how many
> pins you use.  You need to get a set of high-speed decouplers very
> close to the FPGA, within a 2cm circle, I'd say.  

And I'd agree now my 10s are in the right place :-)

> Modern 0402
> components allow you to place a good number of these within the
> device's footprint.  Fan out from there with mid to low frequency caps
> to support charge transfer and avoid starving he HF caps.  Again,
> quantity and type depend on your design and edge rates.  There are
> good books out there that cover the basics.  One such books is "High
> Speed Digital Design, a Handbook of Black Magic" by Howard Johnson.
> 

I can recommend that book also, along with subsribing to the si-list
(http://www.freelists.org/webpage/si-list)

Apologies again for my arithmetic!

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 63031
Subject: linker script
From: Tom <t_t_1232000@yahoo.com>
Date: Thu, 13 Nov 2003 11:15:22 +0100
Links: << >>  << T >>  << A >>
Hi, 

when using linker scripts, how can you check if the various sections
actually fit into the specified memory regions ?

Thanks,

Tom

Article: 63032
Subject: SystemC Implementation
From: luckylukedalton@yahoo.com (Holger)
Date: 13 Nov 2003 02:53:21 -0800
Links: << >>  << T >>  << A >>
Hi people, can anybody help me?
I want to implement a clock process in a modul to generate a
independent  testbench. My gain is to translate the systemc-code to
vhdl and simulate the projekt in vhdl. It is possible to implement
sc_clock outside sc_main(), but i can not use the parameters for
example sc_clock clk("Clk",20 ,0.5,2,true).

Have anybody a similar problem and have you found a solution?

Thanks.

Article: 63033
(removed)


Article: 63034
Subject: Archiving Projects
From: "Jock" <ian.mcneil@nospam.com>
Date: Thu, 13 Nov 2003 11:22:41 -0000
Links: << >>  << T >>  << A >>
When using Xilinx ISE 4.1 to archive my project I get the following message:

************************
The zip process invoked as
zip -r -q [zip_path]\filename.zip
[netlist_path]
[project_path]
failed:
***********************

It doesn't give any reason why it's failed. Has anyone else seen this and
knows why?



Article: 63035
Subject: Reading O value
From: fpga_uk@yahoo.co.uk (Isaac)
Date: 13 Nov 2003 03:41:28 -0800
Links: << >>  << T >>  << A >>
Hi Champs 
Its Isaac after long time,,,,,,,,,,,,,,I am having problem reading out
values from SRAM in FPGA everytime I try to target SRAM I am getting
0. The code is given below . The  check node and variable node
component's function is not mentioned here.
Can any body pin point the problem....In state s6 I am reading out the
values from FPGA. State s2 and s3 are not defined.


P_IO_FFS : process(	
				CLK_2X, LOCKED
)
begin
	if RISING_EDGE(CLK_2X) then
		if LOCKED = '1' then
			-- Outputs
--			LED_V3 <= LED_V3_int;
			STAT_V3 <= STAT_V3_int;
			-- Inputs
			SR_ADDR_IO_int <= SR_ADDR_IO;
			SR_DATA_IO_int <= SR_DATA_IO;
			SR_IRD_int <= SR_IRD;
			SR_IWR_int <= SR_IWR;
			SR_IVCS_V3_int <= SR_IVCS_V3;

		end if;
	end if;
end process P_IO_FFS;

Process (CLK_2X,SR_ADDR_IO_int,SR_DATA_IO_int,SR_IWR_int,SR_IVCS_V3_int)
  begin 
   	if RISING_EDGE(CLK_2X) then
	 	if SR_IVCS_V3_int = '0' then  
			if SR_IWR_int = '0' then  
			 		SR_DATA_IO_int <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"; 	  
			 		state_signal <= '0';
					
				if SR_ADDR_IO_int = "000000" then	
						   channelbit1 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif  SR_ADDR_IO_int = "000001" then	
						   channelbit2 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "000010" then	
						   channelbit3 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "000011" then	
						   channelbit4 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int <= "000100" then	
						   channelbit5 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "000101" then	
						   channelbit6 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "000110" then	
						   channelbit7 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "000111" then	
						   channelbit8 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "001000" then	
						   channelbit9 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "001001" then	
						   channelbit10 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "001010" then	
						   channelbit11 <= SR_DATA_IO_int(2 downto 0) ; 	
				elsif SR_ADDR_IO_int = "001011" then	
					channelbit12 <= SR_DATA_IO_int(2 downto 0) ; 	
					state_signal <= '1';
				end if;	
				end if;
			end if;
		end if; 
end process ;

process3 : process (CLK_2X,state)
  begin 
if RISING_EDGE(CLK_2X) then	  
	case state is   
		when s1 => 
--		if RISING_EDGE(CLK_2X) then	  
			paritycheck <= '0';	 
		if state_signal = '1' then 
				k <= 0;
				state <= s4;
			end if;	
--		end if;
		when s4 =>						
--			if RISING_EDGE(CLK_2X) then
				k <= k + 1;		
				state <= s5; 	   	   
--			end if;		  
		  when s5 =>
--		  	if RISING_EDGE(CLK_2X) then
		  		if remainder = 0 then  
					k <= 0;
					state <= s6 ;
					paritycheck <= '1';	  
					eb_bits <= eb_hat_bits;  
				else
					state <= s4 ;
				    k<= k+1;
				end if ;				
--			end if;
		  when s6 =>
--		  		 if RISING_EDGE(CLK_2X) then
		  			if SR_IVCS_V3_int = '0' then  
		  				if SR_IRD_int = '0' then 
							if SR_ADDR_IO_int = "001100" then	
							   	SR_DATA_IO (11 downto 0)<= eb_bits; 
								SR_DATA_IO (31 downto 12) <= "00000000000000000000";   
								state <= s7; 
								
							end if;	
						else 
							Null;
						end if;
					else 
							Null;
					end if ;				
--				end if;
			when s7 =>
--				 if RISING_EDGE(CLK_2X) then
					if SR_IVCS_V3_int = '0' then  
		  				if SR_IWR_int = '0' then 
							if SR_ADDR_IO_int = "001101" then	
								state <= s1;
							else Null;end if;
						else Null; end if;
					  else Null;   end if;	
--				end if;
								
			when others =>
					Null;
	    end case; 			
	end if;
end process process3; 

-----------------------------------------------------------------------------------
--Parity Check Process
--	Process (clock)	
	Process (start,CLK_2X)
		begin 
				if CLK_2X'EVENT and CLK_2X = '1' then  
					if start = '1' then 				
							address <= address + "001";
							data  <= eb_hat_bits;
							a <= '0';
							kk <= '0';
--							t<= '0';
							s<= '0';
							q<= '0';
							
					elsif start = '0' then 				
						t<= '0';						
					end if;	
				if address = "001" then 
						kk<= '1';
				end if;	 
				if address = "010" then 
						a <= '1' ;
						address <= "ZZZ";
				end if ; 
				if a = '1' then 
						s <= '1'; 	 
				end if;	 
				if s = '1' then 
					t <= '1';
					address <= "000";
				end if;	 
				end if;
	end process	;
	

	Process (start,address)
		begin 

			if start = '1' then 
				case address is
					when "000" =>				  
						word1 <=  rom( conv_integer("000"));
						word2 <=  rom( conv_integer("001"));
						word3 <=  rom( conv_integer("010"));
						word4 <=  rom( conv_integer("011"));
						word5 <=  rom( conv_integer("100"));
						word6 <=  rom( conv_integer("101"));
					when others =>
						Null;
				end case;
			end if;
	end process	;  

 	
	Process (a)
	 	begin 
			if a = '1' then 
				adderrow1 <= add1 + add2+ add3 + add4 + add5 + add6+add7 + add8+
					add9 + add10+add11+add12;							
				adderrow2 <= adder1_2+adder2_2+adder3_2+adder4_2+adder5_2+adder6_2+
					adder7_2+adder8_2+adder9_2+adder10_2+adder11_2+adder12_2;
				adderrow3 <= adder1_3+adder2_3+adder3_3+adder4_3+adder5_3+adder6_3+
					adder7_3+adder8_3+adder9_3+adder10_3+adder11_3+adder12_3;
				adderrow4 <= adder1_4+adder2_4+adder3_4+adder4_4+adder5_4+adder6_4+
					adder7_4+adder8_4+adder9_4+adder10_4+adder11_4+adder12_4;
				adderrow5 <= adder1_5+adder2_5+adder3_5+adder4_5+adder5_5+adder6_5+
					adder7_5+adder8_5+adder9_5+adder10_5+adder11_5+adder12_5;
				adderrow6 <= adder1_6+adder2_6+adder3_6+adder4_6+adder5_6+adder6_6+
					adder7_6+adder8_6+adder9_6+adder10_6+adder11_6+adder12_6;
			else 
							Null;
			end if;	
	end Process	;

 Process (s)
		 begin
			 if s = '1' then 
--				 Addition <=  adderrow1 + adderrow2 + adderrow3 
--				 	+ adderrow4 + adderrow5 + adderrow6 ;
				 Remainder1 <= adderrow1 rem 2;
				 Remainder2 <= adderrow2 rem 2;
				 Remainder3 <= adderrow3 rem 2;
				 Remainder4 <= adderrow4 rem 2;
				 Remainder5 <= adderrow5 rem 2;
				 Remainder6 <= adderrow6 rem 2;
			 else 
							Null;
			 end if ; 
			
		end process	;
Process (t)
begin 
		if t = '1' then
		  remainder <= Remainder1 + Remainder2 + Remainder3 + Remainder4
+Remainder5 + Remainder6;
		elsif t = '0' then 
			remainder <= 1;
		end if ;
end process	;

state_machine : process	(k)
begin 
--if (CLK_2X'EVENT and CLK_2X = '1') then 
		case k is 
			when 1 =>
			--Initialization value at check nodes input coming from variable
node 1
					v2c1_1 <= channelbit1;
					v2c4_1 <= channelbit1;
					v2c6_1 <= channelbit1;
					received_1<= channelbit1; 
			--Initialization value at check nodes input coming from variable
node 2
					v2c2_2 <= channelbit2;
					v2c3_2 <= channelbit2;
					v2c4_2 <= channelbit2;
					received_2<= channelbit2; 
			--Initialization value at check nodes input coming from variable
node 3
					v2c1_3 <= channelbit3;
					v2c2_3 <= channelbit3;
					v2c4_3 <= channelbit3;
					received_3<= channelbit3;
			--Initialization value at check nodes input coming from variable
node 4
					v2c2_4 <= channelbit4;
					v2c3_4 <= channelbit4;
					v2c5_4 <= channelbit4;
					received_4<= channelbit4;
			--Initialization value at check nodes input coming from variable
node 5
					v2c2_5 <= channelbit5;
					v2c5_5 <= channelbit5;
					v2c6_5 <= channelbit5;
					received_5<= channelbit5;
			--Initialization value at check nodes input coming from variable
node 6
					v2c1_6 <= channelbit6;
					v2c3_6 <= channelbit6;
					v2c6_6 <= channelbit6;
					received_6<= channelbit6;
			--Initialization value at check nodes input coming from variable
node 7
					v2c1_7 <= channelbit7;
					v2c2_7 <= channelbit7;
					v2c5_7 <= channelbit7;
					received_7<= channelbit7;
			--Initialization value at check nodes input coming from variable
node 8
					v2c3_8 <= channelbit8;
					v2c4_8 <= channelbit8;
					v2c6_8 <= channelbit8;
					received_8<= channelbit8;
			--Initialization value at check nodes input coming from variable
node 9
					v2c1_9 <= channelbit9;
					v2c3_9 <= channelbit9;
					v2c4_9 <= channelbit9;
					received_9<= channelbit9;
			--Initialization value at check nodes input coming from variable
node 10
					v2c3_10 <= channelbit10;
					v2c5_10 <= channelbit10;
					v2c6_10 <= channelbit10;
					received_10<=channelbit10;
			--Initialization value at check nodes input coming from variable
node 11
					v2c4_11 <= channelbit11;
					v2c5_11 <= channelbit11;
					v2c6_11 <= channelbit11;
					received_11<= channelbit11;
			--Initialization value at check nodes input coming from variable
node 12
					v2c1_12 <= channelbit12; 
					v2c2_12 <= channelbit12;
					v2c5_12 <= channelbit12;
					received_12<= channelbit12;

when 7|13|19|25| =>			
			--Incoming messages  to check node 1
			-- Or outgoing messages from varaible nodes to check node 1
					v2c1_1 <= v2c11;
					v2c1_3 <= v2c31; 
					v2c1_6 <= v2c61;
					v2c1_7 <= v2c71;
					v2c1_9 <= v2c91;
					v2c1_12 <= v2c121;
			--Incoming messages  to check node 2
			-- Or outgoing messages from varaible nodes	to check node 2
					v2c2_2  <=	v2c22;
					v2c2_3  <=	v2c32;
					v2c2_4  <=	v2c42;
					v2c2_5  <=	v2c52;
					v2c2_7  <=	v2c72;
					v2c2_12 <=	v2c122;
			--Incoming messages to check node 3
			-- Or outgoing messages from varaible nodes	to check node 3
					v2c3_2  <=	v2c23;
					v2c3_4  <=	v2c43;
					v2c3_6  <=	v2c63;
					v2c3_8  <=	v2c83;
					v2c3_9  <=	v2c93;
					v2c3_10 <=	v2c103;
			--Incoming messages to check node 4
			-- Or outgoing messages from varaible nodes	to check node 4
					v2c4_1  <=	v2c14;
					v2c4_2  <=	v2c24;
					v2c4_3  <=	v2c34;
					v2c4_8  <=	v2c84;
					v2c4_9  <=	v2c94;
					v2c4_11 <=	v2c114;
			--Incoming messages check node 5
			-- Or outgoing messages from varaible nodes	to check node 5
					v2c5_4  <=	v2c45;
					v2c5_5  <=	v2c55;
					v2c5_7  <=	v2c75;
					v2c5_10  <=	v2c105;
					v2c5_11  <=	v2c115;
					v2c5_12 <=	v2c125;	
			--Incoming messages  to check node 6
			-- Or outgoing messages from varaible nodes	to check node 6
					v2c6_1  <=	v2c16;
					v2c6_5  <=	v2c56;
					v2c6_6  <=	v2c66;
					v2c6_8  <=	v2c86;
					v2c6_10  <=	v2c106;
					v2c6_11 <=	v2c116;
					start <= '0';	
						
when 2|8|14|20|26=>
			--Incoming messages to variable node 1
			-- Or outgoing messages from check nodes to variable node 1
					c2v11 <= c2v1_1;
					c2v14 <= c2v4_1;
					c2v16 <= c2v6_1; 
			--Incoming messages to variable node 2
			-- Or outgoing messages from check nodes to variable node 2
					c2v22 <= c2v2_2;
					c2v23 <= c2v3_2;
					c2v24 <= c2v4_2;
			--Incoming messages to variable node 3
			-- Or outgoing messages from check nodes to variable node 3
					c2v31 <= c2v1_3;
					c2v32 <= c2v2_3;
					c2v34 <= c2v4_3;
			--Incoming messages to variable node 4
			-- Or outgoing messages from check nodes to variable node 4
					c2v42 <= c2v2_4;
					c2v43 <= c2v3_4;
					c2v45 <= c2v5_4;
			--Incoming messages to variable node 5
			-- Or outgoing messages from check nodes to variable node 5
					c2v52 <= c2v2_5;
					c2v55 <= c2v5_5;
					c2v56 <= c2v6_5;
			--Incoming messages to variable node 6
			-- Or outgoing messages from check nodes to variable node 6
					c2v61 <= c2v1_6;
					c2v63 <= c2v3_6;
					c2v66 <= c2v6_6;
			--Incoming messages to variable node 7
			-- Or outgoing messages from check nodes to variable node 7
					c2v71 <= c2v1_7;
					c2v72 <= c2v2_7;
					c2v75 <= c2v5_7;
			--Incoming messages to variable node 8
			-- Or outgoing messages from check nodes to variable node 8
					c2v83 <= c2v3_8;
					c2v84 <= c2v4_8;
					c2v86 <= c2v6_8;
			--Incoming messages to variable node 9
			-- Or outgoing messages from check nodes to variable node 9
					c2v91 <= c2v1_9;
					c2v93 <= c2v3_9;
					c2v94 <= c2v4_9;
			--Incoming messages to variable node 10
			-- Or outgoing messages from check nodes to variable node 10
					c2v103 <= c2v3_10;
					c2v105 <= c2v5_10;
					c2v106 <= c2v6_10;
			--Incoming messages to variable node 11
			-- Or outgoing messages from check nodes to variable node 11
					c2v114 <= c2v4_11;
					c2v115 <= c2v5_11;
					c2v116 <= c2v6_11;
			--Incoming messages to variable node 12
			-- Or outgoing messages from check nodes to variable node 12
					c2v121 <= c2v1_12;
					c2v122 <= c2v2_12;
					c2v125 <= c2v5_12;
			
					start <= '1';	 
			when others =>
						Null;
		end case ;			  
		
--	end if ;	   
end process	state_machine;
multiplication: Process	(kk )
--	Multiplication Process Long enough not mentioned

Article: 63036
Subject: Re: Layout examples
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 13 Nov 2003 11:48:06 GMT
Links: << >>  << T >>  << A >>
"Martin Thompson" wrote:

> Indeed it would, I think I must have dropped a factor of 10 somewhere,
> sorry about that!

'been there, done that, paid for it dearly...  :-(


> How about we say that 1-2cm is close enough (for the HF decouplers?)

That would seem to be the case.


> > For my last design truly labored over this and took the approach of
> > writing a custom power distribution system simulation tool in order to
> > get a handle on what was going on.
...
> Agreed - I did much the same thing here.

What's scary is that no matter how much you research the subject it's hard
to achieve convergence.  It seems that everyone has a different --and
perfectly valid-- reason why it should be done differently.  As is the case
with many things in engineering you have no choice but to abandon the search
for the truth, pick an approach you're comfortable with, and move on.

> capacitance?  We put two 3.3V/GND 4thou separation pairs in the board,
> which got us a few nF of very low inductance capacitance, which comes
> in handy at the top end.

Did that, exactly.

> I came to the conclusion that above 100-150MHz you couldn't do a lot
> with capacitors anyway.

Probably true for discrete capacitors.  I remember looking into these BGA
packaged cap arrays that seemed to do quite well at high frequencies.

> > ESR).  If you run the curves, you want some ESR to mitigate peaky
> > resonance effects.
> >
>
> You could always fit some small resistors in series :-)

Funny enough, I did think about this.  The more I looked at the calculations
and the curves the more I realized that you do want more series resistance
with your decouplers.  Sort of counter-intuitive in looking at the problem
superficially, but makes perfect sense in the context of a power
distribution system.  Well, I didn't want to be the first fool to try to
double-stack 0402 chip caps with 0402 chip resistors.  I'll leave that
excercise for those who might be substantially better funded than I am
(enough to redo a board)!  :-)


> Apologies again for my arithmetic!

See what happens when you don't use an RPN calculator!


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"







Article: 63037
Subject: Re: Transforming vector position to binary value
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Thu, 13 Nov 2003 11:53:31 GMT
Links: << >>  << T >>  << A >>
"Peter Alfke" wrote:

> I like using BlockRAMs for unconventional applications
...

Is there an app note or techxclusives article listing unconventional uses of
BlockRAM's and multipliers?  That could be useful to trigger some creative
thinking.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"





Article: 63038
Subject: Re: Transforming vector position to binary value
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Thu, 13 Nov 2003 12:16:30 -0000
Links: << >>  << T >>  << A >>
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
 news:%gKsb.733$Nw.45922360@newssvr21.news.prodigy.com...
> "Peter Alfke" wrote:
> > I like using BlockRAMs for unconventional applications
>
> Is there an app note or techxclusives article listing
> unconventional uses of BlockRAM's and multipliers?
> That could be useful to trigger some creative thinking.

Don't be silly; if it's in a Xilinx appnote, it's _ipso facto_
conventional :-)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 63039
Subject: Xilinx Virtex2 tristate support
From: viveklk@hotmail.com (Vivek)
Date: 13 Nov 2003 04:24:52 -0800
Links: << >>  << T >>  << A >>
Hi,

Does anybody know, whether Xilinx Virtex2 FPGA supports internal tristate?
(the tristate that can't be pushed towards the interface or pins).

Thanks in advance,

Vivek

Article: 63040
Subject: Re: Xilinx Virtex2 tristate support
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 13 Nov 2003 12:46:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Vivek <viveklk@hotmail.com> wrote:
: Hi,

: Does anybody know, whether Xilinx Virtex2 FPGA supports internal tristate?
: (the tristate that can't be pushed towards the interface or pins).

Look for TBUFs
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 63041
(removed)


Article: 63042
(removed)


Article: 63043
Subject: Re: Reading O value
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Thu, 13 Nov 2003 14:11:35 -0000
Links: << >>  << T >>  << A >>
"Isaac" <fpga_uk@yahoo.co.uk> wrote in message
news:889eb3fb.0311130341.64adc04d@posting.google.com...

> Can any body pin point the problem....In state s6
> I am reading out the
> values from FPGA. State s2 and s3 are not defined.

Oh, please.....

* You have posted more than 400 lines of code.
* The code contains no useful comments whatever.
* Most of the signal names are incomprehensible.
* All the state names are meaningless.
* Many of the process sensitivity lists contain
  signals that they do not need.

Kindly put in the effort to isolate the problem
more carefully.  As part of that process, you should
document your code.  This documentation will help
you in understanding what's going on for yourself.

If you still have a problem after you have done
this, then at least you will be able to post
something manageable and there is some chance that
someone will try to help you.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 63044
Subject: unknown devices in JTAG chain
From: "Kay Schubert" <kaytastroph@gmx.de>
Date: Thu, 13 Nov 2003 16:23:55 +0100
Links: << >>  << T >>  << A >>
Hi,

I designed a FPGA prototyping board with a Spartan XC2S200E and a XC18V02
PROM.
To configure these devices I put a JTAG header on the board and routed it as
described in
the following Xilinx datasheet:
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/designing7.html

At the software-side I use impact and the PC3 from Xilinx. When I start
impact in boundary-scan mode,
the PC3 will be detected (as PC3@200kHz) and  the boundary-scan chain will
be identified. But there's the problem:
impact always detects 11 devices in the chain, but there are only two.
And: Even though the two devices are original Xilinx parts, no ID codes were
returned (or better: the returned codes
don't match with Xilinx parts).

I checked the configuration connections and the power supply, but
everything seems to be o.k. Has anybody of you an idea what the problem
could be?

thanks, Kay



Article: 63045
Subject: Re: fitting Xilinx CPLD - I/O Pin Termination
From: Klaus Falser <kfalser@IHATESPAMdurst.it>
Date: Thu, 13 Nov 2003 16:33:08 +0100
Links: << >>  << T >>  << A >>
In article <bopldr$1h0son$1@ID-212430.news.uni-berlin.de>, valentin@abelectron.com says...
> It is not the same as Programmable GND Pins on Unused I/O. I can choose
> between Keeper and Float. There is no information about this property.
> 
> 

Look at the 'bus bold circuitry' in the XC9500XL date sheet and 
at answer #5175 in the Xilinx answer data base.

Best regards  
-- 
Klaus Falser
Durst Phototechnik AG
kfalser@IHATESPAMdurst.it

Article: 63046
Subject: Re: Frequency Doubler - VHDL/Verilog
From: "Arash Salarian" <arash dot salarian at epfl dot ch>
Date: Thu, 13 Nov 2003 17:00:04 +0100
Links: << >>  << T >>  << A >>


HI,
You didn't say anything about the frequency, so maybe for lower =
frequencies one way is to cascade 2 of these 2f circuits to get a 4f =
frequency and then using a simple flipflop to divide it by two, get a =
perfect 50% duty cycle 2f signal.

Best Regards
Arash
  "Gazelle" <wmu@pandora.be> wrote in message =
news:S_vsb.20088$Q87.707719@phobos.telenet-ops.be...
  Good day gents,
                          I am wondering if VHDL (or Verilog) code =
exists in order to make a frequency doubler in a normal
  CPLD (without internal DDL/DPL/PLL infrastructure ) with a symmetric =
duty cycle.
  Below some code can be found which generates a by-2 multiplied =
frequency - however the duty cycle
  is very assymmetrical ...

  Many thanks for your input !

  Regards,

  Michel


  -- Frequency Doubler using DFF
  -- code in VHDL

  library ieee;
  use ieee.std_logic_1164.all;

  entity F2 is
  port  (fi :  in std_logic;  -- Input signal fi
           fo : out std_logic);  -- fo =3D 2*fi
  end F2;


  architecture behav of F2 is
  signal  clk :  std_logic;
  signal q :  std_logic;
  signal notq :  std_logic;


  begin
  process (clk) begin
   if (clk 'event and clk =3D '1') then
   q <=3D notq;
   end if;
  end process;

  notq <=3D not q ;
  clk <=3D (notq xnor fi) ;
  fo <=3D clk;

  end behav;



Article: 63047
Subject: Re: Xilinx Virtex2 tristate support
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 13 Nov 2003 16:19:46 GMT
Links: << >>  << T >>  << A >>
"yes"

I opened the Virtex-II datasheet (Functional Description) and the info was
RIGHT THERE in the bookmarks, "3-State Buffers."


"Vivek" <viveklk@hotmail.com> wrote in message
news:a5bfe71f.0311130424.5dd09bfb@posting.google.com...
> Hi,
>
> Does anybody know, whether Xilinx Virtex2 FPGA supports internal tristate?
> (the tristate that can't be pushed towards the interface or pins).
>
> Thanks in advance,
>
> Vivek



Article: 63048
Subject: Re: unknown devices in JTAG chain
From: Chen Wei Tseng <chenwei.tseng@xilinx.com>
Date: Thu, 13 Nov 2003 09:21:38 -0700
Links: << >>  << T >>  << A >>
Kay,

I assume that you were using initialize chain to detect the devices. I 
also assume that you're using 6.1isp2 iMPACT to perform configuration. 
When iMPACT performs chain initialization, only TMS and TCK are toggled. 
Take a look at Xilinx soln 11857.

So if the chain isn't detected correct, you'll want to probe the TMS, 
TCK, and TDO pins of each device. (ie. are the pins connected correctly, 
anything shorted, etc...)

Other possible causes includes board SI, parallel port noise. You may 
want to contact the Xilinx hotline support for further help.

Regards, Wei

Kay Schubert wrote:
> Hi,
> 
> I designed a FPGA prototyping board with a Spartan XC2S200E and a XC18V02
> PROM.
> To configure these devices I put a JTAG header on the board and routed it as
> described in
> the following Xilinx datasheet:
> http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/designing7.html
> 
> At the software-side I use impact and the PC3 from Xilinx. When I start
> impact in boundary-scan mode,
> the PC3 will be detected (as PC3@200kHz) and  the boundary-scan chain will
> be identified. But there's the problem:
> impact always detects 11 devices in the chain, but there are only two.
> And: Even though the two devices are original Xilinx parts, no ID codes were
> returned (or better: the returned codes
> don't match with Xilinx parts).
> 
> I checked the configuration connections and the power supply, but
> everything seems to be o.k. Has anybody of you an idea what the problem
> could be?
> 
> thanks, Kay
> 
> 


Article: 63049
Subject: Re: Reading O value
From: Brent Hayhoe <For_My_Address@see.my.sig>
Date: Thu, 13 Nov 2003 16:25:00 +0000
Links: << >>  << T >>  << A >>

Jonathan Bromley wrote:

> "Isaac" <fpga_uk@yahoo.co.uk> wrote in message
> news:889eb3fb.0311130341.64adc04d@posting.google.com...
>>
>>Can any body pin point the problem....In state s6
>>I am reading out the
>>values from FPGA. State s2 and s3 are not defined.
> 
> Oh, please.....
> 
> * You have posted more than 400 lines of code.
> * The code contains no useful comments whatever.
> * Most of the signal names are incomprehensible.
> * All the state names are meaningless.
> * Many of the process sensitivity lists contain
>   signals that they do not need.
> 
> Kindly put in the effort to isolate the problem
> more carefully.  As part of that process, you should
> document your code.  This documentation will help
> you in understanding what's going on for yourself.

Jonathan, you left out a few:

* processes without names/labels
* long 'if/elsif' statements where 'case' is more appropriate
* 'Std_Logic_Arith' used instead of 'Numeric_Std'
* and finally <TABs> instead of <spaces> (#note 1)

This has to be the worst example of bad coding style that I've come across in a 
long time - LOL


#note 1 people who use tabs in source code should be
         hung drawn and quartered!.............. IMHO ;-)

-- 

Regards,

         Brent Hayhoe.

Aftonroy Limited
Email: <A 
HREF="mailto:&#066;&#114;&#101;&#110;&#116;&#046;&#072;&#097;&#121;&#104;&#111;&#101;&#064;&#065;&#102;&#116;&#111;&#110;&#114;&#111;&#121;&#046;&#099;&#111;&#109;">




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
2019JanFebMar2019

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