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 153800

Article: 153800
Subject: Re: Logic Glitches in Spartan-3?
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 23 May 2012 23:22:26 -0500
Links: << >>  << T >>  << A >>
In article <jpk3g1$pmp$1@speranza.aioe.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

>It seems to me that a tree of glitch-free LUTs is glitch-free,
>but see what others say.

I don't think so.

Consider this example:
  LUT1 is OR(LUT2, LUT3)
  LUT2 is XOR(A, 0)
  LUT3 is XOR(A, 1)

In the static case, it doesn't matter what A is.
Now switch A.  With appropraite routing delays you can make a glitch.

-- 
These are my opinions.  I hate spam.


Article: 153801
Subject: Re: Logic Glitches in Spartan-3?
From: j.m.granville@gmail.com
Date: Wed, 23 May 2012 22:33:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, May 24, 2012 11:34:26 AM UTC+12, Rob Gaddi wrote:
> I've got a 24-input AND gate that I'd like to avoid having add another
> register delay to before I toss it across a clock boundary.

 A 24 wide and, is an unusual Clock Mux, and Glitches usually only bother a design if they are on a clock tree. Is this clocking something ?

 So long as the wide-AND output meets your clock domain Tsu.Th, why are you worried about glitches ? 

Article: 153802
Subject: Re: Logic Glitches in Spartan-3?
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Thu, 24 May 2012 03:06:40 -0500
Links: << >>  << T >>  << A >>
"Rob Gaddi" <rgaddi@technologyhighland.invalid> wrote in message 
news:20120523163426.7e77de05@rg.highlandtechnology.com...
> seems like neither structure should glitch.  "Try it and see" doesn't
> work; testing all 2^24 combinations and trying to determine whether I
> get a glitch would be a beast of an effort.

Doesn't seem it should be that difficult. 2^24 is only 16 million, not all 
that large compared with the 100's of MHz clocks. 


Article: 153803
Subject: Re: Logic Glitches in Spartan-3?
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 24 May 2012 04:19:22 -0500
Links: << >>  << T >>  << A >>
>"Rob Gaddi" <rgaddi@technologyhighland.invalid> wrote in message 
>news:20120523163426.7e77de05@rg.highlandtechnology.com...
>> seems like neither structure should glitch.  "Try it and see" doesn't
>> work; testing all 2^24 combinations and trying to determine whether I
>> get a glitch would be a beast of an effort.
>
>Doesn't seem it should be that difficult. 2^24 is only 16 million, not all

>that large compared with the 100's of MHz clocks. 
>
>
And the most important part of that can be done by a walking-zero test:
Start with all zero.
Then all one.
24-stage walking-zero.
All one.
All zero.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153804
Subject: Re: Logic Glitches in Spartan-3?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 24 May 2012 10:17:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
> In article <jpk3g1$pmp$1@speranza.aioe.org>,

(snip, I wrote)
>>It seems to me that a tree of glitch-free LUTs is glitch-free,
>>but see what others say.

> I don't think so.

> Consider this example:
>  LUT1 is OR(LUT2, LUT3)
>  LUT2 is XOR(A, 0)
>  LUT3 is XOR(A, 1)

> In the static case, it doesn't matter what A is.
> Now switch A.  With appropraite routing delays you can make 
> a glitch.

But note that I specifically excluded ones that depend on
timing delays, but you snipped out that part.

Note that non-LUT logic can glitch with timing delays, so
that is nothing new. 

Depending on design, LUT logic can glitch even in cases where 
gates wouldn't, which is why FPGAs use glitch-free LUTs. 

-- glen

Article: 153805
Subject: Re: Logic Glitches in Spartan-3?
From: Gabor <gabor@szakacs.invalid>
Date: Thu, 24 May 2012 09:32:10 -0400
Links: << >>  << T >>  << A >>
j.m.granville@gmail.com wrote:
> On Thursday, May 24, 2012 11:34:26 AM UTC+12, Rob Gaddi wrote:
>> I've got a 24-input AND gate that I'd like to avoid having add another
>> register delay to before I toss it across a clock boundary.
> 
>  A 24 wide and, is an unusual Clock Mux, and Glitches usually only bother a design if they are on a clock tree. Is this clocking something ?
> 
>  So long as the wide-AND output meets your clock domain Tsu.Th, why are you worried about glitches ? 

Maybe you missed the fact that he's crossing clock domains, so there's
no way to ensure setup and hold time.

The walking 0's case is really the worst case for an AND gate.  It
guarantees glitches if your inputs aren't set up to "break
before make".  i.e. if you go from 1110111 to 1101111 without
going to 1100111 in between, you'll get a glitch if there
are enough routing delay differences to pass through the LUT.
You'll need to walk the zeroes in all directions to ensure
complete timing test coverage.  This means 276 transitions
for the 24-bit case (combination of 24 taken 2 at a time).
If your input logic can guarantee that you'll never make this
sort of state transition, then you won't get glitches.  I
think it would be easier to add another register after the
AND gate and then you just need to meet Tsu and Th.

- Gabor

Article: 153806
Subject: Re: ITU656 to JPEG/Mpeg4 with Fpga?
From: thomas.entner99@gmail.com
Date: Thu, 24 May 2012 07:18:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
> > Convert this to JPEG
> > over Ethernet with a FpGa as implemented by the SoC  Milkymist
> > project.
> >
> > Ques: Where would one option an IP for this?
> 
> So You need to convert video frames to JPEG or to MPEG4? MPEG4 would be huge 
> and cost a lot... Afaik JointWave could offer something for You.

If you require JPEG, we can offer a small, high-performance and reasonable priced encoder (and also decoder):
http://www.entner-electronics.com/tl/index.php/jpeg-codec.html

Thomas

www.entner-electronics.com

Also check out our EEBlaster: 
http://www.entner-electronics.com/tl/index.php/eeblaster.html

Article: 153807
Subject: Re: Logic Glitches in Spartan-3?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 24 May 2012 14:24:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Gabor <gabor@szakacs.invalid> wrote:
> j.m.granville@gmail.com wrote:
>> On Thursday, May 24, 2012 11:34:26 AM UTC+12, Rob Gaddi wrote:
>>> I've got a 24-input AND gate that I'd like to avoid having add another
>>> register delay to before I toss it across a clock boundary.
 
>>  A 24 wide and, is an unusual Clock Mux, and Glitches usually 
>> only bother a design if they are on a clock tree. Is this 
>> clocking something ?

> Maybe you missed the fact that he's crossing clock domains, 
> so there's no way to ensure setup and hold time.

That is true, but if there aren't any glitches it will go 1
either one cycle or the next.

> The walking 0's case is really the worst case for an AND gate.  
> It guarantees glitches if your inputs aren't set up to "break
> before make".  i.e. if you go from 1110111 to 1101111 without
> going to 1100111 in between, you'll get a glitch if there
> are enough routing delay differences to pass through the LUT.

Given that it is an AND of done bits, in the usual case each
one transitions from 0 to 1 until all are 1. 

If you use a traditional SRAM, with row select logic, the bits
of each row coming out, and then a MUX to select one of the
rows, even if the inputs change between states that don't
even come close to a cell of a different value, the output
can still glitch. The delays through different parts of
the DEMUX row select, or the MUX column select can be
different. Fill up a SRAM such that only one cell is 1, 
hold one input at 0, and go through all combinations of
the other inputs. 

For that matter, fill the array with all 0, and go through 
all combinations of inputs. An SRAM can still glitch to 1. 

The glitchless LUTs used in FPGAs are designed not to do that.

If you hold one input a 0, for all combinations of other inputs,
even with timing differences, the output should stay zero.

> You'll need to walk the zeroes in all directions to ensure
> complete timing test coverage.  This means 276 transitions
> for the 24-bit case (combination of 24 taken 2 at a time).
> If your input logic can guarantee that you'll never make this
> sort of state transition, then you won't get glitches.  I
> think it would be easier to add another register after the
> AND gate and then you just need to meet Tsu and Th.

Since the 24 bit AND will be generated as some number of
LUTs feeding either another LUT or carry chain AND logic,
another possibility is to put a register between the two
levels of AND. It seems to me that isn't necessary, but
could be done.

-- glen

Article: 153808
Subject: Re: Logic Glitches in Spartan-3?
From: Andy <jonesandy@comcast.net>
Date: Thu, 24 May 2012 07:30:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 23, 6:34=A0pm, Rob Gaddi <rga...@technologyhighland.invalid>
wrote:
> I've got a 24-input AND gate that I'd like to avoid having add another
> register delay to before I toss it across a clock boundary.
>
> =A0 =A0 =A0 =A0 all_done <=3D and_reduce(done);
>
> If I just do it, AND it all together without a flop on the output, does
> anyone know whether I'll get transition glitches (an output of 1 when
> not all inputs are 1)?
>
> I seem to remember something about individual LUTs being glitch-free,
> and the synthesizer has to compose my giant AND out of either a LUT
> tree or a mess o' LUTs "wire-and" driving a carry chain, =A0Offhand, it
> seems like neither structure should glitch. =A0"Try it and see" doesn't
> work; testing all 2^24 combinations and trying to determine whether I
> get a glitch would be a beast of an effort.
>
> Anyone know offhand?
>
> --
> Rob Gaddi, Highland Technology --www.highlandtechnology.com
> Email address domain is currently out of order. =A0See above to fix.

Unless you can guarantee that no more than one of the done bits
changes at any one time, you WILL get glitches sooner or later, and
sooner or later they will line up with the (async) receiveing clock,
and you will have bad data transferred, if you simply leave it up to
the synthesis tool to implement the LUT/Carry structure.

If you force the synthesis tool to implement a specific AND structure,
you may be able to avoid glitches based on how the done bits
collectively behave. For example, if you are only concerned with the
leading edge of all_done, and the done bits monotonically transition
from 0 to 1 (never go back to zero until you don't care), you can
probably get some structure to work reliably.

If you don't have time for an additional clock cycle in the source
domain, do you have time for a half-cycle (register all_done on the
opposite edge of the source clock)?

Depending on the relative clock frequencies and your latency
requirements, you may have time to "filter" the all_done signal in the
destination clock domain, and thus reject glitches.

There are probably many ways to do this, but the conventional approach
of registering all_done in the source domain prior to sampling in the
destination domain is the easiest by far to verify.

Andy

Article: 153809
Subject: Re: Logic Glitches in Spartan-3?
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 24 May 2012 13:56:04 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:


> 
> It seems to me that a tree of glitch-free LUTs is glitch-free,
> but see what others say.
It seems to me that routing delays will make this not work.
Yes, for exactly one input changing state at a time, your statement
MIGHT still be true, but for multiple inputs changing state at
the same time, such as one input going high while one other
goes low, the propagation of these signals through the routing
will certainly cause glitches.

Now, maybe there is some simplification possible depending on
how this is used.  If the normal state is all inputs false,
and occasionally a few inputs are true, then this might never glitch.
If the normal state is 23 inputs true, and the pattern of which ones
are true changes, then I would expect glitches are possible.

Jon

Article: 153810
Subject: Re: Logic Glitches in Spartan-3?
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Thu, 24 May 2012 12:13:51 -0700
Links: << >>  << T >>  << A >>
On Thu, 24 May 2012 14:24:53 +0000 (UTC)
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> 
> Given that it is an AND of done bits, in the usual case each
> one transitions from 0 to 1 until all are 1. 
> 

That's exactly right, and I feel silly for not having mentioned it out
front.  The assertion of all_done, shifted onto a different clock
domain, is what goes back around and asynchronously
clears all of the individual done flags.

All of you stop wincing; I know exactly how bad that sounds and I
swear to god there are reasons it had to be this way.

So the only possible modes of operation are:
  all_done is low, and all I want is for it to never erroneously
  transition high until all 24 done flags come up.  Once it's up it
  stays up.

  all_done has been high, causing a 20 ns asynchronous clear pulse to
  hit all the done flags, dropping them all.  In this case, all_done
  should drop once and only once as the various path skews from the
  pulse to the clear to the AND gate structure all work themselves out.

The reason I'm concerned about glitches is, because all_done is sampled
asynchronously to it's originating clock, a glitch could happen to get
captured, with some unknown but small probability.  The reason I can't
just test it out is the same: given that if a glitch exists there's
only a small probability of capturing it, I might test a given
sequence 10,000 times without catching a glitch that I would have seen
on the 10,001st.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 153811
Subject: Re: Logic Glitches in Spartan-3?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 24 May 2012 21:28:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
> On Thu, 24 May 2012 14:24:53 +0000 (UTC)

(snip, I wrote) 
>> Given that it is an AND of done bits, in the usual case each
>> one transitions from 0 to 1 until all are 1. 

> That's exactly right, and I feel silly for not having mentioned 
> it out front.  The assertion of all_done, shifted onto a different 
> clock domain, is what goes back around and asynchronously
> clears all of the individual done flags.

You mean a register between all_done and when it goes back around?
I would call it asynchronous if there wasn't a register there.

> All of you stop wincing; I know exactly how bad that sounds and I
> swear to god there are reasons it had to be this way.

If there is a zero hold time register (And even if not, the 0
signal won't make it back fast enough to cause problems.)
then that is fine. If there is no register around the loop,
then it takes somewhat more analysis.

> So the only possible modes of operation are:
>  all_done is low, and all I want is for it to never erroneously
>  transition high until all 24 done flags come up.  Once it's up it
>  stays up.

You don't say about any possibly glitches on inputs to the AND.

>  all_done has been high, causing a 20 ns asynchronous clear pulse to
>  hit all the done flags, dropping them all.  In this case, all_done
>  should drop once and only once as the various path skews from the
>  pulse to the clear to the AND gate structure all work themselves out.

The only way you could know the pulse was 20ns is coming from a FF
clocked at 50MHz, so I will assume that. In that case, you only have
to worry about glitches that last longer than 20ns. That is, after
all_done has been latched, could it glitch low 20ns later. The AND
gate shouldn't do that itself, but if its inputs can, that could
still be a problem. But 20ns is pretty long, so you should be able
to prove that can't happen. 

> The reason I'm concerned about glitches is, because all_done is sampled
> asynchronously to it's originating clock, a glitch could happen to get
> captured, with some unknown but small probability.  The reason I can't
> just test it out is the same: given that if a glitch exists there's
> only a small probability of capturing it, I might test a given
> sequence 10,000 times without catching a glitch that I would have seen
> on the 10,001st.

There is another problem not discussed yet: metastability.
Metastability is completely separate from race conditions, but
people sometimes get the two confused. You need to separately 
show that metatability isn't a problem. 

I am still not sure where the registers are, so I won't try to
say more about metastability.

Also, if there is no register around the loop (which seems 
unlikely mentioning clock domains) then it takes different
treatment.

-- glen

Article: 153812
Subject: Re: Logic Glitches in Spartan-3?
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 24 May 2012 23:28:20 GMT
Links: << >>  << T >>  << A >>
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

>I've got a 24-input AND gate that I'd like to avoid having add another
>register delay to before I toss it across a clock boundary.
>
>	all_done <= and_reduce(done);
>
>If I just do it, AND it all together without a flop on the output, does
>anyone know whether I'll get transition glitches (an output of 1 when
>not all inputs are 1)?
>
>I seem to remember something about individual LUTs being glitch-free,
>and the synthesizer has to compose my giant AND out of either a LUT
>tree or a mess o' LUTs "wire-and" driving a carry chain,  Offhand, it
>seems like neither structure should glitch.  "Try it and see" doesn't
>work; testing all 2^24 combinations and trying to determine whether I
>get a glitch would be a beast of an effort.
>
>Anyone know offhand?

You'll get glitches for sure due to different routing delays between
the LUTs themselves and the input signals.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153813
Subject: Re: Logic Glitches in Spartan-3?
From: j.m.granville@gmail.com
Date: Thu, 24 May 2012 16:50:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, May 25, 2012 7:13:51 AM UTC+12, Rob Gaddi wrote:
> The reason I'm concerned about glitches is, because all_done is sampled
> asynchronously to it's originating clock, a glitch could happen to get
> captured, with some unknown but small probability.  The reason I can't
> just test it out is the same: given that if a glitch exists there's
> only a small probability of capturing it, I might test a given
> sequence 10,000 times without catching a glitch that I would have seen
> on the 10,001st.

 Since this seems to be a slow handshake, and you do not expect it to spin at 50MHz, but you do want to avoid another register in the 'go' pathway, why not design your state handshake, so single-pulse glitches are tolerated/ignored ?


Article: 153814
Subject: Re: Logic Glitches in Spartan-3?
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Fri, 25 May 2012 03:44:28 -0500
Links: << >>  << T >>  << A >>
>On Thu, 24 May 2012 14:24:53 +0000 (UTC)
>glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> 
>> Given that it is an AND of done bits, in the usual case each
>> one transitions from 0 to 1 until all are 1. 
>> 
>
>That's exactly right, and I feel silly for not having mentioned it out
>front.  The assertion of all_done, shifted onto a different clock
>domain, is what goes back around and asynchronously
>clears all of the individual done flags.
>
>All of you stop wincing; I know exactly how bad that sounds and I
>swear to god there are reasons it had to be this way.
>
>So the only possible modes of operation are:
>  all_done is low, and all I want is for it to never erroneously
>  transition high until all 24 done flags come up.  Once it's up it
>  stays up.
>
>  all_done has been high, causing a 20 ns asynchronous clear pulse to
>  hit all the done flags, dropping them all.  In this case, all_done
>  should drop once and only once as the various path skews from the
>  pulse to the clear to the AND gate structure all work themselves out.
>
>The reason I'm concerned about glitches is, because all_done is sampled
>asynchronously to it's originating clock, a glitch could happen to get
>captured, with some unknown but small probability.  The reason I can't
>just test it out is the same: given that if a glitch exists there's
>only a small probability of capturing it, I might test a given
>sequence 10,000 times without catching a glitch that I would have seen
>on the 10,001st.
>
>-- 
>Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>Email address domain is currently out of order.  See above to fix.
>

Perhaps a silly question, but why can you not register 'all_done'?

For extra safety, don't assert 'clear_dones' until 2 or 3 successive
highs.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153815
Subject: Read output from external chip using microblaze
From: "nana_7488" <nana_7488@n_o_s_p_a_m.yahoo.com>
Date: Fri, 25 May 2012 05:34:27 -0500
Links: << >>  << T >>  << A >>
Hi all
I got stuck with my design. I'm planning to use microblaze in ML505 board
to read my full custom chip output and display to hyperterminal.
I've found one tutorial about read DIP switch using microblaze, but here I
want the output of my external chip to be read by microblaze.
I'm confused of the device_ID that I should use in my programming so that
the microbalze can read the signal.

FYI, I want to test my chip by driven the input signal using test vector
that I've designed using VHDL in Virtex-5(ML505)and the test vector output
will be the input of my chip. Then my chip will produce the output and
display at hyperterminal using microblaze.

Hope somebody can help me with this.
Thanks

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153816
Subject: Re: Read output from external chip using microblaze
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Fri, 25 May 2012 06:48:24 -0500
Links: << >>  << T >>  << A >>

"nana_7488" <nana_7488@n_o_s_p_a_m.yahoo.com> wrote in message 
news:SNWdnf0AHOmu_SLSnZ2dnUVZ_gydnZ2d@giganews.com...
> Hi all
> I got stuck with my design. I'm planning to use microblaze in ML505 board
> to read my full custom chip output and display to hyperterminal.
> I've found one tutorial about read DIP switch using microblaze, but here I
> want the output of my external chip to be read by microblaze.
> I'm confused of the device_ID that I should use in my programming so that
> the microbalze can read the signal.
>
> FYI, I want to test my chip by driven the input signal using test vector
> that I've designed using VHDL in Virtex-5(ML505)and the test vector output
> will be the input of my chip. Then my chip will produce the output and
> display at hyperterminal using microblaze.

ChipscopePro does that, I think. I mean, I know what chipscope does; just 
not sure if you meant what I thought you were trying to say. There's a 30 
day free eval license.

The microblaze needs the embedded tools edition. That's dandy if you have it 
already. (In which case, you already have ChipscopePro.) Eval license for 
that is also available.

I wouldn't take the microblaze approach, to solve apparently a small problem 
with a much larger project. I'm assuming here that if the data rate is slow 
enough to make a serial terminal feasible, it's a tiny tiny problem.

Gpio interface is the answer to your dipswitch question. Anything much more 
complex really would be better on chipscope.




Article: 153817
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Christopher Head <chead@is.invalid>
Date: Sat, 26 May 2012 10:10:13 -0700
Links: << >>  << T >>  << A >>
On Wed, 23 May 2012 10:19:05 -0700 (PDT)
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

> Yes, this is why I asked (although it was in the original post).  I
> have confirmed that the problem only happens with the new parser
> (Spartan-6, Virtex-6, 7 Series) and is not present in the original
> parser.  This is still true for the ISE 14.1 release.
> 
> I filed an intenal change request/bug report on the issue to get it
> fixed.
> 
> Note: I need to stop using Google groups because they continue to drop
> my posts (2nd try) unless I logout and then back in again.
> 
> Ed McGettigan
> --
> Xilinx Inc.

Thanks for the attention! Since Xilinx doesn't want bug reports from
university students, I figured this group was an easy way to get some
more eyes on the issue and hopefully get it fixed at some point.

Chris

Article: 153818
Subject: Re: Xilinx ISE Multiple Drivers Error
From: Michael Karas <mkaras@carousel-design.com>
Date: Sun, 27 May 2012 11:44:43 -0700
Links: << >>  << T >>  << A >>
[This followup was posted to comp.arch.fpga and a copy was sent to the 
cited author.]

In article <20120518175419.3278d371@kruskal.chead>, chead@is.invalid 
says...

> I think this may have hit the nail on the head. 
> 
> Chris

Sounds like it is hitting Chris on the head too. :-)

-- 

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com

Article: 153819
Subject: Re: Read output from external chip using microblaze
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Mon, 28 May 2012 04:04:41 -0500
Links: << >>  << T >>  << A >>
>Hi all
>I got stuck with my design. I'm planning to use microblaze in ML505 board
>to read my full custom chip output and display to hyperterminal.
>I've found one tutorial about read DIP switch using microblaze, but here
I
>want the output of my external chip to be read by microblaze.
>I'm confused of the device_ID that I should use in my programming so that
>the microbalze can read the signal.
>
>FYI, I want to test my chip by driven the input signal using test vector
>that I've designed using VHDL in Virtex-5(ML505)and the test vector
output
>will be the input of my chip. Then my chip will produce the output and
>display at hyperterminal using microblaze.
>
>Hope somebody can help me with this.
>Thanks

What is the interface of the "full custon chip" that you want to read?
Or is it just a bunch of signals?
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153820
Subject: EDK problems
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Mon, 28 May 2012 15:20:40 -0500
Links: << >>  << T >>  << A >>
Does anyone have experience of using the Altera and Xilinx embedded
software? I have been using EDK but I am getting very frustrated with it.
It seems that every new release includes a generous helping of bugs. I seem
to find myself wasting hours just trying to get a design to be implemented.
For example the 14.1 release now seems to have some problems with the
interrupt controller, yet it was ok in the previous release. Does the
Altera software have as many bugs?

TIA

Jon

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153821
Subject: Re: Xilinx ISE 12.3 : library simprim problem
From: sandhya.mathur08@gmail.com
Date: Mon, 28 May 2012 22:14:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, 18 October 2010 17:04:55 UTC+5:30, neosis  wrote:
> Hi all, I'm using ISE 12.3 to implement a design.
> I generate a verilog netlist which contains cells of the simprim library.
> I used this command line to do that : 
> netgen -w -ecn conformal -ne -mhf clockbuf
> I obtained 2 verilog files : glbl.v & clockbuf_ecn.v
> 
> Then I take this netlist and do some changes on it ( split it in parts for
> example ). But if I start a new project whith the new files, ise can't find
> simprims library.
> 
> I tried also to start another new project with these 2 files( with
> nochanges), and I included all verilog files of used cells from the simprim
> library. and here is what I obtain :
> 
> ERROR:HDLCompilers:244 -
> "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_OBUF.v" line 36
> Name 'glbl.GTS' could not be resolved
> ERROR:HDLCompilers:185 -
> "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_OBUF.v" line 36
> Illegal right hand side of continuous assign
> ERROR:HDLCompilers:244 -
> "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_FF.v" line 42
> Name 'glbl.GSR' could not be resolved
> ERROR:HDLCompilers:185 -
> "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_FF.v" line 42
> Illegal right hand side of continuous assign
> ERROR:HDLCompilers:244 -
> "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_BUFGMUX.v" line
> 46 Name 'glbl.GSR' could not be resolved
> ERROR:HDLCompilers:185 -
> "../../work/xilinx/opt1/ISE_DS/ISE/verilog/src/simprims/X_BUFGMUX.v" line
> 46 Illegal right hand side of continuous assign
> 
> Can anyone explain me what to do?
> thx for your help.
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

I am facing the same problem. Did you figure out how to resolve this problem?

Article: 153822
Subject: Re: EDK problems
From: Jon Elson <jmelson@wustl.edu>
Date: Tue, 29 May 2012 14:39:45 -0500
Links: << >>  << T >>  << A >>
maxascent wrote:

> Does anyone have experience of using the Altera and Xilinx embedded
> software? I have been using EDK but I am getting very frustrated with it.
> It seems that every new release includes a generous helping of bugs. I
> seem to find myself wasting hours just trying to get a design to be
> implemented. For example the 14.1 release now seems to have some problems
> with the interrupt controller, yet it was ok in the previous release. Does
> the Altera software have as many bugs?
I am not using the very latest Xilinx chip products, so I don't have
to use their very latest software.  I am using 10.1, as it supports the
relatively modern parts I use as well as some of the older parts that
are still used in some of our more mature designs.  Sometimes funny
things happen and I think it is using old versions of the vhdl files,
but exiting the Ise environment and starting it up again seems to clear
it up.  Otherwise, I have had no significant problems with Ise 10.1

Jon

Article: 153823
Subject: ISERDES2 divide factor
From: jonpry <jonpry@gmail.com>
Date: Wed, 30 May 2012 13:50:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

   I have a Spartan-6 LX45 board with a whole bunch of lvds going in
and out at a rate of 780mbps. After running out of pins I was forced
to put two lvds receiving pairs into a different bank from the rest of
the bus. To make matters worse this bank has an active MCB.  All of
the tx/rx lvds is synchronous with a clock I have inside the fpga so
both transmit and receive are handled through the BUFPLL method
suggested in XAPP1064. Receive channels are using the differential
phase detector mode of IDELAY2 and ISERDES2.

   The bank with the MCB presents a unique challenge because the MCB
makes use of both BUFPLL resources available along that edge of the
device. On the bright side I am able to run the memory interface at
the same 780mbps potentially allowing me to use the same BUFPLL
technique used on other edges of the device. The problem is that the
MCB requires the BUFPLL to be run with DIVIDE=2 essentially causing
the fabric side of the ISERDES2 to run at 390mhz!

   In the XAPP1064 source code I found the following note relating to
the instantiation of ISERDES2:

DATA_WIDTH     		=> 6, 			-- SERDES word width.  This should match the
setting is BUFPLL

   I wonder what exactly "should" means. Say that I have BUFPLL with
divide=2 and ISERDES with width=6. What is really going to happen?
Looking at figure 3-1 on page 80 of UG381. It looks to me as though it
would work fine. A bitslip machine would be able to line of which of
the 3 strobes was actually the correct one.

Article: 153824
Subject: Variables, signals: behavioral and post-route simulation
From: aleksazr@gmail.com
Date: Fri, 1 Jun 2012 00:53:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm learning the diff between variables and signals,
and I've found this site:
http://esd.cs.ucr.edu/labs/tutorial/sig_var.vhd
with a corresponding picture here:
http://esd.cs.ucr.edu/labs/tutorial/sig_var.jpg

I've changed the source file to this

library ieee;
use ieee.std_logic_1164.all;

entity sig_var is port (
    d1, d2, d3          : in    std_logic;
    res1, res2, res3    : out   std_logic);
end sig_var;

architecture behv of sig_var is
    signal sig_s1: std_logic;
    signal sig_s2: std_logic;

begin

proc1: process(d1,d2,d3)
    variable var_s1: std_logic;

begin
    var_s1 := d1 and d2;
    res1 <= var_s1 xor d3;
end process;

proc2: process (d1,d2,d3)
begin
    sig_s1 <= d1 and d2;
    res2 <= sig_s1 xor d3;
end process;

sig_s2 <= d1 and d2;
res3 <= sig_s2 xor d3;

end behv;


and this are the simulation results:
http://img521.imageshack.us/img521/346/simulations.gif

As you can see, behavioral and post-route don't match.
Is there something wrong with the VHD source,
or I just don't get the idea behind behavioral simulation?

Post route works as I have expected.

(I've started this thread as a variable/signal issue,
but it turned into behavioral/post-route simulation.)



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