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
Andrew FPGA <andrew.newsgroup@gmail.com> wrote in message 1192444050.006865.143410@k35g2000prh.googlegroups.com... > > i 'm trying to practice VHDL at home,until today i did some things using > > obsolete Lattice and Xilinx CPLD. > > Hi there, if you want to learn VHDL why not focus on the VHDL and > forget about getting it working on the FPGA hardware. Download Xilinx > Webpack and Xilinx Modelsim starter edition(free), write some vhdl, > and then simulate it to check you understand. Iterate. You can also > synthesis it with webpack to check out if it gives you the gates and > flops you were expecting. Stick to some sensible design rules and then > the later jump to the FPGA hardware becomes trivial. > -Keep your design synchronous, use as few clocks as possible, > preferably one. (and only use one edge) > -Don't gate the clock > -Register any asynchronous inputs > > I suppose that approach is not as much fun as playing around with > actual hardware though. > > Cheers > Andrew Thanks for good hints Andrew 2 years ago i started to learn VHDL by myself at home,but i need to touch by hands things to print it in my mind,so as an exercise i tried to implement a basic digital oscilloscope as exercise i used only scraped components a Lattice CPLD ,an Atmega32 MCU and a 640x 480 LCD display from an early laptop Now i would like to redo the same path with a bigger FPGA ,and a freescale 9s12 MCU this is that "thing" that i built,strangely it works,i added read out and cursor to have something looking like a measurement http://img64.imageshack.us/content.php?page=done&l=img64/1348/image010tz3.jp g notice the jungle of enameled branch connecting the 5 ns SRAM end the A/D to the CPLD ,and the anti-crush bars soldered over the Ic's Of course it is at educational level,i didn't faced hardly with problems like skew and glitches,but i considered it an interesting experience.Article: 125001
Hi,
Iam working on profiling , using 6.1d version, memory profiling
reports generated for my project code is interims of mega bytes(total
memory allocated) . when I run same project code on the machine for
running the process it takes memory interims of gig bytes . why so
difference. Help me
THAKS and REGARDS
VISHWANATH
Article: 125002On Oct 12, 2:32 am, "SJU" <sjul...@adeneo.adetelgroup.com> wrote: > Hi all, > > We are building a very simple SOC ( PPC 405, internal memory, UART light)= in > a V4FX60, with a very simple firmware. > The point is that when we use the PLB_BRAM memory, the GDB debugger works > fine, but wneh we use the OCM memories, the debugger behaves in astrange > way. When we download the file then it goes in a assembly state and execu= tes > nothing, I guess it went in some exceptions or executed some unexpected > instructions. > > Is there something to know to use the OCM memories ? > Are there some configuration to make in EDK ? > > Thanks for your help. > > St=E9phane. What you need to watch out for is how you map the memory. One of the items we've noticed in previous builds was if the ISOCM and DSOCM were not in seperate 24M regions, then things would act funny. Therefore, we've mapped our ISOCM to 0xFFFFxxxx and our DSOCM to 0xFEFFxxxx. It seems to work fine in our builds so far. I have not tried re-tuning it yet since I haven't needed the OCM for my current system testing. Also, if you do have the memories separated, you may need to map in the ISOCM through the command line options of XMD: isocmStartAdr isocmSize. -- MikeArticle: 125003
vishii4u@gmail.com wrote:
> Iam working on profiling , using 6.1d version, memory profiling
> reports generated for my project code is interims of mega bytes(total
> memory allocated) . when I run same project code on the machine for
> running the process it takes memory interims of gig bytes . why so
> difference.
Maybe in one case you elaborate the design (vsim my_design)
and in the other you run a simulation (vsim test_my_design).
-- Mike Treseler
Article: 125004
Hal Murray wrote:
> What keeps the system from duplicating a pair of FFs?
Synthesis might use register duplication to
improve routing or fanout. The middle node
of a two flop shifter has no such issues.
-- Mike Treseler
Article: 125005On Oct 14, 5:35 am, pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: > Hi > > In Cyclone II ep2c5 pinouts document:http://www.altera.com/literature/dp/cyclone2/ep2c5.pdf > Some pins have additional discription: DQxxx DQSxx DMxx. > > DQS signals are assign to this pins because this pins are routed directly > to the clock control block and global clock bus. > > But why DQx (data) and DM (data mask) signals are assign to this pins. > > Is that requisite assignment or only recommended? > If recommended then why? > > This assignment is not comfortable for me but I don't know whether I can > change it. > > Thanks for any information. > > -- > PGW Typically, each 8 bits of DQ and corresponding DM bit are grouped together with an associated DQS bit. The idea is that individual pins in this group will see similar skews. Therefore, the DQS to data/dm relationship will not suffer at the memory or fpga. If you are going to be running at the max rated operating frequency it would be important to keep the group as suggested. -sanjayArticle: 125006
vhdl code LED1 <= some_signal; LED2 <= blink_one_second; the LED1,2 are connected to LED's blink_one_second is simple wire that drives LED2 and nothing else. now the code works in real FPGA with following behaviour: when some_signal = 0, then LED2 blinks. when some_signal = 1, then both LEDs blink as full sync to each other. what can cause this? some wrong answers: faulty FPGA fabric, bad PCB, bad power supply. eh, the solution to the problem was weird. but it does exist. sure I assumed FPGA fabric faulty first as I had overstressed the FPGA with 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully working, yet the weird behaviour exist. and this is actually correct behaviour in the particular case. I wonder if somebody is able to quess the answer to the issue. happy thinking! AnttiArticle: 125007
Is there any way to get the MicroBlaze GCC compiler to output DWARF2 debug information? This seems to be the standard these days and is even the default for GCC, but MicroBlaze GCC appears to use the older STABS format. I would even be interested in a 3rd party compiler (or GCC build) that can produce DWARF2, if this isn't possible with the current Xilinx tools. Thanks for any info. -- Steve -- 10/15/07 Steven Guccione Cmpware, Inc. http://www.cmpware.com/Article: 125008
> > I wonder if somebody is able to quess the answer to the issue. happy > thinking! > > Antti > incorrect ucf file had some other signals driving the pins? LEDs are installed backwards and there is also maybe a short?Article: 125009
On 15 Okt., 17:59, Jeff Cunningham <j...@sover.net> wrote: > > I wonder if somebody is able to quess the answer to the issue. happy > > thinking! > > > Antti > > incorrect ucf file had some other signals driving the pins? > > LEDs are installed backwards and there is also maybe a short? no. no pin mapping problem, no LED connection problems. if LED1 and LED 2 are driven from other signal they work properly. keep thinking;) I solved the issue, but to avoig going nuts I called my wife to look the code too. then id take some break and slept over it. and finally solved. AnttiArticle: 125010
Guenter Dannoritzer wrote: > Pierrick wrote: > >>On Oct 9, 12:53 pm, Guenter Dannoritzer <kratfkryk...@spammotel.com> >>wrote: >> >>>Pierrick wrote: >>> >>>>4DSP offers a floating point FFT and it seems like the only one >>>>available today with true IEEE-754 (float) arithmetic for FPGA >>>>devices. >>> >>>That is a bold statement and I would be interested which other available >>>cores you compared yours to and ruled out that they do not support true >>>IEEE-754 arithmetic? >>> >>>Cheers, >>> >>>Guenter >> >>Fair enough! The message however is related to the original thread >>where the user is looking for a 1M points FFT. It looks indeed as if >>there are some alternatives for shorter lengths FFTs (<32k points). > > > I see your point, but don't agree with that statement. When I do a > google search for floating point FFT, the first five hits show > information about floating point FFT cores from: > > - 4DSP > - Dillon Engineering > - Andraka Consulting > - Sundance Multiprocessor Technology Ltd > - Altera > > From all the above only on the web page of Andraka Consulting it says > that their core is limited to 2048 points. > > The other hits either explicit say their core supports lengths up to 1M > or do not state any length limitations. > > And they all state that they are IEEE-754 compliant. > While my core computes up to a 2048 point size, it can be used as a building block for much larger (up to 4M point in two passes) FFTs with external memory. No FPGA has sufficient internal memory to support these larger FFTs without going off-chip.Article: 125011
Eric wrote:
> I'm trying to design a DRAM controller to write/read a pattern to DRAM
> at 18-20 inches. I'm having problems with the controller right now, but
> am I wasting my time?
> I was thinking of running it at ~10-20Mhz.
It is a waste of time if you mean a
long ribbon cable with no impedance control.
A PCB with proper termination might
have a chance 10MHz. Put a scope on it.
-- Mike Treseler
Article: 125012Bad Power Supply? Ground loop or supply instability generating continuous powerup of you FPGA. Bad VHDL coding? Description of asynchronous logic (latches). Laurent Antti wrote: > vhdl code > > LED1 <= some_signal; > LED2 <= blink_one_second; > > the LED1,2 are connected to LED's > blink_one_second is simple wire that drives LED2 and nothing else. > > now the code works in real FPGA with following behaviour: > > when some_signal = 0, then LED2 blinks. > when some_signal = 1, then both LEDs blink as full sync to each other. > > what can cause this? > > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply. > > eh, the solution to the problem was weird. but it does exist. sure I > assumed FPGA fabric faulty first as I had overstressed the FPGA with > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully > working, yet the weird behaviour exist. and this is actually correct > behaviour in the particular case. > > I wonder if somebody is able to quess the answer to the issue. happy > thinking! > > Antti >Article: 125013
On 15 Okt., 19:38, "Amontec, Larry" <laurent.ga...@ANTI- SPAMamontec.com> wrote: > Bad Power Supply? > Ground loop or supply instability generating continuous powerup of you FPGA. > > Bad VHDL coding? > Description of asynchronous logic (latches). > > Laurent NO NO NO NO waiting for more suggestions :) AnttiArticle: 125014
Antti wrote: > On 15 Okt., 19:38, "Amontec, Larry" <laurent.ga...@ANTI- > SPAMamontec.com> wrote: > >>Bad Power Supply? >>Ground loop or supply instability generating continuous powerup of you FPGA. >> >>Bad VHDL coding? >>Description of asynchronous logic (latches). >> >>Laurent > > > NO > NO > NO > NO > > waiting for more suggestions :) > > Antti > if this is not the VHDL code, let us know the VHDL generating the some_signal and the blink_one_second.Article: 125015
On 15 Okt., 19:58, "Amontec, Larry" <laurent.ga...@ANTI- SPAMamontec.com> wrote: > Antti wrote: > > On 15 Okt., 19:38, "Amontec, Larry" <laurent.ga...@ANTI- > > SPAMamontec.com> wrote: > > >>Bad Power Supply? > >>Ground loop or supply instability generating continuous powerup of you FPGA. > > >>Bad VHDL coding? > >>Description of asynchronous logic (latches). > > >>Laurent > > > NO > > NO > > NO > > NO > > > waiting for more suggestions :) > > > Antti > > if this is not the VHDL code, let us know the VHDL generating the > some_signal and the blink_one_second.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - the signal driving LED2 goes only to LED2, also no signals used to generate blink_one_second are in any way used in the part that generates some_signal, let say some_signal comes from external switch directly, and has no FPGA logic except routing. AnttiArticle: 125016
jacobusn@xilinx.com wrote: > The newest version of MIG will support 32-bit Linux Red Hat Enterprise > 4.0. The newest version (2.0) will be in IP Update 2 for ISE 9.2i and > will be released on 10/17/2007. That is good to hear. > What device are you targeting? My immediate use was for a V2Pro device, so I probably will have to stick to the old tool for that. But I was also looking ahead toward using the V5, and hoping the design doesn't need to change much in the migration.Article: 125017
I had a somewhat similar puzzle quite a few years ago. The code had a flip-flop generating out1 and an async assignment out2 = not out1. The two outputs were driving external buffers. Somehow the outputs got enabled together and the buffers smoked. I traced the problem to the synthesizer setting, which created another flop for the out2 and moved negation to its input. I don't remember all the details now, but IIRC the clock was missing for whatever reason when I first powered the board... Apparently debugging that board was my first assignment at a new job. Imagine how I felt when it smoked :) /MikhailArticle: 125018
On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: > I had a somewhat similar puzzle quite a few years ago. The code had a > flip-flop generating out1 and an async assignment out2 = not out1. The two > outputs were driving external buffers. Somehow the outputs got enabled > together and the buffers smoked. I traced the problem to the synthesizer > setting, which created another flop for the out2 and moved negation to its > input. I don't remember all the details now, but IIRC the clock was missing > for whatever reason when I first powered the board... Apparently debugging > that board was my first assignment at a new job. Imagine how I felt when it > smoked :) > > /Mikhail eh, but no one is getting closer to my issue. another hint, no flip flip or any sync logic thing is causing this problem. its also not in any way some compiler or P&R weirdness at all. AnttiArticle: 125019
On Oct 15, 11:33 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: > eh, but no one is getting closer to my issue. > another hint, no flip flip or any sync logic thing is causing this > problem. > its also not in any way some compiler or P&R weirdness at all. > > Antti Did someone get too cheap in the board design and only use a single current limit resistor for both LEDs? If the blink LED has a significantly lower forward drop than the some_signal LED, then when blink LED turns on, it turns off some_signal LED, and when it goes off, some_signal LED comes back on. (You said they blink at the same time, but didn't mention polarity).Article: 125020
On 15 Okt., 22:22, JustJohn <john.l.sm...@l-3com.com> wrote: > On Oct 15, 11:33 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: > > eh, but no one is getting closer to my issue. > > another hint, no flip flip or any sync logic thing is causing this > > problem. > > its also not in any way some compiler or P&R weirdness at all. > > > Antti > > Did someone get too cheap in the board design and only use a single > current limit resistor for both LEDs? If the blink LED has a > significantly lower forward drop than the some_signal LED, then when > blink LED turns on, it turns off some_signal LED, and when it goes > off, some_signal LED comes back on. (You said they blink at the same > time, but didn't mention polarity). same blink rate, same polarity. but it was a good guess. and no it has nothing todo with the LED external wiring. AnttiArticle: 125021
Hello all, I am working on a design for a Xilinx V2P50 and I am trying to diagnose possible timing issues because the hardware performance of my design does not appear to match simulation. I have run the design through Timing Analyzer (ISE 8.2) and notice a huge number of unconstrained paths of the following format "FROM *clk_pad* TO *register*" where *clk_pad* is a clock pad in the design, and *register* is a register in the design that is clocked. Am I missing a necessary timing constraint to eliminate these unconstrained paths? I have period constraints for all of the clocks in the design. If these paths are "correctly" unconstrained, is there any way to eliminate them from Timing Analyzer easily (preferably via command line, not in the GUI) so that only valuable unconstrained paths appear? Thanks for all of your help.Article: 125022
paragon.john@gmail.com wrote:
> If these
> paths are "correctly" unconstrained, is there any way to eliminate
> them from Timing Analyzer easily (preferably via command line, not in
> the GUI) so that only valuable unconstrained paths appear?
I'm sure there is, but I don't have
a quick answer to that question.
I can tell you what I would do.
1. Reduce the number of clocks to a minimum.
2. Synthesize a separate module for each clock
and work out Fmax for each domain.
3. Instance the modules with known-good synchronization as needed.
-- Mike Treseler
Article: 125023
paragon.john@gmail.com wrote:
> Hello all,
>
> I am working on a design for a Xilinx V2P50 and I am trying to
> diagnose possible timing issues because the hardware performance of my
> design does not appear to match simulation.
>
> I have run the design through Timing Analyzer (ISE 8.2) and notice a
> huge number of unconstrained paths of the following format
>
> "FROM *clk_pad* TO *register*"
>
> where *clk_pad* is a clock pad in the design, and *register* is a
> register in the design that is clocked...
>
I think those only occur when a local net is used somewhere in the clock
path. Are you using a gated clock? Is the clock pad using a pin other
than the one with a direct connection to a global clock buffer?
Why don't you post one of the unconstrained paths. That is, the part
that should look something like:
================================================================================
Timing constraint: Unconstrained path analysis
868 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold
errors)
Maximum delay is 6.513ns.
--------------------------------------------------------------------------------
Delay: 3.654ns (data path)
Source: GIGE_CLK_N (PAD)
Destination: aurora_rt2_e/PROTOCOL_ENG1/lane_0_mgt_i (HSIO)
Data Path Delay: 3.654ns (Levels of Logic = 3)
Data Path: GIGE_CLK_N to aurora_rt2_e/PROTOCOL_ENG1/lane_0_mgt_i
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
B15.PADOUT Tiopp 0.312 GIGE_CLK_N
GIGE_CLK_N
C15.DIFFI_IN net (fanout=1) 0.000
TOP_MGT_CLK_BUF/SLAVEBUF.DIFFIN
C15.I Tdiffin 0.843 GIGE_CLK_P
TOP_MGT_CLK_BUF/IBUFDS
BUFGMUX3P.I0 net (fanout=3) 0.435 TOP_REF_CLK2
BUFGMUX3P.O Tgi0o 0.057 TOP_USER_CLK_BUF
TOP_USER_CLK_BUF
GT_X3Y1.RXUSRCLK net (fanout=527) 2.007 TOP_USER_CLK
-------------------------------------------------
---------------------------
Total 3.654ns (1.212ns logic,
2.442ns route)
(33.2% logic,
66.8% route)
Article: 125024Steven Guccione wrote: > Is there any way to get the MicroBlaze GCC compiler to output DWARF2 debug > information? This seems to be the standard these days and is even the > default for GCC, but MicroBlaze GCC appears to use the older STABS format. > I would even be interested in a 3rd party compiler (or GCC build) that can > produce DWARF2, if this isn't possible with the current Xilinx tools. > Thanks for any info. > mb-gcc uses dwarf2 by default in 9.2. If you have to use earlier releases, try adding -gdwarf-2 as a compiler option. -Siva
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