Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 140226On 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. RickArticle: 140227
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: 140228On 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.comArticle: 140229
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. -- glenArticle: 140230
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. RickArticle: 140231
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
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
"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
"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
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 JafarArticle: 140236
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"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
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. SteveArticle: 140239
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, GaborArticle: 140240
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? RickArticle: 140241
"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. /MikhailArticle: 140242
>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
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
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
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: 140246rickman 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 NicolasArticle: 140247
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
"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. /MikhailArticle: 140249
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:
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