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
Hi. We are a couple of guys, working on a school project. We are
trying to get the Xilkernel up and running, on the Spartan 3E starter
kit. We are getting these streams from the debugger:
XMK: Starting kernel.
XMK: Initializing Hardware.
XMK: System initialization.
From these streams we can tell that the function xilkernel_init (); is
running. But we expect that after xilkernel_init (); has finished, the
function xilkernel_start (); should be called next. (see function
"void xilkernel_main()" below) So our guess is that we somehow is
stuck in the xilkernel_init (); function. Because the first thing
xilkernel_start (); should do is to stream out "XMK: Process
scheduling starts.",but nothing happens. (see function "void
xilkernel_start ()" below). This code is taken from the
xilkernel:void xilkernel_main()
{
DBG_PRINT("XMK: Starting kernel.\r\n");
xilkernel_init ();
xilkernel_start ();
} void xilkernel_start ()
{
DBG_PRINT("XMK: Process scheduling starts.\r\n");
#if defined (MB_XILKERNEL)
microblaze_enable_interrupts();
#elif defined (PPC_XILKERNEL)
XExc_mEnableExceptions (XEXC_NON_CRITICAL);
#endif idle_task
(); // Does not
return
} So we think the question we should be asking is:How do we get the
scheduler running ?
This is our mss file:
BEGIN OS
PARAMETER OS_NAME = xilkernel
PARAMETER OS_VER = 4.00.a
PARAMETER PROC_INSTANCE = microblaze_0
PARAMETER sysintc_spec = xps_intc_0
PARAMETER stdout = RS232_DCE
PARAMETER stdin = RS232_DCE
PARAMETER config_pthread_mutex = true
PARAMETER systmr_freq = 50000000
PARAMETER systmr_dev = delay
PARAMETER config_debug_support = true
PARAMETER debug_mon = true
PARAMETER verbose = true
PARAMETER systmr_interval = 5
PARAMETER max_readyq = 10
PARAMETER n_prio = 32
PARAMETER sched_type = SCHED_RR
PARAMETER config_sched = true
PARAMETER config_pthread_support = true
PARAMETER max_pthread_mutex_waitq = 10
PARAMETER max_pthread_mutex = 10
PARAMETER pthread_stack_size = 1000
PARAMETER max_pthreads = 10
PARAMETER systmr_spec = true
PARAMETER static_pthread_table = ((shell_main,1))
END
Source file:
#include "xmk.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <os_config.h>
#include <sys/process.h>
#include <pthread.h>
void* shell_main(void *dummy)
{
return 0 ;
}
int main()
{
xilkernel_main();
}
Article: 132226Hi, MicroBlaze in EDK 9.2 can use either PLB46 or OPB. There is a new parameter "C_INTERCONNECT" on MicroBlaze which specify what bus standard to use. The default value is PLB46 so if you port a design that is using OPB, make sure that this parameter is set for OPB. Göran "wicky" <wicky.zhang@gmail.com> wrote in message news:bc03051e-9376-408d-a0f7-326c8ccbee6f@b5g2000pri.googlegroups.com... On May 16, 3:09 pm, karthick <karthick...@gmail.com> wrote: > We are using SPARTAN 3 E FPGA. I would like to know what is the > difference between ISE 8.2i and ISE 9.2i with respect to the micro > blaze core. > We are able to access the FLASH and RTC via SPI in 8.2i whereas the > same is not possible in 9.2i. > So we would like to know what is the difference between 8.2i and 9.2i. The most diffirence is that the new version of MicroBlaze use the unify PLB46 bus and OPB bus is no longer available, thus your opb peripherials need to be updated to PLB46. Best Regards, WickyArticle: 132227
On May 16, 4:07 pm, austin <aus...@xilinx.com> wrote: > Rate, > > Why do you need to reset the FPGA after some number of software errors? > Won't the software errors just re-occur? How does resetting > (restarting) the FPGA affect the software? > > To start over, forgetting everything, the best way is to pull PROG > (low). Tying an output of the same FPGA to the PROG line input is not > something we can easily recommend, as unless we really have it tested, > that is a race condition (as the first thing that happens when PROG is > pulled low, is all IOs go tristate!). > > I believe this works for some parts...and perhaps Peter will chime in > and let me know which one(s). > > Austin Hi Austin , Our hardware development is at its infancy. There are some hardware bugs , for which I have come up with software workarounds(hacks!) But it is very important we provide an interim solution to the customer that works. So if the number of hardware problems spotted by the software goes over a threshold I would like to reconfigure the hardware and start execution agian. The part that I am using is XC3S1500-4FG676. Any advice on handling the prog line effectively would be greatly appreciated. BR RateArticle: 132228
On May 19, 8:56 am, ratemonotonic <niladri1...@gmail.com> wrote: > On May 16, 4:07 pm, austin <aus...@xilinx.com> wrote: > > > > > Rate, > > > Why do you need to reset the FPGA after some number of software errors? > > Won't the software errors just re-occur? How does resetting > > (restarting) the FPGA affect the software? > > > To start over, forgetting everything, the best way is to pull PROG > > (low). Tying an output of the same FPGA to the PROG line input is not > > something we can easily recommend, as unless we really have it tested, > > that is a race condition (as the first thing that happens when PROG is > > pulled low, is all IOs go tristate!). > > > I believe this works for some parts...and perhaps Peter will chime in > > and let me know which one(s). > > > Austin > > Hi Austin , > > Our hardware development is at its infancy. There are some hardware > bugs , for which I have come up with software workarounds(hacks!) > > But it is very important we provide an interim solution to the > customer that works. So if the number of hardware problems spotted by > the software goes over > > a threshold I would like to reconfigure the hardware and start > execution agian. > > The part that I am using is XC3S1500-4FG676. > > Any advice on handling the prog line effectively would be greatly > appreciated. > > BR > > Rate Will an external IC e.g. 555 timer do ? What are the timing requirement for resetting the FPGA i.e how long will the prog line pulled down for? BR RateArticle: 132229
Yes, I'm using a camera link interface. I'm generating a 140 MHz clock (3.5 x 40 MHz) and using both rising and falling edges to achieve the desired 280 MHz clock. 378 Mbps is the camera data rate, id est, it sends 30 fps (each frame is 1024 x 1024 pixels of size and each pixel is digitized with 12 bits). A bad skew could be the problem, I think i'll try to implement de-skew on the v4 (I don't know how yet) and if it doesn't work i'll use a pre- fpga stage using the ni receiver... I have to use the described cable because my application needs to pass through two walls and needs to have two discontinuities (in order to fit the mechanical and optical subsystems)Article: 132230
Yes i'm using a camera link interface. I generating a 140 MHz clock (3.5 x 40 MHz) and using both rising and falling edges to achieve the desired 280 MHz clock. My camera is sending 30 fpgs (each frame is 1024 x 1024 pixels of size and each pixel is 12 bits digitized). A bad skew could be the problem, i think i'll try to use the v4 de- skew features (i don't know how yet) and it doesn't work i'll use a pre-fpga stage including the ni receiver (which works fine)... I have to use the described cable because in my application such cable must pass through two walls (and it's not possible to change it in order to fit the mechanical and optical subsystems). Thank you for your answerArticle: 132231
On Sun, 18 May 2008 11:25:15 +0100, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Sun, 18 May 2008 08:22:24 +0100, Brian Drummond wrote: > >>I wrote: VHDL is not a dynamically typed language; you can't stretch and >>shrink subtypes e.g. ranges during run time. >> >>Which makes sense if you think about its orientation as a hardware >>language; it is difficult to stretch and shrink registers or counters >>after synthesis. > >Yes, but subprograms (procedures and functions) are dynamically >elaborated: all their arguments, and their local variables, are >constructed dynamically at the moment of invocation. This is >what allows you to handle unconstrained arguments so elegantly. >For synthesis, the tool must convince itself that each subprogram >call is in a context in which the tool can statically determine >what will get elaborated; in other words, you effectively get >a new static instance of each subprogram for each distinct >invocation. Absolutely; I didn't mean anything different. I possibly misread Rickman's post; that he was re-calling the function for a different value of the same variable in the same instance of the same process. Which is not clear is the case. Otherwise, I agree, it looks like a bug. I have found problems with ISE incorrectly synthesising different calls to a procedure in the same process so a similar bug in their simulator is credible. >Alternatively, there may be other ways to get your >type conversion, saving you the trouble of fighting >a possibly buggy FMF package. Converting a SLV to >its hex text representation is easy enough. That's why I was suggesting a static range, and using the parameter's length attribute to determine the number of digits. - BrianArticle: 132232
Hi, Thanks for all this information. I notice that there is some discussion on the possibilities of 3.3V IO with Cyclone 3. What's your experience with 3V3 IO and Cyclone 3, is it just a case of proper termination or are there other problems? thanks, KarelArticle: 132233
On May 16, 4:52 pm, explore <chethanzm...@gmail.com> wrote: > Hi, > I have been running my designs on ISE 9.2i for a virtex-5 LX110t FPGA. > The time taken by the tool to complete a full synthesis and > implementation is a little over 3 hours on a Core2 Quad CPU running at > 2.4 GHz with 2GB of RAM and Windows XP Pro 32-bit edition. I have > tried using ISE 10.1 and have observed that the time taken to run the > same design is less than 2 hrs. I have read the threads on Xilinx > about using more memory, I will be upgrading my memory to 3 GB or > more. I would like to get some recommendations for a system > configuration in terms of the best suitable processor, memory and any > other useful configuration to bring down the synthesis-map-par run- > time. The other discussion threads that I went through were either old > or did not point to an optimal configuration. Your inputs will be > helpful and is highly appreciated. > > Thanks! First off, a multiprocessor/core system won't do you much since the tools do *NOT* support any type of SMP currently. And if you read through the previous discussions about it, you'll see there's a lot of feet dragging with trying to actually implement it as well. Secondly, from what I've seen here's what you really need: a) a TON of RAM with a 64bit OS to actually support it. b) the fastest processor with the most cache: probably one of the nice big Xeon's. I have been working on the Core2Duo 6600's for my designs and they've been alright. I have a Xeon w/ 4MB of cache sitting in the lab w/ RH and I have been meaning to get around to testing a build on it, and comparing it between my P4D-3.2Ghz and the Core2Duo 6600. If I ever get around to it, I'll post the results. -- MikeArticle: 132234
Hi
I should have some kind of PRNG that generates me for each clock
2 random bits. I was thinking for a start of implementing an
8-bit LSFR and just using then the last two bits as output.
I am just wondering if there is an easy way to change the seed
in each run when I initialise the temp variable? The design
should work on an FPGA in the end ;)
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
entity PRNG is
port (
clk : in std_logic;
R0 : out std_logic;
R1 : out std_logic
);
end PRNG;
architecture Behavior of PRNG is
begin
process(clk)
variable temp : std_logic_vector(7 downto 0) := B"01111101";
begin
temp := (temp(1) xor temp(0)) & temp(7 downto 1);
R0 <= temp(0);
R1 <= temp(1);
end process;
end architecture Behavior;
Many thanks,
Clemens
Article: 132235On May 19, 1:35 am, vikram <vikram...@gmail.com> wrote: > hello, > > I am trying to interface between my pc (windows) and a Xilinx > Virtex2Pro board using ethernet. i am told i require Xilinx PLB > Ethernet MAC ip core. i must admit i am very new to such work, forgive > my blatantness.... i would like to know: > > 1) What exactly do i get in the Xilinx Ethernet MAC ip core? (design > files etc?) You get the unlocked CoreGen core. In other words, you could generate the core from CoreGen and use it however. Or, you'll be able to use it directly in EDK. Of course, since you're referring to the V2Pro, you're also referring to the Softcore MAC. This provides a full MAC capable of performing 10/100 communication. Starting with EDK 9.2, the OPB version of the core has been released for 'free' (included w/ the purchase of EDK 9.2). > 2) Using XPS (EDK 9.1) and ISE 9.1, how do i integrate it into an > existing project? It will appear as an unlocked core in the High-Speed communications category of the EDK core list in any of your projects. > 3) the ethernet is just a part of the project.... i only need to > transfer data between my pc and the board.... should the MAC be a part > of the board? Well, Ethernet is split into multiple parts. The first part is the PHY or the physical communication. This provides the lowest layer to which the data is transmitted. This device is responsible for conversion from a Media-Independent Interface (R/S/G/MII) to the physical layer: copper/fiber/etc. The next layer up is the MAC: Media Access Control. This provides the conversion from your real data into a Media- Independent Interface (R/S/G/MII). So unless you're going to build your own MAC and design it to meet all of the IEEE specs for whatever MII you use, then YES you need it. > 4) do i have to use an embedded processor (microblaze/powerpc) to > integrate the MAC? No, but depending on what you're doing you may want to have processor perform the work. It's possible to create devices that just take/put streams with solely logic and state machines. But if you want to start handling TCP traffic or anything higher-layer (HTTP/FTP) or more complicated you will probably want a processor and software to handle it. But that's my $0.02. -- MikeArticle: 132236
On May 19, 2:51 am, Jespr <DonMad...@gmail.com> wrote: > Hi. We are a couple of guys, working on a school project. We are > trying to get the Xilkernel up and running, on the Spartan 3E starter > kit. We are getting these streams from the debugger: > XMK: Starting kernel. > XMK: Initializing Hardware. > XMK: System initialization. > From these streams we can tell that the function xilkernel_init (); is > running. But we expect that after xilkernel_init (); has finished, the > function xilkernel_start (); should be called next. (see function > "void xilkernel_main()" below) So our guess is that we somehow is > stuck in the xilkernel_init (); function. Because the first thing > xilkernel_start (); should do is to stream out "XMK: Process > scheduling starts.",but nothing happens. (see function "void > xilkernel_start ()" below). This code is taken from the > xilkernel:void xilkernel_main() > > <SNIP> > This is our mss file: > <SNIP> You didn't provide your MHS file, which would help out a little more with respect to your problem. Did you follow the XilKernel requirements of having an external timer for support on the Microblaze? -- MikeArticle: 132237
On Mon, 19 May 2008 13:44:21 +0100, Clemens wrote: >I should have some kind of PRNG that generates me for each clock >2 random bits. I was thinking for a start of implementing an >8-bit LSFR and just using then the last two bits as output. Don't do that. R(0) on the next clock will then be exactly the same as R(1) on this clock. Not very random-like. Consider using two separate LFSRs of different lengths to generate the two bits. >I am just wondering if there is an easy way to change the seed >in each run when I initialise the temp variable? So, on an FPGA what do you mean by "on each run"? Do you want each build of the FPGA to have a different seed, or do you want the FPGA to choose a different seed each time it powers-up? The first of these is achieved by cunning scripts, the second probably by exploiting some variable physical behaviour such as the value of a real-time clock. I guess it's fair to say that *either* there must be something nonvolatile in your system that can keep track of time-of-day, or perhaps save some state across power cycles; *or* there must be some way to measure a physical effect at the moment you start up. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 132238
> Don't do that. R(0) on the next clock will then be exactly > the same as R(1) on this clock. Not very random-like. > > Consider using two separate LFSRs of different lengths to > generate the two bits. Thanks Jonathan, I just saw this not very random like behaviour in the simulator ;). So I am thinking of using two 16-bit LFSRs with different seeds each providing one bit of information. > So, on an FPGA what do you mean by "on each run"? Do you want > each build of the FPGA to have a different seed, or do you want > the FPGA to choose a different seed each time it powers-up? A different seed for each power-up would have been nice. Its not in an end product, I am just doing some "research" and it would be interesting to evaluate the behaviour of my implementation with different seeds for different runs. If the worst comes to the worst I have to sythesise the design with a different hardcoded seeds each time... Cheers, ClemensArticle: 132239
On 19 Mai, 15:20, Clemens <Clem...@hotmail.com> wrote: > A different seed for each power-up would have been nice. Its not in an > end product, I am just doing some "research" and it would be interesting > to evaluate the behaviour of my implementation with different seeds for > different runs. If the worst comes to the worst I have to sythesise the > design with a different hardcoded seeds each time... Run the LFSRs continously and start your application with a pushbutton. This should produce enough randomness for requirements as low as yours. KoljaArticle: 132240
Clemens wrote: > >> Don't do that. R(0) on the next clock will then be exactly >> the same as R(1) on this clock. Not very random-like. >> >> Consider using two separate LFSRs of different lengths to generate the >> two bits. > > Thanks Jonathan, I just saw this not very random like behaviour in the > simulator ;). So I am thinking of using two 16-bit LFSRs with different > seeds each providing one bit of information. You could also modify the LFSR to make it perform several steps at each clock cycle.Article: 132241
On 16 mai, 19:12, dajjou <swissiyous...@hotmail.fr> wrote: Dajjou , i think they start by GCLK frame M.BArticle: 132242
Any external one-shot device would be sufficient, Holding PROG_b low is specified in the data sheet (page 41, config user's guide): it states it is asynchronous, which means that basically you just need to bring the line low long enough for the internal logic to reset. Based on simulations, this is probably in the 1 to 5 ns range, so I would do something with margin, say have a minimum of 10 ns low to assert PROG_b. Placing an external cap doesn't help (we are still going tristate as soon as the PROG_b is recognized...). A capacitor is not a true delay line....but: A delay line (10 ns of coax or PCB trace, or external buffers) would also work. Austin ratemonotonic wrote: > On May 16, 4:07 pm, austin <aus...@xilinx.com> wrote: >> Rate, >> >> Why do you need to reset the FPGA after some number of software errors? >> Won't the software errors just re-occur? How does resetting >> (restarting) the FPGA affect the software? >> >> To start over, forgetting everything, the best way is to pull PROG >> (low). Tying an output of the same FPGA to the PROG line input is not >> something we can easily recommend, as unless we really have it tested, >> that is a race condition (as the first thing that happens when PROG is >> pulled low, is all IOs go tristate!). >> >> I believe this works for some parts...and perhaps Peter will chime in >> and let me know which one(s). >> >> Austin > > Hi Austin , > > Our hardware development is at its infancy. There are some hardware > bugs , for which I have come up with software workarounds(hacks!) > > But it is very important we provide an interim solution to the > customer that works. So if the number of hardware problems spotted by > the software goes over > > a threshold I would like to reconfigure the hardware and start > execution agian. > > The part that I am using is XC3S1500-4FG676. > > Any advice on handling the prog line effectively would be greatly > appreciated. > > BR > > RateArticle: 132243
He told me why, He is a student. AustinArticle: 132244
On May 18, 11:28 pm, kris2552 <muralee.vkris...@gmail.com> wrote: > could anybody please explain me ....whether is there any chance of > clock skew being greater than or equal to the time period of the clock? > If so,what are the effects? Any explanation would be deeply > appreciated..... > Thanks in advance.... Yes, there is. Bad effects. When I was teaching, I would check the usenet to see if my questions were being posted; they were really quite easy to spot. Zero points for the person(s) who just copied the answers off of the responses.Article: 132245
Clemens wrote: > >> Don't do that. R(0) on the next clock will then be exactly >> the same as R(1) on this clock. Not very random-like. >> >> Consider using two separate LFSRs of different lengths to generate the >> two bits. > > Thanks Jonathan, I just saw this not very random like behaviour in the > simulator ;). So I am thinking of using two 16-bit LFSRs with different > seeds each providing one bit of information. > >> So, on an FPGA what do you mean by "on each run"? Do you want >> each build of the FPGA to have a different seed, or do you want the >> FPGA to choose a different seed each time it powers-up? > > A different seed for each power-up would have been nice. Its not in an > end product, I am just doing some "research" and it would be interesting > to evaluate the behaviour of my implementation with different seeds for > different runs. If the worst comes to the worst I have to sythesise the > design with a different hardcoded seeds each time... > > Cheers, > Clemens Not sure it matters in your application, but two 16-bit LFSRs still only provide as much randomness as one 16-bit LFSR, i.e. you still have a repetition length of 2^16-1. Conversely, a 16-bit LFSR feeding one bit, and a 15-bit LFSR feeding the other, have a much higher repetition length. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 132246
On May 16, 1:25=A0pm, Peter Alfke <pe...@xilinx.com> wrote: > On May 16, 8:07=A0am, austin <aus...@xilinx.com> wrote: > > > > > Rate, > > > Why do you need to reset the FPGA after some number of software errors? > > =A0Won't the software errors just re-occur? =A0How does resetting > > (restarting) the FPGA affect the software? > > > To start over, forgetting everything, the best way is to pull PROG > > (low). =A0Tying an output of the same FPGA to the PROG line input is not= > > something we can easily recommend, as unless we really have it tested, > > that is a race condition (as the first thing that happens when PROG is > > pulled low, is all IOs go tristate!). > > > I believe this works for some parts...and perhaps Peter will chime in > > and let me know which one(s). > > > Austin > > To re-configure, you must pull down PROG for a certain length of > time,expressed in microseconds.If you use one FPGA output to do this, > you face a dilemma: Once reconfiguration starts, every output is being > 3-stated, which violated the min PRG=3DLow time requirement.In older > parts, this self-triggering worked reliably "by design", since both > reconfiguration and 3-stating were controlled by a common latch. Once > set, there was no way to stop configuration. > This nice design was changed in some of the Virtex and probably also > in some of the Spartan parts, just because the rationale for the > previous design methodology was forgotten (its impact had never been > officially documented anyhow). I'll try to find out, once and for all, > which parts are designed which way. > In future parts we intend to re-institute the old design method, since > it offers one unbeatable advantage... > Peter Alfke In Spartan-3 and Spartan 3E you need an external delay. In Spartan3A and its derivatives (AN, DSP and future devices) the safe operation is guaranteed by design: just use one output to drive PROG Low. Virtex, Virtex-II and Virtex-4 need an external delay. Virtex-5 has an internal controller that can start re-configuration (see Config User Guide, page 145). Peter AlfkeArticle: 132247
this is my code:
entity Top_Module is
port (
o_DSP0 : out MyRecordType
);
end Top_Module;
whe o_DSP0 is:
type MyRecordType is record
int4 : std_logic;
int5 : std_logic;
int6 : std_logic;
int7 : std_logic;
end record;
---------------
How is o_DSP0 declared in ucf file?
Article: 132248Altera have put out a press release announcing Stratix IV. Handbook http://www.altera.com/literature/hb/stratix-iv/stx4_5v4.pdf. Interestingly it's gone 40nm and does not appear to have a true 3.3V compatability so buy your shares in manufacurers of bus switches now. John Adair Enterpoint Ltd.Article: 132249
Pablo wrote:
> How is o_DSP0 declared in ucf file?
A vhdl port type is declared in a package file.
The package file must be listed
in the synthesis file list,
above all files using the package.
-- Mike Treseler
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