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
On Thu, 23 Jul 2009 22:52:43 +0200, Petter Gustad wrote: > General Schvantzkoph <schvantzkoph@yahoo.com> writes: > >> offer the bare minimum in the free package. They also probably have >> some idea that it costs them more to support Linux, I doubt that true, >> the > > I always thought that Altera had to pay a per seat license fee to the > Windu toolkit developers. > > Petter You could be right about that, Xilinx had that limitation until they rewrote their GUI (the really old Xilinx tools like fpga editor use Motif which is open source, it was ISE that had the problem). Is there someone from Altera reading this thread? It would be nice to get an official explanation.Article: 142076
I am currently working on a design using the v4fx20. My current design consists of bram memory at 0xffff0000 to 0xffffffff and DDR at 0x00000000 to 0x03ffffff. I can read and write from the bram memory, but whenever I either read or write from anywhere within the DDR memory space, my entire memory space (0x00000000 - 0xffffffff) becomes unusable. For example: XMD% mrd 0xffffff00 16 FFFFFF00: 00000000 FFFFFF04: 00000000 FFFFFF08: 00000000 FFFFFF0C: 00000000 FFFFFF10: 00000000 FFFFFF14: 00000000 FFFFFF18: 00000000 FFFFFF1C: 00000000 FFFFFF20: 00000000 FFFFFF24: 00000000 FFFFFF28: 00000000 FFFFFF2C: 00000000 FFFFFF30: 00000000 FFFFFF34: 00000000 FFFFFF38: 00000000 FFFFFF3C: 00000000 XMD% mwr 0xffffff00 0x12345678 XMD% mrd 0xffffff00 16 FFFFFF00: 12345678 FFFFFF04: 00000000 FFFFFF08: 00000000 FFFFFF0C: 00000000 FFFFFF10: 00000000 FFFFFF14: 00000000 FFFFFF18: 00000000 FFFFFF1C: 00000000 FFFFFF20: 00000000 FFFFFF24: 00000000 FFFFFF28: 00000000 FFFFFF2C: 00000000 FFFFFF30: 00000000 FFFFFF34: 00000000 FFFFFF38: 00000000 FFFFFF3C: 00000000 XMD% mrd 0x00000000 16 0: FFFFFFF8 4: FFFFFFF8 8: FFFFFFF8 C: FFFFFFF8 10: FFFFFFF8 14: FFFFFFF8 18: FFFFFFF8 1C: FFFFFFF8 20: FFFFFFF8 24: FFFFFFF8 28: FFFFFFF8 2C: FFFFFFF8 30: FFFFFFF8 34: FFFFFFF8 38: FFFFFFF8 3C: FFFFFFF8 XMD% mrd 0xffffff00 16 FFFFFF00: FFFF0958 FFFFFF04: FFFF0958 FFFFFF08: FFFF0958 FFFFFF0C: FFFF0958 FFFFFF10: FFFF0958 FFFFFF14: FFFF0958 FFFFFF18: FFFF0958 FFFFFF1C: FFFF0958 FFFFFF20: FFFF0958 FFFFFF24: FFFF0958 FFFFFF28: FFFF0958 FFFFFF2C: FFFF0958 FFFFFF30: FFFF0958 FFFFFF34: FFFF0958 FFFFFF38: FFFF0958 FFFFFF3C: FFFF0958 To me this sounds like a timing issue, but I believe I have everything constrained that needs to be constrained. It could also be a initialization issue but I'm not sure. Has anyone run into such an issue?Article: 142077
On Jul 20, 11:20=A0pm, maverick <sheikh.m.far...@gmail.com> wrote: > Hi, I have a Spartan3AN xc3s1400AN FPGA board. There are externally > devices connected to the FPGA on the board. One of the external > devices is a TMS320DM6446 TI DSP connected to this FPGA with its EMIF > bus interface. Other external devices are memory mapped to this TI > DSP. The access to these external devices from the DSP are provided > through the FPGA. For this, a simple Verilog framework has been > written where interfaces to all these external devices are written and > connected to the EMIF bus. In addition to these memory mapped devices, > one 16-bit register has also been memory mapped inside the FPGA. The > Verilog framework has been tested and verified in simulation. On one > of the FPGA boards with exact specs, the same Verilog framework runs > with no problem and the DSP can write and read all memory mapped > devices with no problem including the 16-bit register inside FPGA. > However, when the same Verilog code is programmed on another similar > FPGA board (exactly the same), there is one issue. Before describing > the issue, I must inform that the board has been thoroughly tested for > all voltage levels being provided to the FPGA (core/IO voltages). > The EMIF successfully writes and reads external devices. However, it > fails to write and read the 16-bit memory mapped register. The > register is designed to drive the LEDs with the value written into it. > On this FPGA board, the LEDs do not change their state from the > default condition for any value written into this register from the > DSP. To further investigate, ChipScope Pro cores were inserted to see > transactions taking place on EMIF bus. It was observed that valid > values were traveling into the FPGA on EMIF pins and proper bus > protocol was taking place. In the next phase, CSP cores were hooked up > with the 16-bit register and it was observed that the register was not > latching the value at its input and does not change from its initial > state. In the next phase, the LEDs were removed from the design and > synthesized. Now the value written into the register will not drive > the LEDs as they are disconnected. When analyzed with CSP, it was > observed that the register is latching the value properly. In the next > level, the same register output was connected to other set of GPIOs, > the problem re-appeared again. It seems as if there is problem > whenever this register is connected to GPIO. Here it is important to > note that the same code with all changes of CSP cores works perfectly > fine on the other FPGA board with same specs. Is the FPGA damaged? Is > there any way to find out that? Any suggestions how to fix this > problem? I'm a little unclear on exactly how many test cases you have, but with just two, you cannot be sure which is 'more typical' :) It does sound like a case for having read-back paths on all registers, (if the resource allows it), and then you can verify as you go, and catch quite low failure rates. That's normally part of POST (Power on Self Test) and Board bring-up tests, so even if you final product cannot fit such paths (rare, but possible), you should create a test case that does. -jgArticle: 142078
On Jul 23, 11:55=A0am, vizziee <vizz...@gmail.com> wrote:
> On Jul 9, 12:47=A0pm, Dirk Bell <bellda2...@cox.net> wrote:
>
>
>
> > On Jul 8, 6:44=A0pm, vizziee <vizz...@gmail.com> wrote:
>
> > > > Check your equations. =A0I get
>
> > > > ( ( (22-1)/2 )/20 + ( (22-1)/2 )/10 + ( (1010-1)/2 )/5 ) =3D 102.47=
50
> > > > which is consistant with what you are actually getting, not what yo=
u
> > > > are calculating.
>
> > > > Also note that the filters you are identifying as half-band filters
> > > > are not actually half-band filters. =A0Half-band filters have the
> > > > property that almost half of the coefficients are zero, saving
> > > > calculations, which may be useful to you. But, among other properti=
es,
> > > > the lengths of halfband filters are constrained to {3, 7, 11, 15, 1=
9,
> > > > 23, 27, ..., previous+4, ...}, so a filter of length 22 isn't a hal=
f-
> > > > band filter.
>
> > > > Dirk Bell
>
> > > Thanks Dirk. I checked the Halfband filters that I generated in
> > > MATLAB. It says it has Direct Form Polyphase Filter structure. The
> > > coefficients were generated by specifying 'halfband' option to
> > > fdesign.decimator function. The number of generated coefficients for
> > > this half-band decimator is actually 21 and I padded a zero to make i=
t
> > > 22 for a 2-path polyphase implementation.
>
> > > I did a reading for Half-band filters and what you say about the
> > > HalfBand FIR filter coefficients is absolutely true: the number of
> > > coefficients should be 3+4n for a non-negative integer n. However I
> > > couldn't reconcile the MATLAB halfband filter generated above with
> > > this definition. Are halfband decimators different than the Nyquist
> > > half-band filters? Also the way you calculated the delay of half-band
> > > filters appears very much true. However assuming this is the polyphas=
e
> > > implementation of half-band decimators, shouldn't delay be calculated
> > > like a standard polyphase filter delay formula: ((No_of_taps-1)/2)/
> > > Decimation_Factor?
>
> > > Thanks again for your insightful replies earlier. I could drastically
> > > reduce the no of taps in my current design while also bettering the
> > > response. Though the questions as above still linger in my mind.
>
> > > Regards,
>
> > > vizziee.
>
> > Vizziee,
>
> > Would you post the coefficients (or preferably all MATLAB inputs and
> > resulting output) from your halfband design.
>
> > BTW a halfband filter could have a length 21 if it is really a length
> > 19 filter with a zero added to each end, but that would be a waste of
> > computation if you used the zero coefficients.
>
> > Dirk Bell
> > DSP Consultant
>
> Thanks Dirk. After a little bit of reading and experimenting, it
> appears to me that the MATLAB coefficients so generated for a Halfband
> filter were because of the fact that they were implemented as
> polyphase structure. The coefficients and the command use dto generate
> them are as follows:
>
> dhb =3D fdesign.decimator(2, 'halfband', 'N,AST', 20, 80, 200e6);
> hb =3D design(dhb);
> hb.Numerator =3D
> 0 =A0 =A00.0015 =A0 =A0 =A0 =A0 0 =A0 -0.0083 =A0 =A0 =A0 =A0 0 =A0 =A00.=
0283 =A0 =A0 =A0 =A0 0
> -0.0801 =A0 =A0 =A0 =A0 0 =A0 =A00.3087 =A0 =A00.5000 =A0 =A00.3087 =A0 =
=A0 =A0 =A0 0
> -0.0801 =A0 =A0 =A0 =A0 0 =A0 =A00.0283 =A0 =A0 =A0 =A0 0 =A0 =A0-0.0083 =
=A0 =A0 =A0 =A0 0
> 0.0015 =A0 =A0 =A0 =A0 0
>
> Regards,
> vizziee.
I gather that since I specified the order of this half-band filter, it
is bound to have 21 coefficients. The condition N =3D 3q+1 where N =3D
order of the filter and q a non-neg integer for half-band filters is
only applicable when one designs it for "minimum order".
Regards,
vizziee.
Article: 142079Here is a concise overview with links to most User Guides. http://www.pldesignline.com/ Spartan-6 will get the same treatment in about a week. Peter Alfke, XilinxArticle: 142080
Torfinn Ingolfsen wrote: > Are there alternative development tools for Altera (DE1) that runs under > FreeBSD? Icarus Verilog[1] runs under FreeBSD. Thanks to BobH for making me aware of this tool. References: 1) http://www.freshports.org/cad/iverilog/ -- Torfinn Ingolfsen NorwayArticle: 142081
Mike Treseler wrote: > I agree. If some of my "switched off" code does not elaborate, > that means I have changed or eliminated the target of some identifier > that previously make the code usable. > I would either fix up the option or take it all out. I have a project suite that I've been attempting to perfect for some time. It consists of a "framework" if you like, comprising a hierarchy of entities, some of which may be substituted with project-specific variants, whilst others may be provided by generic, cross-project architectures. The suite itself is used in "many" projects, each of which may be targeted to "many" hardware platforms. I use records as far as possible when defining the ports of entities within the framework. Each entity can have up to a dozen records as ports, as each record contains only closely-related signals. In general thus far, record declarations are "global" across projects - they never change. Recently however, I've introduced a record that may be defined on a per-project basis. This record is used in a number of entities throughout the suite. This doesn't cause problems with entity ports so much - it's when, for example, those (variable) record members are accessed directly in "generic" modules within the framework. Now, this is all very much WIP, and I'm not claiming that the problem can't better be solved (I've tried to use configurations but either they just don't seem to suit my purpose, result in redundant coding effort which complicates maintenance, or I can't work out how to use them properly), but it is in these cases that it would be very useful to be able to exclude code segments, based on a constant or generic or compiler directive, that wouldn't - for this project - pass compilation. And again, this is only one example. Anyway, I offer this explanation not for any justification of my methods, but merely an explanation of what I am trying to achieve. I would acknowledge that this is far from the typical or perhaps even intended use of VHDL. Regardless, I'm not convinced that my goal is ultimately realisable using current VHDL standards and current-gen tools (happy to be proven wrong). What I _do_ know is that I could easily achieve this in software. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142082
Hi, Peter Alfke wrote: > Here is a concise overview with links to most User Guides. > http://www.pldesignline.com/ > Spartan-6 will get the same treatment in about a week. Quote from the last page : " Encryption, Readback, and Partial Reconfiguration As a special option, the bitstream can be AES-encrypted to prevent unauthorized copying of the design. The Virtex-6 FPGA performs the decryption using the internally stored 256-bit key that can use battery backup or alternative non-volatile storage. " hmmm.... It can be useful, I have no doubt about it, but it's not very practical :-/ I have examined Actel's method which, if not what I would like to find, looks more solid. Maybe the next revisions of the family will include a secret serial number in OTP, and challenge-based authentication so update of the bitstream through the 'net could be safe, or something along these lines ? regards, > Peter Alfke, Xilinx yg, not a cryptographer -- http://ygdes.com / http://yasep.orgArticle: 142083
Allan wrote: > > "Once a month or once a decade" was more like once > every few times I toggled the reset input on the DCM, > on the particular design I tested. The probability > changed from part to part. On some FPGAs, I couldn't > make it happen at all. > I agree completely; I've seen similar corruption caused by DCM startup or other clock switching transients. I first noticed this problem ~2003 in a multicycle read situation similar to that described by Bob P. in 2005: http://groups.google.com/group/comp.arch.fpga/msg/018c5fc683d5a9aa Overall, I consider this corruption issue to be a much more serious problem than does Peter. Why? Because any application that switches clock sources on the fly without a-priori knowledge ( e.g. A/V, networking, variable sample clocks ), or one that simply recovers from DCM unlocks, CAN NOT SAFELY USE INITIALIZED BRAM !!! ( Unless having an initialization re-load procedure through reconfiguration or other means ) Offhand, I can recall just one Xilinx app note, XAPP873, that has the proper DCM startup clock enable inhibit logic for an initialized BRAM. ( disclaimer: I haven't explicitly trawled the app notes looking for this logic since mid-2008) For further reading, here is a list of my posts on this topic from years past; I've posted just the shorter google link to individual messages, click the resulting page's thread title link for the whole thread: 2005 thread: "Important BRAM Safety Tip" http://groups.google.com/group/comp.arch.fpga/msg/458bb7a6301318d9 http://groups.google.com/group/comp.arch.fpga/msg/67b112027f71ade8 2007 thread: "Use BRAM as ROM (Xilinx)" http://groups.google.com/group/comp.arch.fpga/msg/30bb0573b9468241 http://groups.google.com/group/comp.arch.fpga/msg/5f0d539d3c59131e 2008 thread: "Aligned PLL clocks in RTL simulation" http://groups.google.com/group/comp.arch.fpga/msg/3c2200d437d1e9e1 BrianArticle: 142084
On Jul 23, 3:06=A0pm, jleslie48 <j...@jonathanleslie.com> wrote: > On Jul 22, 6:38 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > > > > > > > > jleslie48 <j...@jonathanleslie.com> writes: > > > Sorry to start from scratch yet again, but I don't know where to > > > begin. > > > > In the past I've had log file info dump out onto =A0a UART as > > > necessary. =A0The UART is slow, and requires an additional device to > > > capture the datastream. > > > How fast do you need? FTDIs UART-USB (TTL-232R-3V3) cable will go @ > > 3Mbps IIRC. =A0It's an extra cable, hardly a device though, unless you > > count the PC as well? > > >http://apple.clickandbuild.com/cnb/shop/ftdichip?productID=3D53&search= =3D... > > > > I want to be able to write to a removable memory stick, or compact > > > flash card, but I don't have any idea how to do it. =A0When the FPGA = is > > > powered up it should start a new "file" on the compact flash card, an= d > > > start writing to it. =A0On commanded bit or powerdown, the file shoul= d > > > be closed, and stored such that I can pull the card, plug it into a P= C > > > and read the file with notepad or such. > > > Is this sort of thing any use? > > >http://www.vinculum.com/ > > > Easy modules:http://apple.clickandbuild.com/cnb/shop/ftdichip?op=3Dcata= logue-product... > > > I've never used them, but it looks like a simple way to add use-storage > > to a system. > > > Failing that, glue a USB host controller on the side and run linux on a > > microblaze. > > > [BTW, even though I sound like an FTDI salesman I have no affiliation > > with FTDI, other than having used various of their products!] > > > Cheers, > > Martin > > > -- > > martin.j.thomp...@trw.com > > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp:/= /www.conekt.net/electronics.html > > Ok, I'm looking at these solutions, they look promising, but has > anyone actually got one of these to work? > > I've got a Diligent test board and it has a compact flash reader on > it, so I'm assuming someone actually used this reader for something, > but I can't find any test code or any clue how to use it. =A0I keep > hearing something about microblaze, and then I can write C code, but I > have yet to stumble onto an example. For just datalogging, where throughput isn't too important, I'd personally go with an SD card, using the SPI mode of communication. There are several examples of C code for controlling an SD card with the SPI interface, such as http://www.flashgenie.net/index.html#code. There are some examples of FAT32 code floating around on the net, too. The SD card association at www.sdcard.org also publishes a simplified spec which shows a lot of the SPI commands you can use with SD cards. You can find some breakout boards for SD cards at www.sparkfun.com, and tie them to your Digilent board if it has an IO header that goes to the FPGA. If the CF card on your board is connected to a Xilinx SystemAce chip, then it might be fairly simple to use with an embedded processor. Otherwise, you'll either have to learn the IDE spec or find some IP to handle it. There's an IDE controller on opencores.org, but I have no experience with it. You could also use one of the USB/UART solutions that have been proposed, and have the computer to the logging. You'd need to be tethered to a computer, but it would be super-fast to implement. Good luck, DaveArticle: 142085
Torfinn Ingolfsen <tingo@start.no> writes: > Torfinn Ingolfsen wrote: > Icarus Verilog[1] runs under FreeBSD. Thanks to BobH for making me > aware of this tool. GtkWave runs under Linux and I would assume it runs under FreeBSD as well. You can then dump the simulation trace in Icarus Verilog and open it in GtkWave. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 142086
General Schvantzkoph <schvantzkoph@yahoo.com> writes: > On Thu, 23 Jul 2009 22:52:43 +0200, Petter Gustad wrote: >> I always thought that Altera had to pay a per seat license fee to the >> Windu toolkit developers. >> >> Petter > > You could be right about that, Xilinx had that limitation until they > rewrote their GUI (the really old Xilinx tools like fpga editor use Motif I wish Altera used some other toolkit under Linux which did not have a costly license restriction. Personally I would be fine with the command line tools under Linux, except maybe the FPGA editor and probably the MegaWizard generator. But the general idea of the free web-packs is that they should get people started using their tools at a low cost, and most users will probably not get started with the command line tools. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 142087
On Jul 23, 8:16=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > OK, so what is inherently better about this... > > case xyz is > =A0 when Blah =3D> > =A0 =A0 #ifdef DEBUG > =A0 =A0 =A0 -- Put your debug code here > =A0 =A0 #end if > =A0 =A0...etc... > end case; > > Compared to this... > case xyz is > =A0 when Blah =3D> > =A0 =A0 if DEBUG > =A0 =A0 =A0 -- Put your debug code here > =A0 =A0 end if; > =A0 =A0...etc... > end case; Try this: When the #IFDEF is used as a block comment, to remove declarations, or whole chunks of source code, that do not fit inside a case (or similar) statement. That's why many languages use separate syntax for the Flow (conditional compile) stuff : even tho you can cover many instances with constants, you cannot cover all... -jgArticle: 142088
On Jul 23, 6:25=A0pm, vizziee <vizz...@gmail.com> wrote:
> On Jul 23, 11:55=A0am, vizziee <vizz...@gmail.com> wrote:
>
>
>
>
>
> > On Jul 9, 12:47=A0pm, Dirk Bell <bellda2...@cox.net> wrote:
>
> > > On Jul 8, 6:44=A0pm, vizziee <vizz...@gmail.com> wrote:
>
> > > > > Check your equations. =A0I get
>
> > > > > ( ( (22-1)/2 )/20 + ( (22-1)/2 )/10 + ( (1010-1)/2 )/5 ) =3D 102.=
4750
> > > > > which is consistant with what you are actually getting, not what =
you
> > > > > are calculating.
>
> > > > > Also note that the filters you are identifying as half-band filte=
rs
> > > > > are not actually half-band filters. =A0Half-band filters have the
> > > > > property that almost half of the coefficients are zero, saving
> > > > > calculations, which may be useful to you. But, among other proper=
ties,
> > > > > the lengths of halfband filters are constrained to {3, 7, 11, 15,=
19,
> > > > > 23, 27, ..., previous+4, ...}, so a filter of length 22 isn't a h=
alf-
> > > > > band filter.
>
> > > > > Dirk Bell
>
> > > > Thanks Dirk. I checked the Halfband filters that I generated in
> > > > MATLAB. It says it has Direct Form Polyphase Filter structure. The
> > > > coefficients were generated by specifying 'halfband' option to
> > > > fdesign.decimator function. The number of generated coefficients fo=
r
> > > > this half-band decimator is actually 21 and I padded a zero to make=
it
> > > > 22 for a 2-path polyphase implementation.
>
> > > > I did a reading for Half-band filters and what you say about the
> > > > HalfBand FIR filter coefficients is absolutely true: the number of
> > > > coefficients should be 3+4n for a non-negative integer n. However I
> > > > couldn't reconcile the MATLAB halfband filter generated above with
> > > > this definition. Are halfband decimators different than the Nyquist
> > > > half-band filters? Also the way you calculated the delay of half-ba=
nd
> > > > filters appears very much true. However assuming this is the polyph=
ase
> > > > implementation of half-band decimators, shouldn't delay be calculat=
ed
> > > > like a standard polyphase filter delay formula: ((No_of_taps-1)/2)/
> > > > Decimation_Factor?
>
> > > > Thanks again for your insightful replies earlier. I could drastical=
ly
> > > > reduce the no of taps in my current design while also bettering the
> > > > response. Though the questions as above still linger in my mind.
>
> > > > Regards,
>
> > > > vizziee.
>
> > > Vizziee,
>
> > > Would you post the coefficients (or preferably all MATLAB inputs and
> > > resulting output) from your halfband design.
>
> > > BTW a halfband filter could have a length 21 if it is really a length
> > > 19 filter with a zero added to each end, but that would be a waste of
> > > computation if you used the zero coefficients.
>
> > > Dirk Bell
> > > DSP Consultant
>
> > Thanks Dirk. After a little bit of reading and experimenting, it
> > appears to me that the MATLAB coefficients so generated for a Halfband
> > filter were because of the fact that they were implemented as
> > polyphase structure. The coefficients and the command use dto generate
> > them are as follows:
>
> > dhb =3D fdesign.decimator(2, 'halfband', 'N,AST', 20, 80, 200e6);
> > hb =3D design(dhb);
> > hb.Numerator =3D
> > 0 =A0 =A00.0015 =A0 =A0 =A0 =A0 0 =A0 -0.0083 =A0 =A0 =A0 =A0 0 =A0 =A0=
0.0283 =A0 =A0 =A0 =A0 0
> > -0.0801 =A0 =A0 =A0 =A0 0 =A0 =A00.3087 =A0 =A00.5000 =A0 =A00.3087 =A0=
=A0 =A0 =A0 0
> > -0.0801 =A0 =A0 =A0 =A0 0 =A0 =A00.0283 =A0 =A0 =A0 =A0 0 =A0 =A0-0.008=
3 =A0 =A0 =A0 =A0 0
> > 0.0015 =A0 =A0 =A0 =A0 0
>
> > Regards,
> > vizziee.
>
> I gather that since I specified the order of this half-band filter, it
> is bound to have 21 coefficients. The condition N =3D 3q+1 where N =3D
> order of the filter and q a non-neg integer for half-band filters is
> only applicable when one designs it for "minimum order".
>
> Regards,
>
> vizziee.- Hide quoted text -
>
> - Show quoted text -
Vizzee,
You have a newer version of MATLAB than I do, so I do not know what
all of the implications are of the MATLAB code you posted. nor exactly
how you are going to use the result. Here are a couple of comments
you can read and forget if they are not relevant to what you are
doing.
If you are using this as a polyphase filter implemented as two equal
length filters then you would drop the leading 0 coefficient. When you
then put alternate coefficients into the two filters, one will be all
nonzero taps, and the other will be all zeros except for the 0.5
term. If you implement this using a generic decimate by two polyphase
implementation then the second section will do a lot of multiplies by
zero. This negates the main advantage of using a halfband filter,
which is not multiplying by zero coefficients.
So if you are interested in multiplier efficiency, a general purpose
polyphase filter implementation should not be used for a decimating
halfband filter. There might be a more efficient implementation
script in the newer MATLAB or you could write your own.
Dirk Bell
DSP Consultant
Article: 142089Torfinn Ingolfsen <tingo@start.no> wrote: > Torfinn Ingolfsen wrote: > > Are there alternative development tools for Altera (DE1) that runs under > > FreeBSD? > Icarus Verilog[1] runs under FreeBSD. Thanks to BobH for making me aware > of this tool. And thanks to Steve and Cary for that tool! -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142090
Petter Gustad <newsmailcomp6@gustad.com> wrote: > Torfinn Ingolfsen <tingo@start.no> writes: > > Torfinn Ingolfsen wrote: > > Icarus Verilog[1] runs under FreeBSD. Thanks to BobH for making me > > aware of this tool. > GtkWave runs under Linux and I would assume it runs under FreeBSD as > well. You can then dump the simulation trace in Icarus Verilog and > open it in GtkWave. Dinotrace is another good waveform viewer -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 142091
On Jul 23, 12:36=A0am, Andy Peters <goo...@latke.net> wrote: > I installed the full-up Xilinx ISE 11.x tools on a spare machine so I > could give it a test-drive. (We have a site license.) ... > I opened a WebCase, which I suspect will be ignored like every other > WebCase. > > -a Well, Andy, I hate to say that, but it is your own fault. Perhaps you are a new user ... Using anything but only the fundamental features of the tools is asking for trouble. Even when just using the fundamental tools like "map <option>" in a perl script you will see that they tend to rename and change the way some switches work from release to release. This is a good example of a closed industry that locks out innovation and growth though patents. It is impossible to design a new and fresh FPGA architecture and tool chain without stepping on one or another patent. That's why everybody whines about how bad the tools are how bad and expensive the the FPGAS and support are, and why feature x, y and z are not there ... Xilinx just like all the other players has to make a trade off as to how much money to invest in to tools upgrades and developments and improving FPGAs. Being a large company with many levels of management, they tend to be less efficient than they could be and innovation is at it's minimal level. You want better tools and better FPGAS ? Let you wallet speak. Chose FPGAs from vendors that meet all your needs, that respect you even as a small end-user and meet you budget. I bet you'll be back at X & A ! The moral of it all ? Think positive and you will live longer :*) Cheers, rudiArticle: 142092
Petter Gustad wrote: > GtkWave runs under Linux and I would assume it runs under FreeBSD as > well. You can then dump the simulation trace in Icarus Verilog and > open it in GtkWave. It does, both version 2.x[1] and version 3.x[2]. Thanks for making me aware of it! References: 1) http://www.freshports.org/cad/gtkwave/ 2) http://www.freshports.org/cad/gtkwave3/ -- Torfinn Ingolfsen, NorwayArticle: 142093
Hi all, I have a bunch of used FPGA boards available. They have been replaced in a product by a similar board that has additional NAND Flash. Here are the details of the board: * Altera Cyclone EP1C6Q240 FPGA * 512 KB FLASH (for FPGA configuration and program code) * 1 MB fast SRAM * ByteBlasterMV port * Watchdog with LED * EPM7064 PLD to load FPGA from FLASH (on watchdog reset) * Voltage regulator (1V5) * Crystal clock (20 MHz) at the PLL input (up to 640 MHz internal) * Serial interface (MAX3232) * 56 general purpose IO pins Price is EUR 99,- See: http://www.jopdesign.com/cyclone/index.jsp Cheers, MartinArticle: 142094
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>Hi,
>
>We want to use an XC3S1500 to talk to a single 16-wide 1 gbit DDR2
>dram chip. The coregen thing seems to successfully build a dram
>interface that's claimed to work up to 133 MHz. The DRAM is spec'd to
>work down to 128 MHz, so there's a small overlap window. We'd run at
>128.
>
>Our Xilinx FAE seems to be discouraging us from doing this, without
>saying precisely why, suggesting some other parts. Spartan 6 would be
>ideal (hard dram controller as I understand it) but are unavailable
>for some vague time. We'd rather not use a new part for a single
>project, since we will cut over to the s6's when they are available.
>
>Has anyone done DDR2 from a Spartan 3? Success/horror stories?
I did a DDR design at 100MHz which shares a standard PC memory module
(64 bit wide) between two Spartan 3 FPGAs (800MB/s per FPGA). I didn't
like the MIG tool (way too big, ugly and too limited) so I rolled my
own DDR controller. The trick is to get the sampling point for the
incoming data right. I used a 90 degrees phase shifted capture clock
that hit the sweet spot perfectly. I'm planning on upgrading this
design to DDR2 using the speed grade 5 devices. I still have to do the
math whether the phase shifted clock will work. There has to be a
window in which the data is stable for the FPGA to sample it. If there
is no such window a calibration scheme is required.
I looked at the Spartan 6 FPGA but I doubt it will offer much
improvement. The memory controller is still very limited when it comes
to the amount of memory (width and address space) it can control.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142095Configuration the Flash PROM for Spartan-3 Starter Kit Board. Loading the serial configuration Flash PROM. If you have no parallel port at your PC or Laptop, you can use Digilent’s JTAG-USB cable to load the Flash PROM with the configuration File. There are several Methods to load the PROM and SRAM on the Spartan-3 Board. Here is one Method that works properly: 1) Start the “Generate Programming File” from the Xilinx ISE Software 2) “Configure device using Boundary Scan (JTAG)”. 3) Prepare a PROM File: name.mcs 4) Select the Flash PROM Type (XCF02S). 5) Generate the File: name .mcs Xilinx expects now a parallel port to load the Flash PROM or Xilinx specific ports. Now use Digilent’s Adept Software: Connect the JTAG-USB cable between Laptop and Spartan-3 Board. 6) Start the Adept Software of Digilent. If the Adept driver is correctly installed, Digilent’s Adept recognized the device and initialized the chain. 7) Select the File: name.mcs for the PROM (XCF02S). 8) Start “Program” to load the PROM. Now you can work with the Spartan-3 Board. I had a Problem to load the .bit File directly in the FPGA. There was a warning: “Startup clock for this File is “CCLK” instead of “JTAG CLK”. But you don’t need the .bit File for configuration the Flash PROM, you can take the .mcs File. See also: Application with Spartan-3 Board: www.d-wecker.deArticle: 142096
On Jul 22, 4:45=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote: > It just seems to me from a 'common sense' viewpoint that although the pro= cesses of compiling a C > program and syntesising for an FPGA are very different, the requirements = for managing variants are > almost identical, so a means of doing it in the same way would seem to be= a sensible way to do it. =A0 > A preprocessor which preprocessed all source files in a project, be they = VHDL, pin mappings, timing > constraints, memory contents in a uniform fashion just seems to be an obv= ious way to do it... When the only tool in your toolbox is a hammer, you tend to treat every problem like a nail, and pound it into submission. Pre-processors were developed to handle deficiencies in existing programming languages. Some later languages built in many/most of those features so that the language itself controlled the semantics, not an external text processing step. Seems some SW developers also have a lot of "history" and... > everything is now probaly just too ingrained and hard to change to suit t= he current state of the > art. With modern, optimizing compilers (for both software and hardware languages) constants (and generics in VHDL) can be used to optimize away whole chunks of code, just as if it had been ifdef'd out of existence before it hit the compiler, with or without the limitations of the generate statement. But with the language controlling the semantics, you don't get awkward ifdef constructs that arbitrarily cross language semantic structures (like an ifdef statement mixed around when statements). For example, if you gate all the interface signals to a module with a generic/constant, the synthesis tool will not implement one gate/flop of it (leave the clock and reset alone, they'll go away by themselves). Any simulator worth it's salt will likewise optimize it away (if you care about simulation). On the other hand, if a HW hacker (that's what I'd call an "FPGA developer" that neither simulates nor believes his code will ever be seen/used/maintained by anyone else again) wants to abandon the capabilities of the language for his pre-processor comfy crutches, to each his folly. AndyArticle: 142097
On Jul 23, 6:01=A0pm, Torfinn Ingolfsen <ti...@start.no> wrote: > Torfinn Ingolfsen wrote: > > Are there alternative development tools for Altera (DE1) that runs unde= r > > FreeBSD? > > Icarus Verilog[1] runs under FreeBSD. Thanks to BobH for making me aware > of this tool. > > References: > 1)http://www.freshports.org/cad/iverilog/ > -- > Torfinn Ingolfsen > Norway Look in /usr/ports/cad (http://www.freebsd.org/ports/cad.html) to find more. Still won't help you on programming the part, though.Article: 142098
On Thu, 23 Jul 2009 18:50:00 -0700 (PDT) Brian Davis <brimdavis@aol.com> wrote: > Allan wrote: > > > > "Once a month or once a decade" was more like once > > every few times I toggled the reset input on the DCM, > > on the particular design I tested. The probability > > changed from part to part. On some FPGAs, I couldn't > > make it happen at all. > > > > I agree completely; I've seen similar corruption caused > by DCM startup or other clock switching transients. > > I first noticed this problem ~2003 in a multicycle read > situation similar to that described by Bob P. in 2005: > http://groups.google.com/group/comp.arch.fpga/msg/018c5fc683d5a9aa > > Overall, I consider this corruption issue to be a much > more serious problem than does Peter. > > Why? > > Because any application that switches clock sources on > the fly without a-priori knowledge ( e.g. A/V, networking, > variable sample clocks ), or one that simply recovers > from DCM unlocks, CAN NOT SAFELY USE INITIALIZED BRAM !!! > > ( Unless having an initialization re-load procedure through > reconfiguration or other means ) > > Offhand, I can recall just one Xilinx app note, XAPP873, > that has the proper DCM startup clock enable inhibit logic > for an initialized BRAM. ( disclaimer: I haven't explicitly > trawled the app notes looking for this logic since mid-2008) > > For further reading, here is a list of my posts on this > topic from years past; I've posted just the shorter google > link to individual messages, click the resulting page's > thread title link for the whole thread: > > 2005 thread: "Important BRAM Safety Tip" > http://groups.google.com/group/comp.arch.fpga/msg/458bb7a6301318d9 > http://groups.google.com/group/comp.arch.fpga/msg/67b112027f71ade8 > > 2007 thread: "Use BRAM as ROM (Xilinx)" > http://groups.google.com/group/comp.arch.fpga/msg/30bb0573b9468241 > http://groups.google.com/group/comp.arch.fpga/msg/5f0d539d3c59131e > > 2008 thread: "Aligned PLL clocks in RTL simulation" > http://groups.google.com/group/comp.arch.fpga/msg/3c2200d437d1e9e1 > > > Brian > This sounds like it can be pretty easily worked around by using the lock output of the DCM to switch a clock through a BUFGCE. Assuming, of course, one knows about the need to do so. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 142099
On Jul 24, 1:17=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > On Jul 23, 12:36=A0am, Andy Peters <goo...@latke.net> wrote: > > > I installed the full-up Xilinx ISE 11.x tools on a spare machine so I > > could give it a test-drive. (We have a site license.) > > ... > > > I opened a WebCase, which I suspect will be ignored like every other > > WebCase. > > > -a > > Well, Andy, I hate to say that, but it is your own fault. > Perhaps you are a new user ... No, actually, I've being doing this for a long time -- remember XACT? > Using anything but only the fundamental features of the > tools is asking for trouble. Even when just using the > fundamental tools like "map <option>" in a perl script > you will see that they tend to rename and change the way > some switches work from release to release. I realize that things change all the time, which is why I like to minimize my dependency on the tools. But unfortunately, that's not always possible. And this little archiving feature was one of Xilinx' better ideas, which is probably why they shitcanned it.
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