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 56100

Article: 56100
Subject: Re: FIFO Controller
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 29 May 2003 09:02:47 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> I am looking at revamping the FIFO cores, giving you many options:
> asynchr. vs synchronous, with exact empty and full
> extra one-clock-early empty and full indicators

Interesting - this would allow a smaller fifo for 
continual streaming output ?

> programmable almost empty and full indicators,
> readable occupied size ,
> etc
> Any additional suggestions?

 Newer UART fifos have a WDOG type feature, where a montostable timer
(runs at some multiple character time), generates an interrupt
if ever bytes are 'left in the FIFO', but under the interrupt threshold.
 Allows a fully interrupt design, and avoids separate polling to
check for remnant data, which might be a noise side-effect.

 -jg

Article: 56101
Subject: Re: 5v TTL to 3.3v 2.5v 1.8v 1.2v LVTTL solution
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 29 May 2003 09:14:49 +1200
Links: << >>  << T >>  << A >>
Amontec Team wrote:
> 
> Hi all,
> 
> I have to find the best solution to do a TTL level converter.
> I have to convert 5v <-> 3.3v 2.5v 1.8v 1.2v.
> 
> I have an external Vref signal for the second part.
> I have some bidirectional signal :-(
> 
> The shem would be some think like this:
> 
>                      Ĥ-------------Ĥ
>                      Ĥ             +<----- Vref from 1.2v to 3.3v
>                      Ĥ             Ĥ
>                      Ĥ  TTL level  Ĥ
> 5v TTL signals <--->+ converter   +<----> 1.2v to 3.3v LVTTL signals
>                      Ĥ-------------Ĥ       depending on Vref
> 
> Which solutions to do that?
> Is there any device to do that?

The wider spec LVDS devices should be good for this.
They are effectively (very) fast comparitors designed for digital use, 
and come in a range of voltages and widths.

-jg

Article: 56102
Subject: Re: FIFO Controller
From: "Pete Fraser" <pete@rgb.com>
Date: Wed, 28 May 2003 14:24:29 -0700
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3ED51C5D.3B8A1565@xilinx.com...
> I am looking at revamping the FIFO cores, giving you many options:
> asynchr. vs synchronous, with exact empty and full
> extra one-clock-early empty and full indicators
> programmable almost empty and full indicators,
> readable occupied size ,
> etc
> Any additional suggestions?

Like the old NEC uPD42101.

In clock, in enable, in reset (synchronous).
Out clock, out enable, out reset (synchronous).
Contents can be read multiple times



Article: 56103
Subject: Re: 5v TTL to 3.3v 2.5v 1.8v 1.2v LVTTL solution
From: Amontec Team <laurent.gauch@DELALLCAPSamontec.com>
Date: Wed, 28 May 2003 23:28:26 +0200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Amontec Team wrote:
> 
>>Hi all,
>>
>>I have to find the best solution to do a TTL level converter.
>>I have to convert 5v <-> 3.3v 2.5v 1.8v 1.2v.
>>
>>I have an external Vref signal for the second part.
>>I have some bidirectional signal :-(
>>
>>The shem would be some think like this:
>>
>>                     Ĥ-------------Ĥ
>>                     Ĥ             +<----- Vref from 1.2v to 3.3v
>>                     Ĥ             Ĥ
>>                     Ĥ  TTL level  Ĥ
>>5v TTL signals <--->+ converter   +<----> 1.2v to 3.3v LVTTL signals
>>                     Ĥ-------------Ĥ       depending on Vref
>>
>>Which solutions to do that?
>>Is there any device to do that?
> 
> 
> The wider spec LVDS devices should be good for this.
> They are effectively (very) fast comparitors designed for digital use, 
> and come in a range of voltages and widths.
> 
> -jg

Have you some good www entry points ?


Article: 56104
Subject: Re: 5v TTL to 3.3v 2.5v 1.8v 1.2v LVTTL solution
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 29 May 2003 09:32:12 +1200
Links: << >>  << T >>  << A >>
Amontec Team wrote:
> 
> Jim Granville wrote:
> 
> > Amontec Team wrote:
> >
> >>Hi all,
> >>
> >>I have to find the best solution to do a TTL level converter.
> >>I have to convert 5v <-> 3.3v 2.5v 1.8v 1.2v.
> >>
> >>I have an external Vref signal for the second part.
> >>I have some bidirectional signal :-(
> >>
> >>The shem would be some think like this:
> >>
> >>                     Ĥ-------------Ĥ
> >>                     Ĥ             +<----- Vref from 1.2v to 3.3v
> >>                     Ĥ             Ĥ
> >>                     Ĥ  TTL level  Ĥ
> >>5v TTL signals <--->+ converter   +<----> 1.2v to 3.3v LVTTL signals
> >>                     Ĥ-------------Ĥ       depending on Vref
> >>
> >>Which solutions to do that?
> >>Is there any device to do that?
> >
> >
> > The wider spec LVDS devices should be good for this.
> > They are effectively (very) fast comparitors designed for digital use,
> > and come in a range of voltages and widths.
> >
> > -jg
> 
> Have you some good www entry points ?

http://www.national.com/parametric/0,1850,1624,00.html

http://www.fairchildsemi.com/products/interface/lvds.html

there are quite a few LVDS players, so it's quite a well resourced
field.

-jg

Article: 56105
Subject: Re: JTAG madness
From: "Charles Krinke" <someone@pacbell.net>
Date: Wed, 28 May 2003 21:36:54 GMT
Links: << >>  << T >>  << A >>
Gee, and I thought it had something to do with trying to ensure that
companies that manufacture drills made a profit.

"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhbrxm24a3.fsf@ruckus.brouhaha.com...
> Keith R. Williams <krw@btv.ibm.com> writes:
> > Why do you think pads and vias are round. ;-)
>
> Because donuts are so tasty?



Article: 56106
Subject: Re: New Xilinx PROMs
From: "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it>
Date: Wed, 28 May 2003 22:16:33 GMT
Links: << >>  << T >>  << A >>
"Robert" <rpudlik@poczta.onet.pl> ha scritto nel messaggio
news:3ED4C3FC.10006@poczta.onet.pl...

> Does anyone knows when new Xilinx serial PROMs (e.g
> XCF02S) will be
> available? I don't see them at distributors yet.

XCF01S and XCF02S are already available, either as "engineering samples"
and normal parts. At least this is what my Xilinx distributor (from
Avnet Silica) told me, but I still haven't any samples.

The prices are around 3 euro for '01 and 7 euro for '02.

-- 
Lorenzo



Article: 56107
Subject: Re: JTAG madness
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 May 2003 18:36:41 -0400
Links: << >>  << T >>  << A >>
Magnus Homann wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> 
> > I am finding JTAG to be a major hassle to try to use for both debug and
> > production boundary scan.  Seems there are conflicting requirements
> > which the two camps are not generally interested in dealing with.
> 
> RISCTrace/Watch from IBM used to have the same issues. We had the
> PowerPC in the middle of the chain.
> 
> If I remember correctly we (i.e. my colleague) solved this by:
> 
> 1) connecting all TMS and TCK in parallel.
> 
> 2) rotuing TDI/O from part A to connector X to part P and split to
>    connector X and part B (see fig).
> 
> 3) When debugging, connector was used so that only part P was in the
>    chain. Pullups on TDI for other parts kept them out of trouble.
> 
> 4) When tetsing for production, connector was used so that the entire
>    chain was used (strap in X to connect TDo of A with TDI on P).
> 
> 5) The last part could also be achieved with resistor.
> 
> The issue with long stubs on TDI/O we didn't think mattered,
> considering it's a synchronous system with a failry low system clock. TCK on the other hand was routed as a long clock winding to all parts and ending in a Thevenin termination.
> 
> All this from memory, if it doesn't work, blame someone else.
> 
> (fig 1)
> 
>   |--------|         |--------|     |--------|
> --| part A |--|   |--| part P |-----| part B |---
>   |--------|  |   |  |--------|  |  |--------|
>               |   |              |
>               |   |              |
>             |----------------------|
>             | connector X          |
>             |----------------------|

I like most of what you said, but I don't think you can *debug* the
board with all the TMS and TCK signals in parallel.  This would send the
same instructions to all devices and put them in a possibly poor state
for normal operation when you only intended to be controlling part P.  I
expect to have to use jumpers to disable the TRST, TMS or TCK inputs on
all parts other than P.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56108
Subject: Re: JTAG madness
From: "Brett Foster" <custserv@forums.ws>
Date: Wed, 28 May 2003 19:09:51 -0400
Links: << >>  << T >>  << A >>
It was early. I wasn't in my right mind! And I replied on the wrong thread.
;) But alas it's not important now because well I'm tired again.

"Jerry Avins" <jya@ieee.org> wrote in message
news:3ED4EE8D.7B729A22@ieee.org...
> Brett Foster wrote:
> >
> > Well this was actually meant for the serious posters silly.
> >
> > "Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message
> > news:bb29ag$q5u$1@nets3.rz.RWTH-Aachen.DE...
> > > In comp.arch.embedded Brett Foster <custserv@forums.ws> wrote:
> > > > I thought this was largely disproven. Or at least the effect rather
> > minimal
> > > > (negligible).
> > >
> > > Depends on what kind of "trace" you're talking about. ;-P
> > >
> > > If it happens to be a proper race track for electrons, a.k.a.
> > > high-energy particle accelerator, you'll have a rather "interesting"
> > > time trying to survive standing on the outside of any of its curved
> > > segments without heavy shielding in between.  Kids: please _don't_ try
> > > this at home!
> > > --
> > > Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
> > > Even if all the snow were burnt, ashes would remain.
>
> Come, now! CBFalconer's remark was a joke in the first place. Injury?
> Smiley!
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
> ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ



Article: 56109
Subject: Re: Moore Vs Mealy machine ..
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 28 May 2003 16:12:48 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> Eric Bohlman wrote:
> 
>>Spam Hater <spam_hater_7@email.com> wrote in
>>news:jve7cvgldg4va3thk6pbubq18rjuh07van@4ax.com:
>>
>>>I always forget which one is which, but I prefer the one where the
>>>outputs come directly from the flops.  And yes, it's a -personal-
>>>bias.
>>
>>That's true of a correct implementation of either model.  In a Mealy
>>machine, the output at time t+1 is a function of both the current state at
>>time t and the input at time t.  In a Moore machine, the output is a
>>function of the current state only.  Some people implement Mealy machines
>>sloppily, with the output being a *combinatorial* function of the current
>>state and the input, but that's not an inherent characteristic of the
>>model.
> 
> Actually, that is not the "sloppy" Mealy machine, it is the literal
> Mealy machine.  If you register the outputs in a Mealy machine so that
> the outputs are a function of the previous inputs and state, you have
> simply converted your machine to a Moore machine while leaving the
> outputs out of the state description.  But it is still a Moore machine.

See the state machine example elsewhere in this thread with output ACK.
The output is registered in each case.
The timing is the same in each case.
The trick is that an output register can combine either the D or Q side of the 
state register.

     -- Mike Treseler



Article: 56110
Subject: Re: JTAG madness
From: eric.jacobsen@ieee.org (Eric Jacobsen)
Date: Wed, 28 May 2003 23:37:54 GMT
Links: << >>  << T >>  << A >>
On Tue, 27 May 2003 23:52:22 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Brett Foster wrote:
>> "Mike Rosing" <rosing@neurophys.wisc.edu> wrote in message
>> >
>> > The short stubs are important, and the traces shouldn't have
>> > any sharp angles - you want a really clean signal all around. 
>> > I assume you've got ground planes and not a 2 layer board? 
>> > That'll help a lot too.
>> 
>> Why no sharp angles?
>
>Those electrons are moving at an appreciable fraction of the speed
>of light, and tend to oversteer.  The rear end breaks loose going
>around those corners, and they are likely to go straight through
>the wall and injure somthing. :-)

Nothing softer rear springs and bigger front swaybars won't cure.
They just have to be really, really small.


Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org

Article: 56111
Subject: Re: JTAG madness
From: eric.jacobsen@ieee.org (Eric Jacobsen)
Date: Wed, 28 May 2003 23:41:02 GMT
Links: << >>  << T >>  << A >>
It's weird, though, even when the drill bit is square the hole comes
out round!

I always figure that's why vias are round, so the manholes don't fall
though them...

...I think.  If I don't think, am I not?

I'd better stop now.

On Wed, 28 May 2003 21:36:54 GMT, "Charles Krinke"
<someone@pacbell.net> wrote:

>Gee, and I thought it had something to do with trying to ensure that
>companies that manufacture drills made a profit.
>
>"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
>news:qhbrxm24a3.fsf@ruckus.brouhaha.com...
>> Keith R. Williams <krw@btv.ibm.com> writes:
>> > Why do you think pads and vias are round. ;-)
>>
>> Because donuts are so tasty?
>
>

Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org

Article: 56112
Subject: need help on sending 500Mbit/s data through 100 feet of cable, Giga-Ethernet?
From: ospyng@yahoo.com (spyng)
Date: 28 May 2003 16:49:07 -0700
Links: << >>  << T >>  << A >>
hi all,
need some help on this,

need to send about 500Mbit/s of data(images) between our equipment 100
ft (30 meter ) apart. we have rule out USB 2.0 and Firewire, because
of the distance. both are about 5 meter per segment (as I understand).
so we are thinking of using Gigabit Ethernet, just the phy if
possible. I am not too familiar with the Gigabit Ethernet, so here is
the question

1) how difficult to create a custom-built interface in Xilinx Virtex
II to GMII or TBI, just to transfer data? any pointer, link , that I
could read about the GMII? I try google, but most of them is talking
about interfacing with the MAC. not much on the protocol of GMII.

2) or must we use a MAC and implement TCP/IP stack? we trying to avoid
that.

3) we are looking at LVDS too, National claim to be able to drive
300meter of cable with an Adjustable Output cable driver CLC001, any
one have experience with it ?

any comments,link, pointer are welcome. thanks
pyng

Article: 56113
Subject: Re: why xflow?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 29 May 2003 10:02:55 +1000
Links: << >>  << T >>  << A >>
Alfredo wrote:
> Hi,
> I've been experimenting with xflow, but I still do not see why I would
> use it instead of a makefile, or within a script (c-shell, tcl, perl,
> etc.)
> 
> It is hard to tell from Xilinx's documentation what the value of xflow
> is. But for one thing, it seems to be used in the edk environment to
> automate the build process.
> 
> Any comments?

As best I can tell xflow doesn't work properly under Linux/Wine either - 
the rest of the synthesis tools do (not libgen or platgen for EDK though).

xflow doesn't seem to get a lot of use though - it seems many people 
just do as you suggest and script things themselves.

I use it to generate scripts (the -norun option produces equivalent .bat 
and .tcl scripts) which I then run from within my own scripts.

John


Article: 56114
Subject: Re: JTAG madness
From: Jerry Avins <jya@ieee.org>
Date: Wed, 28 May 2003 20:30:32 -0400
Links: << >>  << T >>  << A >>
Eric Jacobsen wrote:
> 
> It's weird, though, even when the drill bit is square the hole comes
> out round!

I use three-sided bits to drill square holes. I make mine from worn out
three-square* files, but you can buy them. 

http://www.integerspin.co.uk/polygon.htm

  ...

Jerry
______________________
* A stupid name I didn't make up.
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Article: 56115
Subject: Re: JTAG madness
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Wed, 28 May 2003 17:35:34 -0700
Links: << >>  << T >>  << A >>
On Wed, 28 May 2003 15:36:41 -0700, rickman wrote:

> Magnus Homann wrote:
>> 
>> rickman <spamgoeshere4@yahoo.com> writes:
>> 
>> > I am finding JTAG to be a major hassle to try to use for both debug
>> > and production boundary scan.  Seems there are conflicting
>> > requirements which the two camps are not generally interested in
>> > dealing with.
>> 
>> RISCTrace/Watch from IBM used to have the same issues. We had the
>> PowerPC in the middle of the chain.
>> 
>> If I remember correctly we (i.e. my colleague) solved this by:
>> 
>> 1) connecting all TMS and TCK in parallel.
>> 
>> 2) rotuing TDI/O from part A to connector X to part P and split to
>>    connector X and part B (see fig).
>> 
>> 3) When debugging, connector was used so that only part P was in the
>>    chain. Pullups on TDI for other parts kept them out of trouble.
>> 
>> 4) When tetsing for production, connector was used so that the entire
>>    chain was used (strap in X to connect TDo of A with TDI on P).
>> 
>> 5) The last part could also be achieved with resistor.
>> 
>> The issue with long stubs on TDI/O we didn't think mattered,
>> considering it's a synchronous system with a failry low system clock.
>> TCK on the other hand was routed as a long clock winding to all parts
>> and ending in a Thevenin termination.
>> 
>> All this from memory, if it doesn't work, blame someone else.
>> 
>> (fig 1)
>> 
>>   |--------|         |--------|     |--------|
>> --| part A |--|   |--| part P |-----| part B |---
>>   |--------|  |   |  |--------|  |  |--------|
>>               |   |              |
>>               |   |              |
>>             |----------------------|
>>             | connector X          |
>>             |----------------------|
> 
> I like most of what you said, but I don't think you can *debug* the
> board with all the TMS and TCK signals in parallel.  This would send the
> same instructions to all devices and put them in a possibly poor state
> for normal operation when you only intended to be controlling part P.  I
> expect to have to use jumpers to disable the TRST, TMS or TCK inputs on
> all parts other than P.
 
Should be no problem, all non-tested parts would first be put in bypass
mode, (instructions come from TDI, not TMS)

Whether the software you have will DTRT is another question...


PCW

Article: 56116
Subject: An FPGA is flying to Mars
From: reconfigurable_logic@yahoo.com (Mike Butts)
Date: 28 May 2003 18:38:26 -0700
Links: << >>  << T >>  << A >>
The May 2003 issue of IEEE Spectrum has a nifty and
detailed article on the exciting British Beagle 2
lander hitching a ride on ESA's Mars Express orbiter,
set to launch soon and arrive in December.  

Its robotic arm carries a bunch of instruments and
other devices.  "Discrete electronic interfaces
between each instrument and the lander would have
been complex to build and heavy as well.  So the 
PAW uses a single interface with a field-programmable
gate array that can reconfigure itself to match each
instrument's needs."

Excellent!  One of you must be able to tell us more.
Who's the clever designer?  Who's the lucky vendor?  
What device?  Rad-hard?  Fault-tolerant?  Designed 
in what language?  Verified how?  Bitstreams stored 
where and loaded by what?  Can they upload new 
bitstreams from Earth?  (Now that's an UPload!)
What if DONE doesn't go high?

Will this be the first FPGA in Mars space?

Most important of all, will they send a paper to
FPL 2003 or FPGA 2004 or FCCM 2004?

  --Mike

Article: 56117
Subject: Re: JTAG madness
From: Mike Rosing <rosing@neurophys.wisc.edu>
Date: Wed, 28 May 2003 21:27:36 -0500
Links: << >>  << T >>  << A >>
Keith Larson wrote:
> Hi Rick
> 
> The #1 challenge I can think of is to ensure a clean TCLK.  Basically 
> TCLK is used to sample all of the other signals and as long as those are 
> stable when TCLK transistions (cleanly), all should be well.
> 
> The underlying tricks that I can think of are...
> 
> 1) Routing a clean TCLK to all devices simultaneosly.  A bad example 

[...]

> 2) Do not push the TCLK rate so high that the setup and hold times are 
> violated.  That is, resulting in clean and stable signals at the time of 
> the (clean) TCLK edge.

[...]

That's really the bottom line, make TCLK clean and most all other problems
are gone.

> You will note however that the JTAG header pinout is *not* the same, nor 
> can it be considering what it does.  This makes swapping in and out 
> other vendors JTAG tools a pain in the butt, because you would need to 
> create header adapters.  Simple, but I dont see any other way except to 
> isolate the various JTAG chains.
> 
> Maybe someone could comment on the standardization of the JTAG test port 
>  header (there might not be one?).

I don't see how.  ADI has one EMU line and TI has 2.  The other signals are
standard, but the order at the header is arbitrary.  It's even worse than
the RS-232 "standard", you have lots of choices :-)

You can have one header for standard i/o pin testing and one header for
debugging, just use a switch to select the operation being performed.  But
if the debug tool knows how to read bsdl files, it should be able to pass
the info thru all the chips in the chain correctly.  I suspect it would
really screw up the timing on the EMUx lines in a multi processor board
if you alternated cpld's with dsp's tho.

Patience, persistence, truth,
Dr. mike


-- 
Mike Rosing
www.beastrider.com                   BeastRider, LLC
SHARC debug tools


Article: 56118
Subject: Re: Multiply 19.44MHz with Virtex-II DCM
From: "Jay" <yuhaiwen@hotmail.com>
Date: Thu, 29 May 2003 10:48:36 +0800
Links: << >>  << T >>  << A >>
Yes, I'v thought about the frequency doubler.
But what I'm afraid of is: would any delay be introduced between fin and
fout, for there is no guarantee of de-skew.
Anyway, I would use it as "a tool of last resort".

"Austin Lesea" <Austin.Lesea@xilinx.com>
??????:3ED4C5C4.CCA011EA@xilinx.com...
> Yes,
>
> One can put the input through a simple frequency doubler (see Peter's
> circuit tricks Xclusive), and then into the input.  This gets the
> frequency down to 12 MHz for the DLL.  One then uses the duty cycle
> correction ON (to help fix the asymmetry of the doubled clock).  Since
> taps are updated every 6 times the 2's complement of the jitter filter
> settings, the asymmetry of the doubled clock does not violate the input
> jitter specification.
>
> Haven't tried this, but there is no reason why it shouldn't work.  If
> anyone has it working, let us know.
>
> Austin
>
> Heavenfish wrote:
> >
> > So my question is if there any alternate way to implement both DLL and
DFS
> > function when my input clk is less than 24MHz?
> > or I have to change my application.
> >
> > "Austin Lesea" <Austin.Lesea@xilinx.com>
> > ??????:3ED3C590.F0C93004@xilinx.com...
> > > Jon,
> > >
> > > The DCM CLKFX feature works down to a 1 MHz input frequency (as long
as
> > > the output being synthesized is greater than 24 MHz).
> > >
> > > Note that you can not use "sync to DLL" (ie connect CLK0 to CLKFB) in
> > > this mode (DFS only mode).
> > >
> > > Austin



Article: 56119
Subject: Re: Moore Vs Mealy machine ..
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 May 2003 23:08:42 -0400
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> 
> rickman wrote:
> > Eric Bohlman wrote:
> >
> >>Spam Hater <spam_hater_7@email.com> wrote in
> >>news:jve7cvgldg4va3thk6pbubq18rjuh07van@4ax.com:
> >>
> >>>I always forget which one is which, but I prefer the one where the
> >>>outputs come directly from the flops.  And yes, it's a -personal-
> >>>bias.
> >>
> >>That's true of a correct implementation of either model.  In a Mealy
> >>machine, the output at time t+1 is a function of both the current state at
> >>time t and the input at time t.  In a Moore machine, the output is a
> >>function of the current state only.  Some people implement Mealy machines
> >>sloppily, with the output being a *combinatorial* function of the current
> >>state and the input, but that's not an inherent characteristic of the
> >>model.
> >
> > Actually, that is not the "sloppy" Mealy machine, it is the literal
> > Mealy machine.  If you register the outputs in a Mealy machine so that
> > the outputs are a function of the previous inputs and state, you have
> > simply converted your machine to a Moore machine while leaving the
> > outputs out of the state description.  But it is still a Moore machine.
> 
> See the state machine example elsewhere in this thread with output ACK.
> The output is registered in each case.
> The timing is the same in each case.
> The trick is that an output register can combine either the D or Q side of the
> state register.

You can put registers anywhere you want in a design.  But neither Moore
nor Mealy machines have registers on the output values unless the
outputs happen to be the same as your state variables.  In both machines
the outputs are combinatorial functions of the state variables and in
the case of the Mealy machine, also the inputs.  Adding a register adds
a delay to the output and in reality is modeled accurately by a Moore
machine where the state variable included all registers, both the
original state bits and the registered output bits.  

S = f(S, I)
O = f(S, I) *Mealy*
O = f(S)    *Moore*

By adding the register to the outputs, you make the output a function of
the *previous* state and/or inputs, not the current state.  You can
define the output register input functions so that the outputs change on
the same sets of inputs and states as the state register, but then the
output registers become "state" registers.  If you look at the outputs
this way, you will see that treating them as Moore machine state
variables makes the programming much simpler.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56120
Subject: Re: JTAG madness
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 May 2003 23:15:36 -0400
Links: << >>  << T >>  << A >>
"Peter C. Wallace" wrote:
> 
> On Wed, 28 May 2003 15:36:41 -0700, rickman wrote:
> 
> > Magnus Homann wrote:
> >>
> >> (fig 1)
> >>
> >>   |--------|         |--------|     |--------|
> >> --| part A |--|   |--| part P |-----| part B |---
> >>   |--------|  |   |  |--------|  |  |--------|
> >>               |   |              |
> >>               |   |              |
> >>             |----------------------|
> >>             | connector X          |
> >>             |----------------------|
> >
> > I like most of what you said, but I don't think you can *debug* the
> > board with all the TMS and TCK signals in parallel.  This would send the
> > same instructions to all devices and put them in a possibly poor state
> > for normal operation when you only intended to be controlling part P.  I
> > expect to have to use jumpers to disable the TRST, TMS or TCK inputs on
> > all parts other than P.
> 
> Should be no problem, all non-tested parts would first be put in bypass
> mode, (instructions come from TDI, not TMS)
> 
> Whether the software you have will DTRT is another question...

But if you are driving part P with TDI, how do you drive the other parts
with a different serial stream?  Surely you are not suggesting that the
daisy chain be changed in the middle of debugging?  

As to the software, that is the cruxt of the problem.  If the software
worked well with other devices in the chain, there would be no problem
at all.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 56121
Subject: Re: JTAG madness
From: Peter Wallace <pcw@karpy.com>
Date: Wed, 28 May 2003 20:58:43 -0700
Links: << >>  << T >>  << A >>
On Wed, 28 May 2003 21:15:36 -0700, rickman wrote:

> "Peter C. Wallace" wrote:
>> 
>> On Wed, 28 May 2003 15:36:41 -0700, rickman wrote:
>> 
>> > Magnus Homann wrote:
>> >>
>> >> (fig 1)
>> >>
>> >>   |--------|         |--------|     |--------|
>> >> --| part A |--|   |--| part P |-----| part B |---
>> >>   |--------|  |   |  |--------|  |  |--------|
>> >>               |   |              |
>> >>               |   |              |
>> >>             |----------------------|
>> >>             | connector X          |
>> >>             |----------------------|
>> >
>> > I like most of what you said, but I don't think you can *debug* the
>> > board with all the TMS and TCK signals in parallel.  This would send
>> > the same instructions to all devices and put them in a possibly poor
>> > state for normal operation when you only intended to be controlling
>> > part P.  I expect to have to use jumpers to disable the TRST, TMS or
>> > TCK inputs on all parts other than P.
>> 
>> Should be no problem, all non-tested parts would first be put in bypass
>> mode, (instructions come from TDI, not TMS)
>> 
>> Whether the software you have will DTRT is another question...
> 
> But if you are driving part P with TDI, how do you drive the other parts
> with a different serial stream?  Surely you are not suggesting that the
> daisy chain be changed in the middle of debugging?

Its the same stream, different parts get different instructions loaded
depending on where they are in the stream, unused chips get bypass
instructions in their part of the TDI bitsteam, the DUT gets whatever is
needed. 

If the debug tools can't do the right thing with daisy chained parts,
another option is to tie all the TDI's, TDO's and TCKs together and do a
"chip select" by connecting the desired TMS to the JTAG probe (the other
TMS's having pullups) This is called "star" mode in TIs JTAG tutorial...

> 
> As to the software, that is the cruxt of the problem.  If the software
> worked well with other devices in the chain, there would be no problem
> at all.

Article: 56122
Subject: fpga4un
From: "Jean Nicolle" <j.nicolle@sbcglobal.net>
Date: Thu, 29 May 2003 04:01:20 GMT
Links: << >>  << T >>  << A >>
Hi all,

I'm building a new site
www.fpga4fun.com

It's still under construction but it has already one HDL tutorial/FPGA
project.
I also made a digital scope that is pretty cool, I'll post the design in the
next weeks.

Please check the site out and let me know how can I improve it!
Thanks.
Jean



Article: 56123
Subject: Re: need help on sending 500Mbit/s data through 100 feet of cable, Giga-Ethernet?
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 29 May 2003 04:16:15 GMT
Links: << >>  << T >>  << A >>
On 28 May 2003 16:49:07 -0700, ospyng@yahoo.com (spyng) wrote:

>hi all,
>need some help on this,
>
>need to send about 500Mbit/s of data(images) between our equipment 100
>ft (30 meter ) apart. we have rule out USB 2.0 and Firewire, because
>of the distance. both are about 5 meter per segment (as I understand).
>so we are thinking of using Gigabit Ethernet, just the phy if
>possible. I am not too familiar with the Gigabit Ethernet, so here is
>the question
>
>1) how difficult to create a custom-built interface in Xilinx Virtex
>II to GMII or TBI, just to transfer data? any pointer, link , that I
>could read about the GMII? I try google, but most of them is talking
>about interfacing with the MAC. not much on the protocol of GMII.
>

I don't think it is worth the effort to work at GMII level. You need
to implement MAC functionality yourself which is not trivial for 1000B
Ethernet.

>2) or must we use a MAC and implement TCP/IP stack? we trying to avoid
>that.

You don't necessarily have to implement tcp/ip. For point to point
apps like yours, just a mac and a custom processing engine would be
good enough. I suggest you hook up a MAC to a Virtex and process your
own packets in the FPGA.

Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations

Article: 56124
Subject: 20 to 5 encoder optimization?
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 29 May 2003 04:22:17 GMT
Links: << >>  << T >>  << A >>
Hi,
I need to implement 20 (one hot) to 5 encoder. The result would cover
21 codes of the 32 available (one for no input active case). I am
hoping that I can do better than binary encoding. The question is how
do I find an optimal encoding where any unique assignment of the 21
codes with the remaining codes assigned in a don't care fashion would
be acceptable. The optimality criteria can be minimum area (say
minimum number of 2 input gates). One way woul be to write a script
which generates Verilog rtl for all 2^32 possible assignments and run
the synthesizer for a long time trying all of them. Any other good
ways ?

Muzaffer Kal

http://www.dspia.com
ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations



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