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 140225

Article: 140225
Subject: ML402 kernel config : option missing "CFI Flash device PetaLinux
From: =?ISO-8859-1?Q?Nicolas_Herv=E9?= <nicolas.herve@gmail.com>
Date: Mon, 4 May 2009 14:47:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am tempting to install petalinux on a Xilinx ML402 board.
I am following the "PetaLinux Platform From Scratch" tutorial from
page http://developer.petalogix.com/wiki/BoardGuides/Custom/Tutorial
but when configuring kernel for "Mapping drivers for chip access" I do
not have the option reported on the tutorial : "CFI Flash device
PetaLinux AutoConfig"
(neither the "Generic uClinux RAM/ROM filesystem support"), so I did
use theses options :
[*] CFI Flash device in physical memory map
     (0x88800000) Physical start address of flash mapping
     (0x00800000) Physical length of flash mapping
     (4)   Bank width in octets
(Addresses are those found in the EDK or Kconfig.auto)

All following steps seems ok but at kernel boot I have the following
message:
"kobject_add failed for physmap-flash.0 with -EEXIST, don't try to
register things with the same name in the same directory."

If I remove the option "CFI Flash device in physical memory map" then
I get a
"Kernel panic - not syncing: Attempted to kill init!".

Did I miss something ?

I am using a recent version of the petalinux project (SVN rev 5238,
last changed date: 2009-04-26).



Thank you for any help.

Nicolas

Article: 140226
Subject: Re: High-speed signals crossing a split-ground
From: rickman <gnuarm@gmail.com>
Date: Mon, 4 May 2009 15:55:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 4, 3:16=A0pm, "MM" <mb...@yahoo.com> wrote:
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
>
> news:gtncrq$1a8$2@naig.caltech.edu...
>
>
>
> > (after I wrote)
> >>> If it is differential shouldn't it be mostly balanced?
>
> >> Balanced doesn't mean that return current for one side actually
> >> uses another side.
>
> > I qualified with "mostly". =A0One would have to look at the
> > individual case. =A0Properly terminated, it is hard to see whereelse
> > the current would go, but signals aren't always properly terminated.
>
> Please check out this article by Eric Bogatin:http://www.thefreelibrary.c=
om/So+far,+so+close:+understanding+return+...
>
> It should be available on his web site (http://www.bethesignal.net/) as w=
ell
> in a better format but I couldn't find it quickly...
>
> /Mikhail

That's an interesting article.  I had never known that there was so
little coupling in a differential pair, although I should have known
that.  A class I took made the point that when it comes to cross
coupling between unrelated signals, you only need to consider signals
running on different layers with no ground/power plane between them.
The coupling between adjacent signals is so small that it can be
ignored.

In fact, would that make a good differential pair, to run the traces
opposite each other with a ground plane between them?  The ground
currents would clearly cancel in that case.  I guess in practice it
would be hard to do unless you were willing to use a lot of plane
layers so that the two traces see the same environment.

But it wouldn't be hard to put two signal layers between two plane
layers.  That would be very similar to the shielded, twisted-pair
mentioned in the article.  I prefer to keep my power planes on
adjacent layers to provide the maximum decoupling, but this could be
done locally if you were using eight or more layers.

Rick

Article: 140227
Subject: Re: High-speed signals crossing a split-ground
From: CBFalconer <cbfalconer@yahoo.com>
Date: Mon, 04 May 2009 19:08:08 -0400
Links: << >>  << T >>  << A >>
Barry wrote:
> ee_ether <xjjzdv...@sneakemail.com> wrote:
>
>> I'm working a design that has isolation between two sub-systems
>> on one PCB (the grounds are separate).  One side is a "high-speed"
>> digital side with FPGAs and DDR doing DSP and the other side is
>> an analog side that has high-resolution 24-bit ADCs and DACs.
>>
... snip ...
> 
> You can probably run data lines single-ended, with series resistors
> to slow the edges and limit the current.  You are right about the
> long return current path causing radiated noise, but the random
> nature of the data lines will make it rather spread-spectrum, so it
> should be tolerable.  Clocks, on the other hand, should only cross
> a split-plane as differential signals.  You still get radiated
> emissions, but much less.  The diff pair over split plane can be
> modeled as a diff pair over continuous plane plus a small loop
> antenna with dimensions equal to the split width and the pair
> spacing.  So make the split small and the lvds traces close
> together.  Henry Ott covered this in one of his books; sorry I
> don't remember which one.

The major problem solved by separated grounds is common noise by
spikes on the power lines.  So you want to ensure the two grounds
are completely separate, and have only one common point, which does
not include power supply leads that can provide common impedances.  

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



Article: 140228
Subject: Re: FIFO that latches data asynchronic manner
From: Muzaffer Kal <kal@dspia.com>
Date: Mon, 04 May 2009 16:20:09 -0700
Links: << >>  << T >>  << A >>
On Mon, 4 May 2009 17:45:21 -0400, "MM" <mbmsv@yahoo.com> wrote:

>"de4" <de4@poczta.onet.pl> wrote in message 
>news:K8ednSNliKhh02LUnZ2dnUVZ_sCdnZ2d@giganews.com...
>> I thinking now how for example InChipScope debbugging in
>> circuit working in order to save some asynchronious event in FPGA that can
>> occur independly from clock because it is very similar to my task that I'm
>> trying to reach....I only know that it stores changes of states in BRAM 
>> but
>> how it store asynch states if writing to Block RAM must be synchronious...
>>
>
>ChipScope doesn't do anything at all to help you with capturing async events 
>"properly".

That's not strictly true. VIO certainly tries to do the right thing to
sample the events you select by connecting them to the clock input of
a flop which has its data input connected to high. Later an async
reset clears the flop for the next event. If your VIO signals are
separated enough for this to work, you certainly catch them
asynchronously on chip. The fact that they have to be recorded and
transported with the jtag clock is a different matter though.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 140229
Subject: Re: High-speed signals crossing a split-ground
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 4 May 2009 23:58:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote:
(Someone wrote)

>> Please check out this article by Eric Bogatin:http://www.thefreelibrary.com/So+far,+so+close:+understanding+return+...
 
> That's an interesting article.  I had never known that there was so
> little coupling in a differential pair, although I should have known
> that.  A class I took made the point that when it comes to cross
> coupling between unrelated signals, you only need to consider signals
> running on different layers with no ground/power plane between them.
> The coupling between adjacent signals is so small that it can be
> ignored.

I didn't get a chance to read it yet.  What should be important
is that the impedance of the two are equal.  Well, also that the
lengths are equal.  The lines on modern motherboards between CPU
and memory often follow a zig-zag path to equalize the lengths.
 
> In fact, would that make a good differential pair, to run the traces
> opposite each other with a ground plane between them?  The ground
> currents would clearly cancel in that case.  I guess in practice it
> would be hard to do unless you were willing to use a lot of plane
> layers so that the two traces see the same environment.

More usual is to run a ground between the traces, but that should
work, too.  But you can't put them so close together or they
will couple to other signals.
 
> But it wouldn't be hard to put two signal layers between two plane
> layers.  That would be very similar to the shielded, twisted-pair
> mentioned in the article.  I prefer to keep my power planes on
> adjacent layers to provide the maximum decoupling, but this could be
> done locally if you were using eight or more layers.

-- glen

Article: 140230
Subject: Re: FIFO that latches data asynchronic manner
From: rickman <gnuarm@gmail.com>
Date: Mon, 4 May 2009 20:42:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 4, 7:20=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Mon, 4 May 2009 17:45:21 -0400, "MM" <mb...@yahoo.com> wrote:
> >"de4" <d...@poczta.onet.pl> wrote in message
> >news:K8ednSNliKhh02LUnZ2dnUVZ_sCdnZ2d@giganews.com...
> >> I thinking now how for example InChipScope debbugging in
> >> circuit working in order to save some asynchronious event in FPGA that=
 can
> >> occur independly from clock because it is very similar to my task that=
 I'm
> >> trying to reach....I only know that it stores changes of states in BRA=
M
> >> but
> >> how it store asynch states if writing to Block RAM must be synchroniou=
s...
>
> >ChipScope doesn't do anything at all to help you with capturing async ev=
ents
> >"properly".
>
> That's not strictly true. VIO certainly tries to do the right thing to
> sample the events you select by connecting them to the clock input of
> a flop which has its data input connected to high. Later an async
> reset clears the flop for the next event. If your VIO signals are
> separated enough for this to work, you certainly catch them
> asynchronously on chip. The fact that they have to be recorded and
> transported with the jtag clock is a different matter though.
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>
> http://www.dspia.com

I don't understand what this accomplishes.  This will catch a positive
transition, but it does not know when the falling edge is and if the
positive edge comes while you are resetting the flop, well, it gets
lost!  How is this used exactly?  I think I am not getting it.

Rick

Article: 140231
Subject: Re: Spartan3E Starter Kit MISO and Flash pin shared
From: "mstanisz" <matt.staniszewski@gmail.com>
Date: Tue, 05 May 2009 01:18:12 -0500
Links: << >>  << T >>  << A >>
Okay, I went ahead and removed the duplicate NETs in the UCF and made them
internal.  I'm trying to figure out how to MUX between the two signals
using a core in EDK.  It does seem like it should be fairly simple, but I'm
not sure how to go about it with IP cores.  Thanks.

Matt

>Busses become single pins in the .ucf. Comment out the Data<0> and
SPI_MISO 
>nets in the ucf so they become internal ports, and add a new NET to 
>represent their combined function. You'll need a module to connect and 
>select between them. I suspect this is much easier said than done, 
>especially if the functions are in different clock domains or if the
enables 
>are less than dead simple. Also, the added logic might push a marginal 
>design beyond timing allowances. All the same, modifying supplied HDL
always 
>seems a bad idea.>
>"mstanisz" <matt.staniszewski@gmail.com> wrote in message 
>news:1t6dnfigwrwkXmDUnZ2dnUVZ_qmdnZ2d@giganews.com...
>> Hi Glen,
>>
>> The EDK is Xilinx's Embedded Development Kit.  The way components, such
as
>> the ADC and flash memory, are implemented as reconfigurable
Intellectual
>> Property (IP) cores.  These are essentially reconfigurable blocks of
VHDL
>> code that you set in the GUI.
>>
>> So, I believe I'll need to modify this VHDL code after it's generated,
>> since the EDK gui will not let me set a single pin from the flash data
bus
>> to a specific location.  Rather, the IP core only lets you map a
16-bit
>> bus.
>>
>> Thanks.
>>
>> Matt
>>
>>
>>>mstanisz <matt.staniszewski@gmail.com> wrote:
>>>
>>>> Thanks for the quick response.  I've read through the User's Guide
and
>> saw
>>>> that part.  I have a GPIO set up for all the CENs and CSs that I
need
>> to
>>>> control as specified in the documentation.  However, I wasn't sure
how
>> to
>>>> multiplex the two devices to the N10 net in the EDK, since the flash
>> IP
>>>> core specifies a 16-bit bus and I only need to share 1 bit of that
with
>> the
>>>> MISO signal.  I feel I need to modify the system VHDL file that the
>> EDK
>>>> generates, but I wasn't sure where I should do that.  Any help would
>> be
>>>> great.  Thanks!
>>>
>>>I am not sure what EDK is.
>>>
>>>I think the usual way is to use only one at a time, and make
>>>sure that the other one is disabled.
>>>
>>>There is a similar double use on the LCD display.
>>>
>>>-- glen
>>> 
>
>

Article: 140232
Subject: Darnit! Broke MXE...
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Tue, 5 May 2009 01:33:40 -0500
Links: << >>  << T >>  << A >>
Feeling empowered and encouraged because MXE-III 6.3c Starter was running so 
well, I downloaded and installed MXE-III 6.4. It had problems compiling the 
EDK 10.1sp3 libraries, aborting the experiment abruptly. Several more 
iterations of failure later, sleep deprivation suggested that ModelSim PE 
student version was a good idea. After all, Xilinx characterizes MXE 
performance relative to PE. A search for license limitations turned up only 
the need to renew the license every 6 months. Alas, I discovered very 
quickly that it suffers the same 10k line limitation as MXE. It stalled at 
about the 80% mark while compiling the ISE libraries. That was my weekend in 
a nutshell.

This evening, I tried in earnest to restore MXE 6.3 to working order. The 
library paths, environment vars, and tools settings are a faint blur in my 
mind, after a weekend of little sleep and much despair. Is there a neat 
checklist somewhere of things to put back in order to get it working again? 
Simulations bomb out on the Microblaze IP, complaining that the library .dat 
file is incompatible. Other modules blow out on various Unisim or other 
components. I've unpacked, installed, recompiled, updated, refreshed, and 
basically stirred around everything that could be stirred around. I've 
reinstalled the 10.1.3 ISE libraries, etc. Recmpiled the EDK libs, which 
reports a varying number of errors each time. Any help would be much 
appreciated.

(I don't know if it's a bad idea or not, but 11.1 is downloading in the 
background as I type this. In for a penny..., as the saying goes. I was 
searching for MXE 6.4 version compatibility on the Xilinx website, when I 
was presented with a download button and a page offering to create floating 
licenses for my DSP stuff and EDK. Oh, what the heck. If it works, the 
recent frustrations will be moot.)

(PPS: and totally unrelated to anything at all... This afternoon, a huge 
housefly noisily buzzed my monitors before landing on the window screen of 
the open window in the upstairs office. Crap! I had no way to invite it 
outside while preventing its escape to buzz the rest of the house. So I 
closed the storm window, trapping it in the narrow space between. He was 
doomed, of course, and there was no way he could know this. From his 
considerable size, he obviously survived the winter, only to come to this 
ignominious end. Long story short, he fought hard to the very end. Through 
it all, I watched him from time to time, and waved various stuff at him to 
keep him agitated and watch his response. I'm pleased and proud for him, for 
never once giving in to despair or frustration. Life is like that for each 
of us at one time or another, I think. My weekend sucked. I wonder this 
moment if 11.1 is the hoped for open window, or just another pretty purple 
plastic fly swatter. 2 hours left to go on the download...)



Article: 140233
Subject: Re: Spartan3E Starter Kit MISO and Flash pin shared
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Tue, 5 May 2009 02:39:17 -0500
Links: << >>  << T >>  << A >>
"mstanisz" <matt.staniszewski@gmail.com> wrote in message 
news:19mdndgAN665R2LUnZ2dnUVZ_qadnZ2d@giganews.com...
> Okay, I went ahead and removed the duplicate NETs in the UCF and made them
> internal.  I'm trying to figure out how to MUX between the two signals
> using a core in EDK.  It does seem like it should be fairly simple, but 
> I'm
> not sure how to go about it with IP cores.  Thanks.

Minimally, define a module with OUT pins for the two now disconnected nets, 
additional pins for selection, and an IN pin for the external net. Add the 
external net to the UCF. This is exactly as you would do for any old simple 
design. There might already be an example or usable hdl in the samples files 
for that board.

My normal workflow wraps the EDK project in an ISE project. Instantiate the 
switcher/mux in the top most module, at the same level you instantiate the 
EDK system. Swap and mix the pins as you need. Take a look at (for a project 
named system.xmp) hdl/system_stub.vhd for an example of instantiating the 
EDK system.

I think it would be a bad idea to tear into the pcore hdl or wrappers to do 
this.


Article: 140234
Subject: Re: ISE/EDK/SDK 11.1 licensing
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Tue, 5 May 2009 02:51:45 -0500
Links: << >>  << T >>  << A >>
"MM" <mbmsv@yahoo.com> wrote in message 
news:7620brF19dgeiU1@mid.individual.net...
> "MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
> news:wePKl.28356$yr3.9710@nlpi068.nbdc.sbc.com...
>>
>> Pardon my musing... Regarding node-locked, is that tied to the MAC 
>> address on an Ethernet device on the licensed system?
>
> Precisely so.

Good grief! Suppose I accidently reconfigured my VNA so flexlm no longer 
worked? Now I'd be in a world of hurt and wishing I had bought a floating 
license instead.




Article: 140235
Subject: ISE 11.1 won't work on Fedora 10 32bit
From: Akhundov Jafar <jafar@hrz.tu-chemnitz.de>
Date: Tue, 05 May 2009 10:05:38 +0200
Links: << >>  << T >>  << A >>
Hi everyone!

I've tried multiple times to install ISE 11.1. After the installation is 
completed I accomplish the product registration and then, when I try to 
start ISE from the XILINX/11.1/ISE directory, I get a segmentation fault.
My kernel version is 2.6.27.21-170.2.56.fc10.i686. Has anyone else 
experienced such problems?

Best wishes
Jafar

Article: 140236
Subject: ISE & VHDL : how to include time/date
From: Nicolas Matringe <nic_o_mat@msn.com>
Date: Tue, 5 May 2009 02:22:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello all
I'm just done with this and since this a quite frequent question I
thought I might give my solution so that the time I struggled with
this probllem will benefit to others.

My time/date is a top-level generic parameter called G_DATE :
  generic (
    G_DATE : string  := "00:00 00/00/00");

I generated a tcl script as explained in this post
http://groups.google.fr/group/comp.arch.fpga/browse_thread/thread/90a6889c77255a7b/eccb486e5f664c20?hl=fr&lnk=gst&q=tcl+date#eccb486e5f664c20

and added this line:
   set current_date [clock format [clock seconds] -format "%H:%M %D"]
which gives me the date in the format I want

I then set the top-level generic parameter
   project set "Generics, Parameters" "G_DATE=\"$current_date\" " -
process "Synthesize - XST"
Do not put spaces around the '=' and put one space between the double
quotes


You can do it in a single (ugly) line:
   project set "Generics, Parameters" "G_DATE=\"[clock format [clock
seconds] -format "%H:%M %D"]\" " -process "Synthesize - XST"

Hope this helps
Nicolas

Article: 140237
Subject: Re: High-speed signals crossing a split-ground
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 5 May 2009 11:24:25 +0100
Links: << >>  << T >>  << A >>

"ee_ether" <xjjzdv402@sneakemail.com> wrote in message 
news:707a89a7-c3cf-4953-b776-b5d36265f5b4@r13g2000vbr.googlegroups.com...

>
> The isolation is due partially to safety and to keep as much noise
> away from analog side as I can.  I haven't found much literature on
> isolation and crossing split-grounds.
>
> Your opinions are welcome.

Don't do this. Use a single ground plane. Route all your signals with great 
discipline, keep digital and analog traces and power supplies away from each 
other. With a split joined at a single point, you'll find the two planes 
make an excellent dipole antenna, radiating broadband noise. Even if by some 
miracle you get it working at all, your product will fail its RFI/EMI tests. 
As another poster said, if you have a safety issue, use a transformer at the 
front end.

Ask the guys at SI-LIST like MM says.

Good luck, Syms. 



Article: 140238
Subject: Re: FIFO that latches data asynchronic manner
From: chewy <steve_baka@hotmail.com>
Date: Tue, 5 May 2009 05:38:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 4, 11:42=A0pm, rickman <gnu...@gmail.com> wrote:
> On May 4, 7:20=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
>
>
>
> > On Mon, 4 May 2009 17:45:21 -0400, "MM" <mb...@yahoo.com> wrote:
> > >"de4" <d...@poczta.onet.pl> wrote in message
> > >news:K8ednSNliKhh02LUnZ2dnUVZ_sCdnZ2d@giganews.com...
> > >> I thinking now how for example InChipScope debbugging in
> > >> circuit working in order to save some asynchronious event in FPGA th=
at can
> > >> occur independly from clock because it is very similar to my task th=
at I'm
> > >> trying to reach....I only know that it stores changes of states in B=
RAM
> > >> but
> > >> how it store asynch states if writing to Block RAM must be synchroni=
ous...
>
> > >ChipScope doesn't do anything at all to help you with capturing async =
events
> > >"properly".
>
> > That's not strictly true. VIO certainly tries to do the right thing to
> > sample the events you select by connecting them to the clock input of
> > a flop which has its data input connected to high. Later an async
> > reset clears the flop for the next event. If your VIO signals are
> > separated enough for this to work, you certainly catch them
> > asynchronously on chip. The fact that they have to be recorded and
> > transported with the jtag clock is a different matter though.
> > --
> > Muzaffer Kal
>
> > DSPIA INC.
> > ASIC/FPGA Design Services
>
> >http://www.dspia.com
>
> I don't understand what this accomplishes. =A0This will catch a positive
> transition, but it does not know when the falling edge is and if the
> positive edge comes while you are resetting the flop, well, it gets
> lost! =A0How is this used exactly? =A0I think I am not getting it.
>
> Rick

I think what Muzaffer is trying to say is, you can capture an
asynchronous EVENT with this method. Certainly not an accurate
waveform, but if all you care about is "did event A happen?", then
you've got your circuit.

I will say, however, that I still prefer oversampling for such
situations.


Steve

Article: 140239
Subject: Re: High-speed signals crossing a split-ground
From: gabor <gabor@alacron.com>
Date: Tue, 5 May 2009 07:10:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 5, 6:24=A0am, "Symon" <symon_bre...@hotmail.com> wrote:
> "ee_ether" <xjjzdv...@sneakemail.com> wrote in message
>
> news:707a89a7-c3cf-4953-b776-b5d36265f5b4@r13g2000vbr.googlegroups.com...
>
>
>
> > The isolation is due partially to safety and to keep as much noise
> > away from analog side as I can. =A0I haven't found much literature on
> > isolation and crossing split-grounds.
>
> > Your opinions are welcome.
>
> Don't do this. Use a single ground plane. Route all your signals with gre=
at
> discipline, keep digital and analog traces and power supplies away from e=
ach
> other. With a split joined at a single point, you'll find the two planes
> make an excellent dipole antenna, radiating broadband noise. Even if by s=
ome
> miracle you get it working at all, your product will fail its RFI/EMI tes=
ts.
> As another poster said, if you have a safety issue, use a transformer at =
the
> front end.
>
> Ask the guys at SI-LIST like MM says.
>
> Good luck, Syms.

I would tend to agree.  In my experience the best bet is to have
one ground plane, but end any digital power plane at the same
cut-off point where you were going to cut the ground.  Make sure
that no digital signals wander into the analog region except
those that directly connect to the A/D converter.  In this
case the bulk of the digital noise in the analog side will
be generated by the converter itself and will hopefully be
synchronous to the sampling rate.  Control signals from the
digital circuitry to the A/D should be slow and therefore
can be filtered at the interface.  Just be sure you can live
with the reduced edge rates on these signals after your filter.

Regards,
Gabor

Article: 140240
Subject: Setting top level VHDL generics in XST
From: rickman <gnuarm@gmail.com>
Date: Tue, 5 May 2009 08:03:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am trying to use a generic at the top level of my code to define
which device family the code is being compiled to.  In XST there is a
property dialog that can attach a generic property to the synthesis
process.  I am using this and not finding that it works.

In the top level code, I assign a default value to the generic which
is what is being used.  Of course, I use the same default value at
every level of the code.  If I remove the default value for the
generic, the tool complains that there is *no* value assigned.  The
value set as the process property shows up in the Synthesis Report
except that in the property dialog box the generic value is enclosed
in double quotes and in the report the trailing quote is missing.
Removing the quotes does not work either.

Am I doing something wrong here?  Does this generic assignment
function work in XST?  Anyone else use it?

Rick

Article: 140241
Subject: Re: High-speed signals crossing a split-ground
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 5 May 2009 11:19:06 -0400
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message 
news:414a5fd8-d826-41aa-bada-c3068096eb8d@s20g2000vbp.googlegroups.com...

> In fact, would that make a good differential pair, to run the traces
> opposite each other with a ground plane between them?

I don't think so. Two sides of such a pair would be subjected to different 
common mode (or in fact not so common) noise which wouldn't be cancelled by 
a receiver. It might be irrelevant for the types of the digital signals  the 
OP is interested in, but it certainly matters for sensitive analog signals.

> The ground currents would clearly cancel in that case.

It's not so clear. At high frequencies the currents flow on the surface of 
the plane. In fact, this can and frequently is used to separate analog from 
digital when space is limited, i.e. you can treat a single physical GND 
plane as almost two separate GND planes relative to the traces above and 
below it.


/Mikhail 



Article: 140242
Subject: Re: problem with high speed data transfer
From: "mingyuexin" <Lijiao.Liu@student.uib.no>
Date: Tue, 05 May 2009 11:34:33 -0500
Links: << >>  << T >>  << A >>
>On Apr 23, 4:35=A0am, 'use_real_email' wrote:
>> Gabor
>> Thank you for the reply.I'm sorry I didn't describe it clearly.
>> --What about data from B to A?
>> No data should be transferred from B to A.
>> --If not can you use LVDS for the interconnect?
>> Yes,I use LVDS for the interconnect .
>> If Virtex2 is the source, you can use DDR flops to drive the
>> interface.
>> I will have a look at DDR flops.
>> --What makes you think the problem is crosstalk? Do you have adequate
>> --grounding on the cables?
>> I just think it should be crosstalk,because 8 links work at the high
>> speed at the same time.The cables are network cables,which are not
>> grounded.
>> --Are you using DCI or series resistors at the driver to reduce
>> overshoot?
>> No,I didn't use any DCI or resistros.Can ou get a single link to work
>> reliably?
>> I just did the test in only B board,which means B sends and B receives
>> it back.
>> For one link,it workes reliably.
>> But for more than one link,it doesn't work,the received data is
>> wrong.when I do post simulation in questasim,more than one links
>> receiver have unknown state.even if I reduce the speed to 100 MHZ,I
>> don't know why.
>>
>> --
>> mingyuexin
>>
------------------------------------------------------------------------
>> mingyuexin's
Profile:http://www.fpgacentral.com/group/member.php?userid=
>=3D72
>> View this
thread:http://www.fpgacentral.com/group/showthread.php?t=3D8959=
>6
>
>So you have not actually successfully tested one link, over cable,
>from one board to a different board?
>
>I suspect the different boards are not properly grounded, since LVDS
>has a very low common mode range, meaning that if their grounds differ
>by much, the data is incomprehendable. You need to provide for a very
>ground connection between the boards. Since your signaling is
>differential, the ground connection need not be in the network cable,
>but it could be put there.  Network cables work with ethernet and no
>common ground because the signals are transformer isolated and have
>almost infinite common mode range.
>
>You may also be having a problem with properly synchronizing the
>incoming data stream and clock. Loop-backs from the same board usually
>share a common clock (already synchronous), so it does not show up
>there.
>
>Andy
>

Thank you all guys, multi channels communicates at the same time
successfully in B board(which was wrong before because my wrong test
code),I know I'm facing the challenge that different boards have
unsynchronized clock.I will test it next week,because A board is not
available now.




Article: 140243
Subject: Re: Setting top level VHDL generics in XST
From: Jan Pech <invalid@void.domain>
Date: Tue, 05 May 2009 19:50:39 +0200
Links: << >>  << T >>  << A >>
Hi Rick,
I do not use ISE GUI but in Makefile driven compilation I set top-level
generics in an XST file using '-generics' parameter. That should have
the same effect as setting it in the GUI. The appropriate line of the
*.xst file might look like this:
-generics {BIDIR=TRUE CHANNELS=1}
Regards, Jan

On Tue, 2009-05-05 at 08:03 -0700, rickman wrote:
> I am trying to use a generic at the top level of my code to define
> which device family the code is being compiled to.  In XST there is a
> property dialog that can attach a generic property to the synthesis
> process.  I am using this and not finding that it works.
> 
> In the top level code, I assign a default value to the generic which
> is what is being used.  Of course, I use the same default value at
> every level of the code.  If I remove the default value for the
> generic, the tool complains that there is *no* value assigned.  The
> value set as the process property shows up in the Synthesis Report
> except that in the property dialog box the generic value is enclosed
> in double quotes and in the report the trailing quote is missing.
> Removing the quotes does not work either.
> 
> Am I doing something wrong here?  Does this generic assignment
> function work in XST?  Anyone else use it?
> 
> Rick


Article: 140244
Subject: Xilinx XPS_INTC and XPS_UARTLITE interrupt issues
From: leevv <leevv@mail.ru>
Date: Tue, 5 May 2009 11:03:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
I've discovered recently the problem with the edge-type interrupts
under the Xilinx EDK.
I heard that it was acknowledged by Xilinx and AR will come out soon.
May be the following will be usefull for somebody.



1) XPS_INTC v1.00a synchronization FFs for the edge-type interrupts.

During the upgrade of the working project from ISE/EDK9.1sp3 to  ISE/
EDK10.1sp3 environment we've got a problem with the skipping
interrupts from the custom =93Interleaver=94 PCORE.

Interrupt subsystem consist of "Interleaver" PCORE ->  XPS_INTC 1.00a -
>  PPC405_virtex4 v2.01a.
"Interleaver" PCORE generates a regular Interrupt pulse every few
mSeconds on asynchronous (relative to XPS_INTC) clk domain. Interrupt
is configured to be a rising-edge-type interrupt. The duration of the
pulse is more then several clk periods of the XPS_INTC clk (100 MHz in
our case), as it=92s required by datasheet.

After analysis with Chipscope it's turns out that the problem is due
to the absence of synchronization flip-flops (FFs) on the interrupt
inputs of the XPS_INTS !!!

I was "surprised" to see the following in the "intc_core.vhd" of the
XPS_INTC pcore:

=20
---------------------------------------------------------------
                -- Process REG_INTR_P to regiter the interrupt signal
=20
---------------------------------------------------------------
                REG_INTR_P : process (Clk) is
                begin
                    if(Clk'event and Clk=3D'1') then
                        if (Rst =3D RESET_ACTIVE) then
                            intr_d1(i) <=3D '1';
                        else
                            intr_d1(i) <=3D Intr(i);
                        end if;
                    end if;
                end process REG_INTR_P;

                -- Creating one-shot rising edge triggered interrupts
                intr_edge(i) <=3D '1' when Intr(i) =3D '1' and intr_d1(i)
=3D '0'
                                 else '0';

As you can see the =93Intr=94 signal, which is the input to the XPS_INTC
module and could be completely ASYNCHRONOUS, is involved in the edge
detection.
There is no synchronization FFs et al! Not even mentioning meta-
stability double FFs.

I added a couple of FFs like this to the rising and falling edge
inputs of XPS_INTC like this:

=20
---------------------------------------------------------------
                -- Process REG_INTR_P to regiter the interrupt signal
=20
---------------------------------------------------------------
                REG_INTR_P : process (Clk) is
                begin
                    if(Clk'event and Clk=3D'1') then
                        if (Rst =3D RESET_ACTIVE) then
                            intr_d1(i) <=3D '0'; intr_d2(i) <=3D '0';
intr_d3(i) <=3D '0';
                        else
                            intr_d3(i) <=3D intr_d2(i);
                            intr_d2(i) <=3D intr_d1(i);
                            intr_d1(i) <=3D Intr(i);
                        end if;
                    end if;
                end process REG_INTR_P;

                -- Creating one-shot rising edge triggered interrupts
               intr_edge(i) <=3D '1' when intr_d3(i) =3D '1' and intr_d2
(i) =3D '0' else '0';

Now Interleaver PCORE works fine. I still don=92t understand how our
project was working under ISE/EDK9.1. There is no synchronization FFs
either in OPB_INTC pcore. May be we were lucky (or unlucky) not to
discover it under 9.1.

But unfortunately this is not the end of the story.

2) XPS_UARTLITE v.1.00a receive interrupt.

Now other edge-type interrupt inputs, which are connected to the
XPS_INTC pcore, have a problem. In particularly the XPS_UARTLITE
pcores has a problem with the receive interrupts. In our system we
have only XPS_UARTLITE and Interleaver pcores which are using edge-
type interrupts. All the rest pcores use level-type interrupts.
In this project one XPS_UARTLITE is used as a debug console for the
Linux and another one is used for the communication with the external
peripheral (Upconverter). Both start to fail after I=92ve made the
modification to XPS_INTC. On the debug console I can see that print-
outs are working fine, while when I=92m typing something in the console
- the RX direction of the XPS_UARTLITE doesn=92t work.

Now I was =93surprised=94 second time to discover in the datasheet that
XPS_UARTLITE generates the edge-type interrupt for the transmit part
and level-type interrupt for the receive part of the pcore. While this
is two completely different types of interrupts, they are both
signaled through one physical output signal of the XPS_UARTLITE
pcore !!!

=20
-------------------------------------------------------------------------
    -- Interrupt register handling
=20
-------------------------------------------------------------------------
    INTERRUPT_DFF: process (Clk) is
    begin
        if Clk'event and Clk =3D '1' then
            if Reset =3D '1' then         -- synchronous reset (active
high)
                Interrupt <=3D '0';
            else
                Interrupt <=3D enable_interrupts and
                             (rx_Data_Present or (tx_Buffer_Empty and
                                             not
tx_Buffer_Empty_Pre));
            end if;
        end if;
    end process INTERRUPT_DFF;

Here the =93rx_Data_Present=94 signal is the level-type interrupt,
indicating that Receive buffer is not empty.
I=92m not sure either the root of the problem is in the low-level
software driver, which handle the XPS_UARTLITE interrupts or something
else, but I think it=92s better to have both TX and RX interrupts to be
edge-type anyway, especially if interrupt signal from the XPS_UARTLITE
coming to the single edge-type input of the XPS_INTC. So I changed it
to be edge type, and now it works fine.

-------------------------------------------------------------------------
    -- convert level RX interrupt to rising edge
    Process (Clk) is
    begin
        if (Clk'event and Clk =3D '1') then
            if Reset =3D '1' or enable_interrupts=3D'0' then
                rx_Data_Present_Pre <=3D '0';
            else
                rx_Data_Present_Pre <=3D rx_Data_Present;
            end if;
        end if;
    end process ;

=20
-------------------------------------------------------------------------
    -- Interrupt register handling
=20
-------------------------------------------------------------------------
    INTERRUPT_DFF: process (Clk) is
    begin
        if Clk'event and Clk =3D '1' then
            if Reset =3D '1' then         -- synchronous reset (active
high)
                iInterrupt <=3D '0';
            else
                iInterrupt <=3D enable_interrupts and
                              ((rx_Data_Present  and not
rx_Data_Present_Pre) or
                             (tx_Buffer_Empty and not
tx_Buffer_Empty_Pre));
            end if;
        end if;
    end process INTERRUPT_DFF;


As a conclusion. Somebody should be very careful about designing
Interrupt-related modules in a system (hardware or software). This
kind of problem potentially could cause very rare and weird
malfunctioning of the system which is very-very difficult to catch.







Article: 140245
Subject: Re: Setting top level VHDL generics in XST
From: gabor <gabor@alacron.com>
Date: Tue, 5 May 2009 13:09:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 5, 1:50=A0pm, Jan Pech <inva...@void.domain> wrote:
> Hi Rick,
> I do not use ISE GUI but in Makefile driven compilation I set top-level
> generics in an XST file using '-generics' parameter. That should have
> the same effect as setting it in the GUI. The appropriate line of the
> *.xst file might look like this:
> -generics {BIDIR=3DTRUE CHANNELS=3D1}
> Regards, Jan
>
> On Tue, 2009-05-05 at 08:03 -0700, rickman wrote:
> > I am trying to use a generic at the top level of my code to define
> > which device family the code is being compiled to. =A0In XST there is a
> > property dialog that can attach a generic property to the synthesis
> > process. =A0I am using this and not finding that it works.
>
> > In the top level code, I assign a default value to the generic which
> > is what is being used. =A0Of course, I use the same default value at
> > every level of the code. =A0If I remove the default value for the
> > generic, the tool complains that there is *no* value assigned. =A0The
> > value set as the process property shows up in the Synthesis Report
> > except that in the property dialog box the generic value is enclosed
> > in double quotes and in the report the trailing quote is missing.
> > Removing the quotes does not work either.
>
> > Am I doing something wrong here? =A0Does this generic assignment
> > function work in XST? =A0Anyone else use it?
>
> > Rick
>
>

I've used the "Verilog Macros" box in the same dialog which should
have a similar syntax.  I found that it was finicky about spaces.
In the examples it showed multiple entries separated by vertical
bars ( "|" ) and spaces, but I found that I needed to remove
all spaces around the bars as well as around the equal signs.
It's been a while since I did it, but if memory serves me correctly
I needed to get rid of the quotes, too.

Regards,
Gabor

Article: 140246
Subject: Re: Setting top level VHDL generics in XST
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Tue, 05 May 2009 22:36:07 +0200
Links: << >>  << T >>  << A >>
rickman a écrit :
> I am trying to use a generic at the top level of my code to define
> which device family the code is being compiled to.  In XST there is a
> property dialog that can attach a generic property to the synthesis
> process.  I am using this and not finding that it works.
> 
> In the top level code, I assign a default value to the generic which
> is what is being used.  Of course, I use the same default value at
> every level of the code.  If I remove the default value for the
> generic, the tool complains that there is *no* value assigned.  The
> value set as the process property shows up in the Synthesis Report
> except that in the property dialog box the generic value is enclosed
> in double quotes and in the report the trailing quote is missing.
> Removing the quotes does not work either.
> 
> Am I doing something wrong here?  Does this generic assignment
> function work in XST?  Anyone else use it?

Hi Rick
Have a look at my last post (today, subject "ISE & VHDL : how to include 
time/date")
At least in the tcl script there must be a space between final quotes. I 
don't know how you can fix this in the GUI though

Nicolas

Article: 140247
Subject: Re: Spartan3E Starter Kit MISO and Flash pin shared
From: "mstanisz" <matt.staniszewski@gmail.com>
Date: Tue, 05 May 2009 15:57:30 -0500
Links: << >>  << T >>  << A >>
The MISO and data<0> signals are bidirectional (IO).  Can you make a
mux/switcher and bus splitter for bidirectional signals?

Matt

>"mstanisz" <matt.staniszewski@gmail.com> wrote in message 
>news:19mdndgAN665R2LUnZ2dnUVZ_qadnZ2d@giganews.com...
>> Okay, I went ahead and removed the duplicate NETs in the UCF and made
them
>> internal.  I'm trying to figure out how to MUX between the two signals
>> using a core in EDK.  It does seem like it should be fairly simple, but

>> I'm
>> not sure how to go about it with IP cores.  Thanks.
>
>Minimally, define a module with OUT pins for the two now disconnected
nets, 
>additional pins for selection, and an IN pin for the external net. Add
the 
>external net to the UCF. This is exactly as you would do for any old
simple 
>design. There might already be an example or usable hdl in the samples
files 
>for that board.
>
>My normal workflow wraps the EDK project in an ISE project. Instantiate
the 
>switcher/mux in the top most module, at the same level you instantiate
the 
>EDK system. Swap and mix the pins as you need. Take a look at (for a
project 
>named system.xmp) hdl/system_stub.vhd for an example of instantiating the

>EDK system.
>
>I think it would be a bad idea to tear into the pcore hdl or wrappers to
do 
>this.
>
>

Article: 140248
Subject: Re: Xilinx XPS_INTC and XPS_UARTLITE interrupt issues
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 5 May 2009 17:13:34 -0400
Links: << >>  << T >>  << A >>
"leevv" <leevv@mail.ru> wrote in message 
news:26e4d8a3-8437-4498-a929-550be1b7a67a@m24g2000vbp.googlegroups.com...

> Now I was “surprised” second time to discover in the datasheet that
> XPS_UARTLITE generates the edge-type interrupt for the transmit part
> and level-type interrupt for the receive part of the pcore. While this
> is two completely different types of interrupts, they are both
> signaled through one physical output signal of the XPS_UARTLITE pcore !!!


This was a known problem with UARTLITE since long ago. I agree, it is 
completely ridiculous. To add to the confusion in *.mpd file the type of 
interrupt for UARTLITE was set to edge-sensitive.

/Mikhail 



Article: 140249
Subject: Code blocks to realize this in VHDL
From: "mstanisz" <matt.staniszewski@gmail.com>
Date: Tue, 05 May 2009 16:27:20 -0500
Links: << >>  << T >>  << A >>
I've searched a little more and found that if I can somehow merge Ben
Cohen's 0 ohm device
(http://groups.google.com/group/comp.lang.vhdl/msg/7d14832588a0cabb) with a
bi-directional MUX
(http://www.tek-tips.com/viewthread.cfm?qid=1188582&page=7), then I might
be able to create the VHDL module I would need.  The bus splitting doesn't
need a module, since in VHDL I'll just manipulate bit0 of the inputted
flash data bus and pass the other 7 bits through.  Would this work? 
Thanks.

Matt



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