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
Marlboro schrieb: > Will it be available in Spartan2 or VirtexE? > Spartan2/virtexE are supported AnttiArticle: 109101
In article <1158792992.714588.34210@h48g2000cwc.googlegroups.com>, "Antti" <Antti.Lukats@xilant.com> wrote: > David Ashley schrieb: > > > Assuming it must be free + open source, does anyone have > > any recommendations? 32 bit minimum. I was looking > > at the plasma on opencores. Has anyone done a uclinux > > port or thought of doing one? Conversely if someone wants > > a uclinux port to plasma I'll do it for $$$. :) > > > > -Dave > > > > > > -- > > David Ashley http://www.xdr.com/dash > > Embedded linux, device drivers, system architecture > David, > > how much $$$ are we talking about? > I am looking for open-source core with uclinux, but OR1K is too large > > Antti I think the leon3 is smaller then the or1k.. But if im wrong ill be corrected :) its also 'standard' so all the tools/os/etc are out there today. Less development.Article: 109102
In article <1158770147.385889.73830@m73g2000cwd.googlegroups.com>, "Antti" <Antti.Lukats@xilant.com> wrote: > Kyle H. schrieb: > > > Is this not similar to Xilinx's PPC and MicroBlaze cores using EDK? > > > > Possibly a much cheaper solution? > > > > Regards, > > Kyle > Hi Kyle, > > using PPC or MicroBlaze usually requires both ISE and EDK and usually > some hardware (HDL) knowledge as well - isnt that so? > > using MicroFpga requires only > 1) FPGA > 2) C compiler > > it does *NOT* require > 1) FPGA vendor provided tools > 2) any HDL knoweldge > > there is a difference I think ;) > > Antti Seen as its currently only for "selected EAP members", will it have a cost once its released? If so, people like me will need to stick to other 'free' cores.Article: 109103
Has anyone been able to get montavista4.0.1 to build a 2.6 kernel for the mini-module? I get a build but the kernel crashes trying to allocate kernel cache memory: loaded at: 00400000 004E913C board data at: 004E7124 004E713C relocated to: 004051E4 004051FC zimage at: 00405A3D 004E6BC4 avail ram: 004EA000 04000000 Linux/PPC load: console=tty1 console=ttyS0,9600 ip=on root=/dev/xsysace2 rw Uncompressing Linux...done. Now booting the kernel Linux version 2.6.10_mvl401-ml40x (Administrator@Rachel_d600) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.100.0600797 2006-06-06)) #4 Wed Sep 20 19:14:20 EDT 2006 Xilinx ML40x Reference System (Virtex-4 FX) Port by MontaVista Software, Inc. (source@mvista.com) Built 1 zonelists Kernel command line: console=tty1 console=ttyS0,9600 ip=on root=/dev/xsysace2 rw Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000 PID hash table entries: 512 (order: 9, 8192 bytes) hr_time_init: arch_to_nsec = 20971520, nsec_to_arch = 429496729 Console: colour dummy device 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 62848k available (1452k kernel code, 452k data, 116k init, 0k highmem) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Badness in __schedule at kernel/sched.c:2842 Call trace: [c0003a64] check_bug_trap+0x98/0xdc [c0003c98] ProgramCheckException+0x1f0/0x2b4 [c00032a4] ret_from_except_full+0x0/0x4c [c01674c4] __schedule+0x28/0x728 [c0167c34] preempt_schedule+0x70/0xa4 [c003e04c] buffered_rmqueue+0x2ec/0x2f8 [c003e120] __alloc_pages+0xc8/0x3ac [c003e42c] __get_free_pages+0x28/0x68 [c0042c80] cache_alloc_refill+0x32c/0x5d0 [c00426dc] kmem_cache_alloc+0x68/0x6c [c006436c] sget+0xc4/0x3fc [c006558c] get_sb_single+0x34/0xcc [c009b700] sysfs_get_sb+0x1c/0x2c [c0065680] do_kern_mount+0x5c/0x118 [c01d2e8c] sysfs_init+0x48/0x80 kmem_cache_create: Early error in slab bdev_cache kernel BUG in kmem_cache_create at mm/slab.c:1209! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT NIP: C0043C94 LR: C0043C94 SP: C01BFF60 REGS: c01bfeb0 TRAP: 0700 Not tainted MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c0198710[0] 'swapper' THREAD: c01be000 Last syscall: 0 GPR00: C0043C94 C01BFF60 C0198710 00000035 00000703 FFFFFFFF 00000001 00000720 GPR08: C01F0000 C01C0000 00000000 C01BE000 44000028 00003570 02001400 00000000 GPR16: 00000001 00000001 FFFFFFFF 007FFF00 01FFAA80 C0065E54 00000003 00000000 GPR24: 00000000 C0176A18 FF950040 78737973 00062000 C01A0000 00000000 00000188 NIP [c0043c94] kmem_cache_create+0x5c/0x5e0 LR [c0043c94] kmem_cache_create+0x5c/0x5e0 Call trace: [c01d2078] bdev_cache_init+0x3c/0xb0 [c01d2424] vfs_caches_init+0xf0/0x108 [c01c05dc] start_kernel+0x12c/0x170 [c000225c] start_here+0x44/0xb0 Kernel panic - not syncing: Aiee, killing interrupt handler! <0>Rebooting in 180 seconds..<NULL> Near as I can tell it is crashing because it thinks it's in an interrupt when it goes to allocate the kernel cache. It's got to be something simple like the interrupt controller is programmed wrong based on my xparm.h file. Anyway, does anybody have a 2.6 kernel working on mini-module? So far neither MV or Xilinx have been any help. Thanks, ClarkArticle: 109104
Hi, thanks. I had checked the UCF file and there was no more than one assignment for the same pin. When I specified that IOSTNADARD to SSTL18_II_DCI, it worked fine. But it went wrong when the IOSTANDARD is DIFF_SSTL18_II_DCI. Seems the ISE can recognize this and set the IOSTANDARD to the default LVCMOS25. I am correct to say that? Is this the problem with ISE? I am using ISE 8.1i and my FPGA device is Virtex-4 XC4VFX60. Please advice. Thanks.Article: 109105
Peter Alfke wrote:
Many thanks for your help so far. I am afraid this post is a bit long
but with a bit of luck I am not the only one who cares to know the
answers, even if the thread is surprisingly quiet for what can often be
a rather popular topic. Perhaps it was something I said early on :-)
> Let's look at the basics:
> A flip-flop has an undefined output delay when the D input changes
> within a very tiny portion of the set-up time window,
Yes, so it seems a shame that no-one will tell me what T0 is and hence
I have to use the size of the entire setup window instead.
> For a 3 ns extra delay I measured (indirectly) this tiny window as a
> small fraction of a femtosecond. Expressed this way, MTBF and data and
> clock frequencies fall out of the equation,
Yes, so that way is not directly useful if I have the frequencies and
need to get the MTBF (?)
> and the behavior looks as
> if it were deterministic. So I consider this a basic figure of merit of
> the flip-flop.
Sorry to nitpick, but did you mean to say "for a 500ps (not 3ns) extra
delay" the window size is 0.03 fs?
Does that value (or anything else in the techxclusive) allow me to
determine the MTBF of my synchroniser? I cannot see how I could do any
better than get the MTBF of a circuit with exactly the same routing
delay and other overheads as the circuit used in writing the
techxclusive (unless I throw in a value of T0). I guess you might say
that my settling time will be off by no more than maybe half a
nanosecond if I just extrapolate from the MTBFs in the techxclusive.
Sadly, that difference translates to a MTBF different by orders of
magnitude and might result in a need for a second flip-flop if the
user is sufficiently paranoid. Maybe an example of what I want to find
would help:
I have the usual synchroniser composed of two flip-flops. The output of
the first is directly connected to the input of the second. ISE has
been told to ensure that the output delay + routing delay + setup time
+ the difference of clock skews can be at most x ns. The input of the
first flip-flop is connected to a source that may transition f2 times
per second. Both flip-flops are clocked at frequency f1. We can assume
the clocks are asynchronous for now. I can look up the tau of the first
flip-flop. Now, what is the mean time between failures, where a failure
occurs whenever the second flip-flop samples a metastable signal?
[ There are two solutions I tried, both based on obtaining T0 and using
the usual formula.
One was to calculate T0 based on the values in the table in the
techXclusive. This resulted in a ridiculously large time because, at a
rough guess, half the time in the half-periods is spent on overheads.
There is a note that says so in the techxclusive, it is just that it
was not obvious exactly how huge the implied value of T0 would be :-)
The other was to get T0 from the graph. Taking the point where several
of the lines intersect I came up with 0.03fs. This seems much too small
because it matches the 0.03fs value mentioned earlier in the
techxclusive that I interpret to be T_{500ps} (?). Obviously, T0 must
be several orders of magnitude larger than T_{500ps}.
Is there a third way, or can either one above be made to work? ]
> If your two frequencies are correlated, you may have a very hard time
> calculating the proabbility that the two edges ever get that close.
> They may always be very close, or they may never be close at all.
Yes, so I attempted to come up with a formula for a lower bound on the
MTBF when the clocks are synchronous, and was hoping someone here could
confirm that it is correct. To save anyone interested looking up the
original article, it was MTBF >= 1/(( min f1 f2 ) e^{-t/tau}). I would
be pleased to explain why I think the formula is correct if it is not
obvious and anyone cares.
It would be equally good if someone could point me to a
webpage/book/paper that discusses the MTBF when the clocks are
synchronous. I am sure it exists, but could not find it myself.
> Especially if you are exposed to, or if you rely on jitter...
Being exposed to jitter can only help in my circumstances. Relying on
jitter is obviously much less safe, especially if the best known value
of T0 is roughtly the same order of magnitude :-(
Article: 109106Antti =E5=86=99=E9=81=93=EF=BC=9A > cathy schrieb: > > > > of course you can initialize BRAMs from file > > > I havent done that with multiply BRAM blocks being used but it is > > > defenetly > > > doable. > > > > > Would you tell me how to do it in more detail? How the files look like > > and how to use it? Or some link to the guidance? > > Thanks a lot > > > one way that DEFENETLY works (if all others fail) > > > is to create manually .BMM file with PLACED constraints > > > and add matching LOC's for the BRAMs into the UCF > > > > > > but I hope XPS can handle multi BRAM inits also in more easy manner > > > > > > Antti > > I want to do the BRAM initialzation in simulation. The XPS generated > > system_init.bmm file automatically like this: > > opbBram64k/opbBram64k/ramb16_s1_s1_0 [31:31] ; > > opbBram64k/opbBram64k/ramb16_s1_s1_1 [30:30] ; > > opbBram64k/opbBram64k/ramb16_s1_s1_2 [29:29] ; > > ........................... > > opbBram64k/opbBram64k/ramb16_s1_s1_30 [1:1] ; > > opbBram64k/opbBram64k/ramb16_s1_s1_31 [0:0] ; > > the data is store in another file called system_init.vhd. > > And in this case, I need to split my each bit of my 32-bit data into > > different BRAM, so I need 32 different files to do that. Is that > > correct? Then I need to write another program to generated these files. > > That doable, but require some time. > > How do I give data in the .bmm file? > > > > Thanks a lot > > look at data2mem > options it can convert quite many different things > of course the easiest is just to test in FPGA :) > > I am NEVER doing microblaze hdl sims. > maybe I am forced todo them someday, but usually > its easier to test in FPGA with XMD and ChipScope then doing sims > > Antti Thanks, I have to do the simulation becasue I don't have the board. :)Article: 109107
I want to do some testing on some of the low power CPLDs and I can't find a decent test board for the Lattice ispMACH4000 parts or the XPLA3 parts. The XPLA3 parts are hard to find on a good eval board because they are a bit long in the tooth and even though they are a good choice when you want to use a single supply (or need 5 volt tolerance) support for them is starting to wane. The only good eval board for the XPLA3 parts that I can find is from India. The MACH4000 parts are a whole different matter. Lattice has an eval board that uses the LC4032ZC or the LC4064ZC chip, but nothing larger. It also has terrible documentation. Further I believe I am hearing that they never intended it to be an eval board, but rather a marketing tool to compare their part to an X brand part. So it was pushed into eval service with little documentation and support. With no third party eval board that I can find and the Lattice board with a $500 price tag and no useful documentation, it looks like I will have to go with the XC2C128 part just by default! Anyone know of eval boards for the ispMACH4000 parts?Article: 109108
Please ref to UG075.pdf from xilinx. check your package and you'll find that problem. Virtex-4 XC4VFX60? when use ISE, we also need to know the package. then you get the pin infomation in their Packaging and Pinout Specification. zyan wrote: > Hi, thanks. > > I had checked the UCF file and there was no more than one assignment for the same pin. When I specified that IOSTNADARD to SSTL18_II_DCI, it worked fine. But it went wrong when the IOSTANDARD is DIFF_SSTL18_II_DCI. Seems the ISE can recognize this and set the IOSTANDARD to the default LVCMOS25. I am correct to say that? Is this the problem with ISE? I am using ISE 8.1i and my FPGA device is Virtex-4 XC4VFX60. > > Please advice. Thanks.Article: 109109
Let's for a moment forget about the missing value for T0.
What I published were experimental results, extrapolated with the
knowledge that MTBF increases exponentially. So I had to measure only
two or three points on the (exponential) straight line.
We all know that the location of the tiny timing window moves about
with temperature and voltage and is also affected by processing
prameters. That's why the manufacturer gives you the wide spread for
the set-up time. Pinning down the location of the tiny window inside
the set-up time is meaningless and impossible, but we can measure its
effective width.
For uncorrolated clocks, we can measure and plot the MTBF and thus
derive the probability of any additional (beyond normal prop-delay)
non-deterministic, statistical metastable delay.
I plotted this as a graph, and mentioned that the vertical axis must be
scaled by the inverse of the product of the two frequencies. So for 100
MHz clock and 10 MHz data, the y-axis values must be multiplied by 3 x
5 = 15. (Because the likelyhood of any specific metastable delay is 3
times less due to the slower clocking, and another 5 times less due to
the more sparse data edges).
I am of the opinion that this is a really useful tool to quantify
metastable behavior.
The graph is based on real measurements, not on simulation, and not on
an attempt to match an equation. That's why I do not get excited about
the "missing T0"
Moreover, it shows that the traditional double-synchronizer is very
effective. In most cases, the metastable delay never reaches the set-up
time window of the second flip-flop. (Even if it did, the level change
would have to fall into the tiny window on the second synchronizer
flip-flop, which is a very remote probability). But the traditional
rule still holds: minimize the delay between the two flip-flops. When
every half nanosecond of available slack affects MTBF by a factor of a
million, it would be foolish not to shorten that path.
I did these measurements first in 1988 (after years of frustrating
experiments at my previous job, fresh at Xilinx, and tempted by the
ability to put the "instrument" inside the device under test). Then I
repeated the tests two more times, first with XC4000 and lastly with
Virtex-2 Pro. There has been little pressure to repeat them again, but
anybody who has a spare couple of days is welcome, and is assured of my
assistance. It takes only an eval board, a crystal oscillator plus a
clock generator, a good frequency counter and a stopwatch. Nothing
exotic.
Anybody who knows how to configure an FPGA can do it. Any professor or
student ready to volunteer? You might even gain some insight...
Peter Alfke, Xilinx Applications (from home)
=======================
comp.arch.fpga.posting.account@googlemail.com wrote:
> Peter Alfke wrote:
>
> Many thanks for your help so far. I am afraid this post is a bit long
> but with a bit of luck I am not the only one who cares to know the
> answers, even if the thread is surprisingly quiet for what can often be
> a rather popular topic. Perhaps it was something I said early on :-)
>
> > Let's look at the basics:
> > A flip-flop has an undefined output delay when the D input changes
> > within a very tiny portion of the set-up time window,
>
> Yes, so it seems a shame that no-one will tell me what T0 is and hence
> I have to use the size of the entire setup window instead.
>
> > For a 3 ns extra delay I measured (indirectly) this tiny window as a
> > small fraction of a femtosecond. Expressed this way, MTBF and data and
> > clock frequencies fall out of the equation,
>
> Yes, so that way is not directly useful if I have the frequencies and
> need to get the MTBF (?)
>
> > and the behavior looks as
> > if it were deterministic. So I consider this a basic figure of merit of
> > the flip-flop.
>
> Sorry to nitpick, but did you mean to say "for a 500ps (not 3ns) extra
> delay" the window size is 0.03 fs?
>
> Does that value (or anything else in the techxclusive) allow me to
> determine the MTBF of my synchroniser? I cannot see how I could do any
> better than get the MTBF of a circuit with exactly the same routing
> delay and other overheads as the circuit used in writing the
> techxclusive (unless I throw in a value of T0). I guess you might say
> that my settling time will be off by no more than maybe half a
> nanosecond if I just extrapolate from the MTBFs in the techxclusive.
> Sadly, that difference translates to a MTBF different by orders of
> magnitude and might result in a need for a second flip-flop if the
> user is sufficiently paranoid. Maybe an example of what I want to find
> would help:
>
> I have the usual synchroniser composed of two flip-flops. The output of
> the first is directly connected to the input of the second. ISE has
> been told to ensure that the output delay + routing delay + setup time
> + the difference of clock skews can be at most x ns. The input of the
> first flip-flop is connected to a source that may transition f2 times
> per second. Both flip-flops are clocked at frequency f1. We can assume
> the clocks are asynchronous for now. I can look up the tau of the first
> flip-flop. Now, what is the mean time between failures, where a failure
> occurs whenever the second flip-flop samples a metastable signal?
>
> [ There are two solutions I tried, both based on obtaining T0 and using
> the usual formula.
>
> One was to calculate T0 based on the values in the table in the
> techXclusive. This resulted in a ridiculously large time because, at a
> rough guess, half the time in the half-periods is spent on overheads.
> There is a note that says so in the techxclusive, it is just that it
> was not obvious exactly how huge the implied value of T0 would be :-)
>
> The other was to get T0 from the graph. Taking the point where several
> of the lines intersect I came up with 0.03fs. This seems much too small
> because it matches the 0.03fs value mentioned earlier in the
> techxclusive that I interpret to be T_{500ps} (?). Obviously, T0 must
> be several orders of magnitude larger than T_{500ps}.
>
> Is there a third way, or can either one above be made to work? ]
>
> > If your two frequencies are correlated, you may have a very hard time
> > calculating the proabbility that the two edges ever get that close.
> > They may always be very close, or they may never be close at all.
>
> Yes, so I attempted to come up with a formula for a lower bound on the
> MTBF when the clocks are synchronous, and was hoping someone here could
> confirm that it is correct. To save anyone interested looking up the
> original article, it was MTBF >= 1/(( min f1 f2 ) e^{-t/tau}). I would
> be pleased to explain why I think the formula is correct if it is not
> obvious and anyone cares.
>
> It would be equally good if someone could point me to a
> webpage/book/paper that discusses the MTBF when the clocks are
> synchronous. I am sure it exists, but could not find it myself.
>
> > Especially if you are exposed to, or if you rely on jitter...
>
> Being exposed to jitter can only help in my circumstances. Relying on
> jitter is obviously much less safe, especially if the best known value
> of T0 is roughtly the same order of magnitude :-(
Article: 109110There was a pretty good thesis called "Evaluation of synthesizable CPU cores" (google for it) that compares the LEON and OpenRisc (also mircoblaze). It goes into resource utilization, performance, etc.Article: 109111
I am currently using OR1200. I did read this Evaluation of synthesizable CPU cores, I seem to remember it as being biased towards LEON... Anyways, one aspect that was not mentioned in that thesis was user community. Being a member of both the OR and the LEON boards, the LEON community is far stronger (at least more publically active) Which is a very big benefit in my opinion. I have yet to jump on the LEON band wagon yet though. Soley due to laziness. chris.felton@gmail.com wrote: > There was a pretty good thesis called "Evaluation of synthesizable CPU > cores" (google for it) that compares the LEON and OpenRisc (also > mircoblaze). It goes into resource utilization, performance, etc.Article: 109112
Hi!
I have been working on a design lately where I use a the Xilinx Spartan
3E starter kit board. I use a logic analyser to check the output on some
signals which are assigned to the boards' J1, J2 and J4 connectors.
Sometimes, I get some of the signals to not even be "connected" on the
external pins. When this happens, I find that going in to the VHDL code and
adding a few changes that are usually never related to the signals I want to
observe in the first palce, fix things for me.
Lately, I have tried verifying the FPGA after downloading a newly
generated configuration to it. The verification came back with 3076 errors.
When I look at the logic analyser trace, it seems to provide "most" of the
signals except for one one that should be there but it is not.
Is there a way to obtain more info as to why thee would be so many
errors during the programming of an FPGA? Are there some settings I may not
be using correctly in the tool that causes the recompile to not be as clean
as I think it should? Does the verification process pick up noise on te
programming cable (I use the USB cable in this case)? Could the FPGA be
damaged (static perhaps)?
I guess I am curious as to why this is happening. Most of the time
things seem to work fine, but on the odd compile, something disapears.
Thanks for any help/hints.
Article: 109113Austin, Currently Iam in Pakistan. What is the nearest Xilinx FAE here ?? regards MHArticle: 109114
Hi, I am profiling some piece of code using some techXclusive article (the root of all evil) but I change it to a ppc405 target. The profiling seems to work fine but when i execute the profile command at the XMD prompt the output file of this command, gmon.out, is getting larger and larger and it never stops !!! I have managed to get profiling information with other pieces of code but I did not understnad the differences between the pieces of code and the configuration. If someone has some clues ? Best regards, JFArticle: 109115
Thanks. I had checked the document and the package that I am using is Virtex-4 XC4VFX60-10FF1152. This had been specified correctly in ISE. I still can't figure out any problem from UG075. Please advice. Thanks.Article: 109116
ref to UG070.pdf, page 286 : Rules for Combining I/O Standards in the Same Bank and check signals in Bank 7, is there two or more I/O standards? zyan wrote: > Thanks. > > I had checked the document and the package that I am using is Virtex-4 XC4VFX60-10FF1152. This had been specified correctly in ISE. I still can't figure out any problem from UG075. Please advice. Thanks.Article: 109117
I only used DIFF_SSTL18_II_DCI and SSTL18_II_DCI in bank 7. This satisfy the rules. But ISE didn't assign DIFF_SSTL18_II_DCI for the pins. It turned out to assign the default LVCOMS25 on those pin, which had violated the rules. It seems like I was not allowed to specify DIFF_SSTL18_II_DCI. So how should I fix this problem? Thanks.Article: 109118
List of distributors here http://www.xilinx.com/company/sales/ww_disti.htm. John Adair Enterpoint Ltd. mh wrote: > Austin, > > Currently Iam in Pakistan. What is the nearest Xilinx FAE here ?? > > regards > MHArticle: 109119
Jack Zkcmbcyk wrote: > Hi! > > I have been working on a design lately where I use a the Xilinx Spartan > 3E starter kit board. I use a logic analyser to check the output on some > signals which are assigned to the boards' J1, J2 and J4 connectors. > Sometimes, I get some of the signals to not even be "connected" on the > external pins. When this happens, I find that going in to the VHDL code and > adding a few changes that are usually never related to the signals I want to > observe in the first palce, fix things for me. > > Lately, I have tried verifying the FPGA after downloading a newly > generated configuration to it. The verification came back with 3076 errors. > When I look at the logic analyser trace, it seems to provide "most" of the > signals except for one one that should be there but it is not. > > Is there a way to obtain more info as to why thee would be so many > errors during the programming of an FPGA? Are there some settings I may not > be using correctly in the tool that causes the recompile to not be as clean > as I think it should? Does the verification process pick up noise on te > programming cable (I use the USB cable in this case)? Could the FPGA be > damaged (static perhaps)? > > I guess I am curious as to why this is happening. Most of the time > things seem to work fine, but on the odd compile, something disapears. > > Thanks for any help/hints. > > My spartan-3e Rev-D has performed flawlessly for me, no unpredictable behaviour as you describe. Recently I'm using the xup-0.0.2 + XC3Sprog approach described here earlier (bypass Impact + reprogram CPLD and use a linux utility to download the bitfile image in 8 seconds). Either before with windows/impact or now with linux have I ever experienced a failure to download the bitfile intact. Hope this data point is useful. Note I'm using the USB interface also. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109120
jean-francois hasson wrote: > Hi, > > I am profiling some piece of code using some techXclusive article (the > root of all evil) but I change it to a ppc405 target. The profiling > seems to work fine but when i execute the profile command at the XMD > prompt the output file of this command, gmon.out, is getting larger and > larger and it never stops !!! I have managed to get profiling > information with other pieces of code but I did not understnad the > differences between the pieces of code and the configuration. If someone > has some clues ? > > Best regards, > > JF gmon.out looks like gprof. Your behaviour sounds ok. Just abort the process you're profiling at some point and see what you got. As I recall you do something like gprof [executable] [gmon.out] It will output all sorts of useful info. Note I don't know what your toolchain is, gmon.out is the only thing familiar and I know of that from linux + gnu tools. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109121
Alex wrote: > I would greatly appreciate if someone could explain the behavior I'm > seeing for me. > > In the inner most if-state, where I write to bDATA_OUT ---- if I run > the program as written, it does nothing (my DATA_OUT lines remain in > the state they were previously). If I remove the "else, bDATA_OUT <= > "11000000"" segment, it properly outputs 00001010. I don't understand > why it would work w/o the else, but not w/. > elsif mode='1' then -- DATA INCOMING > if column_out(0)='0' then > bDATA_OUT <= "00001010"; > else > bDATA_OUT <= "11000000"; > end if; When you remove the 'else', then bDATA_OUT is only ever assigned "00001010" (Otherwise the value is undefined). Could the synthesis tool be noticing this and simply optimising your code away, in the case where you skip the 'else'? One way to test this would be to put an assignment for bDATA_OUT under your "if mode = '0'" clause. Otherwise, easiest way to investigate this would be a chipscope, or similar method (Depends on what your hardware is). Another way to determine if it's *actually* working would be to assign bDATA_OUT a changing value (like a counter) - I'm not sure that you have enough information with purely static values to determine that the case without the 'else' is actually working. JeremyArticle: 109122
Problem with CPLDs is that not many people want development boards other than possibly students. Generally I think people think of these devices as "simple" so go straight to their own board rather than trying a ready made platform. Speaking as a development board manufacturer the other problem with making boards like these is that profit line would be very low. Generally people have an expectation that CPLDs are cheap and the drive is not there in most cases to justify development. That all said we already do a CPLD module that can be used as a crude development module but not in the lower power devices you are interested in. We are looking at making this into a proper board with a power jack and regulator to allow easy stand alone powering from a brick in the wall. No timescales yet on this but we are talking a number of academic institutions to find out interest level. John Adair Enterpoint Ltd. rickman wrote: > I want to do some testing on some of the low power CPLDs and I can't > find a decent test board for the Lattice ispMACH4000 parts or the XPLA3 > parts. The XPLA3 parts are hard to find on a good eval board because > they are a bit long in the tooth and even though they are a good choice > when you want to use a single supply (or need 5 volt tolerance) support > for them is starting to wane. The only good eval board for the XPLA3 > parts that I can find is from India. > > The MACH4000 parts are a whole different matter. Lattice has an eval > board that uses the LC4032ZC or the LC4064ZC chip, but nothing larger. > It also has terrible documentation. Further I believe I am hearing > that they never intended it to be an eval board, but rather a marketing > tool to compare their part to an X brand part. So it was pushed into > eval service with little documentation and support. With no third > party eval board that I can find and the Lattice board with a $500 > price tag and no useful documentation, it looks like I will have to go > with the XC2C128 part just by default! > > Anyone know of eval boards for the ispMACH4000 parts?Article: 109123
Definately a market shaker is my comment given the current interest in high speed links we are seeing. John Adair Enterpoint Ltd. Gabor wrote: > rickman wrote: > > John_H wrote: > > > "rickman" <gnuarm@gmail.com> wrote in message > > > news:1158605643.208484.113710@m7g2000cwm.googlegroups.com... > > > > > > > > The pricing I have gotten on the ECP2 line is attractive, but in the > > > > grand scheme of things I don't see where it is a significant difference > > > > with the other players in the field. I think that optimizing any given > > > > parameter in the FPGA market is a matter of timing. A couple of years > > > > ago Spartan 3s were the low cost chips, then when the Cyclone II parts > > > > came out they were a bit cheaper. Now that ECP2 parts are starting to > > > > show, they will be cheaper... until the Spartan 4/5 parts make it to > > > > the scene. > > > > > > > > If only there was something that actually distinguished the different > > > > families of parts! > > > > > > > > > The ECP2 line is nice but not terribly remarkable. > > > > > > The ECP2M parts, on the other hand, blow past the Brand A and Brand X > > > low-cost offerings on memory to logic ratios *and* are the first low-cost > > > devices to include SERDES functionality and at *very* attractive per-channel > > > power levels. > > > > > > My attention was attracted to the offering because of the memory. Adding > > > PCI express would be quite a bonus for me. > > > > Please don't get me wrong, I am not knocking any of these parts. But I > > don't see a serdes and being a valuable addition to a low cost FPGA. > > Normally the items you are interfacing to with a serdes are not so > > cheap, but maybe I am not current and serdes are more popular now. But > > I see it as similar to the conversation where someone was complaining > > about needing to use $0.09 FETs for a high current interface rather > > than the low cost $0.03 cent 7002 FETs because the 3.3 volt interface > > on the FPGA would not drive the FET fully. Even a cheap FPGA is around > > $20 in most designs, so what is the diff on a few cents on the FETs? > > LIkewise, what is the diff on a $40 FPGA rather than a $20 FPGA if it > > interfaced to a $200+ fiber interface? > > > > Personally what I want is a good $10 FPGA with 260 IOs. So far they > > are all about $20. If it has more memory to support an imbedded MCU, > > all the better! > > Not all SERDES go into optics, and in fact many never leave the > printed circuit board. Low-cost devices with SERDES can help > with multi-device designs, where extra devices are more cost-effective > than a single device with the required number of I/O's. Using high- > speed SERDES from chip to chip reduces the interconnect pin > count giving you more of the I/O you added the parts for. I would > think the ASIC simulation guys would snap these parts up...Article: 109124
David Ashley schrieb: > Jack Zkcmbcyk wrote: > > Hi! > > > > I have been working on a design lately where I use a the Xilinx Spartan > > 3E starter kit board. I use a logic analyser to check the output on some > > signals which are assigned to the boards' J1, J2 and J4 connectors. > > Sometimes, I get some of the signals to not even be "connected" on the > > external pins. When this happens, I find that going in to the VHDL code and > > adding a few changes that are usually never related to the signals I want to > > observe in the first palce, fix things for me. > > > > Lately, I have tried verifying the FPGA after downloading a newly > > generated configuration to it. The verification came back with 3076 errors. Jack, I have seen FPGA verification errors once (this was also an S3e board designed by Digilent) - and that was defenetly proven damaged FPGA. It did take me long time to understand that, I even optimized some simple counter HDL to be more 'fault tolerant' eg to work in that damaged FPGA. So something is badly wrong, either damaged FPGA or partially malfunctioning power supply, or maybe your design takes too much power and those causes power supply spike so heavy that configuration is lost. whatever the reason - STOP trying out any designs loaded into the FPGA as long as the verificiation errors are not gone. config verification *MUST* pass or your design can have any undesired unpredictable behavior Antti
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