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 151800

Article: 151800
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Brad <hwfwguy@gmail.com>
Date: Wed, 18 May 2011 14:02:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 5:32=A0am, wzab <wza...@gmail.com> wrote:
> to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool)

Maybe you've looked at the CPU-less option before. Python has an
interactive console, so it's almost like "C done right". In that
respect, since you seem to know more Python than Forth, Python on the
host end would make sense.

Usually a built-in CPU is used primarily to control things. The
debugger is an added feature. If all you need is the debugger and you
define the hardware, a CPU may not be necessary.

-Brad

Article: 151801
Subject: Re: Modelsim
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Wed, 18 May 2011 22:57:49 +0100
Links: << >>  << T >>  << A >>
On Wed, 18 May 2011 11:57:09 -0500, "maxascent" wrote:

>>>> Does anyone know if its possible to change the waveform signals so
>that
>>>> they are in hex instead of binary. I dont want to do it manually but
>>>> just have it come up in hex when the design is loaded.

Manually tweak the waves so at least some of them look
the way you want.  Then, in the wave window, pick
menu File/SaveFormat.  This will save you a "wave.do"
file, which is just a big messy Tcl script.  You can
replay that into the wave viewer any time, or you
can pick individual lines from it and modify them
to taste to create your custom setup script, and
then execute that on the command line using
  vsim -do my_script.tcl

It's a good idea to save the wave format first,
because that file contains a lot of unusual but
straightforward commands to adjust wave view that
would take you ages to find by reading the docs.
-- 
Jonathan Bromley

Article: 151802
Subject: Re: How to use the EXT_CLK_P and EXT_CLK_N pins of Virtex II Pro
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 18 May 2011 17:24:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 11:14=A0am, Pratap <pratap.i...@gmail.com> wrote:
> On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote:
>
>
>
>
>
> > Hi,
> > I need to take out two square wave signals from the Virtex II Pro FPGA
> > board(XC2VP30, package ff896) with good signal shape and less jitter
> > value. The frequency of the two square wave signals are around 40MHz
> > and one is the delayed version of the other. I am trying to evaluate
> > the performance of a delay generator block inside the FPGA. Hence, the
> > shape and precision of the delays is of greater importance to me. I
> > have tried to take the signals through various pins on the board
> > including the high speed expansion connector. But I found that only
> > when the signals are routed out through the EXT_CLK_P(G15) and
> > EXT_CLK_N(F15) pins, the jitter performance is the best. But there is
> > a funny thing happening when I observe the two waveforms on a scope.
> > Below are the two cases. Looks like, when the signal levels of the two
> > signals are different, the signal with ZERO logic goes up to around
> > 0.2*Vsupply and at the same time the signal with logic '1' goes down
> > by around 0.2Vsupply. Can anybody suggest how can I avoid such a
> > situation? I feel there is some sort of resistor coupling between
> > these two signals. But, can I =A0disable this coupling by changing some
> > setting in the ucf file? This is the entry in the ucf file
> > corresponding to the two pins mentioned above.
>
> > NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW =3D=
 FAST |
> > DRIVE =3D 12 ;
> > #EXTERNAL_CLOCK_P=3DG15
>
> > NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVTTL |=
 SLEW
> > =3D FAST | DRIVE =3D 12 ;
> > #EXTERNAL_CLOCK_N=3DF15
>
> > Please suggest a way to set these signals such that the coupling
> > between these two signals is nullified and I can use them as two true
> > single ended outputs.
>
> > Here is an illustration of the case.https://picasaweb.google.com/lh/web=
Upload?uname=3Dpratap.iisc&aid=3D56081...
>
> > Waiting for some helpful answers.
> > Thanks and regards,
> > Pratap
>
> Sorry...The link for the picture was wrogly pasted...Here is the
> correct link.https://picasaweb.google.com/pratap.iisc/May182011?authkey=
=3DGv1sRgCMjQ...- Hide quoted text -
>
> - Show quoted text -

Based on the names these are intended to be a differential pair.  This
means that they have been routed close together on the board and will
have intentional coupling/crosstalk between the two routed nets.  In
addition there is likely a 100 ohm termination resistor between the
two nets that is generating the bump that you are seeing.

The resistor could be removed, you will need to check the schematics
for you board to determine which one it is.

The crosstalk however cannot be removed.

Ed McGettigan
--
Xilinx Inc.

Article: 151803
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Wed, 18 May 2011 19:46:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 8:32=A0am, wzab <wza...@gmail.com> wrote:
> > At this point I can't say I understand what you are asking. =A0Do you
> > have something specific you are asking about or have you figured it
> > out at this point?
>
> The idea was to have a small but efficient CPU inside of FPGA which
> could be used to collect some debugging data (e.g. connected
> to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool)
> and also to control behavior of user IP core.
> Forth seems to be the best solution due to it's extendibility
> and possibility to work using simple link (serial or other).
>
> I've exchanged some e-mails with the developer who ported J1 to
> MyHDL and after this discussion I think, that the approach used
> in Riscy Pygness may be really the best solution.

Sounds like you will be doing what I would like to be doing.  I have
my own dual stack CPU design intended to run Forth.  I have only used
Forth as a sort of macro assembler for it and with no more work that
needs such a CPU it has sat for a number of years with no further
development.

I have considered a couple of alternatives for adding proper software
development support for an embedded processor.  One is using open
source software such as Riscy Pygness.  The other is working from a
commercial package such as MPE Forth.  From my perspective a
commercial package has lot of benefits which include a wide software
base that conceivably could be available to support complex projects.
The down side is that the use of the processor would be limited to
owners of the commercial tool.

The advantage of an open source tool is that it is available for
anyone to work with and to work on.  But you start with a lot less
capability.

How do you plan to proceed?  I assume you are looking for some initial
capability that will let you compile code to machine instructions,
download those instructions to the target and then interact with the
target for debugging.  Do you look for anything more?

Rick

Article: 151804
Subject: Re: Scoping a glitch
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Wed, 18 May 2011 20:15:17 -0700
Links: << >>  << T >>  << A >>
Nial Stewart wrote:
>>> What's the signal path to the FPGA?
>>> The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to
>> connect to a research lab.  The output of the ISO (input to FPGA) at
>> 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA
>> header pin on the Digilent NEXYS2 board.
> 
> Then it's probably not a ground problem, especially if this is the only
> input to the FPGA.
> 
>> That is a horizontally magnified view of the input to the FPGA (ch1
>> "A0") measured at the Digilent board pin, with 1.5cm probe ground to the
>> Digilent pin.
> 
> Does that go straight to the FPGA?
> 
> Is this what it's seeing?

Yes, the FPGA input is at the other end of about 2" of trace after the
pin where the signal was scoped.

>>> If that falling edge is an input than at ~30ns it's shouldn't be what's causing
>>> the problem unless you've got _terrible_ ground problems.
>> Well if there are ground problems, they are out of my control, as this
>> is the signal at the pin on the Digilent board.  I would expect them to
>> have done a competent job.
>> I'm not sure, is there a history of people complaining about Digilent
>> board signal integrity problems?
> 
> No, as above this almost definitely isn't a problem.
> 
>>> This shows your design is still susceptible to asynchronous inputs toggling.
>> The important other fact is that if the drive impedance is made stiffer
>> (180->50ohms) and speed to the FPGA input increased (30->10ns) then the
>> glitches are no longer observed, even after an all night wait.
> 
> There could be a race condition internally which stops being a factor when
> you speed up the inputs.
> 
> Depending on your build, choice of pins etc this could be re-introduced at
> any point.

I find this less plausible than simply ground bounce.  Although at the
same time, I find it very new to have a problem with a 30ns rise/fall.

Can you explain a mechanism for such a race condition so I can think
about it better?

Regarding other things going on, there are the QEP outputs switching a
few ns after the clock switches.

There were several other asynchronous IOs going in and out, such as a
1MHz and 250kHz divided clock, coming from the 50MHz board clock (which
is async vs. the 288kHz qep_sim() clock causing the trouble.

> :-)

Indeed.

>>> Synchronise both(all) the inputs at the IO to the system clock then use those
>>> to look for falling or rising edges for your counter
>> Yeah, tried that.  Works.  I think I have things under control, with two
>> possible choices of path forward.
> 
> No, there's _only_ one path forward, synchronise your inputs.

Well that's what I've changed it to and it worked fine the first time.

> The input you're looking at is _reasonably_ fast, how fast is the internal clock
> you're using to synchronise it? Ideally it'll be a good multiple (> 5) of this
> clock.

Well, the board clock is 50MHz.  That works fine.  Later I will
experiment with sending that into the on chip DCM/PLL/DLL thingy and see
what happens when I resync stuff at 100MHz, and 200MHz.

Of course, now the outputs of my qep_sim() have 20ns of
re-synchronization jitter relative to the 288kHz QEP "clock" input.

This is Ok in this situation because there are no other data flows
synchronous with the 288kHz that must interact with the output from the
FPGA.

But I can envision cases where this just can't be tolerated, and the
FPGA must be configured to count, divide, etc. external clocks and
produce outputs that are synchronous with the external clock.

It seems the FPGA designers are focussed on a world of data interfaces
where the one rule always applies.  But what if sub-ns jitter pulse
genration of frequency division relative to an external timebase is
required?   How to do that?  Can't be done unless you allow an isolated
clock domain.  This is a common need in scientific experiments, pulse
generators, laser control logic, etc.

What am I to do with those problems, design discrete logic again?

The whole point of an FPGA to me is that in a research environment, the
requirements change constantly, so flexible logic on an inflexible PCB
is necessary.  I take the expected needs today and say "oh they need a
few counters and gates, so multiply that by 100-1000 and in a few years
they will have chewed through half of the over-designed resources."
That much time I don't have to re-spin the hardware PCBs.  I love PLDs!
 Coupled with a decent CPU and one little platform can fill a thousand
roles.

That said, certainly what I've gathered at this point is that for
whatever clock is brought into the FPGA, that certainly shouldn't be
gated or muxed, unless perhaps it's done with resources designed for
that purpose, and there is comprehension on how to analyze the timing.



>> Thanks for the feedback.

Once again!




-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151805
Subject: Re: Counter clocks on both edges sometimes, but not when different
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Wed, 18 May 2011 20:21:53 -0700
Links: << >>  << T >>  << A >>
Pete Fraser wrote:
> Brian Drummond wrote:
>> On Tue, 17 May 2011 06:40:07 -0700, rickman wrote:
>>
>>> this is working well for my kayaking schedule.  :^)
>>>
>> Heh, you too, huh?
> 
> Is there some requirement that FPGA coders
> are also kayakers?
> 
> Pete Fraser
> Looksha IV HV


No, only that you can only ever use one clock. ;-)



-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151806
Subject: Re: Scoping a glitch
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 18 May 2011 21:48:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 11:15=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
> Nial Stewart wrote:
> > Depending on your build, choice of pins etc this could be re-introduced=
 at
> > any point.
>
> I find this less plausible than simply ground bounce. =A0Although at the
> same time, I find it very new to have a problem with a 30ns rise/fall.
>
> Can you explain a mechanism for such a race condition so I can think
> about it better?
>

FPGA logic is implemented with memory lookup tables.  Since your mux
logic has two clock inputs that are presumably running at different
frequencies there will be times when both of those inputs are changing
*close* to the same time and from the viewpoint of the memory device
that is encoding the mux logic might temporarily be outputting the
'wrong' value.  FPGA vendors can make the so that a single input
change to the memory will not cause a spurious output glitch but they
typically don't guarantee no glitches when two or more inputs change
simultaneously.  This may or may not be the failure mechanism in your
particular case here, but it is a mechanism that needs to be avoided.
This is also why one would want to sync the clocks first and then mux
them.

It's easy to think of the logic you write as being implemented by
gates, but that is not what is happening.  FPGA logic gets implemented
in lookup table memories.  Changing the address inputs can cause a
glitch on the output in certain cases.

Another situation would be if the two inputs are not asynchronous but
changing the relative timing of one with respect to the other changes
the behavior slightly (for better or worse).  As an example, any case
where you have a clock path that clocks some device and the clock then
goes through some delay and then gets used to clock some other device
that receives data input (directly or through logic) from the first
clocked device would be this type of situation.  If the delay through
the clock path is *long* and the delay through the data path is
*short* then the data can beat the clock to the downstream device.
This is a race condition.  In this case you can find that an apparent
'fix' (really a band-aid) can be any of the following:
- Re-routing until you get a long enough delay on the data path so
that the clock wins the race
- Put a big capacitor on the data line to attempt to slow the edge
down
- Re-route the clock on the board with wires so that the clock gets to
the downstream device sooner
- Spray the part with cold spray or heat up the device with hot air to
change the transistor characteristics just enough so that things
work...for a few seconds or minutes at best.

>
> Of course, now the outputs of my qep_sim() have 20ns of
> re-synchronization jitter relative to the 288kHz QEP "clock" input.
>
> This is Ok in this situation because there are no other data flows
> synchronous with the 288kHz that must interact with the output from the
> FPGA.
>
> But I can envision cases where this just can't be tolerated, and the
> FPGA must be configured to count, divide, etc. external clocks and
> produce outputs that are synchronous with the external clock.
>

In that situation you might use one of the other techniques that I
mentioned in your other posting:
- Replicate the logic, use the two clock inputs as real clocks and put
the mux on the back end outputs.
- Use a PLL that can switch over between multiple clock inputs

Which approach to use depends on what the actual conditions and
constraints you have to deal with in that situation.

> It seems the FPGA designers are focussed on a world of data interfaces
> where the one rule always applies. =A0

This isn't really limited to FPGAs.  Hark back to Digital Logic 101
class and recall that there are lots of ways to implement any logic
function:  memory devices, nand gates, nor gates, multiplexers.  Not
all approaches guarantee 'no glitch' performance.  What they guarantee
is that when the dust settles, the black box function appears to be
identical.

I'm not sure just what 'one rule' you're referring to, but the
important thing is that one must be somewhat aware of the actual
implementation and what pitfalls there can be with that type of
implementation so that one can avoid the pitfalls as best as possible.

> But what if sub-ns jitter pulse
> genration of frequency division relative to an external timebase is
> required? =A0 How to do that? =A0Can't be done unless you allow an isolat=
ed
> clock domain. =A0This is a common need in scientific experiments, pulse
> generators, laser control logic, etc.
>
> What am I to do with those problems, design discrete logic again?
>

Whether you need discrete logic would depend on the particular
problem, but the two approaches I mentioned earlier would likely
suffice for at least some of the problems.

>
> That said, certainly what I've gathered at this point is that for
> whatever clock is brought into the FPGA, that certainly shouldn't be
> gated or muxed, unless perhaps it's done with resources designed for
> that purpose, and there is comprehension on how to analyze the timing.
>

Then you've taken away the right lesson.

Kevin Jennings

Article: 151807
Subject: Re: Counter clocks on both edges sometimes, but not when different IO
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 18 May 2011 21:54:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 11:21=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
> Pete Fraser wrote:
> > Is there some requirement that FPGA coders
> > are also kayakers?
>
> > Pete Fraser
> > Looksha IV HV
>
> No, only that you can only ever use one clock. ;-)
>

Not true.  FPGAs implement dual clock FIFOs and memories just fine.

Kevin Jennings

Article: 151808
Subject: Re: How to use the EXT_CLK_P and EXT_CLK_N pins of Virtex II Pro
From: Pratap <pratap.iisc@gmail.com>
Date: Thu, 19 May 2011 09:26:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 5:24=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On May 18, 11:14=A0am, Pratap <pratap.i...@gmail.com> wrote:
>
>
>
> > On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote:
>
> > > Hi,
> > > I need to take out two square wave signals from the Virtex II Pro FPG=
A
> > > board(XC2VP30, package ff896) with good signal shape and less jitter
> > > value. The frequency of the two square wave signals are around 40MHz
> > > and one is the delayed version of the other. I am trying to evaluate
> > > the performance of a delay generator block inside the FPGA. Hence, th=
e
> > > shape and precision of the delays is of greater importance to me. I
> > > have tried to take the signals through various pins on the board
> > > including the high speed expansion connector. But I found that only
> > > when the signals are routed out through the EXT_CLK_P(G15) and
> > > EXT_CLK_N(F15) pins, the jitter performance is the best. But there is
> > > a funny thing happening when I observe the two waveforms on a scope.
> > > Below are the two cases. Looks like, when the signal levels of the tw=
o
> > > signals are different, the signal with ZERO logic goes up to around
> > > 0.2*Vsupply and at the same time the signal with logic '1' goes down
> > > by around 0.2Vsupply. Can anybody suggest how can I avoid such a
> > > situation? I feel there is some sort of resistor coupling between
> > > these two signals. But, can I =A0disable this coupling by changing so=
me
> > > setting in the ucf file? This is the entry in the ucf file
> > > corresponding to the two pins mentioned above.
>
> > > NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW =
=3D FAST |
> > > DRIVE =3D 12 ;
> > > #EXTERNAL_CLOCK_P=3DG15
>
> > > NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVTTL=
 | SLEW
> > > =3D FAST | DRIVE =3D 12 ;
> > > #EXTERNAL_CLOCK_N=3DF15
>
> > > Please suggest a way to set these signals such that the coupling
> > > between these two signals is nullified and I can use them as two true
> > > single ended outputs.
>
> > > Here is an illustration of the case.https://picasaweb.google.com/lh/w=
ebUpload?uname=3Dpratap.iisc&aid=3D56081...
>
> > > Waiting for some helpful answers.
> > > Thanks and regards,
> > > Pratap
>
> > Sorry...The link for the picture was wrogly pasted...Here is the
> > correct link.https://picasaweb.google.com/pratap.iisc/May182011?authkey=
=3DGv1sRgCMjQ...Hide quoted text -
>
> > - Show quoted text -
>
> Based on the names these are intended to be a differential pair. =A0This
> means that they have been routed close together on the board and will
> have intentional coupling/crosstalk between the two routed nets. =A0In
> addition there is likely a 100 ohm termination resistor between the
> two nets that is generating the bump that you are seeing.
>
> The resistor could be removed, you will need to check the schematics
> for you board to determine which one it is.
>
> The crosstalk however cannot be removed.
>
> Ed McGettigan
> --
> Xilinx Inc.

Thanks a lot McGettigan for the quick answer.
I checked the board again and found out that there was indeed an SMD
resistor soldered from the bottom side creating this impact. After
removing that resistor it looks nice. The crosstalk is not that much
as I am operating at around 40MHz. But one thing I am wandering is,
how only these two outputs are behaving so well where as none of the
other pins (even some pins taken from high speed expansion connector
J37) produce such clean and less jittery waveforms.

-Pratap

Article: 151809
Subject: Re: How to use the EXT_CLK_P and EXT_CLK_N pins of Virtex II Pro
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 19 May 2011 10:23:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 9:26=A0am, Pratap <pratap.i...@gmail.com> wrote:
> On May 19, 5:24=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On May 18, 11:14=A0am, Pratap <pratap.i...@gmail.com> wrote:
>
> > > On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote:
>
> > > > Hi,
> > > > I need to take out two square wave signals from the Virtex II Pro F=
PGA
> > > > board(XC2VP30, package ff896) with good signal shape and less jitte=
r
> > > > value. The frequency of the two square wave signals are around 40MH=
z
> > > > and one is the delayed version of the other. I am trying to evaluat=
e
> > > > the performance of a delay generator block inside the FPGA. Hence, =
the
> > > > shape and precision of the delays is of greater importance to me. I
> > > > have tried to take the signals through various pins on the board
> > > > including the high speed expansion connector. But I found that only
> > > > when the signals are routed out through the EXT_CLK_P(G15) and
> > > > EXT_CLK_N(F15) pins, the jitter performance is the best. But there =
is
> > > > a funny thing happening when I observe the two waveforms on a scope=
.
> > > > Below are the two cases. Looks like, when the signal levels of the =
two
> > > > signals are different, the signal with ZERO logic goes up to around
> > > > 0.2*Vsupply and at the same time the signal with logic '1' goes dow=
n
> > > > by around 0.2Vsupply. Can anybody suggest how can I avoid such a
> > > > situation? I feel there is some sort of resistor coupling between
> > > > these two signals. But, can I =A0disable this coupling by changing =
some
> > > > setting in the ucf file? This is the entry in the ucf file
> > > > corresponding to the two pins mentioned above.
>
> > > > NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW=
 =3D FAST |
> > > > DRIVE =3D 12 ;
> > > > #EXTERNAL_CLOCK_P=3DG15
>
> > > > NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVT=
TL | SLEW
> > > > =3D FAST | DRIVE =3D 12 ;
> > > > #EXTERNAL_CLOCK_N=3DF15
>
> > > > Please suggest a way to set these signals such that the coupling
> > > > between these two signals is nullified and I can use them as two tr=
ue
> > > > single ended outputs.
>
> > > > Here is an illustration of the case.https://picasaweb.google.com/lh=
/webUpload?uname=3Dpratap.iisc&aid=3D56081...
>
> > > > Waiting for some helpful answers.
> > > > Thanks and regards,
> > > > Pratap
>
> > > Sorry...The link for the picture was wrogly pasted...Here is the
> > > correct link.https://picasaweb.google.com/pratap.iisc/May182011?authk=
ey=3DGv1sRgCMjQ...quoted text -
>
> > > - Show quoted text -
>
> > Based on the names these are intended to be a differential pair. =A0Thi=
s
> > means that they have been routed close together on the board and will
> > have intentional coupling/crosstalk between the two routed nets. =A0In
> > addition there is likely a 100 ohm termination resistor between the
> > two nets that is generating the bump that you are seeing.
>
> > The resistor could be removed, you will need to check the schematics
> > for you board to determine which one it is.
>
> > The crosstalk however cannot be removed.
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Thanks a lot McGettigan for the quick answer.
> I checked the board again and found out that there was indeed an SMD
> resistor soldered from the bottom side creating this impact. After
> removing that resistor it looks nice. The crosstalk is not that much
> as I am operating at around 40MHz. But one thing I am wandering is,
> how only these two outputs are behaving so well where as none of the
> other pins (even some pins taken from high speed expansion connector
> J37) produce such clean and less jittery waveforms.
>
> -Pratap- Hide quoted text -
>
> - Show quoted text -

The most likely answer is that you are getting a good connection for
the scope probe and a bad one trying to connect to the other
connector.

Ed McGettigan
--
Xilinx Inc.

Article: 151810
Subject: Re: Scoping a glitch
From: "Andrew Holme" <ah@nospam.com>
Date: Thu, 19 May 2011 22:06:33 +0100
Links: << >>  << T >>  << A >>

>"KJ" <kkjennings@sbcglobal.net> wrote in message
>On May 18, 11:15 pm, "Mr.CRC" >wrote:
>> Nial Stewart wrote:
>> > Depending on your build, choice of pins etc this could be re-introduced 
>> > at
>> > any point.
>>
>> I find this less plausible than simply ground bounce. Although at the
>> same time, I find it very new to have a problem with a 30ns rise/fall.
>>
>> Can you explain a mechanism for such a race condition so I can think
>> about it better?
>
>FPGA logic is implemented with memory lookup tables.  Since your mux
>logic has two clock inputs that are presumably running at different
>frequencies there will be times when both of those inputs are changing
>*close* to the same time

I think KJ has spotted the problem.

Try using a BUFGMUX primitive instead of a LUT to MUX the clocks. 



Article: 151811
Subject: Re: Scoping a glitch
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Thu, 19 May 2011 20:36:23 -0700
Links: << >>  << T >>  << A >>
Andrew Holme wrote:
>> "KJ" <kkjennings@sbcglobal.net> wrote in message
>> On May 18, 11:15 pm, "Mr.CRC" >wrote:
>>> Nial Stewart wrote:
>>>> Depending on your build, choice of pins etc this could be re-introduced 
>>>> at
>>>> any point.
>>> I find this less plausible than simply ground bounce. Although at the
>>> same time, I find it very new to have a problem with a 30ns rise/fall.
>>>
>>> Can you explain a mechanism for such a race condition so I can think
>>> about it better?
>> FPGA logic is implemented with memory lookup tables.  Since your mux
>> logic has two clock inputs that are presumably running at different
>> frequencies there will be times when both of those inputs are changing
>> *close* to the same time
> 
> I think KJ has spotted the problem.
> 
> Try using a BUFGMUX primitive instead of a LUT to MUX the clocks. 

No, I don't think it's the mux glitching since it does it even with one
of the inputs constant.  I think I even removed the mux altogether and
it still had problems, until stiffening the source impedance.

I'm remaining convinced that it's ground bounce.

I tried a BUFGMUX and had a hell of a time with inability to implement
the design due to not being able to get the IO pins chosen to connect to
it.  I was using right side GCLKn inputs on a Spartan 3E 500k.

I'm happy with the independent edge detectors providing clock enables,
which are muxed prior to sending to the qep_sim() which now clocks of
the board clock at 50MHz.


Now I have to go rework some amateurish resettable clock dividers...


-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151812
Subject: Verify failed between address 0x80000 and 0x8FFFF
From: "harishac" <harishac@n_o_s_p_a_m.bel.co.in>
Date: Fri, 20 May 2011 06:17:02 -0500
Links: << >>  << T >>  << A >>
Hello,

I've been attempting to basically run through the mem_test template and
tutorial,on Cyclone® III EP3C120 chip board.

I am able to compile the custom SOPC design, the encompassing Quartus file,
download the SRAM Object File .sof to the board correctly, create the
Application from BSP and Template, and even build the file in NIOS II with
no errors. The problem comes about when I attempt to run the system; the
.elf downloads in its entirety , but then fails during verification.


Verifying 08000000 ( 0%)
Verify failed between address 0x80000 and 0x08FFFF
Leaving target processor paused.


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

Article: 151813
Subject: AVI container and VGA display
From: "tandt_53" <dothetan.040490@n_o_s_p_a_m.gmail.com>
Date: Fri, 20 May 2011 06:17:10 -0500
Links: << >>  << T >>  << A >>
hi all! 
I'm working on the Spartan 3E started with mapping MJPEG decoder. I had the
source code of the JPEG deccoding, now I use AVI container to display MJPEG
via VGA port. I wanna find the first image inside of AVI container but I
don't understand the AVI's structure. it has some index such as super
index, old index, ect. And I don't know how to display video into monitor
via VGA port. any body has idea for my problems? Please, help me!
thanks alot! 

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

Article: 151814
Subject: Re: Verify failed between address 0x80000 and 0x8FFFF
From: =?ISO-8859-2?Q?G=F3rski_Adam?= <gorskiamalpa@wpkropkapl>
Date: Fri, 20 May 2011 14:08:06 +0200
Links: << >>  << T >>  << A >>
Hello,

Do you have system ID included in your SOPC design ?

Adam
> Hello,
>
> I've been attempting to basically run through the mem_test template and
> tutorial,on Cyclone® III EP3C120 chip board.
>
> I am able to compile the custom SOPC design, the encompassing Quartus file,
> download the SRAM Object File .sof to the board correctly, create the
> Application from BSP and Template, and even build the file in NIOS II with
> no errors. The problem comes about when I attempt to run the system; the
> elf downloads in its entirety , but then fails during verification.
>
>
> Verifying 08000000 ( 0%)
> Verify failed between address 0x80000 and 0x08FFFF
> Leaving target processor paused.
>
>
> 	
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com


Article: 151815
Subject: Problem with xilinx 12.3 Timing Analyzer
From: "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com>
Date: Fri, 20 May 2011 11:56:01 -0500
Links: << >>  << T >>  << A >>
Hi,

I am using xilinx 12.3 for my synthesis and implementation. I am having
issues running timing analyzer, the problem is that when i run timing
analyzer from the ISE Design Tools menu as a stand alone application and
open my design with .ncd file, a message pops up and says "Design is missin
for open design. Please make sure design (.ncd) is opened". I have no idea
what it means as i am openeing the design according to the procedure i read
on some site.

 

Secondly, if i run it from within xilinx Project navigator-> Tools-> Timing
Analyzer->Post Place and Route, a message comes in console window at the
bottom saying

 

"Process "Analyze Post-Place & Route Static Timing" completed
successfully".

But i don't see timing analyzer running or anything.

 

Can anyone tell me how to make it work.

 

thanks

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

Article: 151816
Subject: Re: Scoping a glitch
From: rickman <gnuarm@gmail.com>
Date: Fri, 20 May 2011 13:29:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 11:15=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
> Nial Stewart wrote:
> >>> The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to
> >> connect to a research lab. =A0The output of the ISO (input to FPGA) at
> >> 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA
> >> header pin on the Digilent NEXYS2 board.
>
> > Then it's probably not a ground problem, especially if this is the only
> > input to the FPGA.

Nial,

I'm curious as to why you think this indicates it is not a ground
bounce problem?


> >>> If that falling edge is an input than at ~30ns it's shouldn't be what=
's causing
> >>> the problem unless you've got _terrible_ ground problems.
> >> Well if there are ground problems, they are out of my control, as this
> >> is the signal at the pin on the Digilent board. =A0I would expect them=
 to
> >> have done a competent job.
> >> I'm not sure, is there a history of people complaining about Digilent
> >> board signal integrity problems?
>
> > No, as above this almost definitely isn't a problem.

I don't follow.  A 30 ns rise time is slow compared to the pulse
widths the FFs will clock at.  The slow edge looks like a ramp and
with only a few tens of milivolts of ground noise imposed by the pins
and bond wires the voltage the internal input sees can glitch through
the threshold giving an unexpected clock edge.


> >>> This shows your design is still susceptible to asynchronous inputs to=
ggling.
> >> The important other fact is that if the drive impedance is made stiffe=
r
> >> (180->50ohms) and speed to the FPGA input increased (30->10ns) then th=
e
> >> glitches are no longer observed, even after an all night wait.
>
> > There could be a race condition internally which stops being a factor w=
hen
> > you speed up the inputs.
>
> > Depending on your build, choice of pins etc this could be re-introduced=
 at
> > any point.
>
> I find this less plausible than simply ground bounce. =A0Although at the
> same time, I find it very new to have a problem with a 30ns rise/fall.
>
> Can you explain a mechanism for such a race condition so I can think
> about it better?
>
> Regarding other things going on, there are the QEP outputs switching a
> few ns after the clock switches.

CRC,

So this is while the external clock is still slewing?  If they are
high current or a lot of them, it can cause a problem with a slow
clock input.

I would also like to hear the details of the race condition.


> There were several other asynchronous IOs going in and out, such as a
> 1MHz and 250kHz divided clock, coming from the 50MHz board clock (which
> is async vs. the 288kHz qep_sim() clock causing the trouble.
>
> > :-)
>
> Indeed.
>
> >>> Synchronise both(all) the inputs at the IO to the system clock then u=
se those
> >>> to look for falling or rising edges for your counter
> >> Yeah, tried that. =A0Works. =A0I think I have things under control, wi=
th two
> >> possible choices of path forward.
>
> > No, there's _only_ one path forward, synchronise your inputs.
>
> Well that's what I've changed it to and it worked fine the first time.
>
> > The input you're looking at is _reasonably_ fast, how fast is the inter=
nal clock
> > you're using to synchronise it? Ideally it'll be a good multiple (> 5) =
of this
> > clock.
>
> Well, the board clock is 50MHz. =A0That works fine. =A0Later I will
> experiment with sending that into the on chip DCM/PLL/DLL thingy and see
> what happens when I resync stuff at 100MHz, and 200MHz.
>
> Of course, now the outputs of my qep_sim() have 20ns of
> re-synchronization jitter relative to the 288kHz QEP "clock" input.
>
> This is Ok in this situation because there are no other data flows
> synchronous with the 288kHz that must interact with the output from the
> FPGA.
>
> But I can envision cases where this just can't be tolerated, and the
> FPGA must be configured to count, divide, etc. external clocks and
> produce outputs that are synchronous with the external clock.

The more I think about this the less I agree.  Logic always has
delays.  The only issue if if the delay is too much.  Then you need to
find a way to mitigate that delay or reduce it.  I can't remember a
design where I couldn't just clock signals at the interface if that
was what I wanted to do.


> It seems the FPGA designers are focussed on a world of data interfaces
> where the one rule always applies. =A0But what if sub-ns jitter pulse
> genration of frequency division relative to an external timebase is
> required? =A0 How to do that? =A0Can't be done unless you allow an isolat=
ed
> clock domain. =A0This is a common need in scientific experiments, pulse
> generators, laser control logic, etc.

I have to say I'm not sure what "sub-ns jitter pulse genration of
frequency division relative to an external timebase" is exactly.  So I
can't say what it requires in an FPGA.  But no one has said you can't
use multiple clock domains.  Your problem comes from a clock input
with an excessively slow rise/fall time.  One easy fix is to not use
it as a clock, but as a clock enable by detecting the edge with
another clock.  That effectively provides a low pass filter so the
fast glitches are removed.


> What am I to do with those problems, design discrete logic again?

How would discrete logic be any different than an FPGA?


> The whole point of an FPGA to me is that in a research environment, the
> requirements change constantly, so flexible logic on an inflexible PCB
> is necessary. =A0I take the expected needs today and say "oh they need a
> few counters and gates, so multiply that by 100-1000 and in a few years
> they will have chewed through half of the over-designed resources."
> That much time I don't have to re-spin the hardware PCBs. =A0I love PLDs!
> =A0Coupled with a decent CPU and one little platform can fill a thousand
> roles.

How is a PLD any different from an FPGA???  I'm very confused at this
point.


> That said, certainly what I've gathered at this point is that for
> whatever clock is brought into the FPGA, that certainly shouldn't be
> gated or muxed, unless perhaps it's done with resources designed for
> that purpose, and there is comprehension on how to analyze the timing.

Just to be clear running a clock through logic is not really an issue
for the clock.  The only reason it is a bad thing is if you are using
the multiplexed clock for data on an IO pin.  Then the internal delay
between the clock pin and the IO pin can be hard for the tools to
account for, mostly the variability in the delay.  The LookUp Table
(LUT) structure in FPGAs is not the same as a semiconductor memory and
is designed to not glitch from a single input changing state.  In the
case of a multiplexer, the clock input that is not selected never has
an impact on the output regardless of what the other clock is doing.
As long as that clock is being used in a way such that the delay is
not important, then it will not cause problems... providing the select
line is not changing when your downstream logic is enabled.  You don't
want to have splinter pulses on the clock mucking with your state
machines and counters.

If you think your problems here have anything to do with the fact that
you are using an FPGA, then you misunderstand what I have been telling
you.  I hope I haven't given you any wrong information.

Rick

Article: 151817
Subject: Re: Scoping a glitch
From: rickman <gnuarm@gmail.com>
Date: Fri, 20 May 2011 13:30:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 5:06=A0pm, "Andrew Holme" <a...@nospam.com> wrote:
> >"KJ" <kkjenni...@sbcglobal.net> wrote in message
> >On May 18, 11:15 pm, "Mr.CRC" >wrote:
> >> Nial Stewart wrote:
> >> > Depending on your build, choice of pins etc this could be re-introdu=
ced
> >> > at
> >> > any point.
>
> >> I find this less plausible than simply ground bounce. Although at the
> >> same time, I find it very new to have a problem with a 30ns rise/fall.
>
> >> Can you explain a mechanism for such a race condition so I can think
> >> about it better?
>
> >FPGA logic is implemented with memory lookup tables. =A0Since your mux
> >logic has two clock inputs that are presumably running at different
> >frequencies there will be times when both of those inputs are changing
> >*close* to the same time
>
> I think KJ has spotted the problem.
>
> Try using a BUFGMUX primitive instead of a LUT to MUX the clocks.

That would be a band aid, if it even works.  What makes you think this
is not noise in the ground connection imposing a spike on the slow
rise/fall time of the clock?

Rick

Article: 151818
Subject: Re: Scoping a glitch
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 20 May 2011 16:03:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 20, 4:29=A0pm, rickman <gnu...@gmail.com> wrote:
> On May 18, 11:15=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
>
> Just to be clear running a clock through logic is not really an issue
> for the clock.

This is not true.  If the memory implementing the logic has a couple
of inputs changing together a glitch can occur.  Based on what CRC
says this may not be his failure mode, but it is a failure caused by
"running a clock through logic".

> The only reason it is a bad thing is if you are using
> the multiplexed clock for data on an IO pin.

CRC's code does not clock in any data on an I/O pin...it simply clocks
a counter, all internal.  So saying 'The *only* reason...' is not
correct.

> The LookUp Table
> (LUT) structure in FPGAs is not the same as a semiconductor memory and
> is designed to not glitch from a single input changing state.

A plausible explanation though for the rogue clock edge that advanced
CRC's counter at the falling edge is that the LUT structure did glitch
as a result of a single input changing.  There are other plausible
explanations, my point is that I wouldn't rule out this as a
possiblity.

> In the
> case of a multiplexer, the clock input that is not selected never has
> an impact on the output regardless of what the other clock is doing.

Not true.  What about when both clocks happen to switch simultaneously
(or nearly so).  Now you'll have two of the three inputs to the LUT
switching.  Even if you were guaranteed no glitches with one input
changing, you're not guaranteed the same result with two.

Kevin Jennings

Article: 151819
Subject: Re: Scoping a glitch
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Fri, 20 May 2011 20:48:13 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> On May 18, 11:15 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
> wrote:
> CRC,
> 
> So this is while the external clock is still slewing?  If they are
> high current or a lot of them, it can cause a problem with a slow
> clock input.
> 
> I would also like to hear the details of the race condition.
>
>
>> There were several other asynchronous IOs going in and out, such as a
>> 1MHz and 250kHz divided clock, coming from the 50MHz board clock (which
>> is async vs. the 288kHz qep_sim() clock causing the trouble.

Well considering:
http://web.newsguy.com/crobcng/spartan3e/scope_12.png

The answer is "no" since the QEP output is switching *because* of the
erroneous count on the falling edge.  Ie., QEP output switching here is
effect, not cause.  So chalk this one up to my engaging mouth before
brain again.

What is going on is the asynchronous outputs from a pair of clock
dividers running off the board clock (which is async. to the QEP
mechanism) with outputs switching nearby to the troublemaker.

So a good experiment would be to scope those along with an incidence of
this glitch, and see if something else is actually observable switching
during the sensitive portion of the QEP clock edge.

But seriously, at this point this is all academic, because I have solved
the problem by following the good and applicable advice of everyone
here, by resynchronizing the QEP clock input and using the edge detects
as CEs.

>> Of course, now the outputs of my qep_sim() have 20ns of
>> re-synchronization jitter relative to the 288kHz QEP "clock" input.
>>
>> This is Ok in this situation because there are no other data flows
>> synchronous with the 288kHz that must interact with the output from the
>> FPGA.
>>
>> But I can envision cases where this just can't be tolerated, and the
>> FPGA must be configured to count, divide, etc. external clocks and
>> produce outputs that are synchronous with the external clock.
> 
> The more I think about this the less I agree.  Logic always has
> delays.  The only issue if if the delay is too much.  Then you need to
> find a way to mitigate that delay or reduce it.  I can't remember a
> design where I couldn't just clock signals at the interface if that
> was what I wanted to do.

Ok, but you do agree at this point that my QEP outputs now have 20ns of
jitter relative to the 288kHz signal which serves as their timebase, due
to the fact that the 288kHz has been re-synced to the board's 50MHz clock.

My point is simply that in the case where that 20ns of jitter is not
acceptable, then there would be two choices:

1.  resynchronize the external clock with a higher frequency FPGA clock
such that the synchronization jitter is within tolerable limits, or

2.  use the externally supplied clock directly, assuming that signal
integrity requirements were satisfied and that it was understood that
the logic driven by this clock constitutes a unique clock domain.


>> It seems the FPGA designers are focussed on a world of data interfaces
>> where the one rule always applies.  But what if sub-ns jitter pulse
>> genration of frequency division relative to an external timebase is
>> required?   How to do that?  Can't be done unless you allow an isolated
>> clock domain.  This is a common need in scientific experiments, pulse
>> generators, laser control logic, etc.
> 
> I have to say I'm not sure what "sub-ns jitter pulse genration of
> frequency division relative to an external timebase" is exactly.  So I
> can't say what it requires in an FPGA.

Simply taking in a clock, dividing it by N and spitting out the result.
 Or using an external clock as the timebase to generate pulses of N
counts of that clock.

These are cases where synchronization jitter might not be tolerable,
precisely because it is necessary that the result signals must remain
*in* the clock domain of the external clock.  Yes there will be delay,
but delay is delay, and jitter is jitter.  The delay in this case would
be understood.

>  But no one has said you can't
> use multiple clock domains.

Yes.  And so there is no disagreement.


>  Your problem comes from a clock input
> with an excessively slow rise/fall time.  One easy fix is to not use
> it as a clock, but as a clock enable by detecting the edge with
> another clock.  That effectively provides a low pass filter so the
> fast glitches are removed.

Yes.  Please recognize that sometimes I speak generally.  Most of the
past few iterations of this discussion have been about generality, not
the original problem, which is solved and understood pretty well I think.


>> What am I to do with those problems, design discrete logic again?
> 
> How would discrete logic be any different than an FPGA?

Well for one thing, it is composed of actual gates rather than LUTs, so
one can actually prove correctness of asynchronous designs if one
desires.  Where, that seems to be impossible with LUTs.

>> The whole point of an FPGA to me is that in a research environment, the
>> requirements change constantly, so flexible logic on an inflexible PCB
>> is necessary.  I take the expected needs today and say "oh they need a
>> few counters and gates, so multiply that by 100-1000 and in a few years
>> they will have chewed through half of the over-designed resources."
>> That much time I don't have to re-spin the hardware PCBs.  I love PLDs!
>>  Coupled with a decent CPU and one little platform can fill a thousand
>> roles.
> 
> How is a PLD any different from an FPGA???  I'm very confused at this
> point.

Just speaking generally again.  I use the term "PLD" to mean the overall
category of programmable logic devices that includes PALs, GALs (both
mostly obsolete for my purposes) and more importantly CPLDs and FPGAs.


>> That said, certainly what I've gathered at this point is that for
>> whatever clock is brought into the FPGA, that certainly shouldn't be
>> gated or muxed, unless perhaps it's done with resources designed for
>> that purpose, and there is comprehension on how to analyze the timing.
> 
> Just to be clear running a clock through logic is not really an issue
> for the clock.  The only reason it is a bad thing is if you are using
> the multiplexed clock for data on an IO pin.  Then the internal delay
> between the clock pin and the IO pin can be hard for the tools to
> account for, mostly the variability in the delay. 

Key point.  Got it many times over!

> The LookUp Table
> (LUT) structure in FPGAs is not the same as a semiconductor memory and
> is designed to not glitch from a single input changing state. 

Key point, of a more subtle variety.  I've got it, but am still working
on a full understanding of this.  I think another post is in order.

> In the
> case of a multiplexer, the clock input that is not selected never has
> an impact on the output regardless of what the other clock is doing.

That would be in the case of a "glitch-free mux."  I will make a new
post about this.

> As long as that clock is being used in a way such that the delay is
> not important, then it will not cause problems... providing the select
> line is not changing when your downstream logic is enabled.  You don't
> want to have splinter pulses on the clock mucking with your state
> machines and counters.

Yes!

> If you think your problems here have anything to do with the fact that
> you are using an FPGA, then you misunderstand what I have been telling
> you.  I hope I haven't given you any wrong information.
> 
> Rick

The only thing different about my FPGA is the fact that it is capable of
operating at frequencies several times higher than what I've dealt with
before.

Don't worry so much.  Your input has been especially helpful, and I
think you are the one who's on target re: the real cause of my
glitch--ground bounce rather than the mux glitching.  I'm pretty sure
this is proved at this point by the various observations that have been
made so far.

One nice thing about this group is that people have a much more
professional demeanor than at certain other less civil neighborhoods
(cough, cough, SED, cough cough).

I really appreciate this.  I want to be able to have my kid peek over my
shoulder and not feel shame at the behavior of otherwise highly
intelligent folks.

Thanks to all!

I'll be back with more fun logic silliness in the future...


-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151820
Subject: Can a glitch-free mux be designed in an FPGA?
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Fri, 20 May 2011 21:18:07 -0700
Links: << >>  << T >>  << A >>
Hi:

The simplest incarnation of a 2-to-1 multiplexer can be described by the
equation:

y = ~s & a | s & b

where 'y' is the output, 's' is the select input, with 'a' and 'b' the
data inputs.

Of course, this multiplexer is broken because a practical implementation
 glitches in a if 'a' and 'b' are true, and the select line toggles.
Such as this example from the book (1):
-----------------------------------------
module mux21g (
    input wire a,
    input wire b,
    input wire s,
    output wire y
);

wire _s;
wire c, d;

assign #10 _s = ~s;
assign #10 c = _s & a;
assign #10 d = s & b;
assign #10 y = c | d;
------------------------------------

The fix for the glitching is of course to implement an extra term
(Verilog not shown, but I think we can all handle it):

y = ~s & a | s & b | a & b


So the big questions are:

1.  What happens (ie., synthesizes) when you implement these equations
in an FPGA?

1a.  What synthesizes if you do:

assign y = ~s & a | s & b; // ???

1b.  What synthesizes if you code the corrected mux equation:

assign y = ~s & a | s & b | a & b; // ???

1c.  Is there any difference in the synthesis if you code it one bitwise
operation at a time, like the module above, vs. all in one equation?

1d. If you "infer" a mux using the code shown in the vendor's device
library, then do you get a good mux, or a glitchy mux?


In the case of a CPLD, I would expect that I could implement the fixed
mux if I selected suitable synthesis properties, such as "mux
extraction" (which I think recognizes my intent to create a mux, perhaps
whether I code it glitch free or not, and implements a correct mux--can
any tool experts clarify?) and/or "wysiwyg" which will probably even
implement the bad mux if I so choose.

But the FPGA with its LUTs is a different ball of wax.

I will be extremely interested to hear what the experts make of these
questions.


I think that it is possible, though I don't yet know how, to see the
"RTL" output by the synth?  Are the answers to my questions to be found
there?

Then there are pre-synthesis and post-synthesis (or is it pre and post
fitting?) simulation models, etc., and whew!  There are quite a few
things I haven't delved into yet.


Have a nice weekend!


(1) "Learning by Example using Verilog ..." Richard Haskell, et.al. pg. 78.


Disclaimer -- none of the above is intended to imply that one should
ever route a clock through logic such as a mux!


-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151821
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 21 May 2011 07:52:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mr.CRC <crobcBOGUS@removethissbcglobal.net> wrote:
 
> The simplest incarnation of a 2-to-1 multiplexer can be 
> described by the equation:
 
> y = ~s & a | s & b
 
> where 'y' is the output, 's' is the select input, with 'a' and 'b' the
> data inputs.
 
> Of course, this multiplexer is broken because a practical implementation
> glitches in a if 'a' and 'b' are true, and the select line toggles.

(snip)
> The fix for the glitching is of course to implement an extra term
> (Verilog not shown, but I think we can all handle it):
 
> y = ~s & a | s & b | a & b

As I understand it, the FPGA LUTs are designed not to glitch
in just this condition.  The exact implementation I don't know,
but they should not glitch in the cases where a combination of
gates that the LUT represents would not glitch.

-- glen

Article: 151822
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: "Andrew Holme" <ah@nospam.com>
Date: Sat, 21 May 2011 09:57:15 +0100
Links: << >>  << T >>  << A >>

"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message 
news:ir7ee102lrc@news6.newsguy.com...
> 1a.  What synthesizes if you do:
> assign y = ~s & a | s & b; // ???
> 1b.  What synthesizes if you code the corrected mux equation:
> assign y = ~s & a | s & b | a & b; // ???

They both synthesize to the same thing: a function of 3 inputs, which is 
implemented as a single LUT.

According to Peter Alfke, Xilinx LUTs do not glitch if only a single input 
changes at a time.

> I think that it is possible, though I don't yet know how, to see the
> "RTL" output by the synth?  Are the answers to my questions to be found
> there?

You can view a post-synthesis schematic and you can examine the final output 
using FPGA Editor.



Article: 151823
Subject: Re: Can a glitch-free mux be designed in an FPGA?
From: KJ <kkjennings@sbcglobal.net>
Date: Sat, 21 May 2011 06:16:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 21, 12:18=A0am, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
>
> The fix for the glitching is of course to implement an extra term
> (Verilog not shown, but I think we can all handle it):
>
> y =3D ~s & a | s & b | a & b
>
> So the big questions are:
>
> 1. =A0What happens (ie., synthesizes) when you implement these equations
> in an FPGA?
>

Redundant logic terms do not get synthesized.  If you add them to the
source, they will get stripped out of the result.

Kevin Jennings

Article: 151824
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: wzab <wzab01@gmail.com>
Date: Sat, 21 May 2011 06:57:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 19, 4:46=A0am, rickman <gnu...@gmail.com> wrote:

> Sounds like you will be doing what I would like to be doing. =A0I have
> my own dual stack CPU design intended to run Forth. =A0I have only used
> Forth as a sort of macro assembler for it and with no more work that
> needs such a CPU it has sat for a number of years with no further
> development.
>
> I have considered a couple of alternatives for adding proper software
> development support for an embedded processor. =A0One is using open
> source software such as Riscy Pygness. =A0The other is working from a
> commercial package such as MPE Forth. =A0From my perspective a
> commercial package has lot of benefits which include a wide software
> base that conceivably could be available to support complex projects.
> The down side is that the use of the processor would be limited to
> owners of the commercial tool.
>
> The advantage of an open source tool is that it is available for
> anyone to work with and to work on. =A0But you start with a lot less
> capability.
>

I definitely prefer to use the open source approach (if I'm only
allowed to ;-) - sometimes I'm bound by conditions set for the
whole design, which do not allow me to publish it).

> How do you plan to proceed? =A0I assume you are looking for some initial
> capability that will let you compile code to machine instructions,
> download those instructions to the target and then interact with the
> target for debugging. =A0Do you look for anything more?
>

Well, unfortunately this a rather low priority project for me, which
I'm
doing only in my spare time.
In fact all I need at the moment is a possibility to define new words
for J1.

It could be done in a "Riscy Pygness" way, but then the tool
running on the host (corresponding to riscy.tcl in RP) should
record all the interactive session to allow further analysis, and
extraction
of best performing words defined during the session.

Wojtek



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