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
2017JanFebMarApr2017

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 41300

Article: 41300
Subject: Re: Missing Timing by 30,000 ns
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 25 Mar 2002 08:53:07 -0800
Links: << >>  << T >>  << A >>

--------------92C391979D5F11BD267F9D04
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Goran,

When we added the DFS in the DCM (I know, it is all my fault - I was on
the DCM development team doing verification....I can't believe how
strange real life is some times) it created CLKFX, which is M/D the
frequency of CLKIN, or D/M the period of CLKIN.  To constrain a design
properly, you need to know these things.

Teaching the tools how to deal with this required a lot of work, and
getting all of it covered wasn't easy, as you suggest.

First time I saw this post I thought, "curious, why does this seem
familiar?"

When I saw the internal thread on the software solution, it suddenly
dawned on me, "oh, yes, we added this to support the DFS and the CLKFX
period...."

Fix is coming soon.  There is a simple workaround: (contact the hotline
for details):

"If you look in the timing report do you see timing requirements for
0.001ns? If
you do then this is due to the Trace tools rounding up and rounding down
when
dealing with CLKFX outputs. Its a known issue and will get solved in
Flint. The
way to get round it is to have an exact multiple of the CLKFX output.
e.g I had a customer who had the same issue. He had a 24.576MHz
clock(40690 ps
period) and I was getting the large failures.He had one DCM which gave a
CLK2X
output. He required a 1.5X output on the CLKFX from one DCM  and he also

required a 2x output from a CLK2X on another DCM. Thats why the tools
were
having a problem trying to sort out the timing requirement between the 2
clock
domains.    The first thing I did was to change the timing constraint to
40500
ps in the UCF file. This meant that the CLKFX output eas now 40500 /3 ps
= 13500
ps. When I ran that through the tools it went through OK."

Just trying to stay one step ahead,

Austin

Goran Bilski wrote:

> Kevin,
>
> Glad I could help.
>
> I'm not sure why it wasn't fixed in 4.2, probably because it was not
> an easy fix.
> The period has to be non-integer and with a lot of decimal digits. I
> think that the problem is due
> to rounding errors with floating point calculations.
>
> I'm told that it will be fixed in our next major release.
>
> Göran
>
> Kevin Neilson wrote:
>
>>  Goran,You're right... I thought this didn't work because I changed
>> the period in the UCF to an integer and saw no difference but forgot
>> that I had a period constraint in the NCF too so I just deleted the
>> NCF. Thanks a lot... you save me a lot of time. But since you're
>> from Xilinx maybe I can complain a bit... how come I have version
>> 4.2 and this problem still persists?  Am I the only person that uses
>> noninteger periods? -Kevin
>>
>>      "Goran Bilski" <goran@xilinx.com> wrote in message
>>      news:3C99089E.57DA27B5@xilinx.com...Hi,
>>
>>      I actually run in to this problem a little while ago.
>>      The reason for the huge timing delays is when you are
>>      using DLL and has a clock period constraint that
>>      has many decimals. I think that there are some rounding
>>      errors in the timing tools.
>>      So just change your clock period to 41 ns and the problem
>>      should go away
>>
>>      Göran
>>
>>
>>      Kevin Neilson wrote:
>>
>>      > All,I keep running into this problem all the time in
>>      > which I have a route that misses my constraint by tens of
>>      > thousands of nanoseconds.  I'm using the Xilinx 4.1 PAR
>>      > tools.  In this case the bad paths are ones that cross
>>      > from a domain with a 20ns period to a domain with a 10ns
>>      > period.  The faster domain is generated from a DLL locked
>>      > to the first, so while it is twice the freq, it is
>>      > synchronous to the first.  I'm taking care to read data
>>      > in the second domain only on "even" cycles of the first
>>      > domain, so the data has 20ns to get from the slow domain
>>      > to the fast.The first evidence of a problem comes during
>>      > routing:End of iteration 1
>>      > 22869 successful; 0 unrouted; (152088) REAL time: 5 mins
>>      > 34 secsYou've all cringed at seeing this message before.
>>      > Then, in the PAR summary, I see
>>      > this:--------------------------------------------------------------------------------
>>      >
>>      > * PERIOD analysis for net "clk_management/f | 10.416ns
>>      > | 38591.280ns | 4
>>      >   irclk_dcm_clk2x" derived from  NET "clk_m |
>>      > |            |
>>      >   anagement/CLK_ibufg" PERIOD =  41.667 nS  |
>>      > |            |
>>      >     HIGH 50.000000 %                        |
>>      > |            |
>>      >
>>      > -------------------------------------------------------------------------------This
>>      > is obviously a problem:  my constraint for the fast clock
>>      > domain is 10.4ns, and one path requires 38591ns, meaning
>>      > I need to slow my clock to the kilohertz range. Here's
>>      > the detail from
>>      > Trace:================================================================================Timing
>>      > constraint: PERIOD analysis for net
>>      > "clk_management/firclk_dcm_clk2x" derived from NET
>>      > "clk_management/CLK_ibufg" PERIOD = 41.667 nS   HIGH
>>      > 50.000000 % ; divided by 2.00 and duty cycle corrected to
>>      > 10.416 nS  HIGH 5.208 nS  29336 items analyzed, 58 timing
>>      > errors detected. Minimum period is
>>      > 38591.280ns.--------------------------------------------------------------------------------Slack:
>>      > -3.704ns (requirement - (data path - negative clock
>>      > skew))  Source:               dpll/theta[12]
>>      > Destination:          fir/phase_reclock[5]
>>      > Requirement:          0.001ns  Data Path Delay:
>>      > 3.705ns (Levels of Logic = 4)  Negative Clock Skew:
>>      > 0.000ns  Source Clock:         sclk rising at
>>      > 216975.695ns  Destination Clock:    firclk rising at
>>      > 216975.696ns  Data Path: dpll/theta[12] to
>>      > fir/phase_reclock[5]    Location             Delay
>>      > type         Delay(ns)  Physical
>>      > Resource
>>      > Logical Resource(s)
>>      > -------------------------------------------------
>>      > -------------------    SLICE_X57Y32.YQ
>>      > Tcko                  0.568
>>      > theta[13]
>>      > dpll/theta[12]    SLICE_X54Y33.F1      net
>>      > (fanout=3)        0.551   theta[12]
>>      > SLICE_X54Y33.COUT    Topcyf                0.769
>>      > fir/phase_reclock[2]
>>      > fir/phase_reclock_qxu[2]
>>      > fir/phase_reclock_cry[2]
>>      > fir/phase_reclock_cry[3]    SLICE_X54Y34.CIN     net
>>      > (fanout=1)        0.000   fir/phase_reclock_cry[3]/O
>>      > SLICE_X54Y34.Y       Tciny                 1.446
>>      > fir/phase_reclock[4]
>>      > fir/phase_reclock_cry[4]
>>      > fir/phase_reclock_s[5]    SLICE_X54Y34.DY      net
>>      > (fanout=1)        0.001   fir/phase_reclock_s[5]
>>      > SLICE_X54Y34.CLK     Tdyck                 0.370
>>      > fir/phase_reclock[4]
>>      > fir/phase_reclock[5]
>>      > -------------------------------------------------
>>      > ---------------------------
>>      > Total                                      3.705ns
>>      > (3.153ns logic, 0.552ns
>>      > route)
>>      > (85.1% logic, 14.9%
>>      > route)--------------------------------------------------------------------------------This
>>      > is just whack.  You can see that the path delay is 3.7ns,
>>      > which easily meets the 20ns period of the slow clock
>>      > (sclk).  However, for some reason it thinks the source
>>      > clock is sclk rising at 216975ns.  Where did that come
>>      > from?  And how did it get a slack of -3.704ns?  Also,
>>      > where did the 38591ns period in the PAR summary come
>>      > from?  That's not even close to 216975. This path really
>>      > shouldn't be analyzed at all.  The Xilinx answer files
>>      > state that 4.1i doesn't analyze paths that cross clock
>>      > domains.  Sometimes when I see this problem, I can "fool"
>>      > PAR by putting a FROM-TO in the UCF that explicity states
>>      > that paths from the "sclk" domain to the "firclk" domain
>>      > have 20ns.  However, this isn't working now, and Trace
>>      > claims that 0 items are analyzed using that TIMESPEC,
>>      > even though there are obviously many paths that fit that
>>      > description.Has anybody else seen this?-Kevin
>>



Article: 41301
Subject: Can't detect Altera MAX7000s using JTAG
From: "James Thurley" <newsgroups@NO.SPAM.PLEASE.jamesthurley.com>
Date: Mon, 25 Mar 2002 17:26:54 +0000 (UTC)
Links: << >>  << T >>  << A >>

I'm trying to program my Altera MAX7128SLC84-15 in JTAG mode, and I'm
getting nowhere fast.  This is the first time I've tried this, so I may be
doing something obvious wrong...

Firstly some information about how I'm doing it.   I know this not the best
way, but I'm only at university doing a project with a very limited budget
(my own budget) and very limited time.  The Altera is going into a PLCC to
DIL converter, which is in a hand soldered circuit that should let me
program the PLD and not a lot else, and it's all done on a matrix board.  So
there's the first 100 places where I could have made an error  :)

The power supply is running at 4.5 volts comming directly from a regulated
AC/DC adapter which I picked up at my local electronics store.  It's at the
low end of the recommended supply voltages, but should be ok I think.

I'm using a NEF-A-P (http://www.nefdesign.com/) programmer because it's
cheaper than the ByteBlasterMV and works at a good range of voltages.  I'm
assuming this is in good working order...

I'm pretty sure I've got everything connected correctly - I've checked many
times (following the altera diagrams and the report file for my program) -
but when I click on "Detect JTAG Chain Info" in the Altera Stand Alone
Programmer it says it can't detect any devices.

So.... I know there are loads of places that this could be wrong, but can
anyone tell me where the most likely points are?  Or have I done something
fundementally wrong?

Any help at all would be hugely apreciated!

Thanks,
James.



Article: 41302
Subject: Re: question on LFSR
From: John_H <johnhandwork@mail.com>
Date: Mon, 25 Mar 2002 17:31:45 GMT
Links: << >>  << T >>  << A >>
Thanks, Nicholas, but those with lower than max-length have less than (2^N)-1.

Two app notes give values to 168, but not quite up to 257...
 http://www.xilinx.com/xapp/xapp052.pdf
and
 http://www.xilinx.com/xapp/xapp210.pdf

(the latter probably references the former).



Nicholas Weaver wrote:

> In article <abc3b185.0203242257.1cf8a4ca@posting.google.com>,
> anish <anish@myrealbox.com> wrote:
> >hi all,
> >  would be glad to know about effcient implmentation of LFSR of odd
> >length i.e not powers of 2 ...like 257 ...is it possible if so how...
> >thanks in advance
>
> All max period shift registers of size N have a length of (2^N) - 1.
>
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 41303
Subject: Re: High speed clock routing
From: <adyer@m5.dyer.dhs.org>
Date: Mon, 25 Mar 2002 17:36:46 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <spamgoeshere4@yahoo.com> wrote:
> I think that most people don't want to simulate because it is unfamiliar
> territory for them.  I am in that camp.  I would perfer not to, but I am
> not willing to take a chance on 100 MHz clock lines which may be run up
> to 133 when the faster chip comes out.  Yes, I know that the clock speed
> is not what is important, but rather it is the edge rate.  But to allow
> the clock to speed up the edge rate will also go up.  

> But I am concerned that I will not have the correct data when I perform
> the simulation.  I still need to close the loop to get valid data that
> reflects my PCB.  That is an item that I will have to research further. 
> I am going to start with an old copy of the Motorola ECL data book.  It
> has a good chapter on Stripline and Microline (if I am remembering the
> terms correctly) and calculating all the relevant characteristics... if
> I can get the appropriate data on the PCB materials.  

I worked for a company that subcontracted some of this stuff out when
we were getting started.  The contractor we used did a nice job -
their website is http://www.avid-tech.com.  They also sold the tools
(hyperlynx) to us after we got up to speed.  (No affiliation, etc,
etc)

-- 
"The sooner you fall behind, the more time you'll have to catch up!"

Article: 41304
Subject: Re: Pipelined sorting algorithms...
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Mon, 25 Mar 2002 09:54:58 -0800
Links: << >>  << T >>  << A >>

Thank you to all who replied!  I value your
insight into the problem.  I'm going to see
where I can get a copy of Knuth's book to
see for myself...

Thanks again,
Eric

Article: 41305
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 25 Mar 2002 10:54:12 -0800
Links: << >>  << T >>  << A >>
James Thurley wrote:
> 
> I'm trying to program my Altera MAX7128SLC84-15 in JTAG mode, and I'm
> getting nowhere fast.  This is the first time I've tried this, so I may be
> doing something obvious wrong...
> I know this not the best
> way, but I'm only at university doing a project with a very limited budget
> (my own budget) and very limited time. 

Altera will show you how to make your own byteblaster.
see page 4 of
http://www.altera.com/literature/ds/dsbytemv.pdf

 -- Mike Treseler

Article: 41306
Subject: Re: question on LFSR
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Mon, 25 Mar 2002 19:00:14 GMT
Links: << >>  << T >>  << A >>
I don't see why you couldn't use just a subset of a maximal length LFSR...
you could just reset the LFSR reg when it hits a certain value.  For
example, if you have a 9-bit LFSR that you reset to 9'b1, you and you know
that the 257th value in that sequence is x(257), then you can just reset the
LFSR back to 9'b1 whenver you hit x(257).  To maintain full speed you can
instead detect x(256) or x(255) instead and pipeline the detector circuitry
so you only have one level of LUT logic.

"anish" <anish@myrealbox.com> wrote in message
news:abc3b185.0203242257.1cf8a4ca@posting.google.com...
> hi all,
>   would be glad to know about effcient implmentation of LFSR of odd
> length i.e not powers of 2 ...like 257 ...is it possible if so how...
> thanks in advance
> anish



Article: 41307
Subject: Re: question on LFSR
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 25 Mar 2002 11:10:44 -0800
Links: << >>  << T >>  << A >>
Kevin,

An old tried and true technique that I used in XC3000 fpga's.  Find the nth
count value, detect it, and synchrounously load the first value again.

Austin

Kevin Neilson wrote:

> I don't see why you couldn't use just a subset of a maximal length LFSR...
> you could just reset the LFSR reg when it hits a certain value.  For
> example, if you have a 9-bit LFSR that you reset to 9'b1, you and you know
> that the 257th value in that sequence is x(257), then you can just reset the
> LFSR back to 9'b1 whenver you hit x(257).  To maintain full speed you can
> instead detect x(256) or x(255) instead and pipeline the detector circuitry
> so you only have one level of LUT logic.
>
> "anish" <anish@myrealbox.com> wrote in message
> news:abc3b185.0203242257.1cf8a4ca@posting.google.com...
> > hi all,
> >   would be glad to know about effcient implmentation of LFSR of odd
> > length i.e not powers of 2 ...like 257 ...is it possible if so how...
> > thanks in advance
> > anish


Article: 41308
Subject: Re: question on LFSR
From: "Jan Gray" <jsgray@acm.org>
Date: Mon, 25 Mar 2002 11:51:55 -0800
Links: << >>  << T >>  << A >>
See "On Arbitrary Cycle n-Bit LFSRs",
http://www.fpgacpu.org/usenet/lfsrs.html, and the lfsr design program in the
XSOC kit at http://www.fpgacpu.org/xsoc/.

Jan Gray, Gray Research LLC




Article: 41309
Subject: Re: Missing Timing by 30,000 ns
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Mon, 25 Mar 2002 20:19:23 GMT
Links: << >>  << T >>  << A >>
It wouldn't bother me so much that this is a known issue if Xilinx made the
workaround easy to find.  Even if there is an answer in the help files, it
is useless if one can't find it.  I spent an hour typing in every possible
search pattern that might relate to this problem and never did I find answer
#12174.  At least not in the first several dozen hits.

"Jason Daughenbaugh" <fpgaguy@aedinc.net> wrote in message
news:3efced06.0203250838.795ada9e@posting.google.com...
> > But since you're from Xilinx maybe I can complain a bit... how come I
> > have version 4.2 and this problem still persists?  Am I the only person
> > that uses noninteger periods?
>
> No, you are not the only one.
>
> I have seen this problem many times since I upgraded to 4.1i.
>
> Xilinx support pointed me to answer #12174.
>
> It is for Virtex2 DCM's, but he said that the problem also exists for
> Vitex/spartan-2 DLL's.
>
> A agree that it is a little dissappointing that has not been fixed in
> any service pack or 4.2i, especially since it has apparently bitten
> several engineers and they have known about it for a while (I
> contacted them in December / January, and he told me that it is a
> "known issue.")  Hopefully it will be fixed in the next service pack?
> But answer 12174 does not seem to indicate any plan to fix it.
>
> It is almost comical to see the report say that something with two
> logic levels can only run at 33kHz in a Spartan-2 FPGA.  Seems like
> something Xilinx would like to avoid...
>
> Jason Daughenbaugh
> http://www.aedinc.net



Article: 41310
Subject: Re: question on LFSR
From: vhdlcohen@aol.com (VhdlCohen)
Date: 25 Mar 2002 20:39:16 GMT
Links: << >>  << T >>  << A >>
My site has a vhdl lfsr + reference to book that has all the equations for
various sizes. 
----------------------------------------------------------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830  
http://www.vhdlcohen.com/                 vhdlcohen@aol.com  
Author of following textbooks: 
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8 
* Component Design by Example ",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

Article: 41311
Subject: Re: Xilinx 4.2i not working on my design
From: emanuel stiebler <emu@ecubics.com>
Date: Mon, 25 Mar 2002 13:52:38 -0700
Links: << >>  << T >>  << A >>
David Frith wrote:
> 
> Hello all
> 
> I've just loaded on ISE 4.2i and the first design I ran through gives me an
> error at ngdbuild. This is with exactly the same input files as 4.1i which

Did you instal the SP1 already ? Probably it goes away ...

Article: 41312
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: "Tuomo Auer" <tuomo.auer@removethis.hut.fi>
Date: Mon, 25 Mar 2002 23:06:05 +0200
Links: << >>  << T >>  << A >>
Maybe you have a dead device. My students have destroyed EPM7064S-devices
several times having no ground connection between the programming computer
and PSU supplying the circuit board. If you have bad luck, ground pin is not
the first pin to makimg connection when inserting programming cable, but a
signal pin routed to Altera device. Surge voltage and current caused by
different potential of computer and the circuit board can easily kill this
pin. So always make a connection between the case of computer and the ground
of the pcb before connecting the programming device. And firstly remove the
programming device and then the external ground connection. It's also a good
idea to have shottky diodes from every signal-pins of JTAG to ground and
VCC. Dual shottky BAT54S will handle glound and VCC simultaneously
--
Tuomo Auer



Article: 41313
Subject: Using GCLK1 as Input on Spartan II under Foundation 4.1
From: "Robert S. Grimes" <rsg@payload.nospam.com>
Date: Mon, 25 Mar 2002 21:38:53 GMT
Links: << >>  << T >>  << A >>
Hi all,

According to the Spartan II datasheets, a pin I must use is defined as "I,
GCK1" for its function.  Because of the prototyping board I am using - and
what I am trying to do!, I must use this pin as an input.  Here is a portion
of my VHDL code:

--Stuff here

signal WrEnable: std_logic;

-- in arch begin/end

-- Invert the input pin P_WR_L to get active high signal
WrEnable <= not P_WR_L;

-- Instantiate RAM block from Coregen
ram_block : rammodule
        port map (
            addr => P_Address,     -- Address pins
            clk => SCLK,              -- System clock
            din => P_Data,             -- Data pins
            dout => RData,            -- To tri-state buffers
            we => WrEnable);        -- Write Enable signal

This synthesises fine.  However, when I attempt to implement this design, I
get the following error:

Running directed packing...
ERROR:Pack:1107 - Unable to combine the following symbols into a single IOB
   component:
    PAD symbol "p_wr_l" (Pad Signal = p_wr_l)
    BUF symbol "p_wr_l_IBUF" (Output Signal = p_wr_l_IBUF)
   Each of the following constraints specifies an illegal physical site for
a
   component of type IOB:
    Symbol "p_wr_l" (LOC=P77)
   Please correct the constraints accordingly.
Problem encountered during the packing phase.

The associated constraints file has the following entry:
  NET "p_wr_l"         LOC =  "P77";

I do not understand the error, nor how to fix it!  BTW, if I use a I/O only
pin, instead of P77, everything works fine!  But of course, I cannot do
that! *sigh*

Thanks for your help!
-Bob



Article: 41314
Subject: Re: question on LFSR
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 25 Mar 2002 13:45:44 -0800
Links: << >>  << T >>  << A >>


John_H wrote:

> Thanks, Nicholas, but those with lower than max-length have less than (2^N)-1.
>
> Two app notes give values to 168, but not quite up to 257...
>  http://www.xilinx.com/xapp/xapp052.pdf
> and
>  http://www.xilinx.com/xapp/xapp210.pdf
>

Not really.
Thetwo app notes just give the circuitry for different values of n.
The question, the way I understood it, was how to design an LFSR that is
repetitive for different numbers, not just (2 exp n) -1.
Conceptually, the trick would be to change the input polarity at a certain point,
for only one clock tick, and thus skip the appropriate number of clock ticks.
Easily said, and guaranteed to work, but I am not good enough at math to
implement it.
:-)
257 requires a 9-bit LFSR. So you can try out "my" method by brute force. That's
what computers are good at...


Peter Alfke


Article: 41315
Subject: Re: Help with Xilinx CoolRunner Problem
From: halstoninaustin@yahoo.com (Mik e Payne)
Date: 25 Mar 2002 14:49:01 -0800
Links: << >>  << T >>  << A >>
Falk,

Thanks for your reply.  I am using short (less than 3") wires for the
power and ground.  I've got decoupling caps on both the SRAM and 8051.
I'm using a 7805 5V regulator to supply the 5V to the SRAM/8051.  I've
got decoupling caps on the input (22uf) and the output (10uf and .1uf)
of the 7805.  I've run 4 wires from the ground of the 7805 to 4 of the
decoupling capacitors on the CPLD to help my grounding issues.  These
are in addition to several other wires I have creating a common ground
between the 5V and 3.3 volt logic.  I'm using the thickest wire I can
that will fit through the PCB holes.  I'm not sure what else I can do
to fix my grounding issues.  There's not many more places I can solder
a wire to.

Thanks for your help.
Mike



"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<a7l39c$m7io0$1@ID-84877.news.dfncis.de>...
> "Mik e Payne" <halstoninaustin@yahoo.com> schrieb im Newsbeitrag
> news:b1946105.0203232118.7d4ecbeb@posting.google.com...
> 
> > the low address lines and control read/write enable).  I'm using an
> > AVNET evaluation board for the prototyping.  I cannot get this design
> 
> How do you connect the 8051 and SRAM to the demo board? Via 10 feet of
> ribbon cable with just 1 ground wire ? ;-)
> Just kidding.
> Serious, I think a 8051 isnt such a killer (IOs are not too fast) to produce
> heavy ground bounce and/or ringing if the setup is reasonably OK. Use short
> (<10 cm) connection cables, good ground connections (close to the signals,
> not fly-around ground wire) and everything should be OK.
> 
> > I'm thinking that I'm not understanding something about this CPLD.  It
> > has a 32.768KHz clock going into CLK0 and CLK1-3 are tied to ground.
> > Do I need to have clocks on all of these lines?  Does the clock need
> 
> No. As far as I acn see you are just running the asynchronous interface
> between the 8051 and SRAM through the CPLD, so there is no need for a clock.

Article: 41316
Subject: Re: Help with Xilinx CoolRunner Problem
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Mon, 25 Mar 2002 17:35:44 -0600
Links: << >>  << T >>  << A >>
Mik e Payne wrote:

> Falk,
>
> Thanks for your reply.  I am using short (less than 3") wires for the
> power and ground.  I've got decoupling caps on both the SRAM and 8051.
> I'm using a 7805 5V regulator to supply the 5V to the SRAM/8051.  I've
> got decoupling caps on the input (22uf) and the output (10uf and .1uf)
> of the 7805.  I've run 4 wires from the ground of the 7805 to 4 of the
> decoupling capacitors on the CPLD to help my grounding issues.  These
> are in addition to several other wires I have creating a common ground
> between the 5V and 3.3 volt logic.  I'm using the thickest wire I can
> that will fit through the PCB holes.  I'm not sure what else I can do
> to fix my grounding issues.  There's not many more places I can solder
> a wire to.

I'm not exactly clear on what the CPLD is mounted on.  Is it on the
Avnet evaluation board?  If so, then the power supply bypassing is
all by etched traces already on the board?  If all that is so, then
bypassing of the CPLD should be adequate.  I'e done a number of
XC9572 designs and not had any surprises with power decoupling,
the chips are quite well behaved.  I would expect the CoolRunner should
be the same.  But, there is the 5/3.3V interface that could be messing
things up.  Could the 3.3 V outputs from the CoolRunner be causing the
8051 or SRAM to go haywire?

You mentioned a 32 KHz clock, but the VHDL looks pretty combinatorial,
not clocked.  So, where does CLK0 go, and what does it do?  If you are
not using the clock in your equations, then don't provide it to an input
of the chip.  No telling what it has configured that pin for if it is not
specified in the equations.

Jon


Article: 41317
Subject: Re: Poor availability problems on Coolrunner
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Mon, 25 Mar 2002 17:45:42 -0600
Links: << >>  << T >>  << A >>
rickman wrote:

> Yes, I just finished looking at that.  There is quite a discrepance
> between the pricing that Xilinx lists on their web page for HUGELY high
> volumes and the prices we little people get.  I saw $5.50 for an XCS30XL
> on the Xilinx promo page and >$30 at Avnet for 100.

Should be cheaper than that, at least in TQ144 package.  I paid $30 (ea) for
5 XCS30-3TQ144 parts, and the NON-XL cost a lot more than the XL.
There IS a big difference in price based on the package, though.

Jon


Article: 41318
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: James Horn <jimhorn@svn.net>
Date: 25 Mar 2002 15:48:44 -0800
Links: << >>  << T >>  << A >>
You can also use a logic probe or oscilloscope to verify that data is 
flowing to the chip's TDI pin - and *should* be coming from its TDO pin.  
If the first isn't true, the interface isn't driving the pin or it's 
shorted.  If TDI works and TDO doesn't, the chip is probably gone, though 
again a short could be the culprit.  TCK should pulse when you use the 
interface too.

Best to you and your project!

Jim

Article: 41319
Subject: Re: Pipelined sorting algorithms...
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 26 Mar 2002 00:02:25 GMT
Links: << >>  << T >>  << A >>
Christopher.Saunter@durham.ac.uk (Christopher Saunter) writes:
>Eric Crabill (eric.crabill@xilinx.com) wrote:

>: I am looking to build a circuit for sorting small data sets,
>: and am hoping someone here might have some pointers for where
>: I should start looking for algorithms to do it.

(snip)

>I got thinking about sorting, and this is what I came up with.
>It should sort data at high speed, and accepts all words in 
>a single cycle in parallel, and spits them out in parallel,
>sorted, a fixed number of cycles later.  I think with a bit
>of effort in layout it would run very fast as well.  However,
>it makes rather less efficient use of a Xilinx device than
>the FIFO solution, as it uses flip-flops for data storage, not
>LUTs.

>Please lay into any problems it has, I'm out to learn!

>---
>The design consists of a number of pipeline stages, each of which
>partially sorts the data by sorting pairs of values.

>We have N words.  Conceptually these are split into N/2 pairs 
>of words, each of which are sorted based on the 4 bit key.
>This could be done with a 4 bit magnitude comparitor and two 2:1 
>mux's - see my noddy diagram at
>http://www.dur.ac.uk/christopher.saunter/sort1.bmp

>So the first stage of the sorting pipeline is as follows:

(snip)

Fast sorting algorithms are O(n log n) comparisons.  Here you are
doing m comparisons at a time, maybe even n comparisons.  I don't
know if there is an O(n log n) parallel sort algorithm.

I did once implement a maximum of two 16 bit numbers in XC4000 
series.  It is convenient in that the carry logic does the compare
and the LUT's do the select, so it can be done in 9 CLBs.  It seems
that newer Xilinx FPGA's don't allow this separate carry logic
operation.

I would look into systolic array algorithms, as they tend to be
good for doing this.  According to my systolic algorithms book
bubble sort is about the most efficient systolic sort algorithm,
which is pretty much what you were describing.  You need n cells
and n cycles to sort n elements.

-- glen

Article: 41320
Subject: Re: question on LFSR
From: Ray Andraka <ray@andraka.com>
Date: Tue, 26 Mar 2002 00:14:57 GMT
Links: << >>  << T >>  << A >>
Getting the correct length by selectively inverting the input works, but it can be
challenging to find the right timing and decode.  Back in the 3000 days, I found it
was easier to decode a specific state and then reset the shift register.  You could
easily backup the count or advance the reset state to get an easy decode followed by
one or a few registers to adjust the timing.  I even went as far as writing an LFSR
tool that would give you the minimum decode for the state n counts away from the
current state, or with a decode pattern and current state tell you how many counts
till the decode hit.

Peter Alfke wrote:

> John_H wrote:
>
> > Thanks, Nicholas, but those with lower than max-length have less than (2^N)-1.
> >
> > Two app notes give values to 168, but not quite up to 257...
> >  http://www.xilinx.com/xapp/xapp052.pdf
> > and
> >  http://www.xilinx.com/xapp/xapp210.pdf
> >
>
> Not really.
> Thetwo app notes just give the circuitry for different values of n.
> The question, the way I understood it, was how to design an LFSR that is
> repetitive for different numbers, not just (2 exp n) -1.
> Conceptually, the trick would be to change the input polarity at a certain point,
> for only one clock tick, and thus skip the appropriate number of clock ticks.
> Easily said, and guaranteed to work, but I am not good enough at math to
> implement it.
> :-)
> 257 requires a 9-bit LFSR. So you can try out "my" method by brute force. That's
> what computers are good at...
>
> Peter Alfke

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41321
Subject: How to recover a Bluetooth data stream.
From: "Kelvin Hsu" <qijun@okigrp.com.sg>
Date: Tue, 26 Mar 2002 08:45:53 +0800
Links: << >>  << T >>  << A >>
From what I know decoded bluetooth data comes out with 1us period.
Maybe there are noise like spikes and phase shift. Is there any reference
design on how to recover this data stream and create a clock?
thanks.



Article: 41322
Subject: Re: question on LFSR
From: "Jan Gray" <jsgray@acm.org>
Date: Mon, 25 Mar 2002 17:21:43 -0800
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote in message
news:3C9FBD85.3022F77@andraka.com...
> Getting the correct length by selectively inverting the input works, but
it can be
> challenging to find the right timing and decode.

That's what my aftorementioned little LFSR design program does...


And as long as I am replying to this thread a second time, I would like to
remind folks that in an FPGA architecture with SRL16 (16-bit programmable
output tap shift registers in a single 4-LUT), you can often design simpler
divide-by-n counters using a couple of SRL16s.  I recommend Ken Chapman's
'techXclusives' articles on SRL16E:

http://www.xilinx.com/support/techxclusives/SRL16-techxclusive2.htm
http://www.xilinx.com/support/techxclusives/SRL16-techxclusive3.htm
http://www.xilinx.com/support/techxclusives/SRL16-techxclusive4.htm

The clock division discussion is in part 2.

And you can even mix paradigms, using an LFSR made with an SRL16-based shift
register, as Maria George and Peter Alfke discuss here:
http://www.xilinx.com/xapp/xapp210.pdf.

Jan Gray, Gray Research LLC




Article: 41323
Subject: Re: Can't detect Altera MAX7000s using JTAG
From: "Arbitrary" <wackedy@XXXhotmail.com>
Date: Tue, 26 Mar 2002 02:24:22 GMT
Links: << >>  << T >>  << A >>
"Tuomo Auer" <tuomo.auer@removethis.hut.fi> skrev i meddelandet
news:a7o3eq$g6n$1@tron.sci.fi...
> Maybe you have a dead device. My students have destroyed EPM7064S-devices
> several times having no ground connection between the programming computer
> and PSU supplying the circuit board. If you have bad luck, ground pin is
not
> the first pin to makimg connection when inserting programming cable, but a
> signal pin routed to Altera device. Surge voltage and current caused by
> different potential of computer and the circuit board can easily kill this
> pin. So always make a connection between the case of computer and the
ground
> of the pcb before connecting the programming device. And firstly remove
the
> programming device and then the external ground connection. It's also a
good
> idea to have shottky diodes from every signal-pins of JTAG to ground and
> VCC. Dual shottky BAT54S will handle glound and VCC simultaneously
> --
> Tuomo Auer
>

These devices seem kind of sensitive. I recently built myself a
ByteBlasterMV cable and a small pcb for an EPM7064S with headers for all
pins and JTAG. The first time I tried it everything seemed to work ok, I
could examine the chip and readout the data(though I thought the chips would
be blank when purchased but it was not). Then I wired everything up to test
the program I wrote and it didnt work anymore. I could not find anything
wrong with the way it was hooked certainly not anything that would kill the
chip. So it might have been fried the way Tuomo suggested or by ESD. If it
was the way Tuomo suggested I think its weird that this is not stated in the
ByteBlaster manual or any of the application notes regarding ISP. I checked
the TCK and TDI signals with a scope and they seemed ok but the TDO signal
was stuck at 0 V.

Arbitrary



Article: 41324
Subject: Re: question on LFSR
From: Ray Andraka <ray@andraka.com>
Date: Tue, 26 Mar 2002 03:24:01 GMT
Links: << >>  << T >>  << A >>
Jan,

I agree, the SRL16 is a wonder drug.  I don't however like to use it as a closed
loop state machine as described by Ken because such a design will not self
recover in the event of an upset.  The SRL16 only gets initialized on
configuration, so if for some reason you get an upset (and in the .15 micron it
does sometimes happen), your state machine carries that upset state bit until
the device is reconfigured.  In my book, that is poor design practice.  As soon
as you add the logic to detect the illegal states, the size gets considerably
larger (it may be more advantageous to use TMR here).

The LFSR in an SRL16 is a different story, since in that case there is only one
illegal state, not 2^n-n.  The SRL16s are really nice for compact LFSRs as long
as you don't need to reset them in less than N clocks and you don't need access
to more than a few bits.  That makes the SRL16 LFSR fine for random pattern
generation, but not so hot for state machines.  These days, I am not using LFSRs
very often at all.


Jan Gray wrote:

> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3C9FBD85.3022F77@andraka.com...
> > Getting the correct length by selectively inverting the input works, but
> it can be
> > challenging to find the right timing and decode.
>
> That's what my aftorementioned little LFSR design program does...
>
> And as long as I am replying to this thread a second time, I would like to
> remind folks that in an FPGA architecture with SRL16 (16-bit programmable
> output tap shift registers in a single 4-LUT), you can often design simpler
> divide-by-n counters using a couple of SRL16s.  I recommend Ken Chapman's
> 'techXclusives' articles on SRL16E:
>
> http://www.xilinx.com/support/techxclusives/SRL16-techxclusive2.htm
> http://www.xilinx.com/support/techxclusives/SRL16-techxclusive3.htm
> http://www.xilinx.com/support/techxclusives/SRL16-techxclusive4.htm
>
> The clock division discussion is in part 2.
>
> And you can even mix paradigms, using an LFSR made with an SRL16-based shift
> register, as Maria George and Peter Alfke discuss here:
> http://www.xilinx.com/xapp/xapp210.pdf.
>
> Jan Gray, Gray Research LLC

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759





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
2017JanFebMarApr2017

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